上个月接手了一个光伏组件外观缺陷检测的项目甲方要求检测设备必须塞进产线旁边的小机柜夏天机柜里温度能到五十多度供电还是老厂房的直流电源电压波动非常厉害。一开始想着用普通工控机加显卡的方案顶一顶结果要么算力不够跑不动深度学习模型要么体积和发热根本压不住。后来换成 Axiomtek AIE110-XNX 这套基于 NVIDIA Jetson Xavier NX 的边缘 AI 开发套件才真正把项目推进下去。这篇文章不打算写成参数罗列式的产品新闻稿而是老老实实分享我从选型、开箱、系统部署到实际落地这一整套过程中的真实体验。如果你也在做工业质检、移动机器人、智能安防这类边缘 AI 项目正在纠结选什么硬件或者已经看中 Xavier NX 平台但不确定工业级套件和普通开发板有多大差别那这篇内容应该能帮你少走不少弯路。1. 项目定位与方案选型思路1.1 边缘计算为什么卡在工业现场很多朋友第一次接触边缘 AI习惯性地拿云端那套思路来想问题GPU 不够就加卡算力不够就上集群。但工业现场的约束条件完全不一样。首先产线旁边的物理空间非常有限一台带 RTX 显卡的工控机往往是放不进去的。其次工业现场的供电环境远没有机房那么干净大功率设备启动时电压跌落、变频器干扰这些都是常态。最后也是最重要的一点工业设备必须保证长时间稳定运行消费级显卡的散热设计在这种环境下很容易触发降频导致推理速度波动。边缘 AI 设备的存在就是要把推理计算放到数据产生的地方在几乎没有网络延迟、不依赖外部连接的情况下完成实时分析。这样既解决了带宽问题也避免了把敏感生产数据传到外部带来的合规风险。但在工业场景里光有算力还不够设备必须耐得住高温、扛得住电压波动、接得上现场的各种传感器和执行机构。这就是我对这类设备的基本要求。单看算力Jetson Xavier NX 模块能提供最高 21 TOPS 的 INT8 算力功耗却只有 10 到 20 瓦左右这个算力功耗比在同类产品里可以说几乎没有对手。但裸模块本身没法直接用在现场它需要载板提供供电、接口、散热这些基础设施。而 Axiomtek AIE110-XNX 的价值恰恰在于它把 Xavier NX 模块变成了一个真正能进产线、能上车、能挂在电柜里的完整设备。1.2 同类方案的横向对比在选型阶段我认真对比过几类方案包括 Raspberry Pi 加 NPU 加速棒、普通工控机配低端显卡、Jetson 系列开发板以及这款工业级边缘 AI 开发套件。它们的差异非常明显。Raspberry Pi 加加速棒成本确实低一套下来一千出头但算力撑死几个 TOPS跑轻量分类模型可以跑 YOLO 级别的目标检测就比较吃力了。而且树莓派的稳定性和工业环境适配性差很多没有可靠的宽温设计长期运行 TF 卡还容易损坏。工控机配 GTX 1650 这类低端显卡算力是够了但整机功耗要到一百瓦往上体积普遍偏大散热问题在密封机柜里很难处理。Jetson 开发板比如 Jetson Xavier NX Developer Kit算力足够生态也成熟但开发板的定位是给开发者做原型验证用的接口的工业防护、供电稳定性、安装方式都不适合直接部署到现场。AIE110-XNX 给我的第一印象是它把 Jetson 的高算力低功耗优势和工业级的可靠性结合在了一起。宽温设计、宽压输入、丰富的串口和 CAN 接口、DIN 导轨安装这些都不是消费级产品的配置而是长期面对恶劣环境的工业设备才有的特性。从长期维护的角度看这类平台的一次性投入虽然比开发板贵但省去了后续现场故障的返修成本这笔账是算得过来的。1.3 AIE110-XNX 适合哪些实际场景基于我这段时间的使用经验我觉得这套设备最适合三类场景。第一类是工业机器视觉检测比如产品表面的缺陷检测、字符识别、尺寸测量摄像头固定在产线上方AIE110 实时跑检测模型把结果通过 IO 信号传给 PLC 控制剔除机构。第二类是移动机器人和无人车辆也就是 AGV、AMR、巡检机器人设备装在车体内部通过 CAN 接口和底盘通信通过网口连接激光雷达或摄像头在车上完成实时感知和路径规划。第三类是智慧交通和安防场景比如卡口抓拍、人流统计、区域入侵检测设备部署在道路旁边的机柜或者杆件上要求能在恶劣天气条件下稳定运行。当然它也有不适合的场景。比如你要做大规模的模型训练那应该用数据中心级别的 GPU 服务器而不是这种边缘设备。再比如你对单台设备的算力要求超过 50 TOPS那可能得看更高端的 Jetson Orin 系列或者其他方案。搞清楚边界选型才不会跑偏。2. 硬件规格与接口细读2.1 核心计算单元Jetson Xavier NX 模块AIE110-XNX 的计算核心是 NVIDIA Jetson Xavier NX 模块这个模块一共有 384 个 CUDA 核心、48 个 Tensor Core、2 个 NVDLA 深度学习加速引擎以及一颗 6 核 Carmel ARM 处理器。纸面算力最高 21 TOPSINT8支持 FP16、INT8 这些对深度学习推理非常友好的精度模式。这颗芯片的特别之处在于它把完整的 GPU 架构塞进了 15 瓦左右的功耗范围里。虽然跟最新的 Orin 系列比算力有差距但对于绝大多数工业视觉应用来说这个算力级别已经完全够用了。以我的实际经验在 TensorRT 加速下YOLOv8n 在 640 分辨率下能做到 60 帧以上ResNet18 分类模型跑 224 分辨率更是轻松跑满两百多帧。Xavier NX 还支持多种功耗模式切换从 10 瓦到 20 瓦可以按需调整。在电池供电的移动设备上经常我们会切成低功耗模式来延长续航在固定安装的产线设备上直接开满功耗模式让算力全开。另外模块自带 8GB 或 16GB 的 LPDDR4x 内存这两个版本的选择建议直接上 16GB因为跑多路视频流或者大模型时内存很容易成为瓶颈。2.2 板卡级设计工业 I/O 才是重点如果只关注 Jetson 模块本身那 AIE110-XNX 和其他开发板似乎没什么区别。但把目光放到载板设计上差别就非常大了。AIE110-XNX 提供了两个千兆网口其中一个支持 PoE可以直接为网络摄像头供电现场布线省掉了单独的电源线。USB 3.0 接口有四个外接工业相机、鼠标键盘、U 盘都够用。串口方面配备了 RS-232/422/485 可切换接口兼容老式 PLC、仪器仪表这类设备非常关键。真正让我觉得这套设备是为了工业场景而生的是它自带 CAN 总线接口和 8 路数字输入输出DI/DO。在移动机器人项目里底盘电机控制器基本都是走 CAN 通信的有这个接口就不需要额外转接模块了。DI/DO 则可以直接对接光电传感器、继电器、报警灯实现检测结果到执行机构的闭环。比如产线上检测到缺陷产品程序通过 DO 输出一个高电平信号给剔除气缸的电磁阀整个过程不需要经过 PLC 中转延迟极低。供电方面它支持 9 到 36 伏的宽压直流输入这个范围覆盖了工业现场常见的 12V、24V 电源系统。即使供电电压有波动设备也能正常工作。温度适应性上它支持 -10 到 60 度的宽温工作范围内部采用无风扇散热设计。这一点在粉尘大的车间里特别重要普通带风扇的设备用不了几个月风扇就会被灰尘堵死而无风扇设计直接避免了这个问题。2.3 存储、无线与安装扩展存储方面AIE110-XNX 板载一个 M.2 2280 NVMe SSD 插槽系统、模型、数据全都放在 NVMe 盘上读写速度比 TF 卡和 eMMC 快了一个数量级。还有一个 M.2 2230 插槽可以用来扩展 Wi-Fi 蓝牙模块以及一个 SIM 卡槽支持接入 4G 或 5G 通信模块。在移动无人车或者远程巡检这种需要无线回传的场景里插上 4G 模块就能远程访问设备非常方便。安装方面这套套件支持 DIN 导轨安装这是工业控制柜里的标准安装方式。设备两侧有安装孔位也可以直接固定在机柜背板或机器人本体上。接口布局很合理电源输入、网口、串口这些经常插拔的接口都安排在容易操作的侧面USB 和其他不太常动的接口安排在另一侧现场接线的时候明显能感觉到这个设计是考虑过实际使用场景的。3. 系统烧录与基础环境部署3.1 开箱检查与首次接线设备拿到手首先检查配件是否齐全。除了 AIE110-XNX 主机本体一般还会附带电源适配器、DIN 导轨卡扣、以及快速安装手册。电源适配器输出电压通常不一定是 24V具体看产品型号配置我拿到的这一版是 24V 适配器接头是标准的 DC 圆头。首次接线有几点要注意一是电源线正负极不要接反虽然设备有反接保护但养成好习惯总没错二是如果现场使用自己的电源而不是原装适配器建议先确认空载电压在 9-36V 范围内再把电源接入设备三是如果你要用 PoE 给摄像头供电需要先确认网口的 PoE 供电规格是否匹配摄像头的功耗需求。接好电源和显示器键盘鼠标之后上电开机。正常情况下电源指示灯会亮起几秒钟后显示器输出画面。这时进入的是预装的 Linux 系统或者等待烧录的状态取决于出厂配置。如果是纯开发套件一般拿到手之后需要自己烧录系统。3.2 系统烧录与 JetPack 版本选择Jetson 平台的操作系统叫 JetPack它不是单纯的 Linux 系统而是包含了 Ubuntu、CUDA、cuDNN、TensorRT、OpenCV 等一系列 AI 开发工具的完整 SDK。选择 JetPack 版本的时候要注意和后续要用的深度学习框架版本的兼容性。Xavier NX 支持 JetPack 5.x 和 JetPack 6.x 系列我这边为了保证 Docker 容器生态的兼容性选择的是 JetPack 5.1.2 版本搭载 Ubuntu 20.04 LTS 系统。烧录有两种常见方式一种是用 NVIDIA SDK Manager 通过图形界面操作优点是自动选择匹配的版本和组件但对宿主机系统有要求必须在 x86 的 Ubuntu 系统上运行。另一种是下载官方预编译的系统镜像用 Etcher 或 dd 命令把镜像写入一张 TF 卡或 NVMe SSD然后从外部存储启动系统。这个方式不依赖额外的宿主机系统适合在机房或者办公室快速完成初始系统部署。我这次用的是镜像写入的方式。具体步骤是先从官网下载对应设备型号的 Xavier NX 烧写镜像考虑到 8GB 以上容量直接写入 NVMe SSD然后把 SSD 插到 AIE110-XNX 的 M.2 插槽里用 SDK Manager 或者系统自带的初始化脚本把系统从 SSD 启动起来。需要注意的是如果你用的是外接显示器做初始配置需要提前准备好 HDMI 转接线因为 AIE110 的显示接口有 HDMI 和 DP 两种别插错了口。3.3 功耗模式与性能状态调整系统装好之后第一步要做的不是急着跑模型而是把设备的功耗模式设置成你的目标模式。Jetson 平台默认的功耗模式不一定是最适合你应用的比如 Xavier NX 有 10W、15W、20W 几个档位每个档位下 CPU 核心数量和频率也不同。执行以下命令可以查看当前模式和可用模式sudo nvpmodel --query通常 20W 模式内部编号可能是 0 或 2依 JetPack 版本而定会全部开启 6 个 CPU 核心和 GPU 的完整频率性能最强。如果设备是电池供电可以切到 10W 低功耗模式。改完功耗模式之后还有必要执行一次sudo jetson_clocks来释放最大频率这个命令会把 CPU、GPU 的频率锁到最高档避免系统因为负载低而自动降频。当然如果设备散热条件不好不建议开启这个命令否则容易触发温度保护。我强烈建议装一个 jtop 监控工具用来实时查看 CPU、GPU、内存、温度、功耗这些关键数据sudo apt update sudo apt install python3-pip sudo pip3 install jetson-stats sudo jtopjtop 的可视化界面能直观看到 6 个 CPU 核的使用率、GPU 的负载百分比、内存占用和当前温度。后面做性能压测的时候这个工具非常重要。用 jtop 确认设备温度和频率稳定之后再进入下一步深度学习和推理环境的配置。3.4 Docker 容器化环境的搭建Jetson 平台我强烈建议从一开始就使用 Docker 来管理运行环境。因为深度学习项目涉及的软件依赖非常复杂Python 版本、CUDA 版本、PyTorch 版本之间稍微不匹配就会出各种莫名其妙的问题。用容器拆分开之后不同项目用不同的容器互不影响升级也方便。JetPack 系统自带 NVIDIA Container Toolkit可以直接拉取 NVIDIA 为 Jetson 平台发布的镜像。比如跑 PyTorch 的项目直接用官方发布的 PyTorch 容器镜像里面已经把对应版本的 CUDA、PyTorch、TorchVision 都配好了省去了自己编译的痛苦经历。给容器启一个带 GPU 加速的交互式环境命令大概是这样的sudo docker run --runtime nvidia -it --rm --network host \ -v /home/edge/project:/project nvcr.io/nvidia/pytorch:23.08-py3这套方式在 Xavier NX 上实测是非常稳定的。需要注意的是Jetson 的 Docker 镜像和 x86 平台的镜像是两套体系千万别把 x86 的镜像直接拉过来跑架构不匹配会报Exec format error。正确的镜像都是基于 ARM64 架构构建的。如果自己从 Dockerfile 构建镜像基础镜像也要选 ARM64 版本。4. 实际推理性能与应用落地4.1 常用模型在 Xavier NX 上的实测表现系统环境配好之后我把几个在工业场景里最常用的模型都用 TensorRT 做了一遍实测。这里我用的是 TensorRT FP16 精度输入分辨率按典型场景设定统计结果是设备在 20W 模式、环境温度 25 度、jtop 显示设备稳定的情况下跑出来的模型输入分辨率精度模式平均推理耗时说明YOLOv8n640x640TensorRT FP16约 16 毫秒目标检测轻量场景YOLOv8s640x640TensorRT FP16约 28 毫秒目标检测平衡型YOLOv8m640x640TensorRT FP16约 58 毫秒目标检测高精度ResNet18224x224TensorRT FP16约 3 毫秒图像分类ResNet50224x224TensorRT FP16约 9 毫秒图像分类MobileNetV3320x320TensorRT FP16约 4 毫秒轻量分类DeepLabV3 (MobileNetV2)512x512TensorRT FP16约 38 毫秒语义分割这组数据和其他平台对比起来很能说明问题。YOLOv8s 在 28 毫秒左右完成一帧检测换算下来每秒能处理 35 帧以上对于大多数产线质检和安防监控场景这个速度是足够的。关键是在这个性能水平下整机功耗只有二十瓦左右热量又低所以才能放进密封机柜里长期运行。对比一下如果我用普通工控机加独立显卡要跑到这个性能整机功耗至少一百瓦起步散热设计、电源容量、机柜体积都要上一个台阶。所以对很多固定安装的边缘视觉项目来说Xavier NX 级别算力配合工业级载板确实是最优解。4.2 TensorRT 加速的实践经验很多初学者在 Jetson 设备上直接跑 PyTorch 的原始模型性能非常差CPU 吃满但 GPU 利用率只有个位数。原因在于 PyTorch 默认的推理路径没有充分调用 TensorRT 的深度优化。在 Jetson 平台上做推理一定要走 TensorRT 这条路线。最常用的转换路径是先导出 ONNX 模型再用 TensorRT 自带的 trtexec 工具把 ONNX 转成 engine 文件。举个例子如果你的模型是 YOLOv8 的 PyTorch 权重先导出 ONNXyolo export modelyolov8n.pt formatonnx opset12然后宿主机上执行 TensorRT 转换Xavier NX 上 trtexec 的默认路径一般是/usr/src/tensorrt/bin/trtexec/usr/src/tensorrt/bin/trtexec \ --onnxyolov8n.onnx \ --saveEngineyolov8n.engine \ --fp16 \ --workspace2048转换完成后代码里就用 TensorRT 的 Python API 加载这个 engine 文件做推理不要直接跑 PyTorch 的 forward。这一步做完性能提升通常是几倍到十几倍。我用 YOLOv8n 实测PyTorch 原始推理在 Xavier NX 上大概一百多毫秒一帧TensorRT FP16 加速后直接降到十六毫秒左右。不过要注意一点FP16 精度虽然视觉上识别效果几乎无差别但对于某些对数值精度极其敏感的任务比如工业仪表读数识别还是建议做一次完整的精度验证。如果发现 FP16 下精度有明显下降可以退回到 FP32 模式代价是推理速度会下降一半左右或者采用 TensorRT 的 INT8 量化实测速度和精度都表现更好但需要准备校准数据集。4.3 一个完整的落地案例光伏组件缺陷检测拿这次最典型的光伏组件外观缺陷检测项目来具体说说。需求是检测光伏板表面的隐裂、断栅、脏污这三类缺陷产线节拍要求每块组件检测时间不超过四秒。相机用的是 1200 万像素工业相机架在流水线上方每次拍摄获取一张 3000 万像素级别的高清图像。整体架构是这样工业相机通过 USB 3.0 连接到 AIE110-XNX相机触发信号由 PLC 通过光电传感器给出设备跑 YOLOv8 模型做缺陷定位然后根据检测结果通过 DO 口输出分类信号控制后端的喷码机打标记。整个流程闭环都在设备本地完成不需要任何服务器参与。处理 3000 万像素的大图如果直接送进 YOLO 网络显存和计算量都是问题。我采用的方法是先对原图进行滑窗切割切成若干 640x640 的小图然后逐个送入 TensorRT 引擎推理最后合并结果。这样每个小图的推理耗时约 16 毫秒一张大图大概几十个窗口总耗时控制在两秒左右完全满足四秒的节拍要求。这个项目在现场跑了整整三个月设备温度稳定在六十度以下没有出现过一次死机或者推理超时。之前用普通设备遇到的死机、过热降频问题在这台设备上完全没有出现。这套硬件在这种高强度持续推理场景下稳定性的表现确实让人放心。5. 踩坑记录与排查技巧5.1 散热与降频问题第一次把设备装进密封机柜后我隔几天用 jtop 查看时发现设备温度长期徘徊在七十度以上频率被限制到较低的档位推理耗时比实验室环境多了将近一倍。排查下来发现机柜内没有加装散热风扇整个柜子简直是个烤箱。这个问题不是设备本身设计有缺陷而是安装环境的散热条件太差。解决方法不复杂给机柜加装了一个排气风扇确保空气能从进风口流向出风口再在设备外壳和机柜壁之间保留了至少五厘米的散热空间。改完之后设备温度降到了五十度左右性能恢复正常。如果你也遇到类似问题先别急着怀疑硬件检查一下设备周围有没有被其他发热设备包围散热通道有没有被堵住。长期高温运行不仅会触发频率限制还会加速电子元器件的老化这一点在工业现场特别要重视。5.2 供电电压波动引起的意外重启光伏车间里有大量的变频器和伺服电机电网污染非常严重。设备刚装上去的时候运行几个小时就会偶发重启没有任何规律。排查过程很痛苦最后还是摸到规律重启发生的时间点和大功率设备启停的时间点高度吻合。检查了设备的电源输入电压记录发现当车间大功率设备同时启动时直流母线上的电压会瞬间跌落低于设备的正常工作电压下限导致设备断电重启。解决方法是调整供电方案从同一个直流电源上单独拉一路给 AIE110 供电并在电源输入端加了一个容量比较大的电容做蓄能对短暂跌落起到了缓冲作用。另外检查了接地确认设备外壳和机柜的接地电阻没问题。整改后重启问题基本杜绝了。Kern.log 里记录到voltage drop相关的信息也是一个重要的排查线索。5.3 串口和 CAN 通信权限问题如果你要用 AIE110-XNX 和现场的 PLC、电机驱动器通信大概率会用到串口和 CAN 接口。Linux 系统下外设的访问权限是个很容易踩的坑。默认情况下普通用户访问/dev/ttyUSB0或者/dev/ttyTHS1经常会遇到Permission denied必须加 sudo 才能操作这个问题在现场调试时极其烦人。解决方案是把当前用户加入 dialout 组同时用 udev 规则固定设备节点的名称。比如你的 USB 转串口模块每次插入时设备名可能会在ttyUSB0和ttyUSB1之间跳来跳去写应用程序时就不能写死端口名需要用 udev 根据设备的 VID/PID 映射一个固定的符号链接比如/dev/plc1。CAN 接口也是一样先设置好波特率再打开sudo ip link set can0 up type can bitrate 500000 sudo ip link set can0 up5.4 常见问题速查表我把这几个月遇到的高频问题整理成了表格方便你排查现象可能原因处理办法推理速度越来越慢散热不良导致频率墙jtop 确认温度加装风扇或改善通风无规律重启供电电压跌落或接地不良检查供电线路单独供电改善接地摄像头无法识别USB 接口供电不足检查 USB 供电使用带独立供电的镜头接口开机后显示器无信号显示接口接错或系统未启动确认 HDMI/DP 接口选择正确检查指示灯状态串口读写报权限错误用户不在 dialout 组执行sudo usermod -aG dialout $USER并重新登录模型转换失败ONNX 导出 opset 版本过旧或过高检查 opset 版本使用官方推荐参数重新导出系统盘空间耗尽日志和容器镜像过多清理旧容器镜像定期清理日志文件设备 IP 变了连不上DHCP 获取到了新地址现场固定 IP配置静态地址这套速查表在项目交付时我同步整理给了运维同事之后现场出了问题他们能独立处理一半以上不用每次都远程找我。工业设备长期运行这种可运维性往往比参数本身更重要。最后再分享一个我自己养成的习惯新设备到手不要急着跑 demo先把系统、SDK、Docker 环境、监控工具全部配好做一次完整的温度压测和性能基准记录存档。后面项目上线后设备性能有波动翻出基线数据一对比问题在哪里立刻就有方向。这一步相当于给设备的健康状态留了个底稿省下来的可能是一整周的排查时间。
上个月接手了一个光伏组件外观缺陷检测的项目甲方要求检测设备必须塞进产线旁边的小机柜夏天机柜里温度能到五十多度供电还是老厂房的直流电源电压波动非常厉害。一开始想着用普通工控机加显卡的方案顶一顶结果要么算力不够跑不动深度学习模型要么体积和发热根本压不住。后来换成 Axiomtek AIE110-XNX 这套基于 NVIDIA Jetson Xavier NX 的边缘 AI 开发套件才真正把项目推进下去。这篇文章不打算写成参数罗列式的产品新闻稿而是老老实实分享我从选型、开箱、系统部署到实际落地这一整套过程中的真实体验。如果你也在做工业质检、移动机器人、智能安防这类边缘 AI 项目正在纠结选什么硬件或者已经看中 Xavier NX 平台但不确定工业级套件和普通开发板有多大差别那这篇内容应该能帮你少走不少弯路。1. 项目定位与方案选型思路1.1 边缘计算为什么卡在工业现场很多朋友第一次接触边缘 AI习惯性地拿云端那套思路来想问题GPU 不够就加卡算力不够就上集群。但工业现场的约束条件完全不一样。首先产线旁边的物理空间非常有限一台带 RTX 显卡的工控机往往是放不进去的。其次工业现场的供电环境远没有机房那么干净大功率设备启动时电压跌落、变频器干扰这些都是常态。最后也是最重要的一点工业设备必须保证长时间稳定运行消费级显卡的散热设计在这种环境下很容易触发降频导致推理速度波动。边缘 AI 设备的存在就是要把推理计算放到数据产生的地方在几乎没有网络延迟、不依赖外部连接的情况下完成实时分析。这样既解决了带宽问题也避免了把敏感生产数据传到外部带来的合规风险。但在工业场景里光有算力还不够设备必须耐得住高温、扛得住电压波动、接得上现场的各种传感器和执行机构。这就是我对这类设备的基本要求。单看算力Jetson Xavier NX 模块能提供最高 21 TOPS 的 INT8 算力功耗却只有 10 到 20 瓦左右这个算力功耗比在同类产品里可以说几乎没有对手。但裸模块本身没法直接用在现场它需要载板提供供电、接口、散热这些基础设施。而 Axiomtek AIE110-XNX 的价值恰恰在于它把 Xavier NX 模块变成了一个真正能进产线、能上车、能挂在电柜里的完整设备。1.2 同类方案的横向对比在选型阶段我认真对比过几类方案包括 Raspberry Pi 加 NPU 加速棒、普通工控机配低端显卡、Jetson 系列开发板以及这款工业级边缘 AI 开发套件。它们的差异非常明显。Raspberry Pi 加加速棒成本确实低一套下来一千出头但算力撑死几个 TOPS跑轻量分类模型可以跑 YOLO 级别的目标检测就比较吃力了。而且树莓派的稳定性和工业环境适配性差很多没有可靠的宽温设计长期运行 TF 卡还容易损坏。工控机配 GTX 1650 这类低端显卡算力是够了但整机功耗要到一百瓦往上体积普遍偏大散热问题在密封机柜里很难处理。Jetson 开发板比如 Jetson Xavier NX Developer Kit算力足够生态也成熟但开发板的定位是给开发者做原型验证用的接口的工业防护、供电稳定性、安装方式都不适合直接部署到现场。AIE110-XNX 给我的第一印象是它把 Jetson 的高算力低功耗优势和工业级的可靠性结合在了一起。宽温设计、宽压输入、丰富的串口和 CAN 接口、DIN 导轨安装这些都不是消费级产品的配置而是长期面对恶劣环境的工业设备才有的特性。从长期维护的角度看这类平台的一次性投入虽然比开发板贵但省去了后续现场故障的返修成本这笔账是算得过来的。1.3 AIE110-XNX 适合哪些实际场景基于我这段时间的使用经验我觉得这套设备最适合三类场景。第一类是工业机器视觉检测比如产品表面的缺陷检测、字符识别、尺寸测量摄像头固定在产线上方AIE110 实时跑检测模型把结果通过 IO 信号传给 PLC 控制剔除机构。第二类是移动机器人和无人车辆也就是 AGV、AMR、巡检机器人设备装在车体内部通过 CAN 接口和底盘通信通过网口连接激光雷达或摄像头在车上完成实时感知和路径规划。第三类是智慧交通和安防场景比如卡口抓拍、人流统计、区域入侵检测设备部署在道路旁边的机柜或者杆件上要求能在恶劣天气条件下稳定运行。当然它也有不适合的场景。比如你要做大规模的模型训练那应该用数据中心级别的 GPU 服务器而不是这种边缘设备。再比如你对单台设备的算力要求超过 50 TOPS那可能得看更高端的 Jetson Orin 系列或者其他方案。搞清楚边界选型才不会跑偏。2. 硬件规格与接口细读2.1 核心计算单元Jetson Xavier NX 模块AIE110-XNX 的计算核心是 NVIDIA Jetson Xavier NX 模块这个模块一共有 384 个 CUDA 核心、48 个 Tensor Core、2 个 NVDLA 深度学习加速引擎以及一颗 6 核 Carmel ARM 处理器。纸面算力最高 21 TOPSINT8支持 FP16、INT8 这些对深度学习推理非常友好的精度模式。这颗芯片的特别之处在于它把完整的 GPU 架构塞进了 15 瓦左右的功耗范围里。虽然跟最新的 Orin 系列比算力有差距但对于绝大多数工业视觉应用来说这个算力级别已经完全够用了。以我的实际经验在 TensorRT 加速下YOLOv8n 在 640 分辨率下能做到 60 帧以上ResNet18 分类模型跑 224 分辨率更是轻松跑满两百多帧。Xavier NX 还支持多种功耗模式切换从 10 瓦到 20 瓦可以按需调整。在电池供电的移动设备上经常我们会切成低功耗模式来延长续航在固定安装的产线设备上直接开满功耗模式让算力全开。另外模块自带 8GB 或 16GB 的 LPDDR4x 内存这两个版本的选择建议直接上 16GB因为跑多路视频流或者大模型时内存很容易成为瓶颈。2.2 板卡级设计工业 I/O 才是重点如果只关注 Jetson 模块本身那 AIE110-XNX 和其他开发板似乎没什么区别。但把目光放到载板设计上差别就非常大了。AIE110-XNX 提供了两个千兆网口其中一个支持 PoE可以直接为网络摄像头供电现场布线省掉了单独的电源线。USB 3.0 接口有四个外接工业相机、鼠标键盘、U 盘都够用。串口方面配备了 RS-232/422/485 可切换接口兼容老式 PLC、仪器仪表这类设备非常关键。真正让我觉得这套设备是为了工业场景而生的是它自带 CAN 总线接口和 8 路数字输入输出DI/DO。在移动机器人项目里底盘电机控制器基本都是走 CAN 通信的有这个接口就不需要额外转接模块了。DI/DO 则可以直接对接光电传感器、继电器、报警灯实现检测结果到执行机构的闭环。比如产线上检测到缺陷产品程序通过 DO 输出一个高电平信号给剔除气缸的电磁阀整个过程不需要经过 PLC 中转延迟极低。供电方面它支持 9 到 36 伏的宽压直流输入这个范围覆盖了工业现场常见的 12V、24V 电源系统。即使供电电压有波动设备也能正常工作。温度适应性上它支持 -10 到 60 度的宽温工作范围内部采用无风扇散热设计。这一点在粉尘大的车间里特别重要普通带风扇的设备用不了几个月风扇就会被灰尘堵死而无风扇设计直接避免了这个问题。2.3 存储、无线与安装扩展存储方面AIE110-XNX 板载一个 M.2 2280 NVMe SSD 插槽系统、模型、数据全都放在 NVMe 盘上读写速度比 TF 卡和 eMMC 快了一个数量级。还有一个 M.2 2230 插槽可以用来扩展 Wi-Fi 蓝牙模块以及一个 SIM 卡槽支持接入 4G 或 5G 通信模块。在移动无人车或者远程巡检这种需要无线回传的场景里插上 4G 模块就能远程访问设备非常方便。安装方面这套套件支持 DIN 导轨安装这是工业控制柜里的标准安装方式。设备两侧有安装孔位也可以直接固定在机柜背板或机器人本体上。接口布局很合理电源输入、网口、串口这些经常插拔的接口都安排在容易操作的侧面USB 和其他不太常动的接口安排在另一侧现场接线的时候明显能感觉到这个设计是考虑过实际使用场景的。3. 系统烧录与基础环境部署3.1 开箱检查与首次接线设备拿到手首先检查配件是否齐全。除了 AIE110-XNX 主机本体一般还会附带电源适配器、DIN 导轨卡扣、以及快速安装手册。电源适配器输出电压通常不一定是 24V具体看产品型号配置我拿到的这一版是 24V 适配器接头是标准的 DC 圆头。首次接线有几点要注意一是电源线正负极不要接反虽然设备有反接保护但养成好习惯总没错二是如果现场使用自己的电源而不是原装适配器建议先确认空载电压在 9-36V 范围内再把电源接入设备三是如果你要用 PoE 给摄像头供电需要先确认网口的 PoE 供电规格是否匹配摄像头的功耗需求。接好电源和显示器键盘鼠标之后上电开机。正常情况下电源指示灯会亮起几秒钟后显示器输出画面。这时进入的是预装的 Linux 系统或者等待烧录的状态取决于出厂配置。如果是纯开发套件一般拿到手之后需要自己烧录系统。3.2 系统烧录与 JetPack 版本选择Jetson 平台的操作系统叫 JetPack它不是单纯的 Linux 系统而是包含了 Ubuntu、CUDA、cuDNN、TensorRT、OpenCV 等一系列 AI 开发工具的完整 SDK。选择 JetPack 版本的时候要注意和后续要用的深度学习框架版本的兼容性。Xavier NX 支持 JetPack 5.x 和 JetPack 6.x 系列我这边为了保证 Docker 容器生态的兼容性选择的是 JetPack 5.1.2 版本搭载 Ubuntu 20.04 LTS 系统。烧录有两种常见方式一种是用 NVIDIA SDK Manager 通过图形界面操作优点是自动选择匹配的版本和组件但对宿主机系统有要求必须在 x86 的 Ubuntu 系统上运行。另一种是下载官方预编译的系统镜像用 Etcher 或 dd 命令把镜像写入一张 TF 卡或 NVMe SSD然后从外部存储启动系统。这个方式不依赖额外的宿主机系统适合在机房或者办公室快速完成初始系统部署。我这次用的是镜像写入的方式。具体步骤是先从官网下载对应设备型号的 Xavier NX 烧写镜像考虑到 8GB 以上容量直接写入 NVMe SSD然后把 SSD 插到 AIE110-XNX 的 M.2 插槽里用 SDK Manager 或者系统自带的初始化脚本把系统从 SSD 启动起来。需要注意的是如果你用的是外接显示器做初始配置需要提前准备好 HDMI 转接线因为 AIE110 的显示接口有 HDMI 和 DP 两种别插错了口。3.3 功耗模式与性能状态调整系统装好之后第一步要做的不是急着跑模型而是把设备的功耗模式设置成你的目标模式。Jetson 平台默认的功耗模式不一定是最适合你应用的比如 Xavier NX 有 10W、15W、20W 几个档位每个档位下 CPU 核心数量和频率也不同。执行以下命令可以查看当前模式和可用模式sudo nvpmodel --query通常 20W 模式内部编号可能是 0 或 2依 JetPack 版本而定会全部开启 6 个 CPU 核心和 GPU 的完整频率性能最强。如果设备是电池供电可以切到 10W 低功耗模式。改完功耗模式之后还有必要执行一次sudo jetson_clocks来释放最大频率这个命令会把 CPU、GPU 的频率锁到最高档避免系统因为负载低而自动降频。当然如果设备散热条件不好不建议开启这个命令否则容易触发温度保护。我强烈建议装一个 jtop 监控工具用来实时查看 CPU、GPU、内存、温度、功耗这些关键数据sudo apt update sudo apt install python3-pip sudo pip3 install jetson-stats sudo jtopjtop 的可视化界面能直观看到 6 个 CPU 核的使用率、GPU 的负载百分比、内存占用和当前温度。后面做性能压测的时候这个工具非常重要。用 jtop 确认设备温度和频率稳定之后再进入下一步深度学习和推理环境的配置。3.4 Docker 容器化环境的搭建Jetson 平台我强烈建议从一开始就使用 Docker 来管理运行环境。因为深度学习项目涉及的软件依赖非常复杂Python 版本、CUDA 版本、PyTorch 版本之间稍微不匹配就会出各种莫名其妙的问题。用容器拆分开之后不同项目用不同的容器互不影响升级也方便。JetPack 系统自带 NVIDIA Container Toolkit可以直接拉取 NVIDIA 为 Jetson 平台发布的镜像。比如跑 PyTorch 的项目直接用官方发布的 PyTorch 容器镜像里面已经把对应版本的 CUDA、PyTorch、TorchVision 都配好了省去了自己编译的痛苦经历。给容器启一个带 GPU 加速的交互式环境命令大概是这样的sudo docker run --runtime nvidia -it --rm --network host \ -v /home/edge/project:/project nvcr.io/nvidia/pytorch:23.08-py3这套方式在 Xavier NX 上实测是非常稳定的。需要注意的是Jetson 的 Docker 镜像和 x86 平台的镜像是两套体系千万别把 x86 的镜像直接拉过来跑架构不匹配会报Exec format error。正确的镜像都是基于 ARM64 架构构建的。如果自己从 Dockerfile 构建镜像基础镜像也要选 ARM64 版本。4. 实际推理性能与应用落地4.1 常用模型在 Xavier NX 上的实测表现系统环境配好之后我把几个在工业场景里最常用的模型都用 TensorRT 做了一遍实测。这里我用的是 TensorRT FP16 精度输入分辨率按典型场景设定统计结果是设备在 20W 模式、环境温度 25 度、jtop 显示设备稳定的情况下跑出来的模型输入分辨率精度模式平均推理耗时说明YOLOv8n640x640TensorRT FP16约 16 毫秒目标检测轻量场景YOLOv8s640x640TensorRT FP16约 28 毫秒目标检测平衡型YOLOv8m640x640TensorRT FP16约 58 毫秒目标检测高精度ResNet18224x224TensorRT FP16约 3 毫秒图像分类ResNet50224x224TensorRT FP16约 9 毫秒图像分类MobileNetV3320x320TensorRT FP16约 4 毫秒轻量分类DeepLabV3 (MobileNetV2)512x512TensorRT FP16约 38 毫秒语义分割这组数据和其他平台对比起来很能说明问题。YOLOv8s 在 28 毫秒左右完成一帧检测换算下来每秒能处理 35 帧以上对于大多数产线质检和安防监控场景这个速度是足够的。关键是在这个性能水平下整机功耗只有二十瓦左右热量又低所以才能放进密封机柜里长期运行。对比一下如果我用普通工控机加独立显卡要跑到这个性能整机功耗至少一百瓦起步散热设计、电源容量、机柜体积都要上一个台阶。所以对很多固定安装的边缘视觉项目来说Xavier NX 级别算力配合工业级载板确实是最优解。4.2 TensorRT 加速的实践经验很多初学者在 Jetson 设备上直接跑 PyTorch 的原始模型性能非常差CPU 吃满但 GPU 利用率只有个位数。原因在于 PyTorch 默认的推理路径没有充分调用 TensorRT 的深度优化。在 Jetson 平台上做推理一定要走 TensorRT 这条路线。最常用的转换路径是先导出 ONNX 模型再用 TensorRT 自带的 trtexec 工具把 ONNX 转成 engine 文件。举个例子如果你的模型是 YOLOv8 的 PyTorch 权重先导出 ONNXyolo export modelyolov8n.pt formatonnx opset12然后宿主机上执行 TensorRT 转换Xavier NX 上 trtexec 的默认路径一般是/usr/src/tensorrt/bin/trtexec/usr/src/tensorrt/bin/trtexec \ --onnxyolov8n.onnx \ --saveEngineyolov8n.engine \ --fp16 \ --workspace2048转换完成后代码里就用 TensorRT 的 Python API 加载这个 engine 文件做推理不要直接跑 PyTorch 的 forward。这一步做完性能提升通常是几倍到十几倍。我用 YOLOv8n 实测PyTorch 原始推理在 Xavier NX 上大概一百多毫秒一帧TensorRT FP16 加速后直接降到十六毫秒左右。不过要注意一点FP16 精度虽然视觉上识别效果几乎无差别但对于某些对数值精度极其敏感的任务比如工业仪表读数识别还是建议做一次完整的精度验证。如果发现 FP16 下精度有明显下降可以退回到 FP32 模式代价是推理速度会下降一半左右或者采用 TensorRT 的 INT8 量化实测速度和精度都表现更好但需要准备校准数据集。4.3 一个完整的落地案例光伏组件缺陷检测拿这次最典型的光伏组件外观缺陷检测项目来具体说说。需求是检测光伏板表面的隐裂、断栅、脏污这三类缺陷产线节拍要求每块组件检测时间不超过四秒。相机用的是 1200 万像素工业相机架在流水线上方每次拍摄获取一张 3000 万像素级别的高清图像。整体架构是这样工业相机通过 USB 3.0 连接到 AIE110-XNX相机触发信号由 PLC 通过光电传感器给出设备跑 YOLOv8 模型做缺陷定位然后根据检测结果通过 DO 口输出分类信号控制后端的喷码机打标记。整个流程闭环都在设备本地完成不需要任何服务器参与。处理 3000 万像素的大图如果直接送进 YOLO 网络显存和计算量都是问题。我采用的方法是先对原图进行滑窗切割切成若干 640x640 的小图然后逐个送入 TensorRT 引擎推理最后合并结果。这样每个小图的推理耗时约 16 毫秒一张大图大概几十个窗口总耗时控制在两秒左右完全满足四秒的节拍要求。这个项目在现场跑了整整三个月设备温度稳定在六十度以下没有出现过一次死机或者推理超时。之前用普通设备遇到的死机、过热降频问题在这台设备上完全没有出现。这套硬件在这种高强度持续推理场景下稳定性的表现确实让人放心。5. 踩坑记录与排查技巧5.1 散热与降频问题第一次把设备装进密封机柜后我隔几天用 jtop 查看时发现设备温度长期徘徊在七十度以上频率被限制到较低的档位推理耗时比实验室环境多了将近一倍。排查下来发现机柜内没有加装散热风扇整个柜子简直是个烤箱。这个问题不是设备本身设计有缺陷而是安装环境的散热条件太差。解决方法不复杂给机柜加装了一个排气风扇确保空气能从进风口流向出风口再在设备外壳和机柜壁之间保留了至少五厘米的散热空间。改完之后设备温度降到了五十度左右性能恢复正常。如果你也遇到类似问题先别急着怀疑硬件检查一下设备周围有没有被其他发热设备包围散热通道有没有被堵住。长期高温运行不仅会触发频率限制还会加速电子元器件的老化这一点在工业现场特别要重视。5.2 供电电压波动引起的意外重启光伏车间里有大量的变频器和伺服电机电网污染非常严重。设备刚装上去的时候运行几个小时就会偶发重启没有任何规律。排查过程很痛苦最后还是摸到规律重启发生的时间点和大功率设备启停的时间点高度吻合。检查了设备的电源输入电压记录发现当车间大功率设备同时启动时直流母线上的电压会瞬间跌落低于设备的正常工作电压下限导致设备断电重启。解决方法是调整供电方案从同一个直流电源上单独拉一路给 AIE110 供电并在电源输入端加了一个容量比较大的电容做蓄能对短暂跌落起到了缓冲作用。另外检查了接地确认设备外壳和机柜的接地电阻没问题。整改后重启问题基本杜绝了。Kern.log 里记录到voltage drop相关的信息也是一个重要的排查线索。5.3 串口和 CAN 通信权限问题如果你要用 AIE110-XNX 和现场的 PLC、电机驱动器通信大概率会用到串口和 CAN 接口。Linux 系统下外设的访问权限是个很容易踩的坑。默认情况下普通用户访问/dev/ttyUSB0或者/dev/ttyTHS1经常会遇到Permission denied必须加 sudo 才能操作这个问题在现场调试时极其烦人。解决方案是把当前用户加入 dialout 组同时用 udev 规则固定设备节点的名称。比如你的 USB 转串口模块每次插入时设备名可能会在ttyUSB0和ttyUSB1之间跳来跳去写应用程序时就不能写死端口名需要用 udev 根据设备的 VID/PID 映射一个固定的符号链接比如/dev/plc1。CAN 接口也是一样先设置好波特率再打开sudo ip link set can0 up type can bitrate 500000 sudo ip link set can0 up5.4 常见问题速查表我把这几个月遇到的高频问题整理成了表格方便你排查现象可能原因处理办法推理速度越来越慢散热不良导致频率墙jtop 确认温度加装风扇或改善通风无规律重启供电电压跌落或接地不良检查供电线路单独供电改善接地摄像头无法识别USB 接口供电不足检查 USB 供电使用带独立供电的镜头接口开机后显示器无信号显示接口接错或系统未启动确认 HDMI/DP 接口选择正确检查指示灯状态串口读写报权限错误用户不在 dialout 组执行sudo usermod -aG dialout $USER并重新登录模型转换失败ONNX 导出 opset 版本过旧或过高检查 opset 版本使用官方推荐参数重新导出系统盘空间耗尽日志和容器镜像过多清理旧容器镜像定期清理日志文件设备 IP 变了连不上DHCP 获取到了新地址现场固定 IP配置静态地址这套速查表在项目交付时我同步整理给了运维同事之后现场出了问题他们能独立处理一半以上不用每次都远程找我。工业设备长期运行这种可运维性往往比参数本身更重要。最后再分享一个我自己养成的习惯新设备到手不要急着跑 demo先把系统、SDK、Docker 环境、监控工具全部配好做一次完整的温度压测和性能基准记录存档。后面项目上线后设备性能有波动翻出基线数据一对比问题在哪里立刻就有方向。这一步相当于给设备的健康状态留了个底稿省下来的可能是一整周的排查时间。
