大模型推理优化：让AI又快又便宜的十个思路

大模型很强，但也很贵。

一个中等规模的大模型，每次推理需要消耗几十亿次浮点运算。如果你的系统每天要处理百万级的请求，GPU 的账单会让你怀疑人生。更糟糕的是，用户的耐心是有限的。一个需要等五秒才回复的 AI 助手，用户用两次就卸载了。

所以，推理优化不是一个可选项，而是大模型从实验室走向生产环境的必经之路。

为什么大模型推理慢

要优化推理速度，首先要理解它为什么慢。

大模型的推理分为两个阶段。第一个阶段叫做"预填充"，处理用户的输入。这个阶段是计算密集的，需要大量矩阵运算。第二个阶段叫做"解码"，逐个生成输出 token。这个阶段是内存带宽密集的，因为每个 token 的生成都需要读取整个模型的参数。

对于一个 70B 参数的模型，模型本身就需要 140GB 的存储（以 FP16 计算）。每次生成一个 token，都需要把这 140GB 的数据从显存读取一遍。GPU 的显存带宽就成了瓶颈。

这就是为什么大模型推理慢的根本原因：模型太大，显存带宽有限。

量化：用精度换速度

最直接的优化方式是降低模型参数的精度。原始模型通常使用 FP16（16 位浮点数），每个参数占 2 字节。如果把它量化成 INT8（8 位整数），每个参数只占 1 字节，模型大小减半，推理速度也接近翻倍。

更激进的量化可以到 INT4 甚至更低。4bit 量化让 70B 模型缩小到 35GB 以内，可以在一张消费级 GPU 上运行。

量化的代价是精度损失。参数精度降低后，模型的输出质量会下降。但好的量化算法能把这个损失控制在可接受的范围内。对于很多应用场景，4bit 量化的模型和原始模型的差异几乎察觉不到。

GPTQ、AWQ、GGUF 是目前最流行的量化方案。它们各有侧重：GPTQ 量化速度快，AWQ 保持精度好，GGUF 兼容 CPU 推理。

KV Cache 优化

大模型推理中的一个重要优化是 KV Cache。在生成每个新 token 时，模型需要"回顾"之前所有的 token。如果每次都重新计算，成本会随着序列长度急剧增长。

KV Cache 的做法是把之前 token 的中间计算结果缓存起来，生成新 token 时直接复用，不需要重新计算。这是用显存空间换计算时间的策略。

但 KV Cache 本身也会消耗大量显存。一个长对话的 KV Cache 可能比模型本身还大。各种优化方案被提出来解决这个问题：PagedAttention 把 KV Cache 分成固定大小的页，按需分配，避免了预分配的浪费；GQA（分组查询注意力）通过减少 Key-Value 头的数量来压缩 KV Cache 的大小。

批处理优化

在生产环境中，同时会有多个用户发请求。批处理是提高 GPU 利用率的关键。

但大模型的批处理和传统模型不同。不同用户的请求长度不同、生成的 token 数量也不同，如果等所有请求都完成才处理下一批，短请求会被长请求拖慢。

连续批处理解决了这个问题。它不等所有请求完成，而是随时可以加入新请求、随时可以移除已完成的请求。这样 GPU 始终保持忙碌状态，利用率大幅提高。

vLLM 是连续批处理的代表性实现。它把 GPU 的吞吐量提升了好几倍，已经成为大模型推理服务的标配。

模型架构优化

除了运行时的优化，模型架构本身也可以针对推理进行优化。

混合专家模型（MoE）是目前最有效的架构优化。它不是激活整个模型的所有参数，而是根据输入只激活一部分"专家"。这样虽然模型的总参数量很大，但每次推理的计算量却小得多。

Flash Attention 是另一种架构级别的优化。它重新组织了注意力计算的过程，大幅减少了显存的访问次数。对于长序列输入，Flash Attention 的加速效果尤其明显。

投机解码是最近兴起的一种技术。它用一个小模型快速生成候选 token，然后用大模型一次性验证。如果小模型猜对了（大多数时候会猜对），就跳过了大模型的逐 token 生成过程。

硬件层面的优化

软件优化之外，硬件的选择也很重要。

不同 GPU 的特性差异很大。A100 擅长大规模计算，H100 在推理场景下有专门的优化，消费级的 4090 在性价比上有独特优势。选择适合你工作负载的硬件，比盲目追求高端 GPU 更重要。

推理芯片是另一个值得关注的方向。专门针对推理设计的芯片，去掉了训练不需要的特性，专注于推理场景的效率。Groq、Cerebras 等公司的推理芯片在特定场景下展现出了惊人的性能。

边缘推理也有独特的优化需求。在手机、嵌入式设备上运行大模型，需要更激进的量化、更小的模型、更高效的推理引擎。MediaPipe、Core ML 等框架针对移动端做了大量优化。

缓存与预测

有些优化不是技术层面的，而是策略层面的。

语义缓存是一种聪明的做法。如果两个用户的问题意思相近（即使措辞不同），可以直接返回缓存的回答，不需要重新推理。这在客服等场景下效果很好，因为用户的很多问题是重复的。

预计算也是一种策略。对于可以预测的请求（比如每天早上 9 点的日报生成请求），可以提前启动推理，用户请求到达时直接返回结果。

请求路由也是一种优化。简单的请求用小模型处理，复杂的请求用大模型处理。这样既能保证质量，又能控制成本。

我的建议

对于正在部署大模型的团队，我的建议是按优先级依次尝试以下优化。

首先上量化，这是投入产出比最高的优化。从 INT8 量化开始，如果精度可以接受，再尝试 4bit 量化。

然后上连续批处理，用 vLLM 或者类似工具替代简单的推理服务。这一步通常能把吞吐量提升好几倍。

接着考虑模型选择。如果你的场景不需要最强的模型，用一个小模型可能就够了。70B 模型的推理成本是 7B 模型的十倍，但如果 7B 模型能完成你的任务，就没有必要用 70B。

最后考虑硬件优化。根据你的工作负载特征选择合适的 GPU，必要时考虑推理专用芯片。

推理优化是一个持续的过程，不是一次性的工作。随着模型的更新、流量的变化、新技术的出现，优化策略也需要持续调整。