把算力花在刀刃上：大模型推理优化深度解析

摘要：当模型能力趋于接近，"单位智能成本"就成了 AI 应用繁荣的真正变量。本文从大模型推理的两个阶段讲起，逐一拆解 KV Cache、PagedAttention、Continuous Batching、投机解码、PD 分离与量化等核心优化技术的原理与适用场景，并给出一套可以直接落地的优化清单。

一、为什么推理优化值得单独写一篇

同样一个开源模型、同样的显卡，不同团队的推理成本可以相差三到十倍。这个差距不是来自什么黑科技，而是来自对推理过程的理解深度。

对大多数公司来说，训练一个大模型是天方夜谭，但推理是每天都发生的支出。模型上线一天，账单就滚动一天。推理成本每降低一半，意味着原来不敢上线的场景可以上线了、原来收费的功能可以免费了。所以有人说：AI Infra 的优化能力，就是 AI 时代的产品能力。

这篇文章不预设你懂 CUDA，只需要你理解 Transformer 的基本结构（自注意力 + 自回归生成）。我们从"钱到底花在哪"说起。

二、先搞清楚问题：推理的两个阶段，两种性格

一次大模型推理请求，由两个截然不同的阶段组成：

• Prefill（预填充）：处理用户输入的全部 Prompt，一次性并行计算所有 Token 的表示，生成第一个输出 Token 和整段 KV Cache。
• Decode（解码）：逐个 Token 往外蹦，每生成一个 Token 都要对之前的全部历史做一遍注意力计算。

两个阶段的资源画像完全相反，这是理解一切优化的起点：

为什么 Decode 是访存密集？因为每生成一个 Token，都要把全部模型权重和整段 KV Cache 从显存搬到计算单元，搬一次却只算一个 Token——就像开一辆大卡车，跑一趟只送一封信。显存带宽，而不是算力，是 Decode 阶段的真正天花板。

理解了这一点，后面所有优化技术的动机就都清晰了：要么少搬数据，要么一趟多送几封信，要么把两种性格的工作分开安排。

三、显存去哪了：KV Cache 的数学

Decode 慢，一半的根源在 KV Cache。先算一笔账。

每个 Token 的 KV Cache 大小有一个简单的公式：

每 Token KV 显存
  = 2 (K和V) × 层数 × KV头数 × 每头维度 × 每元素字节数

以一个典型的 7B 模型为例（32 层、32 个注意力头、每头 128 维、FP16 存储，即每元素 2 字节）：

kv_per_token = 2 * 32 * 32 * 128 * 2   # = 524,288 B ≈ 512 KB

每个 Token 仅 KV Cache 就要 512 KB。乘一下上下文长度：

• 4K 上下文：约 2 GB —— 和整个模型权重（约 14 GB）相比还能接受；
• 32K 上下文：约 16 GB —— 比模型本身还大；
• 高并发场景：上面两个数还要再乘以并发数。

结论很残酷：**长上下文时代，显存的敌人不是模型，是 KV Cache。**顺便说一句，现代模型普遍采用 GQA/MQA（分组查询注意力），让多个注意力头共享一组 KV 头，公式里的"KV头数"远小于"注意力头数"，KV Cache 已经缩小了好几倍——这是架构层面为推理做的让步。即便如此，它依然是吃显存的大户。

四、PagedAttention：向操作系统借的智慧

早期推理引擎为每个请求预留一整块连续显存放 KV Cache，按最大长度分配。于是两个经典的显存问题出现了：内部碎片（申请 2K 长度、实际只用了 300）和外部碎片（显存不连续，凑不出一块大的）。实测显存利用率往往只有 20%~40%。

PagedAttention 的做法和操作系统的虚拟内存分页如出一辙：把 KV Cache 切成固定大小的"块"（Block，比如 16 个 Token 一块），按需分配，用一张页表把逻辑位置映射到物理块。这一改动带来三个收益：

