BloomBloom
发起研究

Ironwood vs B200/B300：每 token 成本是一场带 SLO 的系统结果

为什么 "每百万 token 多少钱" 不能脱离 TCO 与吞吐来讲

2026 年 9 月，SemiAnalysis 在 InferenceX 平台上发布了一组对比数字：Google Ironwood（TPU v7）在 Qwen3.5-397B、FP8、8k1k（8K 上下文输入、1K 输出）聚合服务工作负载下，每百万 token 成本 0.181 美元；NVIDIA B200 同等工作点上 0.222 美元；B300 则是 0.276 美元InferX. 这条 headline 看上去像一次 "TPU 全面胜利"，但数字翻一下就知道它只在某个特定工作点成立。把同一篇文章里的另一组数字拿出来看：在 20 tok/s/user 这样的低交互量端，Ironwood 的单芯片吞吐领先 B200 大约 5%（9,364 对 8,903 tok/s/chip），但因为 TPU 的小时成本更低，乘出来的 $/token 优势被放大到 50.4%；把 TCO 口径从外部 1.21 美元换成 SemiAnalysis 估算的内部 1.03 美元/chip-hour（Google 公开 on-demand 价为 12 美元），同时把工作点从 20 tok/s/user 挪到并发 256，perf/$ 优势可以进一步放大到 76.7%，甚至 130.2%——但这是「切 TCO + 挪工作点」两个变量同时切换的复合结果，对应的代价是 mean TTFT 5.41 s（TPU）vs 3.75 s（B200）vs 2.40 s（B300），TPU 反而是三者里 TTFT 最慢的那个。单个变量单独切换并不能直接复现这两个百分比。

这就是第一张图想回答的问题：$/token 不是一个芯片的固有属性，它是一个比值。

图注：Ironwood 与前代 TPU 的逐代硬件对比。Ironwood 的 192 GiB HBM3E、7.37 TB/s HBM 带宽、4,614 FP8 TFLOPs/chip、1.2 TB/s 双向 ICI、9,216 芯片组成的 superpod 等数字直接来自这张表的脚注与正文。v4 / v5p 的 FP8 标称值是 emulated（Google 自己加的脚注），Ironwood 才是第一代在硬件上原生支持 FP8 的 TPU。这张表还隐含另一条：Ironwood 在 BF16 与 FP8 之间有 2 倍算力差，但表格只列到这两档，FP4 路径未在该代硅片文档中出现Ironwood.

把 $0.181 这条 headline 拆开：分母是 "每个 chip 每秒产出的合格 token 数"，分子是 "每个 chip 每小时花的钱"。SemiAnalysis 在 external TCO 口径下给的每小时成本是 TPU 1.21 美元、B200 1.73 美元、B300 2.26 美元，对应的 raw throughput（20 tok/s/user 工作点）是 9,364 / 8,903 / 8,925 tok/s/chip。于是：

$$$/M\ token = \frac{TCO_{chip\text{-}hour}}{goodput_{tok/s/chip} \times 3600} \times 10^6$$

把 TPU 一侧的 1.21 美元/chip-hour 除以 9,364 tok/s/chip，再除以 3600 秒/小时，最后乘以 10^6 缩到百万 token 单位，得到 0.0359 美元（验证：1.21 ÷ 9364 ÷ 3600 × 10^6 ≈ 0.0359）；但这是在 20 tok/s/user 处的算式，不是在 100 tok/s/user 的 headline 工作点（100 tok/s/user 的 goodput 并不直接可拆，headline 是把 interactivity 与 cost 在 Pareto 曲线上读出来的，所以不要做这种手算反推）。重要的是同一个公式：换 1.03 美元的内部 TCO，Ironwood 的 $/token 直接同比例下降；把工作点挪到并发 256 处的 TTFT（5.41 s vs 3.75 s vs 2.40 s）作 SLO 约束，符合 SLO 的合格 token 数降低，$/token 上升，TPU 反而变成三者里 TTFT 最慢的那个。这就是 "口径一变，排名翻一次" 的具体含义。

