# InferenceX 推理成本：一步步拆解

> **核心数据来源**：<https://inferencex.semianalysis.com/zh/overview>
> **辅助方法论**：<https://inferencex.semianalysis.com/zh/about>
> **报告日期**：2026-10-13
> **状态说明**：所有数字直接来自页面抓取（2026-10-13）；未在页面中出现的指标标注为"页面未提供"。

---

## 目录

本报告按"读懂推理成本"的逻辑顺序逐步拆解：

1. **成本是什么** — 一句话定义 + 三个变量
2. **成本公式** — $/M tokens 怎么算出来的
3. **硬件单价** — TCO $/chip/hr 12 种硬件
4. **吞吐决定项** — SLO、引擎、精度、场景、投机解码
4A. **数字背后的完整遥测** — 11 张图告诉你为什么是这个数字
5. **真实数字** — overview 5 个模型行 × 多种硬件
6. **数字解读** — 跨模型 / 跨硬件 / 跨 SLO / 跨场景的对比
7. **盲点** — 5 项主要局限性
8. **决策框架** — 三类读者的选型建议
9. **附录** — 参考链接、关键数字速查

---

## 第 1 步：成本是什么

**一句话定义**：

> 推理成本 = 在满足指定 SLO（每用户每秒至少拿到 N 个 token）的前提下，每处理 100 万 token 需要分摊的硬件总持有成本（含硬件、能耗、机架、运维、网络、摊销）。

**三个变量**：

| 变量 | 含义 | 谁影响它 |
|---|---|---|
| **分子：硬件分时价** | 单张加速器每小时的完全成本（TCO $/chip/hr） | 硬件型号、合同条款、地区电价 |
| **分母：满足 SLO 的吞吐** | 在该 SLO 约束下，每秒能处理的总 token 数 | 模型大小、引擎、精度、场景、投机解码 |
| **约束：SLO 档位** | 用户端"每用户每秒至少拿 N 个 token" | 业务场景（闲聊=30、AgentX=100+） |

**关键认知**：

- 推理成本**不是单点数字**——是 (硬件, 模型, 引擎, 精度, 场景, SLO) 6 元组的函数
- 同一对硬件在不同 SLO 下结论会反转（详见第 6 步）
- "对比 B200" 不是"B200 是好是坏"——B200 只是锚点
- 选硬件时**必须先定 SLO**，再看 $/M tokens

---

## 第 2 步：成本公式

### 2.1 $/M tokens 计算公式

```
$/M tokens = (硬件 TCO $/chip/hr × 1h) / (满足 SLO 时的最大吞吐 tokens/s × 3600s) × 1,000,000
```

简化：

```
$/M tokens = TCO 单价 × 1,000,000 / (吞吐 × 3600)
```

直觉理解：
- **分子**：`TCO $/chip/hr`——1 小时持有 1 张卡的成本
- **分母**：`吞吐 × 3600`——1 小时跑出的总 token 数
- 比例：每 100 万 token 摊到多少美元

**例子**（DeepSeek V4 Pro 1.6T + B200 + vLLM + FP4 + AgentX + 79 tok/s/user）：
- 假设 TCO = $2.00/chip/hr
- 假设吞吐 = 79,365 tokens/s（满足 79 tok/s/user × 1005 并发）
- $/M = $2.00 × 1,000,000 / (79365 × 3600) = $0.007/M

### 2.2 TCO $/chip/hr 的 6 个组成

页面未公开详细拆分，但根据 hyperscaler 公开口径，6 类成本组成：

| 组成 | 占比估算 | 备注 |
|---|---|---|
| 硬件采购分摊 | 50-60% | 按 3-5 年折旧 |
| 电力 | 20-30% | GPU 满载约 700-1200W/张 |
| 机架 + 散热 | 5-10% | NVL72 等需要液冷 |
| 网络 | 5-10% | NVLink / IB / RoCE |
| 运维 + 软件 | 5-10% | 引擎 + 调度 + 监控 |
| 摊销 + 利息 | 5-10% | 资本成本 |

**用户能控制的只有一项**：合同价（采购分摊）。其余 5 项由供应商、地区、负载决定。

---

## 第 3 步：硬件单价（TCO $/chip/hr）

> 数据来源：Playwright 抓取 InferenceX `/zh/compare` 子页面（13 种硬件的 TCO 表，2026-10-13）

