推理加速有哪些方法？量化、批处理、并行和 vLLM 怎么理解？
上回我们聊了怎么让模型乖乖输出 JSON——结构化输出和 Function Calling，听起来挺完美的对吧？但问题来了：模型想明白了怎么回答，你却发现等一个回答要好几秒。用户点一下，要喝完半杯水才看到结果。
这不是模型的锅。是推理太贵、太慢了。
今天就把推理加速的门道讲清楚——量化、批处理、并行计算，外加一个叫 vLLM 的"加速神器"。一条一条拆，手把手教你怎么让大模型跑得又快又稳。
先搞清楚问题在哪——传统推理为什么慢
大模型推理，天然就是个"重活"。
一个 70B 参数的模型，光是把参数加载进显存就要 140GB。什么意思？你那张旗舰显卡显存可能才 80GB，连装都装不下。更别说推理时还要存中间计算结果、缓存历史上下文。
传统框架的问题更气人。你用 HuggingFace Transformers 跑过就知道，请求是串行处理的——一个请求处理完，才能处理下一个。就像餐厅里，一桌吃完了下一桌才能入座。高峰期门口大排长龙，有人等烦了直接走人。
GPU 明明很强，但大部分时间在空转。因为下一个请求还在排队，它不知道干什么。
用户体验差，成本也高。同样一台机器，能处理的请求数上不去，单次请求的成本就下不来。
所以推理加速，解决的是两件事：让用户等得更少，让成本降得更低。
量化——让模型"轻装上阵"
第一个武器叫量化。
原理很简单：我们把模型参数从高精度"压缩"成低精度的。
原来模型参数用 FP32 存储——每个数字占 4 个字节。现在改成 INT8，每个数字只占 1 个字节。更激进一点，用 INT4，只占 0.5 个字节。
模型还是那个模型，能力几乎不变，但占用的显存直接少了一半甚至四分之三。
这就像把一本精装书换成口袋版。内容一字不差，但随身携带轻松多了，翻起来还快。
现在生产环境主流用 AWQ 4-bit 量化方案。为什么？精度损失小，速度提升明显，显存占用刚好卡在很多显卡能 hold 住的范围内。
效果有多猛？原来要 80GB 显存才能跑动的模型，量化后 24GB 就够了。你家那台游戏显卡，突然就能跑大模型了。
我之前拿 Llama-3-70B 实测了一下，FP16 版本加载要 140GB 显存，根本跑不动。换 AWQ 4-bit 量化后，2 张 A100（每张 80GB）就能稳稳跑起来，生成速度大概 15-20 tokens/s。
当然量化不是银弹。精度损失虽然很小，但确实存在。有些任务对精度敏感，可能要调回 INT8 或者干脆用 FP16。但对大多数应用来说，AWQ 4-bit 就是最优解。
批处理——从"排队等位"到"拼桌就餐"
量化解决了"装得下"的问题。接下来解决"跑得快"。
第二个武器叫批处理，核心思路是把多个请求凑在一起处理。
你可能会问：多个请求一起处理，不还是会互相等待吗？
这就看你怎么"凑"了。
静态批处理是最原始的做法：等凑满 N 个请求，一起送进 GPU 处理。简单，但问题也很明显——如果只来了 3 个请求，你得等凑够 N 个才能开始。GPU 还是要空转等数据。
真正的突破叫连续批处理（Continuous Batching）。
它的思路像火锅店的"拼桌"模式：不等整桌满员，有空位就塞人。一桌吃完了，新来的直接补位，不用等下一轮。
具体怎么做到？GPU 在处理一个批次的时候，调度器会盯着看——哪个序列生成完了，马上把新请求插进去。无缝衔接，GPU 基本不停。
vLLM 就是这个思路的集大成者。它能同时运行几十个序列，动态管理，效率拉满。
我之前做过一个对比：同样一台 8 卡 A100 服务器，跑 ChatGLM3-6B 的 API 服务，用原始 HF Transformers，QPS 只能到 30 左右。换成 vLLM 开启连续批处理，QPS 直接飙到 200+，翻了 6-7 倍。
原来 GPU 利用率可能只有 30%，连续批处理能拉到 80% 以上。成本直接砍半，用户等待时间也跟着降。
这就是为什么 vLLM 一出来，整个行业都在用它。不是因为它有什么黑科技，而是它把"拼桌"这个概念真正做好了。
并行策略——多卡协同作战
量化压缩了模型，批处理压榨了 GPU。但如果你要同时服务成百上千的用户，一台机器还是不够。
这时候就要上并行。
并行有三种主流姿势：
张量并行（Tensor Parallelism）：把模型横向切开。模型每一层都拆成多份，分别放到不同显卡上。计算时大家协同完成，最后汇总结果。就像装修队，有人刷墙、有人铺地、水电工同时作业，最后拼成完整工程。
张量并行需要高速互联，NVLink 是标配。不然卡与卡之间传数据太慢，并行的收益就被吃光了。我们组之前试过用普通 PCIe 跑张量并行，结果通信开销太大，4 张卡反而比 2 张卡还慢，血的教训。
数据并行（Data Parallelism）：把模型原封不动复制多份，每份处理不同的请求。这个最简单粗暴，适合高并发场景——请求多到一台机器跑不过来，那就多加几台。
流水线并行（Pipeline Parallelism）：把模型按层切开，按顺序流水线作业。前一张卡处理完，把结果传给下一张。像流水线工厂，一批产品依次经过各个工位。
但流水线有个问题：空闲时间太多。第一张卡忙的时候，后面的卡都在等。所以需要"微批次"来填缝，让各个工位尽量保持忙碌。
多卡并行听起来很美，但有个前提：你的批次得足够大。如果每个请求都很短，GPU 刚启动就要等通信，并行反而更慢。
所以选哪种策略，要看你的场景：是高并发还是低延迟？硬件条件如何？这些都决定了怎么组合搭配。
vLLM——推理加速的集大成者
前面三个武器，量化、批处理、并行，单独用都很强。但要把它们组合起来，打出最优效果，有个框架帮你搞定——这就是 vLLM。
vLLM 出身名门：加州大学伯克利分校的研究团队开发，GitHub 星标早就过万了。现在是开源推理框架里最火的一个。
它的核心突破叫 PagedAttention。
这个名字来自操作系统的"分页内存管理"概念。操作系统会把内存分成固定大小的页，按需分配和回收。vLLM 把这个思想用到了 KV 缓存上。
原来 KV 缓存是怎么存的？一次性分配一整块连续空间，每个序列从头到尾都占着。但如果序列长度差异很大，就会产生大量碎片——有的缓存用完了空着，有的还没用就被截断了。
PagedAttention 的做法是：按需分配，用多少占多少。不同序列的缓存块可以共享同一块物理内存，像图书馆的智能书架——不是一次性搬空再整理，而是分页存取、随用随取。
这样显存利用率大幅提升，能同时服务的序列数直接翻倍。
更厉害的是，vLLM 还支持前缀缓存。如果多个请求有相同的前缀（比如 system prompt），这个部分只需要存一份，后面的请求直接复用。省显存，省计算，白捡的性能提升。
生态方面，vLLM 做得也很完善。无缝对接 HuggingFace 模型、LangChain 工具链、FastAPI 服务框架。你原来怎么用，现在还怎么用，只是底层快了。
用 vLLM 跑 llama、mistral、qwen 这些主流模型，吞吐量是原来 HuggingFace 的十几倍甚至几十倍。这不是吹的，是 benchmark 实打实测出来的。
我们线上跑的是 vLLM 0.4.0 版本，配合 Qwen2-72B 和 AWQ 量化，单机能跑到 500+ QPS，TTFT 稳定在 200ms 以内。用户反馈明显比之前"跟打字一样流畅"。
生产环境的实战配置
理论和工具都有了，接下来聊点实在的：上线之后怎么调。
容量规划，别盯着 QPS，要看令牌率（Token Rate）。
QPS 是每秒请求数，但每个请求长度不一样。同样是 100 QPS，一个请求 100 token 和一个请求 1000 token，负载差十倍。真正衡量系统能力的是每秒处理多少 token。
还有一个关键指标叫 TTFT（Time To First Token），意思是用户发请求到看到第一个字要多久。这个比 total latency 更影响体验——用户能看到"正在打字"和干等着，是完全不同的感受。
并发序列数怎么设？ 以 A100 为例，从 64-128 开始，然后逐步增加。增加到 TTFT 开始明显变差的时候，就是你的极限。显卡越强、显存越大，能并发的序列数越高。
有个坑要提醒：不是设得越高越好。之前我们设到 256，以为能多扛点压力，结果请求堆积严重，P99 延迟直接从 300ms 飙到 2s。后来降到 160，稳定多了。
前缀缓存是个好功能，但要用对。 如果你的应用里大量请求共享 system prompt 或者固定的模板，开启前缀缓存能省下不少资源。前提是你的请求确实有足够的重复前缀。像 AI 助手类应用，系统提示词长且固定，开启后效果很明显。
运维方面，网关层要做准入控制。流量太大直接拒掉，别让后端过载。设置背压机制，当队列积压严重时主动降速。还有就是监控——TTFT、吞吐量、GPU 利用率，这三个指标要盯紧。
写在最后
好了，推理加速的三板斧——量化、批处理、并行——加上 vLLM 这个集大成者，你已经知道它们各自怎么工作、怎么配合了。
实际落地时，没有银弹。并发优先还是延迟优先？硬件条件如何？模型多大？这些都决定了怎么组合搭配。
但有一点是肯定的：大模型要真正走进千家万户，推理加速是必经之路。模型再强，响应太慢也没人用。
下一个问题来了：模型跑快了，但有时候它会"瞎编"——一本正经地说些不存在的事。还有重复输出、截断问题、安全风险。这些"生成质量"的问题怎么解决？
这就是下篇要聊的了——幻觉、重复、截断和安全兜底，咱们不见不散。