硬件底线两侧各摆一组。TPU 一侧，Ironwood 单芯片 192 GiB HBM3E、7.37 TB/s 带宽、4,614 FP8 / 2,307 BF16 TFLOPs，每芯片 1.2 TB/s 双向 ICI 互连，9,216 芯片通过 OCS（光路交换）拼接成 superpod，pod 级聚合 ICI 带宽达 88,473.6 TbpsIronwood. B200/B300 一侧，HGX B200 单卡 192 GB HBM3e、1.8 TB/s NVLink、NVFP4 Tensor Core 144 sparse / 72 dense PFLOPS；GB200 NVL72 在 72 GPU 单一 NVLink 域内提供 130 TB/s 聚合带宽与 13.4 TB HBM3e；GB300 把单卡 HBM 拉到 288 GB，NVFP4 dense 算力到 1,080 PFLOPSHGX. 这里已经可以看出几个不对称：单芯片 HBM 容量上 TPU 与 B200 在此档相同（都是 192 GiB / GB 一档），真正的差异在两端——一边是可扩展域规模（TPU 9,216 颗 superpod 通过 OCS+ICI 拼接 vs NVL72 72 颗单 NVLink 域，量级差 128×），另一边是 B300 把单卡 HBM 拉到 288 GB 的更高一档；NVIDIA 单卡有原生 FP4、TPU 这一代没有。把这两组数字放进 $/token 的分母里，读者立刻能看出 $0.181 的 headline 不是一个 "TPU 硬件便宜" 的故事，而是 "TPU 在 FP8 这条路径上硬件便宜 + 8k1k 工作负载刚好不吃 FP4 的亏" 的特定组合。

到了这里，$/token 的两个分量都摊在了桌面上：TCO 是分子（不同时刻、不同合同、不同区域都不一样），goodput 是分母（满足 TTFT 与 TPOT 的 SLO 约束时真正能交付的 token 速率）。下一章要做的事，就是把 "满足 SLO" 这个限定语从一个口号变成一个可计算的指标。

什么叫 "满足 SLO 的合格 token"：把比较单位从 TPS 换成 goodput

"每秒产出多少 token" 是一种直觉，但它不是工程决策单位。DistServe 在 OSDI 2024 上给出的定义是：per-GPU goodput = 在 TTFT 与 TPOT 同时满足 SLO、且 SLO attainment ≥ 90% 的前提下，每个 GPU 能够服务的最大请求速率DistServe. 这个定义的精妙之处在于：它把 "我不卡 SLO 跑出来多少 token" 和 "我在 SLO 内跑出来多少 token" 区分开。后者才是厂商真正能卖给用户的能力，前者只是峰值跑分。

为什么必须这样区分？两个阶段的算力特征根因不同。Prefill 是 compute-bound：13B 模型在单张 A100 上处理一条 512-token prompt 就足以饱和 GPU 算力，再往上 batch 只会按比例延长所有请求的处理时间。Decode 是 memory-bandwidth-bound：单条 decode job 的算力利用率极低，必须靠 batch 把带宽吃满DistServe. 两条曲线在 throughput vs batch size 上形态完全不同。如果让它们共享同一张 GPU，TTFT 与 TPOT 必然互相挤占：prefill 来了 decode 必须等，decode batch 起来 prefill 又被推后。结果是系统要么过度配置（双倍 GPU 满足同一并发），要么牺牲一边（TTFT 超 SLO 或 TPOT 超 SLO）。

图注：单 A100 跑 13B 模型 + 512 token prompt + 64 token output 的动机实验。上半 P90 TTFT：colocation 模式下 rps 一上来 TTFT 就突破 SLO（绿线），单独跑 prefill 把满足 SLO 的 rps 上限显著推高（橙线）。下半 P90 TPOT 形态对称：colocation 在低 rps 就被 decode 抢占拖高，单独跑 decode 把 SLO 上限推到 ~10 rps。这张图给 "为什么 prefill 与 decode 必须分池" 一个直观的视觉证据DistServe.

