小白也能看懂的大模型推理优化：为什么AI回复能这么快

麦庐最后的光

11人浏览 · 2026-06-14 07:00:00

麦庐最后的光 · 2026-06-14 07:00:00 发布

系列文章：AI大模型知识体系 | 第四篇

引言

你有没有好奇过：一个 70B（700 亿）参数的大模型，光模型文件就有上百 GB，凭什么你问它一个问题，它几秒钟就能开始回复你？

直觉上，这就像让一个人把整座图书馆的书全读完再回答你。但实际上，AI 不仅读得快，写得也快，还能同时跟成千上万人聊天。这背后，是一系列推理优化技术在默默发力。今天我们来逐一拆解。

一、大模型推理的两大阶段：Prefill 和 Decode

大模型回答你的问题，其实分两步走。我们可以把它想象成考试答题：

第一步：Prefill —— 审题

当你输入一段 Prompt，模型首先要理解你的整段话。这一步叫做 Prefill（预填充）。

Prefill 一次性把所有输入都看完，就像考生先把题目通读一遍、理解题意。因为是一起处理的，GPU 的并行计算能力被充分利用，速度很快。

第二步：Decode —— 一个字一个字写答案

审完题后，模型开始生成回答。关键在于：它是一个字（Token）一个字往外蹦的，每生成一个字都要做一次完整的模型计算。这一步叫做 Decode（解码）。

Decode 就像学生一个字一个字地写答案——每一步只处理一个字，GPU 的大量计算单元其实都在"闲着等"。

推理优化的核心挑战就是：让审题更快，让写答案不再磨蹭。接下来的所有技术基本都围绕这两点展开。

二、KV Cache：最重要的加速手段

做数学题时，你会把中间结果写在草稿纸上

想象你在做一道复杂的数学大题。每算出一个中间结果，你会把它写在草稿纸上，后面用到的时候直接看草稿纸就好，而不用从头再算一遍。

KV Cache 就是这个"草稿纸"。

在 Decode 阶段，模型每生成一个新 Token 都需要用到之前所有 Token 的 Key 和 Value。如果没有 KV Cache，每生成一个字，都要把之前所有内容重新"算一遍"——就像每写一个字都要重新审一遍题。

有了 KV Cache，模型把已算过的 Key 和 Value 缓存起来。生成下一个字时，只需算新字的 Query，直接去"草稿纸"上查结果即可。

没有 KV Cache vs 有 KV Cache

	没有 KV Cache	有 KV Cache
生成第 10 个字	重新计算前 9 个字的 K、V	只算第 10 个字的 Q，复用前 9 个字的 K、V
计算量	随序列长度平方级增长	随序列长度线性增长
实际感受	越往后越慢，根本不可用	每个字的生成速度基本稳定

KV Cache 的显存代价

当然，"草稿纸"也要占显存。序列越长、并发用户越多，占用越大。举个例子：70B 模型在上下文 4096 时，单用户的 KV Cache 约 10.7 GB；同时服务 32 个用户就要 340 多 GB——比模型本身还大。这也是为什么 vLLM 提出了 PagedAttention 来更高效地管理 KV Cache 显存。

三、模型量化：把大模型"压缩"一下

就像图片压缩一样

你肯定经历过：一张原图 10 MB 的 PNG，压缩成 JPG 之后只有 500 KB，但肉眼几乎看不出区别。模型量化的思路一模一样——用更少的位数来存储模型权重，换取更小的体积和更快的速度。

模型权重默认用 FP16（半精度浮点，16 位） 存储。量化就是把精度降低：

INT8（8 位整数）：体积缩小到原来的 1/2，就像 PNG 压缩成高质量 JPG。
INT4（4 位整数）：体积缩小到原来的 1/4，就像压缩成更小尺寸的图片，细节稍有损失但整体还行。

一个 70B 参数的模型，FP16 下需要约 140 GB 显存；量化到 INT4 之后，只需要约 35 GB——直接从"需要两张 A100"变成"一张卡就能装下"。

量化会不会变笨？

这是大家最关心的问题。简单回答：大部分场景下，几乎感觉不到差别。

