AMD MI355X 正面挑战 NVIDIA HGX B300：Kimi K3 上每 GPU 24.4% 的 token/s 领先是怎么测出来的

AMD MI355X 正面挑战 NVIDIA HGX B300：Kimi K3 上每 GPU 24.4% 的 token/s 领先是怎么测出来的

开场：一个被广泛转发的数字，和它的脚注

2026 年 10 月中旬，vLLM 官方博客站点上出现了一篇围绕 Kimi K3 推理优化的技术文章，其中给出了一个被大量转发的对比结论：一套由 8 块 AMD Instinct MI355X 组成、运行 vLLM 的系统，在服务 Kimi K3 时，每 GPU 总 token 吞吐比 NVIDIA HGX B300 高出 24.4% [1]。这个数字很有传播力，因为它把「AMD 正面挑战 NVIDIA」的叙事压缩成了一个百分比。

但同一段文字里还跟着三个几乎不会被转发的脚注：其一，交互性指标采用的是 P90 response inter-token latency（响应阶段 token 间隔延迟的 90 分位），且不含 TTFT（time to first token，首 token 时间）；其二，统计的总 token 同时包含被复用的输入 token（reused input tokens）与生成的输出 token；其三，数据来源标注为 SemiAnalysis InferenceX 2026 年 10 月 9 日的一份快照 [1]。

数据速览

本文不试图判定 AMD 或 NVIDIA 谁「更强」——现有材料不足以支撑这种结论，因为双方的官方规格、价格、测试配置并未完整给出。本文要做的事情更实用：把这组数据的测量口径、归一化方式和成本换算链完整拆开，让你拿到下一份厂商 benchmark 时，能够自己判断它可比、不可比，以及结论在什么条件下成立。

第一部分：基准口径拆解——三个定义决定 24.4% 的成色

inter-token latency 与 P90：测的是流式体验的尾部

流式生成场景下，用户感知到的「流畅度」并不取决于平均出字速度，而取决于相邻两个 token 之间是否出现明显卡顿。inter-token latency（ITL）统计的正是生成阶段相邻 token 的时间间隔。如果把一次响应的时间轴画出来，它大致分为两段：从请求发出到第一个 token 返回的等待段，以及此后逐 token 产出的生成段。

P90 的选择意味深长。假设 1000 个 token 间隔中有 900 个都在 20 ms 以内、100 个卡到了 200 ms，均值可能仍然好看，P50 完全不受影响，但 P90 会立刻暴露这些长尾停顿。对聊天和 Agent 流式输出而言，长尾卡顿正是「这台机器是不是在转圈」的直接体感。因此 P90 相比均值更严格，它惩罚的是尾部延迟而非平均能力。这里还有个细节：原文写的是 response inter-token latency，即在一次响应的生成阶段内部统计 token 间隔，而不是跨请求统计 [1]。

值得注意的是，用 P90 ITL 作为约束、用 token 吞吐作为被比较量，本质上是在问：「在给定交互流畅度目标下，谁的单位硬件产出更高？」这是一种延迟约束下的吞吐比较（throughput under latency constraint），与无约束峰值吞吐是两种完全不同的命题。

为什么剔除 TTFT：把 prefill 与 decode 分开测

TTFT 度量从请求到达至第一个 token 输出的等待时间，它包含排队、调度、以及 prefill 阶段（对全部输入 token 做一次前向计算以生成 KV cache）的耗时。剔除 TTFT，意味着这次对比聚焦在 decode 阶段的持续生成吞吐，而不评价首 token 响应速度。

这个选择在工程上是合理的：prefill 与 decode 的瓶颈不同，前者更依赖算力与并行效率，后者更依赖显存带宽、KV cache 容量与批处理调度。把两者混在一个指标里，反而难以归因。但它同时带来一个容易被忽略的后果：对于强交互场景，TTFT 是用户体验的重要组成部分，剔除它不代表它不重要，只代表「本次对比不测它」。如果某个系统在 decode 上更快、但在 prefill 或排队调度上更慢，那么这组数据不会告诉你这件事。

为什么计入 reused input tokens：分母被什么撑大

总 token 统计包含被复用的输入 token [1]。所谓复用输入，通常指命中前缀缓存（prefix cache）的那部分输入 token：当多个请求共享相同的系统提示、工具定义或历史上下文时，引擎可以跳过对这部分的重复计算，直接复用已有 KV cache。这些 token 在某些统计口径下会被计入「处理的总 token」，从而抬高 token/s 这个比值的分子。

