2、BM1684平台基础：芯片架构、算力特性与模型部署格式

BM1684是算能科技（Sophgo）推出的第三代云端/边缘推理芯片，广泛用于智能视频分析、AI边缘计算盒子、国产化服务器等场景。在OTA升级体系中，BM1684的模型部署格式（bmodel）、芯片资源边界和运行环境直接决定了模型包如何打包、如何校验、如何回滚。本章从芯片架构、算力特性、bmodel格式、开发环境四个维度展开，为后续模型包发布与版本追踪打下硬件与格式基础。

上图展示了BM1684从芯片核心到bmodel格式再到OTA升级链路的整体关系。芯片的TPU、ARM CPU、VPU和内存控制器构成硬件基础；bmodel是模型在芯片上运行的唯一静态格式；OTA升级则是在此之上实现版本管理、校验和回滚的工程体系。下面逐一展开。

2.1 BM1684芯片架构与算力特性

核心原理：异构SoC的职责划分

BM1684采用异构SoC设计，将不同计算单元集成在同一颗芯片上，各司其职。其关键模块包括：

• TPU（张量处理单元）：BM1684的算力核心，支持INT8和FP32两种精度。INT8算力标称可达17.6 TOPS，FP32算力约2.2 TFLOPS。TPU内部包含大量MAC阵列、累加器和片上SRAM，适合卷积、矩阵乘等密集型计算。
• ARM CPU集群：集成8核ARM Cortex-A53，主频1.5GHz左右。CPU负责预处理、后处理、控制逻辑、网络协议栈等非张量任务。在OTA升级中，CPU负责下载模型包、校验哈希、触发加载流程。
• VPU（视频处理单元）：支持H.264/H.265硬件编解码，最高支持32路1080P解码。对于视频分析类模型，VPU负责将视频流解码为帧数据，再送入TPU推理。
• 内存控制器：支持DDR4，典型配置为4GB或8GB。内存带宽约25.6GB/s，是TPU与CPU共享的数据交换枢纽。模型权重、中间特征图、输入输出缓冲区均驻留于此。

理解异构架构的意义在于：OTA升级时，不仅要考虑模型本身的兼容性，还要考虑CPU侧驱动、VPU固件、内存布局的变化。例如，新版本模型若使用了更大的输入分辨率，可能导致内存带宽成为瓶颈，即使TPU算力足够。

算力特性与模型部署的约束

在OTA模型包发布前，必须确认目标模型的算力需求是否在芯片能力范围内。例如，一个输入为608×608的YOLOv5s模型，INT8量化后单帧推理时间约5-8ms；若升级为YOLOv7模型，参数量增大，推理时间可能翻倍，需要重新评估帧率要求。

2.2 bmodel模型部署格式详解

核心原理：bmodel是静态编译产物

bmodel是BM1684平台专用的模型格式，由TPU-MLIR编译器将训练好的模型（如ONNX、Caffe、TFLite）编译生成。bmodel内部包含：

• 模型结构描述：网络层顺序、算子类型、输入输出张量形状。
• 权重数据：经过量化或格式转换后的权重，以INT8或FP32存储。
• 运行时参数：如TPU核心分配、内存地址偏移、DMA传输配置。
• 子网划分：一个bmodel可包含多个子网（subnet），每个子网对应一个独立的推理入口。例如，一个检测模型和一个分类模型可以封装在同一个bmodel中，通过不同的输入ID调用。

bmodel的静态特性意味着：模型一旦编译生成，其网络结构、算子实现、内存布局均已固定。OTA升级时，不能像Python脚本那样动态修改网络层，必须整体替换bmodel文件。

bmodel的版本标识与兼容性

每个bmodel文件头部包含一个magic number和版本信息字段。使用bmrt工具可以查看模型详情：

# 查看bmodel基本信息
bmrt --info model.bmodel

# 输出示例
[BM1684] model: yolov5s_int8.bmodel
  subnet: 1
  input: images [1,3,640,640] float32
  output: output [1,25200,85] float32
  dynamic: false
  chip: BM1684
  version: 1.0.0

在OTA升级中，版本追踪的关键是记录bmodel的编译时间、TPU-MLIR版本、量化校准数据集版本。这些信息建议写入模型包的元数据文件（如JSON），随OTA包一起下发。

2.3 常见开发环境与工具链

核心原理：交叉编译与运行时分离

