2. 边缘AI基础
在开始使用 Docker Compose 编排边缘 AI 推理服务之前，我们必须先建立对边缘 AI 的清晰认知。边缘 AI 并非简单地将模型部署到小设备上，而是涉及计算范式、网络拓扑、资源约束和业务逻辑的系统性重构。本章将围绕边缘计算的核心概念、典型推理场景、与云端 AI 的对比，以及硬件设备与软件架构四个维度展开，为后续容器化编排打下坚实的理论基础。
2.1 边缘计算的核心概念与演进逻辑
边缘计算（Edge Computing）并非一个全新的技术，而是对传统集中式云计算模型的一种补充与延伸。其核心思想是将计算、存储和网络资源从数据中心下沉到靠近数据源或用户的物理位置，即网络边缘。在物联网和人工智能爆发式增长的背景下，数据量呈指数级上升，如果所有数据都回传云端处理，将面临带宽瓶颈、高延迟和隐私风险三大难题。边缘计算通过"就近计算"策略，在数据产生端附近完成大部分实时处理，仅将必要的聚合结果或模型更新上传云端。
从演进逻辑来看，边缘计算经历了三个阶段：第一阶段是内容分发网络（CDN），主要缓存静态内容；第二阶段是边缘计算，开始承载应用逻辑和轻量级数据库；第三阶段是边缘智能，即当前我们正在经历的阶段，AI 模型被压缩、量化并部署到边缘设备上，实现实时的目标检测、语音识别和异常诊断。理解这一演进过程，有助于我们把握 Docker Compose 在边缘 AI 中的定位——它正是为了解决边缘节点上多组件（推理引擎、预处理模块、消息转发）的部署编排问题而存在的。
2.2 边缘AI推理的典型场景与业务价值
边缘 AI 推理场景具有鲜明的行业属性和技术共性。从技术维度看，边缘推理主要处理三类任务：图像与视频分析（如缺陷检测、人脸识别）、时序数据分析（如振动预测、能耗优化）和自然语言与音频处理（如语音指令、声纹识别）。从部署位置看，边缘 AI 可以运行在摄像头内部的 SoC 上，也可以运行在车间机柜的工业 PC 上，甚至可以运行在路侧机箱的嵌入式服务器中。
| 场景领域 | 典型应用 | 关键性能指标 | 边缘部署优势 |
|---|---|---|---|
| 智能制造 | 产品表面缺陷检测、设备预测性维护 | 检测精度 >99%，单张推理 <50ms | 产线数据不出厂，实时停机响应 |
| 智慧零售 | 客流统计、货架商品识别、自助结算 | 并发识别 >30路，误检率 <1% | 弱网环境下仍可运营，降低门店带宽成本 |
| 智能安防 | 安全帽佩戴检测、区域入侵报警 | 端到端延迟 <200ms，7x24小时稳定 | 视频流本地解析，只上传告警片段 |
| 车联网 | 车道线识别、障碍物检测、驾驶员监控 | 推理延迟 <30ms，功耗 <15W | 车载计算单元独立决策，不依赖基站 |
以智能制造中的设备预测性维护为例，边缘 AI 网关通过振动传感器以 20kHz 的采样率采集数据，在本地运行轻量级异常检测模型。当检测到频谱特征偏离基线时，边缘节点立即触发报警并上传 10 秒的原始波形片段到云端。这种模式下，每天产生的 1.7GB 原始数据中，只有约 5MB 的数据需要回传云端，带宽消耗降低了 99.7%，同时报警响应时间从云端的 5 秒缩短至边缘的 80 毫秒。
2.3 边缘AI与云端AI的深度对比
边缘 AI 与云端 AI 并非替代关系，而是互补关系。理解两者的差异，是设计 Docker Compose 部署策略的前提。下表从八个关键维度进行对比：
| 对比维度 | 云端 AI | 边缘 AI | 设计考量 |
|---|---|---|---|
| 推理延迟 | 50-500ms（含网络传输） | 5-50ms（本地计算） | 实时控制类场景必须边缘推理 |
| 网络依赖 | 强依赖，断网即服务中断 | 弱依赖，支持离线运行 | 边缘节点需具备本地缓存与重连机制 |
| 计算资源 | GPU集群，数十TOPS算力 | 边缘SoC，0.5-10 TOPS | 模型需量化、剪枝，选择轻量级架构 |
| 数据隐私 | 数据需上传，存在合规风险 | 数据本地处理，隐私性高 | 医疗、金融数据必须本地推理 |
| 部署运维 | 集中式，统一升级 | 分布式，需远程批量管理 | Docker Compose 可实现原子化升级 |
| 功耗限制 | 无严格限制 | 5W-50W 常见 | 需考虑 CPU/GPU 频率调节与模型大小 |
| 模型更新 | 随时更新，算力充裕 | 需 OTA 推送，且要保证兼容性 | 容器镜像版本管理至关重要 |
| 故障影响面 | 单点故障影响全局 | 单点故障仅影响局部 | 边缘节点需支持降级运行 |
2.4 典型边缘设备与硬件架构
边缘 AI 设备的形态多样，从几美元的 MCU 到几百美元的 GPU 边缘盒子不等。在 Docker Compose 编排场景中，我们主要关注能够运行 Linux 操作系统和容器引擎的设备。以下是四类典型的边缘设备及其架构特征：
- ARM 应用处理器（如 Raspberry Pi 4、RK3588）：集成 CPU+GPU+NPU，功耗 5-15W，适合轻量级视觉和语音应用。RK3588 内置 6 TOPS NPU，可运行 YOLOv5s 模型。
- x86 工业 PC（如 Intel NUC、研华工控机）：搭载 Intel Core 或 Atom 处理器，可选配 Intel Movidius VPU 或 Arc GPU，兼容性最好，适合复杂业务逻辑。
- NVIDIA Jetson 系列（如 Orin NX、Xavier NX）：专为 AI 推理设计，集成 Ampere GPU 和深度学习加速器，算力 10-100 TOPS，是边缘 AI 的标杆平台。
- FPGA 加速卡（如 Xilinx Kria）：可重构计算，延迟极低，适合需要确定性时延的工业控制场景，但开发门槛较高。
从软件架构角度看，边缘 AI 设备通常采用 Linux + Docker + 推理运行时 的三层结构。以 NVIDIA Jetson 平台为例，其软件栈包括 JetPack SDK（包含 L4T 内核、CUDA、cuDNN、TensorRT），Docker Engine 运行在 L4T 之上，而 AI 推理容器则基于 nvcr.io/nvidia/l4t-tensorrt:r8.5 镜像构建。这种分层架构使得 Docker Compose 能够将硬件相关的底层库（如 CUDA）与上层应用逻辑解耦，实现"一次构建，多处运行"。
背景与约束：某智慧园区需要在 8 个监控点位部署安全帽检测，每个点位接入 2 路 1080p 视频流。现场仅提供 220V 电源和有线网络，无 GPU 服务器。要求检测延迟 <150ms，误报率 <5%。
初始现象：最初尝试在 RK3588 上直接运行 Python + PyTorch 模型，CPU 占用率 100%，推理延迟 800ms，且频繁内存溢出。
分析过程：通过
htop 和 npu-smi 工具定位瓶颈，发现模型未使用 RK3588 的 NPU，且 PyTorch 框架本身占用大量内存。进一步分析，模型为 YOLOv5s（FP32），参数量 7.2M，计算量 16.8 GMACs。实际操作步骤：
- 将 YOLOv5s 转换为 ONNX 格式，再通过 RKNN-Toolkit2 量化为 INT8 模型，模型体积从 28MB 降至 7.5MB。
- 编写 Dockerfile，基于
rknn-toolkit-lite2运行时镜像，将推理脚本和 RKNN 模型打包。 - 使用 Docker Compose 定义两个服务：
camera-simulator（模拟 RTSP 流）和rknn-inference（推理服务），通过内部网络共享视频流。 - 设置
shm_size: 256mb和mem_limit: 1g限制容器资源。
风险与代价：INT8 量化导致 mAP 下降 1.2%，但通过增加检测置信度阈值（从 0.25 调至 0.35）有效控制了误报。整个优化过程耗时 2 人天，其中模型转换和调试占 80% 时间。
2.5 边缘AI架构设计原则与常见误区
在掌握了设备特性和场景需求后，我们需要总结边缘 AI 架构设计的核心原则。这些原则将直接影响后续章节中 Docker Compose 文件的编写方式。
原则一：以数据流为中心设计服务边界。边缘 AI 系统通常包含数据采集、预处理、推理、后处理、上传五个环节。每个环节应独立成容器，通过消息队列或共享内存通信。例如，摄像头采集服务与推理服务之间使用 Redis Stream 或 NanoMSG 解耦，避免因推理速度波动导致数据丢失。
原则二：资源隔离与弹性伸缩并重。边缘设备资源有限，Docker Compose 应通过 cpuset、mem_limit 和 pids_limit 严格限制容器资源。同时，对于多路视频分析场景，可以使用 docker compose up --scale inference=4 实现推理服务的水平扩展，但需注意 NPU 或 GPU 的共享限制。
原则三：模型与代码分离，支持热更新。将模型文件放在独立的数据卷中，通过挂载方式提供给推理容器。这样在模型更新时，只需替换数据卷中的模型文件并重启容器，无需重新构建镜像。结合 watchtower 或 renovate 可以实现半自动化的模型版本管理。
- 误区一：在边缘设备上使用 GPU 版本的 PyTorch/TensorFlow 镜像。这些镜像体积超过 5GB，且需要 CUDA 运行时，应改用 TensorRT、OpenVINO 或 ONNX Runtime 的轻量级镜像。
- 误区二：忽略容器时区与日志时区设置。边缘设备常跨时区部署，应在 docker-compose.yml 中设置
TZ=Asia/Shanghai环境变量，并配置日志轮转策略。 - 误区三：将边缘节点视为"小云端"，直接使用 Kubernetes。对于单机多容器的边缘场景，Docker Compose 的简单性和低开销远胜 K8s，且支持
docker compose watch实现开发热重载。 - 误区四：忽视网络模式选择。默认 bridge 网络会引入 NAT 开销，对于低延迟场景应使用
network_mode: host或配置 macvlan 网络。
总结复盘：边缘 AI 的本质是在资源受限、网络不稳、环境复杂的条件下，通过合理的软硬件协同设计，实现接近云端的智能水平。本章建立的设备认知、场景认知和架构认知，是后续使用 Docker Compose 进行服务编排的基础。在下一阶段的实战中，我们将基于 NVIDIA Jetson 平台，从零构建一个完整的边缘 AI 推理服务栈，届时会深入讲解 Docker Compose 文件的具体编写技巧、GPU 透传配置、模型热更新机制以及多容器日志聚合方案。请务必理解本章中关于资源约束和模型压缩的内容，它们是容器化编排成功的关键前提。