★ FEATURED ARTICLE 1. 推理优化到底在优化什么九月底那几天我一直在折腾推理链路的性能问题起因很简单线上一个文本生成任务的平均响应时间从月初的1.2秒涨到了2.8秒P99更是直接飙到6秒以上。用户侧的感受就是卡而成本侧因为单次请求耗时翻倍同样的并发量需要多出近一倍的算力资源来兜底。这不是某一个模块的问题而是整条推理链路在长序列、高并发场景下暴露出来的系统性瓶颈。先把概念说清楚。推理优化指的是在模型训练完成之后针对模型加载、请求调度、计算执行、结果返回这一整条链路做性能提升的过程。它和训练优化的关注点完全不同——训练看的是吞吐和收敛推理看的是延迟、吞吐、显存占用这三个指标的平衡。你不可能同时把三个都做到极致必须根据业务场景做取舍。比如在线对话场景首字延迟TTFT是生命线用户等超过1秒就会觉得卡而离线批量生成场景吞吐量才是核心延迟高一点无所谓。这次优化的目标很明确在不降低生成质量的前提下把P99延迟压回3秒以内同时把单卡并发能力提升至少50%。适合阅读这篇总结的人包括正在做推理服务部署的工程师、需要评估推理成本的架构决策者以及刚接触推理优化、想知道从哪里下手的新手。我会把整个排查和优化过程拆开讲包括每一步的判断依据、参数计算、踩过的坑以及那些文档里不会写的实操细节。2. 优化前的基线测量与瓶颈定位2.1 为什么必须先做基线测量很多人一上来就想着换推理框架、上量化、加缓存但如果你不知道当前系统的瓶颈在哪这些操作大概率是白费力气。我见过最典型的案例是某团队花了两周把模型从FP16量化到INT8结果延迟只降了8%因为真正的瓶颈在数据预处理阶段模型计算只占总耗时的30%。所以第一步永远是建立可复现的基线。我用的工具组合是py-spy做Python层面的火焰图采样nsys做CUDA层面的kernel耗时分析再配合服务端自己埋点的分段计时。三者交叉验证才能定位到真正的热点。基线测量的关键指标包括指标含义本次基线值目标值TTFT首字延迟850ms400msTPOT每输出token耗时45ms25msP99总延迟99分位端到端延迟6.2s3s单卡并发单卡稳定支撑的并发请求数812显存峰值推理过程显存占用峰值68GB55GB测量时有个细节很容易被忽略必须用真实分布的请求做压测不能用固定长度的假数据。因为推理的耗时和输入长度、输出长度强相关固定长度压测出来的数据完全没有参考价值。我的做法是从线上日志里采样500条真实请求保持输入输出长度分布一致然后用locust回放。2.2 瓶颈定位的实操过程火焰图跑出来之后问题比我想的要分散。耗时分布大致是这样的数据预处理占18%模型前向计算占52%后处理和解码占22%剩余8%是调度和网络开销。模型计算虽然是大头但并没有占到压倒性比例这意味着单纯优化模型本身最多只能拿到一半的收益。进一步下钻模型计算部分发现几个具体问题。第一KV Cache的显存管理效率低用的是朴素的预分配策略每个请求都按最大序列长度预留显存导致大量浪费实际利用率只有40%左右。第二Attention计算没有用上Flash Attention还在跑朴素的实现长序列下O(n²)的复杂度直接拖垮了性能。第三batch调度是静态的请求攒够固定数量才一起推理导致短请求要等长请求尾延迟被拉高。后处理部分的问题也很典型解码用的是逐token的Python循环每个token都要做一次numpy转换和CPU-GPU同步这个开销在长输出场景下累积起来非常可观。预处理部分则是tokenizer在多进程下没有做批处理每个请求单独调用一次Python的GIL成了瓶颈。这里有个经验定位瓶颈时不要只看总耗时占比还要看耗时的方差。方差大的环节往往是调度问题方差小的环节往往是计算问题两者的优化手段完全不同。3. 核心优化手段的选型与原理3.1 KV Cache优化的原理与参数计算KV Cache是自回归生成的核心数据结构。每生成一个token都需要用到之前所有token的Key和Value向量如果每次都重新计算复杂度是O(n²)。缓存下来之后每步只需要计算当前token的KV复杂度降到O(n)。但缓存本身要占显存而且占用量和序列长度成正比。显存占用的计算公式是KV Cache显存 2 × batch_size × num_layers × num_heads × head_dim × seq_len × dtype_bytes以本次的模型为例32层32个注意力头head_dim为128FP16存储2字节。单个请求在序列长度2048时2 × 1 × 32 × 32 × 128 × 2048 × 2 1.07 GB看起来不多但并发8个请求、每个序列长度2048时就是8.6GB。而原来的预分配策略是按最大序列长度4096预留直接翻倍到17GB这就是显存利用率只有40%的根源。优化方案是改用PagedAttention式的分页管理把KV Cache切成固定大小的block比如16个token一块按需分配用完即回收。这样显存利用率能提到85%以上同样的显存能支撑的并发数直接翻倍。这个思路借鉴的是操作系统的虚拟内存分页机制把连续的大块需求拆成离散的小块管理用页表做映射。3.2 注意力计算的加速选择Attention的优化有两条路一是用Flash Attention重写kernel二是用更高效的注意力变体。我选了前者因为后者会改变模型行为可能影响生成质量而Flash Attention是数值等价的只是计算方式不同。Flash Attention的核心思想是分块计算在线softmax。传统实现需要把完整的attention矩阵算出来存到显存里再softmax显存占用是O(n²)。Flash Attention把Q、K、V分块逐块计算attention并增量更新softmax的归一化因子显存占用降到O(n)而且因为减少了显存读写速度也更快。实测下来序列长度2048时Flash Attention比朴素实现快2.3倍显存占用降低60%。序列越长收益越大4096长度时能快3.1倍。这个收益是白捡的因为数值结果完全一致不需要重新验证模型质量。3.3 动态批处理的调度策略静态批处理的问题是木桶效应——一批里最慢的请求决定整批的完成时间。动态批处理也叫连续批处理的思路是不等整批完成某个请求生成结束后立刻把新请求插进来让GPU始终处于满载状态。实现上有几个关键参数需要调最大批大小受显存限制本次设为16。设太大容易OOM设太小GPU利用率上不去。批处理超时请求等待多久就必须开始推理本次设为50ms。这个值直接影响TTFT设太大首字延迟高设太小批大小上不去。调度粒度按token调度还是按请求调度。按token调度更细但调度开销大按请求调度简单但会有气泡。本次选了折中的按请求调度token级抢占。动态批处理的调参没有万能公式必须结合你的延迟SLA和硬件配置反复试。我的经验是先把批处理超时设小比如20ms观察GPU利用率如果利用率低于70%就逐步调大超时直到找到利用率和延迟的平衡点。4. 完整实操过程与关键配置4.1 环境准备与依赖确认动手之前先把环境理清楚避免改到一半发现版本不兼容。本次用的基础环境是CUDA 12.1 PyTorch 2.1推理框架选的是vLLM 0.2.x版本因为它原生支持PagedAttention和连续批处理省去了自己实现的成本。依赖确认清单# 确认CUDA版本 nvcc --version # 确认PyTorch能正确识别GPU python -c import torch; print(torch.cuda.is_available(), torch.version.cuda) # 确认Flash Attention可用 python -c import flash_attn; print(flash_attn.__version__)这里踩过一个坑Flash Attention对CUDA版本和PyTorch版本有严格的对应关系版本不匹配时不会报错而是静默回退到朴素实现你以为用上了其实没用。验证方法是跑一个短序列的benchmark对比开启和关闭Flash Attention的耗时如果没差异就是没生效。4.2 模型加载与显存配置模型加载阶段的优化空间经常被忽视。默认的加载方式是先把权重加载到CPU内存再逐个搬到GPU这个过程在大模型上要花好几分钟。优化手段是用分片加载异步传输把权重按层切分边加载边传输加载时间能压缩60%以上。关键配置项from vllm import LLM, SamplingParams llm LLM( modelyour-model-path, tensor_parallel_size2, # 张量并行度2卡 gpu_memory_utilization0.90, # 显存利用率上限留10%给系统 max_model_len4096, # 最大序列长度 block_size16, # PagedAttention的block大小 swap_space8, # CPU交换空间单位GB enforce_eagerFalse, # 关闭eager模式启用CUDA Graph )gpu_memory_utilization这个参数很关键。设成0.95以上容易OOM设成0.8以下又浪费显存。0.90是实测下来比较稳的值但要注意如果你的服务还有其他CUDA进程共享同一张卡得把这个值调低。block_size的选择也有讲究。设太小比如8页表开销大设太大比如32内部碎片多。16是经验值但不同模型的最优值可能不同建议用实际负载测一下。4.3 请求调度与批处理配置调度层的配置直接决定延迟和吞吐的平衡。本次的核心配置是# 调度器配置 scheduler_config { max_num_batched_tokens: 8192, # 单批最大token数 max_num_seqs: 16, # 单批最大请求数 max_paddings: 256, # 最大padding token数 }max_num_batched_tokens是单批所有请求的token总数上限。这个值决定了单次前向计算的计算量设太大会导致单批耗时过长尾延迟升高设太小GPU利用率上不去。8192是实测的平衡点对应单批计算耗时约120ms。max_num_seqs限制单批请求数防止请求数过多导致调度开销超过计算收益。16这个值配合8192的token上限平均每个请求512个token符合本次业务的输入输出长度分布。4.4 后处理与解码优化后处理部分的优化最容易被忽略但收益很实在。原来的逐token Python循环改成批量解码后后处理耗时从占总延迟的22%降到7%。具体做法是用tokenizer的batch decode接口把一批请求的所有输出token一次性解码而不是每个请求单独调用。同时把CPU-GPU同步从每token一次改成每批一次减少了大量的同步开销。# 优化前逐token解码 for token in output_tokens: text tokenizer.decode(token) # 每次都同步 result text # 优化后批量解码 texts tokenizer.batch_decode(output_tokens_list, skip_special_tokensTrue)这个改动看起来简单但在长输出场景下效果显著。输出512个token时后处理耗时从180ms降到45ms。5. 优化效果验证与数据对比5.1 延迟指标的改善优化前后的对比数据如下指标优化前优化后改善幅度TTFT850ms320ms-62%TPOT45ms22ms-51%P50总延迟2.1s0.9s-57%P99总延迟6.2s2.7s-56%单卡并发81475%显存峰值68GB51GB-25%P99延迟从6.2秒压到2.7秒达到了预期目标。单卡并发从8提到14意味着同样的业务量可以少用近一半的卡成本收益非常直接。5.2 生成质量的验证性能优化最怕的是优化完质量掉了。所以每次改动后都必须做质量回归。本次用的验证方法是从业务测试集里抽200条prompt用优化前后的服务各生成一遍对比输出的BLEU和ROUGE分数同时人工抽检50条看语义是否合理。结果BLEU差异在0.3%以内ROUGE差异在0.5%以内人工抽检没有发现明显质量下降。这个结果符合预期因为本次的优化手段PagedAttention、Flash Attention、动态批处理都是数值等价的不改变模型计算逻辑。这里要提醒一句如果你用了量化、剪枝、蒸馏这类会改变模型数值的手段质量验证必须更严格最好用业务侧的端到端指标比如任务完成率、用户满意度来评估光看BLEU不够。5.3 压力测试与稳定性观察优化上线前跑了72小时的稳定性测试用真实流量回放观察几个关键点显存是否泄漏连续跑72小时后显存占用稳定在51GB没有持续增长说明PagedAttention的block回收逻辑正确。长尾请求是否被饿死监控P99.9延迟稳定在4.5秒左右没有出现某些请求被无限推迟的情况。异常输入是否导致崩溃构造了超长输入、空输入、特殊字符输入等边界case服务都能正常处理或优雅拒绝。6. 常见问题与排查技巧实录6.1 优化后延迟反而升高怎么办这是最常见的问题。原因通常有三个一是批处理超时设太大请求等待时间超过了计算节省的时间二是block_size设太小页表管理开销超过了显存节省的收益三是CUDA Graph没生效每次推理都有kernel启动开销。排查顺序先看TTFT如果TTFT升高说明是调度问题调小批处理超时如果TTFT正常但TPOT升高说明是计算问题检查Flash Attention是否生效如果两者都正常但P99高说明是长尾问题检查是否有请求被饿死。6.2 显存OOM的排查思路OOM不一定是因为显存真的不够也可能是碎片化。PagedAttention本身就是为了解决碎片化但如果block_size设得和实际序列长度不匹配碎片依然存在。排查方法用torch.cuda.memory_summary()看显存分配情况重点关注reserved和allocated的差值。如果reserved远大于allocated说明碎片严重需要调小block_size或开启显存整理。6.3 常见问题速查表问题现象可能原因排查方法解决手段TTFT升高批处理超时过大看调度日志的等待时间调小超时到20-50msTPOT升高Flash Attention未生效对比开关前后的benchmark检查版本兼容性P99飙升长请求饿死短请求看请求延迟分布启用token级抢占显存OOM碎片化或配置过大memory_summary调小block_size或降并发吞吐上不去GPU利用率低nvidia-smi看利用率调大批大小或超时输出质量下降优化改变了数值质量回归测试回退有损优化手段6.4 几个文档里不会写的实操心得第一压测数据必须用真实分布。我一开始用固定长度压测优化效果看起来很好换成真实数据后收益打了对折。因为真实请求的长度分布是长尾的短请求和长请求混在一起时调度策略的影响会被放大。第二优化要一个一个上不要一次全改。我见过有人一次性把量化、Flash Attention、动态批处理全上了结果延迟没降反升根本不知道是哪个环节出了问题。正确的做法是每上一个优化就跑一次基线对比确认收益后再上下一个。第三监控要覆盖优化前后的全链路。光看端到端延迟不够必须把预处理、模型计算、后处理、网络传输各段都埋点否则出了问题只能猜。本次优化过程中就是靠分段监控发现后处理是隐藏瓶颈的。第四留好回退开关。每个优化手段都要能独立开关出问题时能快速回退到上一个稳定版本。本次所有优化都通过配置项控制回退只需要改一个参数重启服务不用重新部署代码。7. 后续还能继续挖的优化空间这次优化把能拿的快钱基本都拿了但还有几个方向值得继续投入。一是投机解码用小模型先草拟多个token大模型并行验证在输出分布比较确定的任务上能再快1.5到2倍。二是量化把权重从FP16降到INT8甚至INT4显存和带宽压力都能大幅降低但需要仔细评估质量损失。三是请求级别的缓存对于重复或相似的prompt直接复用之前的KV Cache能省掉大量重复计算。我个人在实际操作中的体会是推理优化没有一劳永逸的方案业务在变、流量在变、模型在变优化是一个持续的过程。与其追求一次做到极致不如把监控和压测体系建好让每次变更都能快速验证效果这样才能在长期迭代中保持系统的性能水位。最后分享一个小技巧每次优化前先把当前配置和基线数据存一份快照包括模型版本、框架版本、所有参数值这样出问题时能快速定位是哪个变更引入的比事后回忆靠谱得多。
阅读完成 · 觉得有帮助？
