课程导入：Edge AI压缩的价值与挑战
边缘人工智能（Edge AI）正在从概念验证走向规模化落地。在工业质检、智能安防、车载感知、可穿戴健康监测等场景中，模型必须部署在算力受限、功耗敏感、网络不稳定的终端设备上。模型压缩技术——包括量化、剪枝、知识蒸馏、低秩分解——因此成为边缘部署的关键使能器。然而，压缩并非简单的“模型变小”过程。实践中，工程师经常遭遇三类典型失败：压缩后模型精度急剧下降（精度崩溃）、某些算子在新硬件上无法运行（层不兼容）、以及压缩后推理速度或功耗并无实质改善（收益不足）。本课程将系统拆解这三类问题的根因、诊断方法和修复策略，帮助学员建立从“能压缩”到“会压缩”再到“压得好”的完整能力。
上图展示了本课程的核心框架：左侧是Edge AI压缩带来的实际价值，中间是三大核心问题，右侧是学习路径。三者构成闭环——只有解决了精度崩溃、层不兼容和收益不足，才能真正兑现压缩的价值。下面我们逐一展开。
1.1 Edge AI压缩的价值：为什么必须压缩
边缘设备的硬件资源极其有限。以典型的工业视觉检测设备为例，其嵌入式处理器可能只有2GB内存、4个CPU核心，没有独立GPU。一个ResNet-50模型原始权重约98MB，浮点运算量约3.8GFLOPs，直接部署会导致内存溢出、推理延迟超过500ms，完全无法满足产线节拍要求。模型压缩正是为了解决这一矛盾而生。
压缩的核心价值维度：
- 存储与内存：量化到INT8后模型体积缩小4倍，剪枝可再减少30%~80%参数，使模型能够装入片上SRAM或低功耗DDR。
- 计算效率：INT8矩阵乘法的吞吐量通常是FP32的2~4倍，剪枝后的稀疏网络可跳过无效计算。
- 功耗控制：内存访问是边缘设备功耗的主要来源，压缩后内存读写减少，直接降低动态功耗。
- 实时性：在自动驾驶、工业控制等场景，推理延迟必须控制在10ms~50ms内，压缩是满足硬实时要求的必要手段。
然而，压缩不是免费的午餐。每一次压缩操作都在“精度-速度-功耗”三角中寻找新的平衡点。当平衡被打破时，就出现了本课程要解决的三大问题。
1.2 三大核心问题：精度崩溃、层不兼容、收益不足
在多年的边缘AI部署实践中，我们观察到压缩失败并非随机发生，而是呈现出高度规律性的三类模式。理解这些模式是排查故障的第一步。
| 问题类型 | 典型表现 | 常见根因 | 影响范围 |
|---|---|---|---|
| 精度崩溃 | 压缩后模型精度下降超过5%，或验证集上损失函数发散 | 量化范围选择不当、敏感层被过度剪枝、蒸馏温度过高、权重分布偏移 | 模型整体性能，可能导致无法上线 |
| 层不兼容 | 某些层在目标硬件上无法加速，回退到CPU执行，或直接报错 | 算子不支持、通道数不对齐、数据布局不匹配、硬件指令集限制 | 推理延迟剧增，部分功能失效 |
| 收益不足 | 压缩后模型体积减小，但推理速度没有提升，功耗下降不明显 | 内存带宽瓶颈、非计算层占比高、量化后仍使用FP32计算、剪枝后稀疏度不足 | 压缩投入产出比低，项目ROI为负 |
这三类问题往往相互交织。例如，为了追求更高的压缩比，工程师可能将模型从INT8进一步压缩到INT4，结果导致精度崩溃；修复精度时又可能引入不兼容的算子；最终即使精度恢复，推理速度却因算子回退而毫无提升。因此，本课程强调系统性排查，而非孤立地解决单一问题。
1.3 学习路径与课程目标
本课程共30章，分为四个递进阶段。每个阶段都配有真实案例和可操作的排查清单。
- 基础诊断阶段（第1~8章）：掌握压缩原理、精度评估方法、硬件特性分析。学会使用工具定位精度崩溃的层、识别不兼容的算子、测量实际推理性能。
- 修复与调优阶段（第9~20章）：针对三类问题分别给出修复策略。包括敏感层保护、混合精度量化、算子替换、剪枝重训练、硬件适配层设计等。
- 验证与部署阶段（第21~26章）：在真实硬件上进行端到端验证，包括多线程调度、内存对齐、功耗测量、长稳测试。
- 收益评估与优化阶段（第27~30章）：建立压缩收益的量化评估体系，包括延迟-精度曲线、功耗-精度帕累托前沿、ROI计算模型。
学习建议：每章内容都包含“核心原理→判断方法→案例拆解→常见误区”四个模块。建议学员在阅读案例时，先自己尝试分析原因，再对照文中的排查过程。课程中的代码和配置示例均可在常见的Edge AI框架（如TensorRT、ONNX Runtime、TFLite、RKNN）中复现。
1.4 案例拆解：一个典型的压缩失败项目
为了帮助学员建立对三大问题的直观认识，我们来看一个真实的项目案例。某电子制造企业希望将PCB缺陷检测模型部署到边缘盒子（采用瑞芯微RK3588芯片，8核CPU + 6 TOPS NPU）。原始模型为YOLOv5s，FP32权重14MB，在GPU服务器上mAP@0.5为0.92。
初始压缩方案：直接使用RKNN-Toolkit将模型量化为INT8，目标是将推理延迟从原始的120ms降低到30ms以内。
第一次尝试结果：
- 模型体积从14MB降至3.8MB（压缩比3.7×）
- 但mAP@0.5从0.92骤降至0.61（精度崩溃，下降33.7%）
- 推理延迟为45ms，未达到30ms目标（收益不足）
- 日志显示部分层回退到CPU执行（层不兼容）
排查过程：
- 首先使用逐层精度分析工具，发现第17层（Focus层）和第21层（SPP层）的量化误差最大，这两层的权重分布呈长尾分布，INT8量化范围选择不当。
- 检查NPU支持列表，发现Focus层在RK3588 NPU上不支持，自动回退到CPU执行，导致延迟增加。
- 进一步分析发现，即使修复了精度问题，由于模型中有大量小卷积核（1×1和3×3混合），NPU的利用率只有35%，内存带宽成为瓶颈。
修复措施：
- 将Focus层替换为等价的普通卷积层（结构重参数化），使其在NPU上可加速。
- 对第17层和第21层使用混合精度（保留FP16），其余层使用INT8。
- 对模型进行通道剪枝，将通道数从64/128/256调整为48/96/192，减少内存访问量。
最终结果：mAP@0.5恢复至0.89（仅下降3.3%），推理延迟降至28ms，满足产线要求。但代价是模型体积从3.8MB增至4.5MB（混合精度和结构重参数化导致），压缩比降至3.1×。
案例启示：压缩失败很少是单一原因造成的。本案例中精度崩溃、层不兼容、收益不足三个问题同时出现，且相互影响。如果只修复精度问题而不处理层兼容性，延迟依然不达标；如果只优化延迟而不修复精度，模型无法上线。因此，排查压缩故障必须采用系统性方法，这正是本课程的核心方法论。
1.5 常见误区与总结复盘
在开始正式课程之前，我们先澄清几个常见的认知误区，这些误区往往导致压缩项目从一开始就走向失败。
| 误区 | 实际情况 | 正确做法 |
|---|---|---|
| 压缩比越高越好 | 过高的压缩比会导致精度不可逆损失，且可能引入额外计算开销 | 以“精度-延迟-功耗”三角平衡为目标，而非单纯追求压缩比 |
| 量化后精度下降是正常的 | 精度下降超过1%~2%通常意味着量化配置有问题，而非必然代价 | 使用逐层敏感度分析定位问题层，采用混合精度或量化感知训练 |
| 模型变小推理就一定变快 | 推理速度受内存带宽、算子实现、并行度等多因素影响 | 使用profiler测量实际延迟瓶颈，而非仅看模型体积 |
| 压缩是部署阶段的最后一步 | 压缩应贯穿模型训练和部署全流程，训练时就应考虑压缩友好性 | 采用量化感知训练、剪枝感知训练、结构重参数化等方法 |