1. 课程导入
边缘AI交付是一个将算法模型从训练环境迁移到真实业务场景，并使其稳定、高效、可运维地持续运行的系统工程。对于基于算能（Sophon）系列芯片（如BM1684、BM1684X、BM1688等）的智能硬件，交付工作远不止“烧录一个镜像”或“拷贝几个文件”那么简单。它涉及模型格式转换与精度校准、推理引擎适配、容器化封装、硬件资源分配、系统配置固化以及运维文档沉淀等多个环节。任何一个环节的疏漏，都可能导致设备在现场出现性能不达标、运行不稳定甚至完全不可用的情况。本章作为整个课程的开篇，旨在帮助学习者建立算能边缘AI交付的全局视野，明确学习路径，并理解每个交付环节在整个生命周期中的位置与价值。
1.1 算能边缘AI交付的核心原理与整体流程
算能边缘AI交付的本质，是将训练好的深度学习模型（如YOLOv5、ResNet、Transformer等）通过一系列工具链转换，部署到算能TPU（Tensor Processing Unit）硬件上，并以服务的形式对外提供推理能力。与云端GPU服务器不同，边缘设备通常面临资源受限（内存小、存储小、无独立显卡）、环境复杂（高温、震动、断电）、网络不稳定等挑战。因此，交付流程必须围绕“适配”和“稳定”两个核心展开。
一个标准的交付流程包含以下七个关键环节：
- 模型分析与选型：评估算法模型的复杂度、算子类型、输入输出尺寸，判断是否适合在目标算能芯片上运行。例如，BM1684X支持FP32、FP16、INT8等多种精度，但某些自定义算子可能不被支持，需要替换或重写。
- 模型转换与优化：使用算能提供的
tpu-mlir工具链，将PyTorch、ONNX、Caffe等格式的模型转换为TPU可执行的bmodel格式。此过程包括算子映射、图优化、内存规划等。 - 量化与精度验证：为了提升推理速度，通常会将模型量化为INT8。量化需要准备具有代表性的校准数据集，并在量化后对比精度损失。若精度下降超过业务容忍阈值（如mAP下降超过2%），则需要调整量化策略或回退到FP16。
- 容器化封装：将推理程序、依赖库（如OpenCV、FFmpeg）、运行时环境（如Sophon Inference SDK）打包成Docker镜像。容器化可以屏蔽底层硬件差异，实现“一次构建，到处运行”。
- 系统配置与资源分配：在目标设备上配置Docker运行参数，包括TPU设备映射（
--device /dev/sgpu）、内存限制、CPU核数分配、日志驱动等。错误的配置可能导致TPU无法识别或性能骤降。 - 功能与压力测试：在交付前进行全面的测试，包括单路视频流推理测试、多路并发压力测试、7×24小时稳定性测试。测试指标包括FPS（每秒帧数）、端到端延迟、CPU/内存占用率、TPU利用率等。
- 运维文档与交付物整理：输出完整的交付文档，包括系统架构图、部署手册、配置参数说明、常见故障排查指南、模型版本记录等。这是保障后续运维和团队协作的关键。
1.2 判断交付质量的关键指标与验收方法
如何判断一次边缘AI交付是否成功？不能仅凭“能跑起来”就宣告完成。我们需要建立一套可量化的验收指标体系。下表列出了边缘AI交付中最核心的几类指标及其验收标准：
| 指标类别 | 具体指标 | 典型验收标准 | 测试方法 |
|---|---|---|---|
| 功能正确性 | 模型精度（mAP/Accuracy） | 与GPU基线相比，INT8量化后精度损失 ≤ 2% | 使用测试集进行离线推理比对 |
| 性能指标 | 单路推理FPS | ≥ 25 FPS（针对1080P视频流） | 使用官方SDK benchmark工具 |
| 性能指标 | 端到端延迟（p99） | ≤ 100ms（从图像输入到结果输出） | 打点统计，采集1000次以上 |
| 资源占用 | 内存占用 / TPU利用率 | 内存 ≤ 设备总内存的70%，TPU利用率 ≥ 50% | 监控 docker stats 和 bm-smi |
| 稳定性 | 长时间运行崩溃率 | 7×24小时连续运行，无崩溃或内存泄漏 | 持续压测并监控日志 |
| 可运维性 | 日志完整度 / 配置可回溯 | 关键操作均有日志，配置项有版本记录 | 人工检查文档与日志系统 |
在验收过程中，需要特别注意“性能指标”与“精度指标”的权衡。例如，为了追求更高的FPS，可能会将模型输入分辨率从1920×1080降到1280×720，这会直接影响小目标的检测精度。因此，验收标准必须在项目启动前与客户或业务方达成一致，避免交付后产生争议。
1.3 典型应用场景与交付案例拆解
算能边缘AI设备广泛应用于多个行业，不同场景对交付的要求侧重点不同。我们以两个典型场景为例进行拆解：
场景一：智慧园区安防（人脸识别+结构化分析）
- 背景与约束：某园区部署了50路摄像头，需要在园区机房部署一台算能边缘计算盒子（如SE5），实现实时人脸抓拍、陌生人告警和车辆结构化分析。机房环境无空调，设备工作温度可能达到60℃。
- 初始目标：单台设备支持16路1080P视频流并发分析，人脸抓拍准确率≥95%，告警延迟≤2秒。
- 关键操作：首先，将训练好的人脸检测模型（如SCRFD）和识别模型（如ArcFace）转换为INT8 bmodel。由于设备散热条件差，我们在容器配置中限制了CPU最大频率，并设置了TPU功耗模式为“低功耗”。同时，为了应对网络抖动，在容器内增加了断网缓存机制。
- 结果对比：初始版本在16路并发时，TPU利用率达到98%，但设备温度迅速上升到75℃并触发降频，导致FPS从30掉到18。经过调整，我们将模型输入分辨率从1080P降到720P，并开启TPU的“智能调度”模式，最终在保证精度损失<1%的情况下，稳定运行在25 FPS，温度控制在65℃以内。
- 复盘经验：边缘交付必须将“热设计”纳入考量。性能调优不能只看芯片理论算力，还要看设备的散热能力。后续项目中，我们会在交付前增加“高温环境压力测试”环节。
场景二：工业质检（缺陷检测）
- 背景与约束：某工厂生产线需要检测产品表面的划痕、脏污。检测节拍要求每件产品检测时间<500ms。产线现场有强电磁干扰，且设备需要7×24小时不间断运行。
- 初始现象：在实验室环境测试时，单张图片推理仅需80ms，但部署到产线后，偶尔出现推理结果超时（>1s）的情况。
- 分析判断：通过查看日志，发现超时发生在TPU进行内存拷贝时。进一步排查发现，由于现场电压不稳定，导致TPU工作频率波动。我们通过配置Docker的
--cpu-quota限制CPU占用，并为设备增加了工业级稳压电源模块，问题得以解决。 - 操作步骤：1. 在容器内增加TPU健康检查脚本，每5秒检测一次
bm-smi状态；2. 配置看门狗，当检测到TPU异常时自动重启容器；3. 优化预处理代码，将图像缩放操作从CPU迁移到TPU的VDEC模块。 - 结果：最终实现了平均检测时间120ms，故障率从0.5%降低到0.02%。
1.4 常见误区与学习路径建议
在边缘AI交付的实践中，工程师常常陷入以下误区，导致项目延期或交付质量低下：
- 误区一：重模型、轻工程。认为只要模型精度高，部署就水到渠成。实际上，模型转换时的算子兼容性、量化误差、内存对齐等问题，往往比训练模型更耗时。
- 误区二：忽略容器资源限制。直接在设备上
docker run而不设置--memory、--cpus等参数，导致多个容器互相争抢资源，系统整体性能下降。 - 误区三：文档与交付物脱节。代码写完了，但部署文档还是旧版本，配置参数没有注释，导致后续运维人员无法接手。
- 误区四：不做版本管理。模型文件、bmodel文件、Docker镜像、配置文件散落在各处，没有统一的版本号，出现问题后无法回溯。
为了帮助大家系统掌握这门课程，我们设计了以下学习路径建议：
- 基础夯实：先了解算能芯片的架构特点（如BM1684X的TPU核、VPU、VDEC模块），熟悉Linux操作系统和Docker基本命令。
- 工具链实操：重点学习
tpu-mlir的模型转换流程，掌握如何查看模型转换日志、如何定位算子不支持的问题。 - 容器与配置进阶：深入理解Docker的设备映射原理（cgroup、namespace），学习如何编写高效的Dockerfile，以及如何通过环境变量动态配置推理服务。
- 运维体系构建：学习如何搭建日志采集系统（如ELK）、监控系统（如Prometheus+Grafana），以及如何设计OTA升级方案。
- 综合实战：选择一个真实场景（如智慧社区、明厨亮灶），从零开始完成一个完整的交付项目，并输出全套文档。