从第一次在工厂车间里把一台 Jetson 设备接到流水线摄像头旁边到彻底跑通整个 AI 视觉检测流程我花了不少时间踩坑。AI-Edge 这个词看着简单真要做扎实涉及模型压缩、推理加速、设备选型、长期稳定性一大堆事。这篇文章我就以自己一个真实项目为例把边缘 AI 从方案选型到部署上线的完整链路拆开讲清楚包括硬件怎么挑、TensorRT 怎么用、INT8 量化怎么不掉点、现场排查怎么定位问题给准备上手 AI-Edge 的同行一个能直接抄作业的参考。1. 先搞清楚 AI-Edge 到底解决什么问题1.1 云端方案为什么在工业现场跑不动很多人接触 AI 项目第一反应是把画面传到服务器用 GPU 跑推理再把结果返回。这套云端架构在实验室里没有问题但到了真实的工业现场最先崩溃的往往不是模型而是网络。我接到这个项目时客户的产线对检测时延的要求是 200 毫秒以内产品经过相机下方的速度很快超过这个时间就意味着漏检。现场的网络环境并不理想车间里金属设备多Wi-Fi 信号干扰严重有线网络虽然稳定但产线改造施工周期很长。如果把视频流全部推到云端识别单路 1080p 视频按 2Mbps 码率计算光传输延迟就得 50 到 100 毫秒再加上云端排队和回传整体延迟冲到 400 毫秒以上很正常完全达不到要求。还有一个容易被忽略的问题是数据隐私。工厂的产线画面涉及产品工艺和流程客户明确要求画面不能出厂区这时候把所有数据上传云端本身就不可接受。AI-Edge 的核心思路就是把推理计算放到数据产生的地方相机旁边直接完成识别只有最终的结果上传到服务器带宽压力和隐私风险同时解决。1.2 AI-Edge 常见的四种部署形态接触多了之后会发现AI-Edge 不只是边缘设备跑 AI这一个模式按计算能力和交互方式可以分成四类第一类是端侧推理模型直接跑在设备上比如手机里的相册分类、智能摄像头里的人形侦测特点是芯片功耗极低算力有限只能跑轻量模型。我的项目就是用这条路Jetson 设备放在产线现场模型完全本地推理。第二类是边缘网关在网关设备里集成 AI 加速芯片同时负责协议转换和数据上传常见于工业物联网场景。这类设备比手机算力强可以同时处理多路视频流。第三类是边缘服务器把小型服务器放到机房或现场配备独立 GPU 或 AI 加速卡可以跑比较大的模型。适合那些无法上云、但算力需求高的场景比如园区级的安防系统。第四类是云边协同云端负责模型训练和更新边缘端负责实时推理两边通过网络同步模型版本和推理结果。这是目前工程落地最多的架构我做的项目虽然没有上云但后续客户确实计划把数据回传做进一步分析那就是典型的云边协同形态。选哪种形态完全看需求。如果只处理一两路视频端侧设备足够如果现场有几十路相机那就必须上边缘服务器了。2. 方案选型硬件、模型和软件栈怎么定2.1 先把需求量化成技术指标项目启动第一步不是买硬件而是把需求翻译成数字。我和客户反复确认了这几个关键指标检测对象产品表面划痕和污渍目标是漏检率小于 0.5%检测速度单个产品从进入视野到输出结果不超过 150 毫秒相机数量一期部署 2 路工业相机后续可能扩展到 8 路运行环境车间环境温度最高 40 摄氏度灰尘较大需要 7x24 小时连续运行功耗要求现场不能改造电路设备整机功耗需控制在 30W 以内这些数字直接决定了硬件选型。150 毫秒的推理时延意味着模型单帧推理时间至少要留 50% 的余量不然相机触发抖动或者画面模糊时就会超时。2 路相机要求设备有足够的编码和解码能力。30W 功耗排除了大部分桌面级 GPU只能选择嵌入式平台或者低功耗加速卡。2.2 硬件选型为什么选了 Jetson Orin Nano边缘 AI 设备我测试过不少包括树莓派加 Coral USB 加速棒、Intel NUC 加 Movidius 神经计算棒、Jetson 系列还有各种国产 NPU 盒子。综合算力、生态、功耗和价格最终选了 Jetson Orin Nano 8GB 版本。先看算力。Orin Nano 的 INT8 算力大约 40 TOPSFP16 算力大约 20 TFLOPS对于 YOLOv8s 这种规模的模型来说跑 INT8 量化后单帧推理时间能压到 15 到 20 毫秒余量很充足。再看生态NVIDIA 的 TensorRT、DeepStream、CUDA 工具链非常成熟遇到的绝大多数问题都能在社区找到答案这对快速落地很重要。还有一个关键点是解码能力。Orin Nano 自带硬件视频编解码器支持多路 H.264/H.265 硬解码这省掉了 CPU 软解的负担。如果选普通的 ARM 开发板仅靠 CPU 解码一路 1080p 视频就会占用 30% 以上的算力留给推理的资源就不够了。相机选的是海康的工业相机GigE 接口分辨率 1920x1080帧率 30fps。选 GigE 而不是 USB 接口主要是考虑到线材可以做到 100 米而且供电和传输共用一根网线现场布线会方便很多。GigE 相机的带宽计算很简单1080p 30fps 的 8 位灰度图带宽是 1920x1080x8x30大约 497Mbps千兆网完全够用。2.3 软件栈选型TensorRT 是绕不开的加速核心硬件定了软件栈基本也就定了。推理框架我对比过 ONNX Runtime、OpenVINO 和 TensorRT最终选择 TensorRT 作为主要推理引擎配合 ONNX 作为中间格式。TensorRT 的核心价值在于层融合和精度校准。层融合把多个算符合并成一个 kernel减少了显存读写次数。INT8 量化则通过校准数据集计算每层激活值的动态范围把 FP32 的权重映射到 INT8推理速度能提升 2 到 4 倍。对于部署在边缘设备上的模型来说这是必须做的优化否则算力利用率上不去。模型层面用的是 YOLOv8s目标检测模型里属于性价比比较高的选择COCO 数据集上 mAP 50 大约在 44.9%在复杂背景下对划痕和污渍这类小目标的召回率也比较理想。训练框架是 PyTorch训练完成后导出 ONNX再通过 TensorRT 转成 engine 文件。整套软件栈可以总结成一张表层级选型说明训练框架PyTorch 2.x生态完善模型定义灵活模型格式ONNX中间交换格式兼容多种推理引擎推理引擎TensorRT 8.6层融合 INT8 量化性能最强视频处理GStreamer / DeepStream硬解码 多路流管理服务框架FastAPI暴露 HTTP 接口便于对接上位机宿主机系统Ubuntu 20.04 LTS兼容性好驱动支持最省心3. 实操过程从训练到边缘端部署全流程3.1 数据集准备与模型训练做工业视觉检测最大的工作量通常不在模型结构上而在数据上。划痕和污渍这类缺陷正样本合格品和负样本缺陷品的比例可能达到 100:1直接用原始数据训练模型会严重偏向预测为正常。我当时的做法是先做数据增强包括旋转、缩放、亮度扰动、噪声添加把缺陷样本扩充到总量的 30% 左右同时对正常样本做随机裁剪增加背景多样性。标注工具用的 LabelImg目标框格式是 YOLO 的 txt 格式。总共标注了 8000 多张图片其中缺陷样本 2500 张划分比例训练集 70%、验证集 20%、测试集 10%。训练超参数可以参考这个配置# 训练配置示例 model: yolov8s.pt data: defect.yaml epochs: 150 batch: 16 imgsz: 640 optimizer: SGD lr0: 0.01 mosaic: 0.5 mixup: 0.2训练过程中重点观察两个指标一个是 mAP50也就是 IoU 阈值 0.5 下的平均精度另一个是召回率。对缺陷检测来说漏检比误检严重得多召回率上不去宁可多调几轮。我最后的模型 mAP50 到了 0.93召回率 0.91基本满足需求。3.2 导出 ONNX 与 TensorRT 转换训练完成后第一步是把 PyTorch 模型导出成 ONNX 格式。YOLOv8 官方库自带导出接口但有几个细节要注意。第一是导出时的 opset 版本TensorRT 8.6 支持的 opset 最高到 17选择低一点的版本兼容性更好。第二是 dynamic batch 还是固定 batch边缘端部署一般固定 batch1 就够了动态 batch 会引入额外的显存开销和转换复杂度。第三是模型输出层的处理YOLOv8 的输出包含多个尺度的检测头导出时建议把后处理逻辑留在外部只导出主干网络和检测头的原始输出这样 TensorRT 转换更高效。转换命令大概长这样trtexec \ --onnxyolov8s.onnx \ --saveEngineyolov8s.engine \ --fp16 \ --int8 \ --calibcalibration.cache这里 --calib 参数指定的是校准缓存第一次运行 INT8 转换时需要准备一个校准数据集我用了 500 张验证集图片运行时会自动统计每层激活值的分布生成校准表并缓存后续转换就不再需要原图了。3.3 写一个最小可用的推理服务模型转换完成后真正部署的时候还需要写一个推理服务。这个服务要做三件事接收前端传入的图片或视频帧调用 TensorRT 推理返回检测框和类别。我用的语言是 Python推理框架是 PyTorch 加 TensorRT 的 Python API。虽然 C 性能更高但 Python 开发效率高对于单路或双路视频流Python API 的延迟损失可以接受约 2 到 3 毫秒。核心代码结构如下import numpy as np import tensorrt as trt class YOLOv8Engine: def __init__(self, engine_path): self.logger trt.Logger(trt.Logger.WARNING) with open(engine_path, rb) as f: runtime trt.Runtime(self.logger) self.engine runtime.deserialize_cuda_engine(f.read()) self.context self.engine.create_execution_context() self.inputs, self.outputs, self.bindings [], [], [] self.stream cuda.Stream() for binding in self.engine: size trt.volume(self.engine.get_binding_shape(binding)) dtype trt.nptype(self.engine.get_binding_dtype(binding)) host_mem cuda.pagelocked_empty(size, dtype) device_mem cuda.mem_alloc(host_mem.nbytes) self.bindings.append(int(device_mem)) if self.engine.binding_is_input(binding): self.inputs.append({host: host_mem, device: device_mem}) else: self.outputs.append({host: host_mem, device: device_mem}) def infer(self, img): # 预处理: resize, letterbox, normalize input_tensor self.preprocess(img) self.inputs[0][host] np.ascontiguousarray(input_tensor) cuda.memcpy_htod_async( self.inputs[0][device], self.inputs[0][host], self.stream ) self.context.execute_async_v2(bindingsself.bindings, stream_handleself.stream.handle) for output in self.outputs: cuda.memcpy_dtoh_async( output[host], output[device], self.stream ) self.stream.synchronize() return self.postprocess(self.outputs)几个容易出错的地方输入张量一定要做 letterbox 填充不能直接 resize 拉伸否则会破坏目标的长宽比导致检测框偏移预处理后的数据必须连续内存避免 Strassen 之类的非连续内存导致 CUDA 拷贝失败后处理里 NMS 需要根据实际模型的输出格式调整置信度阈值一般设在 0.25 到 0.35 之间比较合适。3.4 视频流接入与检测逻辑编排单张图片跑通只是第一步真实场景里需要同时处理多路视频流。我用 GStreamer 管道从相机拉流每路视频单独开一个线程缓存最新的帧检测逻辑从缓存里取帧推理结果写入共享队列。GStreamer 管道配置大概是这样rtspsrc locationrtsp://192.168.1.100:554/stream1 \ ! rtph264depay ! h264parse ! nvv4l2decoder \ ! nvvidconv ! video/x-raw,formatBGRx ! videoconvert \ ! video/x-raw,formatBGR ! appsink重点是使用 nvv4l2decoder 实现硬解码把 CPU 占用率降下来。实测下来2 路 1080p 视频流同时硬解码CPU 占用率从软解时的 30% 降到 5% 以内这个优化幅度非常可观。检测逻辑需要注意丢帧策略。工业场景里相机帧率是固定的但检测算法可能跟不上比如上一帧还在处理下一帧已经到来了。稳妥的做法是当检测线程忙时直接丢弃新帧保证检测结果的实时性而不是让帧排队等待那样会让延迟持续累积。这种跳帧检测的策略比逐帧检测更适合实时性要求高的场合。4. 性能优化延迟、显存、功耗三端同调4.1 延迟优化能省 1 毫秒的细节都不能放过部署初期我用 TensorRT FP16 跑 YOLOv8s单帧推理时间大约 28 毫秒看起来还不错但放到整个链路里就会发现还有很多可以优化的地方。从相机抓帧到结果输出实际耗时分布大概是相机抓帧约 8 毫秒预处理约 5 毫秒推理约 28 毫秒后处理约 2 毫秒总共 43 毫秒加上网络传输大约到 60 毫秒虽然满足 150 毫秒的要求但我还是想把余量做大。第一个优化点是推理精度。FP16 转 INT8 后单帧推理时间从 28 毫秒降到 11 毫秒。mAP 只下降了 0.8%但延迟几乎减半。测试过后发现本项目对精度的要求不是特别苛刻INT8 完全能接受。如果你做的是医疗影像之类对精度极度敏感的项目需要认真评估这个 trade-off。第二个优化点是 CUDA 流的使用。程序里如果顺序执行拷入、推理、拷出每次都会等前一步完成再进行下一步。改用两个 CUDA 流把主机到设备的拷贝和推理重叠起来实测能再快 3 到 4 毫秒。这个幅度看起来不大但在多路视频流场景里它对吞吐量的提升是显著的。第三个优化点是批量推断。如果同时处理多路视频流可以凑够一个 batch 再一次性推理。Jetson 上 batch4 推理的耗时大约是 batch1 的两倍但一次处理四张图单帧平均耗时反而只有原来的四分之一。这个在摄像头路数多的时候收益特别大。4.2 显存优化8GB 内存怎么放进 3 个模型Orin Nano 8GB 版本实际上 CUDA 可用显存大约 7.2GB。跑一个 INT8 模型只占 800MB 左右但后续客户想在同一台设备上再跑一个分类模型和一个实例分割模型显存立刻吃紧。TensorRT 有个显存池机制可以为多个 engine 共享同一个 CUDA 上下文避免每个模型都单独申请一大块显存。实际做法是把多个 engine 放到同一个上下文里初始化并设置 workspace size 为合适的值不要贪大。另外8GB 的统一内存架构下CPU 能直接访问 GPU 内存但要尽量避免 CPU 端频繁创建临时张量那样会触发内存碎片。一个稳妥的做法是固定内存池通过预分配 buffer 来减小显存波动这在长时间运行时尤为重要。4.3 功耗与稳定性长期运行不是跑通就行工业现场 7x24 小时运行最怕的是设备过热降频、断电重启、内存泄漏。Jetson 模块支持几种运行模式我选择的是 15W 功耗的 max-sp 模式牺牲一点峰值性能换取稳定和散热压力降低。实测数据FP16 模式下整机功耗稳定在 20W 左右INT8 模式下大约 14W。设备在无空调车间里连续跑了 72 小时外壳温度约 60 摄氏度GPU 核心温度稳定在 68 摄氏度没有出现降频。如果是炎热夏天建议加一个小风扇或者用金属外壳辅助散热。内存泄漏是另一个常见的坑。Python 环境里如果每次推理都新建数组而不释放几小时后内存就会被吃光。建议在代码层面显式释放大数组并使用内存监控脚本定期检查。我写了一个简单的监控脚本每 10 秒记录一次内存和显存占用连续运行两天后看趋势排查泄漏非常有效。5. 部署现场遇到的坑与排查实录5.1 推理速度忽快忽慢先查 CPU 频率策略项目现场跑起来时发现一个问题推理时间波动很大有时 11 毫秒有时跳到 30 毫秒。第一反应是系统有后台任务在抢 CPU检查一遍并没有。后来发现是 Jetson 的 CPU 定频策略问题默认的调度策略在负载波动时会频繁调整频率导致前处理和后处理耗时出现抖动。解决办法是把 CPU 和 GPU 的频率模式固定在高性能档。执行sudo nvpmodel -m 0 sudo jetson_clocksnvpmodel -m 0 切换成 15W 上限模式jetson_clocks 把所有核心和显存频率拉满。这之后推理时间稳定在 11 毫秒左右波动很小。注意 jetson_clocks 是测试和固定频率用的如果你想长期跑建议设置开机自启动。5.2 第一次跑 TensorRT 就崩问题出在 ONNX 算子有次同事导出了一个新训练的模型转 TensorRT 时直接报Unsupported ONNX operator: GridSample。查资料发现是模型里用了 torch.nn.functional.grid_sample这个算子在 TensorRT 8.6 还不支持。我们的模型没有用 grid_sample 啊后来排查发现是 YOLOv8 官方导出接口在被调用时自动加入了某些特殊处理导致图里出现了不常见算子。解决办法有三种一是改模型的实现方式把 grid_sample 替换成等价的卷积组合这个工程量大二是升级到支持该算子的 TensorRT 9.x三是我最推荐的导出 ONNX 时设置opset12可以规避很多高级算子导致的不兼容问题。实际操作用第二种方案升级到 TensorRT 9.2问题直接解决了。5.3 连续运行两周后死机查日志发现是磁盘写满设备在客户现场连续跑了差不多两周某天突然没有任何响应ping 不通现场只能断电重启。我上去查日志发现根目录满了。原因是我在调试阶段把日志级别设成了 debug推理时每次请求都会打印一行完整输出再加上 TensorRT 的 profiler 日志两周下来写了几十 GB。这听着很初级但确实是最常见的生产事故。解决办法是把日志输出全部用系统日志接管设置日志轮转并写了一个定期清理临时目录的脚本。这里特别提醒边缘设备往往用的存储卡或 SSD 容量不大日志策略最好从第一天就设计好别等到出了问题再补救。5.4 常见问题速查表整理一下我遇到过的和同行交流到的典型问题方便大家排查现象可能原因解决办法推理速度波动大CPU 频率策略未固定执行 jetson_clocks 定频转 engine 报 Unsupported operatorONNX 算子版本过高升级 TensorRT 或降低 opset 版本显存不足多个模型重复加载使用显存池共享上下文长时间运行内存暴涨Python 对象未释放显式释放大数组监控脚本定期检查设备过热重启散热不够或功耗模式过高切换到 15W 模式增加外部散热视频流延迟累计越来越大帧队列堆积改用丢帧策略检测忙时直接丢弃新帧相机频繁断连网线过长或供电不足检查 PoE 供电缩短网线或加交换机断电后服务不自动恢复未配置开机自启用 systemd 配置服务自启动加 watchdog排查问题时我的习惯是先看资源再看日志。现场设备不像服务器那样方便随时连上去调试优先检查 CPU、内存、显存、磁盘、温度这五项再结合日志文件定位绝大多数问题都能快速圈定范围。我个人在实际项目里最大的体会是AI-Edge 项目的难点从来不只是模型准确率而是模型之外的那一整套工程问题。算力调度、延迟控制、功耗平衡、设备稳定性、现场环境适配每一个细节都在决定项目能不能真正跑起来。把本文里这些问题提前处理好你的边缘 AI 项目就能少走很多弯路。