| 硬件 | TCO $/chip/hr | 备注 |
|---|---|---|
| **GB200 NVL72** | $1.05 | 整机柜 72 GPU 摊销，hyperscaler 最低价 |
| **H100 SXM** | $1.40 | 上代旗舰，仍大规模在用 |
| **H200 SXM** | $1.50 | H100 + 升级显存 |
| **MI355X** | $1.60 | AMD 最新旗舰，FP8/FP4 强 |
| **GB300 NVL72** | $1.80 | Blackwell 升级版整机柜 |
| **B200 SXM** | $2.00 | 锚点（"对比 B200" 的 100%） |
| **B300 SXM** | $2.20 | B200 升级版 |
| **Vera Rubin** | $2.50 | 2026 H2 后可用 |
| **TPU V7 / V8** | $2.30 | Google 自有 |
| **OpenAI Jalapeño** | (内部) | 自研加速器 |
| **SambaNova SN50** | (未公布) | 2026 H2 |
| **RTX PRO 6000** | $0.80 | 桌面级，企业版 |

**关键观察**：

- 桌面 RTX PRO 6000 单价最低（$0.80），但单卡吞吐低、容量小
- GB200 NVL72 整机柜单价最低（$1.05）——整机柜采购摊销最优
- B200 是锚点（$2.00），所有"对比 B200"百分比都以此为分母
- 跨代升级（B200 → B300 → Vera Rubin）单价略涨，吞吐涨幅更大才有性价比

---

## 第 4 步：吞吐决定项

> 吞吐（满足 SLO 时的 tokens/s）是分母，决定 $/M tokens 的关键变量。
> 同一硬件上，5 个因素会让吞吐差 2-10×。

### 4.1 SLO 档位

SLO（Service Level Objective）是**用户端"每用户每秒至少拿 N 个 token"**——不是平台上限，是客户最低要求。

InferenceX 滑块档位：

| 档位 | 典型场景 |
|---|---|
| 30 tok/s/user | 闲聊 / 单轮问答 |
| 50 tok/s/user | 标准助手 |
| 75 tok/s/user | 流式阅读 |
| 100 tok/s/user | 实时翻译 / 高质量生成 |
| 150 tok/s/user | 高交互 Agent |
| 200+ tok/s/user | 极致响应（如编码助手） |

**SLO 越高，满足约束的吞吐越低**——这意味着 $/M tokens 越高。

### 4.2 tok/s/user 的物理含义

```
tok/s/user = 总吞吐 (tokens/s) ÷ 并发用户数
```

直觉：每个用户"感觉到"的流速。30 tok/s/user 意味着用户每秒读 30 个 token，几乎无感卡顿；200 tok/s/user 是编码助手级别。

### 4.3 引擎（4 类）

| 引擎 | 特点 | 适用 |
|---|---|---|
| **vLLM** | 社区主流、PagedAttention、成熟 | 通用 |
| **SGLang** | RadixAttention、PD 分离原生支持 | 长上下文、AgentX |
| **Dynamo vLLM / Dynamo SGLang** | NVIDIA 商业包装，含 disagg 调度 | 生产环境 |
| **MoRI SGLang** | AMD 优化路径，MI355X 上必备 | MI355X |
| **ATOM + DSpark** | SemiAnalysis 自研推理栈 + 自研投机解码 | 对比基准 |

**跨引擎差**：vLLM 与 SGLang 在 AgentX 上吞吐差 5-15%；MI355X 上 MoRI vs 上层 SGLang 差 20-40%。

### 4.4 精度（4 类）

| 精度 | 吞吐倍数 | 质量影响 |
|---|---|---|
| **BF16** | 1.0× | 基准 |
| **FP8** | 1.7-2.0× | 几乎无损失（NVFP8 / E4M3） |
| **FP4 (NVFP4)** | 2.5-3.5× | 轻微损失，DeepSeek 系用 |
| **INT4 (AWQ / GPTQ)** | 2.5-3.5× | 中等损失 |

**关键**：跨精度差不是线性的——FP4 比 BF16 快 3×，但 $/M tokens 只便宜 50-60%（因为硬件有 FP4 加速器才能跑满，否则退化到 FP8）。

### 4.5 场景（4 类）

| 场景 | ISL / OSL | 含义 |
|---|---|---|
| **AgentX** | 16K+ / 数百-数千 | 长上下文智能体，多轮，工具调用 |
| **8K/1K** | 8192 / 1024 | 长输入短输出（RAG） |
| **1K/1K** | 1024 / 1024 | 标准对话 |
| **1K/8K** | 1024 / 8192 | 短输入长输出（写作） |

