# BEV 感知部署：从模型延迟到系统实时性

> 结合 BEVPoolv2 与 TensorRT 官方资料，分析 BEV 的计算和访存优化，以及 FPS、端到端延迟和量化评估的口径。

作者：[汤国放](https://tonwork.fun/#person)
发布日期：2025-02-21
更新日期：2026-10-08
原文：https://tonwork.fun/blog/%E9%BB%91%E7%AE%B1%E6%8F%AD%E7%A7%98-%E8%B7%91%E6%BB%A130fps%E7%9A%84%E9%87%8F%E4%BA%A7bev%E6%84%9F%E7%9F%A5%E7%B3%BB%E7%BB%9F/

---

BEV 感知能不能实时运行，不能只看显卡算力，也不能拿论文 FPS 和某辆车的相机刷新率直接比较。我更愿意先问：测的是模型、单个算子，还是从相机帧到感知结果的完整链路？输入和测量范围没对齐，“更小的车端芯片比 A100 快”这个结论就没有依据。

这次修订删去了原文没有对应测试记录的帧率和加速倍数，改用公开论文、代码及 NVIDIA 文档解释优化路径。本文没有量产车实测，也没有新跑 TensorRT 引擎；具体部署收益需要在目标平台测量。[TensorRT 性能工作流](https://docs.nvidia.com/deeplearning/tensorrt/latest/performance/best-practices.html)

## 先把性能口径写清楚

30 FPS 代表平均每 `1000 / 30 ≈ 33.3 ms` 交付一次结果，但不自动代表一帧的端到端延迟小于 33.3 ms。流水线可以提高吞吐，排队也可能让数据变旧；驾驶系统需要同时关注输出频率和输出所用输入的时间戳。

假设预处理、推理、后处理各用 12、25、8 ms，串行时总计 45 ms；理想流水线在资源不冲突时，可按瓶颈的约 25 ms 间隔输出。这里是解释概念的假设数字，真实系统的共享带宽、同步和调度开销会改变结果。

| 比较项 | 至少记录什么 |
| --- | --- |
| 模型与数据 | 代码版本、权重、相机路数、输入尺寸、BEV 网格和时序帧数 |
| 平台与软件 | 设备型号、功耗/频率模式、驱动、CUDA 与 TensorRT 版本 |
| 推理配置 | batch、数值精度、动态 shape、是否多流、是否包含主机与设备数据传输 |
| 测量区间 | 预处理、推理、后处理是否计入，预热与同步方式 |
| 稳定性 | 平均值、p95/p99、持续运行时长、丢帧和结果数据年龄 |
| 质量 | 同一验证集上的检测/地图指标，以及远距、小目标、遮挡等分组结果 |

NVIDIA 的 benchmark 文档同样强调时钟、功耗、温度、同步和数据传输的影响。仅标注 GPU 型号，仍不足以复现性能。[TensorRT 性能测量](https://docs.nvidia.com/deeplearning/tensorrt/latest/performance/best-practices.html)

## 一个值得看的案例：BEVPoolv2

[BEVPoolv2 论文](https://arxiv.org/abs/2211.17111) 从视角转换的工程实现入手，避免显式计算和保存体量很大的 frustum feature，减少中间计算与存储负担，并提供 TensorRT 部署示例。它很适合说明一个问题：瓶颈有时在内存访问和数据组织，不在模型参数量。

但 BEV pooling 算子的加速，不等于整条感知链路获得同样倍数的收益。如果它原先只占总耗时的一小部分，即使大幅提速，整体收益也有限。论文里算子延迟、PyTorch 模型 FPS 和部署 backend 的结果应分别阅读，不能取最大的倍数贴到“量产系统”上。

这类针对性优化，比泛泛地说“换个更轻的 backbone”更值得先研究。具体操作顺序是先用 profiler 找到耗时或访存热点，再判断能否改变中间张量、索引预计算和算子布局。

## 模型结构要改，但要知道改了什么

压缩 backbone、降低输入分辨率或减少时序帧数，都会改变计算预算，也可能改变远距感知和遮挡处理能力。深度可分离卷积能减少某些计算，但实际延迟还受内存访问和硬件 kernel 影响，不能统一承诺“快十倍”。

注意力也一样。密集自注意力的 token 交互随序列长度平方增长；窗口化或参考点采样可以缩小部分计算范围，但 BEV 编码器、查询自注意力和交叉注意力是不同模块。需要按实际实现分析，不能把“采用可变形注意力”当成整个模型都线性复杂度的证明。[BEVFormer 论文](https://arxiv.org/abs/2203.17270)

例如 [MapTR 查询解读](https://tonwork.fun/blog/transformermaptr-%E6%A0%B8%E5%BF%83%E6%80%9D%E6%83%B3%E4%B8%8E%E6%B5%81%E7%A8%8B%E6%80%BB%E7%BB%93/) 中，地图解码器的交叉注意力使用采样，自注意力仍在查询之间进行。减少实例数或点数可以改变开销，但也改变了地图表达容量，要与任务指标一起验证。

## TensorRT 的收益来自具体引擎

TensorRT 会选择计算实现，并在支持的模式下融合层、减少 kernel 启动或调整执行方式。收益取决于实际网络、shape 和目标设备，不能把每个优化项的理论倍数相乘。导出后也要检查不支持的算子、插件实现和 layout 转换，尤其是 BEV 视角转换这类特殊模块。[TensorRT 优化说明](https://docs.nvidia.com/deeplearning/tensorrt/latest/performance/best-practices.html)

低精度能降低存储和计算成本，但“FP32 改 INT8 就快 3–4 倍”不是通用结论。量化还涉及缩放、校准或 QAT，以及后端支持的执行路径；部分模块维持较高精度、格式转换或内存瓶颈，都可能影响收益。具体流程以所用 TensorRT 版本为准。[量化类型与工作流](https://docs.nvidia.com/deeplearning/tensorrt/latest/inference-library/work-with-quantized-types.html)

我会把导出正确性和性能优化分开验收：先比较原框架与引擎的输出误差和任务指标，再测延迟。量化数据要覆盖真实输入分布，同时保留独立验证集，不能只展示少量看起来正常的样例。

## 系统流水线也要测输入的新鲜度

实际链路可能包括采集、ISP、预处理、推理、后处理与融合。哪些步骤能并行，取决于平台能力和资源占用，不能把某一张 SoC 框图当成所有系统的固定分工。

异步执行能提高利用率，但 GPU 时间、CPU 提交时间和完整墙钟时间要区分；多路相机还要检查时间对齐和掉帧策略。队列越长未必越好，持续输出旧帧会把“帧率很高”变成误导。建议为每次输出保留输入时间戳、输出时间戳和版本信息，便于把延迟与质量问题追到同一帧。

如果目标是 30 Hz，可以把它作为结果交付频率的目标，再单独定义可接受的数据年龄、尾延迟和质量要求。具体阈值取决于车辆速度、感知用途和下游设计；网络 FPS 本身不能证明车辆闭环安全性。

BEV 优化最有价值的交付物，应是同一质量口径下、能复现的性能前后对比。想继续看训练配置和多传感器融合，见 [BEV 感知工程导读](https://tonwork.fun/topics/bev/)；系统选型部分可接着读 [智能驾驶硬件与算法适配](https://tonwork.fun/blog/%E9%80%A0%E8%BD%A6%E9%AA%A8%E6%9E%B6%E5%B8%88-%E6%88%91%E7%9A%84%E6%99%BA%E8%83%BD%E9%A9%BE%E9%A9%B6%E6%BC%94%E8%BF%9B%E5%BC%8F%E6%9E%B6%E6%9E%84%E5%93%B2%E5%AD%A6/)。