推理优化这件事很多人第一次接触时都会有个误区以为把模型跑起来就算完事了。实际上一个模型从实验室的FP32权重到真正能在生产环境里稳定响应请求中间要经历的路比想象中长得多。我见过太多团队在GPU上跑通了demo结果一上生产就发现显存爆了、延迟翻了三倍、并发一上来直接OOM。这些问题的根源往往不在模型本身而在于推理优化和部署这一环没做扎实。这篇内容围绕推理优化与部署展开重点聊三件事量化怎么选、蒸馏怎么做、模型怎么选型。适合已经能把模型跑起来、但想让它在真实业务里跑得更快更省的人。不管你是做本地部署、边缘设备推理还是云端服务这里面的取舍逻辑都是通用的。我会尽量把每个决策背后的“为什么”讲清楚而不是只丢一堆参数让你抄。1. 推理优化到底在优化什么1.1 三个核心指标延迟、吞吐、显存做推理优化本质上是在三个维度上做权衡延迟Latency、吞吐Throughput、显存占用Memory Footprint。这三个指标互相拉扯你很难同时把三个都做到最优。延迟指的是单个请求从进到出的时间用户直接感知的就是这个。吞吐指的是单位时间内能处理多少请求直接关系到你的服务成本。显存占用决定了你能不能在有限的硬件上跑起来以及能同时跑几个实例。举个具体的例子。你用FP16精度跑一个7B模型显存大概占14GB左右。如果换成INT8量化显存能压到7GB出头理论上同样一张卡能多跑一个实例吞吐直接翻倍。但代价是什么量化后的模型精度会有损失某些任务上输出质量会下降。这就是典型的吞吐换质量的权衡。再比如你用批处理Batching来提升吞吐把多个请求攒在一起送进模型。批越大GPU利用率越高吞吐越好。但每个请求的延迟会变大因为它要等同一批的其他请求凑齐。这就是吞吐和延迟的权衡。所以做推理优化第一步不是急着上工具而是先搞清楚你的业务场景到底最在意哪个指标。在线对话服务延迟优先离线批量处理吞吐优先边缘设备部署显存优先。目标不同优化路径完全不一样。1.2 为什么“能跑”和“跑得好”差距这么大很多人觉得模型能跑起来就行了但“能跑”和“跑得好”之间的差距可能是一个数量级的成本差异。我拿一个实际场景来说明。假设你有一个13B的模型用原始FP32精度部署。权重文件大概52GB你需要至少一张80GB的卡才能装下而且推理速度很慢因为FP32的计算量是FP16的两倍。这时候你做了几件事转成FP16显存降到26GB速度提升接近一倍再做INT8量化显存降到13GB一张40GB的卡就能跑还能留出空间做KV Cache如果业务允许再上INT4量化显存降到7GB左右消费级显卡都能跑。这一路下来硬件成本可能从一张几万块的卡降到一张几千块的卡而输出质量在大多数任务上下降不到5%。这就是推理优化的价值——它不是锦上添花而是决定你的方案能不能落地、成本能不能接受的关键。还有一个容易被忽略的点推理框架的选择。同样的模型和精度用不同的推理引擎跑性能可能差好几倍。比如ONNX Runtime、TensorRT、vLLM这些框架各自针对不同的场景做了深度优化。选错了框架你可能白白浪费一半的硬件性能。1.3 优化前的基线测量别拍脑袋做决策在动手优化之前有一件事必须做建立基线。你得先知道当前方案在延迟、吞吐、显存三个维度上的具体数字才能判断优化有没有效果、值不值得做。基线测量要覆盖几个关键场景单请求延迟P50和P99都要看、不同并发下的吞吐、峰值显存占用、以及长输入和短输入分别的表现。P99延迟特别重要因为用户感知到的卡顿往往来自那1%的慢请求。测量工具方面可以用简单的压测脚本也可以用专业的推理基准工具。关键是要保证测试条件一致同样的输入长度分布、同样的并发模式、同样的硬件环境。不然你优化前后的数字没有可比性。我自己的习惯是每次做优化之前先跑一轮基线把数字记下来。优化之后再跑一轮对比看提升在哪里、有没有引入新的瓶颈。这个习惯帮我避免了很多次“感觉快了但实际没快”的误判。2. 量化精度换效率的核心手段2.1 量化的基本原理从浮点到整数量化的本质是把模型权重和激活值从高精度浮点数比如FP32、FP16转换成低精度整数比如INT8、INT4。为什么这样做能加速因为整数运算比浮点运算快而且低精度数据占用的显存和带宽更少。具体来说一个FP16的权重占2字节INT8只占1字节INT4只占0.5字节。一个7B模型FP16下权重占14GBINT8下占7GBINT4下占3.5GB。显存占用直接减半再减半这意味着你可以在同样的硬件上跑更大的模型或者跑更多的实例。但量化不是简单地把浮点数截断成整数。它需要一个**缩放因子Scale和零点Zero Point**来做映射。简单说就是把一个浮点数范围线性映射到整数范围。比如把[-1.0, 1.0]映射到[-127, 127]这样每个浮点数都能找到一个对应的整数近似值。反量化的时候再用同样的映射关系还原回去。这个映射过程会引入误差也就是量化误差。误差大小取决于权重的分布和量化的粒度。粒度越细误差越小但计算和存储开销越大。这就是为什么量化方案有那么多变体。2.2 PTQ与QAT两条路线的取舍量化主要分两条路线训练后量化PTQPost-Training Quantization和量化感知训练QATQuantization-Aware Training。PTQ是在模型训练完成之后直接做量化不需要重新训练。优点是快、成本低几分钟到几小时就能搞定。缺点是精度损失可能比较大尤其是量化到INT4这种极低精度时。PTQ适合那些对精度要求不是极致、但想快速降低部署成本的场景。QAT是在训练过程中模拟量化误差让模型“提前适应”低精度环境。具体做法是在前向传播时插入伪量化节点模拟量化带来的误差反向传播时正常更新权重。这样训练出来的模型对量化误差更鲁棒精度损失更小。缺点是需要在训练阶段就介入成本高、周期长。实际选型时我的经验是如果INT8 PTQ的精度损失在可接受范围内比如下降不到2%就直接用PTQ省时省力。如果必须上INT4或者PTQ后精度掉得厉害再考虑QAT。大多数场景下INT8 PTQ已经能带来足够的收益。2.3 INT8、INT4、FP8精度档位怎么选不同精度档位的适用场景差别很大选错了要么浪费硬件要么精度不达标。精度显存占用相对FP16精度损失适用场景FP16100%无对精度要求极高的任务INT850%很小大多数生产场景的首选INT425%中等显存受限、精度要求不苛刻FP850%很小支持FP8的新硬件INT8是目前最成熟的量化方案工具链完善精度损失小大多数任务上几乎感知不到差异。如果你的硬件支持INT8加速大多数现代GPU和推理芯片都支持优先考虑INT8。INT4的显存优势明显但精度损失也更大。它适合那些显存极度受限的场景比如边缘设备、消费级显卡。用INT4的时候建议对关键层比如注意力输出层保留更高精度做混合量化这样能在显存和精度之间找到更好的平衡。FP8是较新的格式在支持它的硬件上比如某些新一代GPU能兼顾精度和速度。如果你的硬件支持值得尝试。但要注意工具链的成熟度不是所有推理框架都完整支持FP8。2.4 量化实操中的坑校准集、层融合与精度回退量化实操里最容易踩的坑是校准集的选择。PTQ需要一个校准集来统计权重和激活值的分布从而确定缩放因子。校准集选得不好量化误差会明显变大。校准集的原则是代表性。它应该覆盖你实际业务中会遇到的输入分布。如果你用一堆短文本做校准结果上线后遇到长文本激活值分布完全对不上精度就会崩。我一般会从真实业务数据里采样几百到几千条覆盖各种长度和类型。另一个坑是层融合Layer Fusion。量化工具通常会把某些层融合在一起比如ConvBNReLU融合后的量化行为可能和预期不一样。有些层对量化特别敏感比如LayerNorm、Softmax这些层通常建议保留高精度。做量化时要检查哪些层被融合了、哪些层被跳过了确保关键层没有被误量化。精度回退是另一个常见问题。有时候量化后模型在某些特定输入上会输出完全错误的结果这就是精度回退。排查方法是先用校准集测一遍看整体精度再针对性地测边界情况比如超长输入、特殊字符、极端数值。发现回退后可以尝试调整量化粒度从per-tensor改成per-channel、换校准集、或者对敏感层做混合精度。提示量化后的模型一定要做完整的回归测试不能只看几个样例就上线。我见过量化后整体指标正常、但特定类别输入全部出错的案例这种问题只有系统测试才能发现。3. 蒸馏让小模型继承大模型的能力3.1 知识蒸馏的核心逻辑软标签的价值知识蒸馏的思路很直观让一个小模型学生模型去学习一个大模型教师模型的输出从而获得接近大模型的性能但参数量和计算量小得多。关键不在于学习最终的硬标签比如分类任务里的正确类别而在于学习教师模型输出的软标签Soft Labels。软标签包含了类别之间的相对概率关系比如“这张图有70%概率是猫、20%是狗、10%是兔子”这种信息比单纯的“这是猫”丰富得多。学生模型通过拟合这些软标签能学到教师模型内部的决策逻辑而不只是死记硬背答案。温度参数Temperature在这里很关键。它用来平滑softmax的输出让软标签的分布更柔和包含更多信息。温度太高分布太平均信息量下降温度太低分布太尖锐退化成硬标签。通常温度设在2到10之间需要根据任务调。3.2 蒸馏的几种变体响应蒸馏、特征蒸馏、关系蒸馏蒸馏不只有一种做法常见的有三类**响应蒸馏Response Distillation**是最基础的形式学生模型直接拟合教师模型的输出层。实现简单适用面广但学生模型只能学到教师模型的最终决策学不到中间过程。**特征蒸馏Feature Distillation**让学生模型拟合教师模型中间层的特征表示。这样学生模型能学到更丰富的内部表示效果通常比响应蒸馏好但需要设计层与层之间的映射关系实现复杂度更高。**关系蒸馏Relation Distillation**让学生模型学习样本之间的关系比如“样本A和样本B的相似度”。这种蒸馏方式不依赖具体的特征值而是学习结构信息在某些任务上效果很好。实际应用中这三种方式经常组合使用。比如同时做响应蒸馏和特征蒸馏让学生模型既拟合输出又拟合中间特征。组合蒸馏的效果通常比单一方式好但调参也更复杂。3.3 蒸馏实操教师模型选择、损失函数设计与训练策略蒸馏实操里教师模型的选择是第一道关。教师模型不一定要越大越好关键是它在你目标任务上的表现要足够好。一个在目标任务上表现优秀的7B模型可能比一个表现一般的70B模型更适合做教师。损失函数的设计也很关键。通常会用KL散度来衡量学生和教师输出分布的差异再加上学生模型在真实标签上的交叉熵损失。两者的权重需要调一般蒸馏损失权重大一些让模型优先学习教师的行为。训练策略上有几个经验值得分享。第一先预热再蒸馏。学生模型先在有标签数据上正常训练一段时间再引入蒸馏损失这样收敛更稳定。第二温度退火。训练初期用较高温度让软标签信息更丰富后期逐渐降低温度让模型更关注正确类别。第三数据增强。蒸馏对数据量要求高数据增强能显著提升效果。还有一个容易被忽略的点学生模型的结构。学生模型不是越小越好太小了容量不够学不到教师的能力。一般建议学生模型的参数量是教师的1/4到1/10具体要看任务复杂度。3.4 蒸馏与量化的组合拳先蒸后量还是先量后蒸蒸馏和量化经常一起用但顺序很重要。先蒸馏后量化是更常见的做法。先用蒸馏得到一个性能不错的小模型再对它做量化。这样量化的对象是一个已经优化过的模型量化误差相对可控。而且蒸馏后的小模型本身参数量就小量化后的显存占用更低。先量化后蒸馏相对少见但也有场景。比如你有一个已经量化好的教师模型想蒸馏出一个更小的学生模型。这种情况下学生模型学的是量化后教师的行为可能继承一些量化误差。一般不推荐除非有特殊需求。我的建议是如果两个都要做先蒸馏再量化。蒸馏解决的是模型容量问题量化解决的是数值精度问题先解决容量再解决精度逻辑更顺。4. 模型选型没有最好只有最合适4.1 选型的第一原则场景决定一切模型选型最容易犯的错是盲目追求“最强模型”。实际上选型的核心原则是场景匹配。你的场景是实时对话还是离线批处理是云端服务还是边缘设备是中文任务还是多语言对延迟的要求是毫秒级还是秒级这些问题的答案直接决定了你应该选什么模型。举个例子。如果你做的是本地部署的文档问答硬件是一张消费级显卡那7B级别的模型加上INT4量化可能是最优解。如果你做的是云端高并发服务那可能需要考虑更大参数的模型配合高效的推理框架用吞吐换单次质量。如果你做的是边缘设备上的实时检测那模型必须足够小可能要用专门为边缘优化的轻量模型。4.2 参数规模与硬件匹配一张表说清楚模型参数规模和硬件的匹配关系是选型时最实际的约束。下面这张表是我根据实际部署经验整理的参考模型规模FP16显存INT8显存INT4显存推荐硬件1-3B2-6GB1-3GB0.5-1.5GB消费级显卡、边缘设备7B14GB7GB3.5GB单张中端显卡13B26GB13GB6.5GB单张高端显卡30B60GB30GB15GB多卡或高端单卡70B140GB70GB35GB多卡集群这张表只是粗略参考实际显存占用还要加上KV Cache、激活值、框架开销等。一般来说实际占用会比权重本身多20%到50%。所以选硬件时显存要留足余量。还有一个关键点显存带宽。很多时候瓶颈不在显存容量而在带宽。低精度量化能减少带宽压力这也是量化能加速的重要原因。选硬件时除了看显存大小也要看带宽指标。4.3 推理框架选型vLLM、TensorRT、ONNX Runtime怎么挑推理框架的选择对性能影响巨大。几个主流框架各有侧重vLLM的核心优势是PagedAttention和连续批处理特别适合高并发的在线服务。它能高效管理KV Cache吞吐表现优秀。如果你做的是API服务vLLM是很值得考虑的方案。TensorRT是NVIDIA的推理优化框架对NVIDIA硬件做了深度优化延迟表现通常最好。但它的模型转换流程相对复杂对非NVIDIA硬件支持有限。如果你追求极致延迟且用NVIDIA硬件TensorRT是首选。ONNX Runtime的跨平台支持最好能在多种硬件上运行部署灵活。性能上不如前两者极致但胜在通用性和易用性。如果你需要跨平台部署ONNX Runtime是稳妥的选择。选框架时还要考虑生态成熟度、社区活跃度、以及和你现有技术栈的兼容性。不要只看benchmark数字实际落地时的工程成本同样重要。4.4 本地部署与云端部署的选型差异本地部署和云端部署的选型逻辑差别很大。本地部署的核心约束是硬件固定。你只能用现有的硬件所以选型时要优先考虑模型能不能装下、能不能跑得动。量化在这里几乎是必选项因为本地硬件通常显存有限。另外本地部署对模型的依赖要少最好能离线运行不依赖外部服务。云端部署的核心约束是成本。你要在满足延迟和吞吐要求的前提下尽可能降低单位请求的成本。这时候选型要考虑的是性价比用多大的模型、什么精度、什么框架能在成本和质量之间找到最优解。云端部署还可以利用弹性伸缩根据负载动态调整实例数量。还有一个差异是更新频率。云端部署可以频繁更新模型本地部署更新成本高。所以本地部署选型时要更看重模型的稳定性和长期可用性。5. 部署落地从权重文件到稳定服务5.1 部署前的检查清单模型部署上线前有一份检查清单能帮你避免大部分低级问题模型权重文件完整校验和正确推理框架版本和模型格式匹配显存占用在硬件限制内留有余量输入输出格式和业务接口对齐异常输入有处理逻辑空输入、超长输入、非法字符并发压力测试通过P99延迟达标日志和监控就位能追踪请求和错误回滚方案准备好出问题能快速切回旧版本这份清单看起来简单但每一条都对应着实际踩过的坑。比如显存余量我见过太多因为没留余量导致高峰期OOM的案例。再比如异常输入处理上线后总会遇到各种意想不到的输入没有兜底逻辑就会直接报错。5.2 服务化封装接口设计与并发处理把模型封装成服务接口设计要考虑几件事请求格式要简单明确响应格式要包含足够的信息比如耗时、token数错误码要能区分不同类型的失败。并发处理是服务化的核心。模型推理本身是计算密集型的并发请求需要合理调度。常见做法是用请求队列加批处理请求先入队攒到一定数量或等待一定时间后一起送进模型。这样能提升GPU利用率但要注意控制队列长度避免延迟无限增长。还有一个细节是超时处理。推理服务一定要设超时不然慢请求会拖垮整个服务。超时后要能优雅地返回错误而不是让请求一直挂着。5.3 监控与调优上线只是开始模型上线不是终点而是起点。上线后要持续监控几个指标延迟分布P50、P95、P99、吞吐量、错误率、显存占用、GPU利用率。延迟分布要特别关注P99因为长尾延迟往往是用户体验的杀手。如果P99明显高于P50说明有慢请求可能是输入长度分布不均、批处理策略不合理、或者有资源竞争。显存占用要监控峰值和趋势。如果显存占用持续增长可能有内存泄漏需要排查。GPU利用率如果长期偏低说明资源没充分利用可以考虑调整批处理策略或增加并发。调优是个持续过程。随着业务变化最优配置也会变。定期回顾监控数据根据实际情况调整参数才能让服务保持最佳状态。5.4 常见故障排查OOM、延迟抖动、精度异常部署后最常见的三类故障是OOM、延迟抖动和精度异常。**OOM显存溢出**通常发生在高峰期或长输入场景。排查时先看显存占用曲线确认是权重占用还是KV Cache占用。如果是KV Cache可以限制最大序列长度或调整批处理策略。如果是权重占用考虑量化或换更小的模型。延迟抖动表现为P99远高于P50。常见原因是批处理策略不合理导致某些请求等待时间过长。也可能是输入长度差异大长输入拖慢了整批。解决办法包括按输入长度分桶、设置合理的批处理超时、或者对长输入单独处理。精度异常表现为输出质量下降或错误。排查时先确认是不是量化导致的可以对比量化前后的输出。如果是量化问题尝试调整量化粒度或换校准集。如果不是量化问题检查输入预处理和输出后处理逻辑看有没有格式转换错误。注意排查故障时一定要有可复现的输入样例。没有复现样例排查效率会低很多。平时就要积累一些边界样例出问题时能快速定位。推理优化和部署这件事说到底是在约束条件下找最优解。没有万能方案只有适合当前场景的方案。量化、蒸馏、选型、部署每个环节都有取舍关键是搞清楚你的约束是什么、目标是什么。我自己的经验是先把基线测清楚再针对瓶颈做优化每次只改一个变量这样效果可衡量、问题可定位。踩过的坑多了慢慢就有手感了。