2. 边缘计算基础
在正式进入模型剪枝与部署技术之前，我们必须先建立对边缘计算硬件平台的系统性认知。边缘端部署大模型（或轻量化模型）与云端部署有着本质差异：云端拥有近乎无限的电力、散热和扩展能力，而边缘端必须在有限的功耗墙、内存带宽和物理尺寸内完成实时推理。本章将围绕三大主流硬件平台（NVIDIA Jetson、瑞芯微 RK3588、树莓派）展开，深入剖析其算力构成、内存层级和典型应用场景，为后续章节的剪枝策略选择提供硬件约束依据。
3.1 边缘端硬件平台的算力与内存架构
边缘端硬件平台的选择直接决定了模型剪枝的深度和量化策略。我们需要从三个维度评估硬件能力：峰值算力（TOPS或FLOPS）、内存带宽（GB/s）和可用内存容量（GB）。这三个指标共同构成了模型部署的"硬边界"。
3.1.1 NVIDIA Jetson：CUDA生态的王者
Jetson系列是边缘端部署深度学习模型的事实标准。以Jetson Orin NX 16GB为例，其GPU拥有1024个CUDA核心和32个Tensor Core，在INT8精度下可提供100 TOPS算力。但实际部署中，我们更关注可持续算力——在25W功耗模式下，Orin NX的GPU频率会从1.3GHz降至918MHz，实际吞吐量约为峰值的60%。这意味着一个在PC上运行仅需5ms的模型，在Jetson上可能需要8-10ms。
内存方面，Jetson采用LPDDR5统一内存架构，CPU和GPU共享同一物理内存。Orin NX的128-bit LPDDR5提供204.8 GB/s带宽，但实际可用带宽受限于内存控制器效率，通常只能达到理论值的70-80%。对于YOLOv8s这类模型（约11.2M参数，FP32权重约45MB），在INT8量化后权重降至11MB，但激活值（feature map）在1080p输入下可能占用200-400MB内存。因此，内存带宽往往比算力更早成为瓶颈。
3.1.2 瑞芯微RK3588：国产化替代的主力
RK3588是瑞芯微推出的旗舰级SoC，其NPU采用三核架构（两个Cortex-A76 CPU核内嵌NPU + 独立NPU），提供6 TOPS INT8算力。虽然算力低于Jetson，但其优势在于极低的单位算力成本和丰富的视频编解码能力。RK3588内置8K视频解码器，支持多路4K摄像头输入，非常适合智能安防场景。
RK3588的内存配置为LPDDR4x，带宽约68GB/s（64-bit总线）。其NPU对模型的支持依赖RKNN-Toolkit2工具链，该工具链支持PyTorch、ONNX、TensorFlow等主流框架的模型转换。但需要注意，RKNN对某些算子（如动态形状、自定义激活函数）支持有限，这要求我们在模型设计阶段就考虑NPU的算子兼容性。
3.1.3 树莓派5：原型验证与轻量级部署
树莓派5搭载Broadcom BCM2712 SoC，CPU为四核Cortex-A76（2.4GHz），GPU为VideoCore VII。它没有专用NPU，因此深度学习推理只能依赖CPU或GPU的OpenCL/GLES计算。在CPU上运行MobileNetV3-Small（INT8量化后约2.5MB）需要约30ms/帧，而运行YOLOv8n则需要120ms以上。树莓派的价值在于快速原型验证和教学演示，而非生产级部署。
| 硬件平台 | 峰值算力 | 内存带宽 | 典型功耗 | 工具链 | 部署难度 |
|---|---|---|---|---|---|
| Jetson Orin NX | 100 TOPS (INT8) | 204.8 GB/s | 10-40W | TensorRT | 中 |
| RK3588 | 6 TOPS (INT8) | 68 GB/s | 5-15W | RKNN-Toolkit2 | 中高 |
| 树莓派5 | 0.2 TFLOPS (FP32) | 17 GB/s | 5-12W | ONNX Runtime | 低 |
3.2 算力与内存限制的量化分析方法
在开始剪枝之前，我们必须对目标硬件进行基准测试，获取三个关键指标：单帧推理延迟、峰值内存占用和功耗曲线。这些数据将作为剪枝效果的对比基线。
3.2.1 算力利用率计算
算力利用率（Compute Utilization）是衡量模型与硬件匹配度的核心指标。计算公式为：
利用率 = (模型实际计算量 × 硬件频率) / (硬件峰值算力 × 运行时间)例如，在Jetson Orin NX上运行YOLOv8s（INT8），实测延迟为12ms，模型计算量为8.2 GMACs（即16.4 GFLOPs）。则实际算力为16.4 GFLOPs / 0.012s = 1.37 TFLOPS。Orin NX在25W模式下的INT8算力约为50 TOPS（即50 TFLOPS），利用率仅为2.7%。这说明模型受限于内存带宽或算子效率，而非算力不足。
3.2.2 内存占用剖析
模型部署时的内存占用分为三部分：权重内存（模型参数）、激活内存（中间特征图）和运行时开销（框架、CUDA上下文等）。以RK3588部署YOLOv5s为例：
- 权重：FP32约28MB，INT8量化后7MB
- 激活：输入640×640×3，第一层卷积输出320×320×32，单层激活约3.1MB；整个网络峰值激活约50MB
- 运行时：RKNN运行时约80MB，Linux系统约200MB
如果设备只有4GB内存，系统占用约1.5GB，剩余2.5GB可用。模型推理峰值占用约150MB，看似充裕，但若同时运行多路视频流（每路独立推理），内存将迅速耗尽。
3.3 典型应用场景的硬件约束分析
不同应用场景对延迟、功耗和精度的要求差异巨大，这决定了剪枝策略的优先级。我们以三个典型场景为例进行拆解。
3.3.1 智能安防：多路视频流与低功耗
智能安防场景通常需要同时处理4-16路1080p视频流，每路视频要求25FPS实时检测。以RK3588为例，其NPU在INT8下处理单路YOLOv5s（640×640输入）约需15ms，理论上可支持4路并行（60ms/帧）。但实际部署中，NPU的DMA传输和内存带宽会成为瓶颈，通常只能稳定运行2-3路。
剪枝策略建议：对于安防场景，优先采用通道剪枝减少计算量，同时保持输入分辨率不变。例如，将YOLOv5s的C3模块通道数从128剪至96，参数量减少约30%，推理速度提升40%，mAP仅下降1.2%。这种精度损失在安防场景中通常可接受（因为检测目标较大，如车辆、行人）。
3.3.2 工业视觉：高精度与确定性延迟
工业质检场景对精度要求极高（缺陷检测的漏检率需低于0.1%），且要求推理延迟的确定性（不能有抖动）。在Jetson Orin NX上部署缺陷检测模型时，我们通常采用结构化剪枝+INT8量化的组合策略。但需要注意，工业场景的输入图像分辨率往往较高（2048×2048），激活内存会急剧增加。
一个实际案例：某PCB缺陷检测项目，原始模型为ResNet-50（FP32），在Orin NX上推理延迟为28ms。通过以下优化流程，最终将延迟降至9ms：
- 使用TensorRT的自动通道剪枝（APEX）将ResNet-50的通道数减少40%，精度损失0.3%
- 将输入分辨率从2048降至1536（通过裁剪而非缩放，保留关键区域）
- 启用INT8量化，使用1000张校准图片进行KL散度校准
最终模型在保持99.2%准确率的前提下，实现了22ms的延迟，满足产线节拍要求。
3.3.3 自动驾驶：多传感器融合与安全冗余
自动驾驶场景对算力的需求最为苛刻。以Jetson AGX Orin（275 TOPS）为例，需要同时处理6路摄像头（1280×720@30FPS）、1路激光雷达点云和毫米波雷达数据。此时，模型剪枝不再是单一优化手段，而是需要与模型蒸馏和硬件协同设计结合。
在自动驾驶中，我们通常采用层级剪枝策略：对感知模型（如YOLOv8）进行通道剪枝，对融合模型（如PointPillars）进行稀疏化剪枝。但必须注意，自动驾驶模型的安全关键性要求剪枝后的模型必须通过形式化验证或大量场景测试，不能仅依赖mAP指标。
3.4 常见误区与硬件适配总结
在边缘端部署实践中，我们总结了以下高频误区，这些误区往往导致项目延期或性能不达标：
- 误区一：只关注算力，忽视内存带宽。许多模型在Jetson上算力利用率不足10%，原因就是内存带宽饱和。剪枝时不仅要减少计算量，还要减少内存访问量（如降低特征图通道数）。
- 误区二：盲目追求INT8量化。RK3588的NPU对INT8支持良好，但Jetson的TensorRT在INT8量化时可能产生精度损失。对于小模型（如MobileNetV3），FP16往往比INT8更合适。
- 误区三：忽略CPU与NPU的协同。在RK3588上，CPU负责图像预处理和后处理（NMS），NPU负责推理。如果CPU处理速度跟不上NPU，整体吞吐量会受限于CPU。
- 误区四：不进行功耗验证。Jetson在满载时功耗可达40W，如果散热设计不足，GPU会降频导致性能下降30%以上。剪枝后的模型应重新测试功耗曲线。