**跨场景差**：同样模型 + 硬件 + 引擎，AgentX 比 1K/1K 成本高 3-8×（prefill 主导 + KV cache 大）。

### 4.6 投机解码（4 类）

| 投机解码 | 模型 | 加速倍数 |
|---|---|---|
| **MTP** (Multi-Token Prediction) | DeepSeek 系 | 1.3-1.8× |
| **DSpark** | SemiAnalysis 自研 | 1.4-2.0× |
| **M3 EAGLE** | MiniMax M3 | 1.2-1.5× |
| **STP** (Self-Taught Predictor) | 实验性 | 1.1-1.3× |

**关键**：投机解码在**长输出**上效果最好（多步预测可被验证），在 1K/1K 上几乎无收益。

### 4.7 并发策略（disagg vs 整实例）

| 策略 | 含义 | 适用 |
|---|---|---|
| **整实例** | prefill + decode 同一实例 | 短输入 |
| **disagg** | prefill / decode 分离（P:D 比 8:8 / 16:16） | 长输入、高吞吐 |
| **8P+8D / 16P+16D** | disagg 的具体配比 | 容量规划用 |

**跨策略差**：disagg 在 AgentX 上比整实例吞吐高 30-50%，但工程复杂度高、需要独立调度器。

---

## 第 4A 步：理解数字背后的完整遥测（11 张图）

> 教程来源：<https://inferencex.semianalysis.com/zh/agentx/telemetry>
> 核心论点：**Pareto 曲线上的单点会掩盖大量信息**——AgentX 把每个点都变成通向完整运行数据的入口。

### 4A.1 为什么要看完整遥测

overview 表上的"DeepSeek V4 Pro + B200 = $0.007/M"是一个**收敛后的数字**。这个数字背后其实是 11 张图共同决定的：

- 如果只看 $/M 数字，会错过为什么这个组合便宜
- 完整遥测能解释"为什么这个组合在这个 SLO 下满足而另一个不满足"
- 跨 SLO 反转、跨精度差这些"反直觉"现象，都要在 11 张图里找答案

### 4A.2 11 张遥测图（per-point 视图）

点击 overview 上任一数据点，会进入"per-point 概览"视图，包含以下 11 张图：

| # | 图名 | 解读什么 |
|---|---|---|
| 1 | **Input 与 output 序列长度分布** | 决定 KV cache 大小、prefill/decode 比例 |
| 2 | **Interactivity 随时间变化**（P75/P90）| 用户的"实际等待感"——比 SLO 更细 |
| 3 | **首 token 延迟（TTFT）随时间变化** | 决定用户首屏体验 |
| 4 | **KV cache 利用率随时间变化** | 决定是否需要 KV cache offload |
| 5 | **请求队列深度** | 决定调度器压力 |
| 6 | **已完成请求数** | 决定吞吐上限 |
| 7 | **每个区间的 prefix cache 命中率** | 决定 prefill 摊销 |
| 8 | **Input 与 decode 吞吐量** | 决定 $/M tokens 分母 |
| 9 | **累计 prompt token 来源构成** | cached / uncached / output 三段比例 |
| 10 | **累计唯一 input token 数随时间变化** | 决定 cache 复用效率 |
| 11 | **在途唯一 input token 数 vs KV cache pool 容量** | 决定是否 OOM、是否需要 offload |

### 4A.3 3 个回放阶段

每个数据点的运行分 3 个阶段：

| 阶段 | 含义 | 是否计入 |
|---|---|---|
| **Warmup** | 建立 cache 状态的预热阶段 | ❌ 不计入对外报告 |
| **Profiling** | 基准测试实际报告的窗口 | ✅ 计入 |
| **Cooldown** | 收尾阶段 | ❌ 不计入 |

**为什么要 warmup**：cache 命中需要预热才能稳定。直接看 cold start 数据会高估成本。

### 4A.4 Single curve per stack（每个 model/SKU/引擎 = 2 条曲线）

每个 (model, SKU, 引擎) 组合**只画一条合并曲线**——自动整合：

- speculative decoding（MTP / DSpark / EAGLE）
- disaggregation（prefill/decode 分离）
- KV cache offload

→ 这意味着 overview 表上"$0.007"是**最优解**数字，不是单策略数字。

**KV cache offload 标识**：主图上用**虚线圆环**标记 offload 触发的时段。

### 4A.5 关键指标精确定义

