1. 大模型推理优化到底在优化什么先把话说直白一点大模型推理优化本质上就是在不显著损失输出质量的前提下让模型跑得更快、更省显存、更省钱。这件事听起来像是一句正确的废话但真正动过手的人都知道里面涉及的技术栈和取舍逻辑远比想象中复杂。我见过太多团队在模型训练阶段投入了大量资源模型效果也确实不错但一到上线推理环节就傻眼了——单次请求延迟高得离谱并发一上来显存直接爆掉GPU利用率却低得可怜。这不是模型的问题而是推理链路没有做过系统性优化。推理优化要解决的核心矛盾其实就三个维度之间的拉扯吞吐量Throughput、延迟Latency和显存占用Memory Footprint。这三个指标往往互相制约你压低了延迟吞吐可能就上不去你提高了吞吐单次请求的响应时间可能就变长。所以优化的第一步不是急着上工具而是先搞清楚你的业务场景到底更看重哪个指标。举个很典型的例子。如果你做的是面向C端的实时对话产品用户对首Token延迟极其敏感超过两秒还没出字用户可能就关掉页面了。这种情况下你的优化重心应该放在Prefill阶段的加速上比如通过KV Cache复用、Chunked Prefill等手段来降低首Token时间。但如果你做的是离线批量推理任务比如每天凌晨跑一批文档摘要那延迟就不是核心矛盾你更应该关注的是整体吞吐量和单位算力成本。这两种场景的优化策略几乎是完全不同的用错方向就是白费力气。还有一个容易被忽视的点推理优化不是一次性工作而是一个持续迭代的过程。模型在变、业务流量在变、硬件环境在变今天调好的参数下周可能就不适用了。所以我在实际项目中会建议团队建立一套推理性能的监控基线把TTFTTime To First Token、TPOTTime Per Output Token、吞吐量、显存峰值这些指标持续记录下来每次变更后做对比这样才能知道优化到底有没有效果。注意很多团队一上来就想着量化、蒸馏、换推理框架但连自己的性能瓶颈在哪里都没搞清楚。先用 profiling 工具把链路跑一遍找到真正的瓶颈再动手否则很容易优化了非关键路径白忙一场。2. 推理优化的核心技术手段拆解2.1 模型量化用精度换速度的经典操作量化是推理优化里最常被提到的技术之一逻辑也很朴素把模型权重从FP16降到INT8甚至INT4显存占用直接减半甚至降到四分之一同时矩阵乘法的计算速度也能提升。但量化不是简单地做数值截断里面有不少坑。目前主流的量化方案大致分两类训练后量化PTQ和量化感知训练QAT。PTQ不需要重新训练直接对训练好的模型做量化校准成本低、上手快适合大多数场景。QAT则是在训练阶段就模拟量化误差让模型提前适应低精度计算效果通常更好但需要额外的训练资源和时间。实际操作中我比较推荐先从PTQ入手用GPTQ或AWQ这类成熟的量化方法跑一版看看效果能不能接受。GPTQ的核心思路是逐层量化用校准数据集来最小化量化误差AWQ则更关注激活值中重要的通道对这些通道保留更高的精度。两者各有优劣GPTQ在通用场景下表现稳定AWQ在某些模型上能保留更好的效果。量化过程中最关键的参数是校准数据集的选取。校准集应该尽量贴近你的实际业务数据分布否则量化后的模型在你的场景下可能表现很差。我踩过的一个坑是用通用语料做校准结果模型在专业领域的输出质量下降明显后来换成业务相关的校准数据问题就解决了。2.2 KV Cache优化显存大户的精细管理KV Cache是大模型推理中显存占用的主要来源之一尤其是在长上下文场景下。简单来说自回归生成过程中每个已生成的Token都需要缓存其Key和Value向量避免重复计算。上下文越长、并发越高KV Cache就越大。优化KV Cache的手段主要有几种。PagedAttention是目前最主流的方案之一vLLM就是靠这个技术打出了名气。它的核心思想借鉴了操作系统的虚拟内存分页管理把KV Cache切成固定大小的块按需分配避免了传统连续内存分配带来的碎片浪费。实测下来PagedAttention能把显存利用率提升好几倍吞吐量也跟着大幅上涨。另一种思路是KV Cache量化把缓存的Key和Value也做低精度存储进一步压缩显存。还有滑动窗口注意力和稀疏注意力通过限制注意力的范围来减少缓存需求但这类方法对模型效果的影响需要仔细评估。实操心得KV Cache的显存占用可以用这个公式粗略估算——2 × 层数 × 注意力头数 × 头维度 × 序列长度 × 批大小 × 精度字节数。部署前先算一遍心里有个底避免上线后才发现显存不够。2.3 批处理与调度策略把GPU喂饱GPU最怕的就是闲着。推理过程中如果批大小太小GPU的计算单元大量空闲算力浪费严重。但批处理也不是越大越好批太大会导致延迟上升而且显存可能扛不住。连续批处理Continuous Batching是现在推理框架的标配能力。传统静态批处理要等一整批请求都凑齐了才开始计算而且必须等最慢的那个请求生成完毕才能释放资源。连续批处理则是在每个生成步骤动态地插入新请求、移除已完成请求让GPU始终处于高利用率状态。vLLM、TensorRT-LLM、SGLang这些框架都支持这个能力。调度策略方面需要根据业务特点来调。Prefill和Decode的混合调度是一个关键点——Prefill阶段计算密集Decode阶段显存带宽密集两者混在一起跑容易互相干扰。一些框架支持Chunked Prefill把长Prefill拆成小块和Decode交替执行能有效降低首Token延迟。2.4 推理框架选型没有最好只有最合适目前主流的推理框架有vLLM、TensorRT-LLM、SGLang、TGI等各有侧重。vLLM上手快、社区活跃、PagedAttention加持下吞吐表现优秀适合大多数通用场景。TensorRT-LLM是NVIDIA亲儿子在N卡上的极致性能优化做得最好但上手门槛高编译流程复杂。SGLang在结构化生成和复杂调度场景下有优势。TGI则是HuggingFace生态的一部分集成方便。选型时不要只看benchmark数字要结合自己的团队技术栈、运维能力和业务需求来综合判断。我见过有团队为了追求极致性能上了TensorRT-LLM结果因为编译和调试成本太高反而拖慢了迭代速度。3. 从零搭建推理优化环境的完整流程3.1 硬件环境评估与显存预算动手之前先算账。假设你要部署一个7B参数的模型FP16精度下光权重就需要约14GB显存。如果要做INT4量化权重降到约3.5GB。但这只是开始KV Cache、激活值、框架本身的开销都要算进去。以一个实际场景为例7B模型、INT4量化、上下文长度4096、并发数16。KV Cache的估算大概是2 × 32层 × 32头 × 128维度 × 4096长度 × 16并发 × 2字节 ≈ 4GB左右。加上权重3.5GB和框架开销一张24GB显存的卡基本够用。但如果并发提到64KV Cache就膨胀到16GB这时候要么加卡要么上PagedAttention来压缩。提示显存预算一定要留20%左右的余量不要算得刚刚好。推理过程中会有临时张量分配、内存碎片等问题算太紧容易OOM。3.2 推理框架部署与基础配置以vLLM为例安装过程比较简单pip install vllm启动一个基础服务python -m vllm.entrypoints.openai.api_server \ --model /path/to/your/model \ --dtype auto \ --max-model-len 4096 \ --gpu-memory-utilization 0.9 \ --max-num-seqs 32几个关键参数值得说明。gpu-memory-utilization控制框架能使用的显存比例默认0.9设太高容易OOM设太低浪费显存。max-num-seqs限制同时处理的请求数需要根据显存和延迟要求来调。max-model-len是最大上下文长度设得越大KV Cache预留越多。如果要用量化模型vLLM支持AWQ和GPTQ格式直接指定对应的模型路径即可。但要注意量化模型需要提前用相应工具转换好不能直接拿FP16模型让vLLM自己量化。3.3 性能基准测试与调参部署完成后第一件事是跑基准测试建立性能基线。vLLM自带benchmark脚本python -m vllm.benchmarks.benchmark_serving \ --model /path/to/model \ --num-prompts 100 \ --request-rate 10重点看几个指标请求吞吐量requests/s、输出Token吞吐量tokens/s、TTFT、TPOT。记录下这些数字后续每次调参都做对比。调参的顺序建议是先调max-num-seqs找到吞吐和延迟的平衡点再调gpu-memory-utilization压榨显存利用率最后考虑是否启用量化或调整调度策略。每次只改一个变量否则出了问题都不知道是哪个参数导致的。3.4 监控与持续优化上线之后不能就不管了。建议接入Prometheus Grafana做监控重点关注显存使用率、GPU利用率、请求队列长度、P99延迟这些指标。当请求队列持续增长时说明当前配置扛不住流量了需要考虑扩容或优化。持续优化方面可以定期用新版本的推理框架做对比测试框架迭代很快新版本往往有性能提升。另外根据业务流量的时间分布可以考虑弹性伸缩策略高峰期加实例低峰期减实例控制成本。4. 实战中踩过的坑与排查技巧4.1 显存溢出OOM的常见原因与对策OOM是推理部署中最常见的问题原因通常有几类。一是max-model-len设得太大KV Cache预留过多二是并发数太高KV Cache实际占用超出预期三是框架本身的内存管理有问题比如内存碎片导致无法分配连续空间。排查时先用nvidia-smi看显存占用曲线如果是一启动就OOM多半是模型权重加预留KV Cache超了如果是运行一段时间后OOM可能是内存碎片或某个请求的上下文特别长。对策方面启用PagedAttention能有效缓解碎片问题适当降低max-num-seqs和max-model-len也能快速止血。4.2 输出质量下降的排查思路量化之后输出质量下降是常见问题。排查时先对比量化前后的输出看是普遍性下降还是特定类型问题下降。如果是普遍性下降可能是量化粒度太粗试试更细粒度的量化方案或者换AWQ。如果是特定领域下降多半是校准数据集不匹配换业务相关的校准数据重新量化。还有一种情况是推理框架的采样参数和训练时不一致比如temperature、top_p设得不对导致输出风格变化。这种不是模型本身的问题调采样参数就能解决。4.3 吞吐量上不去的瓶颈定位吞吐量上不去先看GPU利用率。如果GPU利用率很低说明瓶颈在CPU侧或者IO侧可能是请求预处理、Tokenization、网络传输拖了后腿。如果GPU利用率很高但吞吐还是低说明计算本身是瓶颈考虑量化或换更高效的推理框架。还有一个容易忽视的点是批处理效率。如果请求到达速率不稳定批处理经常凑不满GPU就会间歇性空闲。这种情况下可以考虑请求排队策略或者用连续批处理来平滑流量波动。常见问题可能原因排查方法解决对策启动即OOM权重KV Cache超显存计算显存预算降低max-model-len或量化运行中OOM内存碎片或长请求监控显存曲线启用PagedAttention输出质量下降量化误差或采样参数对比量化前后输出换量化方案或调采样参数吞吐量低GPU空闲或计算瓶颈看GPU利用率调批处理或量化首Token延迟高Prefill计算量大测TTFTChunked Prefill或缓存复用4.4 多卡部署的注意事项多卡部署不是简单地把模型切到多张卡上就行。张量并行TP和流水线并行PP是两种主要方案。TP把每一层的计算切到多卡上通信量大但延迟低PP把不同层分到不同卡上通信量小但会有流水线气泡。实际选择要看模型大小和卡间带宽。多卡部署时卡间通信是性能关键。NVLink的带宽远高于PCIe如果卡间是PCIe连接TP的加速效果会大打折扣。另外多卡下的负载均衡也很重要如果某张卡显存先满了整个服务就挂了。5. 推理优化的进阶方向与个人体会5.1 投机采样与推测解码投机采样Speculative Decoding是这两年被讨论很多的加速技术。核心思路是用一个小模型先快速生成一批候选Token再用大模型并行验证如果验证通过就一次性接受多个Token相当于用一次大模型前向换多次生成。实测在代码生成、翻译这类确定性较强的任务上加速比能到2倍以上。但投机采样不是万能的。如果小模型和大模型的输出分布差异太大验证通过率低反而会增加开销。另外投机采样会增加显存占用因为要同时加载两个模型。所以是否使用需要根据任务特点和资源情况来权衡。5.2 结构化输出与约束解码在很多业务场景下模型的输出需要符合特定格式比如JSON、SQL或者特定的模板。传统的做法是生成完再解析解析失败就重试效率很低。约束解码则是在生成过程中就限制Token的选择范围保证输出一定符合格式要求。SGLang在这方面做得比较成熟支持用正则表达式或语法来约束输出。这个能力在Agent、工具调用等场景下特别有用能大幅减少无效生成和重试。5.3 个人在实际项目中的几点体会第一不要过早优化。先把基础链路跑通确认功能没问题再考虑性能优化。我见过团队在功能还没稳定的情况下就开始调推理参数结果每次代码变更都要重新调纯属浪费时间。第二建立性能基线比优化本身更重要。没有基线你根本不知道优化有没有效果。建议在项目初期就搭好监控和benchmark流程后续所有变更都有数据支撑。第三优化是一个系统工程。模型量化、KV Cache管理、批处理调度、框架选型这些手段往往需要组合使用才能达到最佳效果。单独用某一个技术提升可能有限但组合起来效果会好很多。第四关注成本而不只是性能。有时候为了追求极致的延迟上了很贵的硬件但业务本身对延迟并没有那么敏感。反过来有些场景用便宜的硬件加合理的调度策略也能满足需求。技术方案要和业务价值匹配不要为了优化而优化。最后分享一个小技巧在做量化之前先用推理框架自带的profiling工具跑一遍看看时间到底花在哪里。很多时候瓶颈不在模型计算本身而在数据预处理、Tokenization或者网络传输上。找到真正的瓶颈再动手比盲目上量化方案有效得多。