GLM-5.2 部署新解：NVFP4 + 双路 TP=4 较 TP=8 提升约 2 倍吞吐

近期 r/LocalLLaMA 上的一篇工程分析详细拆解了 GLM-5.2（约 750B 总参数 / ~40B 激活参数的 MoE 模型）在 8xB200 节点上的最优部署方案。核心结论是：使用 NVFP4 量化配合两路 TP=4 副本，可较传统 TP=8 FP8 部署获得约 2 倍节点吞吐量，并将单 token 成本压到约 0.13 美元/M tokens。

模型与硬件基础

GLM-5.2 采用 256 专家、top-8 路由、约 5.9% 稀疏度，注意力层为 DSA + MLA 架构，上下文长度 1M tokens，许可证为 MIT。FP8 权重约 744 GB，NVFP4 量化后约 459 GB（KV cache 仍保持 FP8）。

8x B200 SXM 节点提供 1,440 GB HBM3e 聚合显存、单 GPU 8 TB/s 带宽、900 GB/s/GPU 的 NVLink 5 互联。

关键洞察：带宽而非算力是瓶颈

分析指出一个常被忽视的事实：MoE 解码阶段在中并发下主要由显存带宽而非算力决定——每步需要从 HBM 读取约 40B 激活参数加上完整 KV cache。这带来两个推论：

B200 相对 H200（同 FP8 精度）的 perf/$ 提升仅约 1.2x，与 HBM 带宽比一致，而非 2.3x FLOPs 比。
真正改变成本结构的是 NVFP4：权重字节数减半，且 Hopper 架构根本没有 FP4 tensor core。

NVFP4 量化后，459 GB 权重可放入 4 张 B200 的 720 GB HBM，剩余约 230 GB 给 KV cache。这意味着单个节点可承载两个独立的 TP=4 副本（在负载均衡器后），聚合吞吐约 2×4×4,116 ≈ 33k tok/s，对比 FP8 TP=8 单引擎的约 15.6k tok/s，提升约 2 倍。

公开基准数据

数据来源为 InferenceX / SemiAnalysis，使用 SGLang v0.5.12 配合 EAGLE MTP，ISL=8192、OSL=1024：

FP8，TP=8（整节点单引擎）：

并发 4：417 tok/s/GPU，100.9 tok/s/user，TPOT 9.9 ms
并发 16：953 tok/s/GPU，56.9 tok/s/user，TPOT 17.6 ms
并发 64：1,619 tok/s/GPU，23.6 tok/s/user，TPOT 42.5 ms
并发 256：1,947 tok/s/GPU，11.9 tok/s/user，TPOT 84.2 ms

NVFP4，TP=4（半节点）：

并发 4：1,039 tok/s/GPU，121.2 tok/s/user，TPOT 8.3 ms
并发 16：2,228 tok/s/GPU，66.3 tok/s/user，TPOT 15.1 ms
并发 64：3,740 tok/s/GPU，26.8 tok/s/user，TPOT 37.3 ms
并发 128：4,116 tok/s/GPU，17.6 tok/s/user，TPOT 56.7 ms

成本与延迟权衡

按 SemiAnalysis 公布的 1.95 美元/GPU/小时 B200 TCO 计算，NVFP4 部署在吞吐曲线末端约 0.13 美元/M tokens；其 H200 FP8 参考部署约 1.06 美元/M tokens（80 tok/s/user 下），同模型族下 perf/$ 差距约 3.5x。

需注意的是，TP=8 NVFP4 仅能在延迟维度换取微弱提升（并发 4 时 140 vs 121 tok/s/user），同时牺牲一半单 GPU 吞吐，仅适用于硬性 TPOT SLA 场景。

长上下文与软件版本避坑

1M 上下文在理论上可放入 1,440 GB HBM（FP8 KV），但单次 1M token prefill 会独占整个聚合引擎，建议从一开始就规划 disaggregated prefill。IndexShare 声称 1M 上下文可减少 2.9x FLOPs，但目前尚无独立 TTFT 测量数据。

版本陷阱：SGLang ≤ v0.5.9 在 B200 上通过旧版 flashmla_kv 路径存在 GLM 精度回归（issue #21291），会输出错误结果但不崩溃，应使用 v0.5.10+（默认采用 FlashInfer TRT-LLM 稀疏 MLA on sm100，issue #21783）。NVFP4 的 GLM-5.2 检查点需要 SGLang v0.5.13.post1+ 或 vLLM v0.23.0+。MTP 推荐参数：--speculative-algorithm EAGLE --speculative-num-steps 3 --speculative-eagle-topk 1 --speculative-num-draft-tokens 4。

待验证问题与后续

原帖提出三个开放问题：

社区版 NVFP4 量化在质量上与 FP8 相比如何？
2×TP=4 布局在生产环境中实际能保留多少理论 2x 吞吐（受 scheduler 与 NCCL 争用影响）？
GLM-5.2 上的 MTP 接受率在不同工作负载下的表现（GLM-5 数据暗示解码提升约 40-55%）？

作者团队表示将在未来几周内对自有 8xB200 节点进行实测，后续将发布 FP8 vs NVFP4、TP=8 vs 2×TP=4 及长上下文 TTFT 的对比数据，并附完整 bench_serving JSON。