这里必须追问一句：两侧的前缀缓存命中率是否一致？如果工作负载中包含大量共享系统提示、多轮对话上下文或相同的工具描述，缓存命中率的差异完全可能显著改变结果。一个直观的敏感性推演：假设纯生成部分的吞吐不变，输入 token 中有相当比例被复用并计入统计，那么「总 token/s」就会比「仅生成 token/s」高出一截。由于原文未披露两侧的缓存命中率与输入/输出长度分布，本文无法量化这一项的具体影响，只能指出它是结论敏感度最高的口径之一。

口径敏感性：同一场测试换个统计方式，结论可能变向

下面给出一段与具体框架无关的 ITL 统计示意代码，仅用于展示「时间戳 → 差分 → 分位数」的逻辑，不代表任何框架的真实 API：

# 示意代码：仅演示统计逻辑，非任何推理框架的真实 API
def inter_token_latency_pct(token_timestamps, percentile=90):
# token_timestamps: 一次响应中按序到达的生成 token 时间戳
deltas = [t2 – t1 for t1, t2 in zip(token_timestamps, token_timestamps[1:])]
deltas.sort()
# 简化的分位数计算，工程实现通常还需处理插值与离散化
idx = int(len(deltas) * percentile / 100)
return deltas[min(idx, len(deltas) – 1)]

# TTFT 不在上述区间内，它需要用首 token 时间戳减去请求到达时间单独统计

第二部分：读懂数字——「每 GPU」归一化与负载条件

从整机到每 GPU：归一化消除了什么、掩盖了什么

24.4% 的比较单位是每 GPU 总 token/s [1]。归一化到单卡，是为了让卡数不同或整机形态不同的系统具备可比性——如果一方是 8 卡节点、另一方是另一种拓扑，直接比较整机吞吐没有意义。

但归一化也会掩盖若干重要事实：单卡显存容量差异会影响 KV cache 可容纳的并发序列数；互联带宽与拓扑影响张量并行的通信开销；单卡功耗与价格差异直接影响真实成本；甚至卡的可用显存与机型整机内存配比也会改变最优并行切分方式。换言之，「每 GPU」是一个不错的中间量，但它不是最终决策量——最终决策量是「每一块钱、每一瓦、每一份配额能交付多少符合 SLA 的有效 token」。

由于现有材料中没有 MI355X 与 B300 的官方规格对比数据（HBM 容量与带宽、互联、功耗、单价），本文不做规格层面的归因分析。任何「因为 MI355X 显存更大所以赢了」的说法，在拿到规格表之前都属于未经证实的推断。

吞吐是在什么约束下测出来的

原始描述中出现了「50 tokens/s 附近」这样的延迟条件表述，但摘录文本在此处被截断 [1]。可以确定的是：这组数据是在某个 inter-token latency 约束点附近取得的，而非无约束的最大吞吐。这类数据点的正确读法是：「在 X 的流畅度目标下，每 GPU 产出多少 token」，而不是「这块卡最快能跑多少」。

对选型而言，前者才有意义。生产系统几乎总是带着 SLA 上线：流式输出要求 token 间隔稳定在某个阈值内、端到端延迟要求在某个分位以内。脱离 SLA 谈吞吐，就像脱离路况谈最高车速。

复现这份对比还缺什么

这份清单本身就是工具：当一份 benchmark 缺少其中一半以上的条目时，它的结论只能当作「方向性信号」，不能当作采购依据。

第三部分：成本视角——从 token/s 到单位算力成本的换算链

选型的真实公式

推理选型最终要落到单位 token 成本。最简化的换算关系是：

# 通用算式：单位 token 成本（美元/百万 token）
# hourly_price: 每 GPU 每小时的租赁或摊销成本（美元）
# tokens_per_sec_per_gpu: 每 GPU 吞吐（token/s）
# utilization: 实际利用率（0~1），即非闲置的有效运行时间占比
def cost_per_million_tokens(hourly_price, tokens_per_sec_per_gpu, utilization=1.0):
tokens_per_hour = tokens_per_sec_per_gpu * 3600 * utilization
return hourly_price / tokens_per_hour * 1e6

在这个公式里，24.4% 的吞吐领先意味着什么？做一个纯算术推演（注意：这是算术，不是实测结论）：若两侧每 GPU 小时价格相同、利用率相同，单位 token 成本之比为 1/1.244 ≈ 0.804，即单位 token 成本约低 19.6%。反过来说，吞吐提升 24.4% 并不等于成本下降 24.4%——这是分母效应，很多人会算错。

