[XPU] Fix Eagle3 initialization on XPU - #43957
Conversation
d3f30f4 to
fcb68e9
Compare
91610ba to
b4e6f7b
Compare
b4e6f7b to
d2713ca
Compare
|
@jikunshang @benchislett please help review |
f79212f to
2da5852
Compare
1d52a8e to
22d60ac
Compare
22d60ac to
9c22079
Compare
|
Please take a look the failed UTs. |
5ea7945 to
9ce89a6
Compare
Signed-off-by: Chaojun Zhang <chaojun.zhang@intel.com>
|
@jikunshang - This PR breaks Gemma 4 MTP. It fails with "Target embedding dim (2816) differs from draft embedding dim (1024). Keeping separate embedding weights." Gemma4MultiTokenPredictor.pre_projection expects 2 * backbone_hidden_size, so for this model it expects 2816 + 2816 = 5632. After #43957 prevents embedding sharing, the draft path feeds 1024 + 2816 = 3840, producing the observed error: The easiest fix would be to change the guard from. I tested it on DGX Spark and it seems to work: if share_embeddings:to: if share_embeddings and hasattr(self.model, "has_own_embed_tokens"):@mgoin - FYI |
@eugr ,can you paste your test command ? |
|
@chaojun-zhang - here we go: vllm serve nvidia/Gemma-4-26B-A4B-NVFP4 \
--max-model-len 262144 \
--gpu-memory-utilization 0.8 \
--port 8000 \
--host 0.0.0.0 \
--max-num-seqs 8 \
--load-format fastsafetensors \
--enable-prefix-caching \
--enable-auto-tool-choice \
--tool-call-parser gemma4 \
--reasoning-parser gemma4 \
--max-num-batched-tokens 8192 \
--speculative-config '{"method":"mtp","model":"google/gemma-4-26B-A4B-it-assistant","num_speculative_tokens":4, "moe_backend": "triton"}'This is for DGX Spark, so you'd need to adjust parameters accordingly for your test platform. |
Signed-off-by: Chaojun Zhang <chaojun.zhang@intel.com> Co-authored-by: Andreas Karatzas <akaratza@amd.com> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com> Co-authored-by: Kunshang Ji <kunshang.ji@intel.com>
Signed-off-by: Chaojun Zhang <chaojun.zhang@intel.com> Co-authored-by: Andreas Karatzas <akaratza@amd.com> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com> Co-authored-by: Kunshang Ji <kunshang.ji@intel.com>
Purpose:
Fix Eagle3 draft model embedding sharing when the target and draft models have different embedding widths.
Why
tests/models/test_initialization.py uses a patched _initialize_kv_caches_v1 to skip the warmup path. That patch works under
forkwithcreate_process_for_each_testbecause the child inherits the test process state, but it does not work under spawn because the child starts fresh. On XPU, that means the real warmup path still runs and exposes the invalid embedding sharing.Changes
Add an embedding-dimension check before sharing embed_tokens.
Keep target and draft embeddings separate when their widths differ.
Log the mismatch so the fallback is visible.
Test plan (CUDA):
VLLM_WORKER_MULTIPROC_METHOD=spawn pytest -v -s tests/models/test_initialization.py::test_can_initialize_large_subset[Eagle3MiniMaxM2ForCausalLM]
Test output