2. Edge AI基础

在进入模型压缩与交付的具体技术之前，我们必须先建立对Edge AI运行环境的完整认知。模型压缩不是纯粹的算法游戏，而是针对特定硬件约束的工程妥协。同一个MobileNetV3在手机NPU、车载域控制器、MCU级IoT设备上的部署策略截然不同——这并非算法本身变了，而是硬件边界决定了压缩的维度和量化策略。本章将系统梳理边缘计算的架构定位、端侧推理的硬件约束矩阵，以及三类典型场景（手机、IoT、自动驾驶）对模型交付的具体要求，为后续章节的压缩技术选型提供决策框架。

上图展示了Edge AI部署的核心矛盾：左侧的硬件约束矩阵与右侧的场景需求共同决定了中间设备的模型交付策略。硬件约束是客观物理边界，场景需求是主观功能目标，而模型压缩则是两者之间的桥梁。下面我们逐一展开。

2.1 边缘计算与云计算的本质差异

边缘计算（Edge Computing）并非简单地把服务器搬到离用户更近的地方，而是计算范式的根本转变。在云端推理中，数据从终端传输到数据中心，模型运行在GPU/TPU集群上，网络延迟和带宽是主要瓶颈；而在边缘推理中，模型直接运行在数据产生的设备上，计算资源受限但延迟极低、数据不出设备、隐私性更好。

从工程交付角度看，两者对模型的要求存在显著差异：

这个对比表揭示了模型压缩在边缘场景中的必要性：当算力、内存、功耗三项同时受限时，模型体积和计算量必须被主动压缩，否则无法满足实时性要求。例如，一个YOLOv8m模型（约49MB，FP32）在云端GPU上推理仅需5ms，但在手机NPU上可能需要200ms以上，且内存占用可能超过可用预算——此时必须通过量化、剪枝等手段将模型压缩到可运行范围。

2.2 端侧推理的硬件约束矩阵

端侧推理的硬件约束可以归纳为四个维度：算力、内存、功耗、I/O带宽。每个维度对模型压缩策略的影响各不相同，我们需要逐一分析。

2.2.1 算力约束（TOPS vs. MACs）

算力是端侧芯片执行乘加运算（MAC）的峰值能力，常用单位是TOPS（Tera Operations Per Second）或GOPS。不同芯片的算力差异巨大：

• MCU级（如STM32H7）：算力约0.01~0.1 TOPS，只能运行极轻量模型（如MobileNetV1 0.25x，约40M MACs）
• 手机NPU（如骁龙8 Gen 2）：算力约30~50 TOPS（INT8），可运行主流检测/分割模型
• 自动驾驶域控制器（如Orin）：算力约200+ TOPS，可运行多传感器融合模型

算力约束直接决定了模型的计算量上限。假设一个模型需要运行在30fps（每帧33ms），芯片有效算力利用率约60%，则单帧可用的MACs预算为：

可用MACs = 芯片TOPS × 1000 × 0.6 × 0.033秒
例如：手机NPU 30 TOPS → 30 × 1000 × 0.6 × 0.033 = 594 GMACs

这意味着在手机NPU上，单帧推理的MACs预算约为594G，而YOLOv8m需要约300G MACs（FP32），勉强可运行；但若考虑内存带宽和NPU利用率波动，实际需要压缩到200G以内才稳妥。

2.2.2 内存约束（容量与带宽）

内存约束包含两个层面：容量（能装下多大模型）和带宽（每秒能读取多少数据）。模型权重、激活值、中间特征图都需要占用内存。以MobileNetV3-Large为例：

• FP32权重：约21MB
• INT8量化后：约5.3MB
• 输入224×224×3的激活值：约150KB
• 中间特征图峰值：约2~5MB（取决于网络结构）

在IoT设备上，如果可用RAM只有512KB，那么即使INT8量化后的5.3MB权重也无法加载——此时必须采用更激进的压缩手段（如深度可分离卷积+低比特量化+权重共享），或者重新设计网络结构。

2.2.3 功耗约束（TDP与能效比）

功耗约束在IoT和手机场景尤为关键。手机NPU的峰值功耗约3~5W，但持续运行AI应用时，整机功耗需控制在2W以内（否则发热降频）；IoT设备（如智能门锁、传感器节点）的功耗预算可能只有50~200mW，且依赖电池供电。

功耗与算力并非线性关系。芯片在低负载时能效比较高，但接近峰值算力时功耗急剧上升。因此，模型压缩不仅要降低计算量，还要考虑计算密度——即让芯片在中等负载区间运行，避免触发降频保护。实际工程中，我们通常将目标算力利用率控制在40%~70%之间。

2.2.4 I/O与数据通路约束

