4. 硬件与软件栈概览
感知模型轻量化部署不是单纯的模型压缩问题，而是模型、推理框架与车载计算平台三者协同匹配的系统工程。同一份 ONNX 模型，在 GPU 上可能依赖 TensorRT 的 FP16/INT8 加速，在 NPU 上则要经过厂商专用编译器量化编译，在 FPGA 上又需要手工划分流水线。理解硬件与软件栈的分层关系，是后续部署优化的前提。
一、车载计算平台的四类算力单元
车载计算平台通常由 SoC 内的多种异构算力单元组成，常见类型包括 GPU、NPU、FPGA 与 ASIC，它们在通用性、能效比、开发难度上各有取舍。
- GPU：以大量并行流处理器为核心，适合卷积、矩阵乘等规则并行计算。优势是生态成熟、支持 FP32/FP16/INT8 多精度，TensorRT 可直接调用；缺点是功耗较高，车规级 GPU 常与 CPU 集成在 SoC 中。
- NPU：面向神经网络算子定制的加速器，典型代表有华为昇腾、地平线征程、黑芝麻华山等。能效比高，但算子支持受限于编译器，非标准算子往往需要回退到 CPU 或改写。
- FPGA：可编程逻辑阵列，适合低延迟、确定性时延的场景，如激光雷达点云预处理。开发周期长，需要 RTL 或 HLS 设计，量产成本较高。
- ASIC：为特定算法定制的专用芯片，能效比最高，但灵活性最差，一旦算法迭代可能面临硬件不匹配的风险。
实际车载平台往往是“CPU + GPU + NPU”的异构组合，例如 NVIDIA Orin 提供 GPU 与 DLA 双路径，地平线征程 5 以 BPU 为核心。部署时需根据算子类型把计算图切分到不同单元，这就是所谓的异构调度。
二、推理框架的定位与差异
推理框架位于模型与硬件之间，负责图优化、算子融合、精度校准与运行时调度。主流框架的定位差异明显：
| 框架 | 主要目标硬件 | 核心优化手段 | 典型部署格式 |
|---|---|---|---|
| TensorRT | NVIDIA GPU / DLA | 层融合、内核自动调优、FP16/INT8 校准 | .engine / .plan |
| OpenVINO | Intel CPU / iGPU / VPU | 图裁剪、异步推理、INT8 量化 | .xml + .bin |
| ONNX Runtime | 跨平台 CPU / GPU / NPU | 图优化、执行提供器切换 | .onnx |
ONNX Runtime 的价值在于“一次导出、多端运行”，它通过 Execution Provider 机制对接不同后端，适合作为中间验证层；TensorRT 与 OpenVINO 则更贴近具体硬件，能拿到更极致的性能，但可移植性较弱。工程上常见做法是：训练框架导出 ONNX，用 ONNX Runtime 做精度对齐，再分别编译为 TensorRT engine 或 OpenVINO IR 上车。
三、部署工具链的典型流程
从训练权重到车端可执行文件，通常要经过导出、优化、量化、编译、验证五个阶段。下面是一段典型的 TensorRT 编译命令：
trtexec --onnx=perception.onnx \
--saveEngine=perception_int8.engine \
--int8 \
--calib=calibration.cache \
--workspace=2048 \
--verbose其中 --int8 启用 INT8 量化，--calib 指定校准缓存，--workspace 控制显存工作区大小。编译完成后需用真实数据回放验证精度，不能只看推理速度。
四、案例：BEV 感知模型在 Orin 上的部署路径
假设有一个 BEV 检测模型，包含主干网络、BEV 变换与检测头。部署到 Orin 时可按以下路径推进：
- 训练框架导出 ONNX，固定输入尺寸与 opset 版本。
- 用 ONNX Runtime 在 CPU 上跑通，确认输出与训练一致。
- 用 TensorRT 解析 ONNX，检查不支持的算子并替换或插件化。
- 对主干网络做 INT8 校准，对 BEV 变换等敏感层保留 FP16。
- 生成 engine，在 Orin 上做端到端时延与精度回归。
该案例的关键在于混合精度策略：并非所有层都适合 INT8，BEV 变换涉及大量坐标运算，量化误差容易放大，通常保留 FP16 更稳妥。
五、常见误区与复盘
复盘时建议建立一张“模型—框架—硬件—精度—时延”的对照表，每次更换任一环节都重新回归。只有把硬件算力单元、推理框架与工具链当作一个整体来设计，轻量化部署才能稳定落地。