写周报这件事我不知不觉坚持到了第三十九期。从最开始记录一些基础论文的阅读笔记到后来逐渐转向实验复现、工程踩坑、性能调优这三十几周的内容基本就是我一个人从入门到能独立做一些模型落地工作的完整轨迹。这一期我不想写那种罗列了一堆论文标题的流水账我想认真聊聊一个相对朴素但非常关键的问题一个在实验环境里跑得不错的模型到底要经过哪些折腾才能真正落到产线设备上跑得又快又稳还不出幺蛾子。这一期的主题就定为模型轻量化与高效部署实战内容会包含完整的方案选型、实操记录、性能对比以及这一周里我踩过的几个坑。如果你正在做算法落地或者手头有个模型因为体积太大、推理太慢被业务方反复打回这篇周报应该能给你一些能直接抄作业的参考。本期所有实验都基于一个自建的小型视觉检测任务场景不算复杂但涉及的问题非常典型模型太大、算力受限、环境苛刻每一步都需要做取舍。1. 本期主线模型轻量化到底在解决什么问题1.1 场景背景与约束条件这周接到的需求是这样产线上有一个外观检测点位原来靠人工目检现在想换成一个边缘盒子做实时自动检测。设备的规格很明确——没有独立显卡CPU是四核的嵌入式平台内存一共2GB系统是裁剪过的Linux发行版。检测目标不算难几类常见的表面缺陷背景相对固定光照变化也不剧烈。业务方给的关键指标只有三个单帧推理耗时必须控制在50毫秒以内模型文件不超过20MB检测精度不能低于90%。听起来指标不算苛刻但我实际去跑才发现组里之前那个已经训好的模型本质上是拿深度残差网络当骨干做特征提取加上一层特征融合结构光权重文件就有42MB参数量约1100万。在目标设备上实测单帧推理耗时120毫秒GPU上用完全没问题搬到这块板子上直接超了两倍多。如果只是做几个小改动比如换输入分辨率或者改一下后处理顶多把120毫秒压到90毫秒左右还是不达标。这种情况唯一的出路就是对模型本身动刀子——做压缩和加速也就是所谓的模型轻量化。1.2 三条主流技术路线的原理对比面对模型体积大、算力需求高的问题业界常见的思路无非三条剪枝、量化、知识蒸馏。这三条路各管一段但很多人容易搞混我先把原理理顺。剪枝做的事情是“拆结构”。模型里很多通道和权重对最终输出的贡献其实很小训练完之后这些冗余几乎不会影响精度。剪枝就是把不重要的连接或者整个卷积核通道删掉让网络变窄。这样计算量直接下降模型体积也同步缩小。核心难点在于怎么判断一个通道“不重要”以及剪完之后怎么恢复精度。量化做的事情是“降精度”。模型训练和推理时默认用32位浮点数表示权重和激活值但实际很多场景用8位整数就够了。把32位降到8位模型体积直接缩到四分之一推理时因为可以用整数运算在支持相应指令集的CPU上速度提升非常明显。代价是数值精度损失某些敏感层可能掉点严重需要针对性处理。知识蒸馏做的事情是“换骨干”。用一个又大又准的模型当老师教一个小而快的模型当学生让小模型去模仿大模型的输出分布而不只是学习硬标签。这等于绕过结构搜索的麻烦直接借老师的“经验”把小模型的精度往上拉。蒸馏不能直接减少计算量但它能让你放心地换一个更小的网络结构属于“间接压缩”。三条路线不互斥实际工程里通常是组合使用。我这次就是先剪枝再量化最后用蒸馏把精度拉回来形成一套完整的处理流水线。1.3 为什么这次要组合使用而不是单点突破单用剪枝的话虽然能把计算量压下来但模型体积缩不到20MB以下。单用量化的话体积能达标但原来120毫秒的推理耗时主要在卷积层的计算上量化对卷积算子密集的场景帮助有限速度未必能腰斩。单用蒸馏的话就更不够了它根本不直接改结构。所以我的策略是分步走第一步用结构化剪枝把卷积通道数量降下来目标是把计算量从3.8GFLOPs压到1.2GFLOPs左右第二步用后训练量化把权重从FP32压到INT8把42MB的文件压到十几MB第三步如果精度低于90%就用知识蒸馏做一次“修复”让压缩后的模型再跟原始大模型学一段。这个思路比较稳妥每一步的效果都能单独量化评估出问题时也好定位。2. 实操过程剪枝、量化、蒸馏的完整流水线2.1 先从性能剖析开始别急着动手我之前在组里带过几个新人发现一个普遍毛病拿到慢模型第一反应就是上网搜“怎么加速”然后乱调一气最后也不知道是哪个改动起了作用。这周我自己动手前先做了一个标准动作——性能剖析。我用了常见的性能分析工具跑了一遍原始模型在目标设备上的推理过程按层统计耗时和访存量。结果非常清晰模型里有大量卷积层前几层分辨率高的卷积耗时尤其突出整个推理过程中卷积操作约占总耗时的78%。这说明计算瓶颈集中在卷积算子而不是全连接层也不是数据预处理或后处理。因此剪枝的重点应该放在卷积层的通道数上尤其是输入分辨率大的浅层而不是平均用力。这一步很多人会跳过但我建议无论如何都要做。因为它直接决定你后续的优化方向省下的时间远超剖析本身花掉的那一点点。2.2 结构化剪枝基于BN层稀疏化重新训练确定方向后我开始做剪枝。我采用的是业界比较成熟的结构化剪枝方案——利用批归一化层的缩放因子作为通道重要性指标。基本原理是BN层在训练时会学到每个通道的缩放系数如果某个通道对应的缩放因子趋近于零说明这个通道的输出几乎没有变化对后续层的影响很小这样的通道可以安全剪掉。为了把更多通道的缩放因子往零推我需要在正常训练loss之外加一个稀疏化惩罚项公式是L L_ce λ * Σ|γ|其中λ控制惩罚强度γ就是BN层缩放因子。我实践中把λ设为1e-4先用原有训练数据继续训练了20个epoch让缩放因子分布逐步变得稀疏。这里有一个经验参数λ太大会把模型精度直接搞崩太小又压不出足够的稀疏度我建议从1e-5开始尝试每次翻10倍观察缩放因子分布的变化找到合适量级。训练完成后我开始统计所有BN层缩放因子的分布。我设定的目标是把通道数保留为原来的70%也就是剪掉30%。方法不复杂把所有缩放因子排序取30%分位数作为阈值低于阈值的通道删掉。关键是处理好残差连接——如果某条捷径分支的通道数和主分支对不上会直接导致维度错误。我在代码里专门对残差结构做了对齐处理保留同一残差块的输出通道一致性。剪完结构后我把模型保存下来做了一次单独评估。精度从91.2%掉到了89.8%符合预期。然后我用较小的学习率继续微调了30个epoch精度回升到90.6%虽然还没到位但已经足够支撑后面继续压缩了。2.3 后训练量化PTQ才是工程首选剪枝之后模型小了一圈接下来处理体积问题。这里我选择的是后训练量化而不是量化感知训练。原因很简单后训练量化不需要重新训练模型只需要准备少量校准数据在推理引擎里跑一下统计数据分布就能算出每层的量化参数。量化感知训练虽然精度通常更好但需要改训练代码还得重新训一轮周期太长。对于已有模型的小步优化PTQ往往是性价比最高的起点。具体操作上我用了对称量化和非对称量化做对比。针对我的模型Conv层用per-tensor的对称量化激活值用per-channel的不对称量化整体效果最稳。校准数据集我从训练集里抽了500张有代表性的图片——注意这里一定要覆盖各种光照、角度和缺陷形态不能只挑清晰的。如果校准集太单一量化参数会偏向某一种分布推理时就可能在真实数据上掉点。量化完结果如下表方案体积单帧耗时精度原始模型42MB120ms91.2%剪枝后26MB68ms90.6%剪枝量化13MB33ms90.2%剪枝量化蒸馏13MB28ms91.0%你看到“剪枝量化”这一步体积和速度都已经达标了但精度还差一点点。如果业务方对精度要求不高其实到这一步就可以收工。但我这次指标压着90%的线90.2%太悬所以决定再上一个蒸馏来兜底。2.4 知识蒸馏让大模型当老师小模型当学生蒸馏这一步我没有重新训练一个学生网络而是把剪枝量化后的模型本身当作学生让原始大模型当老师。这里有一个容易忽略的前提老师模型的输出要先做softmax温度缩放而不是直接用概率分布。温度系数设为3目的是让类别分布更平滑小模型能学到类别之间的相似关系而不是只盯着答案本身。损失函数我用的是硬标签交叉熵和软标签KL散度的加权和L α * CE(y_hard, p_student) (1-α) * KL(softmax(logits_teacher / T), softmax(logits_student / T))α我设为0.7T设为3。训练时冻结老师模型只更新学生模型学习率设成正常训练的十分之一。总共训练了20个epoch精度最终恢复到91.0%比原始模型只低了0.2个百分点算是非常理想的结果。有一个细节我想单独提出来蒸馏使用的是老师模型的纯logits而不是推理引擎里量化后的输出。一开始我把老师也走了量化通道结果软标签里夹杂了量化噪声学生学得很别扭精度反而下滑。改成用FP32的老师模型输出后问题立刻消失。这个坑不算深但很容易掉进去值得标记一下。3. 部署环节的工程细节从PyTorch到边缘设备3.1 模型导出与算子兼容性检查模型调好之后接下来的重头戏是把它导出并部署到目标设备上。我这里使用的流程是先把PyTorch训练好的模型转成开放神经网络交换格式ONNX再用推理引擎做加载和优化。导出这一步最需要注意的是动态维度设置。我的输入尺寸固定是320×320不需要动态宽高所以直接把动态轴关掉这样后续推理引擎能做更多的静态优化。如果你需要支持任意分辨率输入就得设置动态轴并接受一部分性能损失这是个需要实际权衡的取舍。导出后我顺手跑了一遍官方提供的算子兼容性检查工具结果发现模型里有一个自定义的前处理算子不被推理引擎支持。这类问题非常常见尤其是模型里有一些自己写的网络层时。解决方案不复杂把这个算子的逻辑搬到CPU端用Python或C实现模型里只保留标准卷积和激活算子。对前处理这种几乎不耗时的操作来说搬到外部执行完全不影响性能。3.2 推理引擎选型与线程参数配置部署时我对比了手头两个候选推理引擎一个是跨平台的开源运行时下文简称运行时R另一个是面向特定硬件做深度优化的商业引擎引擎E。在目标设备上实测引擎E在INT8模型上能跑到28毫秒单帧运行时R大约在35毫秒。说实话这个差距不算大但引擎E多出来的优势主要集中在对特殊指令集的深度优化上。这里我要多说一句不要盲目追求所谓“性能最强”的引擎还要考虑维护成本、部署体积、硬件适配范围。引擎E虽然快但授权和平台绑定的限制比较死。如果后续要换硬件平台代码改动量会大一些。运行时R胜在跨平台、完全开源遇到问题社区里资料也多。最终我选择以运行时R为主引擎E作为备选方案。线程数配置上最稳妥的做法是跑一个简单的线程扫描脚本分别用1到8个线程测试推理延迟画一条曲线找拐点。我实测下来4线程最优线程数再往上加延迟几乎不变反而因为系统调度开销导致偶尔出现尖刺。同时我把CPU亲和性设置为只绑定前四个物理核避免推理任务在核心之间频繁切换实测延迟稳定性有明显改善。3.3 推理管线整体性能实测为了确保单帧50毫秒的指标不是侥幸达标我做了一个带真实数据输入的连续推理测试模拟产线相机一秒拍10张图的实际频率。测试持续跑了一个小时统计了每一帧的端到端耗时。最终平均耗时28毫秒P99耗时32毫秒没有出现超过40毫秒的帧。这个结果说明系统有充足余量即使相机帧率偶尔提高或者CPU被其他进程抢占一部分也不会直接导致超时。除了延迟我也监控了内存占用。模型本身13MB推理引擎运行时的固定分配加上临时缓冲峰值内存约320MB离2GB的上限还有很大空间。稳定性方面我跑了72小时的压力测试没有出现内存泄漏或崩溃。4. 本周踩坑复盘几个容易让人彻夜难眠的问题4.1 剪枝后残差连接维度对不上第一次跑剪枝脚本时我剪到一半就报错提示拼接时维度不匹配。当时我以为只是稀疏化训练没到位后来逐层排查才发现是个很基础的认知问题剪枝不只是删通道还要同步调整后续所有依赖这个通道数的层。尤其是残差结构里的捷径分支它的输出必须和主分支保持完全一致的通道数。如果只剪主分支不剪捷径维度必然冲突。解决办法是把残差块内所有卷积层的剪枝索引做对齐或者更简单——剪枝前先找出所有需要同步裁剪的层组统一生成一份裁剪掩码再按掩码逐层剪。4.2 量化校准集太少的灾难性后果一开始我图省事从验证集里抽了100张图做量化校准结果量化后的模型在真实测试集上精度直接掉了3个百分点连86%都不到我当时第一反应是量化方案有问题。后来仔细对比才发现100张图里包含的缺陷类别不均匀有几类缺陷一张都没出现量化参数根本没有统计到那部分的激活值分布。校准集扩大到500张并做了类别均衡之后精度损失降到了0.2个百分点。这个事让我长了个记性量化校准不是过流程数据分布不贴近真实场景后面所有指标都会失真。4.3 动态shape导致引擎端推理报错导出模型时我偷懒没有关闭动态轴结果在推理引擎里跑单帧没有任何问题一旦把batch调成4就报错提示某个算子的输入维度不合法。查了半天发现是动态维度在引擎优化时没法确定最优内存布局。最后的解决办法很简单模型输入固定为单batch动态轴全部关掉。代价是没法多帧并行推理但我们的场景本身就是单路视频流完全没有影响。4.4 常见问题速查表我把这一周遇到的其他小问题也整理成了一个表格方便后面遇到类似情况快速定位问题现象根本原因处理方式剪枝后推理结果全错shortcut通道未对齐使用统一的剪枝掩码同步裁剪依赖层PTQ后精度大幅下降校准集数量不足或分布偏斜扩大校准集并做类别均衡引擎端动态shape报错动态轴导致内存布局不确定固定batch并关闭动态轴自定义算子无法加载引擎不支持该算子将算子逻辑移到CPU端实现蒸馏后精度不升反降老师模型混入了量化噪声使用FP32原始模型的logits做监督帧延迟偶发尖刺线程绑定不充分频繁迁移设置CPU亲和性和核心绑定这些坑单看都不算复杂但它们恰恰是部署过程中最消耗时间的部分。我建议每位准备做模型部署的同学提前想清楚算子兼容性和数据分布这两件事至少能少加一半的班。5. 本周阅读推荐与信息流摘要5.1 值得精读的两篇论文这周虽然以实践为主我还是抽空看了两篇和模型压缩相关的新文章都很值得推荐。第一篇讨论的是自适应剪枝的新思路核心观点是不再用一个全局阈值来删通道而是让网络在训练过程中自己学出一种“剪辑策略”每个样本可以动态跳过部分通道。和传统的静态剪枝相比这种方法在推理时可以按输入难度调节计算量简单样本甚至能跳过将近一半的卷积计算而我这次用的静态阈值方案显然做不到这一点。如果后续场景里输入复杂度差异比较明显我会认真考虑迁移这个方案。第二篇是量化感知训练方面的改进研究。传统做法是让模型在训练时就模拟量化的舍入误差这篇文章提出的方法核心是逐步从高精度过渡到低精度让模型有一个“适应期”而不是一步到位直接切到INT8。实验结果显示在较大模型上的精度保持能力比现有方案强不少。虽然我这次的PTQ已经够用但如果下次遇到一个对精度特别敏感、掉点完全不可接受的任务这条路值得走。5.2 一个复现笔记轻量检测器在ARM平台上的优化本周还花了一点时间复现了一个轻量级检测器在ARM平台上的优化案例。这个项目跟我做的场景很类似也是视觉检测但是跑在更低功耗的ARM开发板上。它让我看到一套完整的优化链路模型选型时直接用MobileNetV3作为骨干推理引擎选用带硬件加速的运行时同时把图像预处理全部换成NEON向量化指令实现。我复现后的结果是输入224×224单帧推理耗时22毫秒精度和原来大模型的差距在可接受范围内。这个结果说明如果项目允许从头选择模型结构直接选择一个轻量化骨干网络往往比做大模型再压缩更划算。道理很简单从设计层面就已经为端侧环境考虑好了省去后面大量补救工作。但现实情况往往是我们已有的模型已经训完这时候再推倒重来时间成本太高所以剪枝、量化和蒸馏这套组合方案依然是我认为最稳妥的解法。6. 本周复盘关于轻量化我个人的几点体会连续做了两周的模型压缩和部署我最大的感受是轻量化从来不是某一个算法的功劳而是一个围绕场景约束做系统权衡的过程。剪枝解决计算量量化解决体积和访存量蒸馏修正精度损失推理引擎的配置决定最终能跑出多少性能——每一步都在为下一步铺路任何一个环节偷懒最终结果都会打折扣。我最想给的建议是动手之前先花半天做性能剖析。搞清楚模型到底慢在哪、胖在哪再决定用哪一招。绝大多数人上来就量化的习惯其实是有风险的如果瓶颈是卷积计算本身量化不一定能帮你达到延迟目标反而可能白白损失0.5个点精度。另外校准数据这件事怎么强调都不为过。我这次的精度问题最后能解决靠的不是更高级的算法而是老老实实多抽了500张图把分布弄均匀。工程里很多“玄学问题”追根溯源都是数据分布没拿捏住。这周的内容基本就是这样。下周我计划继续沿着这个方向深挖两个点一是量化参数的硬件亲和性也就是不同芯片对量化格式的支持差异到底怎么影响性能二是蒸馏时教师logits标准化处理的改进方案。希望这篇周报对你手头的部署任务有一点点帮助。 
长河君 · 2026/10/20 2:50:49 · 阅读 1.2k 模型轻量化与高效部署实战：剪枝、量化、蒸馏全流程解析
写周报这件事我不知不觉坚持到了第三十九期。从最开始记录一些基础论文的阅读笔记到后来逐渐转向实验复现、工程踩坑、性能调优这三十几周的内容基本就是我一个人从入门到能独立做一些模型落地工作的完整轨迹。这一期我不想写那种罗列了一堆论文标题的流水账我想认真聊聊一个相对朴素但非常关键的问题一个在实验环境里跑得不错的模型到底要经过哪些折腾才能真正落到产线设备上跑得又快又稳还不出幺蛾子。这一期的主题就定为模型轻量化与高效部署实战内容会包含完整的方案选型、实操记录、性能对比以及这一周里我踩过的几个坑。如果你正在做算法落地或者手头有个模型因为体积太大、推理太慢被业务方反复打回这篇周报应该能给你一些能直接抄作业的参考。本期所有实验都基于一个自建的小型视觉检测任务场景不算复杂但涉及的问题非常典型模型太大、算力受限、环境苛刻每一步都需要做取舍。1. 本期主线模型轻量化到底在解决什么问题1.1 场景背景与约束条件这周接到的需求是这样产线上有一个外观检测点位原来靠人工目检现在想换成一个边缘盒子做实时自动检测。设备的规格很明确——没有独立显卡CPU是四核的嵌入式平台内存一共2GB系统是裁剪过的Linux发行版。检测目标不算难几类常见的表面缺陷背景相对固定光照变化也不剧烈。业务方给的关键指标只有三个单帧推理耗时必须控制在50毫秒以内模型文件不超过20MB检测精度不能低于90%。听起来指标不算苛刻但我实际去跑才发现组里之前那个已经训好的模型本质上是拿深度残差网络当骨干做特征提取加上一层特征融合结构光权重文件就有42MB参数量约1100万。在目标设备上实测单帧推理耗时120毫秒GPU上用完全没问题搬到这块板子上直接超了两倍多。如果只是做几个小改动比如换输入分辨率或者改一下后处理顶多把120毫秒压到90毫秒左右还是不达标。这种情况唯一的出路就是对模型本身动刀子——做压缩和加速也就是所谓的模型轻量化。1.2 三条主流技术路线的原理对比面对模型体积大、算力需求高的问题业界常见的思路无非三条剪枝、量化、知识蒸馏。这三条路各管一段但很多人容易搞混我先把原理理顺。剪枝做的事情是“拆结构”。模型里很多通道和权重对最终输出的贡献其实很小训练完之后这些冗余几乎不会影响精度。剪枝就是把不重要的连接或者整个卷积核通道删掉让网络变窄。这样计算量直接下降模型体积也同步缩小。核心难点在于怎么判断一个通道“不重要”以及剪完之后怎么恢复精度。量化做的事情是“降精度”。模型训练和推理时默认用32位浮点数表示权重和激活值但实际很多场景用8位整数就够了。把32位降到8位模型体积直接缩到四分之一推理时因为可以用整数运算在支持相应指令集的CPU上速度提升非常明显。代价是数值精度损失某些敏感层可能掉点严重需要针对性处理。知识蒸馏做的事情是“换骨干”。用一个又大又准的模型当老师教一个小而快的模型当学生让小模型去模仿大模型的输出分布而不只是学习硬标签。这等于绕过结构搜索的麻烦直接借老师的“经验”把小模型的精度往上拉。蒸馏不能直接减少计算量但它能让你放心地换一个更小的网络结构属于“间接压缩”。三条路线不互斥实际工程里通常是组合使用。我这次就是先剪枝再量化最后用蒸馏把精度拉回来形成一套完整的处理流水线。1.3 为什么这次要组合使用而不是单点突破单用剪枝的话虽然能把计算量压下来但模型体积缩不到20MB以下。单用量化的话体积能达标但原来120毫秒的推理耗时主要在卷积层的计算上量化对卷积算子密集的场景帮助有限速度未必能腰斩。单用蒸馏的话就更不够了它根本不直接改结构。所以我的策略是分步走第一步用结构化剪枝把卷积通道数量降下来目标是把计算量从3.8GFLOPs压到1.2GFLOPs左右第二步用后训练量化把权重从FP32压到INT8把42MB的文件压到十几MB第三步如果精度低于90%就用知识蒸馏做一次“修复”让压缩后的模型再跟原始大模型学一段。这个思路比较稳妥每一步的效果都能单独量化评估出问题时也好定位。2. 实操过程剪枝、量化、蒸馏的完整流水线2.1 先从性能剖析开始别急着动手我之前在组里带过几个新人发现一个普遍毛病拿到慢模型第一反应就是上网搜“怎么加速”然后乱调一气最后也不知道是哪个改动起了作用。这周我自己动手前先做了一个标准动作——性能剖析。我用了常见的性能分析工具跑了一遍原始模型在目标设备上的推理过程按层统计耗时和访存量。结果非常清晰模型里有大量卷积层前几层分辨率高的卷积耗时尤其突出整个推理过程中卷积操作约占总耗时的78%。这说明计算瓶颈集中在卷积算子而不是全连接层也不是数据预处理或后处理。因此剪枝的重点应该放在卷积层的通道数上尤其是输入分辨率大的浅层而不是平均用力。这一步很多人会跳过但我建议无论如何都要做。因为它直接决定你后续的优化方向省下的时间远超剖析本身花掉的那一点点。2.2 结构化剪枝基于BN层稀疏化重新训练确定方向后我开始做剪枝。我采用的是业界比较成熟的结构化剪枝方案——利用批归一化层的缩放因子作为通道重要性指标。基本原理是BN层在训练时会学到每个通道的缩放系数如果某个通道对应的缩放因子趋近于零说明这个通道的输出几乎没有变化对后续层的影响很小这样的通道可以安全剪掉。为了把更多通道的缩放因子往零推我需要在正常训练loss之外加一个稀疏化惩罚项公式是L L_ce λ * Σ|γ|其中λ控制惩罚强度γ就是BN层缩放因子。我实践中把λ设为1e-4先用原有训练数据继续训练了20个epoch让缩放因子分布逐步变得稀疏。这里有一个经验参数λ太大会把模型精度直接搞崩太小又压不出足够的稀疏度我建议从1e-5开始尝试每次翻10倍观察缩放因子分布的变化找到合适量级。训练完成后我开始统计所有BN层缩放因子的分布。我设定的目标是把通道数保留为原来的70%也就是剪掉30%。方法不复杂把所有缩放因子排序取30%分位数作为阈值低于阈值的通道删掉。关键是处理好残差连接——如果某条捷径分支的通道数和主分支对不上会直接导致维度错误。我在代码里专门对残差结构做了对齐处理保留同一残差块的输出通道一致性。剪完结构后我把模型保存下来做了一次单独评估。精度从91.2%掉到了89.8%符合预期。然后我用较小的学习率继续微调了30个epoch精度回升到90.6%虽然还没到位但已经足够支撑后面继续压缩了。2.3 后训练量化PTQ才是工程首选剪枝之后模型小了一圈接下来处理体积问题。这里我选择的是后训练量化而不是量化感知训练。原因很简单后训练量化不需要重新训练模型只需要准备少量校准数据在推理引擎里跑一下统计数据分布就能算出每层的量化参数。量化感知训练虽然精度通常更好但需要改训练代码还得重新训一轮周期太长。对于已有模型的小步优化PTQ往往是性价比最高的起点。具体操作上我用了对称量化和非对称量化做对比。针对我的模型Conv层用per-tensor的对称量化激活值用per-channel的不对称量化整体效果最稳。校准数据集我从训练集里抽了500张有代表性的图片——注意这里一定要覆盖各种光照、角度和缺陷形态不能只挑清晰的。如果校准集太单一量化参数会偏向某一种分布推理时就可能在真实数据上掉点。量化完结果如下表方案体积单帧耗时精度原始模型42MB120ms91.2%剪枝后26MB68ms90.6%剪枝量化13MB33ms90.2%剪枝量化蒸馏13MB28ms91.0%你看到“剪枝量化”这一步体积和速度都已经达标了但精度还差一点点。如果业务方对精度要求不高其实到这一步就可以收工。但我这次指标压着90%的线90.2%太悬所以决定再上一个蒸馏来兜底。2.4 知识蒸馏让大模型当老师小模型当学生蒸馏这一步我没有重新训练一个学生网络而是把剪枝量化后的模型本身当作学生让原始大模型当老师。这里有一个容易忽略的前提老师模型的输出要先做softmax温度缩放而不是直接用概率分布。温度系数设为3目的是让类别分布更平滑小模型能学到类别之间的相似关系而不是只盯着答案本身。损失函数我用的是硬标签交叉熵和软标签KL散度的加权和L α * CE(y_hard, p_student) (1-α) * KL(softmax(logits_teacher / T), softmax(logits_student / T))α我设为0.7T设为3。训练时冻结老师模型只更新学生模型学习率设成正常训练的十分之一。总共训练了20个epoch精度最终恢复到91.0%比原始模型只低了0.2个百分点算是非常理想的结果。有一个细节我想单独提出来蒸馏使用的是老师模型的纯logits而不是推理引擎里量化后的输出。一开始我把老师也走了量化通道结果软标签里夹杂了量化噪声学生学得很别扭精度反而下滑。改成用FP32的老师模型输出后问题立刻消失。这个坑不算深但很容易掉进去值得标记一下。3. 部署环节的工程细节从PyTorch到边缘设备3.1 模型导出与算子兼容性检查模型调好之后接下来的重头戏是把它导出并部署到目标设备上。我这里使用的流程是先把PyTorch训练好的模型转成开放神经网络交换格式ONNX再用推理引擎做加载和优化。导出这一步最需要注意的是动态维度设置。我的输入尺寸固定是320×320不需要动态宽高所以直接把动态轴关掉这样后续推理引擎能做更多的静态优化。如果你需要支持任意分辨率输入就得设置动态轴并接受一部分性能损失这是个需要实际权衡的取舍。导出后我顺手跑了一遍官方提供的算子兼容性检查工具结果发现模型里有一个自定义的前处理算子不被推理引擎支持。这类问题非常常见尤其是模型里有一些自己写的网络层时。解决方案不复杂把这个算子的逻辑搬到CPU端用Python或C实现模型里只保留标准卷积和激活算子。对前处理这种几乎不耗时的操作来说搬到外部执行完全不影响性能。3.2 推理引擎选型与线程参数配置部署时我对比了手头两个候选推理引擎一个是跨平台的开源运行时下文简称运行时R另一个是面向特定硬件做深度优化的商业引擎引擎E。在目标设备上实测引擎E在INT8模型上能跑到28毫秒单帧运行时R大约在35毫秒。说实话这个差距不算大但引擎E多出来的优势主要集中在对特殊指令集的深度优化上。这里我要多说一句不要盲目追求所谓“性能最强”的引擎还要考虑维护成本、部署体积、硬件适配范围。引擎E虽然快但授权和平台绑定的限制比较死。如果后续要换硬件平台代码改动量会大一些。运行时R胜在跨平台、完全开源遇到问题社区里资料也多。最终我选择以运行时R为主引擎E作为备选方案。线程数配置上最稳妥的做法是跑一个简单的线程扫描脚本分别用1到8个线程测试推理延迟画一条曲线找拐点。我实测下来4线程最优线程数再往上加延迟几乎不变反而因为系统调度开销导致偶尔出现尖刺。同时我把CPU亲和性设置为只绑定前四个物理核避免推理任务在核心之间频繁切换实测延迟稳定性有明显改善。3.3 推理管线整体性能实测为了确保单帧50毫秒的指标不是侥幸达标我做了一个带真实数据输入的连续推理测试模拟产线相机一秒拍10张图的实际频率。测试持续跑了一个小时统计了每一帧的端到端耗时。最终平均耗时28毫秒P99耗时32毫秒没有出现超过40毫秒的帧。这个结果说明系统有充足余量即使相机帧率偶尔提高或者CPU被其他进程抢占一部分也不会直接导致超时。除了延迟我也监控了内存占用。模型本身13MB推理引擎运行时的固定分配加上临时缓冲峰值内存约320MB离2GB的上限还有很大空间。稳定性方面我跑了72小时的压力测试没有出现内存泄漏或崩溃。4. 本周踩坑复盘几个容易让人彻夜难眠的问题4.1 剪枝后残差连接维度对不上第一次跑剪枝脚本时我剪到一半就报错提示拼接时维度不匹配。当时我以为只是稀疏化训练没到位后来逐层排查才发现是个很基础的认知问题剪枝不只是删通道还要同步调整后续所有依赖这个通道数的层。尤其是残差结构里的捷径分支它的输出必须和主分支保持完全一致的通道数。如果只剪主分支不剪捷径维度必然冲突。解决办法是把残差块内所有卷积层的剪枝索引做对齐或者更简单——剪枝前先找出所有需要同步裁剪的层组统一生成一份裁剪掩码再按掩码逐层剪。4.2 量化校准集太少的灾难性后果一开始我图省事从验证集里抽了100张图做量化校准结果量化后的模型在真实测试集上精度直接掉了3个百分点连86%都不到我当时第一反应是量化方案有问题。后来仔细对比才发现100张图里包含的缺陷类别不均匀有几类缺陷一张都没出现量化参数根本没有统计到那部分的激活值分布。校准集扩大到500张并做了类别均衡之后精度损失降到了0.2个百分点。这个事让我长了个记性量化校准不是过流程数据分布不贴近真实场景后面所有指标都会失真。4.3 动态shape导致引擎端推理报错导出模型时我偷懒没有关闭动态轴结果在推理引擎里跑单帧没有任何问题一旦把batch调成4就报错提示某个算子的输入维度不合法。查了半天发现是动态维度在引擎优化时没法确定最优内存布局。最后的解决办法很简单模型输入固定为单batch动态轴全部关掉。代价是没法多帧并行推理但我们的场景本身就是单路视频流完全没有影响。4.4 常见问题速查表我把这一周遇到的其他小问题也整理成了一个表格方便后面遇到类似情况快速定位问题现象根本原因处理方式剪枝后推理结果全错shortcut通道未对齐使用统一的剪枝掩码同步裁剪依赖层PTQ后精度大幅下降校准集数量不足或分布偏斜扩大校准集并做类别均衡引擎端动态shape报错动态轴导致内存布局不确定固定batch并关闭动态轴自定义算子无法加载引擎不支持该算子将算子逻辑移到CPU端实现蒸馏后精度不升反降老师模型混入了量化噪声使用FP32原始模型的logits做监督帧延迟偶发尖刺线程绑定不充分频繁迁移设置CPU亲和性和核心绑定这些坑单看都不算复杂但它们恰恰是部署过程中最消耗时间的部分。我建议每位准备做模型部署的同学提前想清楚算子兼容性和数据分布这两件事至少能少加一半的班。5. 本周阅读推荐与信息流摘要5.1 值得精读的两篇论文这周虽然以实践为主我还是抽空看了两篇和模型压缩相关的新文章都很值得推荐。第一篇讨论的是自适应剪枝的新思路核心观点是不再用一个全局阈值来删通道而是让网络在训练过程中自己学出一种“剪辑策略”每个样本可以动态跳过部分通道。和传统的静态剪枝相比这种方法在推理时可以按输入难度调节计算量简单样本甚至能跳过将近一半的卷积计算而我这次用的静态阈值方案显然做不到这一点。如果后续场景里输入复杂度差异比较明显我会认真考虑迁移这个方案。第二篇是量化感知训练方面的改进研究。传统做法是让模型在训练时就模拟量化的舍入误差这篇文章提出的方法核心是逐步从高精度过渡到低精度让模型有一个“适应期”而不是一步到位直接切到INT8。实验结果显示在较大模型上的精度保持能力比现有方案强不少。虽然我这次的PTQ已经够用但如果下次遇到一个对精度特别敏感、掉点完全不可接受的任务这条路值得走。5.2 一个复现笔记轻量检测器在ARM平台上的优化本周还花了一点时间复现了一个轻量级检测器在ARM平台上的优化案例。这个项目跟我做的场景很类似也是视觉检测但是跑在更低功耗的ARM开发板上。它让我看到一套完整的优化链路模型选型时直接用MobileNetV3作为骨干推理引擎选用带硬件加速的运行时同时把图像预处理全部换成NEON向量化指令实现。我复现后的结果是输入224×224单帧推理耗时22毫秒精度和原来大模型的差距在可接受范围内。这个结果说明如果项目允许从头选择模型结构直接选择一个轻量化骨干网络往往比做大模型再压缩更划算。道理很简单从设计层面就已经为端侧环境考虑好了省去后面大量补救工作。但现实情况往往是我们已有的模型已经训完这时候再推倒重来时间成本太高所以剪枝、量化和蒸馏这套组合方案依然是我认为最稳妥的解法。6. 本周复盘关于轻量化我个人的几点体会连续做了两周的模型压缩和部署我最大的感受是轻量化从来不是某一个算法的功劳而是一个围绕场景约束做系统权衡的过程。剪枝解决计算量量化解决体积和访存量蒸馏修正精度损失推理引擎的配置决定最终能跑出多少性能——每一步都在为下一步铺路任何一个环节偷懒最终结果都会打折扣。我最想给的建议是动手之前先花半天做性能剖析。搞清楚模型到底慢在哪、胖在哪再决定用哪一招。绝大多数人上来就量化的习惯其实是有风险的如果瓶颈是卷积计算本身量化不一定能帮你达到延迟目标反而可能白白损失0.5个点精度。另外校准数据这件事怎么强调都不为过。我这次的精度问题最后能解决靠的不是更高级的算法而是老老实实多抽了500张图把分布弄均匀。工程里很多“玄学问题”追根溯源都是数据分布没拿捏住。这周的内容基本就是这样。下周我计划继续沿着这个方向深挖两个点一是量化参数的硬件亲和性也就是不同芯片对量化格式的支持差异到底怎么影响性能二是蒸馏时教师logits标准化处理的改进方案。希望这篇周报对你手头的部署任务有一点点帮助。