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大小是2K和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量化需要校准数据来统计激活值分布校准集的选择要贴近真实业务场景。用通用语料校准出来的缩放因子放到垂直领域数据上可能偏差很大。优化手段显存收益精度风险适用场景FP16权重基准无所有场景INT8权重权重减半极低所有场景INT4权重权重再减半中高对精度不敏感的生成任务KV Cache INT8缓存减半低长上下文、高并发KV Cache INT4缓存再减半中需充分校准验证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平均输出400tokenP99输出2000token。测试结果如下调度策略吞吐token/s平均延迟msP99延迟ms显存利用率静态批处理batch8125032001580045%连续批处理无抢占28001800620082%连续批处理带抢占31002100580088%连续批处理batch上限422001200350070%从数据可以看出连续批处理相比静态批处理吞吐翻倍以上P99延迟降低超过一半。带抢占的策略吞吐最高但平均延迟略有上升因为被抢占的请求需要重新计算或换入换出。批次上限设为4时延迟最低但吞吐牺牲明显。这组数据说明没有万能的配置只有匹配业务SLA的配置。注意抢占虽然能提升吞吐但换出到CPU的KV Cache在换回时需要重新传输如果PCIe带宽是瓶颈抢占的收益可能被抵消。建议在NVLink或高带宽互联的环境下再考虑激进抢占。4. 量化与算子优化精度和速度的平衡术4.1 权重量化的选型GPTQ、AWQ还是GGUF权重量化方案这几年迭代很快主流的有GPTQ、AWQ和GGUF。GPTQ是基于二阶信息的逐层量化量化速度快精度保持不错适合GPU部署。AWQActivation-aware Weight Quantization在量化时考虑了激活值的分布对重要通道保留更高精度实测在INT4下比GPTQ略好尤其是对指令跟随类任务。GGUF更多用于CPU或混合推理场景GPU部署不是首选。我在一个代码生成项目里对比过GPTQ和AWQ的INT4效果。用HumanEval做评测GPTQ的pass1是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推理服务之前我都会做一遍容量测算。模板如下确定模型规格参数量、层数、注意力头数、头维度、精度计算权重显存参数量 × 精度字节数FP16为2INT8为1INT4为0.5估算KV Cache2 × 层数 × 头数 × 头维度 × 精度字节数 × 最大并发 × 平均序列长度加上激活值和框架开销通常取权重和KV Cache之和的15%-20%对比GPU显存总需求不超过显存的80%留出碎片和峰值余量反推最大并发如果显存不够降低并发或启用量化重新计算这个模板看起来简单但能避免绝大多数“上线才发现装不下”的问题。我见过太多团队跳过这一步直接拿Demo配置上生产结果第一天就OOM。6.2 不同业务场景的优化优先级优化手段很多但资源有限要有优先级。我的经验是按业务场景来分业务场景首要目标优先优化手段次要手段实时对话低延迟连续批处理、FlashAttention投机解码、算子融合批量摘要高吞吐PagedAttention、大批次INT8量化、算子融合长文档问答长上下文KV Cache量化、FlashAttention分块处理、稀疏注意力代码生成高精度FP16/INT8、AWQ量化投机解码谨慎高并发API稳定性过载保护、动态批次请求优先级、抢占这张表不是绝对的但能帮你在资源有限时快速决定先做什么。比如实时对话场景先把连续批处理和FlashAttention上了延迟就能降一大截批量摘要场景先把PagedAttention和批次调大吞吐立刻上去。6.3 持续迭代从能跑到跑得好的最后一公里推理优化不是一次性的工作而是一个持续迭代的过程。服务上线只是起点后面还有大量可以打磨的地方。第一定期回顾监控数据看批次填充率有没有下降、队列等待时间有没有上升。业务流量模式会变优化配置也要跟着调。第二关注框架更新。vLLM、TensorRT-LLM、TGI这些框架迭代很快新版本经常带来显著的性能提升。但升级前一定要做回归测试确认精度和稳定性没有退化。第三积累自己的基准测试集。用真实业务数据构造一组有代表性的请求每次调整配置或升级框架后跑一遍对比吞吐、延迟和生成质量。这比看官方benchmark靠谱得多因为你的业务分布只有你自己清楚。第四不要忽视成本。推理优化的终极目标不是跑得最快而是在满足SLA的前提下成本最低。有时候降级到更小的模型、或者对非核心请求做限流比死磕单请求延迟更划算。我在实际项目里最深的一点体会是LLM推理优化没有银弹每个决策都是权衡。显存和延迟权衡吞吐和延迟权衡精度和速度权衡。理解这些权衡背后的原理比记住某个具体配置重要得多。因为业务在变硬件在变框架在变只有原理是稳定的。把原理吃透你就能在任何新场景下快速找到合适的优化路径。 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大小是2K和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量化需要校准数据来统计激活值分布校准集的选择要贴近真实业务场景。用通用语料校准出来的缩放因子放到垂直领域数据上可能偏差很大。优化手段显存收益精度风险适用场景FP16权重基准无所有场景INT8权重权重减半极低所有场景INT4权重权重再减半中高对精度不敏感的生成任务KV Cache INT8缓存减半低长上下文、高并发KV Cache INT4缓存再减半中需充分校准验证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平均输出400tokenP99输出2000token。测试结果如下调度策略吞吐token/s平均延迟msP99延迟ms显存利用率静态批处理batch8125032001580045%连续批处理无抢占28001800620082%连续批处理带抢占31002100580088%连续批处理batch上限422001200350070%从数据可以看出连续批处理相比静态批处理吞吐翻倍以上P99延迟降低超过一半。带抢占的策略吞吐最高但平均延迟略有上升因为被抢占的请求需要重新计算或换入换出。批次上限设为4时延迟最低但吞吐牺牲明显。这组数据说明没有万能的配置只有匹配业务SLA的配置。注意抢占虽然能提升吞吐但换出到CPU的KV Cache在换回时需要重新传输如果PCIe带宽是瓶颈抢占的收益可能被抵消。建议在NVLink或高带宽互联的环境下再考虑激进抢占。4. 量化与算子优化精度和速度的平衡术4.1 权重量化的选型GPTQ、AWQ还是GGUF权重量化方案这几年迭代很快主流的有GPTQ、AWQ和GGUF。GPTQ是基于二阶信息的逐层量化量化速度快精度保持不错适合GPU部署。AWQActivation-aware Weight Quantization在量化时考虑了激活值的分布对重要通道保留更高精度实测在INT4下比GPTQ略好尤其是对指令跟随类任务。GGUF更多用于CPU或混合推理场景GPU部署不是首选。我在一个代码生成项目里对比过GPTQ和AWQ的INT4效果。用HumanEval做评测GPTQ的pass1是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推理服务之前我都会做一遍容量测算。模板如下确定模型规格参数量、层数、注意力头数、头维度、精度计算权重显存参数量 × 精度字节数FP16为2INT8为1INT4为0.5估算KV Cache2 × 层数 × 头数 × 头维度 × 精度字节数 × 最大并发 × 平均序列长度加上激活值和框架开销通常取权重和KV Cache之和的15%-20%对比GPU显存总需求不超过显存的80%留出碎片和峰值余量反推最大并发如果显存不够降低并发或启用量化重新计算这个模板看起来简单但能避免绝大多数“上线才发现装不下”的问题。我见过太多团队跳过这一步直接拿Demo配置上生产结果第一天就OOM。6.2 不同业务场景的优化优先级优化手段很多但资源有限要有优先级。我的经验是按业务场景来分业务场景首要目标优先优化手段次要手段实时对话低延迟连续批处理、FlashAttention投机解码、算子融合批量摘要高吞吐PagedAttention、大批次INT8量化、算子融合长文档问答长上下文KV Cache量化、FlashAttention分块处理、稀疏注意力代码生成高精度FP16/INT8、AWQ量化投机解码谨慎高并发API稳定性过载保护、动态批次请求优先级、抢占这张表不是绝对的但能帮你在资源有限时快速决定先做什么。比如实时对话场景先把连续批处理和FlashAttention上了延迟就能降一大截批量摘要场景先把PagedAttention和批次调大吞吐立刻上去。6.3 持续迭代从能跑到跑得好的最后一公里推理优化不是一次性的工作而是一个持续迭代的过程。服务上线只是起点后面还有大量可以打磨的地方。第一定期回顾监控数据看批次填充率有没有下降、队列等待时间有没有上升。业务流量模式会变优化配置也要跟着调。第二关注框架更新。vLLM、TensorRT-LLM、TGI这些框架迭代很快新版本经常带来显著的性能提升。但升级前一定要做回归测试确认精度和稳定性没有退化。第三积累自己的基准测试集。用真实业务数据构造一组有代表性的请求每次调整配置或升级框架后跑一遍对比吞吐、延迟和生成质量。这比看官方benchmark靠谱得多因为你的业务分布只有你自己清楚。第四不要忽视成本。推理优化的终极目标不是跑得最快而是在满足SLA的前提下成本最低。有时候降级到更小的模型、或者对非核心请求做限流比死磕单请求延迟更划算。我在实际项目里最深的一点体会是LLM推理优化没有银弹每个决策都是权衡。显存和延迟权衡吞吐和延迟权衡精度和速度权衡。理解这些权衡背后的原理比记住某个具体配置重要得多。因为业务在变硬件在变框架在变只有原理是稳定的。把原理吃透你就能在任何新场景下快速找到合适的优化路径。