LLM推理优化实战：从显存管理到批处理调度的生产级指南

1. 从一次线上事故说起：为什么推理优化不是“调参”那么简单

去年冬天，我负责的一个智能问答服务在晚高峰突然大面积超时。监控面板上，P99延迟从800毫秒一路飙到12秒，GPU利用率却诡异地卡在40%上下。团队第一反应是“加机器”，但扩容之后问题依旧——这说明瓶颈根本不在算力总量，而在推理链路的某个环节。后来我们花了整整三天，才把问题定位到KV Cache的内存碎片和连续批处理（continuous batching）策略的冲突上。

这件事让我彻底改变了对LLM推理优化的认知。很多人以为推理优化就是调调temperature、改改max_tokens，或者换个更小的模型。但真正在生产环境跑过大模型服务的人都清楚，推理优化是一套涉及显存管理、批处理调度、量化精度、算子融合、请求路由的系统工程。它决定了你的服务能不能在可接受的成本下，稳定支撑真实用户的并发请求。

这篇文章面向的是已经跑通过LLM推理Demo、准备把它推向生产环境的工程师，或者正在为推理成本和延迟发愁的技术负责人。我会从显存这个最容易被低估的瓶颈讲起，一路拆到批处理调度、量化取舍、算子优化和线上排障。所有内容都来自实际项目中的踩坑和验证，不是论文摘要，也不是官方文档的复述。如果你正在被“模型能跑但服务扛不住”的问题困扰，下面的内容应该能帮你少走几个月的弯路。

2. 显存才是第一瓶颈：KV Cache的账要算清楚

2.1 为什么模型权重只是显存开销的冰山一角

大多数人评估显存需求时，第一反应是看模型参数量。比如一个70亿参数的模型，FP16精度下权重大约占14GB，看起来一张24GB的卡就能装下。但实际部署时你会发现，24GB根本不够用，甚至32GB都捉襟见肘。原因在于，推理过程中的显存开销远不止权重。

推理时的显存主要分三块：模型权重、KV Cache、以及激活值和临时缓冲区。模型权重是静态的，加载后基本不变；激活值在单次前向传播中产生和释放，峰值可控；真正吃显存且随并发数线性增长的，是KV Cache。Transformer的自注意力机制需要缓存每个已生成token的Key和Value向量，避免重复计算。这个缓存的大小与批次大小、序列长度、层数、注意力头数、头维度都成正比。

我做过一个具体的测算。以一个13B模型为例，假设32层、40个注意力头、头维度128、FP16精度，每个token的KV Cache大小是：2（K和V）× 32层 × 40头 × 128维 × 2字节 = 655360字节，约0.625MB。如果并发处理16个请求，每个请求平均序列长度2048，那么KV Cache总量就是16 × 2048 × 0.625MB ≈ 20GB。加上14GB左右的权重，总需求直接超过34GB。这就是为什么很多人在单卡上跑长上下文服务时，明明权重装得下，却频繁OOM。

提示：评估显存时，先算权重，再算“最大并发数 × 最大序列长度 × 每token KV Cache大小”，两者相加再留20%余量，才是安全的部署底线。

2.2 PagedAttention与显存碎片：一个被忽视的隐形杀手

知道了KV Cache的账怎么算，下一个问题就是怎么管。早期做法是给每个请求预分配一块连续显存，按最大可能长度预留。这种方案的浪费极其严重：一个实际只生成200个token的请求，可能占着2048长度的预留空间，利用率不到10%。更麻烦的是显存碎片——不同请求释放和分配的时间不一致，连续大块显存很快就被切得七零八落，最后明明总空闲显存够，却找不到一块连续空间容纳新请求。

vLLM提出的PagedAttention借鉴了操作系统虚拟内存的分页思想，把KV Cache切成固定大小的块（block），每个块存若干个token的KV向量，块之间不需要连续。请求的KV Cache通过块表映射，逻辑上连续、物理上离散。这样一来，显存利用率能从原来的20%-40%提升到90%以上，碎片问题也基本消失。

我在实际迁移到PagedAttention方案时，最直观的感受是：同样的硬件，支持的并发数翻了将近三倍。但要注意，块大小的选择有讲究。块太小，块表本身占用的元数据开销变大，调度器管理成本上升；块太大，内部碎片又会增加。实践中，块大小设为16个token是比较稳妥的起点，具体还要根据你的平均序列长度分布来调。

2.3 量化对显存的真实影响：别只看权重压缩比

