📚 课程目录第2章 BM1684硬件基础

2、BM1684硬件基础：算力、内存、TPU架构、多核并行能力及对多模型调度的支持

BM1684是算能科技推出的第三代云端/边缘推理芯片，专为高密度AI推理场景设计。在多模型并行调度场景中，硬件资源的分时复用与空间隔离能力直接决定了调度策略的上限。本章从算力规格、内存子系统、TPU微架构、多核并行机制四个维度展开，并重点分析这些硬件特性对多模型调度（检测、分类、跟踪）的具体支撑方式与约束条件。

2.1 算力规格与精度支持

BM1684的峰值算力在不同精度下差异显著，这直接影响多模型调度时的算力分配策略。其INT8算力为17.6 TOPS，FP32算力为2.2 TFLOPS，FP16算力约为4.4 TFLOPS。在实际多模型场景中，检测模型（如YOLOv5s）通常以INT8量化后运行，而跟踪模型（如DeepSORT中的ReID网络）可能保留FP16精度以保证特征判别力。调度器需要根据模型实际使用的精度类型，动态计算算力占用率，而非简单按模型数量均分。

精度类型	峰值算力	典型模型	调度考量
INT8	17.6 TOPS	YOLOv5s、ResNet18	算力利用率最高，适合批量推理
FP16	4.4 TFLOPS	ReID网络、关键点检测	精度敏感型任务，算力占用翻倍
FP32	2.2 TFLOPS	调试用、精度验证	仅用于开发调试，不推荐生产

算力分配的核心原则是：以INT8等效算力为统一度量单位。例如，一个FP16模型占用算力相当于4个INT8模型。调度器在分配时间片时，需要将不同精度的模型折算为统一的算力消耗值，才能避免某个模型独占算力导致其他模型饥饿。

2.2 内存子系统与带宽约束

BM1684板载12GB LPDDR4x内存，理论带宽51.2GB/s。在多模型并行场景中，内存带宽往往比算力更早成为瓶颈。检测模型需要读取高分辨率图像（如1920×1080×3字节≈6MB），分类模型需要读取224×224×3≈150KB，而跟踪模型需要频繁读写特征图和历史轨迹数据。当三个模型同时运行时，内存带宽的竞争会导致有效带宽下降至理论值的60%-70%。

内存分配策略建议：

为每个模型预留独立的内存池，避免动态分配带来的碎片化
将输入图像缓存与模型权重分离，权重区只读，输入区可覆盖
跟踪模型的特征历史缓冲区使用环形队列，固定大小，避免内存增长
利用DMA引擎进行异步拷贝，减少CPU参与内存搬运

实际测试表明，当三个模型同时运行时，若不做内存规划，内存带宽利用率可达95%以上，导致模型推理时间增加40%-60%。通过合理的内存分区和DMA调度，可以将带宽利用率控制在80%以内，保证各模型推理延迟稳定。

2.3 TPU微架构与算子执行特性

BM1684的TPU采用脉动阵列（Systolic Array）架构，包含64个NPU核心，每个核心包含独立的乘加单元和激活函数单元。这种架构对卷积运算高度优化，但对非规则算子（如动态形状的RoI Align、NMS）支持较弱。在多模型调度中，需要根据算子类型决定模型在TPU还是ARM CPU上执行。

// 算子执行路径选择示例
if (op_type == CONV || op_type == GEMM) {
    // 送入TPU执行，利用脉动阵列
    tpu_execute(op);
} else if (op_type == NMS || op_type == SORT) {
    // 非规则算子，在ARM CPU上执行
    arm_execute(op);
} else {
    // 其他算子，根据负载动态判断
    if (tpu_load < 0.8) tpu_execute(op);
    else arm_execute(op);
}

TPU的批处理能力也是调度的重要参数。BM1684支持最大batch size为16的INT8推理，但batch越大，单次推理延迟越高。在多模型场景中，调度器需要权衡：是让检测模型以batch=4运行4次，还是以batch=16运行1次。前者延迟更低但吞吐略低，后者吞吐高但延迟波动大。对于实时跟踪场景，通常选择小batch以保证帧率稳定。

2.4 多核并行能力与任务映射

BM1684除了TPU外，还集成了8核ARM Cortex-A53 CPU和硬件视频编解码器。多模型调度时，需要将不同计算特征的任务映射到不同计算单元：

TPU：处理卷积、全连接等密集计算，适合检测和分类模型的主干网络
ARM CPU：处理NMS、目标跟踪的卡尔曼滤波、匈牙利匹配等逻辑运算
VPU（视频处理单元）：负责图像缩放、格式转换、JPEG编解码，可并行处理多路视频流
DMA引擎：负责内存拷贝和搬运，可异步执行，不占用计算核心

一个典型的并行调度方案是：检测模型的TPU推理与跟踪模型的CPU逻辑计算同时进行。当检测模型输出目标框后，CPU立即启动跟踪匹配，而TPU同时开始下一帧的检测推理。这种流水线设计可以将端到端延迟降低30%-40%。

2.5 多模型调度的硬件约束与优化案例

在某智慧交通场景中，需要同时运行车辆检测（YOLOv5s INT8）、车牌分类（ResNet18 INT8）和车辆跟踪（DeepSORT + ReID FP16）。初始方案将三个模型全部部署在TPU上，结果发现跟踪模型的FP16推理占用了大量算力，导致检测模型的帧率从25FPS降至12FPS。

优化过程：

分析瓶颈：通过性能分析工具发现，TPU算力利用率达92%，其中ReID网络占用55%
调整映射：将ReID网络改为FP16在ARM CPU上执行（利用NEON指令集），TPU只运行检测和分类模型
内存优化：将检测模型的输入图像缓存改为双缓冲，利用DMA预取下一帧
时间片调度：检测模型分配70% TPU时间片，分类模型分配30%，跟踪模型完全在CPU执行

优化后，检测帧率恢复至22FPS，分类准确率保持98.5%，跟踪ID切换率下降15%。代价是ARM CPU负载从40%升至75%，但仍在安全范围内。此案例说明，多模型调度不能只看算力总量，还要考虑算子类型、精度、内存访问模式等硬件特性。

常见误区提醒：

误区一：认为TOPS越高，多模型并行能力越强。实际上，内存带宽和算子多样性往往才是瓶颈
误区二：所有模型都量化到INT8。跟踪模型的特征图对精度敏感，过度量化会导致ID切换率上升
误区三：忽略CPU与TPU的负载均衡。当TPU空闲时，CPU可能已满载，反之亦然
误区四：静态分配资源，不根据实际负载动态调整。多模型场景的负载波动大，需要动态调度

总结而言，BM1684的硬件设计为多模型调度提供了充足的算力基础和灵活的异构计算单元，但有效利用这些资源需要深入理解TPU微架构特性、内存带宽约束以及不同计算单元的任务适配性。调度器的核心职责不是简单分配时间片，而是根据模型的计算特征、精度需求和实时性要求，在TPU、CPU、VPU和DMA之间做出最优的任务映射决策。