推理服务：自建还是调 API，以及 KV Cache 这本账

标准公式（这一行必须背对）：

H_kv 是最容易写错的地方。 不少资料写的是注意力头数，因为它们举的例子是 Llama 2 7B——MHA 模型，两个数恰好相等。换成现代 GQA 模型就会错得离谱：Llama-3.1-8B 是 32 个注意力头但只有 8 个 KV 头，写错就是 4 倍；70B 是 64 比 8，写错就是 8 倍。

代入具体数字（bf16，参数取自官方 config）：

一个值得记住的对照：Llama-3.1-8B 的权重是 16.1 GiB，而它在 128K 上下文下，batch=1 的 KV Cache 就是 16.0 GiB——一条长请求的 KV，顶得上一整份模型权重。

再看显存怎么分（H100 80GB 跑 8B，vLLM 的 gpu_memory_utilization 默认 0.9，截至 2026-08 主线已调到 0.92）：

讲"吞吐塌陷"要用并发数讲，不要用显存 GB 讲。「同一张卡，上下文长 16 倍，并发从 54 掉到 3」这一句比任何显存曲线都有说服力。

判断一个计算卡算力还是卡带宽，看算术强度（从显存搬一个字节能摊到多少次浮点运算）。对 Transformer 的矩阵乘法，它约等于这一步参与计算的 token 总数；H100 的临界值约 295 FLOPs/byte（峰值算力÷HBM 带宽）。

所以"decode 是 memory-bound"是关于 batch size 的陈述，不是 decode 的本质属性。 这是面试里的强分水岭，也直接推出下一层：vLLM 官方明确说投机解码（speculative decoding）只在"中低 QPS、memory-bound"下有效——高 QPS 时 decode 已卡算力，多出的验证开销纯亏。

带宽账可以直接算（H100 的 HBM 带宽 3.35 TB/s，decode 每步要把权重和整个 KV Cache 读一遍）：

batch 一大、上下文一长，权重读取被 KV 读取彻底淹没——此时加算力毫无用处，只有减小 KV 体积或复用 KV 才有效。

这两件事常被混为一谈，其实解决的是两个不同的浪费。

continuous batching 解决"等"的浪费。

源头是 Orca（OSDI 2022），机制是迭代级调度 + 选择性批处理。Anyscale 那篇经典测评给的是相对朴素 static batching 约 8 倍吞吐，但有个必须说出来的条件：增益只在输出长度方差大时成立——如果所有请求输出长度都差不多，static batching 本来也没浪费多少。

PagedAttention 解决"占"的浪费。 论文（SOSP 2023）测出当时系统里真正存住 token 状态的显存只占 20.4%–38.2%，其余是三类浪费：为未来生成预留的槽位、按最大长度分配的内部碎片、分配器造成的外部碎片。分页后官方博客的说法是浪费降到"低于 4%"。

报倍数之前必须先问"跟谁比"，这是这道题最有效的过滤器：

张口就是"vLLM 快 24 倍"的人，等于承认自己没看过论文正文。

一个 2026 年的反转（截至 2026-08）。 vLLM 在 v0.25.0（2026-07-11）的 release notes 里写着「PagedAttention has been removed」——那份 V0 时代手写的 paged_attention_*.cu 内核确实被删了，因为 FlashAttention / FlashInfer 生态里的 paged 变体更快。但分块 KV 管理机制完全健在（block_pool、kv_cache_manager、block_table 全都在），只是改由上游注意力库消费 block table。准确的说法是：概念赢了并成为行业地基，那份专用内核输给了上游生态。 说"vLLM 不用 PagedAttention 了"是错的。

DistServe 给了最好用的例子：系统 throughput 是 10 rps，但只有 3 rps 落在延迟约束内，goodput 就是 3——你按 10 rps 付了 GPU 的钱，只交付了 3 rps，有效成本是账面的 3.3 倍。

而 throughput 与延迟之间只有一个旋钮：batch size。

所以唯一正确的优化目标是 goodput：它把延迟约束内生化，逼你在 SLO 边界上找最大 batch，而不是无脑推吞吐或压延迟。NVIDIA 的 AIPerf 已支持直接测，可同时对 TTFT 和 ITL 设阈值。

别一上来算单价，真正决定结论的是这四条：

最容易被漏掉的是最后一条。 自建的隐性成本不是卡钱，是"有人得懂这个"——开头那个故障里两次试错的人力成本，够买很久的 API。

算账的三条硬判据：

1. 用 goodput 而不是 throughput 折算单位成本。峰值吞吐除以 SLO 内的达标率，才是你真正能卖出去的量。
2. 算利用率，别算峰值。一张卡包月的钱是固定的，跑 20% 和跑 80% 一样贵；API 按 token 计费，天然只为用掉的部分付钱——这是 API 最被低估的优势。
3. 自建要打平的不是 API 的标价，是打完折之后的价：批处理四家一律五折、prompt 缓存命中是输入价的 0.1 倍（详见 T6-4）。

