适用读者：要判断"这套推理服务贵不贵、慢在哪"的后端/平台工程师；被 TTFT、TPOT、prefill 这些词绕晕的人。
前置：S20（大模型机制：Transformer/注意力/KV 缓存）、S17（服务容量基础）。
覆盖旧文：A-1988 → 13 点（§1 六个方向与"一年十倍"的背景、§2 MoE 与 prefill/decode）。
扩展点：E-S23-001（TTFT/TPOT 的定义与测量）、E-S23-002（MoE 的算力/显存账）。
下一篇：S23-J02 · 分布式推理。
系列说明：本系列素材只有一张 L2 卡（进阶），因此不设基础层；入门概念（Transformer、KV 缓存）由 S20 承担，本系列从"推理工程"切入。
1. 一句话结论
推理成本由两个阶段、两个指标、两笔账决定：prefill 决定 TTFT（算力账），decode 决定 TPOT（带宽账），MoE 决定"参数很大但每次只算一小部分"（显存账）。 三个账算不清，任何优化都只是猜。
| 概念 | 一句话 | 决定什么 |
|---|---|---|
| prefill | 把输入 token 一次性算完、生成 KV 与首个 token | TTFT（首 token 延迟） |
| decode | 基于已有 KV 逐 token 生成 | TPOT（后续每 token 时间） |
| MoE | 门控选少数专家参与计算（稀疏激活） | 参数规模 vs 单次算力 |
2. 六个方向与"一年十倍"的背景（§1）
原文的判断：2025 年初 DeepSeek 走红后，竞争"早就不只是模型本身"，训练与推理的工程优化同样关键；并给出六个方向——分布式推理、面向 Tile 的开发语言、RL 训推分离、模型-系统协同设计、Agent Infra、超节点硬件。
| 原文事实 | 可验证性 | 本系列处理 |
|---|---|---|
| "2025 年同参数量模型能力比 2024 年差十倍以上" | 无具体基准，属趋势判断 | 标推断，不作为结论使用 |
| 六个方向的划分 | 来自被引技术帖（朱亦博） | 保留并注明出处 |
| 各方向的论文与项目 | 部分给了链接（DistServe、DeepEP） | 能核实的给链接，其余标 needs_verification |
判据：遇到"能力提升 N 倍"这类说法，先问基准是什么（MMLU？Arena？内部集？）、同参数量是否同推理成本。答不出，就只能当趋势信号。
3. MoE：参数大、算得少（E-S23-002）
原文的定义：MoE = 门控网络 + 若干专家，门控选专家，单个请求只激活少数专家（稀疏激活）。
以 DeepSeek-V3 公开口径为例（原文提到"约 1.4 万个专家"，指所有层的专家总数，不是单层）：
| 指标 | 数值 | 含义 |
|---|---|---|
| 总参数 | 671B | 显存要装下（或用专家并行分片） |
| 每 token 激活 | 37B | 实际算力 ≈ 37B 稠密模型 |
| 专家总数 | 约 1.4 万（256 路由专家 × 61 层量级） | 单卡/单机装不下 → 必须跨机 |
两笔账：
算力账：每 token 计算量 ≈ 2 × 激活参数（前向 FLOPs 近似）
显存账：权重 = 总参数 × 每参数字节（FP8=1B, FP16=2B）
671B × 1B ≈ 671 GB（FP8）→ 至少 8×80GB 才装得下
判据：MoE 的划算来自"显存换算力"——你付出的是"装下全部专家"的显存与跨机通信，换来的是"每 token 只算 37B"。如果请求稀疏度不足（门控把流量集中到少数专家），收益会退化为"更贵的稠密模型"。
4. prefill 与 decode：两种完全不同的负载（§2）
原文的划分：prefill 把输入转成 K、V 并生成首个 token（计算密集型）；decode 基于已有 K、V 逐词生成（访存密集型）。
| 维度 | prefill | decode |
|---|---|---|
| 并行度 | 输入整段并行 | 逐 token 串行 |
| 瓶颈 | GPU 算力（矩阵乘） | 显存带宽（读 KV + 权重） |
| 对应指标 | TTFT | TPOT |
| 典型优化 | 大 batch、chunked prefill、更快的 attention 内核 | KV 量化、PagedAttention、投机解码、更大 batch |
KV 缓存要花多少显存（可直接套的估算）：
每 token KV 字节 = 2（K 和 V）× 层数 × 隐藏维 × 每元素字节
例：80 层、hidden 8192、FP16
= 2 × 80 × 8192 × 2 B = 2.62 MB/token
4k 上下文单请求：2.62 MB × 4096 ≈ 10.7 GB ← 这是"并发上不去"的真凶
判据：并发数 ≈ (显存 − 权重占用) ÷ (每请求 KV)。算出这个比值，你就知道为什么"加卡"有时无效——瓶颈在 KV，不在算力。
5. TTFT / TPOT 怎么测（E-S23-001）
原文只给了定义（TTFT = 首个 token 响应时间；TPOT = 后续平均 token 生成时间），这里补上测量口径：
# 用流式响应测 TTFT 与 TPOT（curl 的 time_starttransfer 近似 TTFT）
curl -sN -o /tmp/stream.txt -w "ttft=%{time_starttransfer}\n" \
-H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
-d '{"model":"MODEL","stream":true,"messages":[{"role":"user","content":"写 200 字的技术说明"}]}' \
"$BASE/chat/completions"
# TPOT ≈ (总时长 − TTFT) ÷ (输出 token 数 − 1)
| 指标 | 采样方式 | 常见误用 |
|---|---|---|
| TTFT | 首字节/首 token 时间，取 P50/P95 | 用非流式总时长当 TTFT |
| TPOT | 输出 token 数 ÷ 生成时长（去掉首 token） | 用"字符数"当 token 数 |
| 吞吐 | 总输出 token ÷ 总时长（含并发） | 单请求吞吐冒充系统吞吐 |
判据：报指标必须带"并发数 + 输入长度 + 输出长度"。缺任一项，两个数字不可比。
6. 常见误区
| 误区 | 纠正 |
|---|---|
| "MoE 比稠密模型便宜" | 只在显存充足 + 请求稀疏度足够时便宜；否则更贵 |
| "TTFT 高就是模型慢" | 先看输入长度（prefill 计算量随输入线性增长）与排队时间 |
| "加卡就能提并发" | 并发受 KV 显存限制；先算 §4 的比值 |
| "用总时长衡量体验" | 交互体验由 TTFT 决定，长输出的总时长不可避免 |
7. 自测
- 你的服务报的"延迟 800ms"，是 TTFT 还是总时长？带并发数吗？
- 用 §4 的公式算一次：你的模型单请求 8k 上下文要多少 KV 显存？
- 你的 MoE 服务里，门控的专家分布是否严重偏斜？偏斜时算力账会怎么变？
8. 下一篇
S23-J02 · 分布式推理：PD 分离、DOPD 与 AFD —— 把 prefill 与 decode 拆到不同设备后，收益从哪来、代价在哪、什么时候不该拆。