把这条根因落到工程上，DistServe 给出的两阶段 placement 是：先分别优化 prefill 实例与 decode 实例的并行配置到 phase-level optimal per-GPU goodput，再用 replication 凑齐目标流量。在低带宽跨节点网络（如论文测试床的 25 Gbps 跨节点链路）下，instance 还要切成 inter-op segment，强制 prefill/decode 同阶段的 segment 共置同一节点，使 KV cache 传输只走 NVLink。论文在 4 节点 32 张 A100 上测出 "up to 7.4× more requests or 12.6× tighter SLO while meeting latency for over 90% requests" 这条 headlineDistServe.

但分池只是第一步。同一个 A100 上即使做了分池，长 prompt 仍会以一次完整 prefill 的形式 stall 所有 decode。Sarathi-Serve（OSDI 2024）给出了一个看上去朴素、实际极其有效的修补：把长 prefill 切成接近等长的小 chunk，按固定 token budget 嵌入 decode 批次，从而既不打断 decode、又保留了 prefill 的吞吐SigA. 调度顺序是：先把所有正在跑的 decode 塞进下一批，再容纳任何部分完成的 prefill，最后才接收新 prefill 请求，且新 prefill 总量被 token budget 上限压制（这个上限由 TBT SLO 反推）。这就是 "stall-free batching" 的含义：ongoing decode 从不被 piggyback 的 prefill chunk 暂停，批次保持算力均质，pipeline bubble 被压下去。

图注：vLLM / Orca / Sarathi-Serve 三种调度在同一组到达请求下的对比。vLLM 与 Orca 面板里长 'p' 条拖住 decode；Sarathi-Serve 面板里短 chunked 'p0'、'p1' 与 decode 条交错，没有长 stall。这张图说明的是通用机制：chunked prefill 把 prefill 队列摊薄到 bounded chunks，不会让任何一条长 prompt 一次性打断 decode；它说明了 Ironwood 这类并发结果中必须核查的调度变量。仅凭该数字不能断言基准采用了 Sarathi-Serve 式分块SigA.

到了这一步，"goodput" 这件事的工程链路就清楚了：从单 GPU 的 chunked prefill + stall-free batching（不 stall decode），到跨机器的 prefill/decode 分池（不同算力特征各占各的池子），到 KV cache 作为一类独立资源被 Conductor 用 SLO 满足度而非队列长度调度。Mooncake 把这条链继续往下推了一层：Conductor 的负载信号不是 "队列长度 / 最大容量"，而是 "predicted TTFT/TBT 对 SLO 阈值 l_ttft / l_tbt 的比值"，并且基于这个比值做早期拒绝；为了避免朴素的早期拒绝造成 prefill/decode 池间的 anti-phase 抖动，Mooncake 又在工程上加上了一个预测层（基于系统级均匀 decode 时间，不是 request 级输出长度预测），把过度拒绝从 4,183 降到 3,589Mooncake. 在 8 张 A800 的测试床上，用 dummy LLaMA2-70B replay Kimi 真实 trace，Mooncake 比 vLLM 多处理大约 75% 的请求（在 TBT SLO 上 vLLM 只满足 57%、Mooncake 满足 ~100%）Mooncake. 这组数字再次印证一件事：把分母从 TPS 换成 "满足 SLO 的 goodput"，差距会被压缩、放大或翻转。

理解了 goodput 这个比较单位之后，下一章就可以把第一章的 TCO 分子、这一章的 goodput 分母代进 Qwen3.5-397B FP8 8k1k 的实测数字里，看那 0.181 美元到底在哪些条件下成立、又在哪些条件下被翻盘。

Qwen3.5-397B FP8 8k1k 上的条件性胜负：把公式代入实测数字

InferenceX 的 headline 数字带一组明确的限定语：Qwen3.5 397B、FP8、8K 输入 / 1K 输出、聚合服务（agg，非 disagg）、单 token 预测、No MTP（无多 token 推测解码）。这套口径同时也是 "为什么 $0.181 不能直接外推到自家环境" 的原因：模型换了，量化换了，输入长度换了，服务模式换了，MTP 开关换了，$/token 就会变。

