第二章 芯片架构基础：征程系列芯片的CPU、GPU、BPU等核心模块组成与工作原理
征程系列芯片作为面向智能驾驶与机器人场景的专用计算平台，其架构设计并非简单地将CPU、GPU、AI加速器堆叠在同一个SoC上，而是围绕“数据流驱动计算”这一核心理念进行系统级优化。理解征程芯片的架构，关键在于厘清CPU、GPU、BPU（贝叶斯处理器）以及各类硬件加速单元之间的职责边界、数据通路与协同机制。本章将从模块组成、工作原理、工程判断方法及实战案例四个维度，深入拆解征程系列芯片的底层架构逻辑。
上图展示了征程系列SoC的宏观架构视图。从工程视角看，该芯片并非将CPU、GPU、BPU简单并联，而是通过一个高带宽的NoC（片上网络）总线将它们与安全岛、硬件编解码单元及外部存储紧密耦合。其中，CPU簇负责逻辑控制与调度，GPU负责图形渲染与通用并行计算，而BPU则专门针对深度学习推理中的卷积、矩阵乘等算子进行极致优化。三者之间通过共享内存池（Shared Memory Pool）实现零拷贝数据交互，这是征程芯片实现低延迟推理的关键设计之一。
2.1 核心模块组成与职责边界
征程系列芯片（以征程5为典型参考）的模块划分遵循“功能安全岛+高性能计算簇+专用加速器”的三层设计哲学。这种划分并非随意为之，而是基于智能驾驶场景中“高算力需求”与“高功能安全等级”并存的矛盾而提出的工程解决方案。
2.1.1 CPU簇：逻辑控制与任务调度的中枢
CPU簇通常集成8个Arm Cortex-A78核心，并额外配备2个锁步（Lock-Step）核心用于功能安全监控。A78核心采用DynamIQ架构，支持异构多核配置，最高主频可达2.0GHz以上。在征程芯片中，CPU并非算力主力，而是扮演“指挥官”角色：它运行Linux或QNX操作系统，负责任务调度、通信协议栈、传感器数据预处理以及BPU/GPU的任务分发。
从工程实践角度，CPU簇的性能瓶颈往往不在峰值算力，而在缓存一致性（Cache Coherency）与中断响应延迟。征程芯片通过引入CCI/CMN互联总线，确保CPU、GPU、BPU在访问共享内存时数据一致，避免因缓存未命中导致的性能抖动。在开发中，我们通常将实时性要求高的任务（如车辆控制）绑定在锁步核上，将复杂逻辑任务（如路径规划）分配到A78大核上。
2.1.2 GPU：图形渲染与通用并行计算的补充
征程芯片集成的GPU为Arm Mali-G78系列，具备16个着色器核心，支持Vulkan、OpenGL ES 3.2等图形API。在智能驾驶场景中，GPU的主要职责包括：仪表盘/中控屏的图形渲染、环视影像的拼接与畸变校正、以及部分适合SIMT（单指令多线程）模式的并行算法（如某些光流计算）。
需要特别指出的是，GPU在征程芯片中并非用于运行深度学习模型——这是与桌面级GPU最大的区别。深度学习推理任务被严格限定在BPU上执行，原因在于GPU的能效比（TOPS/W）远低于BPU。例如，在运行ResNet-50时，BPU的能效比可达GPU的5-8倍。因此，在开发中应避免将卷积运算误派发到GPU，否则会显著增加功耗并降低帧率。
2.1.3 BPU（贝叶斯处理器）：AI推理的专用引擎
BPU是征程芯片最核心的差异化模块。其名称“贝叶斯”并非指采用贝叶斯定理进行推理，而是寓意芯片设计借鉴了贝叶斯推断中“先验-后验”的迭代思想，在硬件层面实现了对模型权重的高效压缩与动态稀疏化处理。BPU内部包含多个深度学习核（DL Core），每个核由脉动阵列（Systolic Array）、向量处理单元（VPU）和激活函数引擎组成。
BPU的工作原理可概括为“数据流驱动”计算模式：权重和特征图以流水的形式在脉动阵列中流动，避免了传统冯·诺依曼架构中频繁的取指-译码-执行操作。征程5的BPU支持INT8/INT16混合精度，并针对Transformer结构中的Softmax、LayerNorm等算子提供了硬件加速指令。在实际部署中，BPU的利用率（Utilization）是衡量模型优化程度的核心指标，通常应保持在70%以上。
2.2 核心模块协同工作原理与判断方法
理解各模块的独立功能只是第一步，真正的工程挑战在于如何让它们高效协同。征程芯片通过“异构计算框架”将CPU、GPU、BPU统一抽象为计算资源池，开发者通过工具链（如地平线OpenExplorer）将算法任务映射到不同计算单元上。
2.2.1 数据流与任务分配策略
一个典型的自动驾驶感知任务数据流如下：传感器数据（Camera/LiDAR）→ MIPI/PCIe接口 → 内存 → ISP预处理 → BPU推理 → CPU后处理 → 控制指令输出。在这个过程中，CPU负责配置ISP参数并启动DMA传输，BPU完成神经网络推理，GPU则并行处理可视化渲染。判断任务分配是否合理，可通过以下三个指标进行量化评估：
- 端到端延迟（Latency）：从传感器数据到达SoC到输出控制指令的总耗时，通常要求小于100ms。
- 模块利用率（Utilization）：CPU、GPU、BPU各自的忙碌时间占比，理想状态是三者均衡且无长时间空闲。
- 内存带宽占用（Bandwidth）：各模块对DDR带宽的争抢情况，若带宽占用超过80%，则需考虑数据压缩或零拷贝优化。
- 使用地平线提供的
hrt_tool工具采集BPU的busy_ratio和idle_ratio指标。 - 若
busy_ratio持续高于90%，且CPU侧等待事件（wait_event）频繁触发，则判定BPU为瓶颈。 - 此时应检查模型是否已开启
混合量化（如将敏感层保留INT16），或尝试调整BPU的batch size以提升数据复用率。 - 若
busy_ratio低于50%，则说明模型计算量未充分填充BPU流水线，应检查是否因内存分配碎片化导致数据搬运延迟。
2.2.2 判断BPU是否成为瓶颈的实操方法
在开发过程中，我们经常需要快速定位性能瓶颈。以下是一套基于征程芯片性能计数器的判断流程：
2.3 案例拆解：基于征程5的多传感器融合感知部署
为更直观地说明架构原理，我们以一个实际项目为例：在某L3级自动驾驶控制器中，需要同时处理8路800万像素摄像头数据，并运行一个包含目标检测（YOLOX）、语义分割（PIDNet）和可行驶区域预测的多任务模型。
2.3.1 初始现象与关键指标
系统初始设计将全部8路图像数据直接送入BPU推理，结果发现BPU利用率达到98%，但端到端延迟高达180ms，远超100ms的设计指标。通过hrt_tool采集数据发现：CPU的wait_event占比高达40%，说明CPU在等待BPU结果时大量空转；同时DDR带宽占用达到92%，接近饱和。
2.3.2 分析判断过程
进一步分析发现，问题根源并非BPU算力不足，而是数据搬运开销过大。8路图像以RAW格式直接写入DDR，每帧数据量约50MB，导致内存带宽被大量占用。此外，模型未进行稀疏化剪枝，权重矩阵中存在大量无效计算。
2.3.3 实际操作步骤与结果对比
| 优化步骤 | 具体操作 | 效果指标 |
|---|---|---|
| 1. 数据预处理下沉 | 将ISP输出的图像直接在MIPI接收端完成裁剪/缩放，仅将ROI区域写入DDR | DDR带宽占用从92%降至55% |
| 2. 模型稀疏化 | 使用OpenExplorer工具对YOLOX进行通道剪枝，稀疏度设为2:4 | BPU计算量减少35%，利用率降至85% |
| 3. 任务异构调度 | 将语义分割任务分配到GPU执行，BPU专注目标检测 | 端到端延迟降至95ms，满足设计要求 |
2.3.4 风险与复盘经验
该优化方案并非没有代价。将语义分割迁移至GPU后，GPU利用率从20%提升至75%，导致芯片整体功耗增加了4.5W。在散热受限的控制器中，这可能需要调整风扇策略或降低GPU主频。复盘经验总结为三点：第一，在征程平台上，内存带宽往往比算力更早成为瓶颈，应优先优化数据通路；第二，BPU的稀疏化支持是免费的算力提升手段，但需注意稀疏度设置过高可能引入精度损失；第三，异构调度需要结合具体模型的算子特性，不能一概而论。
2.4 常见误区与总结复盘
在征程芯片的开发实践中，工程师常陷入以下认知误区，需要特别警惕：
hbdk编译器查看算子映射报告，将不支持的算子回退到CPU执行。
libhrt加速库，或考虑将NMS逻辑迁移到GPU并行执行。
总结复盘：征程芯片的架构精髓在于“专芯专用”——CPU负责控制、GPU负责图形、BPU负责AI推理。在实际开发中，应遵循“数据流优先”的设计原则，先梳理清楚数据从传感器到执行器的完整路径，再根据各模块的算力特征进行任务映射。同时，务必建立性能基线测试体系，将BPU利用率、DDR带宽、端到端延迟作为核心监控指标，在每次模型或代码变更后及时回归验证。最后，善用工具链提供的性能分析报告（如hrt_report），它能够精确指出每个算子在BPU上的计算周期和内存访问次数，是定位瓶颈的“显微镜”。