[Bug]: Multi card issue and multi token prediction (mtp) issue with Intel/Qwen3.6-35B-A3B-int4-mixed-AutoRound

快速结论：该报错通常出现在 Intel XPU（Arc Pro B70）上用 vLLM 部署 Intel/Qwen3.6-35B-A3B-int4-mixed-AutoRound 这类 int4 混合量化模型时，涉及 2 卡张量并行（TP=2）与多 Token 预测（MTP）/投机解码两类场景。优先排查量化后端（ARK 与 oneDNN W4A16）与 auto-round 内核版本的匹配问题。

适用环境：Ubuntu 24.04.4 LTS；Python 3.12.3；PyTorch 2.13.0+xpu；Intel Arc Pro B70 ×2；Level Zero loader 1.32.0；oneCCL 2022.0.0；vLLM XPU kernels 0.1.13.2（正文环境）。后续验证中出现 vllm 0.28.1rc1.dev691+g1c75d8397、vllm-xpu-kernels 0.1.14.1、auto-round-lib 0.16.0.dev202609151011、oneAPI DPC++/C++ Compiler 2026.0.0。

最快修复方案：Issue 中明确验证过的首选处理是：强制 vLLM 改用 oneDNN W4A16 后端（而非 ARK）运行，即设置环境变量 VLLM_XPU_INC_WNA16_BACKEND=w4a16；或改为从源码构建最新的 auto-round-kernel（在同一容器内执行）。

注意事项：上述环境变量方式被报告为“quick workaround”，属于绕过而非根因修复；源码构建方式被报告为“direct fix”。两种方案是否适用于 vLLM v0.29.0 官方镜像并未在 Issue 中确认（提问者使用自源码构建的最新 main，提交 b0898a493737ed34864efb2dbebc36a73ea043c5）。MTP 配置中的 qwen3_next_mtp 与 mtp 是 Issue 中提到的两种可选写法，具体适用性需按版本自行验证。

问题场景

用户在 Intel Arc Pro B70 双卡环境上，用 vLLM 或 LLM-Scaler 部署 Intel/Qwen3.6-35B-A3B-int4-mixed-AutoRound 量化模型。触发问题的场景主要有三类：

2×B70 双卡运行时出现 runtime failure，推理负载为图片解释（Visual Language Model 输入）。
启用多 Token 预测（MTP）/投机解码时无法正常工作。
希望把模型分布到两张卡上（部分层在一张卡、其余层在另一张卡），以扩大可用 VRAM、支持更长上下文和更高并发。

报错原文

[Bug]: Multi card issue and multi token prediction (mtp) issue with Intel/Qwen3.6-35B-A3B-int4-mixed-AutoRound

Issue 正文与评论中未附带完整的英文堆栈文本，仅提供了 2×B70 复现日志文件（container.log）。因此这里保留标题中的核心报错原文，其余以场景描述为准。

原因分析

根据 Issue 讨论，最可能的原因集中在量化内核路径上：

可能原因一：int4 混合量化模型在 Intel XPU 上默认走 ARK 后端，而该后端在当时的内核版本下对 2 卡 TP 与多模态输入支持不完善，导致 runtime failure。
可能原因二：auto-round 内核版本偏旧。讨论中提到 intel/auto-round 的 PR #2331 在 B70 上验证通过，提示问题可能已在更新的 auto-round-lib 中修复。
可能原因三：MTP / 投机解码与量化层或 model runner 的交互存在问题，需提交完整堆栈和触发 MTP 的代码片段才能定位，但 Issue 中并未给出对应堆栈。

环境排查

确认 vLLM 版本与安装方式：是否使用官方 XPU 镜像（如 vllm/vllm-openai-xpu:v0.29.0），还是从源码构建的 main 分支。
确认 vllm-xpu-kernels 版本（环境报告为 0.1.13.2，验证环境为 0.1.14.1）。
确认 auto-round-lib 版本（验证环境为 0.16.0.dev202609151011）。
确认 PyTorch 为 XPU 构建（2.13.0+xpu），并检查 Is XPU available 为 True。
确认双卡是否被正确识别（GPU 0 / GPU 1 均为 Intel Arc Pro B70）。
确认 Level Zero loader / driver 版本、oneCCL 版本、Intel oneAPI 编译器版本。
若启用 MTP，确认所用的 --speculative-config 字段写法（mtp 或 qwen3_next_mtp）及 num_speculative_tokens 取值。
若为多模态输入，确认模型与 vLLM 版本是否支持 Visual Language Model 路径。

解决步骤

先复现原始问题：用 vLLM 或 LLM-Scaler 部署 Intel/Qwen3.6-35B-A3B-int4-mixed-AutoRound，在 2×B70 上以 TP=2 运行，并传入图片请求解释内容，记录完整堆栈。
若目标是尽快恢复可用，采用讨论中验证过的 quick workaround：强制 vLLM 使用 oneDNN W4A16 后端而非 ARK，即在启动环境中设置 VLLM_XPU_INC_WNA16_BACKEND=w4a16，并保持 TP=2 与 MTP 配置（method 为 qwen3_next_mtp，num_speculative_tokens 为 2）。报告中该方式下服务可正常启动并生成文本。
若希望做根因修复，采用讨论中验证过的 direct fix：在 vLLM 所在的同一容器内，从源码克隆 intel/auto-round，进入 auto_round_extension/ark 目录，加载 oneAPI 环境后以 --no-build-isolation --force-reinstall --no-deps 方式重新安装，以构建最新的 auto-round-kernel。
如需在双卡间拆分模型层以扩大 VRAM，可参考验证命令中使用 --tensor-parallel-size 2 配合 ZE_AFFINITY_MASK 指定两张卡的思路（该命令出现在 Issue 评论中，用于 ARK 后端验证）。
完成任一方案后，重新以相同负载（图片解释 + MTP/投机解码）发起请求，验证是否不再出现 runtime failure。

验证方法

重新启动服务后，确认 vLLM server 能成功启动（无 runtime failure），并实际发起一次图片解释请求，观察是否能正常返回文本；若启用 MTP，确认投机解码路径下也能正常生成。Issue 中报告使用 VLLM_XPU_INC_WNA16_BACKEND=w4a16 时“server started successfully and generated text”，可作为成功判据参考。