[Bug]: Compilation and Execution Performance Issues with GEMS, and vLLM-Plugin Dispatch Problems on Iluvatar

### Bug Description

We are currently facing critical performance and stability issues when using GEMS with vLLM, and additional problems with the vLLM-plugin's dispatch mechanism on Iluvatar (天数) hardware. This leads to service crashes and evaluation failures.

Current Problem
GEMS compilation and execution are significantly slower than expected. This causes vLLM service timeouts, leading to server crashes and failed evaluations.

Available Operator Options
We have three choices for operator dispatch:

Use GEMS directly – As stated, it is too slow, causing timeouts and server failures.

Use the vLLM-plugin to dispatch non-GEMS operators to Iluvatar chips

For non-GEMS operators, the plugin only guarantees numerical correctness on NVIDIA GPUs; the vendor (Iluvatar) is responsible for ensuring they run correctly on their own hardware.

Currently, the plugin-dispatching mechanism for the non-GEMS fused-moe operator fails on Iluvatar with errors.

So far, only fused-moe has been exposed, but there may be other non-GEMS operators that also fail on Iluvatar.

Proposed Solutions
We see three possible ways to resolve these issues:

Option A: Do not use the plugin at all. Instead, use Iluvatar's own vLLM fork (version 0.20) to complete the model serving. Iluvatar's native vLLM should have the correct set of all Iluvatar-optimized operators dispatched.

Option B: Ask Iluvatar to submit all operators that are dispatched in their own vLLM fork into the vLLM-plugin repository, so that the plugin can properly support them.

Option C: Request that GEMS & the compilation/optimization stack reduce the compilation time of Iluvatar-specific GEMS operators by 10×, bringing it to the level of other domestic GPUs (e.g., Muxi, Hygon).

Impact
Evaluation pipelines are blocked.

Service stability is compromised.

We need a timely fix or workaround.

Please let us know which direction is preferred or if there are other suggestions.

### Steps to Reproduce

Using iluvatar+plugin's verified doc, then serving a model like hy-v3-preview

### Expected Behavior

I can evaluate the vllm's API with GPQA-diamond normally

### Actual Behavior

vllm process crashed

### Environment

https://qcnje6z2ldat.feishu.cn/docx/PDEMdKoZzozx4RxhsZ8c7gIrnPg

### Additional Context

_No response_

Start with the iluvatar+plugin verified document and reproduce serving hy-v3-preview while evaluating GPQA-diamond. No repository file, test, or entry point is named; a useful result would identify whether the crash comes from GEMS compilation/execution or non-GEMS fused-moe dispatch and document a verified fix or workaround.

Written by the indexing model from the issue text.