图注：深色背景折线图，横轴 interactivity 0–180 tok/s/user，纵轴 Cost/M tokens。三条曲线：TPUv7（vLLM，蓝）、B200（SGLang，绿）、B300（SGLang，浅绿）。副标题直接写明口径：Qwen3.5 397B、FP8、8K/1K、No MTP。曲线顶端的 hourly hardware cost 标注 $1.21 / $1.73 / $2.26，对应 TPU/B200/B300。$0.181 / $0.222 / $0.276 这条 headline 是 100 tok/s/user 工作点上的读数，不是单点报价InferX.

把 interactivity 与 cost 这条曲线展开看，三家在低交互量端接近，TPU 因为 hourly cost 最低始终在下方，B300 因为 hourly cost 最高且曲线斜率最陡而拉开最大差距。100 tok/s/user 处 Ironwood 比 B200 便宜约 19%、比 B300 便宜约 34%；在 20 tok/s/user 这种 raw throughput 主导的工作点上，TPU 的 5% 单芯片领先配低 hourly cost 给出的 $/token 优势是 50.4%（vs B200）和 96.0%（vs B300）。在 20 s 中位响应时间的工作点上看，Ironwood ~$0.098/M、B200 ~$0.106/M、B300 ~$0.132/M，TPU 比 B200 便宜约 8%、比 B300 便宜约 25%InferX.

然而这条 headline 排名的另一个角落，SemiAnalysis 也摆了出来：换到内部 TCO 口径（1.03 美元/chip-hour）下的并发 256 工作点，TPU 的 perf/$ 优势涨到 +76.7% / +130.2%，但代价是 mean TTFT 5.41 s，B200 是 3.75 s，B300 是 2.40 s——TPU 在 TTFT 这一项上反而是三者里最慢的InferX. 这是 "goodput 与 TTFT 的取舍" 的具体表达：在这组不同口径的测量中，较高 perf/$ 与较慢 TTFT 同时出现；它提示存在取舍，但不能由这些单点归因到资源如何分配。所以 "19% / 34% 优势" 在哪一段成立，要看具体是哪一段 SLO 在被满足。

更值得注意的是另一条曲线：把服务模式从 Ironwood 聚合换成 GB300 NVL72 disagg、用内部 TCO 重画 cost vs e2e latency，TPU 与 NVIDIA 之间的曲线交叉。

图注：白底折线图，横轴 E2E latency 0–60 s，纵轴 Cost/M tokens 对数刻度。两条曲线：GB300 NVL72（Dynamo SGLang，disagg，绿）与 TPUv7（vLLM，agg，蓝）。约 14 s 处两曲线交叉，中段 GB300 NVL72 disagg 取得 ~30% perf/$ 优势；高 e2e 延迟与低 e2e 延迟两端 TPU 仍竞争InferX. 这张图说明 Ironwood 在低/高 e2e 延迟两端仍有竞争力，中段（medium-latency regime）则是 NVIDIA 一侧 disagg 栈的优势区间。SemiAnalysis 自己也指出，一旦 TPU disagg（TPU-Sync + llm-d）正式落地，这个差距有望被压回InferX.

把这组条件性胜负落到 5 s 短回答里：100 tok/s/user 时 Ironwood 比 B200 便宜 19%、比 B300 便宜 34%；并发 256 时 TPU perf/$ 优势最大（最高 +130.2%），但 TTFT 慢 1.4×–2.3×；~14 s e2e latency 交叉处 GB300 NVL72 disagg 拿走 ~30% perf/$ 优势；20 s 中位响应时间三方对比下，B200 在 ~30 s 处短暂反超、TPU 在更长延迟下重新领先InferX.

那么 5% 的单芯片吞吐领先，是怎么在 $/token 上被放大成 19%–34% 的？答案不只在硬件上，也在软件栈上。Google 在 Ironwood GA 前后给出了官方软件栈图：JAX 与 PyTorch 通过 tpu-inference 插件统一到一条 XLA lowering 路径；Pallas/Mosaic 作为手调 kernel 入口、Pallas 通过 Tokamax 暴露给 PyTorch；vLLM TPU 现在由 tpu-inference 驱动，把上一代 TorchAX + tpu-inference 的 JAX backend 替换掉；MaxText、Pathways、Goodput 等高层库在 ICI/OCS 拓扑上通过 shard_map 直接映射IronwoodStack. 另一侧 NVIDIA 给出的是 Dynamo + TRT-LLM + 72-GPU NVLink 域的全栈组合NVDynamo. 这组端到端优势包含软件栈这一变量；仅凭现有对比无法量化它对 5% 标称差距的放大份额，这是 0.181 这条数字能成立的工程底座。下一章就沿着 MoE 通信、KV cache 调度、FP 精度、软件栈这四条机制轴，看前沿位置具体是被哪些工程变量挪动的。

