快速结论:该报错发生在 vLLM XPU(Intel GPU)后端运行 Mamba 混合模型并开启 prefix caching(--mamba-cache-mode align)时,首次请求即触发引擎崩溃。优先检查 mamba_utils.py 中 state_base_addrs 张量的数据类型以及 Level Zero 的指针地址是否超过有符号 64 位范围。
适用环境:vLLM 0.23.1rc1.dev920(VLLM_TARGET_DEVICE=xpu)、PyTorch 2.12.0+xpu、Python 3.12.3、Intel Arc Pro B70(Battlemage/Xe2, 32GB)、Level Zero 26.18.38308.1、IGC 2.34.4、oneAPI 2025.3.3、vllm-xpu-kernels 0.1.10.1、triton-xpu 3.7.1。
最快修复方案:暂无确认的一步修复方案。Issue 中提出的建议是修改 mamba_utils.py 中 state_base_addrs 的赋值逻辑,将有符号 64 位整数溢出转换为无符号表示(如 ptr - 2**64 if ptr >= 2**63 else ptr),或改用 uint64 张量;该方案仅为建议,尚未在 Issue 中验证。
注意事项:--mamba-cache-mode align 前缀缓存本身标记为实验性功能,当前 Intel XPU 后端存在指针地址超过有符号 int64 上限的底层兼容性问题。CUDA 后端不受影响,因为其设备指针落在有符号范围内。替代建议(例如直接改用 uint64)可能影响下游 Triton 拷贝内核的地址运算,需额外验证。
问题场景
在 vLLM XPU 后端上,使用混合 GDN/Mamba 模型(如 Qwen3.5 / Qwen3.6 MoE)启动服务,并同时开启 --enable-prefix-caching --mamba-cache-mode align。服务初始化正常,但在发送第一个请求时引擎崩溃。同类问题也可能在仅开启 --enable-prefix-caching 的 Qwen3.6-27B-FP8 模型上出现(如评论中报告的启动阶段崩溃)。
报错原文
ValueError: Overflow when unpacking long long
File "vllm/v1/worker/mamba_utils.py", line 626, in initialize_from_forward_context
self.state_base_addrs[idx] = state.data_ptr()
原因分析
可能原因:在 mamba_utils.py 中,state_base_addrs 被分配为 torch.int64(有符号 64 位)张量。在 Intel XPU 上,Level Zero USM 设备指针的地址值可能超过 2^63,因此将 state.data_ptr() 返回的 Python 整数直接赋值给有符号 int64 张量会发生溢出。CUDA 后端不存在此问题,因为其设备指针落在有符号范围内。
Issue 中的复现实验进一步说明,同一模型在未启用 prefix caching 时正常工作,一旦开启 --enable-prefix-caching 即崩溃,表明问题与缓存路径中指针存储逻辑相关,而非模型本身的换算问题。
环境排查
- 确认是否使用 XPU 后端(
VLLM_TARGET_DEVICE=xpu),以及 vLLM 版本是否为 0.23.1rc1.dev920 或相近的主线版本。 - 确认 PyTorch 版本是否为 XPU 构建(
2.12.0+xpu)及对应的 Level Zero / IGC / oneAPI 驱动版本。 - 确认是否开启
--enable-prefix-caching --mamba-cache-mode align(或仅 prefix caching)并配合 Mamba 混合架构模型。 - 检查
mamba_utils.py中state_base_addrs的数据类型是否为torch.int64,以及第 626 行附近state.data_ptr()返回的地址值。
解决步骤
- 复现问题:以
--enable-prefix-caching --mamba-cache-mode align --max-num-batched-tokens 4096 --dtype bfloat16启动 Qwen3.5/3.6 MoE 混合模型,发送一次 completion 请求,确认报错。 - 定位报错位置:查看堆栈中
vllm/v1/worker/mamba_utils.py第 626 行initialize_from_forward_context方法中的赋值逻辑。 - 验证指针值:在崩溃前打印
state.data_ptr()的原始值,确认是否超过 2^63(约 9.22e18)。 - 尝试修改数据类型或赋值方式(可优先尝试):将
state_base_addrs分配为torch.uint64,或对state.data_ptr()返回值做有符号重解释:ptr - 2**64 if ptr >= 2**63 else ptr,保持 int64 缓冲区不变。注意此方案仅为 Issue 中的建议,并未经作者验证,修改后需重新测试。 - 检查下游内核兼容性:如果修改了张量类型,确认 Triton 拷贝内核的地址运算是否仍按预期工作(其地址算术为模 2^64 有符号补码,理论上可解析出正确指针)。
- 临时绕过(如果不需要该功能):在当前 XPU 环境中暂时不开启
--enable-prefix-caching或--mamba-cache-mode align,可避免崩溃。
验证方法
修复后重新启动 vLLM 服务,发送多条完成请求(包括前缀复用场景),确认不再出现 Overflow when unpacking long long 报错,且 Mamba 前缀缓存命中时输出正常。可通过 vllm bench serve 或批量请求工具验证多轮请求的稳定性。
参考来源
AI 工具推荐
想把多个 AI 模型放在一个入口?
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型,适合写作、绘图、视频和日常 AI 工作流。
推广链接:通过此链接购买,我可能获得佣金,不影响你的价格。
这个方案解决了吗?
可以继续搜索完整报错,或查看同一工具的其他排查指南。
![[Krea-2] `enable_gqa` + `attn_mask` produces high usage of VRAM](https://www.chat-gpts.plus/wp-content/uploads/2026/08/14518-5ee4eb67-768x403.jpg)
![[Bug]: MTP spec decode still advances the grammar matcher after termination when a structural tag is built (residual after #44297)](https://www.chat-gpts.plus/wp-content/uploads/2026/08/52767-d83cfbd1-768x403.jpg)
![[Bug]: Native MTP speculative decoding degenerates into garbage token loops on deep agentic conversations (Qwen3-MoE)](https://www.chat-gpts.plus/wp-content/uploads/2026/08/47087-d5d5041b-768x403.jpg)