BM1684的开发环境分为宿主机（x86服务器）和目标机（BM1684设备）。宿主机上安装TPU-MLIR编译器、交叉编译工具链；目标机上运行bmrt运行时、bm-smi监控工具。OTA升级涉及的是目标机侧的运行时环境，但模型包的构建在宿主机完成。

典型开发环境组成：

• 宿主机：Ubuntu 18.04/20.04，安装TPU-MLIR（版本≥1.2），Python 3.6+，ONNX等模型转换依赖。
• 目标机：Linux内核（如4.9或5.4），安装bmnnsdk2（包含bmrt、bmcv、bmvideo等库），驱动版本需与芯片匹配。
• 通信方式：SSH、串口、网口。OTA升级通常通过网口下发模型包，使用SCP或HTTP接口。

模型转换与量化流程

从训练模型到bmodel的标准流程如下：

1. 将PyTorch/TensorFlow模型导出为ONNX格式。
2. 使用TPU-MLIR的model_transform.py将ONNX转换为MLIR中间表示。
3. 使用model_deploy.py进行量化（INT8）或直接编译FP32模型。
4. 生成bmodel文件，并用bmrt验证模型可加载。

# 示例：ONNX转INT8 bmodel
model_transform.py --model_name yolov5s \
  --model_path yolov5s.onnx \
  --input_shapes [[1,3,640,640]] \
  --output_dir ./tmp

model_deploy.py --model_name yolov5s \
  --mlir yolov5s.mlir \
  --quantize INT8 \
  --calibration_table yolov5s_calib_table \
  --chip bm1684 \
  --output yolov5s_int8.bmodel

量化校准表（calibration table）是INT8量化的关键输入，它由校准数据集（通常500-1000张代表性图片）统计各层激活值范围生成。OTA升级时，如果模型量化版本更新，必须同步更新校准表版本记录，否则无法复现精度。

案例拆解：一个检测模型的OTA升级准备

假设某安防场景使用BM1684设备运行YOLOv5s检测模型，现需升级为YOLOv7-tiny模型，同时保持输入分辨率640×640不变。以下是具体操作过程：

背景与约束：设备部署在户外，网络带宽有限（约2Mbps），设备存储空间剩余500MB，要求升级后单帧推理时间不超过10ms，检测精度mAP@0.5不低于原模型的0.85。

初始现象：原模型在BM1684上INT8推理耗时6ms，mAP为0.87。新模型YOLOv7-tiny在GPU上精度更高（mAP 0.90），但未在BM1684上验证。

操作步骤：

1. 在宿主机上导出YOLOv7-tiny的ONNX模型，输入形状设为[1,3,640,640]。
2. 准备校准数据集（从原训练集中随机抽取800张），生成校准表。
3. 使用TPU-MLIR编译INT8 bmodel，得到文件大小约12MB（原模型8MB）。
4. 在开发板上运行bmrt测试，实测推理耗时8.5ms，内存占用增加80MB，满足约束。
5. 用100张测试图片对比新旧模型输出，确认检测框位置和类别一致，mAP为0.88。
6. 将新bmodel打包为OTA升级包，附带版本号、编译日期、校准表哈希。

结果与复盘：升级后设备运行稳定，推理耗时8.5ms满足要求。但发现模型文件增大导致下载时间从10秒增至15秒，后续优化方向是使用模型裁剪或更激进的量化策略。复盘经验：OTA升级前必须在目标硬件上做完整benchmark，不能仅依赖GPU上的精度数据。

2.4 常见误区与总结复盘

误区一：忽略驱动与运行时版本匹配

BM1684的bmodel与驱动、bmrt运行时存在版本耦合。例如，使用TPU-MLIR 1.4编译的bmodel，在旧版bmnnsdk2（如2.7.0）上可能无法加载。OTA升级时，如果只更新模型包而不更新驱动，可能导致加载失败或推理异常。

误区二：只验证精度不验证性能

模型精度高不代表在BM1684上运行快。INT8量化可能引入精度损失，但更常见的问题是内存带宽不足导致推理变慢。例如，一个模型输入从640×640改为1280×1280，计算量增加4倍，但内存访问量增加可能超过4倍，导致实际耗时增加6倍。

误区三：忽略多子网模型的OTA原子性

一个bmodel包含多个子网时，OTA升级必须保证所有子网同时更新。如果只更新了部分子网，可能导致子网间接口不匹配。例如，检测子网输出特征图格式变化，而分类子网仍按旧格式解析，就会产生错误。

总结复盘