但如果两侧的租赁价格不同，结论就要重新计算。MI355X 与 B300 的实际云租用价格或采购摊销成本，在本文掌握的材料中没有可靠数据，因此这里不做具体金额换算。任何看到「$/M tokens」的具体数字，都应当先问：价格从哪来、利用率假设多少、是否把闲置时间计进去、是否包含网络与存储开销。

单一峰值算力为什么失灵

峰值 FLOPS 长期以来是硬件选型的默认语言，但在大模型推理场景中，它与实际产出的相关性相当弱。decode 阶段通常是访存瓶颈：显存带宽决定 token 生成节奏，KV cache 容量决定能同时维持多少条序列，批处理效率决定单位时间的有效 token 数，前缀缓存命中率决定输入侧重复计算的浪费程度。这些因素没有一个能被峰值算力完整刻画。

此外还有三类常被忽略的成本：

把假设显式化

任何成本结论都应附带一张假设表：价格来源与时点、利用率口径、SLA 约束（延迟分位数）、token 统计口径、是否含缓存复用。缺一项，结论就多一分不可复现性。这也是为什么本文反复强调口径脚注——它是成本换算链条的第一环，第一环松了，后面全部失效。

第四部分：DeepInfer 案例——框架与硬件的绑定博弈

事实层：一个「开源但锁定硬件」的推理引擎

围绕推理栈的另一个信号来自 DeepInfer。根据一份公开的研究文档整理，DeepInfer 是 DeepSeek 生产推理框架的开源发布，时间约在 2026 年 10 月 16 日至 20 日之间，采用 Apache-2.0 许可证，服务于 DeepSeek-V4.1-Flash 的线上推理负载；该引擎具有 vLLM 派生血统，同时吸收了 SGLang 与 TensorRT-LLM 的影响；其目标硬件被锁定为两套栈：NVIDIA SM100 与华为昇腾 950 [2]。同一时间段的行业日报也记录了「DeepSeek 开源 DeepInfer」这一事件 [4]。

需要明确的是：上述信息来自一份第三方研究文档的整理 [2]，而非本文直接核对的官方仓库或论文。文档中提到的发布日期存在 10-16 与 10-20 两种说法，许可证文件、硬件支持范围与血统表述均应回到官方仓库和文档逐条核实。本文因此将这些内容标注为「据报道/待核验」，不作为已确认事实使用。

宣称数据的正确引用姿势

该研究文档还转述了一组官方宣称数据：单集群每天处理 155T tokens，以及 $38/GPU-hour 的谷时价格营收口径 [2]。引用这两个数字时必须做三件事：

• 标注为「官方宣称」或「研究报告转述」，而非独立实测；
• 说明 $38/GPU-hour 的口径是营收侧的谷时价格表述 [2]，它不是成本，不能直接用于计算单位 token 成本，更不能与云租用价格混用；
• 155T tokens/天是集群级吞吐，与本文讨论的每 GPU token/s 不是同一层级的指标，不能直接互推。

这三点是技术写作的基本纪律：数字可以引用，但必须带着它的口径一起搬家。

解读：为什么头部玩家「开源引擎但锁硬件」

这一现象背后是工程上的现实张力。异构硬件各自需要深度内核优化：不同的指令集、不同的张量核心单元、不同的内存层级与互联协议，意味着矩阵乘、注意力、量化反量化、通信原语这些关键路径几乎无法用一套通用实现榨干所有硬件。通用引擎追求可移植性，极致性能追求硬件特化，二者天然冲突。

对选型者的含义是：引擎开源不等于硬件可替换。许可证上的自由度，与内核层的可迁移性是两回事。当你选择一套为特定硬件深度优化的推理引擎时，你同时购买了它的性能红利和它的绑定成本；迁移时需要重写或替换的往往是内核与编译栈，而不是上层 API。

第五部分：AWS Batch × SageMaker 配额管理——供给侧的镜像故事

事实层：配额开始成为一等资源

2026 年 10 月 30 日的行业日报记录：AWS ML 团队宣布为 SageMaker 训练任务推出 AWS Batch 配额管理调度新特性，支持跨团队 GPU 算力的借贷与抢占 [3]。这一条属于训练侧的调度与治理能力，其官方公告原文、GA 或 Preview 状态、支持区域与实例类型边界，均需回 AWS 官方文档核实——日报类信息是二手转述，不应替代产品文档。

解读：当硬件异构且紧缺，「配额」进入基础设施层

借贷与抢占这两个词，透露出一个管理学转向：GPU 算力不再只是「买多少卡」的问题，而是「如何在组织内部配置稀缺资源」的问题。当算力可以被借出、被抢占、被按优先级调度，团队级的成本核算与优先级策略就必须下沉到基础设施层，由调度器而非会议纪要来执行。

