RuntimeError: RuntimeError when making fake tensor call

快速结论：该报错通常在使用 vLLM 启动 Gemma4 多 token 预测 (MTP) 推测解码时触发，根本原因是在 PR #43957 后，_maybe_share_embeddings() 中的 embedding 宽度守卫错误地阻止了目标模型与草稿模型间的 embedding 权重共享，导致 MTP 的投影层输入维度不匹配。优先检查 vLLM 版本是否包含 fix（#47953 或 #47833）。

问题场景

用户在启动 vLLM 0.25.0 服务时，加载 Gemma4 MTP 草稿模型（google/gemma-4-26B-A4B-it-assistant）作为推测解码器，服务在初始化阶段崩溃。该问题在 NVFP4 量化模型上也同样复现。

报错原文

RuntimeError when making fake tensor call
  F.linear(FakeTensor(size=(s47, 3840)), Parameter(size=(1024, 5632)))
  -> "a and b must have same reduction dim, but got [s47, 3840] X [5632, 1024]"

# 实际运行时的完整堆栈可能不同，核心是线性层维度不匹配
RuntimeError: mat1 and mat2 shapes cannot be multiplied (8192x3840 and 5632x1024)

原因分析

PR #43957 引入了一个 embedding 宽度守卫（width guard），用于判断目标模型与草稿模型的 embedding token 维度是否一致，若不一致则跳过权重共享。这个守卫默认以草稿模型自己的 embed_tokens 宽度（1024）为准，但是 Gemma4 MTP 的 pre_projection 层是为目标 embedding 宽度（2816+2816=5632）构建的。MTP 需要跨宽度共享权重来完成拼接操作：
combined = torch.cat([inputs_embeds, hidden_states], -1)
当共享被错误跳过时，组合后的维度为 2816 + 1024 = 3840，与 pre_projection 期望的 5632 不匹配，导致运行时崩溃。

环境排查

Python 版本：一般与 vLLM 兼容版本保持一致
PyTorch 版本：torch 2.11.0+cu130 等
显卡：A100-80GB / B300 SXM6 等均受影响
vLLM 版本：<=0.25.0 受影响；包含 #47953 或 #47833 的版本修复
模型：google/gemma-4-26B-A4B-it + google/gemma-4-26B-A4B-it-assistant（MTP 草稿模型）
推测解码配置：--speculative-config '{"method":"mtp","model":"google/gemma-4-26B-A4B-it-assistant","num_speculative_tokens":2}'
注意：该问题独立于编译模式和量化策略（enforce_eager、NVFP4 量化均复现）

解决步骤

确认 vLLM 版本：检查当前版本是否 >= 0.25.0，并确认是否包含 #47953 或 #47833 的修复。
应用修复补丁（应急方案）：将 PR #47953 的修改应用到 _maybe_share_embeddings() 函数，gate 守卫逻辑仅对设置了 has_own_embed_tokens 的 EAGLE 草稿模型生效，MTP 草稿默认始终共享权重。
验证修复效果：重启 vLLM 服务，观察日志中关于权重共享的打印是否从 Target embedding dim (2816) differs from draft embedding dim (1024). Keeping separate embedding weights. 变为 Detected MTP model. Sharing target model embedding weights with the draft model.
编译模式验证：修复后，CUDA graphs 应正常启用，无需设置 enforce_eager 作为变通方案。
官方处理建议：等待 vLLM 正式发布包含该修复的版本。Issue 作者已确认两个独立 PR（#47953、#47833）均能解决问题。