2026 年小团队边缘 AI 部署清单
在边缘部署 AI 与部署云服务有本质区别。硬件受限，网络可能不稳定甚至不存在，出问题时无法简单地再起一个实例。而且系统往往要无人值守运行数月。
这份清单来自过去几年在 Jetson 设备、工业 PC 和边缘服务器上部署视觉 AI 系统的经验，涵盖那些在生产环境中真正会咬你一口、但在教程里几乎不出现的内容。
1. 硬件选型
购买前确定显存/统一内存需求。
Jetson 设备（Orin NX、AGX Orin、AGX Thor）的"统一内存"在 CPU 和 GPU 之间共享。如果你计划在视觉流水线旁边运行 7B 语言模型，要相应地预算内存。Jetson Orin NX 16GB 一旦加载了操作系统、视觉流水线和 LLM，余量就所剩无几了。
将计算能力与延迟需求对应起来。
在 Jetson Orin NX 上以 1080p 对 30B 参数模型进行实时推理（≤30ms/帧）根本不可行。在硬件发货到现场之前，用 trtexec 基准测试或 Ollama 速度测试验证你的模型需求。
2. 模型优化
始终导出为 ONNX 并验证导出结果。
在构建 TensorRT 引擎之前，在一组已知输入上比较 PyTorch 模型和 ONNX 导出的输出。数值差异 ≥ 1e-3 表明有导出问题。
使用适合精度预算的量化方式。
- FP16：几乎总是安全的，默认使用。
- INT8：需要校准。预留 4–8 小时收集校准数据并在测试集上验证精度。
- 动态量化（GGUF Q4_K_M 等）：对受限硬件上的 LLM，Q4 通常是速度和质量之间的最佳平衡点。
在目标设备上构建 TensorRT 引擎。
引擎是 GPU 架构特定的。在 RTX 3090 上构建的 TRT 引擎不能在 Jetson AGX Orin 上加载。
3. 热管理
这是生产环境中最多意外的部分。
Jetson 在持续负载下会降频。
所有 Jetson 设备都有热保护机制。SoC 温度超过阈值时，时钟频率自动降低。在实验室基准测试中跑 60 FPS 的模型，在没有充分散热的生产线上运行 20 分钟后可能只剩 35 FPS。
- 进行 30 分钟的持续推理测试并监控温度：
tegrastats | grep -o 'CPU@[0-9.]*C' - 对任何需要持续吞吐量的部署安装主动散热方案（风扇散热器）
- 明确设置 Jetson 电源模式：
nvpmodel -m 0（最高性能）
4. 系统可靠性
为重启而设计。
你的推理进程最终会崩溃——模型加载错误、CUDA OOM、来自摄像头 SDK 的损坏帧。使用 systemd 或 Docker 重启策略，让服务在没有人工干预的情况下自动恢复。
[Service]
ExecStart=/usr/bin/python3 /opt/inference/run.py
Restart=always
RestartSec=5
处理摄像头断连。
USB 摄像头会断连，GigE 摄像头会丢包。你的推理循环必须优雅地处理 None 帧和摄像头重连。在 camera.read() 返回 False 时崩溃的朴素实现会在凌晨 3 点叫醒你。
记录结构化遥测数据。
在生产环境中，你需要能回答"昨天 14:32 的推理延迟是多少？"将时间戳、推理时间、置信度分数和错误条件记录到文件中。
5. 部署前验证清单
- 推理进程开机自启（systemd/Docker 重启已确认）
- 30 分钟持续推理测试无降频完成
- 摄像头断连/重连已处理（测试期间拔插测试）
- 在代表生产场景的数据上验证了模型精度
- 遥测日志正在写入磁盘且可读
- 远程访问已确认（SSH、VPN 或远程桌面）
- 存储：所有模型安装后至少 20 GB 可用
- NTP 时间同步已启用
- 看门狗或健康检查端点正在运行
个人感受
这份清单上的内容不是边缘情况——它们是真正导致生产事故的东西。30 分钟热测试听起来很繁琐，但我曾经发出过两个在办公室运行正常、到客户现场因为机箱没有通风而严重降频的系统。
重启策略感觉是多余的，直到你的推理进程在午夜因为摄像头发送了一个格式错误的帧而崩溃。
边缘 AI 部署是工程，不只是机器学习。模型是容易的部分。
此清单来自 Jetson Orin NX、Jetson AGX Thor 和基于 RTX 3090 的边缘服务器的部署经验。部分内容是 Jetson 特定的；原则广泛适用。