尧图网页设计 
1. 模型优化器到底在优化什么从一次推理延迟排查说起第一次接触 Model-Optimizer 这个概念是帮一个做智能客服的朋友排查线上问题。他们的对话模型单次推理要 800 毫秒用户等得直骂娘老板天天催着降本增效。当时团队第一反应是换更小的模型结果效果掉得厉害客诉反而更多了。后来我们换了个思路不动模型结构只在推理链路和权重层面做优化硬是把延迟压到了 220 毫秒效果几乎没损失。那次经历让我彻底明白Model-Optimizer 不是一个具体的软件包而是一整套围绕模型推理效率做文章的方法论和工具链的统称。说白了Model-Optimizer 解决的核心问题就一个在尽量不牺牲模型精度的前提下让模型跑得更快、占得更少、花得更省。它面向的是所有把模型部署到真实业务场景里的人——算法工程师、后端开发、运维、甚至自己搭本地大模型玩的技术爱好者。你不需要重新训练一个模型也不需要精通 CUDA 底层只要理解几个关键优化维度就能拿到肉眼可见的收益。我见过太多人一上来就想着量化到 4bit结果精度崩了又回头骂工具不好用。其实模型优化是一套组合拳量化、蒸馏、剪枝、算子融合、KV Cache 优化、批处理调度每一招都有它的适用边界。这篇文章我就按自己踩坑的顺序把这套东西掰开揉碎讲清楚包括每一步为什么这么做、参数怎么算、哪些坑我替你踩过了。2. 优化前的必修课先搞清楚你的瓶颈在哪2.1 别急着动手先做一次完整的性能画像我见过最离谱的案例是一个团队花了两个月做模型量化最后发现真正的瓶颈是数据预处理里的一个同步 IO 操作。模型优化最忌讳的就是凭感觉下手你得先知道时间花在哪、显存被谁吃了、算力利用率到底多少。性能画像要抓三个核心指标。第一是首 token 延迟也就是用户发出请求到看到第一个字的时间这个直接决定体感。第二是吞吐量每秒能处理多少个请求或多少 token这关系到你的机器成本。第三是显存占用峰值它决定了你能用多大的模型、开多大的批。这三个指标往往是互相拉扯的优化就是在这三者之间找平衡点。具体怎么做画像如果你用的是 PyTorchtorch.profiler是最顺手的选择。下面这段代码是我常用的模板能直接打出每个算子的耗时占比import torch from torch.profiler import profile, ProfilerActivity model load_your_model() input_ids torch.randint(0, 30000, (1, 512)).cuda() with profile(activities[ProfilerActivity.CUDA, ProfilerActivity.CPU], record_shapesTrue, profile_memoryTrue) as prof: with torch.no_grad(): for _ in range(10): model(input_ids) print(prof.key_averages().table(sort_bycuda_time_total, row_limit20))跑完你会看到一张表里面清楚列出哪些算子吃掉了大部分时间。经验上Transformer 类模型里矩阵乘法和注意力相关的算子通常占 70% 以上如果发现某个 LayerNorm 或者激活函数异常靠前那多半是算子融合没做好这就是优化的第一个切入点。提示profile 的时候一定要用真实输入长度别拿长度 8 的假数据糊弄自己。序列长度对注意力复杂度是平方级影响短序列的画像完全没有参考价值。2.2 判断你该走哪条优化路线拿到画像之后根据瓶颈类型选路线。我整理了一张对照表这是我实际项目里反复验证过的判断逻辑瓶颈现象根因判断优先优化手段显存不够批大小上不去权重和激活占用大量化、梯度检查点单次推理慢GPU 利用率低算子碎片化、kernel 启动开销大算子融合、图优化长序列推理越往后越慢KV Cache 线性增长KV Cache 量化、分页管理吞吐上不去但单请求不慢调度和批处理策略差连续批处理、动态批模型太大装不下单卡参数量超显存量化、剪枝、张量并行这张表的价值在于它帮你避免“拿着锤子找钉子”。量化不是万能的如果你的瓶颈是调度量化只会让你精度掉一截还解决不了吞吐问题。我个人的习惯是先看显存显存够就看单请求延迟延迟也还行就死磕吞吐按这个优先级走基本不会跑偏。3. 量化收益最大也最容易翻车的一环3.1 量化的本质是一次精度与体积的交换量化的核心思想特别朴素神经网络里的权重和激活值本来是 32 位浮点数但实际很多数值根本用不到那么高的精度用 16 位甚至 8 位、4 位来表示误差在可接受范围内但显存和带宽直接砍半甚至砍到四分之一。这就像你用一把最小刻度是毫米的尺子去量桌子没必要精确到微米够用就行。量化的数学表达其实就是一个仿射映射。把浮点值 x 映射到整数 qq round(x / scale) zero_point x_approx (q - zero_point) * scale其中 scale 是缩放因子zero_point 是零点偏移。scale 的计算通常是(max - min) / (2^bits - 1)。举个例子权重范围是 [-2.5, 2.5]量化到 8 位整数范围 0 到 255那么 scale 5 / 255 ≈ 0.0196zero_point 取 128 附近让 0 能精确表示。这个计算过程看着简单但 scale 怎么选、是按张量整体算还是按通道算直接决定量化后的精度。3.2 训练后量化与量化感知训练怎么选量化分两大流派。训练后量化PTQ是拿训练好的模型直接量化不需要重新训练几分钟就能搞定适合快速验证。量化感知训练QAT是在训练过程中模拟量化误差让模型自己学会适应低精度精度损失更小但需要重新训练成本高。我的经验是8 位 PTQ 在绝大多数模型上精度损失都在 1% 以内可以直接上。4 位 PTQ 就比较看运气了有些模型能扛住有些直接崩。如果 4 位是硬需求那就老老实实上 QAT。下面是一个用 PyTorch 做动态量化的例子这是最简单的 PTQimport torch.quantization as tq model load_your_model().eval() # 动态量化权重离线量化激活在线量化 quantized_model tq.quantize_dynamic( model, {torch.nn.Linear}, # 只量化线性层 dtypetorch.qint8 ) torch.save(quantized_model.state_dict(), model_int8.pt)动态量化对 LSTM、Linear 密集的模型效果很好一行代码就能把模型体积压到四分之一。但它对卷积和注意力的支持一般这时候就得上静态量化需要准备校准数据集跑一遍前向统计激活值的分布来确定 scale。3.3 量化实操中最容易踩的三个坑第一个坑是校准集选得不对。静态量化需要校准数据来统计激活范围如果你拿一堆短文本去校准一个要处理长文档的模型激活范围统计偏小推理时遇到长输入就会溢出精度断崖式下跌。校准集一定要覆盖真实业务的数据分布我一般会从线上日志里随机抽 500 到 1000 条真实请求。第二个坑是忽略了某些层的敏感性。不是所有层都适合量化第一层和最后一层通常对精度影响最大注意力里的 softmax 和 LayerNorm 也对数值范围敏感。稳妥的做法是做逐层敏感度分析把敏感层保留在高精度其余层量化。这个混合精度策略能把精度损失再压一半。第三个坑是量化后没做端到端验证。很多人只看 perplexity 或者准确率这些离线指标觉得没掉就上线了。但量化误差在某些特定输入上会放大我建议一定要构造一批边界 case 做回归测试尤其是那些包含罕见 token、超长序列、特殊符号的输入。注意量化后的模型在不同硬件上的表现差异很大。同一份 int8 权重在某些加速卡上能跑出 3 倍加速在另一些上可能因为缺少对应的整数指令集反而变慢。上线前务必在目标硬件上实测。4. 剪枝与蒸馏给模型做减法的两种思路4.1 结构化剪枝与非结构化剪枝的取舍剪枝的逻辑是神经网络里存在大量冗余参数把不重要的连接或神经元去掉模型变小变快精度基本不变。听起来很美但剪枝分两种效果天差地别。非结构化剪枝是把单个权重置零理论上能压到很高的稀疏度但问题是现在的 GPU 对稀疏矩阵的支持并不好除非稀疏度达到 90% 以上且有专门的稀疏计算库否则实际加速非常有限。我早期做过一个实验把 BERT 非结构化剪到 70% 稀疏模型文件是小了但推理速度几乎没变因为稠密计算该跑还是跑。结构化剪枝是直接砍掉整个神经元、整个注意力头或者整个通道剪完还是稠密的矩阵硬件友好加速立竿见影。代价是精度损失比非结构化大需要更精细的重要性评估。我的建议是除非你有专门的稀疏推理引擎否则优先选结构化剪枝。4.2 用重要性评分决定剪谁剪枝的关键是判断哪些部分不重要。常用的重要性评分有几种。基于权重大小的方法最简单认为绝对值小的权重不重要但这个方法忽略了激活值的影响。更靠谱的是基于激活的方法统计每个通道在真实数据上的激活均值激活小的通道贡献小可以剪。下面是一个基于 L1 范数的通道重要性评估示例import torch def compute_channel_importance(model, calib_loader): importance {} hooks [] def hook_fn(name): def hook(module, inp, out): # 用输出激活的 L1 范数作为重要性 importance[name] out.abs().mean(dim(0, 2)).detach() return hook for name, module in model.named_modules(): if isinstance(module, torch.nn.Linear): hooks.append(module.register_forward_hook(hook_fn(name))) with torch.no_grad(): for batch in calib_loader: model(batch) for h in hooks: h.remove() return importance拿到每个通道的重要性分数后按分数排序剪掉最低的那部分。剪枝比例不要一次到位建议迭代式剪枝每次剪 10% 到 20%剪完微调几轮恢复精度再剪下一轮。一次性剪太多模型直接废掉救都救不回来。4.3 知识蒸馏让小模型学会大模型的“手感”蒸馏的思路和剪枝、量化完全不同。它不是压缩原模型而是训练一个天生就小的学生模型让它去模仿大模型老师模型的输出。学生模型不仅学真实标签还学老师模型输出的软标签——那些概率分布里包含了类别之间的相似性信息这是硬标签给不了的。蒸馏的温度参数 T 是个关键。温度高的时候软标签分布更平滑类别间的相对关系信息更丰富温度低的时候分布更尖锐接近硬标签。实践中 T 取 2 到 5 比较常见。损失函数通常是软标签的 KL 散度和硬标签的交叉熵加权求和loss alpha * KL(student_soft || teacher_soft) (1 - alpha) * CE(student, label)alpha 一般取 0.5 到 0.9偏向软标签。我做过一个文本分类的蒸馏实验学生模型参数量只有老师的四分之一蒸馏后准确率能达到老师的 97%而直接拿学生模型从头训只能到 91%。这 6 个点的差距就是软标签带来的。蒸馏的坑在于老师模型不能太强也不能太弱。老师太强学生学不动差距太大老师太弱学生学不到有用的知识。一般老师比学生大 3 到 10 倍比较合适。另外蒸馏训练时间通常比正常训练长因为软标签的监督信号更柔和收敛更慢要有耐心。5. 推理引擎与运行时优化让优化成果真正落地5.1 算子融合为什么能带来数倍加速前面说的量化、剪枝、蒸馏都是在改模型本身而算子融合和运行时优化是在改执行方式。这两者叠加效果往往是乘法关系。算子融合的原理是深度学习框架默认是逐个算子执行的每个算子都要读写一次显存还要经历一次 kernel 启动。一个 Transformer 层里有几十个算子光是 kernel 启动和显存读写就吃掉大量时间。算子融合把多个连续的小算子合并成一个大 kernel中间结果留在寄存器或共享内存里不落显存启动开销也省了。最典型的融合是Linear Bias Activation合成一个算子还有注意力里的QK^T Softmax V融合。实测下来光是算子融合就能带来 1.5 到 2 倍的加速而且完全不损失精度这是性价比最高的优化手段。5.2 用现成推理引擎还是自己写 kernel自己写 CUDA kernel 优化模型听起来很硬核但绝大多数场景没必要。现在成熟的推理引擎已经帮你做好了算子融合、内存复用、动态批处理这些事。TensorRT 在 NVIDIA 卡上是首选ONNX Runtime 跨平台通用性好OpenVINO 在 Intel 平台上表现优秀。选引擎的核心考量是硬件匹配度和模型支持度。我的一般流程是先把模型导出成 ONNX这是通用的中间格式然后用目标平台的引擎做进一步优化。导出 ONNX 时要注意动态轴的处理序列长度和批大小如果写死部署时就失去了灵活性import torch.onnx dummy_input torch.randint(0, 30000, (1, 128)).cuda() torch.onnx.export( model, dummy_input, model.onnx, input_names[input_ids], output_names[logits], dynamic_axes{ input_ids: {0: batch, 1: seq_len}, logits: {0: batch, 1: seq_len} }, opset_version14 )dynamic_axes这个参数一定要设否则导出的模型只能处理固定形状的输入线上请求长度一变就报错。opset 版本也别太低14 以上对 Transformer 相关算子的支持才完善。5.3 KV Cache 优化长文本场景的救命稻草自回归生成模型有个特点每生成一个 token 都要重新计算前面所有 token 的注意力。如果不做缓存生成长度 n 的序列复杂度是 O(n²)长文本场景直接爆炸。KV Cache 的思路是把已经算过的 Key 和 Value 存下来新 token 只算自己的复杂度降到 O(n)。但 KV Cache 本身也吃显存序列越长占用越大。一个 7B 模型序列长度 4096KV Cache 可能就要吃掉好几个 G。优化手段有几个方向。一是 KV Cache 量化把缓存的精度从 fp16 降到 int8显存直接减半精度损失很小。二是分页管理像操作系统的虚拟内存一样把 KV Cache 分成固定大小的块按需分配避免预分配造成的浪费。三是滑动窗口注意力只保留最近 N 个 token 的缓存适合那些不需要超长记忆的场景。我实测过一个 13B 模型序列长度 8192不做任何 KV Cache 优化时显存直接 OOM开了 int8 量化加滑动窗口后显存占用从 24G 降到 9G单卡就能跑起来生成质量在对话场景下几乎无感。6. 常见问题排查与避坑速查6.1 优化后精度掉了怎么定位精度下降是优化后最常见的问题定位思路是逐层对比。把优化前后的模型对同一批输入做前向逐层比较输出的差异找出误差最大的那一层。如果误差集中在某几层说明这几层对量化或剪枝敏感把它们恢复成高精度即可。我常用的一个技巧是先只优化模型的一半层看精度掉多少再优化另一半这样能快速定位敏感区域。另外精度评估一定要用业务相关的指标别只看 loss。有些优化会让 loss 微涨但业务指标不变这种情况完全可以接受。6.2 加速比不达预期怎么办优化做完了但加速不明显通常有三个原因。一是瓶颈判断错了你优化的不是真正的瓶颈。回到第 2 节的性能画像重新确认。二是算子融合没生效很多融合需要特定的图优化 pass检查你的推理引擎是否开启了对应选项。三是数据预处理或后处理成了新瓶颈模型快了但前后处理没跟上整体延迟没变。这时候要把优化范围扩大到整个推理链路而不只是模型本身。6.3 常见问题速查表问题现象可能原因排查方向量化后输出乱码校准集分布不符换真实业务数据重新校准剪枝后精度暴跌剪枝比例过大降低比例迭代剪枝加微调推理引擎加载失败opset 版本不兼容升级 opset 或降级引擎版本长序列 OOMKV Cache 未优化开启量化或分页管理批处理吞吐上不去批内长度差异大启用连续批处理按长度分桶多卡加速比线性度差通信开销占比高检查并行策略减少同步点提示每次只改一个变量改完立刻验证。同时上量化和剪枝出了问题你根本不知道是谁的锅。这是我在项目里用血泪换来的教训。7. 一套可复用的优化流程与我的实操体会把上面这些串起来我现在的标准流程是这样的。第一步做性能画像确定瓶颈。第二步优先做无损优化也就是算子融合和运行时配置调优这部分不损失精度先拿到手。第三步做量化从 8 位 PTQ 开始不够再上 QAT。第四步如果还需要更小考虑结构化剪枝或蒸馏。第五步做端到端回归测试覆盖边界 case。第六步上线后持续监控延迟和精度指标优化不是一次性的业务数据分布会漂移优化策略也要跟着调。这套流程我在好几个项目里跑过从 7B 到 70B 的模型都适用。印象最深的是一个实时翻译场景原始模型单卡只能跑 2 路并发延迟 1.2 秒。经过算子融合加 int8 量化加连续批处理三板斧同样的卡跑到了 16 路并发延迟降到 300 毫秒以内硬件成本直接省了七成。最后分享一个我踩过的最大的坑。有次为了追求极致压缩我把一个模型量化到 4 位又剪了 40% 的通道离线指标看着还行上线第二天就出事了。某些特定领域的输入会让模型输出完全错乱因为那些领域的激活分布和校准集差异太大。后来我学乖了任何优化上线前一定要用线上真实流量的采样做影子测试跑够至少一天再切量。优化这件事快就是慢稳才是快。 模型优化器实战：量化、剪枝与推理加速全解析
1. 模型优化器到底在优化什么从一次推理延迟排查说起第一次接触 Model-Optimizer 这个概念是帮一个做智能客服的朋友排查线上问题。他们的对话模型单次推理要 800 毫秒用户等得直骂娘老板天天催着降本增效。当时团队第一反应是换更小的模型结果效果掉得厉害客诉反而更多了。后来我们换了个思路不动模型结构只在推理链路和权重层面做优化硬是把延迟压到了 220 毫秒效果几乎没损失。那次经历让我彻底明白Model-Optimizer 不是一个具体的软件包而是一整套围绕模型推理效率做文章的方法论和工具链的统称。说白了Model-Optimizer 解决的核心问题就一个在尽量不牺牲模型精度的前提下让模型跑得更快、占得更少、花得更省。它面向的是所有把模型部署到真实业务场景里的人——算法工程师、后端开发、运维、甚至自己搭本地大模型玩的技术爱好者。你不需要重新训练一个模型也不需要精通 CUDA 底层只要理解几个关键优化维度就能拿到肉眼可见的收益。我见过太多人一上来就想着量化到 4bit结果精度崩了又回头骂工具不好用。其实模型优化是一套组合拳量化、蒸馏、剪枝、算子融合、KV Cache 优化、批处理调度每一招都有它的适用边界。这篇文章我就按自己踩坑的顺序把这套东西掰开揉碎讲清楚包括每一步为什么这么做、参数怎么算、哪些坑我替你踩过了。2. 优化前的必修课先搞清楚你的瓶颈在哪2.1 别急着动手先做一次完整的性能画像我见过最离谱的案例是一个团队花了两个月做模型量化最后发现真正的瓶颈是数据预处理里的一个同步 IO 操作。模型优化最忌讳的就是凭感觉下手你得先知道时间花在哪、显存被谁吃了、算力利用率到底多少。性能画像要抓三个核心指标。第一是首 token 延迟也就是用户发出请求到看到第一个字的时间这个直接决定体感。第二是吞吐量每秒能处理多少个请求或多少 token这关系到你的机器成本。第三是显存占用峰值它决定了你能用多大的模型、开多大的批。这三个指标往往是互相拉扯的优化就是在这三者之间找平衡点。具体怎么做画像如果你用的是 PyTorchtorch.profiler是最顺手的选择。下面这段代码是我常用的模板能直接打出每个算子的耗时占比import torch from torch.profiler import profile, ProfilerActivity model load_your_model() input_ids torch.randint(0, 30000, (1, 512)).cuda() with profile(activities[ProfilerActivity.CUDA, ProfilerActivity.CPU], record_shapesTrue, profile_memoryTrue) as prof: with torch.no_grad(): for _ in range(10): model(input_ids) print(prof.key_averages().table(sort_bycuda_time_total, row_limit20))跑完你会看到一张表里面清楚列出哪些算子吃掉了大部分时间。经验上Transformer 类模型里矩阵乘法和注意力相关的算子通常占 70% 以上如果发现某个 LayerNorm 或者激活函数异常靠前那多半是算子融合没做好这就是优化的第一个切入点。提示profile 的时候一定要用真实输入长度别拿长度 8 的假数据糊弄自己。序列长度对注意力复杂度是平方级影响短序列的画像完全没有参考价值。2.2 判断你该走哪条优化路线拿到画像之后根据瓶颈类型选路线。我整理了一张对照表这是我实际项目里反复验证过的判断逻辑瓶颈现象根因判断优先优化手段显存不够批大小上不去权重和激活占用大量化、梯度检查点单次推理慢GPU 利用率低算子碎片化、kernel 启动开销大算子融合、图优化长序列推理越往后越慢KV Cache 线性增长KV Cache 量化、分页管理吞吐上不去但单请求不慢调度和批处理策略差连续批处理、动态批模型太大装不下单卡参数量超显存量化、剪枝、张量并行这张表的价值在于它帮你避免“拿着锤子找钉子”。量化不是万能的如果你的瓶颈是调度量化只会让你精度掉一截还解决不了吞吐问题。我个人的习惯是先看显存显存够就看单请求延迟延迟也还行就死磕吞吐按这个优先级走基本不会跑偏。3. 量化收益最大也最容易翻车的一环3.1 量化的本质是一次精度与体积的交换量化的核心思想特别朴素神经网络里的权重和激活值本来是 32 位浮点数但实际很多数值根本用不到那么高的精度用 16 位甚至 8 位、4 位来表示误差在可接受范围内但显存和带宽直接砍半甚至砍到四分之一。这就像你用一把最小刻度是毫米的尺子去量桌子没必要精确到微米够用就行。量化的数学表达其实就是一个仿射映射。把浮点值 x 映射到整数 qq round(x / scale) zero_point x_approx (q - zero_point) * scale其中 scale 是缩放因子zero_point 是零点偏移。scale 的计算通常是(max - min) / (2^bits - 1)。举个例子权重范围是 [-2.5, 2.5]量化到 8 位整数范围 0 到 255那么 scale 5 / 255 ≈ 0.0196zero_point 取 128 附近让 0 能精确表示。这个计算过程看着简单但 scale 怎么选、是按张量整体算还是按通道算直接决定量化后的精度。3.2 训练后量化与量化感知训练怎么选量化分两大流派。训练后量化PTQ是拿训练好的模型直接量化不需要重新训练几分钟就能搞定适合快速验证。量化感知训练QAT是在训练过程中模拟量化误差让模型自己学会适应低精度精度损失更小但需要重新训练成本高。我的经验是8 位 PTQ 在绝大多数模型上精度损失都在 1% 以内可以直接上。4 位 PTQ 就比较看运气了有些模型能扛住有些直接崩。如果 4 位是硬需求那就老老实实上 QAT。下面是一个用 PyTorch 做动态量化的例子这是最简单的 PTQimport torch.quantization as tq model load_your_model().eval() # 动态量化权重离线量化激活在线量化 quantized_model tq.quantize_dynamic( model, {torch.nn.Linear}, # 只量化线性层 dtypetorch.qint8 ) torch.save(quantized_model.state_dict(), model_int8.pt)动态量化对 LSTM、Linear 密集的模型效果很好一行代码就能把模型体积压到四分之一。但它对卷积和注意力的支持一般这时候就得上静态量化需要准备校准数据集跑一遍前向统计激活值的分布来确定 scale。3.3 量化实操中最容易踩的三个坑第一个坑是校准集选得不对。静态量化需要校准数据来统计激活范围如果你拿一堆短文本去校准一个要处理长文档的模型激活范围统计偏小推理时遇到长输入就会溢出精度断崖式下跌。校准集一定要覆盖真实业务的数据分布我一般会从线上日志里随机抽 500 到 1000 条真实请求。第二个坑是忽略了某些层的敏感性。不是所有层都适合量化第一层和最后一层通常对精度影响最大注意力里的 softmax 和 LayerNorm 也对数值范围敏感。稳妥的做法是做逐层敏感度分析把敏感层保留在高精度其余层量化。这个混合精度策略能把精度损失再压一半。第三个坑是量化后没做端到端验证。很多人只看 perplexity 或者准确率这些离线指标觉得没掉就上线了。但量化误差在某些特定输入上会放大我建议一定要构造一批边界 case 做回归测试尤其是那些包含罕见 token、超长序列、特殊符号的输入。注意量化后的模型在不同硬件上的表现差异很大。同一份 int8 权重在某些加速卡上能跑出 3 倍加速在另一些上可能因为缺少对应的整数指令集反而变慢。上线前务必在目标硬件上实测。4. 剪枝与蒸馏给模型做减法的两种思路4.1 结构化剪枝与非结构化剪枝的取舍剪枝的逻辑是神经网络里存在大量冗余参数把不重要的连接或神经元去掉模型变小变快精度基本不变。听起来很美但剪枝分两种效果天差地别。非结构化剪枝是把单个权重置零理论上能压到很高的稀疏度但问题是现在的 GPU 对稀疏矩阵的支持并不好除非稀疏度达到 90% 以上且有专门的稀疏计算库否则实际加速非常有限。我早期做过一个实验把 BERT 非结构化剪到 70% 稀疏模型文件是小了但推理速度几乎没变因为稠密计算该跑还是跑。结构化剪枝是直接砍掉整个神经元、整个注意力头或者整个通道剪完还是稠密的矩阵硬件友好加速立竿见影。代价是精度损失比非结构化大需要更精细的重要性评估。我的建议是除非你有专门的稀疏推理引擎否则优先选结构化剪枝。4.2 用重要性评分决定剪谁剪枝的关键是判断哪些部分不重要。常用的重要性评分有几种。基于权重大小的方法最简单认为绝对值小的权重不重要但这个方法忽略了激活值的影响。更靠谱的是基于激活的方法统计每个通道在真实数据上的激活均值激活小的通道贡献小可以剪。下面是一个基于 L1 范数的通道重要性评估示例import torch def compute_channel_importance(model, calib_loader): importance {} hooks [] def hook_fn(name): def hook(module, inp, out): # 用输出激活的 L1 范数作为重要性 importance[name] out.abs().mean(dim(0, 2)).detach() return hook for name, module in model.named_modules(): if isinstance(module, torch.nn.Linear): hooks.append(module.register_forward_hook(hook_fn(name))) with torch.no_grad(): for batch in calib_loader: model(batch) for h in hooks: h.remove() return importance拿到每个通道的重要性分数后按分数排序剪掉最低的那部分。剪枝比例不要一次到位建议迭代式剪枝每次剪 10% 到 20%剪完微调几轮恢复精度再剪下一轮。一次性剪太多模型直接废掉救都救不回来。4.3 知识蒸馏让小模型学会大模型的“手感”蒸馏的思路和剪枝、量化完全不同。它不是压缩原模型而是训练一个天生就小的学生模型让它去模仿大模型老师模型的输出。学生模型不仅学真实标签还学老师模型输出的软标签——那些概率分布里包含了类别之间的相似性信息这是硬标签给不了的。蒸馏的温度参数 T 是个关键。温度高的时候软标签分布更平滑类别间的相对关系信息更丰富温度低的时候分布更尖锐接近硬标签。实践中 T 取 2 到 5 比较常见。损失函数通常是软标签的 KL 散度和硬标签的交叉熵加权求和loss alpha * KL(student_soft || teacher_soft) (1 - alpha) * CE(student, label)alpha 一般取 0.5 到 0.9偏向软标签。我做过一个文本分类的蒸馏实验学生模型参数量只有老师的四分之一蒸馏后准确率能达到老师的 97%而直接拿学生模型从头训只能到 91%。这 6 个点的差距就是软标签带来的。蒸馏的坑在于老师模型不能太强也不能太弱。老师太强学生学不动差距太大老师太弱学生学不到有用的知识。一般老师比学生大 3 到 10 倍比较合适。另外蒸馏训练时间通常比正常训练长因为软标签的监督信号更柔和收敛更慢要有耐心。5. 推理引擎与运行时优化让优化成果真正落地5.1 算子融合为什么能带来数倍加速前面说的量化、剪枝、蒸馏都是在改模型本身而算子融合和运行时优化是在改执行方式。这两者叠加效果往往是乘法关系。算子融合的原理是深度学习框架默认是逐个算子执行的每个算子都要读写一次显存还要经历一次 kernel 启动。一个 Transformer 层里有几十个算子光是 kernel 启动和显存读写就吃掉大量时间。算子融合把多个连续的小算子合并成一个大 kernel中间结果留在寄存器或共享内存里不落显存启动开销也省了。最典型的融合是Linear Bias Activation合成一个算子还有注意力里的QK^T Softmax V融合。实测下来光是算子融合就能带来 1.5 到 2 倍的加速而且完全不损失精度这是性价比最高的优化手段。5.2 用现成推理引擎还是自己写 kernel自己写 CUDA kernel 优化模型听起来很硬核但绝大多数场景没必要。现在成熟的推理引擎已经帮你做好了算子融合、内存复用、动态批处理这些事。TensorRT 在 NVIDIA 卡上是首选ONNX Runtime 跨平台通用性好OpenVINO 在 Intel 平台上表现优秀。选引擎的核心考量是硬件匹配度和模型支持度。我的一般流程是先把模型导出成 ONNX这是通用的中间格式然后用目标平台的引擎做进一步优化。导出 ONNX 时要注意动态轴的处理序列长度和批大小如果写死部署时就失去了灵活性import torch.onnx dummy_input torch.randint(0, 30000, (1, 128)).cuda() torch.onnx.export( model, dummy_input, model.onnx, input_names[input_ids], output_names[logits], dynamic_axes{ input_ids: {0: batch, 1: seq_len}, logits: {0: batch, 1: seq_len} }, opset_version14 )dynamic_axes这个参数一定要设否则导出的模型只能处理固定形状的输入线上请求长度一变就报错。opset 版本也别太低14 以上对 Transformer 相关算子的支持才完善。5.3 KV Cache 优化长文本场景的救命稻草自回归生成模型有个特点每生成一个 token 都要重新计算前面所有 token 的注意力。如果不做缓存生成长度 n 的序列复杂度是 O(n²)长文本场景直接爆炸。KV Cache 的思路是把已经算过的 Key 和 Value 存下来新 token 只算自己的复杂度降到 O(n)。但 KV Cache 本身也吃显存序列越长占用越大。一个 7B 模型序列长度 4096KV Cache 可能就要吃掉好几个 G。优化手段有几个方向。一是 KV Cache 量化把缓存的精度从 fp16 降到 int8显存直接减半精度损失很小。二是分页管理像操作系统的虚拟内存一样把 KV Cache 分成固定大小的块按需分配避免预分配造成的浪费。三是滑动窗口注意力只保留最近 N 个 token 的缓存适合那些不需要超长记忆的场景。我实测过一个 13B 模型序列长度 8192不做任何 KV Cache 优化时显存直接 OOM开了 int8 量化加滑动窗口后显存占用从 24G 降到 9G单卡就能跑起来生成质量在对话场景下几乎无感。6. 常见问题排查与避坑速查6.1 优化后精度掉了怎么定位精度下降是优化后最常见的问题定位思路是逐层对比。把优化前后的模型对同一批输入做前向逐层比较输出的差异找出误差最大的那一层。如果误差集中在某几层说明这几层对量化或剪枝敏感把它们恢复成高精度即可。我常用的一个技巧是先只优化模型的一半层看精度掉多少再优化另一半这样能快速定位敏感区域。另外精度评估一定要用业务相关的指标别只看 loss。有些优化会让 loss 微涨但业务指标不变这种情况完全可以接受。6.2 加速比不达预期怎么办优化做完了但加速不明显通常有三个原因。一是瓶颈判断错了你优化的不是真正的瓶颈。回到第 2 节的性能画像重新确认。二是算子融合没生效很多融合需要特定的图优化 pass检查你的推理引擎是否开启了对应选项。三是数据预处理或后处理成了新瓶颈模型快了但前后处理没跟上整体延迟没变。这时候要把优化范围扩大到整个推理链路而不只是模型本身。6.3 常见问题速查表问题现象可能原因排查方向量化后输出乱码校准集分布不符换真实业务数据重新校准剪枝后精度暴跌剪枝比例过大降低比例迭代剪枝加微调推理引擎加载失败opset 版本不兼容升级 opset 或降级引擎版本长序列 OOMKV Cache 未优化开启量化或分页管理批处理吞吐上不去批内长度差异大启用连续批处理按长度分桶多卡加速比线性度差通信开销占比高检查并行策略减少同步点提示每次只改一个变量改完立刻验证。同时上量化和剪枝出了问题你根本不知道是谁的锅。这是我在项目里用血泪换来的教训。7. 一套可复用的优化流程与我的实操体会把上面这些串起来我现在的标准流程是这样的。第一步做性能画像确定瓶颈。第二步优先做无损优化也就是算子融合和运行时配置调优这部分不损失精度先拿到手。第三步做量化从 8 位 PTQ 开始不够再上 QAT。第四步如果还需要更小考虑结构化剪枝或蒸馏。第五步做端到端回归测试覆盖边界 case。第六步上线后持续监控延迟和精度指标优化不是一次性的业务数据分布会漂移优化策略也要跟着调。这套流程我在好几个项目里跑过从 7B 到 70B 的模型都适用。印象最深的是一个实时翻译场景原始模型单卡只能跑 2 路并发延迟 1.2 秒。经过算子融合加 int8 量化加连续批处理三板斧同样的卡跑到了 16 路并发延迟降到 300 毫秒以内硬件成本直接省了七成。最后分享一个我踩过的最大的坑。有次为了追求极致压缩我把一个模型量化到 4 位又剪了 40% 的通道离线指标看着还行上线第二天就出事了。某些特定领域的输入会让模型输出完全错乱因为那些领域的激活分布和校准集差异太大。后来我学乖了任何优化上线前一定要用线上真实流量的采样做影子测试跑够至少一天再切量。优化这件事快就是慢稳才是快。