1. 碎片几乎归零：显存利用率从三四成提到九成以上，同等显存能容纳的并发数直接翻倍以上；
2. Prefix Caching 成为可能：多个请求如果共享同一段前缀（最典型的是同一个系统提示词），它们的 KV 块可以直接物理共享，公共部分只算一次、只存一份。多轮对话场景下，前缀命中率经常过半——等于一大半 Token 的 Prefill 白送；
3. 为 PD 分离铺路：KV Cache 既是分页的，就可以序列化、传输、在另一台机器上重建，这是后面"分离部署"的基础。

这是我认为推理优化领域最优雅的一个设计：不发明新东西，把操作系统六十年前就验证过的思想搬过来。

五、Continuous Batching：别让整队人等一个人

传统的静态批处理（Static Batching）把一批请求凑齐、一起推理、全部完成再放下一批。问题是输出长度参差不齐：有人 10 个 Token 就完了，有人要 2000 个。短任务结束后它的资源就空转，整批却要陪最长的那个跑到底。

**Continuous Batching（连续批处理）**把调度粒度从"一个请求"细化到"一个解码步"：每生成一个 Token 后重新调度——完成的请求立刻退出腾位子，排队的新请求立刻加入。GPU 永远满负荷，吞吐量提升常常是数倍级别。

它的搭档是 Chunked Prefill：一条超长 Prompt 的 Prefill 可能耗时数百毫秒到数秒，期间会阻塞同批所有请求的 Decode。把长 Prefill 切成若干小块，与 Decode 步交错执行，首字延迟和每字延迟的抖动都会显著改善。

这两个技术如今已是主流推理引擎的默认行为。你不需要做什么，但需要知道它们的存在——当你发现吞吐异常时，先确认这些基础调度特性是不是被关掉了。

六、投机解码：让大模型"抄小模型的作业"

前面说过，Decode 每步只生成一个 Token，算力大量闲置。**投机解码（Speculative Decoding）**把这个浪费利用了起来：

1. 一个便宜的小模型（草稿模型）先一口气起草 k 个 Token；
2. 大模型对这 k 个草稿并行验证——验证 k 个 Token 的计算量约等于自己生成一个 Token，因为验证是并行的；
3. 接受正确的草稿，从第一个被拒绝的位置重新生成。

关键承诺是：通过精心设计的接受-拒绝机制，最终输出分布与纯大模型生成完全一致——这是无损加速，不是用质量换速度。

实际效果取决于草稿模型的"命中率"：常见的搭配下，草稿接受率能达到 70%~80%，整体解码速度提升 2~3 倍。工程上的变体有很多——用模型自身的浅层做草稿、一次草稿多个分支、模型自带多个预测头等——但核心思想都是同一个：用便宜的并行验证，替代昂贵的串行生成。

适用性提醒：投机解码在输出"高可预测"的场景（代码补全、模板文本）收益最大；在高度发散的创意写作上，接受率下降，收益缩水。它不是免费午餐，但午餐确实很便宜。

七、PD 分离：让"急性子"和"慢性子"分开住

把第二节的表再看一遍：Prefill 是计算密集，Decode 是访存密集。混部在一起会发生什么？

一条长 Prompt 的 Prefill 一来，会把 GPU 的计算资源占满，同机所有正在 Decode 的请求全部卡顿——用户看到的现象就是"打着字，突然卡住两秒"。资源画像互补的两个阶段，放在同一张卡上却互相拖累。

**PD 分离（Prefill/Decode Disaggregation）**的思路干脆利落：

• Prefill 集群和 Decode 集群分开部署，各自按自己的资源画像选型与扩缩容；
• Prefill 完成后，把生成的 KV Cache 通过高速网络（RDMA 一类）传输给 Decode 实例；
• 两边互不干扰，各自把利用率推到极限。

代价是 KV Cache 的传输开销和运维复杂度——多了一层架构，就多了一类故障点。所以 PD 分离不是银弹，而是一个规模决策：在高并发、长上下文、延迟敏感（SLO 严格）的大规模服务上，它是主流选择；小规模场景，Chunked Prefill 加好的调度通常就够了。