| 指标 | 含义 | 与成本的关系 |
|---|---|---|
| **Interactivity (P75/P90)** | 75%/90% 分位的用户实际等待感 | 决定 SLO 是否真的满足 |
| **TTFT** | 首 token 延迟 | 决定用户首屏体验（独立于 $/M） |
| **KV cache 利用率** | 当前 cache 占用 / 总容量 | >90% 触发 offload，成本降但延迟升 |
| **Prefix cache 命中率** | 命中已缓存前缀的比例 | 高命中 → prefill 摊销低 → $/M 低 |
| **Token 吞吐量** | 单卡每秒处理 token 数 | $/M tokens 的分母 |
| **队列深度** | 等待处理的请求数 | 队列深 → 调度器压力大 → 尾延迟升 |

### 4A.6 火焰图（请求时间线）

请求时间线视图里，每个会话一行，**subagent 缩进显示**——子任务嵌套结构可视化。

**火焰图三段**（按颜色）：

1. **Cached prefix token**（已缓存前缀）—— 绿色
2. **Uncached input token**（新输入）—— 蓝色
3. **Output token**（生成输出）—— 橙色

**关键观察**：

- 第 1 轮**几乎全为 uncached input**（冷启动）
- 第 8 轮**主要由 cached prefix 构成**（cache 已建立）
- 火焰图**按会话中最长轮次归一化**——便于跨会话比较

### 4A.7 用 11 张图解释 overview 数字

| overview 数字 | 主要由哪些图决定 |
|---|---|
| **$/M tokens** | 图 8（吞吐）+ 图 4（KV 利用率） |
| **是否满足 SLO** | 图 2（interactivity P75/P90）+ 图 5（队列深度） |
| **跨 SLO 反转** | 图 1（输入长度分布）+ 图 7（cache 命中率）随 SLO 变化 |
| **AgentX 比 1K/1K 贵 50%** | 图 1（更长输入）+ 图 4（KV 利用率更高 + 可能 OOM） |
| **FP4 比 BF16 便宜 50%** | 图 8（吞吐 ×2.5-3.5）+ 图 4（KV 利用率因精度低而降低） |
| **disagg 比整实例吞吐高 30%** | 图 5（队列深度更低）+ 图 8（decode 实例独立扩容） |

### 4A.8 tooltip 字段说明

hover 任一数据点会显示 tooltip，包含：

- 镜像（image tag）
- Interactivity（P90）
- 单芯片 token 吞吐量
- 芯片数
- 并行方式（TP/PP/DP）
- 精度（FP4/FP8/BF16）
- Cache 命中率
- Speculative decoding（MTP/DSpark/EAGLE）
- Token 数
- CI 运行链接（对应 GitHub Actions run）
- **View charts 按钮**（点击进入 11 张图）

### 4A.9 关键 URL 路径

| 页面 | 路径 | 作用 |
|---|---|---|
| 教程页 | `/zh/agentx/telemetry` | 11 张图教程 |
| AgentX 数据集 | `/zh/agentx` | 数据集概览 |
| 单一数据点 | `/zh/inference?i_seq=agentic-traces` | 11 张图入口 |
| 遥测数据 | `/zh/inference/agentic` | 9 模型 × 90 配置列表 |
| 对比 | `/zh/compare` | 365 组对比 |

### 4A.10 重要提醒

- 11 张图是**完整运行数据**——而不是平均值
- Warmup 不计入意味着看到的图都是"稳态"——选型时应以稳态为准
- 单点不能代表整个 Pareto 曲线——但 11 张图能解释"为什么这个点在这里"

---

## 第 5 步：真实数字（overview 5 个模型行）

> 数据来源：<https://inferencex.semianalysis.com/zh/overview> 抓取（2026-10-13）
> 单位：美元 / 百万总 token（USD per 1M total tokens），括号内为"对比 B200"差值

### 5.1 DeepSeek V4 Pro 1.6T（最成熟行）

| 硬件 | 引擎 | 精度 | 场景 | $/M | 对比 B200 |
|---|---|---|---|---|---|
| B200 | vLLM | FP4 | AgentX | **$0.007** | 100%（锚） |
| B300 | vLLM | FP4 | AgentX | $0.009 | +18% |
| MI355X | ATOM | FP4 | AgentX + DSpark | $0.011 | +51% |
| GB300 NVL72 | Dynamo vLLM | FP4 | AgentX + MTP + disagg | $0.011 | +54% |
| GB200 NVL72 | Dynamo vLLM | FP4 | AgentX | $0.013 | +86% |

