大模型推理优化实战：从量化到连续批处理的分层调优指南

1. 大模型推理优化的核心命题与整体思路1.1 推理优化到底在优化什么很多人第一次接触LLM推理优化脑子里第一反应是“让模型跑得更快”。这个理解不算错但太粗糙了。实际做过线上服务的人都知道推理优化从来不是单一维度的速度问题它是一组相互拉扯的指标之间的平衡首Token延迟TTFT、每Token输出延迟TPOT、吞吐量Throughput、显存占用、单位算力成本。你把这几个指标摆在一起看就会发现它们天然存在矛盾——想让单次请求响应快就得牺牲并发吞吐想把吞吐拉满单用户体感就会变差。所以我在做任何优化之前习惯先问一个问题这个场景到底更在意什么是在线对话类产品用户盯着屏幕等第一个字出来那TTFT就是命门还是离线批量摘要、数据标注这类任务用户根本不在场那吞吐和成本才是核心。这两种场景的优化路径几乎是相反的。在线场景要优先保延迟批处理Batching要谨慎离线场景可以激进地堆Batch Size把GPU吃满。理解这一点之后后面的所有技术手段才有落脚点。推理优化本质上是在给定硬件预算和SLA约束下找到计算、显存、带宽三者之间的最优解。大模型推理之所以慢根子在于它是显存带宽受限Memory-Bound而非算力受限的任务。每生成一个Token都要把整个模型的权重从显存里读一遍矩阵乘法的计算量相对访存量来说太小了GPU的算力单元大量时间在等数据搬运。这就是为什么很多优化手段——量化、KV Cache管理、连续批处理——本质上都在做同一件事减少单位Token的显存访问量或者让显存访问被更多计算摊薄。1.2 从“能跑”到“跑得好”的分层优化框架我把推理优化拆成四个层次从下往上依次是模型层、引擎层、服务层、系统层。这个分层不是学术分类是我自己在项目里排查问题时用的思路哪一层出问题就往哪一层钻。模型层是最底层的优化包括量化INT8、INT4、FP8、剪枝、蒸馏、算子融合。这一层动的是模型本身收益大但风险也大量化掉点、精度损失都是常见代价。引擎层指的是推理框架的选择和配置比如vLLM、TensorRT-LLM、SGLang这些它们内部实现了PagedAttention、连续批处理、投机解码等机制。服务层是请求调度、路由、缓存、限流这些工程问题。系统层则是硬件选型、多卡并行策略、网络拓扑。新手最容易犯的错是跳过模型层和引擎层直接在服务层瞎调参数。我见过有人花两周调Batch Size和并发数结果发现模型本身用的是FP16全精度换成INT8量化直接吞吐翻倍。所以顺序很重要先把模型和引擎这两层的地基打牢再去做服务层的精细调度。1.3 一个真实的优化目标拆解案例假设你手上有一个7B参数的模型部署在单张24GB显存的卡上要支撑一个内部知识库问答系统日均请求量几千次高峰期并发大概20路。这个场景的优化目标可以这样拆显存7B模型FP16权重约14GB加上KV Cache和激活值24GB卡勉强够用但没余量。所以量化几乎是必选项INT8能把权重压到7GB左右留出充足空间给KV Cache。延迟内部问答场景TTFT控制在1秒内、TPOT控制在50ms以内体感就够用了不需要追求极致。吞吐20路并发不算高但要有突发余量连续批处理能显著提升GPU利用率。这个拆解过程说明一件事优化目标必须量化成具体数字否则你永远不知道什么时候算“优化好了”。我习惯在项目开始就写一张指标基线表优化前后对比用数据说话。2. 模型层优化量化、精度与算子融合的取舍2.1 量化为什么是性价比最高的第一刀量化是我在所有推理优化项目里第一个动手的地方没有例外。原因很简单它直接砍掉了显存带宽压力这个最大瓶颈。前面说过LLM推理是显存带宽受限的权重从FP16降到INT8显存访问量直接减半理论上吞吐就能接近翻倍。而且现代GPU比如带Tensor Core的架构对INT8矩阵乘法有专门的加速支持算力也不是问题。但量化不是免费的午餐。核心矛盾在于精度损失。FP16到INT8动态范围从约65504缩到127模型里那些数值分布跨度大的层尤其是Attention的某些投影层和FFN的中间激活很容易溢出或者精度不够。我实测下来权重量化Weight-Only Quantization比激活量化安全得多因为权重分布相对稳定而激活值随输入变化剧烈量化激活往往掉点明显。常见的量化方案我列个表对比一下这是我踩过坑之后总结的方案精度显存节省掉点风险适用场景FP16基准0无精度敏感、显存充足INT8W8A16高约50%低通用推荐首选INT4W4A16中约75%中显存紧张、可接受轻微掉点FP8高约50%低支持FP8的新硬件GPTQ/AWQ中高约75%中低4bit场景的主流选择提示W8A16表示权重8bit、激活16bit这是最稳妥的量化配置。W4A16虽然省显存但在数学推理、代码生成这类任务上掉点会比较明显选之前一定要在自己的评测集上验证。2.2 量化实操从校准到部署的完整链路量化不是一句“加载INT8模型”就完事的中间有个校准Calibration环节很多人忽略它结果量化后模型胡言乱语。校准的本质是用一批有代表性的数据跑一遍模型统计每一层激活值的分布范围据此确定量化的缩放因子Scale和零点Zero Point。具体步骤我按实际操作顺序写准备校准数据集从你的真实业务数据里采样一般128到512条就够。关键是分布要贴近线上输入如果你用通用语料校准但线上全是专业领域问题量化误差会很大。我一般会混入一部分领域数据。选择校准算法常见的有MinMax、Moving Average、Percentile。MinMax简单但对离群值敏感Percentile比如取99.9%分位更鲁棒是我更常用的。执行量化以GPTQ为例它逐层做量化用Hessian矩阵指导权重更新尽量补偿量化误差。AWQ则关注那些“重要权重”对它们保留更高精度。验证精度这一步绝对不能省。我会准备一个包含50到100条问题的评测集对比量化前后的输出看困惑度Perplexity和实际任务准确率。困惑度涨了5%以内通常可接受涨太多就得回退。# 以GPTQ量化为例的伪代码流程 from transformers import AutoModelForCausalLM, AutoTokenizer from auto_gptq import AutoGPTQForCausalLM, BaseQuantizeConfig quantize_config BaseQuantizeConfig( bits4, # 量化位数 group_size128, # 分组大小越小精度越高但越慢 desc_actFalse, # 是否按激活顺序重排开启精度略高 ) model AutoGPTQForCausalLM.from_pretrained( your-model-path, quantize_configquantize_config ) tokenizer AutoTokenizer.from_pretrained(your-model-path) # 校准数据 calib_data [tokenizer(text) for text in calibration_texts] model.quantize(calib_data) model.save_quantized(your-quantized-model)2.3 算子融合与KV Cache的显存账除了量化模型层还有两个常被忽视的优化点算子融合和KV Cache管理。算子融合指的是把多个小算子合并成一个大算子减少Kernel Launch开销和中间结果的显存读写。比如LayerNorm后面接一个线性层可以融合成一个算子。这个工作通常在推理框架内部完成但如果你自己写推理代码手动融合收益很明显。我实测过一个场景把Attention里的QKV投影融合后端到端延迟降了约8%。KV Cache是另一个显存大户。自回归生成时每生成一个Token都要缓存之前所有Token的Key和Value显存占用随序列长度线性增长。一个7B模型、32层、隐藏维度4096序列长度2048Batch Size为1时KV Cache大概是2K和V× 32层 × 2048序列 × 4096维度 × 2字节FP16 2 × 32 × 2048 × 4096 × 2 ≈ 2.1 GBBatch Size到20就是42GB直接爆显存。所以KV Cache的量化KV Cache INT8和分页管理PagedAttention是必做的。PagedAttention把KV Cache切成固定大小的块像操作系统管理内存页一样按需分配碎片率大幅降低这也是vLLM的核心创新之一。注意KV Cache量化对精度的影响比权重量化更敏感因为Key和Value直接参与Attention计算。我建议先做权重INT8KV Cache保持FP16如果显存还不够再考虑KV Cache INT8并且一定要验证长文本场景下的表现。3. 引擎层优化推理框架选型与批处理策略3.1 主流推理框架的选型逻辑选推理框架这件事我的原则是看场景、看硬件、看团队没有银弹。市面上主流的几个框架各有脾气vLLMPagedAttention和连续批处理的鼻祖社区活跃支持模型多适合快速起步和通用场景。缺点是自定义算子不如TensorRT-LLM灵活。TensorRT-LLMNVIDIA官方出品算子融合和量化支持最深入性能天花板高但编译流程复杂对模型改动敏感适合追求极致性能且有工程能力的团队。SGLang主打RadixAttention对多轮对话、前缀共享场景优化极好如果你的业务有大量重复前缀比如固定System Prompt它能显著提升缓存命中率。llama.cppCPU和边缘设备友好量化方案成熟适合本地部署和资源受限场景。我一般这样决策如果团队没有专门的推理工程能力直接上vLLM它开箱即用的性能已经能覆盖80%的场景。如果业务对延迟极度敏感、且愿意投入人力做编译优化再考虑TensorRT-LLM。SGLang在特定场景多轮对话、Agent下优势明显值得单独评估。3.2 连续批处理吞吐提升的关键机制连续批处理Continuous Batching是我认为推理引擎里最重要的一个机制没有之一。传统静态批处理要等一个Batch里所有请求都生成完才能处理下一批短请求被长请求拖死GPU利用率很低。连续批处理则是每个生成步都重新组批一个请求生成完了立刻腾出位置给新请求GPU几乎不空转。这个机制带来的吞吐提升是数量级的。我实测过一个7B模型静态批处理下吞吐约800 tokens/s换成连续批处理后直接到3000 tokens/s以上。原因在于静态批处理时Batch里最长的那个请求决定了整体耗时短请求的算力全浪费了。但连续批处理也有代价调度开销和显存碎片。每个生成步都要做一次调度决策请求多了调度本身也会成为瓶颈。所以框架通常会设置最大Batch Size和最大Token数上限需要根据硬件调。3.3 投机解码用“草稿模型”换延迟投机解码Speculative Decoding是降低延迟的一个巧妙思路。核心思想是用一个小的草稿模型Draft Model快速生成多个候选Token再用大模型一次性验证这些Token是否正确。因为大模型验证是并行的比逐个生成快得多如果草稿模型命中率高整体延迟就能显著下降。我实测下来投机解码在输入输出有强模式的场景比如代码补全、格式化输出效果最好草稿模型命中率能到70%以上延迟降低30%到50%。但在开放式创作场景命中率低反而可能因为验证开销导致延迟上升。配置上有几个关键参数草稿模型大小一般是大模型的1/10到1/5太小命中率低太大失去加速意义。投机Token数Speculative Length一次生成几个候选通常4到8个太多会浪费验证算力。接受阈值控制验证的严格程度影响输出质量和速度的平衡。提示投机解码不是万能药一定要在自己的业务数据上测命中率。我见过有人盲目上投机解码结果因为草稿模型和主模型分布差异大命中率不到30%延迟反而涨了。4. 服务层与系统层优化调度、缓存与多卡并行4.1 请求调度与优先级管理到了服务层问题就从“模型怎么跑得快”变成了“请求怎么排得合理”。线上流量从来不是均匀的高峰期和低谷期差好几倍而且请求的优先级也不一样——付费用户的请求和免费用户的请求延迟要求可能完全不同。我的做法是分级队列加动态配额。把请求按优先级分成几档高优先级队列分配更多GPU时间片低优先级队列在资源紧张时主动降级比如降低Batch Size、关闭投机解码。同时设置一个准入控制当队列长度超过阈值时直接拒绝或排队避免雪崩。这里有个容易被忽视的点超时设置。LLM生成是流式的一个请求可能持续几十秒如果客户端超时时间设得太短用户看到的是“请求失败”但服务端还在傻傻地生成浪费算力。我一般会把服务端超时设得比客户端略长并且在客户端断开时及时取消服务端的生成任务。4.2 多级缓存把重复计算挡在门外缓存是服务层性价比最高的优化。LLM场景下有两类缓存特别有价值前缀缓存Prefix Caching很多请求共享相同的前缀比如固定的System Prompt、知识库的检索结果。把这些前缀的KV Cache缓存下来后续请求直接复用能省掉大量重复计算。SGLang的RadixAttention就是干这个的vLLM也支持Prefix Caching。我实测过一个知识库问答场景System Prompt加检索上下文占了输入长度的60%开启前缀缓存后TTFT降低了约40%。语义缓存Semantic Cache把用户问题和对应的回答缓存起来新问题来了先做语义相似度匹配如果和缓存里的问题足够相似直接返回缓存答案。这个对FAQ类场景效果极好但要注意相似度阈值的设置设太低会返回错误答案设太高命中率又上不去。我一般用向量相似度0.95以上才命中并且对时效性敏感的问题比如“今天天气”禁用缓存。4.3 多卡并行张量并行与流水线并行的选择单卡放不下模型时就得上多卡。两种主流并行方式张量并行Tensor Parallelism, TP把每一层的权重切分到多张卡上每张卡算一部分然后通信汇总。优点是延迟低因为每层计算被分摊了缺点是通信量大卡间带宽要求高一般用NVLink。流水线并行Pipeline Parallelism, PP把模型按层切成几段每段放一张卡数据像流水线一样流过。优点是通信量小缺点是会有流水线气泡BubbleGPU利用率下降。我的经验是单机多卡优先用TP跨机用PP。因为TP对带宽要求高跨机网络扛不住PP通信少适合跨机。如果模型特别大两者可以混合使用。另外要注意TP的度数不是越多越好一般不超过8超过后通信开销会吃掉并行收益。并行方式通信量延迟吞吐适用场景张量并行TP大低中单机多卡、NVLink流水线并行PP小中高跨机、大模型数据并行DP无低高多副本、高并发5. 常见问题排查与避坑经验实录5.1 显存溢出OOM的排查路径OOM是推理部署最高频的问题没有之一。排查思路我总结成一个顺序先看权重占用模型加载后显存占了多少如果权重就快把卡占满了那必须量化。再看KV Cache按公式估算最大序列长度和Batch Size下的KV Cache这是动态增长的部分最容易爆。然后看激活值和临时缓冲推理框架会有一些临时显存开销通常不大但别忽略。最后看碎片长时间运行后显存碎片会累积PagedAttention能缓解但重启服务仍是最简单的解法。我遇到过一个典型案例模型权重14GB卡24GB看起来够用但一上并发就OOM。算了一下KV CacheBatch Size到8、序列2048时就超了。解决办法是权重INT8量化到7GBKV Cache开INT8同时限制最大序列长度问题解决。5.2 输出质量下降的归因方法优化之后输出变差怎么定位是哪个环节的锅我的方法是逐层回退先把量化关掉用FP16跑如果质量恢复那就是量化的问题需要调整量化配置或换方案。如果FP16也差检查是不是KV Cache量化或投机解码导致的逐个关闭验证。如果都关了还差那可能是框架本身的实现问题或者输入预处理有bug。这个回退过程虽然笨但最可靠。我一般会准备一个固定的评测集每次改动后跑一遍用数据对比避免凭感觉判断。5.3 常见问题速查表问题现象可能原因排查方向解决手段首Token延迟高输入长、无前缀缓存看输入长度分布开启Prefix Caching、压缩Prompt吞吐上不去Batch Size小、无连续批处理看GPU利用率开连续批处理、调大Batch显存OOM权重KV Cache超限算显存账量化、限制序列长度、PagedAttention输出乱码/重复量化掉点、采样参数问题回退FP16验证调整量化、检查temperature/top_p多卡加速比低通信瓶颈看卡间带宽换TP/PP策略、减少通信长文本性能骤降KV Cache溢出、注意力退化测不同长度KV Cache量化、滑动窗口注意力5.4 几个反直觉的实操心得最后分享几个我在实际项目里踩坑得来的、和常规认知不太一样的经验。第一不是所有场景都值得上量化。如果你的业务对精度极度敏感比如医疗、法律而显存又够用那FP16跑着挺好别为了省那点显存引入风险。我见过一个团队为了省显存上了4bit量化结果在专业术语生成上频繁出错最后回退到FP16白折腾两周。第二Batch Size不是越大越好。大Batch能提升吞吐但会拉高TTFT和TPOT。在线场景下Batch Size超过某个点后用户体感会明显变差。我一般会画一条“吞吐-延迟”曲线找拐点而不是无脑拉满。第三监控比优化本身更重要。优化是一次性的但线上流量是变化的。没有完善的监控TTFT、TPOT、吞吐、显存、GPU利用率、错误率你根本不知道优化有没有效果也不知道什么时候该扩容。我习惯在优化前就把监控埋点做好用数据驱动决策。第四别忽视冷启动。模型加载、编译、预热都需要时间如果服务频繁重启冷启动开销会吃掉大量资源。我一般会做预热请求服务启动后先跑几条典型请求把Kernel编译和缓存暖起来再接入真实流量。第五Prompt长度是隐形的成本杀手。很多人只关注模型和框架却忽略了输入Prompt的长度。输入长度直接决定Prefill阶段的计算量和KV Cache大小。我见过一个RAG系统检索回来的上下文塞了8000个Token其中一大半是无关内容白白浪费算力。精简Prompt、做检索结果重排和截断往往比调框架参数收益更大。这些经验没有一条是教科书上写的都是实际跑线上服务时一点点磨出来的。推理优化这件事理论框架能帮你建立方向感但真正的功夫在细节里——在每一次OOM的排查里在每一条延迟曲线的拐点里在每一个用户反馈的bad case里。把监控做好把评测集建好把回退方案留好然后大胆试、小心验证这才是靠谱的做法。