2026 年功能集已高度趋同——continuous batching、分块 KV、前缀缓存、chunked prefill、投机解码、P/D 分离三家都有。选型看的是别的：

两个容易过时的认知要更正：

• "TensorRT-LLM 必须提前 build engine、换模型要重编译"是 2023–2024 的老答案。 截至 2026-08，官方主推的是 PyTorch-native 架构 + trtllm-serve。
• vLLM 与 SGLang 的前缀缓存差别不在"有没有"，在"调度器会不会为命中率重排请求"。 vLLM 是哈希索引 + LRU、调度默认 FCFS；SGLang 用基数树，把"最长共享前缀优先"做成一等公民并证明了最优性。

别问"谁更快"。 三家的相对性能完全取决于你自己的输入输出长度分布、并发度和 SLO，只能实测。上来就报某个倍数，是只读过没做过的最明显信号。

KV 驱逐为什么是这一章最值得讲的"反向判断"：

1. 生产用 FlashAttention，它从不把注意力分数矩阵写进显存——驱逐方法想看的打分信号根本不存在。参考实现是靠退回 eager attention 绕过的，这在生产里等于不可用。
2. 分页布局下，驱逐 90% 的 token 几乎释放不了显存：幸存者散落在几乎每个 block 里，块不空就不回收。
3. 现有 benchmark 普遍是"问题已拼进上下文之后"才压缩，真实部署却是"先压缩、后来问题"。在公平设定下，部署最广的 SnapKV 平均输给"保留开头 + 最近窗口"这个最朴素的基线。

• max_num_batched_tokens 是跷跷板：小（如 2048）ITL 好、TTFT 差；大（>8192）吞吐好。想清楚你在优化哪个。
• 看到 preemption 警告就别再调延迟了，先看 KV Cache 占用率——那是显存不够，不是调度问题。
• 前缀缓存在 vLLM V1 默认开启，命中率为 0 时吞吐损失也小于 1%；但分布式下真正的杀手是路由——负载均衡器把同前缀请求打散到不同实例，缓存局部性就没了。
• 别把"KV 卸载"和旧的"GPU↔CPU swap"搞混：后者为处理抢占而生、在 vLLM V1 已被移除（抢占直接重算），前者是为提高跨请求命中率。

这三道题通常连着问，构成一条从工程决策到底层机制的下沉链：

1. 决策题（Q6-01）："你们自己部署还是调 API？账怎么算的？"——看你有没有算过账。
2. 下沉到引擎（Q6-02）："自建用的什么？vLLM 为什么快？"——看你是照文档起了个服务，还是知道它在优化什么。
3. 落到瓶颈（Q6-03）："上下文拉长之后遇到过什么问题？"——看你有没有把服务跑到过极限。

链条上任何一环答得空，后面就不问了。

Q6-01（自建 vs API）：别先报单价。先说"这笔账取决于四件事"——利用率、数据主权、模型控制、团队能力，再落到自己的场景。收尾一定要有一句："我们按 goodput 折算单位成本，不是按压测峰值。"

Q6-02（vLLM 为什么快）：先拆成两件事——continuous batching 解决"等"的浪费，PagedAttention 解决"占"的浪费，报数字时主动说"跟谁比"。想拿满分就补上 2026 的现状：内核删了、机制还在。

Q6-03（KV Cache）：先给公式并强调是 KV 头数，再分两段答瓶颈（容量限制并发数、带宽限制单步延迟），最后用"同一张卡 8K 并发 54 条、128K 只剩 3 条"这个对照收尾。

什么回答暴露只读过：

• 公式里写成"注意力头数"，或者根本不知道 GQA 会改这个数
• "vLLM 快 24 倍"——不问跟谁比
• 把"长上下文慢"一律归因为注意力的平方复杂度，然后给出"加卡加算力"的扩容方案
• 说"我们上了 H2O / SnapKV 压 KV，省了 90% 显存"
• 谈自建 vs API 只报单价对比，不提利用率
• 把 P/D 分离说成"提升吞吐的优化"（官方文档原话是它不提升吞吐，买的是 TTFT 与 ITL 可独立调）

什么证明真做过：

• 能脱口而出"Llama-3.1-8B 每 token 128 KB、70B 每 token 320 KB"，并解释为什么 8B 是 4 倍压缩而 70B 是 8 倍
• 把瓶颈拆成 prefill 卡算力、decode 卡带宽，并指出**"decode 卡带宽"是关于 batch size 的陈述，并发推到 500 以上它也会变成卡算力**
• 用并发数而不是显存 GB 来讲吞吐塌陷
• 主动区分 throughput 和 goodput，并算过"有效成本是账面的几倍"
• 说得出 FP8 KV 的盈亏平衡线（约 7000 token）——"知道它什么时候不该开"比"知道它能省一半"值钱
• 谈引擎选型时拒绝报倍数，改成"取决于你的输入输出长度分布，得实测"