3. 轻量化核心概念

在自动驾驶感知系统中，模型轻量化并不是单一技术，而是一组围绕“让模型更小、更快、更省资源”的工程手段。理解轻量化，首先要区分两个常被混用的概念：模型压缩与模型加速。模型压缩关注的是模型体积、参数量和存储占用，目标是把模型变小；模型加速关注的是推理过程中的计算效率、延迟和吞吐，目标是把模型跑得更快。两者相关但不完全等价：一个模型可以被压缩得很小，却因为算子不友好而在车端芯片上跑得很慢；也可以推理很快，但精度或内存占用并不理想。

一、四个核心度量：参数量、计算量、内存占用与延迟

参数量（Parameters）指模型中所有可学习权重和偏置的总数，通常以 M（百万）为单位。它直接影响模型文件的存储大小和加载时间。例如一个 20M 参数的 FP32 模型，仅权重就约 80MB；若量化为 INT8，则约 20MB。参数量大并不必然意味着计算量大，全连接层就是典型的高参数、低计算密度结构。

计算量通常用 FLOPs 或 MACs 衡量，表示完成一次前向推理所需的浮点运算次数或乘加次数。它更接近推理耗时的理论上限，尤其对卷积层、注意力层等计算密集型结构影响明显。自动驾驶感知模型输入分辨率高、特征图大，计算量往往比参数量更能决定延迟表现。

内存占用分为两类：权重内存和激活内存。权重内存由参数量和数值精度决定；激活内存由输入分辨率、特征图通道数和批大小决定。车端芯片的片上内存有限，激活内存过大时，即使权重很小，也会因频繁访问外部内存而拖慢推理。

延迟（Latency）指单帧从输入到输出的耗时，通常要求稳定在 30ms、50ms 或 100ms 以内，取决于感知任务的安全等级。吞吐（Throughput）指单位时间内可处理的帧数或样本数，常用 FPS 表示。延迟关注“一帧多快”，吞吐关注“一秒多少帧”。在多路摄像头、多任务并行的自动驾驶域控制器中，两者必须同时满足。

二、方法流程：从指标分析到部署验证

轻量化工程通常遵循“先度量、再压缩、后加速、最后验证”的流程。第一步是建立基线：在目标芯片上测量原始模型的参数量、FLOPs、峰值内存、平均延迟和 FPS。第二步是选择压缩手段，如剪枝、量化、知识蒸馏或低秩分解。第三步是算子级加速，包括算子融合、内存复用、张量重排和推理引擎图优化。第四步是在精度、延迟、内存三个维度上做回归验证，确保不触发安全阈值。

# 典型轻量化评估命令示例
python profile_model.py \
  --model bev_detector.onnx \
  --input-shape 1,3,640,640 \
  --device orin \
  --metrics params,flops,latency,fps,memory

# 输出示例
Params: 24.6 M
FLOPs: 118.3 G
Latency: 42.7 ms
FPS: 23.4
Peak Memory: 1.8 GB

三、案例场景：BEV 感知模型的权衡实践

以 BEV 感知模型为例，输入为 6 路摄像头图像，原始模型参数量 48M、FLOPs 320G、延迟 120ms，无法满足 50ms 的实时要求。工程上先做 INT8 量化，将权重和激活从 FP32 降到 INT8，参数量等效压缩 4 倍，延迟降至约 70ms；再对骨干网络进行结构化剪枝，去掉冗余通道，FLOPs 降至 180G，延迟进一步降到 48ms；最后通过算子融合和内存复用，把峰值内存从 3.2GB 压到 2.1GB。整个过程精度仅下降 0.6 mAP，满足业务要求。

四、常见误区与复盘

• 只看参数量，不看计算量。 参数量小不代表推理快，全连接层和注意力层的计算密度差异很大。
• 只看 FLOPs，不看硬件效率。 某些算子理论 FLOPs 低，但在车端芯片上因访存瓶颈反而更慢。
• 忽略激活内存。 高分辨率特征图会产生大量中间激活，常成为内存瓶颈而非权重。
• 把延迟和吞吐混为一谈。 批处理能提升吞吐，但可能增加单帧延迟，实时感知通常优先保延迟。
• 压缩后不做端到端回归。 离线指标正常，不代表在真实数据流和推理引擎中稳定。

总结来看，模型压缩与加速分别对应“变小”和“变快”两个目标，而参数量、计算量、内存占用、延迟与吞吐构成了轻量化工程的核心度量体系。真正有效的轻量化方案，必须从业务约束出发，明确哪个指标是硬门槛，再选择压缩与加速手段，并通过端到端实测验证精度与性能的平衡。