量化是另一个常被寄予厚望的显存优化手段。把FP16权重压到INT8，理论上权重显存直接减半；压到INT4，再减半。但很多人忽略了一点：KV Cache也可以量化，而且KV Cache的量化收益往往比权重量化更直接，因为它才是随并发增长的那部分。

不过量化不是免费的午餐。INT8权重量化通常对精度影响很小， perplexity上升不到0.1，基本可以放心用。但INT4量化就要谨慎了，尤其是对数学推理、代码生成这类对数值精度敏感的任务，INT4可能导致明显的质量下降。我见过一个团队为了省显存把模型压到INT4，结果客服机器人的回答开始出现事实性错误，最后不得不回退。

KV Cache量化相对安全一些，因为缓存的是中间激活值，对最终输出的影响经过多层传播后会被稀释。但要注意，KV Cache量化需要校准数据来统计激活值分布，校准集的选择要贴近真实业务场景。用通用语料校准出来的缩放因子，放到垂直领域数据上可能偏差很大。

3. 批处理调度：吞吐量和延迟的跷跷板怎么压

3.1 静态批处理为什么在真实服务里行不通

静态批处理是最直观的方案：攒够一批请求，一起送进模型，等这批全部生成完，再处理下一批。它的优点是实现简单、GPU利用率高。但在真实服务里，这个方案几乎不可用，因为请求的生成长度差异太大了。

想象一下，一个批次里有三个请求：A只需要生成10个token就结束，B要生成500个，C要生成2000个。静态批处理下，A和B生成完后，它们的计算槽位就空着，但GPU仍然要等C跑完才能释放整个批次。这期间A和B占用的显存不能回收，计算资源也被浪费。更糟的是，新来的请求必须等当前批次全部结束才能进入，排队延迟急剧上升。

我早期用静态批处理跑一个摘要服务，平均生成长度300token，但偶尔有用户粘贴长文，生成长度冲到3000。结果就是：一个长请求能把整批短请求的延迟从1秒拖到15秒。用户体验断崖式下跌。

3.2 连续批处理的调度逻辑与实现要点

连续批处理（continuous batching）解决了这个问题。它的核心思想是：不再以“批次”为单位调度，而是以“迭代步”为单位。每一步，调度器检查哪些请求已经生成结束，把它们移出批次、释放显存；同时检查等待队列，把能塞进当前显存预算的新请求加进来。这样，GPU的每个计算步都尽可能满载，短请求结束后立刻让位给新请求，长请求继续跑，互不阻塞。

听起来简单，实现起来有几个关键决策点。第一是调度粒度：每步都重新调度，还是每隔几步调度一次？每步调度响应最快，但调度器本身的开销会累积；隔步调度能降低开销，但可能错过最佳填充时机。实践中，每步调度配合高效的块管理，开销可以控制在可接受范围。

第二是抢占策略。当显存不足以容纳新请求时，是让新请求等待，还是抢占某个正在运行的请求？抢占意味着把某个请求的KV Cache换出到CPU内存，等显存够了再换回来。这个操作有带宽开销，但如果等待队列很长，抢占能显著提升整体吞吐。vLLM的默认策略是FCFS（先来先服务）加显存不足时排队，但在高负载场景下，可以考虑基于优先级的抢占。

第三是批次大小的上限。批次越大，吞吐越高，但单步计算时间也越长，导致单请求延迟上升。这个权衡没有标准答案，要根据你的SLA来定。如果延迟敏感，批次上限设小一些；如果吞吐优先，可以放大。

3.3 实测数据：不同调度策略下的吞吐与延迟对比

我在一台A100 80GB上做过一组对比测试，模型是13B FP16，请求长度服从真实业务分布（平均输入200token，平均输出400token，P99输出2000token）。测试结果如下：

从数据可以看出，连续批处理相比静态批处理，吞吐翻倍以上，P99延迟降低超过一半。带抢占的策略吞吐最高，但平均延迟略有上升，因为被抢占的请求需要重新计算或换入换出。批次上限设为4时，延迟最低，但吞吐牺牲明显。这组数据说明：没有万能的配置，只有匹配业务SLA的配置。

注意：抢占虽然能提升吞吐，但换出到CPU的KV Cache在换回时需要重新传输，如果PCIe带宽是瓶颈，抢占的收益可能被抵消。建议在NVLink或高带宽互联的环境下再考虑激进抢占。

4. 量化与算子优化：精度和速度的平衡术

4.1 权重量化的选型：GPTQ、AWQ还是GGUF

