AI推理优化深度科普：量化、KV Cache和投机采样，为什么快比准更值钱

上周跟一个做ML的朋友聊天，他说了句让我印象很深的话："现在大家都在卷模型参数，但真正在生产环境里拉开差距的，是推理速度。"

这话没错。GPT-4o发布的时候，大家惊叹的不是它比GPT-4聪明多少，而是它快了多少、便宜了多少。推理效率，已经悄悄成为AI竞争的主战场。

为什么"算得快"比"算得准"更重要？

这听起来有点反直觉。但仔细想想——一个回答准确率98%但需要30秒响应的模型，和一个准确率95%但500毫秒就给你答案的模型，你在实际工作中会用哪个？

大多数场景下，你会选快的那个。

这不是在说精度不重要，而是说：在精度过了某个"够用"的门槛之后，速度和成本变成了更关键的变量。这个规律在工业界已经反复验证过了。

所以过去两年，推理优化这个方向突然变得炙手可热。不是因为大家不想把模型做更聪明，而是"怎么让现有的模型跑得更快、花更少的钱"，这个问题的回报率更高。

最常见的推理优化手段，是量化（Quantization）。

简单说：神经网络的权重通常用32位浮点数（FP32）存储，量化就是把这些数字压缩成更小的格式——16位（FP16）、8位（INT8）、甚至4位（INT4）。

代价是什么？精度会有轻微损失。但在实际测试中，从FP32压到INT8，模型的表现基本感知不出差别，但推理速度可以提升2-4倍，内存占用直接减半。

我们自己在SFD实验室跑本地Ollama的时候，最深的感受就是量化带来的差异。同一个Qwen2.5-32B模型，Q4_K_M量化版本在96GB的Mac Studio上跑得很流畅，但如果你去跑FP16版本，内存直接撑不住。量化不是"凑合用"的方案，很多时候它就是唯一可行的方案。

推理还有另一个大头：KV Cache（键值缓存）。

当模型在生成长文本的时候，它每生成一个token，都需要"回头看"前面所有的内容。如果每次都重新计算，那代价是O(n²)——文本越长，计算量爆炸式增长。

KV Cache的逻辑是：把之前计算过的注意力键值对缓存起来，下次直接读，不用重新算。这个优化在长文本生成场景下效果巨大，响应速度可以提升几倍到十几倍。

问题是，KV Cache本身也很耗内存。当你同时服务很多用户请求的时候，每个请求都要维护自己的Cache，内存压力很快就上来了。这就是为什么现在有一堆研究在搞"KV Cache压缩"和"跨请求KV Cache共享"。

还有一个比较新颖的方向叫投机采样（Speculative Decoding）。

思路有点意思：用一个小模型先快速"猜"接下来的几个token，然后用大模型来"验证"这些猜测对不对。如果猜对了，直接接受，跳过大模型逐token生成的步骤；猜错了，从错的地方重新开始。

因为小模型运行很快，大模型验证多个token的成本又比逐个生成低，整体下来可以把推理速度提升30%-50%，而且输出结果和直接用大模型完全一致。

这个方案的前提是"大部分时候小模型能猜对"，而在实际语言生成场景中，这个命中率确实相当高——因为很多token的续写其实是高度可预测的（"我今天吃了一碗" → 下一个词大概率是某种食物）。

在服务多用户的推理服务里，批处理（Batching）是另一个关键。

早期的推理框架是静态批处理：等凑够一批请求再一起算。问题是有些请求生成得快、有些慢，快的那些在等慢的，GPU资源白白浪费。

连续批处理（Continuous Batching）解决了这个问题：谁生成完了谁就出去，新进来的请求直接插入批次继续跑。vLLM就是把这个做到极致的框架之一，在高并发场景下，吞吐量提升可以达到10倍以上。

最后说一个架构级别的优化：混合专家模型（Mixture of Experts, MoE）。

传统的Dense模型，每次推理都要跑所有参数。MoE的思路是：把模型拆成很多个"专家"子网络，每次推理只激活其中的少数几个（通常是2-8个），由一个路由器来决定用哪几个专家处理当前输入。

Mixtral 8x7B就是典型的MoE架构：总参数看起来有46B，但每次实际运行的只有12-13B，推理成本跟一个13B的Dense模型差不多，但性能接近一个真正的70B模型。

这种"按需激活"的设计，让模型在保持大容量的同时，推理效率大幅提升。

写这篇的时候，我在想一个问题：推理优化这么重要，为什么用户感知却这么弱？

因为大部分优化都发生在"幕后"——用户就是感觉"好像变快了"，并不知道背后发生了什么。

但对于真正在用AI构建产品的人来说，理解这些机制很重要。它决定了你选哪个推理框架、用多大的量化精度、怎么设计请求批处理逻辑。这些决策，直接影响你的成本和用户体验。

AI的竞争已经从"谁的模型更聪明"，部分转移到了"谁的系统更高效"。后者，对工程能力的要求不亚于前者。