3. 车载AI推理软件栈总览
在R-Car平台上部署一个车载AI功能，从来不是“装一个推理库”这么简单。摄像头数据要经过驱动、中间件、框架、运行时，最终才落到NPU或GPU上执行。理解这套软件栈的分层关系，是后续做性能调优、故障定位和跨平台移植的前提。本节以R-Car V4H/H3这类典型车载SoC为背景，梳理从硬件到应用的分层结构，并说明各层之间的接口与职责边界。
一、为什么必须分层理解
车载AI推理软件栈大致可以划分为五层：硬件层、BSP与操作系统层、通信与中间件层、AI框架层、推理运行时层。每一层向上提供抽象接口，向下依赖具体实现。分层的意义在于：当推理延迟超标时，你能快速判断问题出在运行时调度、框架算子实现，还是BSP里的驱动带宽；当需要把Android方案迁移到QNX时，你知道哪些层可以复用、哪些层必须重写。
一个常见的误区是把“AI框架”和“推理运行时”混为一谈。以TensorFlow Lite为例，它既是模型解析与算子调度的框架，又通过Delegate机制把实际计算委托给底层运行时。在R-Car上，这个Delegate可能指向NPU驱动，也可能回退到CPU。分清这两者，才能理解为什么同一个模型在不同Delegate下性能差异巨大。
二、各层职责与关键接口
硬件层包括CPU集群、GPU、NPU（R-Car V4H集成约13 TOPS的NPU）、ISP和内存子系统。这一层决定了算力上限和内存带宽，是推理性能的物理边界。
BSP与操作系统层是Renesas提供的R-Car BSP，包含启动加载、时钟与电源管理、显示与摄像头驱动、以及NPU/GPU的设备驱动。操作系统可选Linux（含Yocto）、Android或QNX。BSP向上暴露标准接口：Linux下是V4L2、DRM/KMS和DMA-BUF；QNX下则是相应的资源管理器。这一层的关键是零拷贝——摄像头数据通过DMA-BUF直接传给推理运行时，避免在用户态反复拷贝。
通信与中间件层负责把AI能力接入整车软件架构。ROS/ROS 2适合研发阶段快速验证，通过话题和服务传递图像与推理结果；Adaptive AUTOSAR则面向量产，用ARA::COM提供面向服务的通信，并支持功能安全与OTA。两者并非互斥，很多项目在开发期用ROS，量产时迁移到Adaptive AUTOSAR。
AI框架层负责模型加载、图优化和算子调度，常见的有TensorFlow Lite、ONNX Runtime、PyTorch（经TorchScript导出）。框架把模型转成内部表示，再通过Delegate或Execution Provider把子图交给运行时。
推理运行时层是真正驱动NPU/GPU执行的组件，例如Renesas的NPU运行时、OpenVINO或厂商提供的Delegate。它管理内存分配、任务队列和同步，直接决定吞吐与延迟。
三、一次推理请求的完整路径
以“前视摄像头目标检测”为例，走一遍数据流。摄像头通过MIPI CSI-2接入，ISP完成去马赛克和3A处理后，图像以NV12格式写入DMA-BUF。V4L2驱动把缓冲区句柄交给用户态。AI框架（假设是TFLite）拿到句柄后，若模型输入要求RGB，则需在GPU或专用硬件上做色彩空间转换，这一步若用CPU做会成为瓶颈。
接着，TFLite解释器遍历计算图，把卷积、激活等算子通过Delegate交给NPU运行时。运行时把算子编译成NPU指令序列，分配片上内存，启动任务。NPU完成计算后，输出张量写回DDR，框架执行NMS等后处理，最终结果通过ROS话题或ARA::COM服务发给规划控制模块。
这条路径上有三个关键观察点：一是DMA-BUF是否真正贯穿始终，若中间出现一次CPU拷贝，1080p@30fps下就会多出约180MB/s的带宽开销；二是Delegate的算子覆盖率，若覆盖率只有70%，剩余30%回退到CPU，整体延迟可能翻倍；三是NPU任务队列深度，队列过浅会导致NPU空闲等待，过深则增加端到端延迟。
四、跨操作系统的复用边界
Linux、Android、QNX三者的差异主要集中在BSP与操作系统层。Linux和Android共享内核驱动框架，Android额外有HAL和Binder；QNX则使用自己的微内核和资源管理器，驱动需要适配。往上的AI框架层和推理运行时层，只要运行时提供了对应OS的库，基本可以复用。中间件层差异最大：ROS在QNX上支持有限，Adaptive AUTOSAR则天然跨平台。
实际项目中，一个务实的做法是把AI推理封装成独立的服务进程，通过明确定义的接口（如共享内存+信号量）与中间件交互。这样即使从ROS迁移到Adaptive AUTOSAR，推理服务本身几乎不用改动，只需替换通信适配层。
五、分层视角下的调优思路
分层模型的价值在调优时体现得最明显。延迟超标时，按层排查：硬件层看NPU和DDR是否跑满；BSP层看驱动是否有拷贝或中断延迟；框架层看算子是否回退；运行时层看任务调度是否合理；中间件层看通信是否引入额外序列化开销。每一层都有对应的工具和指标，而不是笼统地“优化模型”。
例如，某项目在R-Car V4H上跑YOLOv5s，初始延迟45ms。逐层分析发现：Delegate覆盖率82%，回退算子集中在Resize和Sigmoid；DMA-BUF通路中有一处CPU拷贝用于归一化。把归一化移到GPU shader中执行，并把Resize替换为NPU支持的算子后，延迟降到28ms，NPU利用率从55%提升到78%。这个案例说明，分层理解能直接指导具体的优化动作。