以主流的 AWQ、GPTQ 等方法为例，它们会智能地保护对输出影响最大的"关键权重"，只在不重要的权重上压缩。实测 INT4 量化后，常规对话和文本生成的质量损失通常在 1% 以内。但在数学推理、复杂代码生成等高精度任务上，建议做量化前后的对比测试。

四、Flash Attention：让注意力计算更快

Attention（注意力机制）是 Transformer 的核心，但它的计算有一个问题：需要频繁地在 GPU 的**显存（HBM）和高速缓存（SRAM）**之间搬运数据。

打个比方：你在一间很大的仓库（显存）里存放了所有材料，但你的工作台（SRAM）很小。每次做东西，你都得跑进仓库拿材料、搬到工作台上加工、再把成品搬回仓库。跑来跑去的时间，比实际干活的时间还长。

Flash Attention 的核心思路就是：减少来回搬运的次数。它把任务拆成小块，每次搬一小批到工作台上全部做完再搬回去。计算量没变，但搬运次数大幅减少。

效果非常显著：4K 上下文下 Prefill 快 2~3 倍，16K 长文本下加速 5~8 倍，同时大幅降低显存占用。可以说 Flash Attention 是近年来性价比最高的推理优化技术。

五、投机解码：小助理先写草稿，老板来审核

Decode 阶段最大的问题是一个字一个字往外蹦，太慢了。有没有办法一次多蹦几个字？

投机解码（Speculative Decoding） 的思路特别像这样一个场景：

老板（大模型）很忙，每个字都要亲自写太费时间。于是让一个小助理（小模型）先把草稿写好，比如一口气写 5 个字。然后老板花很少的时间扫一眼草稿——"前 3 个字没问题，第 4 个不对"——于是采纳前 3 个，从第 4 个开始让小助理重写。

这样做的好处是：老板大部分时间只需要审核，而不是一个字一个字地写。审核 5 个字的工作量远小于写 5 个字，因为审核可以并行处理。

实际应用中，小模型通常与大模型同系列但参数小很多（如用 LLaMA-7B 给 LLaMA-70B 当"小助理"）。简单任务上采纳率可达 70%~90%，加速 2~3 倍；复杂任务也有 1.5~2 倍加速。

而且投机解码有数学保证：输出分布与直接用大模型完全一致，质量零损失。

六、批处理（Batching）：同时服务多个用户

前面说过，Decode 阶段 GPU 的计算能力大量闲置。那既然一个人用不完，让多个人一起用不就行了？

这就是批处理（Batching） 的思想：把多个用户的请求合并到一起，让 GPU 一次性处理。

最朴素的做法是 Static Batching：凑一批请求一起处理，全部生成完再返回。问题是有的请求只需 50 字，有的要 500 字——短的先做完只能干等，GPU 白白浪费。

更聪明的做法是 Continuous Batching（连续批处理）：每生成一个字时动态检查——做完的立刻"送走"，新来的随时"插进来"，GPU 始终满载。

Static Batching:     请求A ████████░░░░░░░░  (做完干等)
                     请求B ████████████████  (最长决定结束时间)

Continuous Batching: 请求A ████████ → 请求C ████████ → 请求E ██████
                     请求B ████████████████ → 请求D ████████
                     (GPU 始终满载，无缝衔接)

Continuous Batching 是目前所有主流推理框架的标配功能，也是实现高并发在线服务的基础。

七、主流推理框架怎么选？

了解了上面的优化技术，最后来看看实际部署时该选哪个框架。以下是三个最常见的选择：

特性	vLLM	Ollama	TensorRT-LLM
定位	高性能服务端推理	本地一键跑模型	NVIDIA 极致性能优化
上手难度	中等（pip install）	极简（一行命令）	较高（需编译引擎）
适合谁	需要部署 API 服务的开发者	想在本地电脑上体验大模型的个人用户	追求极致吞吐的生产环境
核心优势	PagedAttention 显存管理高效，并发能力强	开箱即用，支持 GGUF 量化，Mac/Windows/Linux 全平台	深度 CUDA 优化，同等硬件下性能最优
量化支持	GPTQ、AWQ、FP8	GGUF（多种量化）	INT4/INT8、FP8、SmoothQuant
并发能力	强（Continuous Batching + PagedAttention）	弱（主要面向单用户）	最强（In-flight Batching）