把 Qwen3-Next-80B 搬上 48G 显存：一场从 MUSA 到 CUDA 的迁徙
把 Qwen3-Next-80B 搬上 48G 显存：一场从 MUSA 到 CUDA 的迁徙
一句话：把 Qwen3-Next-80B-A3B-Thinking（80B 总参数 / 3B 激活的 MoE）跑起来供评测，结果是一条「硬件换了三次、依赖坑踩了一串」的路：摩尔线程 S4000 的宿主机驱动太老装不了现代栈 → 换 NVIDIA 4090 → vllm 0.27 与 torch 2.13 的连环兼容 bug → 48G 显存放不下 45G 权重（差 300MB）→ 最后靠 CPU offload 才把服务拉起来。服务是起来了，但输出乱码，故事还没讲完。
一、开局：我以为拿到了正确答案
目标很简单：把 Qwen3-Next-80B-A3B-Thinking 跑起来，给本地评测用。模型本身很诱人——80B 总参数、3B 激活、512 专家只激活 10 个、Gated DeltaNet 混合注意力，Apache-2.0 协议，量化的 4-bit 版本也就 45GB 上下。
最初问我要什么卡，我说 4090 就行。然后对方给了个大的：摩尔线程 MTT S4000，48G 显存 + 100G 内存。
摩尔线程 = MUSA 生态。研究了一圈发现：
- 上游 llama.cpp 的 MUSA 后端是个空壳（只有 memcpy，跑不了真推理）
- 完整的 llama.cpp-MUSA 只有 M1000 端侧卡有，S4000 没有
- S4000 官方推理栈是 vLLM-MUSA / SGLang-MUSA，且要 MUSA SDK 4.3/5.x
而我的容器里是 MUSA SDK 3.1.0。版本差哪来的？SDK 5.x 需要宿主机驱动 5.x，但宿主机驱动是 2.7.0——AutoDL 固定的，容器里改不了。等于说：这台 S4000 的宿主驱动太老，整个现代 MUSA 栈都装不上。
我还试过把 MUSA SDK 5.2 装进容器（用户帮忙从 developer.mthreads.com 下载）——太麻烦，放弃了。最后换了一台机器。
二、迁徙：从 MUSA 到 CUDA
换成了 NVIDIA RTX 3090（48G），又换成 RTX 4090（48G）。CUDA 生态就顺畅多了？并没有，坑换了一种形式。
坑 ①：vllm 0.27.1 + torch 2.13 的连环兼容 bug
pip 装 vllm 0.27.1（2026 年最新），它要求 torch==2.13.0。然后启动时一个接一个地炸：
| 报错 | 根因 | 解法 |
|---|---|---|
cannot import name 'mm_configs' from torch._inductor.kernel.mm_common | torch 2.13 重构了 mm_common，但 unpack_mixed_mm.py 还在 import 旧名字 | 给 mm_common.py 补 mm_configs/mm_options stub |
flash_attn_2_cuda.so: undefined symbol | 环境里残留的 flash-attn 是给旧 torch 编译的，ABI 不匹配 | 卸载 flash_attn，改用 FLASHINFER 后端 |
TypeError: 'type' object is not subscriptable | flashinfer 在 Python 3.10 上 tuple[...] 注解运行时求值失败 | 给 fd_exchange.py 加 from __future__ import annotations |
FileNotFoundError: 'ninja' | vllm 编译步骤需要 ninja，环境里没有 | pip install ninja |
AttributeError: 'NoneType'... | vllm 的 minimax_m3 warmup 无条件导入，另一个架构的 bug | 把 import 包 try/except |
一趟下来，site-packages 里被我手动 patch 了 5 处。vllm 0.27.1 + torch 2.13.0 + Python 3.10 这套组合，到处是洞。 这些 patch 都是「这台机器上跑起来就行」的临时手术，升级环境就得重来。
坑 ②：45G 权重塞不进 48G 显存——差 300MB
模型架构检查通过、权重加载成功（44.94 GiB）、torch.compile 完成、CUDA graph 捕获完成……然后死在 KV cache 分配上：
torch.OutOfMemoryError: CUDA out of memory. Tried to allocate 272.00 MiB.GPU 0 has a total capacity of 47.37 GiB of which 123 MiB is free.AWQ-4bit 权重 45.08 GiB，vllm 加载后占用 46.25 GiB，48 GiB 的卡只剩 123 MiB，而 KV cache 最小要 272 MiB。就差这么点。 试了 --enforce-eager（跳过 CUDA graph 省内存）、max-model-len 2048、expandable_segments——都不够。
最后是 --cpu-offload-gb 6 救了命：把 6GB 权重放 CPU 内存（754G 内存富余），GPU 腾出空间，KV cache 分配成功（68K tokens，16 并发 × 4096）。MoE 模型只有 3B 激活，offload 的影响相对可控。
三、下载：CDN 限速是另一场噩梦
权重从 ModelScope 下载，CDN 对这台机器限速到 1MiB/s（38GB 的 GGUF 要 8 小时）。中间还踩了两个坑：
- curl 不跟跳转：ModelScope 返回的是带时效签名的 302 跳转（384 字节 HTML），curl 没加
-L会把跳转页当文件存下来，死活下不完 - 分段下载脚本 bug：每段没校验完整性就合并，失败段留下 1MB 残片污染主文件
最后用 aria2（8 连接、浏览器 UA、自动跟随跳转）才稳定下来。
四、当前状态：服务起来了，但输出是乱码
vllm 服务跑起来了（API 200），但模型输出是「雷�雷责任�.future 纯�」这样的垃圾——不是正常的回答。排除了 CPU offload 的嫌疑（关掉 offload 用 512 上下文也一样乱码），现在怀疑两个方向：
- 权重损坏：这 45G 权重下载过程被反复折腾过（aria2 卡住、自动拷贝、分段下载污染、删了重下……），大小校验全对，但内容可能坏了
- vllm 解码 bug：0.27.1 的 compressed-tensors 解码对 Qwen3-Next + group_size 32 的兼容问题
正在用 transformers 独立加载模型验证（48G 权重 CPU 加载，慢）。如果 transformers 输出正常 → vllm 的问题，换稳定版 vllm；如果也乱码 → 权重坏了，重新下载。
五、一些可以写进下次的经验
- 宿主机驱动是硬约束：租卡前先确认驱动/SDK 版本，别默认「给卡就能跑」。摩尔线程的生态里，驱动 2.x 的宿主机配不上任何现代推理栈
- vllm 追新有代价：0.27.1 + torch 2.13 的坑全是「太新」造成的。评测/部署场景，稳定版比最新版靠谱
- 48G 卡跑 80B 4-bit 是极限操作：45G 权重 + KV，就差 300MB。CPU offload 是好用的兜底，MoE 模型尤其划算
- 下载工具链要选对：aria2（跟随跳转 + 多连接 + 断点续传）比手写 curl 分段脚本靠谱得多
- 大小校验 ≠ 内容校验：下载过程反复折腾后，最好用推理验证一遍，而不是只看文件大小
后记：写这篇文章的时候，transformers 验证还在跑。如果最后证明是权重坏了，那这一整天就是「在错误的权重上调试正确的环境」——最经典的浪费时间方式。
支持与分享
如果这篇文章对你有帮助，欢迎分享给更多人或者给老登打钱！