课程导入：了解Edge AI模型压缩评估的背景、目标与整体学习路径
边缘人工智能（Edge AI）正在从概念验证走向规模化落地。无论是工业质检相机、车载感知单元、智能门锁，还是医疗便携设备，模型部署的物理载体已经从云端GPU集群迁移到功耗受限、算力有限、内存紧张的嵌入式平台。这一迁移带来一个核心矛盾：模型性能（精度）与部署代价（延迟、体积）之间的张力。模型压缩技术——量化、剪枝、蒸馏、低秩分解等——正是为了缓解这一矛盾而生。然而，压缩本身并非目的，如何在精度、延迟和体积三个维度之间做出工程上可接受的联合判断，才是决定一个Edge AI项目能否真正量产的关键。本章作为全课程的开篇，将为你建立评估框架的整体认知，明确三大维度的内在关系，并规划后续29章的学习路径。
1.1 为什么需要联合评估：从“能跑”到“跑得好”
很多工程师在接触模型压缩时，第一个直觉是“压缩后精度别掉太多就行”。这种思路在原型验证阶段勉强可行，但一旦进入产品化阶段就会暴露出严重问题。一个在PC上推理耗时50ms的模型，部署到树莓派上可能变成500ms；一个量化后精度仅下降0.5%的模型，在特定光照条件下可能产生灾难性的误检。这说明脱离硬件和场景谈压缩指标毫无意义。
联合评估的本质，是将三个维度放在同一个决策框架下进行权衡。精度决定了模型是否“可用”，延迟决定了系统是否“实时”，体积决定了硬件成本与升级成本是否“可接受”。三者相互制约：追求极致精度往往意味着更大的模型和更长的延迟；激进压缩虽然能大幅缩减体积，但可能让精度跌破业务红线。因此，评估的目标不是让某个单一指标最优，而是在满足所有约束的前提下，找到最合适的压缩配置。
| 评估维度 | 典型指标 | 业务含义 | 常见测量工具 |
|---|---|---|---|
| 精度 | Top-1/Top-5、mAP、F1、IoU、PSNR | 模型输出与真实标签的吻合程度，直接决定业务效果 | 验证集评估、混淆矩阵、PR曲线 |
| 延迟 | 单帧耗时（ms）、P99延迟、FPS、端到端时延 | 从输入到输出的响应速度，决定实时性与用户体验 | 推理框架benchmark、硬件计时器、profiler |
| 体积 | 模型文件大小（MB/KB）、RAM峰值、Flash占用 | 决定可部署的硬件规格、OTA升级成本、多模型共存能力 | 模型序列化统计、内存剖析工具 |
1.2 三大维度的内在关系：此消彼长与协同优化
精度、延迟和体积并非简单的线性负相关。它们之间的关系取决于具体的压缩技术、硬件架构和模型结构。理解这些关系，是进行联合判断的前提。
精度 vs 体积：通常，模型体积越小，表征能力越弱，精度越低。但不同压缩技术对精度的侵蚀程度差异巨大。例如，8位量化在大多数任务上仅损失0.1%~0.5%的精度，而结构化剪枝若比例过高（如>70%），精度可能骤降5%以上。此外，知识蒸馏甚至可以在缩小模型体积的同时，让精度超过原始大模型——这取决于教师模型的质量和学生模型的结构设计。
延迟 vs 体积：体积减小通常意味着计算量减少，延迟随之降低。但这一关系并非。例如，某些NPU对稀疏模型的支持不佳，剪枝后的模型虽然体积变小，但推理时无法利用稀疏性，延迟反而可能增加。又如，低比特量化（如4位）虽然能显著减小体积，但如果硬件不支持高效的4位运算，实际延迟可能比8位更差。
精度 vs 延迟：这是最直观的权衡。更深的网络、更大的输入分辨率带来更高精度，但延迟也随之上升。然而，架构重设计（如MobileNet、EfficientNet）可以在不显著牺牲精度的情况下大幅降低延迟。压缩评估的真正价值，在于找到“精度-延迟”曲线上的帕累托最优点。
1.3 联合评估的整体流程：从目标定义到决策输出
一个规范的联合评估流程，应当包含以下五个阶段。每个阶段都有明确的输入、输出和检查点，确保评估结果可复现、可追溯。
- 约束收集与目标定义：明确业务场景（实时检测/离线分析）、硬件平台（CPU/NPU/MCU）、功耗预算、内存上限、精度底线。输出：评估规格书。
- 基线模型建立：选择或训练一个未压缩的基线模型，在目标硬件上测量其精度、延迟和体积。输出：基线指标报告。
- 压缩策略设计与实施：根据约束选择一种或多种压缩技术（量化、剪枝、蒸馏等），生成候选压缩模型。输出：候选模型集。
- 多维度测量与对比：在目标硬件（或高保真模拟器）上，对每个候选模型测量三大维度的具体数值，并记录测量环境（温度、CPU频率、内存状态等）。输出：测量数据表。
- 联合决策与风险备案：将测量结果与约束进行比对，选择满足所有硬性红线的方案；若多个方案均满足，则根据软性目标（如成本、功耗）进行优选。输出：压缩方案决策书。
| 阶段 | 关键活动 | 输出物 | 常见误区 |
|---|---|---|---|
| 约束收集 | 与硬件/产品团队对齐需求 | 评估规格书 | 忽略硬件实际算力，仅凭芯片手册标称值 |
| 基线建立 | 训练/获取基线模型并测全指标 | 基线指标报告 | 基线模型未在目标硬件上实测 |
| 压缩实施 | 应用量化/剪枝/蒸馏等技术 | 候选模型集 | 一次性叠加多种压缩技术，无法定位精度损失来源 |
| 多维测量 | 统一测量协议下获取数据 | 测量数据表 | 测量时CPU降频/升温导致数据失真 |
| 联合决策 | 权衡取舍，输出最终方案 | 决策书 | 仅看平均精度，忽略P99延迟或极端场景表现 |
1.4 案例拆解：智能门锁人脸识别模型的压缩评估
为了让你更直观地理解联合评估的运作方式，我们来看一个典型的Edge AI场景——智能门锁上的人脸识别模型压缩。
背景与约束：某智能锁厂商计划在下一代产品中集成活体人脸识别功能。硬件平台为Cortex-A53双核CPU（1.2GHz），无NPU，内存512MB，Flash 8MB。产品经理提出硬性要求：识别准确率（TAR@FAR=1e-5）≥95%，从按下门铃到识别完成（含图像采集）≤800ms，模型文件≤3MB（需同时存储多用户模板）。
初始现象：工程师首先训练了一个基于ResNet-50的基线模型，在服务器上精度达到97.2%，模型体积89MB。但将其转换为TFLite并部署到目标硬件后，单次推理耗时高达2.3秒，远超800ms红线。显然，基线模型无法直接部署。
分析判断过程：团队决定采用“知识蒸馏 + 8位量化”的组合压缩策略。首先，以ResNet-50为教师模型，蒸馏训练一个MobileNetV2-0.5x的学生模型（体积约7.2MB）。然后，对该学生模型进行8位量化，体积降至约1.8MB。在服务器上验证，蒸馏后精度为96.1%，量化后精度为95.4%，均高于95%红线。
实际操作步骤：
# 1. 蒸馏训练（简化示意）
python train_distill.py \
--teacher resnet50.h5 \
--student mobilenetv2_05x \
--distill_weight 0.7 \
--dataset faces_ms1m
# 2. 8位量化（TFLite）
converter = tf.lite.TFLiteConverter.from_keras_model(student_model)
converter.optimizations = [tf.lite.Optimize.DEFAULT]
converter.representative_dataset = representative_gen
tflite_model = converter.convert()
# 3. 目标硬件延迟测量
./benchmark_model --graph=model_quant.tflite --num_runs=50结果对比：量化后的模型在目标硬件上实测单次推理耗时420ms，加上图像采集与预处理约150ms，端到端耗时570ms，满足800ms红线。模型体积1.8MB，满足3MB限制。精度95.4%，满足95%要求。三项指标全部达标。
风险与代价：团队发现，在低光照条件下（<10 lux），量化模型的TAR降至93.8%，低于红线。分析原因是量化对浅层特征的敏感度较高。为此，团队在预处理中增加了自适应直方图均衡化，并针对低光照数据进行了额外的量化校准（使用低光照样本作为representative dataset），最终将低光照下的TAR恢复至95.1%。
复盘经验：第一，量化校准数据集必须覆盖目标场景的极端分布，否则量化误差会在边缘条件下被放大。第二，延迟测量必须在最终硬件上进行，模拟器数据仅供参考。第三，联合评估不是一次性动作，当发现某一维度不达标时，需要回溯调整压缩策略或预处理流程。
1.5 常见误区与总结复盘
在Edge AI模型压缩评估的实践中，以下误区反复出现，值得警惕：
- 误区一：只看模型文件大小，忽略运行时内存。某些压缩技术（如权重共享）能减小文件体积，但推理时的激活值内存可能反而增加。
- 误区二：用GPU上的延迟代替目标硬件延迟。GPU与嵌入式CPU/ NPU的计算特性完全不同，量化算子在GPU上的加速比不能迁移到嵌入式平台。
- 误区三：精度评估只使用单一测试集。压缩后的模型可能对特定噪声、光照、遮挡更敏感，必须在多个子集（如夜间、雨天、运动模糊）上分别评估。
- 误区四：忽略功耗与散热的间接影响。延迟增加会导致芯片温度升高，进而触发降频，形成“延迟-温度”正反馈恶性循环。在评估时，应进行至少30分钟的连续推理压力测试。