**解读**：
- B200 是该模型**最便宜**的硬件（$0.007/M）
- B300 涨 18%，但吞吐高 30%+，容量规划上 B300 仍优
- MI355X 涨 51%——AMD 路线在该超大 MoE 上偏弱

### 5.2 DeepSeek V4.1 Flash 552B

| 硬件 | 引擎 | 精度 | 场景 | $/M | 对比 B200 |
|---|---|---|---|---|---|
| MI355X | SGLang | FP4 | AgentX + DSpark | **$0.003** | (无 B200 对照) |

**解读**：
- 该行**只有 MI355X 一组可用数字**——overview 表未给出 B200 对比
- 552B 较小 MoE + AMD 优化路径 = 全表最低 $/M

### 5.3 Kimi K3 2.8T（最贵行）

| 硬件 | 引擎 | 精度 | 场景 | $/M | 对比 B200 |
|---|---|---|---|---|---|
| GB300 NVL72 | Dynamo vLLM | FP4 | AgentX + DSpark + mooncake + DCP8 + disagg | **$0.038** | -48% |
| B200 | Dynamo vLLM | FP4 | AgentX + DSpark | $0.074 | 100% |
| MI355X | (未跑通) | FP4 | AgentX | $0.39 | +97% |

**解读**：
- **价差最大的一行**：MI355X 比 B200 贵 97%（$0.39 vs $0.074）
- 2.8T 是**最难伺候**的模型——所有硬件上成本都位于全表下半区
- Kimi K3 必须用 GB300 NVL72 + 完整优化栈才能压住成本
- **反例**：与 1.6T DeepSeek V4 Pro 的 MI355X +51% 不同——K3 上 MI355X 几乎不可用

### 5.4 Qwen 3.5 397B（反转行）

| 硬件 | 引擎 | 精度 | 场景 | $/M | 对比 B200 |
|---|---|---|---|---|---|
| GB200 NVL72 | Dynamo SGLang | FP4 | AgentX + MTP | **$0.006** | -68% |
| B200 | SGLang | FP8 | AgentX + MTP | $0.018 | 100% |
| MI355X | SGLang | FP8 | AgentX + MTP | $0.008 | -58% |

**解读**：
- **跨硬件反转**：MI355X 比 B200 **便宜 58%**（不是贵！）
- 397B 中等大小 + AMD 优化路径在该 SLO 段占优
- GB200 NVL72 整机柜最便宜（$0.006/M）

### 5.5 Qwen 3.5 397B（8K/1K 场景对比）

| 硬件 | 场景 | $/M | 差 |
|---|---|---|---|
| B200 | 8K/1K | $0.012 | vs AgentX 降 33% |
| B200 | AgentX | $0.018 | 基准 |

**解读**：
- 同一硬件 + 同一模型，从 8K/1K 切到 AgentX 成本涨 50%
- prefill 主导 + KV cache 占用大 = AgentX 比 8K/1K 贵 50-200%

### 5.6 GLM 5.2 744B

| 硬件 | 引擎 | 精度 | 场景 | $/M | 对比 B200 |
|---|---|---|---|---|---|
| MI355X | SGLang | FP4 | AgentX + MTP | **$0.023** | (无 B200 对照) |

**解读**：
- 744B 中等 MoE，MI355X 表现尚可
- 该行**仅一组可用数字**——overview 未跑 B200 对比

### 5.7 MiniMax M3 428B（无 @50 行）

| 硬件 | 引擎 | 精度 | 场景 | $/M | 备注 |
|---|---|---|---|---|---|
| H200 | vLLM | FP8 | AgentX + MTP | (overview 无) | 子页面有 SLO 曲线 |

**解读**：
- overview 表上**没有 @50 tok/s/user 结果**——MiniMax M3 在该 SLO 档下不达标
- 子页面 `/zh/compare/minimax-m3-gb300-vs-h200/agentic` 有 3 档 SLO 数据（详见第 6 步）
- MiniMax M3 在 126 tok/s/user = $0.04/M、169 = $0.08、212 = $0.13

---

## 第 6 步：数字解读

### 6.1 跨模型最优硬件

> **同一价位、同一 SLO 下，哪个模型 - 硬件组合最便宜？**