对推理侧的类比是直接的：推理集群同样面对多模型共享 GPU、SLA 分级、峰谷调度与容量超卖。一个集群里可能同时跑着延迟敏感的交互式服务和吞吐敏感的批处理任务，如何在它们之间分配显存与算力，如何在高峰期抢占低优先级负载，如何向业务方结算——这些正是训练配额管理正在解决的问题在推理侧的镜像。

边界说明必须写清楚：这是训练侧的调度特性 [3]，不能直接外推为推理侧已有同样能力。它与推理的关系是「叙事层面的互相印证」，而不是「功能层面的等价」。

第六部分：选型清单——用五个问题审任何一份推理 benchmark

一、延迟口径是什么？ 是 ITL/TPOT 还是端到端延迟？取的是均值、P50、P90 还是 P99？含不含 TTFT？不同答案对应完全不同的用户体验承诺。本次对比用的是 P90 response inter-token latency 且不含 TTFT [1]。

二、token 统计含不含复用输入？ 两侧的前缀缓存命中率是否对等？输入/输出长度分布是否披露？「总 token/s」和「生成 token/s」相差可能很大，而缓存命中率是最大的变量。

三、归一化单位是什么？ 每 GPU、每美元、每瓦特还是每机架？比较机型的配置、卡数、互联拓扑与价格是否披露？本次为每 GPU 口径 [1]，价格与功耗未纳入。

四、负载条件是否可复现？ 并发数、长度分布、精度、引擎版本、调度参数、测试时长、预热方式与采样次数是否给出？如果这些全部缺失，数据只能作为方向性信号。

五、数据是谁测的、什么时点的快照？ 厂商自测、第三方抽样还是公开 leaderboard？是否注明快照日期？本次数据标注为 SemiAnalysis InferenceX 2026 年 10 月 9 日快照 [1]，属于引用第三方数据。另外要留意数据源本身的可信度信号：如果一份资料连采集热度、发布时间都缺失，那么它的时效性判断就必须依赖正文内的日期线索，而非榜单表现。

本文数据状态汇总

结语：从峰值算力到「可用的 token」

推理选型的决策量正在发生变化。过去我们问「这块卡的峰值算力是多少 TFLOPS」，现在更应该问「在 50 tokens/s 这样的延迟约束下、在给定价格与利用率假设下，这一块钱每年能交付多少符合 SLA 的有效 token」。前者是纸面规格，后者是账本。

24.4% 这个数字的真正价值，不在于证明 AMD 赢了或 NVIDIA 输了——现有材料远不足以支撑这种结论。它的价值在于：它把 P90、TTFT、reused input tokens 这些埋在脚注里的口径，推到了台前。当厂商开始公开口径，行业就多了一次校准测量语言的机会；当读者开始追问口径，采购决策就从「比大小」变成「比可复现的产出」。

最后仍要提醒：异构不是免费午餐。AMD、NVIDIA、华为昇腾之间的选择，除了吞吐与价格，还要把引擎适配、内核迁移、团队技能栈、配额调度与生态依赖全部入账。DeepInfer 这类「开源引擎 + 锁定硬件」的案例已经说明，许可证上的自由与工程上的可迁移性是两笔账 [2]；AWS 在训练侧推进配额借贷与抢占则说明，算力的稀缺性最终会以治理问题的形式回到基础设施层 [3]。把这三件事放在一起看，推理基础设施的主叙事已经很清楚：不再是单一峰值算力的竞赛，而是异构硬件条件下，单位算力成本与有效 token 交付能力的持续核算。

参考资料

[1] vllm-project.github.io/_posts/2026-10-16-kimi-k3-mi355x.md at main · vllm-project/vllm-project.github.io，GitHub，https://github.com/vllm-project/vllm-project.github.io/blob/main/_posts/2026-10-16-kimi-k3-mi355x.md

[2] deepinfer-research/research_DeepInfer_20261022.md at main · Jackxiaozhiren/deepinfer-research，GitHub，https://github.com/Jackxiaozhiren/deepinfer-research/blob/main/research_DeepInfer_20261022.md

[3] AI 日报（2026年10月30日）今日主题：Mistral 开源万亿参数模型权重、OpenAI 撤回额度缩减并扩大失准，掘金，https://juejin.cn/post/7702057477323653158

[4] AI 资讯日报 | 2026年10月21日：中办国办部署“人工智能+”行动、英伟达 GTC 柏林发 Nemotron 3.5、DeepSeek 开源 DeepInfer、阿里发布 Qwen3.6，CSDN，https://blog.csdn.net/IT_ORACLE/article/details/168726117