H20 和 B300 的差距，通常被描述为“代差”。但 LMSYS 团队在 2026 年 8 月公布的实测数据，把这个代差撕开了一道口子：1.6 万亿参数的 MoE 模型 DeepSeek-V4-Pro，在单节点 H20-141GB 上跑出了 271 output tokens/s，而 B300 的参考成绩是 383.7 tokens/s。差距只有 1.42 倍。别小看这个数字——这不是拿 H20 去硬刚旗舰，而是用一套场景化服务配置，让中端卡摸到了旗舰卡的尾巴。文章的核心不在于 H20 本身有多强，而在于 LMSYS 如何重新定义了“优化”这件事。
271 对 383.7，一场不寻常的逼近
先放下架构分析，把目光落在这两个数字上。B300 的内存带宽是 H20 的数倍，计算单元也更大，理论上 H20 跑 DeepSeek-V4-Pro 这种级别的 MoE 模型，吞吐差距应该翻倍甚至更多。但 1.42 倍意味着，B300 并没有赢得很轻松。
H20 的先天短板被针对性拆解
H20 的痛点不只是算力弱，更在于显存带宽和 HBM 容量之间的平衡。DeepSeek-V4-Pro 采用 MoE 架构，1.6 万亿总参数，但单次推理只激活一部分专家。LMSYS 的做法很直接：不去和 B300 比拼峰值算力，而是把所有资源都压在“让激活参数以最高效率流过 GPU”这件事上。他们承认 H20 的短板，但没有被短板绑架。
旗舰卡的优势被“场景化”稀释
B300 的 383.7 tokens/s 是什么条件下跑出来的？LMSYS 并没有故意压低它——这本身就是参考实现。关键在于，B300 的优势在长上下文、高并发场景下才充分释放，而那些场景并不总是存在的。一旦服务配置针对真实流量做裁剪，H20 就能把用不上的余量腾出来，补到短板上去。
参考实现的真正价值
271 tokens/s 不是实验室里的一次调参侥幸。LMSYS 把它定义为“参考实现”，意味着任何人按照同样配置都能复现。这比“某专家手工调了一周”的案例有价值得多。它给出了一个可量化的基准：在特定硬件上，通过合理的推理服务配置，你能期望自己离 B300 有多近。
别谈通用，谈场景
LMSYS 这份工作的核心不是用了什么黑科技，而是把“通用优化”这个概念彻底抛弃了。他们提出，DeepSeek-V4-Pro 的推理服务应当按上下文长度与并发需求分场景选择 prefill/decode 配置。同一张 H20，不同场景下应该跑不同的配置，而不是一个静态方案包打天下。
上下文长度是第一把尺子
短上下文和长上下文的 prefill 开销完全不是一个量级。LMSYS 在配置中明确区分了短上下文场景和长上下文场景——比如处理 4K 以下的普通对话时，prefill 阶段可以激进地使用更大的 batch；而面对 1M 上下文时，prefill 必须被拆碎，否则显存会瞬间爆炸。这种场景区分，让 H20 在短上下文下不至于为长上下文的能力买单。
并发需求决定 prefill/decode 权重
decode 阶段是 token 吐出的瓶颈，prefill 阶段则是吞入并发的瓶颈。如果服务主打高并发短请求，那么 prefill 的吞吐必须优先保障，否则排队时间会毁掉体验；如果服务主打低并发长输出，decode 的连续性反而更重要。LMSYS 的思路是让两者解耦，各自按需调整算力比例。听起来简单，但大多数推理框架的默认配置根本没给你选择权。
从“跑得动”到“跑得聪明”
“跑得动”是指模型能输出结果，“跑得聪明”指每一毫秒的 GPU 时间都花在刀刃上。LMSYS 的方案实际上是在给 H20 做“分时复用”——不同时段服务不同场景，靠场景识别动态切换配置。这种思路下，H20 不再是那个“勉强能跑大模型”的中端卡，而是“针对特定流量模式做了专项优化”的推理机。
让 HBM 每一字节都值钱
H20-141GB 总显存看似不小，但 DeepSeek-V4-Pro 的权重、KV cache 和中间激活全挤进去，还要留出 1M 上下文的余量，根本不够用。LMSYS 用两招解决了这个矛盾：Humming 压缩和 Online C128。这俩名字听起来像黑话，但实际上都是从 HBM 里“抠空间”的艺术。
Humming 压缩：把 1M 上下文塞进有限显存
长上下文最大的敌人是 KV cache。1M 上下文的 KV cache 规模大到惊人，如果不压缩，H20 的显存会被吃掉大半，留给计算的空间所剩无几。Humming 压缩的作用是在不显著损失精度的前提下，把 KV cache 的体积压下来。LMSYS 把它用在 prefill 阶段，让 H20 也能服务 1M 上下文——这在以前是不可想象的。值得强调的是，压缩不是无脑有损，而是针对 MoE 模型的稀疏激活特性做的自适应策略。
Online C128：在线换挡释放 HBM
C128 听起来像某种缓存策略，实际是一个在线显存管理机制。它在 decode 阶段动态调整分配，把短上下文的空闲空间回收，再补充给长上下文使用。类比的话，这就像高速公路上的动态车道——早高峰多开进城方向，晚高峰多开出城方向。H20 的 HBM 就这么被盘活了，整个服务过程不再被“最坏情况”锁死。
单节点 H20-141GB 的示范意义
LMSYS 选择单节点作为参考单位，而不是集群，这一点很有心机。单节点是大多数企业实际部署的起点，如果单节点都能把性能做到这个水平，横向扩展到多节点时的收益只会更可控。H20-141GB 这个规格也刚好是当前市场上最主流的“能跑大模型但又不贵”的配置。在这个配置上抠出来的每一分性能，都直接转化为成本优势。
限制是常态，优化是常态
业界对推理优化的惯性思维总是“换更好的卡”。LMSYS 的这次实践彻底打破了这种依赖：先接受硬件限制，再通过服务配置把限制带来的损失降到最低。这让部署者不得不重新思考一个问题——你真正需要的是 B300 的绝对性能，还是那个能覆盖你业务场景的性价比方案？
硬件不该被单点峰值定义
B300 是强者，但强者也有自己的性格：功耗高、价格贵、供货周期长。H20 没有这些焦虑，它就是要靠规模换性能。LMSYS 用 271 tokens/s 这个成绩说明，评估硬件的时候，脱离实际工作负载谈峰值性能就是耍流氓。在特定的服务配置下，中端卡的发挥可以非常接近旗舰卡。
从“买更贵”到“用更巧”
这套方案对预算有限、又必须上大模型推理的团队来说，是个新出口。与其花三倍价钱买一块 B300，不如把 H20 集群的配置调好，让两端差距从“打不过”变成“够用”。LMSYS 没有发明新硬件，只是把已有硬件的潜力挖掘了出来——这种“用更巧”的思路，在算力紧张的当下，比“买更贵”更有现实意义。
这个结果的可复制性
最值得称道的一点是，LMSYS 把整套配置以参考实现的形式公开了。不是论文里的抽象算法，而是能直接落地的配置组合。这意味着，任何有 H20 集群的团队，都可以照着这套思路去优化自己的 DeepSeek-V4-Pro 服务。可复制性，才是工程经验里最贵的部分。
归根结底，LMSYS 这次做的事情并不花哨：承认硬件差距，用场景化配置压缩差距，再用显存管理技巧把最后一点潜力榨出来。但就是这么直白的工程方法论，让 H20 在 DeepSeek-V4-Pro 的推理服务上，第一次有了和 B300 同台竞技的底气。下一次当你抱怨显卡不够好时，或许该先问问自己：有没有把现有硬件的每个字节都用好？