前沿位置被什么挪动：MoE 通信、KV cache、FP 精度与软件栈

把 "为什么 Ironwood 与 B200/B300 的前沿位置会随工作点移动" 这件事拆开看，真正在动的不是硅片标称算力，而是四个机制变量：MoE 通信占比、KV cache 调度粒度、FP 精度档位、以及两侧软件栈的对称性。

第一条轴是 MoE 通信。Sem-MoE 在 8×H20 服务器（>400 GB/s 高速互联）上用 SGLang 部署 DeepSeek-V2-Lite 测出一个直白数字：MoE 单层前向时间里，expert-parallel 通信（A2A dispatch + combine）占 59.2%SemMoE. 这条数字的意思是：MoE 推理的瓶颈不是 expert 本身的算力，是 all-to-all 通信把所有 "等待 token 到来" 的算力都浪费了。

图注：柱状图，把 DeepSeek-V2-Lite 在 8×GPU H20 服务器（>400 GB/s 高速互联）上跑 SGLang 时的 MoE 单层延迟拆成多个分量。EP 通信（A2A dispatch + combine）占据接近整层一半的纵向长度，是论文 "59.2%" 的直接视觉证据。这条数字的限定：只在 DeepSeek-V2-Lite + SGLang + 8×H20 这一具体配置下测得，不能外推到 Qwen3.5-397B（512 experts）SemMoE.

Sem-MoE 的回应是把 "expert 放哪" 与 "token 派往哪" 从两个独立决策合并为一个目标函数（local activation rate α）：离线用约束交叉熵（CEO）共聚类把常被同一批 token 激活的 expert 放在同 device，在 attention TP 阶段用 shuffled-reduce-scatter（SRS）替代 all-reduce、token 在算 gate 之前就被预测性洗牌到目标 expert 组。端到端结果是 local activation rate +37% / +43%、MoE 单层延迟 -41.8% / -46.6%（DeepSeek-V2-Lite / Qwen3-30B-A3B vs SGLang + DeepEP 基线）SemMoE. 在更慢的 PCIe-5 + UPI 这种 ~20.8 GB/s 互联上，同一算法的相对提升反而更大（DeepSeek-R1 吞吐提升从 GPU-Server-A 的 1.72× / 1.15× / 1.49× 涨到 GPU-Server-B 的 1.89× / 2.35× / 4.3×）SemMoE. 这条线的工程含义是：算法优化对 "买不起 NVLink 的推理" 是更便宜的杠杆，也是为什么 NVIDIA 一侧要靠 NVL72 把 72 颗 GPU 焊进同一 NVLink 域来跑 wide EP。

NVIDIA 一侧的硬件对策是 GB200/GB300 NVL72：72 颗 Blackwell GPU + 36 颗 Grace CPU 组成单一 NVLink 域，单 GPU 1.8 TB/s NVLink、18 颗 NVSwitch、域聚合 All-to-All 130 TB/s、All-Reduce 260 TB/sNVL72. 这个域规模刚好够装下 DeepSeek-R1 256 routed experts 配 EP=64 的部署（64 GPU × ~4 expert = 256 experts），是 NVIDIA 给 "wide EP 必须全部位于同一低延迟域" 这一硬约束的工程答案NVDynamo. TPU 一侧的对应物是 9,216 芯片 superpod，通过 OCS + ICI 把 wide EP 扩展到 pod 级别，每芯片双向 ICI 1.2 TB/s（即 9.6 Tb/s）。两组硬件都用 "把大量芯片焊进同一低延迟域" 的方式解决 MoE all-to-all 通信瓶颈。

