第 1 章 问题现场：大模型推理为什么又慢又贵

第 1 章 · 问题现场：大模型推理为什么又慢又贵

章节摘要：本章跟着一条追因线走——从一条卡顿的生成请求出发，拆出推理成本到底花在哪几步，建立吞吐、延迟、TTFT 与显存天花板的指标语言，最后落到 vLLM 的解题思路总览。读完本章，你会拿到全册用来"说话"的所有工具：看得懂压测数字，说得出瓶颈位置，画得出问题与解法的对应关系。

一条主线

我们的主线是一个再普通不过的线上场景：产品要求把一个开源大模型架在自己租的显卡上，对外提供对话能力。第一个版本用最直觉的方式部署——Hugging Face Transformers 起一个进程，一个请求进来，模型一个字一个字往外蹦。测试环境里单发请求一切正常；一上流量，吞吐上不去、排队越排越长、账单按 token 计费贵得离谱。

追因从这里开始：慢和贵，究竟发生在哪一步？是矩阵乘法算得太慢？是显存不够？还是请求组织方式有问题？本章沿途会反复回到这条主线上取证据，第 2 章之后每解开一层，都会让主线场景里的某个数字发生可见的变化。

值得先交代一个认知拐点：直觉会把"推理慢"归因于"模型大、算力弱"。但真实世界里，推理服务的瓶颈往往不在计算本身，而在显存的容量与组织方式、请求的调度粒度、重复计算的浪费上。这三件事分别对应本册的三大主线章节——这也是为什么全册的章节顺序是"显存困境 → PagedAttention → 连续批处理"，而不是按功能模块罗列。

沿途站点

本章分三站：

• 1.1 贵与慢发生在哪一步：把一次生成请求拆成 prefill 与 decode 两个阶段，看到 decode 阶段"每出一个字都要搬运全部模型权重和上下文状态"的物理事实，定位第一处堵点。
• 1.2 指标先行：建立吞吐、延迟、TTFT、TBT 的准确定义与相互关系，并引出"显存天花板"——它决定了同时能服务多少条请求，是后面所有优化动作的靶子。
• 1.3 vLLM 的解题思路：把问题清单与 vLLM 的机制清单对上号，给出全册的问题-解法对应图，交代每个机制解决哪个问题、代价是什么。

拐点与结论

本章最关键的认知转折是视角的切换：从"让单次计算更快"转向"让整块显存和整段时间被更充分地利用"。单次计算的优化空间受限于硬件物理规律，而利用率上的浪费动辄是数倍之差——传统部署方式下显存有效利用率长期只有三成上下，这意味着同样一张卡，理论上存在把并发能力翻倍的空间，前提是把管理方式换掉。

vLLM 的答案因此不是"更快的算子"这么简单，而是一套组合：用 PagedAttention 重新组织显存，用连续批处理重新组织时间，用前缀缓存与投机解码消灭重复劳动，用量化与并行突破单卡边界。第 1.3 节会给这张总览图，之后每章展开一个机制。

读完你应该

1. 给别人讲清楚 prefill 与 decode 的区别，以及为什么 decode 阶段是"访存受限"的；
2. 面对一组压测数据，准确指出吞吐、TTFT、TBT 分别是多少、意味着什么；
3. 用公式估算一个模型在给定上下文长度下的 KV Cache 显存开销（哪怕手算）；
4. 说出"显存天花板"由哪几个因素决定，以及它如何限制并发请求数；
5. 把"慢、贵、并发低"三个症状分别归因到对应的机制缺口上；
6. 带着问题清单进入第 2 章，而不是把后续章节当成孤立的功能介绍。

下一章的接力

主线场景的疑点排在首位的是显存：GPU 明明有几十 GB 显存，为什么没服务几条请求就报显存不足？第 2 章我们就去翻这本显存账——把 KV Cache 的计算公式逐项拆开，看看预留式分配和碎片是怎么把大半张卡的容量白白锁死的。