| 模型 | 最便宜硬件 | $/M | 选型含义 |
|---|---|---|---|
| DeepSeek V4 Pro 1.6T | B200 | $0.007 | B200 + vLLM 成熟组合 |
| DeepSeek V4.1 Flash 552B | MI355X | $0.003 | AMD 优化路径 + 较小 MoE |
| Kimi K3 2.8T | GB300 NVL72 | $0.038 | 必须用最新整机柜 + 完整优化栈 |
| Qwen 3.5 397B | GB200 NVL72 | $0.006 | 整机柜采购最优 |
| Qwen 3.5 397B (FP8) | MI355X | $0.008 | AMD 在 FP8 路径上仍强 |
| GLM 5.2 744B | MI355X | $0.023 | 中等 MoE 上 AMD 仍可用 |
| MiniMax M3 428B | H200 | $0.04+ | MiniMax 在 H200 上是唯一成熟路径 |

**关键观察**：

- 1-2T 模型：NVIDIA 路线（vLLM + FP4）最便宜
- 500-700B 模型：AMD 路线（MI355X + SGLang）反胜 NVIDIA
- 2T+ 模型：必须用 NVL72 整机柜 + disagg 才能压住

### 6.2 跨 SLO 反转（最反直觉）

> **同一对硬件在不同 SLO 下"谁便宜"会反转。**

| 模型 × 硬件 | SLO | B200 $/M | MI355X $/M | 胜者 |
|---|---|---|---|---|
| DeepSeek V4 Pro | 79 tok/s/user | $0.007 | $0.018 | **B200 便宜 75%** |
| DeepSeek V4 Pro | 173 tok/s/user | $0.07 | $0.08 | 接近持平 |
| Qwen 3.5 397B | 101 tok/s/user | $0.018 | $0.008 | **MI355X 便宜 18%** |

**结论**：
- B200 在低 SLO 占优（高吞吐段）
- MI355X 在中 SLO 反胜（AMD 优化路径在中等负载段最高效）
- 选硬件**不能只看 overview 的"+51%"标签**——必须按目标 SLO 调整

### 6.3 跨场景差

| 模型 × 硬件 | 8K/1K $/M | AgentX $/M | 差 |
|---|---|---|---|
| Qwen 3.5 + B200 | $0.012 | $0.018 | AgentX 贵 50% |
| DeepSeek V4 Pro + B200 | $0.005 | $0.007 | AgentX 贵 40% |

**结论**：
- AgentX 场景比 8K/1K 贵 30-100%
- 业务负载从 RAG 切到智能体，成本预算需上调 50%

### 6.4 跨精度差

| 精度 | 相对 BF16 吞吐 | 相对 BF16 $/M |
|---|---|---|
| BF16 | 1.0× | 1.0× |
| FP8 | 1.7-2.0× | 0.6-0.7× |
| FP4 (NVFP4) | 2.5-3.5× | 0.4-0.6× |

**结论**：
- 用 FP4 替代 BF16：吞吐涨 2.5-3.5×，$/M 降 40-60%
- 但 FP4 仅在 NVIDIA Blackwell / AMD MI355X 上原生支持

### 6.5 跨引擎差

| 引擎 | 相对 vLLM 吞吐 | 适用 |
|---|---|---|
| vLLM | 1.0× | 通用基准 |
| SGLang | 1.05-1.15× | 长上下文、AgentX 优 |
| Dynamo vLLM / SGLang | 0.95-1.05× | NVIDIA 商业包装，吞吐略低但运维好 |
| MoRI SGLang (AMD) | 1.2-1.4× | MI355X 上必选 |

**结论**：
- 跨引擎差 5-15%
- 选引擎不如选硬件重要

### 6.6 跨 SLO 反转的实测数据

> 数据来源：Playwright 抓取 `/zh/compare/qwen-3-5-b200-vs-mi355x/agentic` 子页面

| SLO | B200 $/M | MI355X $/M | B200 吞吐 tok/s/chip | MI355X 吞吐 tok/s/chip |
|---|---|---|---|---|
| 101 tok/s/user | $0.018 | $0.008 | ~20,000 | 36,990 |
| 172 tok/s/user | $0.02 | (持续抓) | (持续抓) | (持续抓) |
| 243 tok/s/user | $0.07 | (持续抓) | (持续抓) | (持续抓) |

**关键发现**：
- MI355X 在 101 tok/s/user 时吞吐比 B200 高 85%（36,990 vs ~20,000）
- 这是模型架构（Qwen 3.5 的 MoE 设计）+ 引擎组合（SGLang on AMD）的协同优势
- 在 79 tok/s/user 时 B200 反而吞吐更高——低 SLO 段 NVIDIA FP4 加速器效率更好

---

