做自动驾驶泊车、工业质检、园区巡检这类 Physical AI 项目时很多人一开始都习惯把视频流传回云端让服务器跑模型再把结果返回设备端。这个架构在 demo 阶段确实没毛病但一上线就会发现两个要命的问题延迟不可控断网就停摆。我做过的几个实际落地项目都栽过同样的跟头——云端的 RTX 4090 推理只要 10 毫秒加上网络传输、排队、编解码端到端能飙到 300 毫秒以上这在实时控制场景里基本就是灾难。后来被逼着把视觉模型从云端推到边缘整个人工智能系统才真正“活”过来。这篇文章我打算把边缘部署这条路完整拆开讲。内容会覆盖为什么 Physical AI 必须依赖边缘计算、小参数视觉模型怎么选怎么压、在 Jetson 这类边缘设备上如何跑通一个检测模型以及延迟优化和断网容错的具体手段。全程以实战为主相关命令、代码、参数、踩坑记录都会写出来适合正在做边缘 AI 部署或者设备端视觉应用刚起步的工程师参考。1. Physical AI 为什么绕不开边缘部署1.1 云端的两个硬伤延迟不可控、断网就停摆先说延迟。很多人以为延迟主要出在模型推理上其实真实项目里推理只是很小的一部分。我实测过一个园区人脸识别系统云端单帧识别确实快但完整链路是这样的设备采集图像 → 编码上传 → 公网传输 → 服务端解码 → 推理 → 结果回传 → 设备执行。这一步一步走下来最理想的情况下也要 150 到 300 毫秒网络一波动直接上秒。在物理 AI 场景里比如 AGV 小车要避障、机械臂要抓取、无人机要悬停这个响应速度根本没法用。小车以 1m/s 行驶300 毫秒延迟意味着它已经走出去了 30 厘米足够撞上障碍物。再说断网。工业车间、矿区、户外巡检这些物理世界的工作场景网络不是说断才断而是经常断或者信号弱到你根本没法稳定传数据。更麻烦的是网络断开时整个系统并不会“暂停”设备还在动、摄像头还在拍。如果所有推理逻辑都在云端断网那一刻设备就变成了瞎子。这个不只是业务中断的问题还可能造成安全事故。我自己做过一个露天矿卡的项目现场网络用 4G 基站设备一进到矿坑深处就丢包严重云端方案被迫全面返工。血的教训。1.2 边缘侧到底要扛住多少算力压力所以问题就变成把模型推到边缘边缘设备要扛得住多少算力这个得实事求是地算一笔账。Physical AI 的典型视觉任务比如目标检测、人脸识别、语义分割大部分老模型在边缘设备上跑起来是有压力的但现在的轻量级模型其实已经能把体积和算力需求压到很小。我以最常用的 YOLOv5s 为例参数量大概 7.2MFP32 权重差不多 28MB单帧推理在 Jetson Nano 上用 TensorRT 加速可以做到 30 到 50 毫秒在 Jetson Orin NX 上可以跑到 10 毫秒以内。这个性能对于大部分安防、工业、物流场景已经够用了。如果是更轻量的 MobileNetV3-SSD 或 NanoDet计算量还能再降一个量级在几十毫瓦级别的 MCU 上都能跑起来。换句话说边缘设备不需要追上云端的绝对算力它只需要在“够用”的前提下把延迟压下来。关键是要对模型的计算量和设备算力有准确认知。这里有个经验值边缘设备上做实时视觉推理单帧处理时间建议控制在 50 毫秒以内20FPS如果是闭环控制类场景最好做到 30 毫秒以内。达不到这个标准就要考虑换更小的模型或者把分辨率降下来。别一上来就想着跑 YOLOv7、YOLOv8x边缘侧跑不动就是跑不动工程上要讲匹配。1.3 端云协同不是“二选一”而是“各干各的活”把模型推到边缘不代表云端就没用了。我现在的做法是“边缘优先云端兜底”边缘设备负责实时推理、即时响应、控制决策云端负责模型训练、数据汇聚、复杂场景的二次分析和大规模调度。这样分工两边都能发挥长处。边缘端响应快、能离线运行云端算力强、存储大、可以做全局优化。举一个实际架构例子。一个完整的智慧园区系统每个摄像头终端跑一个轻量人脸检测和特征提取模型本地完成抓拍和提特征再把特征值和少量关键帧上报云端云端只做跨摄像头的人脸检索、轨迹生成和告警联动。这种设计下即使某个摄像头断网本地依然能完成陌生人的识别和本地告警网络恢复后再补传数据。延迟只发生在本地设备到中心系统这一段通常是毫秒级。我在很多项目里都会画一张部署拓扑图来和团队对齐核心就是三层设备边缘层推理、区域汇聚层缓冲、去重、预处理、云端中心层训练、分析、管理。这种架构在物理 AI 场景里特别重要因为物理世界的系统不像互联网应用它要求确定性要求故障时可降级这些云端方案天生给不了。2. 模型选型与轻量化边缘部署的第一步棋2.1 小参数视觉模型的现实选择模型能不能推到边缘第一步就看参数规模和计算量。前面提到小参数视觉模型是热门方向这里展开说一下怎么选。常见的小参数视觉模型我列在下面模型参数量输入分辨率边缘端推理耗时Jetson Orin NX适合任务MobileNetV3-SSD约5.8M320×320约10-15ms轻量目标检测YOLOv5s约7.2M640×640约10ms通用目标检测NanoDet-Plus约4.7M320×320约8-10ms端侧实时检测PP-PicoDet约3.3M320×320约7-9ms轻量检测ArcFace-MobileFaceNet约1.2M112×112约2-4ms人脸识别选型原则我自己总结成三点。第一优先选有 TensorRT/ONNX 生态支持的模型否则后面转换会踩很多坑。第二除非精度实在不够否则别选超过 20M 参数的模型边缘设备的算力和内存都有限。第三如果对精度有硬性要求可以考虑“云边双模型”边缘用小模型做粗筛云端用大模型做精检两边结合效果和成本都能平衡。这个思路在我做人脸识别项目时特别管用——边缘端用 MobileFaceNet 快速判断“是不是人”云端用 ArcFace 大模型做细粒度身份比对效果比单用一个大模型好很多成本还低。2.2 量化FP32→FP16→INT8到底怎么选模型选好了接下来是压体积、提速度。量化是最常用也是最有效的手段。原理不复杂把模型权重从 FP324字节压到 FP162字节或者 INT81字节模型体积直接减半甚至减到四分之一推理速度也能明显提升。但代价是数值精度下降可能影响模型输出精度。我的建议是分三步走。第一步先上 FP16。对于绝大多数视觉模型FP16 在边缘设备上的精度损失几乎可以忽略但速度提升明显。Jetson 平台上的 TensorRT 对 FP16 优化得很好几乎是无痛转换。第二步如果 FP16 性能还不够再尝试 INT8。INT8 需要准备校准数据集TensorRT 会根据校准数据计算每个激活层的动态范围从而把浮点运算替换成整型运算。校准数据集最好涵盖真实场景的典型图像我通常从训练集和实际采集数据里各抽一部分凑 500 到 1000 张图效果比较稳定。第三步INT8 后如果发现精度掉得太多有两条路一是换成量化感知训练QAT在训练阶段就模拟量化过程让模型权重提前适应低精度二是把关键层保留为 FP16只对部分层做 INT8TensorRT 支持这种混合精度配置。量化这里有一个不少新手容易忽略的点校准图片的数量和质量比模型本身更影响最终精度。我见过有人拿 50 张图去校准结果 INT8 模型在夜间场景几乎完全失效换成 1000 张覆盖白天、夜晚、逆光、雨雾的图后精度马上就恢复正常了。数据集要覆盖模型部署后的真实环境这是量化成功的关键“为什么”——因为校准其实是在估计实际输入的分布分布估计得越准量化误差越小。2.3 TensorRT从“能跑”到“跑得快”模型量化做完以后还有一个重型武器是 TensorRT。TensorRT 是英伟达的推理优化引擎它通过层融合、内核自动调优、精度校准、内存复用等手段把模型的计算图优化到接近硬件极限。同一个模型PyTorch 原生态在 Jetson 上跑 100 毫秒用 TensorRT 之后可能只需要 20 毫秒这个差距在实时场景里是决定性的。TensorRT 的使用流程大概是先把训练好的 PyTorch 模型导出为 ONNX 格式再用 TensorRT 的 trtexec 工具或者 Python API 把 ONNX 转换成 TensorRT 引擎文件.engine。这个引擎文件是跟具体硬件和 TensorRT 版本绑定的换一台设备或者升级了 JetPack引擎文件必须重新构建。这一点特别容易踩坑我刚开始做的时候把一台设备的 .engine 文件直接拷到另一台设备上结果加载失败浪费了半天时间排查。构建引擎时有两个重要参数一个是精度模式FP32、FP16、INT8一个是 workspace 大小。workspace 决定了 TensorRT 在构建时可以使用的显存上限太小会影响算子的融合效果太大可能在一张卡上构建时合法、部署到显存更小的设备上却 OOM。我建议按目标设备的最大可用显存来设比如 Orin NX 16GB可以用 8GB 作为 workspace 上限。最后构建引擎的时间也可以优化使用 trtexec 生成引擎时加上 --saveEngine 参数把引擎文件提前构建好部署现场直接加载不需要在设备上临时编译。3. Jetson 平台实战把检测模型推上边缘设备3.1 硬件选型Jetson Nano 到 AGX Orin 怎么挑估计不少读者看到这里准备动手了。在写具体步骤之前我先说清楚 Jetson 平台的硬件选型逻辑。英伟达 Jetson 家族目前主流的就是 Nano、TX2、Xavier NX、Orin NX、AGX Orin 这几档每档的算力、功耗和价格差别很大。我自己常用的搭配是原型验证用 Jetson Nano 或 Orin Nano5W 到 15W 功耗被动散热即可工业部署用 Jetson Orin NX10W 到 25W性能接近桌面级 RTX 2060。如果是多路视频或者跑大一点的检测模型AGX Orin 64GB 版本是目前边缘设备里的天花板性能接近 RTX 3060但功耗也到了 40W 往上很多场合需要主动散热。选硬件不要只看算力还要看内存带宽。视觉模型的推理速度很多时候卡在内存带宽而不是算力。比如 Jetson Nano 的内存带宽只有 25.6GB/s而 AGX Orin 有 204GB/s两者差了 8 倍跑同一个大模型时性能差距非常悬殊。所以如果你的项目要跑比较大的模型尽量选 Orin 系列内存带宽对推理性能的影响比核心数量更大。3.2 环境搭建与依赖安装我以 Jetson Orin NX 16GB JetPack 5.1.2 为例写环境搭建过程。JetPack 是英伟达给 Jetson 提供的全套开发套件里面打包了 Linux 系统、CUDA、cuDNN、TensorRT 等刷机之后基本就是开箱即用。先确认 JetPack 版本和 CUDA 版本这是因为很多坑都是版本不匹配导致的。# 查看 JetPack 版本 cat /etc/nv_tegra_release # 查看 CUDA 版本 nvcc --version # 查看 TensorRT 版本 dpkg -l | grep TensorRT我遇到最多的环境问题就是 PyTorch 装不上。Jetson 是 ARM 架构pip install torch 基本装不上官方版本必须使用英伟达提供的 Jetson 专用 PyTorch wheel 包。这个在英伟达官网有专门的页面下载后 pip install 即可。还有一个小技巧是 Python 建议用 3.8 或 3.10和 JetPack 自带的环境更匹配避免莫名奇妙的依赖冲突。接下来安装依赖pip install numpy onnx opencv-python pillow # 安装 PyTorchJetson 专用版本按 JetPack 版本选择 pip install torch2.1.0a0... # 安装 tensorrt 的 python 包 pip install tensorrt3.3 模型导出与转换YOLOv5 从 PyTorch 到 TensorRT环境准备好以后我来完整走一遍从 PyTorch 模型到 TensorRT 引擎的转换流程。我用 YOLOv5s 做例子因为它的生态最成熟导出过程也最有代表性。第一步从 PyTorch 导出 ONNX。在训练好的 YOLOv5 仓库里直接运行python export.py --weights yolov5s.pt --include onnx --opset 12 --dynamic注意 opset 版本要大于等于 11不然 TensorRT 构建时可能报不支持的算子。--dynamic 表示导出动态形状这样后面可以自由调整批量大小。不过动态 shape 在 TensorRT 里会增加引擎构建复杂度如果输入尺寸是固定的建议直接固定 shape性能会更好。第二步用 TensorRT 构建引擎文件。可以用 trtexec 命令行工具快速构建/usr/src/tensorrt/bin/trtexec \ --onnxyolov5s.onnx \ --saveEngineyolov5s_fp16.engine \ --fp16 \ --workspace4096这一步在 Orin NX 上大约需要一两分钟。构建完成后输出一个 .engine 文件之后部署时直接加载这个文件就行。第三步用 Python 加载 TensorRT 引擎做推理。我写一个尽量精简的推理脚本import tensorrt as trt import numpy as np import cv2 import pycuda.driver as cuda import pycuda.autoinit logger trt.Logger(trt.Logger.WARNING) with open(yolov5s_fp16.engine, rb) as f: runtime trt.Runtime(logger) engine runtime.deserialize_cuda_engine(f.read()) context engine.create_execution_context() input_shape (1, 3, 640, 640) # 分配显存和内存 d_input cuda.mem_alloc(trt.volume(input_shape) * trt.float32.itemsize) d_output cuda.mem_alloc(trt.volume((1, 25200, 85)) * trt.float32.itemsize) h_input np.empty(input_shape, dtypenp.float32) h_output np.empty((1, 25200, 85), dtypenp.float32) # 读取一张图片并预处理 img cv2.imread(test.jpg) img cv2.resize(img, (640, 640)) img cv2.cvtColor(img, cv2.COLOR_BGR2RGB).astype(np.float32) / 255.0 img img.transpose(2, 0, 1)[None, ...] np.copyto(h_input, img) # 推理 cuda.memcpy_htod(d_input, h_input) context.execute_v2(bindings[int(d_input), int(d_output)]) cuda.memcpy_dtoh(h_output, d_output) # 后处理这里省略 NMS实际会按置信度阈值过滤并解码框 print(h_output.shape, h_output[0, :2, 4])这段代码虽然粗糙但跑通整个流程的核心已经够了。推理部分的关键点在于显存的绑定和上下文执行TensorRT 比 ONNXRuntime 更底层所以代码相对繁琐。真要工程化我会封装一个推理类把引擎加载、缓冲分配、预处理、后处理都做好对外只暴露一个 predict(image) 接口。3.4 推理性能测试与调优方向部署完以后最重要的一步是性能测试。不能用“感觉快了”来判断要用数据说话。我会在目标设备上用固定数量的图片跑几百次推理统计平均时延和最大时延特别关注最大时延——因为实时系统里偶尔一次卡顿就可能出事故。在 Jetson 上跑到 FP16 之后通常还有几个调优方向可以进一步提速。第一开启 CUDA Graph把推理过程以图的方式固化能减少 kernel 启动开销。TensorRT 做了内置的图优化但 Python 侧的 pycuda 调用仍有开销CUDA Graph 能把这个开销进一步压缩。第二使用多线程流水线采集线程、预处理线程、推理线程、后处理线程各司其职让设备在每时每刻都在干活。第三降低输入分辨率。很多场景不需要 640×640512×512 甚至 416×416 对精度影响不大但推理速度可能提升 30% 以上。这要根据实际业务去测不能凭感觉。还有一个经常被忽略的点Jetson 的 CPU/GPU 频率和功耗模式会影响性能。默认的 NV Power Mode 偏保守性能发挥不出来。可以用 nvpmodel 切换模式比如# 查看可用模式 nvpmodel -q # 切到最高性能模式具体数字取决于设备型号 sudo nvpmodel -m 0这个操作在开发板上一行命令就能带来 20% 以上的性能提升很多人不知道。4. 延迟与断网边缘架构的真正胜负手4.1 延迟从哪里来就在哪里堵模型部署到边缘以后延迟的构成就变了。原来在云端是“传输推理”的双重延迟现在边缘推理本身只要十几毫秒问题焦点转向整条链路中的其他环节。我拆解一下边缘视觉系统的延迟组成通常是图像采集曝光、传感器读取→ 预处理缩放、归一化、内存拷贝→ 推理 → 后处理NMS、阈值过滤→ 业务逻辑 → 控制信号输出。每一步都可能成为瓶颈。图像采集如果走 USB 摄像头UVC 协议本身就有几十毫秒的开销用 CSI 摄像头会快很多。预处理如果图省事在 Python 里用 cv2.resize单帧时间可能比 TensorRT 推理还长因为 CPU 和 GPU 之间有传输开销。最佳做法是使用英伟达的 VPIVision Programming Interface库做图像处理或者直接用 CUDA 把预处理也放到 GPU 上做。内存拷贝的操作要尽量减少不要频繁把数据搬回 CPU。延迟优化不要盯着单一环节猛优化要先做 profiling找到真正的大头。我的经验是90% 的情况下延迟瓶颈不在推理本身而在图像采集、预处理和业务逻辑之间的衔接。把这些衔接部分的重复内存拷贝去掉配合流水线并行端到端延迟能降低一半以上。4.2 断网容错离线能跑在线能补边缘部署的另一个王牌是断网容错。但这绝对不是“断网后设备继续跑模型”那么简单而是要设计一套可靠的状态机。我把它分成三个等级第一级是检测网络状态。设备上常驻一个网络监测模块定期发心跳到汇聚层或者云端心跳超时就切换到本地模式。注意别用硬件层的断网报警因为物理层断开和逻辑层不通是两回事。第二级是本地数据缓存。断网期间推理结果和关键事件存在本地缓存中比如跑在一个 SQLite 或者本地 Capn Proto 文件里。缓存要有容量上限和滚动淘汰策略防止一个长假期间把存储写爆。我习惯对高频状态数据做采样存储对告警事件做全量存储保证关键信息不丢。第三级是补传与对齐。网络恢复后缓存数据按时间戳增量上报边缘和云端做数据去重避免同一事件被重复入库。这一块就用到所谓的边缘节点去重算法——本质是给每条数据一个唯一 ID通常是设备编号时间戳事件哈希上报时云端按 ID 去重。这个方案听着简单但特别实用。4.3 数据同步与并发控制断网恢复后的数据同步比很多人想象中复杂。因为设备可能关机重启、时钟漂移、事件顺序发生变化如果只按时间戳全量拉取很可能会重复、丢失、乱序。我在实际项目里的做法是边缘端维护一个自增的 sequence number每条缓存记录都带上 seq 和 device_id云端按 (device_id, seq) 做唯一约束增量拉取时用 seq 游标代替时间戳。这种设计抗干扰能力强即使设备重启、时间跳变也能保证数据最终一致。还有一个细节是并发上报时的背压控制。断网的设备很多时网络恢复瞬间所有设备同时上报很容易把带宽打满。我一般会给上报模块加一个自适应限速根据当前的网络吞吐量动态调整每批上报的记录数宁可慢一点也别把链路打到瘫痪。实测下来这个机制让整个汇聚层的稳定性提升非常明显。5. 踩坑记录与排查技巧5.1 常见问题速查表下面这些坑是我和团队在多个边缘视觉项目里踩过的每条都配了排查思路整理成表格方便大家对照排查。现象可能原因排查与解决TensorRT 引擎加载失败引擎文件和硬件/TRT版本不匹配确认 dialog 硬件型号与 JetPack 版本在目标设备上重新构建引擎INT8 模型精度骤降校准数据集覆盖面不足重新用覆盖全场景的1000张左右校准图构建引擎推理速度忽快忽慢CPU/GPU 降频或功耗模式受限检查 nvpmodel 模式检查散热必要时限制后台进程显存 OOMworkspace 设置过大或输入分辨率过高降低 --workspace 参数、减小 batch、检查是否存在内存泄漏断网后系统崩溃或退出缺少本地模式降级逻辑在架构层面需要实现边缘优先至少保证本地推理不依赖云端断网恢复后数据重复缺少去重机制在记录中加入设备ID时间戳事件哈希云端做唯一性约束摄像头图像马赛克/延迟大USB带宽不足或编码配置问题换 CSI 摄像头、降低码率、修改 v4l2 缓冲区数量5.2 我在实战中总结的几条经验最后分享几条做了这么多项目后的心得体会全部是拿时间换来的。第一边缘部署从第一天就要按“离线可用”来设计不要先做在线版本再补离线。返工的成本比多写几行状态判断高得多。我在做人脸识别系统时最初版本完全依赖云端客户现场一断网整个考勤和门禁就瘫了后来花了两个星期重构。如果一开始就按边缘优先的架构做这事两天就能搞定。第二不要迷信量化精度损失。很多团队一听 INT8 就害怕精度掉宁可模型大一圈跑在 FP16 上。但实测下来在视觉检测任务里INT8 对精度的影响通常只有 0.5% 到 2%而带来的推理加速和功耗降低却非常可观。尤其对于边缘设备INT8 往往是“能跑”和“不能跑”的分界线。第三日志和监控体系要在系统上线前就准备好。边缘设备分布在各处出了问题上手查非常痛苦。我的做法是在每个边缘节点上跑一个轻量 agent周期上报 CPU、内存、温度、推理耗时、网络状态并把这些数据汇聚到一个简单的看板里。别小看这个工作它能在你排查问题的时候省下一天时间。第四测试用例要覆盖断网、弱网、恢复瞬间这三种网络状态而不是只测满网速的情况。很多边缘系统的 bug 都出在状态切换的边界上断网瞬间的并发上报、恢复瞬间的缓存清空都是重灾区。最后补一个细节如果项目刚开始还没确定用哪块边缘板子我的建议是先用手头最便宜的 Jetson Nano 跑通整个推理流程再根据性能瓶颈决定是否升级到 Orin。很多时候模型优化后 Nano 就够用了省下来几万块的硬件预算比什么都实在。等 Jeston 的流程完全跑通再回头去优化模型、做量化、做流水线每一步都有明确的数据支撑也更容易说服团队或客户为最终的硬件方案买单。Edge AI 这条路已经相当成熟了剩下的就是亲自踩一遍坑踩完你会发现边缘没那么玄也没那么难。