AREX Feed Article
vLLM 称 8×MI355X 服务 Kimi K3 吞吐较 HGX B300 高 24.4%，建模成本下每美元 token 数多 87.4%
10 月 16 日，vLLM 项目在称，八卡 AMD Instinct MI355X 在服务月之暗面（Moonshot AI）的 Kimi K3 时，于 SemiAnalysis 的 AgentX agentic coding 基准、每用户 50 tokens/s 的 P90 交互目标下，每 GPU 总吞吐约 7,567 tokens/s，高于 NVIDIA HGX B300 的 6,083 tokens/s，差距 24.4%；按 SemiAnalysis 建模的持有成本折算，每美元 token 数多 87.4%。
帖文链接的同日发布，给出了这两个数字的算式、两套系统的完整配置，以及 50 多个已合并的 AMD/ROCm 相关 PR。博客写明：两侧都是 8 卡、8 路张量并行（TP8）、FP4 权重与 FP8 KV 缓存；AMD 侧提交日期为 2026 年 9 月 30 日，NVIDIA 侧为 8 月 16 日，数据于 10 月 9 日从 SemiAnalysis 的 InferenceX 取回。这些 PR 来自 AMD、Embedded LLM 与更广的社区。
图为 vLLM 博客发布的对比图。图中按 30、50、150 tokens/s/user 三档 P90 交互目标分组，条形长度表示相对 NVIDIA HGX B300（1.00×）的倍数；底注写明总 token 包含复用的输入，交互性不含首 token 时间。
每美元优势里，约三分之二来自单价假设
博客的换算公式是：每美元 token 数 = 每 GPU 总吞吐 × 3,600 ÷ 建模的每 GPU 小时成本。成本常数取 MI355X 1.50 美元、HGX B300 2.26 美元，因此 7,567 × 3,600 ÷ 1.50 约得 1,816 万 tokens/美元，6,083 × 3,600 ÷ 2.26 约得 969 万，两者相差 87.4%。
两个倍数相乘：1.244 × 1.507 ≈ 1.874，对应 87.4% 的每美元优势。按对数分摊，吞吐贡献约三分之一，单价假设贡献约三分之二。博客还把同一组数据表述为每 token 建模成本低 46.6%，正好是 1 ÷ 1.874 的结果。
成本常数来自 SemiAnalysis 的「大型超大规模租户」（large-hyperscaler）持有模型；文中注明，部分资本开支与利用率假设未公开。
三个目标里，中间档的领先幅度最大
头图给出三个交互目标，三组结论不同。每用户 30 tokens/s 时，MI355X 的每 GPU 吞吐是 B300 的 1.15 倍，每美元 token 数是 1.73 倍；50 tokens/s 时是 1.24 倍和 1.87 倍；到 150 tokens/s 时，每 GPU 吞吐降到 0.85 倍，即低约 15%，每美元 token 数仍有 1.28 倍。1.507 的单价差仍在起作用，只是被吞吐劣势抵掉大半。
帖文用的词是「有竞争力的表现」（competitive performance）。曲线上，优势只出现在 30 与 50 tokens/s 两个目标；到 150 tokens/s 时，AMD 的每 GPU 吞吐低于 B300，靠建模单价维持每美元领先。页面标题写的是「Matching NVIDIA HGX B300 Throughput per GPU on AgentX」（在 AgentX 上追平 NVIDIA HGX B300 的每 GPU 吞吐），正文给出的却是高 24.4%。
AgentX 回放真实 coding agent 的会话轨迹，请求长度、时序与前缀共享模式都保留，token 本身是合成的；在缓存不受限时，该负载的理论前缀复用率超过 96%，投机解码则使用固定的合成接受率参考曲线。文中还注明，吞吐统计的是包含复用输入的总 token，交互性不含首 token 时间。
纸面算力低约 25%，差距补在软件里
公开规格上，MI355X 的 dense 低精度矩阵峰值是 10.1 PFLOP/s（MXFP4），B300 是 13.5 PFLOP/s（FP4），前者低约 25%；两者都是 288 GB HBM3E、8 TB/s 峰值带宽。博客把结果归因于 AMD 与 Embedded LLM 在 vLLM 上的持续工程投入。
Kimi K3 的结构把瓶颈指向三类数据：24 层 MLA 携带随对话增长的压缩 KV 历史，69 层 KDA 携带固定维度的状态矩阵，MoE 每 token 从 896 个专家中选 16 个。一次返回的 agent 轮次能复用大部分前缀，但处理短续写仍要碰这三类数据。博客列出的优化覆盖 attention、循环层、MoE、量化、图执行与缓存等方向，下面几项都附了各自的测试配置，与头图的 AgentX 结果不是同一批实验：
- MoE 输出投影去重（#51253）。原 ROCm 路径下，8 张卡各算一遍相同的投影，等于同一份计算跑了 8 次；改为按输出坐标分工，再借用已有的 shared-expert all-reduce 汇总。在 8×MI355X、TP8、并发 8～128、随机 8K 输入/1K 输出、关闭前缀缓存的测试中，输出吞吐提升 3.05%～4.91%。
- AttnRes 融合（#50593）。把历史层输出的混合与 RMSNorm 合起来，混合值留在寄存器内，100K 输入/1K 输出、TP8 下输出吞吐提升 14.2%，长 prefill 延迟基本不变。
- MLA 查询补齐（#50578）。每卡 12 个查询头补齐到 16 个，以启用 AMD AITER 的汇编解码路径，32K 输入/1K 输出下每输出 token 从 43.8 毫秒降到 23.6 毫秒；1K/1K 时从 22.9 毫秒到 22.8 毫秒，几乎不变。
- KDA 分块（#54038、#58045）。把有先后依赖的 token 更新合并成组规则，先扫出每组起始状态再并行重放；4K 与 16K 输入下输入吞吐提升 5.3%～5.6%。投机验证改用 4 列而非 32 列 tile，独立工作组（workgroup）从 48 个增至 384 个，单层耗时 16.20 微秒降到 5.61 微秒。
一个 decode step 里 69 次多余的拷贝
能说明「差距补在哪」的是矩阵乘法的分发逻辑。原实现先打包输入、再选 kernel；选中回退路径时，kernel 读的是原始输入，那份拷贝没人用。剖析显示，这样的浪费在每个 decode step 有 69 次，对应 69 个 KDA 层，每次只搬 1,792 字节，却要花约 4.8 微秒。博客的判断是：把这些字节搬得更快几乎没有意义，开销主要在启动上。修复把打包移进真正消费它的专用分支（#58566）。
缓存与显存这一侧有两处改动。TP8 下每张卡都存完整的 MLA 历史，八路 decode 上下文并行（DCP8）改为每卡只存八分之一位置，解码时交换查询、各自对本地历史计算再按 softmax 权重合并部分结果；一段 142,000 token 的对话，估算的 MLA 载荷约 1.96 GB，DCP8 降到约 245 MB。另一处是让 MLA 历史与 KDA 检查点的恢复点对齐（#54736）：若 MLA 已到 3,072 token 而最近的兼容 KDA 检查点在 2,048，请求只能从 2,048 起重算；把 attention 块尾部随检查点一起保存，两者就能落在同一位置。
投机解码的取舍也被算成了预算。按 AgentX 的固定接受率参考，3 个 draft（草稿 token）每轮期望提交 3.00 个 token，4 个是 3.36 个，多 12%；因此第 4 个 draft 只有在整个「起草—验证—提交」周期涨幅低于 12% 时才划算。公开的 AMD recipe（运行配方）用 3～7 个 draft 配 DCP1，在 DCP8 的较高并发设置下直接关掉投机。
头图之后才落地的 28.9%
博客还记录了一处时间差。只加载各 rank 实际用到的那部分权重行的改动（#59591），在 92 个 MoE 层上为每 GPU 省出约 3.85 GiB，落地于头图所用镜像之后。单独在 AgentX 上测，并发 32 和 48 时吞吐提升不到 1%，并发 70 时提升 28.9%，前缀缓存命中率从 74.8% 升到 80.1%。文中也承认，要确认这是缓存压力所致，需要把两种实现放在相同缓存容量下再比。
基准注释写明，公开曲线比较的是完整服务栈，而不只是单卡：AMD 侧用 SimpleCPU offload（CPU 卸载），NVIDIA 侧用 Mooncake offload，两侧 host cache（主机侧缓存）预算分别为每 GPU 224.875 GB 与 281 GB；数值是在各自已发布的序列内、按匹配的交互目标插值得到，插值两端运行的并发、DCP 与 draft 深度可能不同。回放是闭环的，文中提醒可能产生不同的请求完成组合。
复现入口是公开的：AMD 侧 vLLM 提交固定在 36768d1bf，NVIDIA 侧为 5894fdf98，两侧的 recipe 与启动脚本都在文中给出了链接和镜像标签。文中还提到，prefill/decode 分离的工作仍在进行，是下一个可观察的位置。至于每美元 token 那一栏，它取决于这套未完全公开的成本假设：吞吐来自测量，单价来自建模；换一组单价，每美元那一栏的倍数就跟着变。