权重量化方案这几年迭代很快，主流的有GPTQ、AWQ和GGUF。GPTQ是基于二阶信息的逐层量化，量化速度快，精度保持不错，适合GPU部署。AWQ（Activation-aware Weight Quantization）在量化时考虑了激活值的分布，对重要通道保留更高精度，实测在INT4下比GPTQ略好，尤其是对指令跟随类任务。GGUF更多用于CPU或混合推理场景，GPU部署不是首选。

我在一个代码生成项目里对比过GPTQ和AWQ的INT4效果。用HumanEval做评测，GPTQ的pass@1是32.5%，AWQ是35.1%，FP16基线是38.7%。AWQ确实更接近基线，但差距依然存在。如果业务对代码正确性要求极高，INT4可能不够，INT8或者FP16更稳妥。如果只是做文本摘要、分类这类容错率高的任务，INT4完全可用。

量化还有一个容易被忽略的点：校准集。GPTQ和AWQ都需要校准数据来统计权重和激活的分布。校准集应该来自真实业务数据，而不是随便拿几百条通用语料。我见过一个团队用新闻语料校准的量化模型去跑医疗问答，结果专业术语的生成质量明显下降。后来换成医疗问答对做校准，质量恢复了大半。

4.2 算子融合与FlashAttention的实际收益

算子融合是推理优化的另一个重要方向。Transformer里有很多可以合并的操作，比如LayerNorm和线性层、残差连接和激活函数。融合之后，减少了kernel启动次数和显存读写，延迟能降10%-20%。这部分通常由推理框架自动完成，但不同框架的融合程度差异很大。TensorRT-LLM的融合做得最激进，vLLM和TGI相对保守但也在持续优化。

FlashAttention是必须提的一项优化。标准注意力计算的显存开销是O(n²)，因为要存储完整的注意力矩阵。FlashAttention通过分块计算和在线softmax，把显存降到O(n)，同时利用GPU的SRAM减少HBM读写，速度也有提升。对于长上下文场景，FlashAttention几乎是必选项。我实测过一个4K上下文的场景，开启FlashAttention后，单步延迟降低约30%，显存节省约40%。

但FlashAttention不是万能的。它的收益在序列长度较短时（比如小于512）不明显，因为分块计算的优势发挥不出来。另外，FlashAttention对头维度的对齐有要求，某些非标准模型结构可能不兼容。部署前一定要确认框架版本和模型结构的匹配性。

4.3 投机解码：用一个小模型撬动大模型的推理速度

投机解码（speculative decoding）是这两年比较热的一个方向。思路很巧妙：用一个小的草稿模型（draft model）先快速生成若干个候选token，然后用大模型一次性验证这些token是否正确。如果草稿模型的预测和大模型一致，就相当于用草稿模型的速度生成了大模型的输出；如果不一致，大模型会纠正，但至少验证是并行的，比逐个生成快。

实测下来，投机解码在草稿模型和大模型分布接近时，加速比能到2-3倍。但如果草稿模型太弱，候选token被拒绝的比例高，加速效果就打折扣，甚至可能因为验证开销而变慢。草稿模型的选择很关键：可以是同系列的小模型，也可以是对大模型做蒸馏得到的模型。另外，投机解码对批处理不太友好，因为不同请求的接受率不同，批次内的同步会变复杂。目前更适合低并发、延迟敏感的场景。

我在一个实时翻译服务里试过投机解码，用1.5B模型做草稿、13B模型做验证，端到端延迟从900ms降到450ms左右，效果很明显。但并发一上去，批处理效率下降，整体吞吐反而不如不用投机解码。所以这个技术要分场景用。

5. 线上排障实录：那些文档里不会写的坑

5.1 延迟毛刺的排查链路：从GPU利用率到请求分布

线上服务最怕的不是持续高延迟，而是偶发毛刺。P50正常，P99突然飙高，用户投诉集中在少数请求上。这种问题排查起来最头疼，因为复现困难。

我遇到过一次典型的毛刺问题：每运行几小时，就会出现一波持续几分钟的P99飙升。第一反应是GPU过热降频，查了温度日志，正常。第二反应是显存碎片导致OOM重试，查了OOM日志，没有。第三反应是某个长请求阻塞了批次，查了请求长度分布，发现确实有少量超长请求，但数量不足以解释整波毛刺。

最后定位到的是调度器的队列积压。当等待队列长度超过某个阈值时，调度器会尝试一次性塞入过多请求，导致单步计算时间暴涨，进而让所有在途请求的延迟都上升。这个阈值在代码里是硬编码的，没有根据实际显存和计算能力动态调整。改成动态阈值后，毛刺消失。

这个案例的教训是：排障不能只看GPU指标，调度器的内部状态（队列长度、批次组成、块分配情况）同样重要。建议在监控里加上这些指标，出问题时能快速定位。