端侧推理不仅是模型计算，还包括数据输入输出。摄像头数据通过CSI接口输入，传感器数据通过I2C/SPI读取，推理结果通过UART/以太网输出。这些I/O通道的带宽和延迟会影响端到端的推理延迟。

例如，在自动驾驶场景中，8路摄像头每路1080p@30fps，原始数据量约3.2Gbps，即使经过ISP处理后，也需要约800Mbps的带宽输入到域控制器。如果I/O带宽不足，即使模型算力充裕，也无法实时处理所有传感器数据——此时需要在传感器端做预处理（如ROI裁剪、降采样），或者在模型输入端做分辨率压缩。

2.3 典型应用场景深度拆解

不同场景对模型压缩的优先级和约束权重完全不同。我们选取三个最具代表性的场景进行拆解。

2.3.1 手机端：体积与实时性的平衡

手机端AI应用（如人脸解锁、实时翻译、拍照增强）的核心约束是：模型体积需控制在10~50MB以内（避免占用过多存储），单帧推理延迟需控制在10~50ms（保证流畅体验），功耗需控制在1~3W（避免发热）。

以某手机厂商的人像分割模型为例：

• 初始模型：DeepLabV3+（MobileNetV2 backbone），FP32权重约45MB，单帧推理在NPU上约80ms
• 压缩目标：体积≤15MB，延迟≤30ms，精度mIoU下降≤2%
• 压缩方案：INT8量化（体积降至11.5MB）+ 通道剪枝（计算量减少35%）+ 知识蒸馏（用大模型指导小模型训练）
• 最终效果：体积12.8MB，延迟28ms，mIoU下降1.7%

这个案例说明，手机端通常需要组合多种压缩技术，且精度损失预算非常有限（≤2%），因为用户对分割边缘质量敏感。

2.3.2 IoT设备：极致资源受限下的生存

IoT设备（如智能音箱、工业传感器、可穿戴设备）的约束更为严苛：内存可能只有256KB~1MB，算力只有0.01~0.1 TOPS，功耗预算50~200mW，且往往没有散热条件。此时，模型压缩的优先级是：内存占用 > 计算量 > 精度。

以关键词唤醒（KWS）模型为例：

• 硬件：Cortex-M4 @ 80MHz，512KB Flash，256KB RAM
• 模型：DS-CNN（深度可分离卷积），FP32权重约1.2MB，无法装入Flash
• 压缩方案：INT8量化（权重降至300KB）+ 权重剪枝（40%稀疏度）+ 权重共享（K-means聚类，进一步压缩至180KB）
• 最终效果：模型体积180KB，推理延迟45ms，精度98.2%（原98.7%）

IoT场景的另一个特点是：往往需要支持离线OTA更新，因此模型文件需要设计为可差分升级的格式，避免每次更新都传输完整模型。

2.3.3 自动驾驶：安全性与确定性的极致要求

自动驾驶是Edge AI中约束最复杂的场景：算力需求极高（多传感器融合）、安全等级要求ASIL-D、推理延迟必须确定性（不能有随机波动）、且需要满足功能安全认证。模型压缩在这里不仅是性能优化，更是安全工程的一部分。

以某L3级自动驾驶的3D目标检测模型为例：

• 硬件：NVIDIA Orin（254 TOPS INT8），32GB LPDDR5
• 模型：PointPillars + ResNet50 backbone，FP32权重约120MB
• 约束：单帧延迟≤50ms（确定性），精度mAP≥85%，需通过ISO 26262认证
• 压缩方案：INT8量化（需校准集验证）+ 层融合（Conv+BN+ReLU融合）+ 张量内存规划（减少碎片化）
• 关键差异：不能使用剪枝（因为稀疏计算在Orin上效率不稳定），不能使用蒸馏（因为训练成本过高且难以验证）

自动驾驶场景对压缩技术的选择有严格限制：任何可能引入不确定性的技术（如动态剪枝、条件计算）都被排除，量化也必须经过充分验证以确保数值稳定性。

2.4 常见误区与工程复盘

在Edge AI模型交付的实践中，我们总结出以下高频误区，这些误区往往导致项目延期或部署失败。

从工程复盘角度看，一个成功的Edge AI模型交付项目应遵循以下流程：

1. 硬件基线测试：在目标芯片上运行基准模型（如MobileNetV2），实测算力、内存、功耗基线
2. 约束量化：将场景需求（延迟、精度、功耗）转化为可量化的技术指标
3. 压缩方案选型：根据约束矩阵选择量化/剪枝/蒸馏的组合策略
4. 迭代验证：每轮压缩后都在目标芯片上实测，而非仅看PC端指标
5. 极端场景测试：验证低功耗模式、高温降频、内存碎片化等边界情况