GLM-5.2 NVFP4 量化在 4×DGX Spark 跑通 128K 推理

一名 Reddit 用户在 r/LocalLLaMA 发布了 GLM-5.2 的 NVFP4 量化权重（1.5 TB → 410 GB，约 3.7× 压缩），并展示了在 4 张 NVIDIA DGX Spark（GB10，统一显存）上以 RoCE 互联实现 128K 上下文推理的完整方案。该方案将 MLA 注意力、DeepSeek 风格 DSA 闪电索引器、路由与 LM 头保留为 BF16，仅对 MoE 专家 FFN（路由 + 共享）做 NVFP4 量化，GSM8K 准确率相对 BF16 仅下降约 2 个百分点。

关键配置

硬件：4× 标准 NVIDIA GB10 DGX Spark，搭配 Microtik RoCE 交换机
量化：NVFP4 混合检查点（attention/路由/LM 头保留 BF16）
推理栈：vLLM 分支，集成 dark-devotion DCP、B12X 稀疏 MLA、FlashInfer/CUTLASS MoE，并禁用 Spark 多节点 Ray 启动时挂起的 TP/DCP 消息队列广播路径
并行：TP4 / PP1 / DCP4 / MTP1
KV 缓存：fp8_ds_mla，1.81 GB/rank
上下文：max model len 131072，KV 容量 132096 tokens
权重文件：https://huggingface.co/Mapika/GLM-5.2-NVFP4

性能结果

短提示解码（MTP1）：约 14.5–15.2 tok/s
长提示预填：约 450–500 输入 tok/s
c=0 解码：约 15–16 tok/s；长上下文下回落至约 13 tok/s
在一段 112K 未缓存 prompt 的实测日志中，预填吞吐稳定在约 512 tok/s（偶发下降至约 409 tok/s，作者未给出确切解释）

系统级调优

DGX Spark 采用统一内存架构，对系统开销极为敏感。作者对 Ray 与操作系统做了较激进的精简：

Ray 端：禁用 Dashboard、Log monitor、Usage stats，将 Object store 压至 128 MiB，启用 /var/tmp/ray-spill 落盘，每节点仅声明 1 CPU + 1 GPU，启用 host networking/IPC
OS 端：禁用 cups、avahi、bluetooth、ModemManager、colord、fwupd、packagekit、桌面门户/PipeWire 等无头节点无关服务（注意：会同时停用桌面 GUI，仅适用于纯推理节点）

作者特别指出，GB10 上几 GB 的随机 Linux/用户态开销就可能决定模型能否装入。

对比与局限

作者同时对比了 M3 Ultra 512GB 上运行 unsloth Q4_K_S 量化版的体验：在 c=0 时凭借大内存获得微弱的解码领先，但随上下文增长而显著塌陷，原因是 macOS 侧缺乏 MLA 内核支持。

需要说明的是，该部署并非开箱即用的标准 vLLM，而是一个「修补 + 调优 + 资源裁剪」的实验性栈，门槛较高，稳定性也参差（例如文中 112K 上下文下偶发的 409/512 tok/s 反复切换）。原文在长提示预填的进一步数据处被截断，相关细节以作者后续补充为准。