5.2 请求失败重试引发的雪崩：一个真实案例

另一个印象深刻的坑是重试风暴。我们的客户端在请求超时后会重试，默认重试3次。平时没问题，但有一次推理服务因为某个算子编译卡顿，响应变慢，大量请求超时。客户端开始重试，瞬间把QPS放大了3倍。服务端本来只是慢，被重试流量一冲，直接雪崩，所有请求都失败。

这个问题的根因不在推理优化本身，而在服务治理。解决方案有几个：一是客户端重试要加退避和抖动，避免同时重试；二是服务端要做过载保护，当队列超过阈值时直接拒绝新请求，而不是让它们排队等死；三是重试请求应该走独立的限流通道，不能和正常请求抢资源。

提示：推理服务的容量规划，一定要把重试流量算进去。如果你的客户端默认重试3次，那服务端的峰值承载能力至少要按正常QPS的3倍来设计，否则一次抖动就可能引发连锁反应。

5.3 监控指标怎么设：别只盯着GPU利用率

GPU利用率是个迷惑性很强的指标。利用率高不代表服务健康，可能是批次里塞了太多长请求，大家都在等最慢的那个；利用率低也不代表有问题，可能是请求稀疏，GPU在等数据。真正有用的指标是分层的：

• 请求层：QPS、P50/P95/P99延迟、超时率、重试率
• 批次层：平均批次大小、批次填充率、抢占次数、队列等待时间
• 显存层：KV Cache使用率、块碎片率、OOM次数
• 计算层：单步计算时间、算子耗时分布、GPU利用率

其中批次填充率和队列等待时间是我最关注的。填充率低说明批次没吃满，吞吐有提升空间；队列等待时间长说明调度跟不上请求到达速度，需要扩容或优化调度。这两个指标结合起来，基本能判断服务是“算力不够”还是“调度不行”。

6. 把优化落到工程里：一套可复用的检查清单

6.1 上线前的容量测算模板

在部署任何LLM推理服务之前，我都会做一遍容量测算。模板如下：

1. 确定模型规格：参数量、层数、注意力头数、头维度、精度
2. 计算权重显存：参数量 × 精度字节数（FP16为2，INT8为1，INT4为0.5）
3. 估算KV Cache：2 × 层数 × 头数 × 头维度 × 精度字节数 × 最大并发 × 平均序列长度
4. 加上激活值和框架开销：通常取权重和KV Cache之和的15%-20%
5. 对比GPU显存：总需求不超过显存的80%，留出碎片和峰值余量
6. 反推最大并发：如果显存不够，降低并发或启用量化，重新计算

这个模板看起来简单，但能避免绝大多数“上线才发现装不下”的问题。我见过太多团队跳过这一步，直接拿Demo配置上生产，结果第一天就OOM。

6.2 不同业务场景的优化优先级

优化手段很多，但资源有限，要有优先级。我的经验是按业务场景来分：

这张表不是绝对的，但能帮你在资源有限时快速决定先做什么。比如实时对话场景，先把连续批处理和FlashAttention上了，延迟就能降一大截；批量摘要场景，先把PagedAttention和批次调大，吞吐立刻上去。

6.3 持续迭代：从能跑到跑得好的最后一公里

推理优化不是一次性的工作，而是一个持续迭代的过程。服务上线只是起点，后面还有大量可以打磨的地方。

第一，定期回顾监控数据，看批次填充率有没有下降、队列等待时间有没有上升。业务流量模式会变，优化配置也要跟着调。

第二，关注框架更新。vLLM、TensorRT-LLM、TGI这些框架迭代很快，新版本经常带来显著的性能提升。但升级前一定要做回归测试，确认精度和稳定性没有退化。

第三，积累自己的基准测试集。用真实业务数据构造一组有代表性的请求，每次调整配置或升级框架后跑一遍，对比吞吐、延迟和生成质量。这比看官方benchmark靠谱得多，因为你的业务分布只有你自己清楚。

第四，不要忽视成本。推理优化的终极目标不是跑得最快，而是在满足SLA的前提下成本最低。有时候降级到更小的模型、或者对非核心请求做限流，比死磕单请求延迟更划算。

我在实际项目里最深的一点体会是：LLM推理优化没有银弹，每个决策都是权衡。显存和延迟权衡，吞吐和延迟权衡，精度和速度权衡。理解这些权衡背后的原理，比记住某个具体配置重要得多。因为业务在变，硬件在变，框架在变，只有原理是稳定的。把原理吃透，你就能在任何新场景下快速找到合适的优化路径。