八、量化：把数字变"粗"，把成本变细

量化的逻辑朴素到近乎粗暴：权重和缓存放进显存的数字，不必都用 16 位浮点存。

• 权重量化（W4A16 / W8A8）：把模型权重压到 4 bit 或 8 bit。基于校准数据的激活感知方法（GPTQ、AWQ 一类思路）能识别出哪些层对精度敏感，重点保护。效果：7B 模型从 14 GB 压到 7 GB 甚至 3.5 GB——显存省下的每一份，都变成了可以容纳的并发；
• FP8：新一代硬件原生支持的 8 位浮点，训练和推理都能用，几乎是当前精度与效率的默认平衡点；
• KV Cache 量化：把 KV Cache 也压到 8 bit，KV 显存直接减半——对长上下文场景是救命稻草。

工程上的唯一忠告：**量化不是无损的，必须带评测上线。**用你的真实业务样本测 perplexity 偏移和下游任务指标，重点盯数学、代码、长文本推理这几类敏感任务。常见策略是混合精度——绝大多数层用低精度，少数敏感层保持高精度。

九、还有一群无名英雄

除了上面这些"明星技术"，还有一排默默干活的优化，简单列出：

• FlashAttention：通过分块计算和在线 Softmax，避免把巨大的注意力矩阵写回显存再读出来，显存占用从平方级降到线性级，长上下文下速度与显存双收益；
• 算子融合与图编译：把一串小算子融合成大算子，减少显存往返和核启动开销；
• 语义缓存：请求层优化——相似的问题（“北京天气怎么样"vs"今天北京会下雨吗”）直接命中缓存返回，连模型都不用进。对 FAQ 型业务命中率可观。

十、把牌打全：一道成本演算题

单看每项技术都有百分之几十的收益，组合起来是什么量级？拿一个典型场景粗算一下（数字为示意，具体取决于负载特征）：

不追求每一项都拿满，一个中规中矩的组合拳下来，整体推理成本降到基线的四分之一到十分之一在实践中完全可达。这就是为什么开头说，同样的模型、同样的卡，不同团队的成本差三到十倍。

十一、落地清单：从今天开始做的八件事

1. 先建基线再谈优化：盯住四个指标——首字延迟 TTFT、每字延迟 TPOT、吞吐 Tokens/s、每百万 Token 成本。没有基线，一切优化都是玄学。
2. 确认现代推理引擎的默认特性全开着：PagedAttention、连续批处理、Chunked Prefill——这些是免费午餐。
3. 把系统提示词和 Few-shot 样例做成全局共享前缀，让 Prefix Caching 吃饱。
4. 上线任何量化前，先跑业务评测集，敏感任务重点回归。
5. 区分两类流量：交互式请求（延迟敏感）和离线批量任务（成本敏感）分开部署，离线的用更大批量、更激进的量化。
6. 输出可预测的高频场景（代码补全、结构化抽取）上投机解码，收益立竿见影。
7. 规模到了再上 PD 分离，别为了架构图好看引入复杂度。
8. 持续回归：模型、引擎、硬件任何一方升级，都重跑一遍基线——性能是会悄悄烂掉的。

十二、结语

大模型推理优化这门手艺，说到底是一门"搬运的艺术"：数据在显存和计算单元之间搬运的每一次浪费，最终都会出现在你的云账单上。而几乎所有伟大的优化——分页、批处理、投机、分离——都在回答同一个问题：

能不能让每一次昂贵的数据搬运，多干一点活？

模型架构的革新会让人眼花缭乱，但这条主线在可预见的未来不会变。把每一分算力花在刀刃上，是 AI 应用时代最朴素、也最持久的竞争力。

本文是"前沿 AI 技术"系列的第二篇，第一篇为《从"会聊天"到"会干活"：2026 年前沿 AI 的五条技术主线》。欢迎在评论区交流你遇到的推理性能问题。