第二条轴是 KV cache 调度。Mooncake 把 KV cache 升级为 first-class 资源：KV 块跨 CPU/DRAM/SSD/RDMA 四层存储，通过 Messenger（GPUDirect-RDMA based transfer service）按需搬运。Conductor 用 "predicted TTFT/TBT vs SLO 阈值" 当作负载信号，在请求到达时做早期拒绝；同时基于预测把朴素的早期拒绝在 prefill/decode 池 anti-phase 抖动上带来的过度拒绝从 4,183 降到 3,589Mooncake. 在长上下文区间（8k、32k、64k），Mooncake 用 dummy LLaMA2-70B 重放模拟长上下文 traffic，吞吐提升从 50% 到峰值 525%；在真实 trace replay 上，比 vLLM 多处理约 75% 请求（同样满足 TTFT，但 TBT 上 vLLM 只满足 57%、Mooncake 满足 ~100%）Mooncake. 这组数字的工程含义是：长上下文的 $/token 弯折点来自 KV 中心调度，不来自芯片 FLOPS。

NVIDIA 一侧对应的软件层是 NVIDIA Dynamo。Dynamo 在 disagg 设置里自动化三件事：prefill/decode GPU 池间 KV cache 快速传输、把请求路由到持有相关 KV 的 decode GPU、通过 Dynamo Planner + Kubernetes 把整个堆栈扩缩到数万个 GPU。Planner 的输入是三组信号：prefill 队列长度、decode GPU 上的 KV block 利用率、人工启发式阈值；输出是 prefill/decode 池各自的扩缩方向与幅度NVDynamo. Dynamo Planner + KV-aware 路由是可能挪动该前沿、与 ~30% mid-curve 优势相容的一个机制变量；但 InferenceX 的端到端曲线并不只跑过 Dynamo 一侧，且本文掌握的材料未对其他栈做同等口径对照，因此无法把这一段 perf/$ 差距单独归因到 Dynamo，也无从判别它在 Ironwood 聚合服务中段排名变化里占多少贡献。

第三条轴是 FP 精度。Ironwood 这一代没有原生 FP4 路径：TPU7x 优化文档只列出 BF16 与 FP8 两档算力，FP4 不在硅片支持的计算路径上Ironwood. BlackWell 一侧原生 NVFP4：HGX B200 单卡 144 sparse / 72 dense PFLOPS，GB200 NVL72 整机 1,440 sparse / 720 dense PFLOPS，GB300 NVL72 把 dense 拉到 1,080 PFLOPSHGX. 这条硬件不对称意味着：如果把 Qwen3.5-397B 改成 FP4 推理（且接受精度税），NVIDIA 一侧的吞吐优势会被放大；SemiAnalysis 自己也说，在 FP4-vs-FP4 或 FP4-vs-FP8 with quality loss 的口径下，NVIDIA B200/B300 仍领先，TPUv8i "Boardfly"（SemiAnalysis 预测配原生 FP4）才有望在 FP4 路径上与 Rubin NVL72 同台InferX. $0.181 这条 headline 之所以能成立，是因为 Qwen3.5-397B FP8 这个工作点刚好落在 TPU 有硬件支持的精度档上。

第四条轴是软件栈对称性。TPU 一侧：JAX + PyTorch 通过 tpu-inference 走 XLA 单路径；Pallas/Mosaic 作为 hand-tuned kernel 入口；vLLM TPU 与 SGLang 都通过 tpu-inference 接入。NVIDIA 一侧：Dynamo + TRT-LLM + Planner + 72-GPU NVLink 域 + 18× NVSwitchIronwoodStack. 两侧软件栈成熟度的差异，是可能挪动该前沿、与 5% 单芯片领先放大为 19%–34% $/token 这一结果相容的一个机制变量；但 InferenceX 的端到端比较没有把软件栈拆出来单独重测，材料里也未给出任何 ablation，因此无法量化软件栈在放大份额里占多少。SemiAnalysis 在 2026-09 的 InferenceX 测量是跑在 TorchTPU vLLM private beta 上、vLLM 与 SGLang 都预期把 TPU 加入 day-0 模型支持、Google 内部已经在 Gemini 上跑了多年的 PD disagg、externalization 通过 TPU-Sync（前身 TPU-raiden）与 Mooncake Store 推出InferX. 这条软件栈成熟度同时意味着：今天的数字是某一组 software-version snapshot 下的结果，下次 major release（PyTorch Conference 2026-10 后 TorchTPU 离开 private beta）数字会再动一次。

