LMSYS 团队公开了一组 DeepSeek-V4-Pro 的服务端优化数据，测试平台是 H20，对照组是英伟达 B300。作者为 Tianyu Zhang、Yusong Gao 和 Yun Zhang，全部工作跑在开源框架 SGLang 上。
先看两条主干数字。预填充阶段，PP2-CP8-TP8 配置在 4K 上下文下达到每秒 16900 token；换成 PP4-CP8-TP8 跑 512K 长上下文，吞吐反而升到每秒 25860 token，处理 100 万 token 耗时 43.7 秒。解码阶段的低延迟场景，单批次在 H20 上每秒出 271 token，B300 是 383.7，两者比值 1.42 倍。
高吞吐场景另有一套配置。DP32-EP32 在 4K 上下文、32 路并发下做到每卡每秒 703.15 token，DP16-EP16 更高一点，759.73。上下文拉到 100 万 token 时，每卡每秒仍有 66 到 67 token。
1.42 倍是个什么概念
H20 是英伟达为中国市场做的合规版本，纸面算力与 B300 之间隔着的远不止一个身位。把单批解码的差距压到 1.42 倍，说明这段路上卡住的并非峰值算力，是访存带宽、通信开销和调度空转。
这也解释了优化清单的构成。收益最大的几项都不在算子精度上：量化热路径融合把 SwiGLU 激活和量化并进一步、去掉中间缓冲，单项吞吐提升 44.0%；把词表权重的点积换成转置 GEMM，减少高并发下的重复读取，吞吐再涨 22.8%；按实测的专家偏好重新做负载均衡放置，又拿到 13.5%。
预填充侧的手法同理。把 7 个算子融成 3 个执行组，首 token 延迟降 3.5%；从生产环境的真实路由直方图里提取高频形状，分别对两组专家权重做针对性优化，首 token 延迟再降 11.35%。最后这一条尤其务实，它没有假设请求分布均匀，照着线上流量本就偏斜的样子去调。
还有一处结构性替换：预填充阶段用张量并行代替专家并行来切 MoE。理由是专家负载不均会拖出长尾，宁可多付一点通信也要把尾巴剪掉。
显存是换出来的
比速度更硬的约束是容量。这组工作里有两项针对显存：Humming MXFP4AFP8 用 MXFP4 存专家权重、配在线 FP8 激活，相对基线拿到 1.71 到 4.47 倍的容量；在线 C128 KV 压缩维护紧凑的聚合状态而不是逐索引状态，贡献 2.268 倍。两者叠加，区间来到 3.88 到 10.14 倍。
对部署方来说，这一项的账最好算。同样一台 8 卡机器，能装下的并发数或上下文长度翻几倍，单位 token 成本就按同样的比例往下走。当卡的数量拿不到增量，容量倍数就是唯一还能自己做主的变量。
DSpark 的贡献单列了一笔：跨流水线阶段协调目标执行与验证步骤之后，每 token 输出时间改善 74.8% 到 78.0%。
把这几项摊到成本上会更直观。假设一台 8 卡 H20 机器的月度持有成本固定，容量倍数提升 4 倍，同一张账单能服务的并发就是原来的 4 倍，单位 token 的机器成本降到四分之一上下（这是粗算，忽略了长上下文带来的额外计算量和路由抖动）。对按 token 定价、毛利本就被价格战压薄的服务方，这一层的腾挪空间往往比换一代卡来得实在，何况卡也未必换得到。
给出的是一张配置表
这篇工作最后落到的并非单一最优解，是一张按场景分档的配置表：预填充在 32K 以内用 PP2、128K 以上换 PP4；解码追求低延迟走 PP2-TP8，追求吞吐走 DP32-EP32，DP16-EP16 留作效率参照。
这种写法本身就是信号。跑分榜要的是一个数字，生产环境要的是知道自己的流量长什么样、该落在哪一档。对手上只有 H20、又必须把 1.6 万亿参数模型服务起来的团队，这张表比任何一条峰值记录都更能直接用上。
参考来源：LMSYS 技术博客、CocoLoop、SGLang 项目文档；吞吐、延迟与容量倍数均取自该博客给出的实测配置表，B300 对照数据同源。