AMD MI355X 跑 DeepSeek-R1 的成本竟比 NVIDIA B200 还低？这不是营销话术，是真金白银的推理账单。SGLang 团队与 AMD 的工程师们甩出了一组蛮横的数据：在相同的交互延迟下，他们的方案每处理百万 token 只需 0.169 美元，比 B200 搭配闭源 Dynamo 的方案便宜 5%，比 B200 直接跑 SGLang 更是狠砍了 40% 的成本。吞吐量也不含糊，24 块 AMD GPU 每块跑到 2,436 tok/s，硬生生把用 48 块卡跑的 B200 方案每卡吞吐甩出 1.25 倍。这不是魔法，是一场从比特量化到通信管线的全栈硬核优化。
推理账单：0.169 美元撕开 B200 的利润护城河
129 毫秒延迟下的真实 TCO 对决
在 129 tok/s/user 的交互延迟下，用户的体感几乎实时。但账单不会撒谎。SGLang 团队采用了端到端的真实部署环境对线：一边是 24 块 AMD MI355X，另一边是 48 块 NVIDIA B200。两套系统都跑 DeepSeek-R1 这个怪物级模型。结果清晰到扎眼：每处理一百万个 token，AMD 方案的成本是 0.169 美元。NVIDIA B200 用自家的 Dynamo 配合 TRT-LLM，啃下了 0.178 美元的价格——只贵了 5%，还算是体面。但一旦 B200 也切换到开源的 SGLang 框架，TCO 直接飙升到 0.282 美元，差距拉大到 40%。这个数字在云计算世界里，足够让任何采购总监重新翻开报价单。
B200 在 SGLang 上为什么更贵？
一个反直觉的事实：NVIDIA 的卡跑开源的框架，反而更烧钱。根源藏在通信管线里。SGLang 的优化哲学是紧贴硬件底层，AMD 的 MI355X 靠的是 Infinity Fabric 和直接内存访问（SDMA）玩起了两批计算重叠，大幅压低了显卡之间的闲聊时间。B200 的 NVLINK 虽然快，但在 SGLang 未深度定制——或者说，安于闭源 TRT-LLM 的舒适区——时，跨节点通信的包袱反而沉重。更不用说，AMD 团队把部分 CPU 流式处理任务甩给了主机，抢出了更多 GPU 时间。这 40% 的价差，实质上是软件栈的话语权争夺。谁掌控了框架的底层，谁就能在推理成本上捅破天花板。
开源框架对闭源生态的微妙挤压
这件事的弦外之音远比技术指标深远。SGLang 作为一个社区驱动、安身于 LMSYS 的开源框架，正一点点凿开 NVIDIA 闭源推理软件构筑的堡垒。B200 在 TRT-LLM 下还能勉强与 AMD 加 SGLang 打平，但一离了“官方优化”就原形毕露——这说明，对于 DeepSeek-R1 这类挑战性模型，闭源生态的优势正在松动。以推理部署为生的工程师们迟早要算这笔账：硬件的牌面变了，软件的忠诚度是否还该一成不变？MI355X 这组数据，像是一封写给全行业的公开信。
吞吐量的物理课：24 卡如何撕碎 48 卡的体面
每卡 2,436 tok/s 是这么跑出来的
只看成本，是会计的思维；吞吐量才是工程师的荷尔蒙。24 块 MI355X，每块 GPU 推出 2,436 tok/s 的推理速度，这是个什么概念？同一套 SGLang 框架下，用 48 块 B200 集群跑，平均每卡只有大约 1,948 tok/s。AMD 用一半的卡数、一半的总互联资源，反而在单卡效率上高出了 25%。秘密藏在数据流动的规划里：SGLang 为 MI355X 重写了 MoRI 混合量化的全到全通信策略，把原本需要巨大带宽的 FP8 张量拆解成 FP4 和 FP8 的混合体，像分拣邮件一样精算每一跳的负载。显卡不再白白等待邻居的同步信号，计算单元的利用率瞬间拉满。
全到全通信：24 卡集群的秘密
推理大模型，瓶颈往往不在计算，而在卡与卡之间的闲聊。DeepSeek-R1 是个庞大的多专家模型，每次推理都要调度多个专家层，这就意味着 GPU 之间必须频繁进行全到全通信——全体卡同时向全体其他卡发送激活值。SGLang 团队的解法颇为刁钻：他们利用 AMD 的 SDMA 引擎，在 GPU 还忙着矩阵乘法时，就让数据提前上路。所谓两批重叠，就是让当前 batch 的计算与上一 batch 的通信并行，像一条不间歇的流水线。加之对 ROCm 平台的精细调优，MI355X 的 24 卡集群几乎没有空转，而这正是 B200 阵容——即使坐拥 48 张卡——没能做到的。
SDMA 与两批重叠的魔法
SDMA（系统直接内存访问）是个老面孔，但在 SGLang 的调校下被玩出了新花样。常规的推理管线里，GPU 往内存读写 KVCache 时，经常把计算核心晾在一边。MI355X 的策略很直接：让 SDMA 控制器独立搬运缓存数据，GPU 核心则专注在下一个 token 的生成上。两批重叠进一步把这种并行推向极致——当前批次还在飞，下一批的输入已经预热完毕。效果立竿见影：MI355X 的每令牌延迟抖动低了，谷值吞吐消失了。反观 B200，并非硬件不行，而是软件层太厚，SGLang 来不及削尖它。这组数据摊开了一件事：在推理这场贴身肉搏中，半导体制程的优势，轻易就能被软硬协同的巧劲抵消掉。
五把手术刀：切开推理系统每一寸神经
MoRI 量化：FP4 和 FP8 的乾坤大挪移
大部分量化方案在精度和速度间痛苦地二选一。SGLang 为 MI355X 弄的 MoRI 混合量化，把选择题变成了复合题。对于 DeepSeek-R1 里对数值误差敏感的注意力层和路由层，留用 FP8 保底；剩下那些占大头的、容错率高的前馈网络层，一刀切到 FP4。结果就是模型运行时的内存足迹和带宽压力骤降一半，精度却没打折扣。这还仅仅是静的部分。在动的层面，FP4 张量小到能塞进 MI355X 的 L2 缓存里翻滚，访问显存的次数腰斩，能耗和延迟双双暴跌。没有这种量化，24 块卡的吞吐巨兽根本推不动。
KVCache 后端：MoRI-IO 的数据高速公路
KVCache 是长上下文推理的头号内存老虎。SGLang 引入的 MoRI-IO KV Cache 后端，相当于专门为 MI355X 修建了一条数据高速公路。传统的缓存管理，GPU 要频繁跟主机 CPU 伸手要数据，链路长、刹车多。MoRI-IO 重写了调度逻辑，把频繁访问的热缓存钉在 GPU 的高带宽内存里，冷数据则智能地溢写到更廉价的系统内存或 SSD 上。配合前面说的 SDMA，GPU 取缓存就像从自己口袋掏钥匙，而不是下楼开后备箱。对于 DeepSeek-R1 这种一口气能啃十几万 token 的模型，这手缓存手术直接决定了 TCO 的生死。
Specv2 MTP 和 CPU 流式：最后的加速器
其余两把刀，虽然切口小，但一样割得深。ROCm 上的 Specv2 MTP（推测式解码第二版）让 MI355X 能一次预测多个后续 token，靠投机来蒸发延迟。与传统的逐个令牌生成不同，推测解码让 GPU 在大部分时间里都处于饱和工作状态，这对单卡 2,436 tok/s 的达成居功至伟。而 CPU 流式处理优化，则是把输入 tokenization、去 tokenization 等预处理后处理任务，完全卸载到主机的多核 CPU 上去，GPU 只碰核心推理。这一招看似简单，却砍掉了 5% 以上的尾延迟。多管齐下，MI355X 这台推理机器就这样从芯片微架构一路优化到了 Python 代码的边界，把 DeepSeek-R1 的成本打到了一个新水位。