把四条轴拼在一起看：5% 的标称吞吐领先、更低 hourly cost、FP8 路径上硬件对齐、软件栈统一，是与 100 tok/s/user 处 19%–34% $/token 优势这一结果相容的一组机制变量；但 InferenceX 的端到端对比同时绑死了模型、量化、batch、调度与软件栈，本文掌握的材料不足以把它们各自对 $/token 的贡献拆开。换到并发 256，TTFT 5.41 s 是这一组选择下被记录下的延迟代价。换到 ~14 s e2e 交叉，NVIDIA disagg 中段优势出现。换到 FP4 路径，TPU 这一代没有硬件支持，下一代才闭环。所以读者应该带走的不是 "TPU 赢了" 或 "GPU 赢了"，也不是 "这四条变量里哪一条决定了 $/token"，而是：前沿位置被 MoE 通信、KV cache 调度、FP 档位、软件栈成熟度这四个工程变量挪动，每换一个变量排名就翻一次，但本文材料不足以把端到端差异在它们之间分配。

把跑分新闻翻译成采购动作：保留快照、按自家 SLO 重放、画整条 Pareto

SemiAnalysis 在文章末尾给了一个看似温和实则强硬的提醒：50%、76.7%、130.2%、30% 这些百分比都是单点。100 tok/s/user 是一个工作点、并发 256 是另一个、20 s 中位是第三个、~14 s e2e 交叉是第四个、~30 s 短暂反超是第五个。没有任何一组数字可以 "代表整条曲线"InferX. 把这条提醒翻译成采购动作，需要一套工程纪律。

第一件动作是保留版本与价格快照。今天看到的 TPU hourly cost、vLLM 版本、TorchTPU private beta、SemiAnalysis TCO 模型假设，所有这些都是会变的。Google Cloud TPU on-demand 价格历史上以季度节奏变动，spot 价格最多 30 天变一次；GPU 一侧的 retail price 由 cloud vendor 自己定，不同 provider / 区域 / 承诺期动态调整（具体节奏以各家实时报价为准）；vLLM / SGLang / TRT-LLM 每次 release 都能换一组 default kernel。把这些数字当作 "某年某月某版本下的 snapshot" 来记录，而不是 "这是 TPU 的价格" 或 "这是 vLLM 的吞吐"，是采购决策的第一道闸门。

第二件动作是按自家流量与 SLO 在自家服务栈上重放。DistServe 给的 goodput 定义（max rps under TTFT+TPOT SLOs w/ >90% attainment）是最直接的比较标尺：满足 SLO 的请求率才是可被卖出的能力DistServe. 在自家环境里重放需要的工作流是四阶段的：deploy → benchmark（4 档并发扫一遍）→ analyze（P50/P95/P99 + tok/s + $/M + MBU）→ visualize（Pareto frontier 自动识别 + Plotly 仪表盘）SageMakerReplay. 这个工作流有几个纪律值得点出来：warmup 阶段先把 JIT 与 KV cache 稳住再开始测；seeding RNG 让 prompt 在不同 run 之间完全一致；每次跑一条 config 出一份 YAML，配置继承自 base.yaml 加新 config 不改代码；audited 数字挂日期戳目录（results/audited-YYYY-MM-DD-current/）而非 semver。这些纪律本身就把 "warm-up 干扰"、"prompt 形状"、"代码版本变化" 这三类常见污染源挡在 canonical 数字之外SageMakerReplay.

