4. 感知算法性能优化：图像预处理加速、模型推理优化、后处理加速技巧

感知算法，说白了就是自动驾驶的「眼睛」和「大脑」。图像进来，你得先洗干净（预处理），再让模型看明白（推理），最后把结果整理好（后处理）。这三个环节，任何一个慢了，整个系统都得卡壳。我在项目中见过太多因为预处理没优化好，导致整个pipeline延迟飙升的案例。今天咱们就聊聊，怎么把这三大块给「榨干」。

4.1 图像预处理加速：别让CPU成为瓶颈

图像预处理，很多人觉得不就是resize、归一化嘛，能有多慢？嗯，你还真别小看它。一张1080p的图像，如果处理不当，光这一步就能吃掉5-10ms。你想想看，整个感知模块的预算可能才30ms，这就去了三分之一。

4.1.1 使用硬件加速单元

我个人习惯，能用硬件做的事，绝不用软件去磨。现在的嵌入式平台，比如NVIDIA的Orin、TI的TDA4，都内置了图像处理单元（ISP或PVA）。

• GPU加速：用CUDA的NPP库做resize和色彩空间转换。我实测过，比OpenCV的CPU版本快5-10倍。
• DMA直接传输：图像数据从相机到内存，别让CPU去搬数据。配置好DMA，让数据自己走。
• 硬件ISP：如果平台有独立的ISP，把白平衡、去马赛克这些活儿都扔给它。CPU只管拿结果。

4.1.2 算子融合与流水线

很多新手喜欢这样写代码：先resize，再转BGR，再归一化，再减均值。每一步都单独调用一个函数。这其实很浪费。

// ❌ 低效做法：多次kernel launch
cv::resize(src, tmp1, size);
cv::cvtColor(tmp1, tmp2, COLOR_RGB2BGR);
tmp2.convertTo(tmp3, CV_32F, 1/255.0);
tmp3 = tmp3 - mean;

// ✅ 高效做法：一次kernel搞定
// 自定义CUDA kernel，在resize的同时完成色彩转换和归一化
__global__ void preprocess_kernel(...) {
    // 读取原始像素
    // 双线性插值
    // RGB转BGR
    // 归一化
    // 减均值
}

我在项目中遇到过，把四个算子融合成一个CUDA kernel后，预处理时间从8ms降到了1.2ms。为什么？因为减少了显存读写和kernel launch的开销。

4.2 模型推理优化：把GPU喂饱

模型推理是整个感知的「心脏」。这块优化不好，前面预处理再快也没用。我见过有人用PyTorch直接推理，帧率只有个位数。换成TensorRT后，直接飙到30帧。差距就这么大。

4.2.1 模型量化与精度校准

FP32转FP16，几乎是零成本的加速手段。在Orin上，FP16比FP32快2倍左右。如果还想再快，可以试试INT8量化。

精度类型	速度提升	精度损失	适用场景
FP32	1x（基准）	无	训练、高精度验证
FP16	2x - 3x	几乎无	绝大多数部署场景
INT8	4x - 6x	0.5% - 2% mAP	对精度不敏感的任务

我曾经在量化一个YOLOv5模型时，INT8量化后mAP掉了1.2%。后来用了校准集（calibration dataset）重新做了一遍量化，精度损失降到了0.3%。嗯，这里要注意：校准集一定要覆盖实际场景，别拿训练集去校准，否则上线后遇到没见过的场景，精度会崩。

4.2.2 动态形状与批处理

自动驾驶场景下，输入图像的尺寸其实不是固定的。不同相机、不同分辨率，甚至同一个相机在不同模式下，尺寸都可能变。

• 动态batch：如果一次只处理一张图，GPU利用率可能只有30%。我建议把多张图拼成一个batch一起推理。但要注意，batch太大延迟也会增加，需要找到平衡点。
• 动态shape：TensorRT支持动态shape输入。但每次改变shape都会触发一次优化，有额外开销。我的做法是：固定几个常用尺寸（比如1280x720、1920x1080），提前建好多个engine，运行时根据输入尺寸切换。

4.2.3 算子选择与融合

不是所有算子都适合在GPU上跑。有些小算子，比如reshape、slice，在GPU上的开销反而比CPU大。因为kernel launch的延迟可能比计算本身还长。

我的经验是：

• 把小的、计算量低的算子合并到相邻的大算子中
• 用TensorRT的layer fusion功能，它会自动帮你做这件事
• 如果手动写插件，尽量把多个操作写在一个kernel里

4.3 后处理加速：别让NMS拖后腿

后处理往往是感知pipeline里最容易被忽视的瓶颈。模型推理只用了5ms，后处理却花了10ms，这种事我见得太多了。尤其是NMS（非极大值抑制），处理不好就是灾难。

4.3.1 高效NMS实现

传统的NMS是O(n²)的复杂度。当检测框数量超过1000个时，CPU上的NMS能跑到20ms以上。这显然不行。

// ❌ 低效：CPU上的串行NMS
std::vector<Box> cpu_nms(std::vector<Box> boxes, float iou_thresh) {
    // 排序、循环、删除... O(n²)
}

// ✅ 高效：GPU上的并行NMS
// 使用CUDA实现，每个线程处理一个框的IOU计算
// 然后用并行前缀和做筛选
__global__ void gpu_nms_kernel(...) {
    // 并行计算所有框对的IOU
    // 使用原子操作或共享内存加速
}

我建议：

• 如果检测框数量少（< 100），CPU NMS就够了
• 如果检测框多（> 500），一定要上GPU NMS
• 还可以用Fast NMS或Cluster NMS，它们牺牲一点点精度，换来大幅加速

4.3.2 解码与过滤的融合

模型输出的通常是偏移量（offset），需要解码成真实的坐标。这个解码过程，很多人是在CPU上做的。其实完全可以放到GPU上，和NMS合并成一个kernel。

我在项目中做过一个优化：把bbox解码、置信度过滤、NMS三个步骤写成一个CUDA kernel。这样数据不用来回在GPU和CPU之间搬运。优化后，后处理时间从12ms降到了2.5ms。

4.3.3 多任务后处理的并行化

现在的感知模型往往是多任务的：检测、分割、车道线识别一起出。每个任务的后处理逻辑不同，但可以并行执行。

• 用CUDA stream实现多任务后处理的并行
• 不同任务的后处理kernel可以同时运行，互不干扰
• 注意显存带宽的限制，别让多个kernel同时读写同一块显存

4.4 实战建议：从端到端的视角看优化

说了这么多，最后给几个实战中的建议：

1. 先profile，再优化：别凭感觉猜瓶颈。用NVIDIA Nsight或NVTX打一下时间戳，看看每个环节到底花了多少时间。
2. 关注pipeline的「最慢环节」：预处理、推理、后处理，哪个最慢就先优化哪个。别在已经很快的环节上浪费时间。
3. 善用异步操作：CPU和GPU可以同时工作。CPU在准备下一帧数据时，GPU在处理当前帧。用CUDA stream和异步拷贝实现流水线。
4. 留有余量：别把GPU利用率跑到99%。留10%-20%的余量，应对突发的高负载场景。

好了，这一章的内容就到这里。下一章咱们聊聊「多传感器融合中的时间同步与延迟补偿」，那又是一个很有意思的话题。