128 GB Thor 跑 120B 级模型：Qwen3.5-122B 与 Flash-Next NVFP4 实测
2026 年 11 月 4–5 日，我在同一台 Jetson AGX Thor 上先后跑通了 nvidia/Qwen3.5-122B-A10B-NVFP4 和 nvidia/Qwen3.8-Flash-Next-NVFP4。两者都采用文本模式、64K 上下文、FP8 KV cache，最多两个活动序列。单路生成实测约为 16 和 22 tok/s。
Flash-Next 能放进这台 128 GB 统一内存设备，关键配置是 --engram-config '{"disk_offload": true}'：约 54 GB 的 PLE 表保留在磁盘 checkpoint 中按需读取，而不是整表常驻分配。
这是一次部署观察记录。每个并发档只有少量请求，两组测试使用不同 vLLM 版本，也没有隔离所有缓存状态，因此下文数字适合判断工程可行性，不构成严格的架构性能排名。
测试环境与证据
| 项目 | 配置 |
|---|---|
| 设备 | NVIDIA Jetson AGX Thor，标称 128 GB 统一内存 |
| 计算能力 | sm_110 |
| 系统 | JetPack / L4T R39.2，MAXN |
| 宿主机 CUDA 驱动 API | 13.2 |
| Qwen3.5 运行时 | vllm/vllm-openai:v0.28.0 |
| Flash-Next 运行时 | 官方 nightly-aarch64，0.33.0rc1.dev806+ga2bcb5657 |
| 服务设置 | --max-model-len 65536 --max-num-seqs 2 --kv-cache-dtype fp8 |
| 模态 | --language-model-only，未验证图像或视频输入 |
宿主机驱动支持的 CUDA 版本与容器里的 CUDA runtime 不是同一个字段。122B 的现场 README 记录容器为 PyTorch 2.13.0 / CUDA 13.0，不能把它统一写成“所有软件均为 CUDA 13.2”。
本文根据 Thor 上的 thorllmtest/README.md、启动脚本和现场记录整理，2026 年 11 月 10 日通过 SSH 复核。可下载部署结果摘录 JSON；该文件是有来源说明的汇总，不是逐请求原始日志。小模型验证及三个 API Demo 见配套文章。
第一站：Qwen3.5-122B-A10B NVFP4
NVIDIA 模型卡列出的结构是 122B 总参数、10B 激活参数。此次模型快照为 98915d837c4e7c87ac8296d02e89de19b3207e6d。
| 项目 | 现场记录 |
|---|---|
| 权重文件 | 77.79 GiB |
| 运行时模型占用 | 72.37 GiB |
| 64K 配置下 KV cache | 12.02 GiB |
| 日志报告的 KV token 容量 | 747,706 |
| 单路生成 | 约 16 tok/s |
| 双路聚合输出吞吐 | 约 27.8–31.9 tok/s |
| 短输入 TTFT | 约 0.4 s |
双路吞吐的两个端点来自不同测试轮次。首次 README 表格记录 27.79 tok/s，后续对比表记录 31.9 tok/s，保留范围比挑一个最好数字更准确。服务的调度并发仍然是 2；KV 容量不能直接换算成已验证的几十路服务能力。
长输入的等待更能反映实际体验：约 14K 输入需要 7.6 秒才开始输出，30K 需要 19.3 秒，60K 需要 50.5 秒。能配置 64K 上下文，和长文档请求能否及时回复，是两个需要分别验证的问题。
第二站：Flash-Next 与 PLE disk offload
现场记录将 Flash-Next 标为约 125B 总参数、6B 激活参数，采用 MoE、Gated DeltaNet、QSA 稀疏注意力与 PLE n-gram 嵌入。本文固定讨论此次 checkpoint 与运行时组合，不将这一参数口径扩展到其他同名变体。
模型 revision 为 fc694b54fb0174e0913e6adf86691ef85a4ead47，镜像固定为：
vllm/vllm-openai@sha256:cca10003856866925653fb4ec45309df385dc15f802dbd47c289eb9c5720f197
启动参数里最关键的几项是：
--engram-config '{"disk_offload": true}' \
--kv-cache-dtype fp8 \
--max-model-len 65536 \
--max-num-seqs 2 \
--mamba-cache-mode align \
--enable-prefix-caching \
--gpu-memory-utilization 0.75
这里卸载的是 PLE 表，不能理解为把全部 MoE 权重或 KV cache 都卸载到磁盘。运行时记录的模型占用为 72.89 GiB；它也不是整机内存占用，系统、KV、临时缓冲和文件页缓存还需要空间。
vLLM 的 Engram 文档解释了这种 disk offload 路径：按需读取 checkpoint 的表行，近期读取的数据可以由操作系统页缓存提供。因此它省去整表常驻分配，但不代表读取过程完全不使用 RAM，也不能假设冷缓存和热缓存的延迟相同。
同机观察：生成和长输入都改善了
| 指标 | Qwen3.5-122B | Flash-Next |
|---|---|---|
| 单路生成 | 约 16 tok/s | 约 22 tok/s |
| 双路聚合 | 约 27.8–31.9 tok/s | 约 37.9 tok/s |
| 30K 输入 TTFT | 19.3 s | 14.0 s |
| 60K 输入 TTFT | 50.5 s | 27.9 s |
按这些观察值，Flash-Next 单路约快 38%，30K 和 60K 输入等待分别缩短约 27% 和 45%。双路对比如果取 31.9 tok/s，则提升约 19%；若取首轮 27.8，提升幅度会不同。
混合注意力和更少激活参数是值得继续验证的解释，但这次模型结构、vLLM 版本、kernel 路径及缓存条件一起变化了。数据支持“这套 Flash-Next 配置在本次测试中更快”，暂时不能把全部收益归因于某一层或某一种注意力。
还有一个直观的交互例子：同样问“用三句话解释 MoE”，122B 生成 2,034 tokens、耗时 125 秒，Flash-Next 生成 156 tokens、耗时 7.5 秒。后者完成得约快 17 倍，但输出长度也大幅减少。这是一次任务完成时间的例子，不能写成解码速度提高了 17 倍，也不能凭一个问题证明它普遍更省思考 token 或质量更好。
第三站：FP4-Local / b12x 路径启动失败
我也尝试了 nvidia/Qwen3.8-Flash-Next-FP4-Local，配合 eugr/spark-vllm-b12x:nightly-20261102，把 CUTE_DSL_ARCH 改成 sm_110a。该组合没有启动成功，实际日志为：
ValueError: Failed to find a kernel that can implement the NVFP4 linear layer.
B12xNvFp4LinearKernel: B12X NVFP4 kernels require a Blackwell 12x device
这条失败定位到该镜像选择的 b12x NVFP4 linear kernel。修改架构环境变量不能补出一个不支持 sm_110 的内核实现。Thor 与 Spark 方案的兼容性要核对到具体 kernel，而不能只看“Blackwell”名称。这个结论限于此次镜像与配置，不表示所有 FP4 路径都无法在 Thor 上运行；前面的标准 NVFP4 路径已经跑通。
复现入口与运行边界
下载整理后的启动脚本，在 Thor 上执行。它依据现场脚本整理，额外固定 122B revision，并将监听地址收敛到本机；先把对应 revision 下载到 Hugging Face 缓存，脚本采用离线加载。一次只运行一个大模型，启动前确认 8000 端口与目标容器名未被占用。
# 二选一；运行前需准备模型缓存与 NVIDIA Docker runtime
bash serve.sh flash-next
# 或
bash serve.sh qwen35
curl http://127.0.0.1:8000/v1/models
docker logs --tail 100 qwen38-flash-next
服务加载完成后再运行配套文章中的 Demo。11 月 10 日复核时，Thor 已重启，当前没有大模型运行，因此本文没有把旧 Web UI 或服务地址作为公众在线体验入口。
本次没有测试 MTP，也没有完整质量评估和长时间稳定性结果。11 月 9 日另一次测试曾在 Flash-Next 驻留、可用内存约 18 GB 时失联；现场现象提示要认真管理统一内存余量，但缺少故障时内核证据，不能断言某个分配或 docker pull 是唯一根因。
这次最有用的结果是：在明确的 NVFP4、FP8 KV、64K 和双路配置下，120B 级 MoE 已能在单台 Thor 上完成本地文本推理。下一步应固定缓存冷热状态和相同运行时，扩大请求数，再验证长文档、输出质量及持续服务的表现。