第三件动作是画 Pareto frontier 而不是挑单点 winner。Pareto frontier 在 cost ↔ latency（或 N 维）平面上挑出 "没有其他 config 同时更便宜且更快" 的子集。这正是 SemiAnalysis 在 Qwen3.5-397B 上做的 cost-vs-interactivity 与 cost-vs-e2e-latency 两种曲线的几何形态，只不过前者是 SemiAnalysis 内部跑的、后者才是采购方该在自家环境复现的版本SageMakerReplay. 几何上的好处是：单点赢家（"B200 便宜 2%"）几乎必然被反驳；Pareto 子集是一个集合，可以从中按业务偏好（更看重成本还是更看重延迟）选型，不依赖单点比较。

第四件动作是 caveat-driven documentation。把 "哪些数字不能用" 与 "哪些对比不公平" 直接写进 README，而不是藏在脚注里。常见的 caveat 包括：smoke config（c=[1,2]、10 requests、max_output_tokens=64）不能与完整 sweep（c=[1,5,10,25]、100 requests）相比；CPU 行（llama.cpp GGUF）与 GPU 行（vLLM FP16、TRT-LLM AWQ）因操作点不同不可直接对比；跨后端 radar / TTFT 图在 TTFT=0.0 的后端上不可信；c=25 的 metric 行存在不代表生产可用SageMakerReplay. 把 caveat 当成文档的一部分，而不是附录，是采购方与跑分新闻消费方的根本区别。

把这些动作整合起来，可以用下面这张 D2 图表示完整工作流的最小集合：

第五件动作是把 "goodput 这件事" 嵌进 metrics。DistServe 的 >90% SLO attainment 阈值是学术上的定义；当前 SageMaker 优化器的 metrics_collector 本身只输出 P50/P95/P99 + tok/s + $/M + MBU + error rate，并没有内建 SLO-attainment 报告SageMakerReplay. 把 TTFT P95 与 ITL P95 两个阈值设进 metrics_collector 的 report 模板，即可直接复用 DistServe 的 >90% attainment 规则。这是从 "SageMaker 优化器" 升级到 "DistServe-style goodput reporting" 的具体下一步动作，也是把采购框架与 goodput 标尺接到同一根线上的最后一公里。

把整条路径收口：从 "Ironwood $0.181 headline" 到 "持续基准 + Pareto frontier" 的完整链路，本质上是把 $/token 从 "硅片常数" 还原回 "TCO / SLO-aware goodput" 这一比值公式。读者带走的不是某一年的某一次跑分，而是一条工程方法：保留版本与价格快照、按自家 SLO 重放、画 Pareto 子集而非挑单点 winner、把 caveat 写进文档、把 goodput 阈值嵌进 metrics。0.181 这条 headline 在这套方法下不再是 "TPU 赢了" 的口号，而是 "在 Qwen3.5-397B FP8 8k1k 100 tok/s/user 这一特定工作点上，TPU 满足 SLO 的 goodput 与 TCO 的比值排第一" 的可校验陈述。换工作点、换模型、换精度、换服务栈，结论就跟着变——而采购方的工作正是把 "变" 这件事变成自己手里可控的工程动作，而不是被动接收每一条 headline。

参考文献

本专题引用的核心资料如下，建议深入学习时阅读原文：

  1. TPU Inference Externalization Full Steam Ahead — inferencex.semianalysis.com
  2. Ironwood: The first Google TPU for the age of inference — blog.google
  3. DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving (arXiv:2401.09670, OSDI 2024) — arXiv:2401.09670
  4. Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve (arXiv:2403.02310, OSDI 2024) — arXiv:2403.02310
  5. Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving (arXiv:2407.00079, FAST 2025) — arXiv:2407.00079
  6. Semantic Parallelism: Redefining Efficient MoE Inference via Model-Data Co-Scheduling (arXiv:2503.04398, ICLR 2026) — arXiv:2503.04398
  7. From silicon to softmax: Inside the Ironwood TPU codesigned AI stack — cloud.google.com
  8. How NVIDIA GB200 NVL72 and NVIDIA Dynamo Boost Inference Performance for MoE Models — developer.nvidia.com
  9. NVIDIA HGX B200 / B300 Product Pages — nvidia.com
  10. SageMaker LLM Inference Optimizer — github.com/varad-more
Ironwood vs B200/B300：每 token 成本是一场带 SLO 的系统结果