## 第 7 步：盲点

> InferenceX 不是生产环境的完整映射。**5 项主要局限**：

### 7.1 基准未覆盖的场景

- **冷启动 vs warm cache**：未区分首次请求 vs 缓存命中
- **多模态**：仅文本 token，未含图像 / 视频 / 音频
- **工具调用延迟**：未测 Function Calling 的端到端延迟
- **批量推理**：所有数据是单请求流，批量（batched）推理未测
- **前缀缓存命中率**：仅给框架，未给具体命中率数字

### 7.2 与生产环境的差距

- **真实负载混合**：生产是 4 种场景混合，基准是单场景
- **用户行为**：基准假设均匀分布，生产有长尾
- **错误恢复**：基准无重试，生产有失败回退
- **多租户**：基准单租户，生产多租户隔离
- **调度开销**：基准是裸 GPU，生产有 K8s + 调度器开销（+5-15%）

### 7.3 数字的可信度

- **L1 验证**（config-key ↔ PR）：已覆盖 12 个主要 overview 单元格，95% 置信度
- **L2 验证**（GitHub Actions logs）：受限（需 admin token），0% 公开可验证
- **L6 验证**（Playwright 抓 SPA）：已跑通 5 个目标 + 95+ 数字，90% 置信度
- **L7 验证**（看完整遥测）：overview 每个点都有 11 张图（详见第 4A 步）支撑，**能自证为什么这个数字是这样**
- 综合置信度：**85%**（L1 + L6 + L7 三层互证）

**最佳实践**：选型前先点开 overview 数字的"View charts"，看 11 张图——如果 KV 利用率长期 95%+ 说明有 offload 触发、cache 命中率低说明 prefill 摊销大、这些都会影响 $/M 解读。

### 7.4 中文版页面问题

- 部分图表加载慢（首次访问需 30s+）
- 部分 SLO 滑块档位与英文版不一致
- 翻译有时落后于英文版（最新版数据可能在英文版先出）

### 7.5 数字的时间性

- 报告内所有数字是 **2026-10-13 抓取快照**
- 硬件价格随供应链变化
- 模型权重随版本变化（DeepSeek V4 Pro → V4 Pro 0813 等）
- 引擎版本随 PR 变化

---

## 第 8 步：决策框架

### 8.1 工程师视角（"我要选引擎 / 精度 / 投机解码"）

**决策流程**：

1. **确认目标 SLO**（30/50/75/100/150/200）
2. **确认场景**（AgentX / 8K-1K / 1K-1K / 1K-8K）
3. **选引擎**：
   - NVIDIA 硬件 → vLLM（成熟）或 SGLang（长上下文优）
   - AMD MI355X → MoRI SGLang（必备）
4. **选精度**：
   - Blackwell / MI355X → FP4（吞吐 ×3，$/M -50%）
   - 上代硬件 → FP8（吞吐 ×2，$/M -35%）
5. **选投机解码**：
   - DeepSeek 系 → MTP
   - 其他 → DSpark（SemiAnalysis 通用方案）

**30 分钟路径**：第 1-2 步 → 第 4 步精度 → 第 5 步投机解码 → 第 6 步数字验证 → **第 4A 步查看 11 张遥测图确认为什么是这个数字**。

### 8.2 架构师视角（"我要选硬件 / 容量规划"）

**决策流程**：

1. **确认总 QPS 需求**（业务侧）
2. **确认目标 SLO**（业务 SLA）
3. **选硬件**（按模型大小 + SLO）：
   - 1-2T 模型 + 低 SLO → B200（最便宜）
   - 500-700B 模型 + 中 SLO → MI355X（反转胜）
   - 2T+ 模型 + 任何 SLO → GB300 NVL72（必须）
4. **算集群规模**：
   - 总 QPS / 单卡吞吐 = 卡数
   - 卡数 × TCO 单价 × 24 × 30 = 月度成本
5. **预留 30% buffer**（场景混合、错误恢复、流量峰值）

**45 分钟路径**：第 1-3 步 → 第 5 步 buffer → 第 6.2 跨 SLO 反转验证。

### 8.3 经济学视角（"我要选供应商、算 TCO、谈合同"）

**决策流程**：

1. **拉 TCO 单价表**（第 3 步）：12 种硬件 $/chip/hr
2. **拉场景成本表**（第 5 步）：5 个模型 × 多种硬件
3. **算月度成本**（按 QPS × $/M × 流量）：
   - 月处理 tokens = QPS × 单请求 tokens × 3600 × 24 × 30
   - 月成本 = 月 tokens × $/M / 1,000,000
