本文要点
- 话题从模型发布推进到H20受限硬件上的服务profile和实测曲线。
- 优化对象从单个benchmark分数转向TTFT、TPOT、KV容量和并发的组合账本。
- Humming、Online C128和DSpark被放进同一条H20服务链路评估。
阅读辅助
先看数字、证据和来源，再读正文。
8月19日新闻点是LMSYS的H20服务优化报告，不是DeepSeek再次发布新模型。
2026-07-06 · LMSYS发布DSpark接入SGLang文章，B300上V4-Pro达到383.7 tok每秒。
LMSYS 8月19日的文章把DeepSeek-V4-Pro放到H20这类现实硬件上，公开了一套服务侧优化账本。DeepSeek自己的更新日志显示，V4-Pro GA已经在8月13日面向App、Web和API推出，API调用名仍是 deepseek-v4-pro。所以今天的新增信息，应限定在LMSYS对H20部署的profile拆解、测量结果和工程取舍。
可核实的主体事实有三层。第一，LMSYS称DeepSeek-V4-Pro是 1.6T参数 的MoE模型，带FP8和FP4权重。第二，H20没有Blackwell GPU的原生FP4 Tensor Core和更高峰值算力，但仍有大量部署基础。第三，LMSYS把服务问题拆成prefill、低延迟decode和高吞吐decode，而不是给出一个万能配置。
需要降级处理的部分也很明确。LMSYS报告里的吞吐、容量和精度数字主要来自团队自测；SGLang上游与旧DSpark文章提供了背景路径，但没有替代第三方复现。本文因此把这些数字写成“LMSYS称”“报告显示”，不把它们扩展成DeepSeek官方性能承诺，也不把H20优化写成模型能力再次提升。
对推理平台和企业调用方来说，这份报告的价值在于可操作的排查框架。若团队正在用H20承载长上下文或高并发MoE服务，它提示你先问三个问题：瓶颈在权重显存、KV cache还是decode热路径；请求更看重TTFT、TPOT还是总吞吐；以及现有profile是否把短上下文、1M上下文和批量并发混在同一套配置里。
8月19日新增了什么
LMSYS的核心判断是，一套模型需要多套服务profile。报告把prefill和decode分开处理：prefill不保留长生命周期的每请求状态，主要受TTFT、计算和通信效率影响；decode要为每个活跃请求保留KV cache，因此显存容量会直接限制上下文长度和并发。
在这套分工下，LMSYS把H20-96GB用于prefill，把H20-141GB用于decode。这个选择本身就是报告的第一层增量：它不是按“最强GPU给最重要任务”的直觉分配，而是按服务阶段的资源瓶颈分配。prefill侧可以在容量足够时优先通信和流水线效率；decode侧则把更大的HBM留给KV cache和长上下文并发。
报告还强调，短输入、长上下文、交互式低延迟和高并发吞吐会把系统推向不同极限。短上下文下，PP2较浅的pipeline减少填充和排空开销；长上下文下，PP4有足够chunk喂满更深的pipeline。decode侧，单节点TP8适合作为batch size 1的低延迟参考，但它在1M上下文下只能容纳batch size 1；PP2-TP8牺牲一部分跨阶段开销，换来更大的KV空间。
| 服务阶段 | LMSYS采用的profile | 优先约束 | 可迁移的判断 |
|---|---|---|---|
| Prefill短上下文 | PP2-CP8-TP8 | TTFT和pipeline开销 | 短请求不一定适合更深pipeline |
| Prefill长上下文 | PP4-CP8-TP8 | chunk数量和总输入吞吐 | 1M prompt能摊薄pipeline固定成本 |
| 低延迟decode | 单节点TP8与PP2-TP8 | batch 1速度和KV容量 | 最快profile未必能服务长上下文并发 |
| 高吞吐decode | DP16-EP16与DP32-EP32 | per-GPU效率和容量 | 扩大EP可释放显存，但跨节点流量上升 |
这张表比单个吞吐数更重要。它把“能不能跑DeepSeek-V4-Pro”拆成“在哪种请求分布下，用哪个profile跑”。对生产系统而言，平均吞吐只是结果；profile选择才是能否稳定满足SLO的原因。
H20上的三类瓶颈
第一类瓶颈是模型权重占用。LMSYS使用Humming MXFP4AFP8，在H20缺少原生FP4 Tensor Core的情况下，以MXFP4专家权重和在线FP8激活降低权重footprint与内存流量。SGLang PR 23754已经提供Humming量化kernel背景，PR正文提到它类似Marlin，但强调大batch和Hopper场景下的性能、JIT编译和DeepSeek V4的W4A8支持。
第二类瓶颈是KV cache容量。LMSYS把Offline C128与Online C128做了区分：前者保留每个压缩page的per-index状态，后者维护更紧凑的聚合状态，把更多HBM让给KV池。报告说Online C128会引入额外状态维护和speculative verification工作，但在其测试中没有观察到TPOT回退。
第三类瓶颈是decode热路径。DSpark在7月的LMSYS文章里已经作为SGLang推测解码路径出现，当时B300、TP8、DeepSeek-V4-Pro的batch size 1参考达到 383.7 tok每秒。8月这篇H20报告把它放进更复杂的场景：PP2-TP8需要跨两个pipeline stage协调投机循环；DP32-EP32则要处理高并发下的refinement和专家路由长尾。
| 优化组件 | 解决的问题 | LMSYS报告中的数字 | 不能外推的部分 |
|---|---|---|---|
| Humming MXFP4AFP8 | 降低权重footprint和内存流量 | DP32-EP32容量先提升 1.71x | 不是模型参数变少 |
| Online C128 | 减少C128辅助状态占用 | 在Humming上再给 2.268x 容量 | 不是无成本扩容 |
| Optimized DSpark | 降低decode TPOT | batch 1 peak TPOT降 74.8%-78.0% | 不等于所有batch同幅提升 |
| Humming热路径融合 | 减少中间buffer和量化pass | 匹配A/B per-GPU吞吐增 44.0% | 仅限报告所测工作点 |
把这些数字合并看，H20方案仍然没有抹平Blackwell的硬件差距。LMSYS自己的说法更克制：profile化和系统优化可以让观测到的服务性能更接近某些任务的前沿参考。最典型的数字是单节点H20-141GB在batch size 1下达到 271 output tokens每秒，B300背景值为 383.7 tokens每秒，报告称观测decode性能比收窄到 1.42x。这句话的比较基准是“最高观测生成速率”，不是峰值Tensor Core算力。
关键数字怎样读
prefill侧，报告给出两个层次的指标。入口摘要称优化prefill达到 8.45k input tokens每秒每节点，并能在 43.7秒 处理 1M-token prompt。附录里，PP4在1M输入长度上的Final TTFT为 43,742.5ms，Final Total Input Throughput为 23,970 tokens每秒；PP2在短上下文有优势，在4K和32K相对PP4分别降低TTFT 16.7% 和 19.5%，但从128K开始PP4明显反超。
decode侧，报告把低延迟和高吞吐分开报。低延迟profile中，Optimized DSpark在四个输入长度上把batch size 1的peak TPOT降低 74.8%-78.0%；在每组共同最大batch上，降低幅度仍有 52.2%-60.0%。高吞吐profile中，4K、每个DP rank并发32请求时，单GPU吞吐从 319.92 tokens每秒 增至 703.15 tokens每秒，提升 2.20x。
容量侧，最容易误读。LMSYS定义的full-token capacity是“权重和runtime buffer分配后，每个rank可容纳的full-attention KV token上限”，它不是可直接承诺给用户的最大batch。报告中，DP32-EP32从Baseline FP8加Offline C128的 1,475,328 tokens每rank，经Humming与Online C128到 5,731,328 tokens每rank；PP2-TP8从 1,089,024 tokens每rank 到 11,044,906 tokens每rank。这解释了为何同样是H20，服务可用性可能差一个数量级。
精度验证则要更谨慎。LMSYS称DP16-EP16的Humming MXFP4AFP8加Online C128加DSpark profile在GSM8K1000上达到 95.5% exact-match accuracy，有1个无效响应、0个系统错误，超过 95.0% 验收阈值。它还引用SGLang Humming集成PR里的200题GSM8K公开参考，其中DeepSeek-V4-Flash上的Humming MXFP4AFP8为 97.0%。这只能说明数学短题口径下没有明显崩坏，不能覆盖编码、长上下文、工具调用和安全拒答。
和8月13日DeepSeek GA的关系
DeepSeek API文档现在已经写得很明确：V4-Pro的GA release在8月13日已经 rollout 到App、Web和API，调用方式保持不变，设置模型名 deepseek-v4-pro 即可使用最新版本。Models & Pricing页面列出当前模型版本为 DeepSeek-V4-Pro-0813，上下文长度为 1M，最大输出为 384K，并发限制为 500。
价格也已经进入新口径。价格页显示V4-Pro按peak和off-peak分档：缓存命中输入每百万token为 $0.044 与 $0.022，缓存未命中输入为 $1.32 与 $0.66，输出为 $3.96 与 $1.98。DeepSeek更新日志写明，新价格在 2026年8月16日16:00 UTC 生效，并说明off-peak价格设为peak-hour价格的一半。这里不能把“调整后价格”写成8月19日的新变化；它只是理解LMSYS H20优化经济性的背景。
这一区分会影响标题和摘要。8月13日讲的是DeepSeek官方产品状态、API名称和价格口径；8月19日讲的是LMSYS如何在H20上服务这个模型。若把两者合成“DeepSeek发布H20优化版新模型”，既错过了LMSYS报告的工程价值，也会误导读者以为模型权重或API版本在8月19日再次变化。
这份报告的价值首先落在方法论：它把大模型服务从“买更强GPU”重新拉回到“拆清工作负载”。当模型已经大到权重、KV、通信和投机解码互相牵制时，部署质量不再由单一benchmark解释。谁能把prefill、低延迟decode和高吞吐decode分开profile，谁就能在相同硬件上多挤出一段可用区间。
对国内和受限硬件环境，H20仍是现实约束。LMSYS没有声称H20消除了Blackwell差距，反而把差距拆开给出了工程补偿路径：权重侧用Humming减少footprint，KV侧用Online C128扩容量，decode侧用DSpark与热路径融合降低TPOT。这种写法比“国产模型又提速”更有价值，因为它告诉服务团队该把profile和日志埋点放在哪里。
但早报的判断边界也必须清楚。报告数字仍主要来自LMSYS自测，GSM8K1000不是完整质量证明，Humming和Online C128也不是免费午餐。下一步能否成立，不看社交媒体复述，而看第三方H20集群能否复现曲线，看SGLang上游能否把关键路径稳定合入，看真实多租户流量下尾延迟是否仍可控。
推理团队应当怎么用这份报告
第一步不是照抄profile，而是把自家流量分桶。短提示聊天、长文档prefill、代码Agent多轮工具调用和批量离线生成，不应该共用同一个容量和延迟假设。LMSYS的结论是“从工作负载和SLO出发选择profile”，而不是“PP4永远优于PP2”或“DP32永远优于DP16”。
第二步是把容量指标翻译成准入策略。full-token capacity越高，意味着系统可容纳的KV上限越大，但生产环境还要扣掉系统prompt、工具消息、缓存策略、并发隔离和失败重试。报告中的 11.04M tokens每rank 可以作为工程目标，却不能直接写成“每个用户都能稳定获得1M上下文乘以多并发”。
第三步是单独复核量化与投机解码的质量。Humming MXFP4AFP8和DSpark提升的是服务效率，可能影响不同任务的数值稳定性、工具参数格式和长上下文召回。LMSYS给出的 95.5% GSM8K1000结果是一个必要但不充分的信号。编码平台、客服系统和安全敏感产品仍需要自己的回归集。
最后，采购和平台团队要把8月13日的DeepSeek产品口径与8月19日的LMSYS工程口径并排看。前者决定你调用的是什么版本、用什么价格和API特性；后者决定同一模型在H20上能否服务得起。只有当版本、价格、profile和复现曲线一起稳定，这类模型才算真正从“可调用”进入“可运营”。