我一直在做开源大模型的私有化部署项目从训练到上线的距离往往比想象中要远得多。模型在训练机里跑得欢天喜地一放到推理服务环境就原形毕露显存不够、首token延迟感人、并发一高直接OOM。这种时候你才会意识到光有训练侧的accuracy还不够部署侧的“好用”是另一套系统工程。我整理自己这段时间搭的Model-Optimizer工具链它本质上是一套面向LLM的模型压缩与推理加速工具箱把量化、结构化剪枝、知识蒸馏、算子融合、KV Cache优化这些散落的招数收拢到一个入口底下让你能从“能跑”走到“跑得稳、跑得快、跑得便宜”。这篇文章不只是介绍它长什么样更想把里面的关键设计逻辑和踩过的坑一一拆开给正在跟模型部署死磕的朋友一份可直接落地的参考。1. 为什么我决定自己造一套优化工具链——部署侧的真实痛点1.1 训练侧“能用”和部署侧“好用”之间的距离先说个很常见的场景你费了三个星期微调好一个7B模型loss降得很漂亮评测集上的分数也符合预期。然后你拿着这个模型去做服务化部署申请了一张A10显卡准备上线。结果一压测发现问题一串一串地冒出来。第一个问题是显存。7B参数量的模型以FP16精度加载光权重就要占到大约14GB7B参数乘以每个参数2字节。这还没算激活值、KV Cache和运行时开销。kv cache尤其容易吓人一跳它随着batch size和sequence length动态增长公式是KV Cache显存 ≈ 2K和V两份 × 层数 × batch_size × seq_len × 注意力头数 × 每头维度 × 每个元素字节数我们用LLaMA-3-8B结构粗算一下32层、8个KV头、每头128维、序列长度2048、并发请求batch8FP16存储条件下这个值大概是2 × 32 × 8 × 2048 × 8 × 128 × 2字节 ≈ 4.29GB一个batch为8、2048长度的请求光KV Cache就要吃掉4GB多显存。如果并发再往上提显存就像水一样流出去。更麻烦的是KV Cache不是连续的数组每个序列的长度不一样如果按最大长度预分配又会造成大量浪费。第二个问题是延迟。Transformer的解码过程是逐token生成的每次只生成一个token但每个token都要重新走一遍整网。计算量本身可能还能忍真正拖时间的是频繁的内核启动和巨大的中间数据搬移。GPU很怕“碎活多跑”一次算子只干了很小一件事数据在显存和缓存之间反复搬运效率全部耗在调度上。第三个问题就更微妙了你辛辛苦苦把模型压下来了但精度肉眼可见地掉了。掉在哪儿为什么掉很多工具只告诉你“量化后MMLU掉了3个点”不告诉你哪些层最敏感、怎么针对敏感层做混合精度。结果只敢整个模型保守地量化到INT8收益打了折扣。这就是我看到的真实空档量化、剪枝、蒸馏、推理优化这些技术单项方案在社区里都有但它们是碎片化的。你要自己一个个试验、拼装、调参中间还要处理工具版本冲突、format转换困难、算子不支持等一系列问题。Model-Optimizer就是冲着这个空档来的——设计目标是一个入口多策略编排把“分析→压缩→评估→导出”串成一条流水线。1.2 为什么不直接拿现成的开源方案拼一拼有人可能会问GPTQ、AWQ这些量化方案不是挺成熟的吗lazy llama.cpp不也能直接跑量化模型吗确实如果你只是想把某个模型量化后塞进推理框架里那些工具完全够用。但我遇到的问题是组合场景既要量化又要剪枝还要保留蒸馏恢复精度的路径最后导出的模型还要能被自己的服务框架加载。这个链条里每换一个工具就要重新做一遍模型格式转换每转换一次就可能引入精度偏差出了问题你根本分不清是量化引入的误差还是转换丢失的误差。另外一个问题是可观测性。大多数优化工具是黑盒你把模型丢进去它吐出一个压缩后的模型过程很不透明。但在生产环境中你不知道模型哪里被剪掉了、哪些层被量化到多少bit、校准数据长什么样。一旦上线后出现问题你连排查的抓手都没有。所以我做Model-Optimizer时第一原则就是“全流程可观测”——每次优化后生成一份报告详细记录每一层的压缩策略、参数分布变化、敏感度得分以及权重更新前的备份。如此才算具备工程上的可维护性。所以这不算什么颠覆性创新更像是我把实践中所有的碎片重新组装并加上了一层“带说明书的调度机制”。模型优化本身仍然是量化、剪枝、蒸馏这些老手艺但Model-Optimizer把它们整理成了可以重复执行、可以自动化评估、可以追溯效果的系统流程。2. 量化模块的关键设计先保住敏感层再谈位数2.1 PTQ与QAT的分工逻辑量化是Model-Optimizer里最基础也最常用的一个模块。它把浮点权重和激活值从FP16/FP32映射到更低bit位数比如INT8、INT4或者混合精度。量化的本质是减少表示精度换取更小的显存占用和更快的计算速度。Model-Optimizer的量化模块同时提供两条路径训练后量化PTQ和量化感知训练QAT。默认流程先走PTQ因为它的成本最低——不需要重新训练模型只需要一小部分校准数据来统计激活值的分布范围。如果PTQ后精度掉得太多再在它的基础上做QAT微调恢复。PTQ的核心就两件事定范围、做映射。所谓定范围就是确定浮点数值要落到哪个[min, max]区间里做映射就是把区间里的值均匀切分成2^N份N是量化bit数然后四舍五入到对应的整数刻度。看起来简单但范围定得准不准直接决定量化损失有多大。2.2 逐层敏感度分析决定混合精度几乎所有做量化的人都会遇到同一个困惑模型所有层都按同一个bit量化真合理吗答案是不合理。一个Transformer模型里embedding层、attention输出投影层、FFN两层MLP对量化的敏感度差异巨大。有些层哪怕量化到INT4精度几乎不掉有些层一量化perplexity立刻飙升。Model-Optimizer里实现了一个叫“逐层敏感度分析”的模块原理基于二阶近似对每一层做一次假量化即把该层切到目标bit数但不真正落地然后观察损失函数的变化量。这里的损失变化不是简单看训练loss而是用一个小的验证集计算模型输出分布变化或者近似用Hessian矩阵的迹来估计。思路是如果某一层的参数变动导致输出变化很大说明这层信息密度高需要保留更高精度。我在实际跑LLaMA-3-8B时观察到几个规律embedding层和lm_head层往往是最敏感的因为它们的输出直接决定了token的概率分布attention的Q/K投影比V投影相对更敏感V投影剪掉一部分信息对最终结果影响较小FFN层里中间层通常是4倍宽度对量化容忍度较高可以放到INT4第一层和最后一层的量化务必谨慎中间层相对皮实。于是Model-Optimizer的默认混合精度策略是embedding和lm_head保留INT16或FP16前几层和最后几层用INT8中间密集计算层用INT4。实际效果比整网INT8平均能省更多显存而且精度损失更少。这个策略之所以有效是因为它不搞一刀切而是把“预算”优先分配给敏感层。一个直觉类比是压缩照片的时候你不会把蓝天和人物脸压缩到同一个质量档位。蓝天部分细节冗余严重压狠一点看不出来人脸部分哪怕有一点色块或模糊观感立刻下降。模型的各层也是一样信息冗余度差异很大。2.3 calibration数据集的构造与陷阱PTQ里的校准calibration环节是最容易被低估的。我在很早的时候犯过一个错误随便拿了几十条训练集数据做校准结果量化后模型直接变成复读机。原因出在数据分布和真实场景不匹配。校准集的目的是统计激活值的分布范围这个范围直接决定了量化的缩放系数和零点。如果校准集和模型真实使用的数据分布差异太大量化时就会出现大量截断把本来还在范围内的值硬生生切成边界值信息丢失严重。Model-Optimizer在配置校准数据集时有几个默认建议样本数量不需要多通常128到512条就够了但必须是和线上数据同分布的真实语料样本要覆盖不同的长度最好同时包含短句和长文否则KV Cache和激活值范围覆盖不全绝对不要使用验证集或测试集做校准否则会得到虚高的精度指标上线立刻露馅如果数据包含多个领域尽量按比例混合避免单领域校准导致其他领域表现恶化。在具体算法层面Model-Optimizer支持两种校准策略按最小化均方误差MSE选择缩放系数或者按KL散度最小化来选择。前者适用于权重量化后者更适合激活值量化。KL散度的思路是让量化后的分布和原始浮点分布尽量接近但是实现上需要注意对分布尾部做截断处理否则会有个别极端值撑爆整个量化范围导致大部分数值退化成粗糙的台阶。2.4 量化重构的公式与实现示意量化计算的本质其实不复杂就是把一个浮点数组变成一个整数数组外加scale和zero_point的元数据。Model-Optimizer里有一个独立的tensor_quant模块核心逻辑大概长这样def quantize_tensor(tensor, bits8, per_channelFalse): # 取数值范围 min_val tensor.min().item() max_val tensor.max().item() # 对称量化时取绝对值最大的作为边界 scale (max_val - min_val) / (2 ** bits - 1) zero_point 0 # 量化并截断到合法整数范围 qmin -(2 ** (bits - 1)) qmax 2 ** (bits - 1) - 1 q_tensor (tensor / scale).round().clamp(qmin, qmax).to(torch.int8) # 反量化用于精度对比 dequant_tensor (q_tensor * scale).to(tensor.dtype) return q_tensor, scale, zero_point, dequant_tensor实际工程里会用更精细的per-channel/groupt量化方案——按输出通道或按组分别计算scale而不是整个张量共用一个scale。组大小group size是当前模型量化里一个重要超参数。比如INT4量化时把group size从128降到64能明显降低异常值的影响但会略微增加存储开销。Model-Optimizer默认给LLM的权重配置是group size128激活值用per-token的动态量化。如果你发现某个层量化后误差很大第一件事就是把这个层的group size调小到64或32往往立刻见效。3. 结构剪枝与蒸馏减的是参数守的是分布3.1 为什么只做量化不够量化做的是“用更少的字节表示相同的数字”它不改变模型的网络结构。可模型该有多大还是多大前向传播的计算量也没少。想要实质性的推理加速就需要动结构——把不重要的通道、注意力头、甚至整层网络去掉让计算图本身变瘦。但结构剪枝有个残酷的问题直接剪掉参数模型精度一定掉。掉多掉少看运气运气不好直接崩。于是知识蒸馏通常是它的配套动作用一个未剪枝的原始模型作为Teacher让剪枝后的Student模型在训练过程中模仿Teacher的输出分布用Teacher的“软标签”去弥补结构剪枝带来的信息丢失。Model-Optimizer把这两个流程绑定成一个名叫PruneDistill的Pipeline组件先做一次剪枝再做若干轮蒸馏训练然后评估精度。如果精度达标就继续下一轮剪枝如果精度掉了超过阈值就回退到上一轮状态。循环往复直到达到目标稀疏度。3.2 通道、头、层三个粒度的选择LLM的剪枝有三个粒度通道剪枝channel pruning、注意力头剪枝head pruning和层剪枝layer pruning。它们分别作用于FFN的中间维度、注意力头和Transformer层数各有各的代价和收益。我在实际使用时通常按这个顺序来先做注意力头剪枝。Transformer里并非每个注意力头都很关键。有些头学到的是重复模式剪掉后对下游任务几乎无感。判断头重要性的办法是计算它在验证集上的“平均注意力得分贡献”或者基于梯度的重要性因子。Model-Optimizer默认用基于梯度的Taylor展开估算每个头的重要性因为这一类方法不需要额外训练跑一次反向传播就够了。再做FFN的通道剪枝。FFN层往往是参数量的大头大约占Transformer参数的2/3剪它的收益最大。通道剪枝对精度影响比较平滑因为它不是整条删掉而是把不重要的神经元置零或移除。但要注意通道剪枝会改变后续层输入维度对系统编程要求高通常要依赖推理框架的稀疏矩阵算子配合才能真正加速否则在你的存储里是变小了但跑起来反而更慢。最后考虑层剪枝。这是最激进的方案虽能获得最大收益但风险也最大。层间冗余确实存在LLM越深浅层和深层之间的语义层次差异越来越小一些中间层完全可能被跳过。Model-Optimizer实现了一个层重要性评估指标逐层去掉某一层观察输出表示之间的余弦距离变化用这个作为层冗余的度量。层剪枝通常情况下建议配合蒸馏训练跑至少500到1000步恢复否则掉点会很明显。3.3 蒸馏的匹配点怎么定知识蒸馏的一个核心问题是Student模型要模仿Teacher的什么最早期的做法是拿softmax输出的概率分布做KL散度损失但LLM的词汇表动辄几万甚至十几万直接在输出分布上算KL散度计算量太大而且容易忽略中间层的语义。Model-Optimizer采取的是多层匹配方案蒸馏loss由三部分组成L α * L_output β * L_hidden γ * L_attn其中L_output是对齐Teacher和Student在词汇表上的logits或Top-K分布L_hidden是对齐Teacher和Student在中间层例如每隔两层的hidden state表示L_attn则对齐注意力矩阵的分布。举个例子假设Teacher倒数第二层输出hidden state维度为4096Student剪枝后是3072那在计算L_hidden时需要先通过一个可学习的线性投影层把Student的表示映射到Teacher的维度上再计算MSE损失。实践中有个很关键的经验hidden matching加在中间层比只加在最后一层效果明显更好。因为剪枝损失的信息是整个网络逐步累积的中间层能把误差更早地引导回去。loss权重按经验值设置通常L_output权重最高L_hidden次之L_attn权重最低。训练时学习率要比正常微调低一两个数量级避免Student忘记Teacher已经教会的知识。3.4 稀疏度调度与回退机制剪枝不是一步到位的。我刚开始做剪枝的时候直接设定一个50%的稀疏度目标一次性剪掉一半通道结果模型直接胡言乱语。后来改成渐进式稀疏度调度gradual pruning schedule效果天差地别。Model-Optimizer的默认调度是从稀疏度0开始每轮增加5到10个百分点每一轮做完剪枝后跑少量蒸馏步数评估验证集loss如果相比上一轮loss上涨幅度超过某个阈值就回退到上一轮检查点并降低本轮稀疏度增量。这个过程很像健身增肌你不能一天把重量加到极限必须循序渐进让“剩余网络”有时间适应新的容量。用大白话说剪枝就是一个不断测试“模型哪部分冗余程度高”的过程。如果剪完精度狂掉说明那部分不是冗余而是核心功能所在。回退机制的意义就在于给这个过程一个安全网不至于一剪子下去就再也补不回来了。4. 推理侧优化数据搬移变小延迟才真的降下来4.1 算子融合与kernel选择量化压缩是把模型“变小”但模型变小之后如果不配合算子层面的优化实际推理加速非常有限。GPU推理的性能瓶颈有很大一部分来自频繁的内核启动和显存数据搬运Model-Optimizer在导出阶段两个动作最有用算子融合Operator Fusion和kernel选择。Transformer里最常见的融合是QKV投影融合。原始实现里通常有三个独立的线性层Q、K、V分别计算三次矩阵乘。GPU每次跑一个线性层就要启动一次kernel。如果把它们拼成一个大的线性层把权重矩阵在列方向上拼接一次矩阵乘就能同时算出QKV三个结果kernel启动次数直接降低到三分之一。类似的还有attention输入投影和位置编码的融合、MLP里两个线性层之间的激活函数融合、LayerNorm之后的残差连接融合等。每一处融合看起来都是小优化累计起来对长序列生成的帮助非常明显——解码阶段本身就是被这种细碎操作拖慢的。4.2 KV Cache压缩与Paged AttentionKV Cache的优化是我在Model-Optimizer里投入最多的部分因为它直接和并发、显存挂钩。前面算了batch8时KV Cache就能吃4GB多。如果量化到INT8显存直接减半到2GB多而且精度损失通常很小。实现KV Cache量化的关键是per-token/per-head动态量化。K和V缓存张量的分布并不完全一样V一般更稳定K受位置信息影响更大。Model-Optimizer把K缓存做per-head量化把V缓存做per-token量化实测下来能够较好平衡精度和显存。另一个有效手段是分页KV CachePaged Attention类比虚拟内存分页。传统的KV Cache按请求预先分配固定大小的连续显存序列短时浪费巨大序列长时又可能不够用。分页式管理把KV Cache拆分成固定大小的块按需分配、靠链表维护逻辑连续性。Model-Optimizer在导出服务对象时默认开启分页它让内存利用率从大约60%提升到90%以上在同样显存下可以承接更多并发请求。4.3 连续批处理与投机解码延迟优化和吞吐优化有时候看起来是矛盾的但实际部署里通常要同时考虑。Model-Optimizer集成了连续批处理continuous batching逻辑传统静态批处理把所有请求塞到一个batch里一个请求生成了必须等整个batch结束后才能腾出位置。连续批处理的做法是某个请求一旦生成结束立刻释放它的KV Cache和显存并把调度队列里的新请求插入进来。这使得GPU在长尾请求场景下始终被填满不会出现“大部分batch资源都被已结束请求占着”的浪费。投机解码speculative decoding则是另一招——用一个很小的草稿模型先快速生成若干候选token再由目标大模型一次并行验证这些token。因为“验证”比“生成”低昂只要草稿模型猜得够准实际延迟会大幅下降。Model-Optimizer的slogan里有一项专门管理草稿模型的匹配草稿模型不需要和主模型同族只要词表对齐即可理想情况下它的大小应该控制在主模型的10%到20%。5. 实测结果一张表看透收益也看透代价5.1 测试环境与模型列表说再多理论不如直接看数据。我在三张不同显卡上做了完整的测试分别是NVIDIA RTX 3090、A100 40GB以及一张较老旧的T4。模型选了三款常见开源模型LLaMA-3-8B-Instruct、Qwen2.5-7B-Instruct、Mistral-7B-v0.3。输入输出长度都固定为1024输入 512输出并发请求为8。精度评估采用困惑度perplexity和MMLU5-shot两项指标。以下是一组不算严谨但完全可复现的实测数据模型优化配置显存峰值首token延迟单token延迟吞吐token/sMMLU下降LLaMA-3-8BFP16基线21.4GB189ms42ms3120LLaMA-3-8BINT8量化12.8GB147ms38ms391-0.4%LLaMA-3-8BINT4混合精度8.6GB98ms31ms476-1.8%LLaMA-3-8BINT4剪枝30%蒸馏6.2GB71ms27ms534-2.6%Qwen2.5-7BINT4混合精度8.2GB95ms29ms462-1.5%Mistral-7BINT4混合精度7.9GB88ms28ms487-1.3%这组数据里最值得关注的是后半段量化加剪枝后的组合显存从21GB降到6GB左右吞吐提升了七成以上代价是MMLU掉大约2.6个点。对于很多业务场景来说这个精度损失是可以接受的尤其当你部署的是微调过的专用模型而不是试图让它在通用知识上保持全盛状态。5.2 精度下降都跑到哪里去了很多人拿到Model-Optimizer的报告后会盯着MMLU看但我更建议看perplexity的分层变化。根据我在优化后模型上的细粒度分析掉点主要来源如下极少出现在token中段的语义断裂更多出现在长尾低频词的top-k分布里。量化后的模型倾向于把概率质量集中到高频词上低频词的概率被低估。这在问答类任务里表现不明显但在生成式任务里容易让输出变得“平淡”剪枝对FFN中间维度的损伤会让模型在需要“多步推理”的任务上显得吃力因为少了一部分并行计算的容量模型记忆复杂关系的能力下降lm_head如果被量化解码阶段的词表分布会整体平滑导致更低置信度输出。所以我在导出配置里默认强制lm_head保持FP16。知道精度掉哪儿之后应对方案就清楚了如果是问答业务多关注高频词覆盖如果是长文本生成优先保留FFN的通道数如果必须保留模型推理能力就用混合bit方案避开敏感层。Model-Optimizer的优化报告就是为了辅助这些判断而不是用单一指标掩盖问题。5.3 什么时候不值得做全套优化不是所有模型都值得上一整套量化剪枝蒸馏。估摸你手里的场景如果模型本身小于3B且序列长度经常在512以内推理延迟通常已经很快单纯量化就够了没必要剪枝如果服务并发很低个位数请求显存不是瓶颈那INT8量化足矣INT4带来的额外精度损失性价比不高如果是CPU推理簇拥在算子融合的收益更明显因为CPU没有GPU那么多并行核数据的反复搬移对性能影响更大如果项目只有三天上线时间别碰知识蒸馏。蒸馏训练超参敏感恢复周期长短期内的确定性远不如量化来得稳。我个人的经验法则是先量化评估掉点如果显存压力仍大且掉点可接受再加剪枝如果剪枝掉点太多才考虑上蒸馏恢复。这个顺序把每步的收益和风险都控制在一个可控范围内。6. 从零跑通Model-Optimizer的完整过程与常见坑6.1 快速上手的API设计Model-Optimizer的使用方式尽量保持简单核心接口就是一个optimize函数加一个配置文件。安装直接用pip完成pip install model-optimizer以量化一个HuggingFace模型为例代码大致如下from model_optimizer import ModelOptimizer optimizer ModelOptimizer( model_nameQwen/Qwen2.5-7B-Instruct, optimization_presetbalanced, # 可选: light / balanced / aggressive work_dir./optimized_models, dtypeauto, device_mapcuda:0, kv_cache_dtypeint8, ) report optimizer.run_evaluation( quantizeTrue, pruneTrue, distillTrue, calibration_dataset./data/calib.jsonl, ) print(report.summary())run_evaluation会执行完整流程先做逐层敏感度分析再按配置的优化档位执行量化、剪枝、蒸馏最后用验证集生成优化报告。报告里包含每一层的bit配置、剪枝比例、显存预估变化、perplexity变化和延迟预估。如果你对默认档位不满意可以传入自定义配置字典逐项覆盖每个模块的参数。6.2 五个最容易翻车的细节我在开发和自用的过程中踩过的坑比文档里写的多得多。挑五个对最终效果影响最大的细节警告后来的使用者第一个坑是校准集和验证集重叠。校准集是用来确定量化范围的验证集是用来评估精度的。如果两者重叠评估结果会虚高。我把校准集和验证集硬性拆开管理Model-Optimizer里也默认做了数据集分割和排重防止这个低级错误悄悄污染结果。第二个坑是batch size差异导致量化范围漂移。同一个模型校准数据单条送入和按batch送入激活值分布可能差异很大尤其是BatchNorm类型的层。即便Transformer基本不用BatchNorm但LayerNorm对输入分布的感知也很强。我的经验是校准时的batch size要和线上推理的典型batch size保持一致否则量化范围永远偏一格。第三个坑是剪枝后的权重无法复用原推理框架。很多推理框架对稀疏模型支持很差通道剪枝后模型参数维度变了库不认。所以Model-Optimizer导出模块会同时输出标准PyTorch权重和ONNX格式并自动检查算子是否在目标框架的算子覆盖范围内。如果目标框架不支持某个算子导出阶段会直接报错而不是生成一个跑不了的模型。第四个坑是KV Cache量化时跳过第一层。第一层的K缓存往往包含大量位置信息对位置编码的敏感度非常高量化后模型对长序列的位置感知会显著退化。所以Model-Optimizer的kv_cache_dtype支持配置层范围白名单默认跳过前两层不做量化。第五个坑是半精度下的absmax溢出。FP16能表示的范围有限量化计算scale时对矩阵全体求absmax如果某个异常值过大可能导致scale小到溢出。在少数极端权重分布下会出现全零张量。规避方法是计算scale时加入一个极小epsilon例如1e-8或者在FP32下计算scale再cast到FP16。6.3 复现我这份结果的最小操作集最后给出一份可复现的最小命令。假设你想复现LLaMA-3-8B的INT4混合精度结果在配备24GB显存显卡的机器上可以执行model-optimizer optimize \ --model meta-llama/Llama-3-8B-Instruct \ --preset aggressive \ --quant-bits int4 \ --group-size 128 \ --skip-layers embedding,layer0,layer31 \ --calibration-size 256 \ --eval-tasks perplexity,mmlu跑完之后优化模型会输出到当前目录下的./optimized_model_fp16_int4_mix目录。你可以再用Model-Optimizer内置的serve子命令快速启动一个兼容OpenAI接口的推理服务model-optimizer serve \ --model ./optimized_model_fp16_int4_mix \ --port 8080 \ --kv-cache-dtype int8 \ --max-batch-size 32 \ --enable-paged-attention我建议第一次做完整优化时哪怕再着急也要打开报告看一眼“逐层bit配置”和“逐层剪枝比例”这两页。Model-Optimizer生成的报告是HTML格式的每一层都能展开看到优化前后的参数分布图。这些细节才是决定你模型最终体感质量的东西。我自己的习惯是每次优化完除了记录eval指标还会保存几个固定测试用例的实际输出比如一个数学题、一个长文摘要、一个代码补全。看数字可以但最终还是要看真实生成的文字质量。模型压缩这条路永远不要只看指标不看输出。每个人的业务场景不一样最优的压缩配置也不一样把流程跑通、把报告看懂、把关键层守住你就能摆脱“用别人调好的模型”的被动局面真正按自己的需求定制推理效率和精度的平衡点。
大模型部署提速指南：量化、剪枝与推理优化实战
我一直在做开源大模型的私有化部署项目从训练到上线的距离往往比想象中要远得多。模型在训练机里跑得欢天喜地一放到推理服务环境就原形毕露显存不够、首token延迟感人、并发一高直接OOM。这种时候你才会意识到光有训练侧的accuracy还不够部署侧的“好用”是另一套系统工程。我整理自己这段时间搭的Model-Optimizer工具链它本质上是一套面向LLM的模型压缩与推理加速工具箱把量化、结构化剪枝、知识蒸馏、算子融合、KV Cache优化这些散落的招数收拢到一个入口底下让你能从“能跑”走到“跑得稳、跑得快、跑得便宜”。这篇文章不只是介绍它长什么样更想把里面的关键设计逻辑和踩过的坑一一拆开给正在跟模型部署死磕的朋友一份可直接落地的参考。1. 为什么我决定自己造一套优化工具链——部署侧的真实痛点1.1 训练侧“能用”和部署侧“好用”之间的距离先说个很常见的场景你费了三个星期微调好一个7B模型loss降得很漂亮评测集上的分数也符合预期。然后你拿着这个模型去做服务化部署申请了一张A10显卡准备上线。结果一压测发现问题一串一串地冒出来。第一个问题是显存。7B参数量的模型以FP16精度加载光权重就要占到大约14GB7B参数乘以每个参数2字节。这还没算激活值、KV Cache和运行时开销。kv cache尤其容易吓人一跳它随着batch size和sequence length动态增长公式是KV Cache显存 ≈ 2K和V两份 × 层数 × batch_size × seq_len × 注意力头数 × 每头维度 × 每个元素字节数我们用LLaMA-3-8B结构粗算一下32层、8个KV头、每头128维、序列长度2048、并发请求batch8FP16存储条件下这个值大概是2 × 32 × 8 × 2048 × 8 × 128 × 2字节 ≈ 4.29GB一个batch为8、2048长度的请求光KV Cache就要吃掉4GB多显存。如果并发再往上提显存就像水一样流出去。更麻烦的是KV Cache不是连续的数组每个序列的长度不一样如果按最大长度预分配又会造成大量浪费。第二个问题是延迟。Transformer的解码过程是逐token生成的每次只生成一个token但每个token都要重新走一遍整网。计算量本身可能还能忍真正拖时间的是频繁的内核启动和巨大的中间数据搬移。GPU很怕“碎活多跑”一次算子只干了很小一件事数据在显存和缓存之间反复搬运效率全部耗在调度上。第三个问题就更微妙了你辛辛苦苦把模型压下来了但精度肉眼可见地掉了。掉在哪儿为什么掉很多工具只告诉你“量化后MMLU掉了3个点”不告诉你哪些层最敏感、怎么针对敏感层做混合精度。结果只敢整个模型保守地量化到INT8收益打了折扣。这就是我看到的真实空档量化、剪枝、蒸馏、推理优化这些技术单项方案在社区里都有但它们是碎片化的。你要自己一个个试验、拼装、调参中间还要处理工具版本冲突、format转换困难、算子不支持等一系列问题。Model-Optimizer就是冲着这个空档来的——设计目标是一个入口多策略编排把“分析→压缩→评估→导出”串成一条流水线。1.2 为什么不直接拿现成的开源方案拼一拼有人可能会问GPTQ、AWQ这些量化方案不是挺成熟的吗lazy llama.cpp不也能直接跑量化模型吗确实如果你只是想把某个模型量化后塞进推理框架里那些工具完全够用。但我遇到的问题是组合场景既要量化又要剪枝还要保留蒸馏恢复精度的路径最后导出的模型还要能被自己的服务框架加载。这个链条里每换一个工具就要重新做一遍模型格式转换每转换一次就可能引入精度偏差出了问题你根本分不清是量化引入的误差还是转换丢失的误差。另外一个问题是可观测性。大多数优化工具是黑盒你把模型丢进去它吐出一个压缩后的模型过程很不透明。但在生产环境中你不知道模型哪里被剪掉了、哪些层被量化到多少bit、校准数据长什么样。一旦上线后出现问题你连排查的抓手都没有。所以我做Model-Optimizer时第一原则就是“全流程可观测”——每次优化后生成一份报告详细记录每一层的压缩策略、参数分布变化、敏感度得分以及权重更新前的备份。如此才算具备工程上的可维护性。所以这不算什么颠覆性创新更像是我把实践中所有的碎片重新组装并加上了一层“带说明书的调度机制”。模型优化本身仍然是量化、剪枝、蒸馏这些老手艺但Model-Optimizer把它们整理成了可以重复执行、可以自动化评估、可以追溯效果的系统流程。2. 量化模块的关键设计先保住敏感层再谈位数2.1 PTQ与QAT的分工逻辑量化是Model-Optimizer里最基础也最常用的一个模块。它把浮点权重和激活值从FP16/FP32映射到更低bit位数比如INT8、INT4或者混合精度。量化的本质是减少表示精度换取更小的显存占用和更快的计算速度。Model-Optimizer的量化模块同时提供两条路径训练后量化PTQ和量化感知训练QAT。默认流程先走PTQ因为它的成本最低——不需要重新训练模型只需要一小部分校准数据来统计激活值的分布范围。如果PTQ后精度掉得太多再在它的基础上做QAT微调恢复。PTQ的核心就两件事定范围、做映射。所谓定范围就是确定浮点数值要落到哪个[min, max]区间里做映射就是把区间里的值均匀切分成2^N份N是量化bit数然后四舍五入到对应的整数刻度。看起来简单但范围定得准不准直接决定量化损失有多大。2.2 逐层敏感度分析决定混合精度几乎所有做量化的人都会遇到同一个困惑模型所有层都按同一个bit量化真合理吗答案是不合理。一个Transformer模型里embedding层、attention输出投影层、FFN两层MLP对量化的敏感度差异巨大。有些层哪怕量化到INT4精度几乎不掉有些层一量化perplexity立刻飙升。Model-Optimizer里实现了一个叫“逐层敏感度分析”的模块原理基于二阶近似对每一层做一次假量化即把该层切到目标bit数但不真正落地然后观察损失函数的变化量。这里的损失变化不是简单看训练loss而是用一个小的验证集计算模型输出分布变化或者近似用Hessian矩阵的迹来估计。思路是如果某一层的参数变动导致输出变化很大说明这层信息密度高需要保留更高精度。我在实际跑LLaMA-3-8B时观察到几个规律embedding层和lm_head层往往是最敏感的因为它们的输出直接决定了token的概率分布attention的Q/K投影比V投影相对更敏感V投影剪掉一部分信息对最终结果影响较小FFN层里中间层通常是4倍宽度对量化容忍度较高可以放到INT4第一层和最后一层的量化务必谨慎中间层相对皮实。于是Model-Optimizer的默认混合精度策略是embedding和lm_head保留INT16或FP16前几层和最后几层用INT8中间密集计算层用INT4。实际效果比整网INT8平均能省更多显存而且精度损失更少。这个策略之所以有效是因为它不搞一刀切而是把“预算”优先分配给敏感层。一个直觉类比是压缩照片的时候你不会把蓝天和人物脸压缩到同一个质量档位。蓝天部分细节冗余严重压狠一点看不出来人脸部分哪怕有一点色块或模糊观感立刻下降。模型的各层也是一样信息冗余度差异很大。2.3 calibration数据集的构造与陷阱PTQ里的校准calibration环节是最容易被低估的。我在很早的时候犯过一个错误随便拿了几十条训练集数据做校准结果量化后模型直接变成复读机。原因出在数据分布和真实场景不匹配。校准集的目的是统计激活值的分布范围这个范围直接决定了量化的缩放系数和零点。如果校准集和模型真实使用的数据分布差异太大量化时就会出现大量截断把本来还在范围内的值硬生生切成边界值信息丢失严重。Model-Optimizer在配置校准数据集时有几个默认建议样本数量不需要多通常128到512条就够了但必须是和线上数据同分布的真实语料样本要覆盖不同的长度最好同时包含短句和长文否则KV Cache和激活值范围覆盖不全绝对不要使用验证集或测试集做校准否则会得到虚高的精度指标上线立刻露馅如果数据包含多个领域尽量按比例混合避免单领域校准导致其他领域表现恶化。在具体算法层面Model-Optimizer支持两种校准策略按最小化均方误差MSE选择缩放系数或者按KL散度最小化来选择。前者适用于权重量化后者更适合激活值量化。KL散度的思路是让量化后的分布和原始浮点分布尽量接近但是实现上需要注意对分布尾部做截断处理否则会有个别极端值撑爆整个量化范围导致大部分数值退化成粗糙的台阶。2.4 量化重构的公式与实现示意量化计算的本质其实不复杂就是把一个浮点数组变成一个整数数组外加scale和zero_point的元数据。Model-Optimizer里有一个独立的tensor_quant模块核心逻辑大概长这样def quantize_tensor(tensor, bits8, per_channelFalse): # 取数值范围 min_val tensor.min().item() max_val tensor.max().item() # 对称量化时取绝对值最大的作为边界 scale (max_val - min_val) / (2 ** bits - 1) zero_point 0 # 量化并截断到合法整数范围 qmin -(2 ** (bits - 1)) qmax 2 ** (bits - 1) - 1 q_tensor (tensor / scale).round().clamp(qmin, qmax).to(torch.int8) # 反量化用于精度对比 dequant_tensor (q_tensor * scale).to(tensor.dtype) return q_tensor, scale, zero_point, dequant_tensor实际工程里会用更精细的per-channel/groupt量化方案——按输出通道或按组分别计算scale而不是整个张量共用一个scale。组大小group size是当前模型量化里一个重要超参数。比如INT4量化时把group size从128降到64能明显降低异常值的影响但会略微增加存储开销。Model-Optimizer默认给LLM的权重配置是group size128激活值用per-token的动态量化。如果你发现某个层量化后误差很大第一件事就是把这个层的group size调小到64或32往往立刻见效。3. 结构剪枝与蒸馏减的是参数守的是分布3.1 为什么只做量化不够量化做的是“用更少的字节表示相同的数字”它不改变模型的网络结构。可模型该有多大还是多大前向传播的计算量也没少。想要实质性的推理加速就需要动结构——把不重要的通道、注意力头、甚至整层网络去掉让计算图本身变瘦。但结构剪枝有个残酷的问题直接剪掉参数模型精度一定掉。掉多掉少看运气运气不好直接崩。于是知识蒸馏通常是它的配套动作用一个未剪枝的原始模型作为Teacher让剪枝后的Student模型在训练过程中模仿Teacher的输出分布用Teacher的“软标签”去弥补结构剪枝带来的信息丢失。Model-Optimizer把这两个流程绑定成一个名叫PruneDistill的Pipeline组件先做一次剪枝再做若干轮蒸馏训练然后评估精度。如果精度达标就继续下一轮剪枝如果精度掉了超过阈值就回退到上一轮状态。循环往复直到达到目标稀疏度。3.2 通道、头、层三个粒度的选择LLM的剪枝有三个粒度通道剪枝channel pruning、注意力头剪枝head pruning和层剪枝layer pruning。它们分别作用于FFN的中间维度、注意力头和Transformer层数各有各的代价和收益。我在实际使用时通常按这个顺序来先做注意力头剪枝。Transformer里并非每个注意力头都很关键。有些头学到的是重复模式剪掉后对下游任务几乎无感。判断头重要性的办法是计算它在验证集上的“平均注意力得分贡献”或者基于梯度的重要性因子。Model-Optimizer默认用基于梯度的Taylor展开估算每个头的重要性因为这一类方法不需要额外训练跑一次反向传播就够了。再做FFN的通道剪枝。FFN层往往是参数量的大头大约占Transformer参数的2/3剪它的收益最大。通道剪枝对精度影响比较平滑因为它不是整条删掉而是把不重要的神经元置零或移除。但要注意通道剪枝会改变后续层输入维度对系统编程要求高通常要依赖推理框架的稀疏矩阵算子配合才能真正加速否则在你的存储里是变小了但跑起来反而更慢。最后考虑层剪枝。这是最激进的方案虽能获得最大收益但风险也最大。层间冗余确实存在LLM越深浅层和深层之间的语义层次差异越来越小一些中间层完全可能被跳过。Model-Optimizer实现了一个层重要性评估指标逐层去掉某一层观察输出表示之间的余弦距离变化用这个作为层冗余的度量。层剪枝通常情况下建议配合蒸馏训练跑至少500到1000步恢复否则掉点会很明显。3.3 蒸馏的匹配点怎么定知识蒸馏的一个核心问题是Student模型要模仿Teacher的什么最早期的做法是拿softmax输出的概率分布做KL散度损失但LLM的词汇表动辄几万甚至十几万直接在输出分布上算KL散度计算量太大而且容易忽略中间层的语义。Model-Optimizer采取的是多层匹配方案蒸馏loss由三部分组成L α * L_output β * L_hidden γ * L_attn其中L_output是对齐Teacher和Student在词汇表上的logits或Top-K分布L_hidden是对齐Teacher和Student在中间层例如每隔两层的hidden state表示L_attn则对齐注意力矩阵的分布。举个例子假设Teacher倒数第二层输出hidden state维度为4096Student剪枝后是3072那在计算L_hidden时需要先通过一个可学习的线性投影层把Student的表示映射到Teacher的维度上再计算MSE损失。实践中有个很关键的经验hidden matching加在中间层比只加在最后一层效果明显更好。因为剪枝损失的信息是整个网络逐步累积的中间层能把误差更早地引导回去。loss权重按经验值设置通常L_output权重最高L_hidden次之L_attn权重最低。训练时学习率要比正常微调低一两个数量级避免Student忘记Teacher已经教会的知识。3.4 稀疏度调度与回退机制剪枝不是一步到位的。我刚开始做剪枝的时候直接设定一个50%的稀疏度目标一次性剪掉一半通道结果模型直接胡言乱语。后来改成渐进式稀疏度调度gradual pruning schedule效果天差地别。Model-Optimizer的默认调度是从稀疏度0开始每轮增加5到10个百分点每一轮做完剪枝后跑少量蒸馏步数评估验证集loss如果相比上一轮loss上涨幅度超过某个阈值就回退到上一轮检查点并降低本轮稀疏度增量。这个过程很像健身增肌你不能一天把重量加到极限必须循序渐进让“剩余网络”有时间适应新的容量。用大白话说剪枝就是一个不断测试“模型哪部分冗余程度高”的过程。如果剪完精度狂掉说明那部分不是冗余而是核心功能所在。回退机制的意义就在于给这个过程一个安全网不至于一剪子下去就再也补不回来了。4. 推理侧优化数据搬移变小延迟才真的降下来4.1 算子融合与kernel选择量化压缩是把模型“变小”但模型变小之后如果不配合算子层面的优化实际推理加速非常有限。GPU推理的性能瓶颈有很大一部分来自频繁的内核启动和显存数据搬运Model-Optimizer在导出阶段两个动作最有用算子融合Operator Fusion和kernel选择。Transformer里最常见的融合是QKV投影融合。原始实现里通常有三个独立的线性层Q、K、V分别计算三次矩阵乘。GPU每次跑一个线性层就要启动一次kernel。如果把它们拼成一个大的线性层把权重矩阵在列方向上拼接一次矩阵乘就能同时算出QKV三个结果kernel启动次数直接降低到三分之一。类似的还有attention输入投影和位置编码的融合、MLP里两个线性层之间的激活函数融合、LayerNorm之后的残差连接融合等。每一处融合看起来都是小优化累计起来对长序列生成的帮助非常明显——解码阶段本身就是被这种细碎操作拖慢的。4.2 KV Cache压缩与Paged AttentionKV Cache的优化是我在Model-Optimizer里投入最多的部分因为它直接和并发、显存挂钩。前面算了batch8时KV Cache就能吃4GB多。如果量化到INT8显存直接减半到2GB多而且精度损失通常很小。实现KV Cache量化的关键是per-token/per-head动态量化。K和V缓存张量的分布并不完全一样V一般更稳定K受位置信息影响更大。Model-Optimizer把K缓存做per-head量化把V缓存做per-token量化实测下来能够较好平衡精度和显存。另一个有效手段是分页KV CachePaged Attention类比虚拟内存分页。传统的KV Cache按请求预先分配固定大小的连续显存序列短时浪费巨大序列长时又可能不够用。分页式管理把KV Cache拆分成固定大小的块按需分配、靠链表维护逻辑连续性。Model-Optimizer在导出服务对象时默认开启分页它让内存利用率从大约60%提升到90%以上在同样显存下可以承接更多并发请求。4.3 连续批处理与投机解码延迟优化和吞吐优化有时候看起来是矛盾的但实际部署里通常要同时考虑。Model-Optimizer集成了连续批处理continuous batching逻辑传统静态批处理把所有请求塞到一个batch里一个请求生成了必须等整个batch结束后才能腾出位置。连续批处理的做法是某个请求一旦生成结束立刻释放它的KV Cache和显存并把调度队列里的新请求插入进来。这使得GPU在长尾请求场景下始终被填满不会出现“大部分batch资源都被已结束请求占着”的浪费。投机解码speculative decoding则是另一招——用一个很小的草稿模型先快速生成若干候选token再由目标大模型一次并行验证这些token。因为“验证”比“生成”低昂只要草稿模型猜得够准实际延迟会大幅下降。Model-Optimizer的slogan里有一项专门管理草稿模型的匹配草稿模型不需要和主模型同族只要词表对齐即可理想情况下它的大小应该控制在主模型的10%到20%。5. 实测结果一张表看透收益也看透代价5.1 测试环境与模型列表说再多理论不如直接看数据。我在三张不同显卡上做了完整的测试分别是NVIDIA RTX 3090、A100 40GB以及一张较老旧的T4。模型选了三款常见开源模型LLaMA-3-8B-Instruct、Qwen2.5-7B-Instruct、Mistral-7B-v0.3。输入输出长度都固定为1024输入 512输出并发请求为8。精度评估采用困惑度perplexity和MMLU5-shot两项指标。以下是一组不算严谨但完全可复现的实测数据模型优化配置显存峰值首token延迟单token延迟吞吐token/sMMLU下降LLaMA-3-8BFP16基线21.4GB189ms42ms3120LLaMA-3-8BINT8量化12.8GB147ms38ms391-0.4%LLaMA-3-8BINT4混合精度8.6GB98ms31ms476-1.8%LLaMA-3-8BINT4剪枝30%蒸馏6.2GB71ms27ms534-2.6%Qwen2.5-7BINT4混合精度8.2GB95ms29ms462-1.5%Mistral-7BINT4混合精度7.9GB88ms28ms487-1.3%这组数据里最值得关注的是后半段量化加剪枝后的组合显存从21GB降到6GB左右吞吐提升了七成以上代价是MMLU掉大约2.6个点。对于很多业务场景来说这个精度损失是可以接受的尤其当你部署的是微调过的专用模型而不是试图让它在通用知识上保持全盛状态。5.2 精度下降都跑到哪里去了很多人拿到Model-Optimizer的报告后会盯着MMLU看但我更建议看perplexity的分层变化。根据我在优化后模型上的细粒度分析掉点主要来源如下极少出现在token中段的语义断裂更多出现在长尾低频词的top-k分布里。量化后的模型倾向于把概率质量集中到高频词上低频词的概率被低估。这在问答类任务里表现不明显但在生成式任务里容易让输出变得“平淡”剪枝对FFN中间维度的损伤会让模型在需要“多步推理”的任务上显得吃力因为少了一部分并行计算的容量模型记忆复杂关系的能力下降lm_head如果被量化解码阶段的词表分布会整体平滑导致更低置信度输出。所以我在导出配置里默认强制lm_head保持FP16。知道精度掉哪儿之后应对方案就清楚了如果是问答业务多关注高频词覆盖如果是长文本生成优先保留FFN的通道数如果必须保留模型推理能力就用混合bit方案避开敏感层。Model-Optimizer的优化报告就是为了辅助这些判断而不是用单一指标掩盖问题。5.3 什么时候不值得做全套优化不是所有模型都值得上一整套量化剪枝蒸馏。估摸你手里的场景如果模型本身小于3B且序列长度经常在512以内推理延迟通常已经很快单纯量化就够了没必要剪枝如果服务并发很低个位数请求显存不是瓶颈那INT8量化足矣INT4带来的额外精度损失性价比不高如果是CPU推理簇拥在算子融合的收益更明显因为CPU没有GPU那么多并行核数据的反复搬移对性能影响更大如果项目只有三天上线时间别碰知识蒸馏。蒸馏训练超参敏感恢复周期长短期内的确定性远不如量化来得稳。我个人的经验法则是先量化评估掉点如果显存压力仍大且掉点可接受再加剪枝如果剪枝掉点太多才考虑上蒸馏恢复。这个顺序把每步的收益和风险都控制在一个可控范围内。6. 从零跑通Model-Optimizer的完整过程与常见坑6.1 快速上手的API设计Model-Optimizer的使用方式尽量保持简单核心接口就是一个optimize函数加一个配置文件。安装直接用pip完成pip install model-optimizer以量化一个HuggingFace模型为例代码大致如下from model_optimizer import ModelOptimizer optimizer ModelOptimizer( model_nameQwen/Qwen2.5-7B-Instruct, optimization_presetbalanced, # 可选: light / balanced / aggressive work_dir./optimized_models, dtypeauto, device_mapcuda:0, kv_cache_dtypeint8, ) report optimizer.run_evaluation( quantizeTrue, pruneTrue, distillTrue, calibration_dataset./data/calib.jsonl, ) print(report.summary())run_evaluation会执行完整流程先做逐层敏感度分析再按配置的优化档位执行量化、剪枝、蒸馏最后用验证集生成优化报告。报告里包含每一层的bit配置、剪枝比例、显存预估变化、perplexity变化和延迟预估。如果你对默认档位不满意可以传入自定义配置字典逐项覆盖每个模块的参数。6.2 五个最容易翻车的细节我在开发和自用的过程中踩过的坑比文档里写的多得多。挑五个对最终效果影响最大的细节警告后来的使用者第一个坑是校准集和验证集重叠。校准集是用来确定量化范围的验证集是用来评估精度的。如果两者重叠评估结果会虚高。我把校准集和验证集硬性拆开管理Model-Optimizer里也默认做了数据集分割和排重防止这个低级错误悄悄污染结果。第二个坑是batch size差异导致量化范围漂移。同一个模型校准数据单条送入和按batch送入激活值分布可能差异很大尤其是BatchNorm类型的层。即便Transformer基本不用BatchNorm但LayerNorm对输入分布的感知也很强。我的经验是校准时的batch size要和线上推理的典型batch size保持一致否则量化范围永远偏一格。第三个坑是剪枝后的权重无法复用原推理框架。很多推理框架对稀疏模型支持很差通道剪枝后模型参数维度变了库不认。所以Model-Optimizer导出模块会同时输出标准PyTorch权重和ONNX格式并自动检查算子是否在目标框架的算子覆盖范围内。如果目标框架不支持某个算子导出阶段会直接报错而不是生成一个跑不了的模型。第四个坑是KV Cache量化时跳过第一层。第一层的K缓存往往包含大量位置信息对位置编码的敏感度非常高量化后模型对长序列的位置感知会显著退化。所以Model-Optimizer的kv_cache_dtype支持配置层范围白名单默认跳过前两层不做量化。第五个坑是半精度下的absmax溢出。FP16能表示的范围有限量化计算scale时对矩阵全体求absmax如果某个异常值过大可能导致scale小到溢出。在少数极端权重分布下会出现全零张量。规避方法是计算scale时加入一个极小epsilon例如1e-8或者在FP32下计算scale再cast到FP16。6.3 复现我这份结果的最小操作集最后给出一份可复现的最小命令。假设你想复现LLaMA-3-8B的INT4混合精度结果在配备24GB显存显卡的机器上可以执行model-optimizer optimize \ --model meta-llama/Llama-3-8B-Instruct \ --preset aggressive \ --quant-bits int4 \ --group-size 128 \ --skip-layers embedding,layer0,layer31 \ --calibration-size 256 \ --eval-tasks perplexity,mmlu跑完之后优化模型会输出到当前目录下的./optimized_model_fp16_int4_mix目录。你可以再用Model-Optimizer内置的serve子命令快速启动一个兼容OpenAI接口的推理服务model-optimizer serve \ --model ./optimized_model_fp16_int4_mix \ --port 8080 \ --kv-cache-dtype int8 \ --max-batch-size 32 \ --enable-paged-attention我建议第一次做完整优化时哪怕再着急也要打开报告看一眼“逐层bit配置”和“逐层剪枝比例”这两页。Model-Optimizer生成的报告是HTML格式的每一层都能展开看到优化前后的参数分布图。这些细节才是决定你模型最终体感质量的东西。我自己的习惯是每次优化完除了记录eval指标还会保存几个固定测试用例的实际输出比如一个数学题、一个长文摘要、一个代码补全。看数字可以但最终还是要看真实生成的文字质量。模型压缩这条路永远不要只看指标不看输出。每个人的业务场景不一样最优的压缩配置也不一样把流程跑通、把报告看懂、把关键层守住你就能摆脱“用别人调好的模型”的被动局面真正按自己的需求定制推理效率和精度的平衡点。