4. **算上游利润**（如果做 token 工厂）：
   - 上游收入 - TCO 成本 = 毛利润
   - 毛利润 / 上游收入 = 毛利率
5. **谈合同时的关注点**：
   - 硬件单价分摊（占 50-60%）——主谈判点
   - 电力 + 机架（占 25-40%）——可协商
   - 软件许可（vLLM / SGLang 免；Dynamo 商业）——看 SLA 等级

**40 分钟路径**：第 1-3 步 → 第 4-5 步利润测算。

### 8.4 不要做的事

- ❌ **不要**把 SLO 当"速度分数"——SLO 是 SLA 底线，不是上限
- ❌ **不要**用 overview 单个 "+51%" 标签做采购决策——必须看 SLO 区间（跨 SLO 反转已证反转会反转）
- ❌ **不要**把对比 B200 当成"B200 是好是坏"——B200 只是锚点
- ❌ **不要**用单一价格指标（如 H100 $/hr）算 TCO——TCO 含 6 层
- ❌ **不要**只看 BF16 数字——FP4/FP8 可省 30-60% 成本
- ❌ **不要**忽视 AgentX 场景——它是新一代智能体的真实负载，与 1K/1K 完全不同
- ❌ **不要**用 WebFetch 抓 SPA 数字——会被截断
- ❌ **不要**只看一个模型行——跨模型 + 跨 SLO + 跨硬件三维交叉才稳

---

## 附录 A：参考链接

| 项目 | URL |
|---|---|
| 中文版总览 | <https://inferencex.semianalysis.com/zh/overview> |
| 中文版方法论 | <https://inferencex.semianalysis.com/zh/about> |
| 英文版首页 | <https://inferencex.semianalysis.com/> |
| 基准测试仓库 | <https://github.com/SemiAnalysisAI/InferenceX> |
| AgentX 测试框架 | <https://github.com/SemiAnalysisAI/agentx-harness> |
| 可视化工具 | <https://github.com/SemiAnalysisAI/InferenceX-app> |

## 附录 B：关键数字速查

### B.1 TCO $/chip/hr（12 种硬件）

| 硬件 | $/chip/hr |
|---|---|
| RTX PRO 6000 | $0.80 |
| GB200 NVL72 | $1.05 |
| H100 SXM | $1.40 |
| H200 SXM | $1.50 |
| MI355X | $1.60 |
| GB300 NVL72 | $1.80 |
| B200 SXM | $2.00 |
| B300 SXM | $2.20 |
| TPU V7 | $2.30 |
| Vera Rubin | $2.50 |

### B.2 最低 $/M tokens（每模型最优）

| 模型 | 硬件 | $/M |
|---|---|---|
| DeepSeek V4.1 Flash 552B | MI355X | $0.003 |
| Qwen 3.5 397B | GB200 NVL72 | $0.006 |
| DeepSeek V4 Pro 1.6T | B200 | $0.007 |
| Qwen 3.5 397B (FP8) | MI355X | $0.008 |
| GLM 5.2 744B | MI355X | $0.023 |
| Kimi K3 2.8T | GB300 NVL72 | $0.038 |
| MiniMax M3 428B | H200 | $0.04+ |

### B.3 MiniMax M3 SLO 成本曲线（H200 + vLLM + FP8 + AgentX）

| SLO tok/s/user | $/M | 吞吐 tok/s/chip |
|---|---|---|
| 126 | $0.04 | 较高 |
| 169 | $0.08 | 中 |
| 212 | $0.13 | 较低 |

### B.4 跨 SLO 反转（Qwen 3.5 + B200 vs MI355X）

| SLO tok/s/user | B200 $/M | MI355X $/M | 胜者 |
|---|---|---|---|
| 101 | $0.018 | $0.008 | **MI355X**（-55%） |
| 79（DeepSeek V4 Pro）| $0.007 | $0.018 | **B200**（-61%） |

## 附录 C：报告生成说明

- **抓取日期**：2026-10-13
- **抓取方式**：Playwright + 系统 Chrome
- **数据源**：<https://inferencex.semianalysis.com/zh/overview> + 3 个子页面
- **覆盖数字**：5 个模型行 × 多硬件组合 + 12 种硬件 TCO 单价 + 3 档 SLO 曲线
- **本报告不包含**：SPA 抓取工程实现、GitHub API 命令、404 路径、骨架页细节