过年期间闲下来把近两年在Jetson平台上折腾AI项目的过程重新捋了一遍。从最早在Jetson Nano上跑通YOLOv5目标检测到后来在Orin NX上部署大模型和SLAM相关任务中间踩过的坑、总结出的套路其实都很固定。不少朋友问我Jetson平台AI开发到底要学哪些东西怎么从跑通demo进阶到能交付项目。这篇文章就围绕选型、环境初始化、模型部署、性能优化、稳定性排查这五块把我认为最核心的知识点串讲一遍。无论你是在校学生做毕设还是工程师做边缘计算产品选型这篇文章给出的都是能直接落地参考的经验。1. Jetson硬件选型不同型号之间的差距不只是算力很多人第一次接触Jetson习惯直接用官方那张TOPS算力图来选型。但实际做项目后你会发现单看算力远远不够内存带宽、显存容量、网络吞吐、散热设计每一项都可能成为瓶颈。1.1 型号定位与核心参数对比目前市面上主流的Jetson设备大致分为几个梯队。老牌的Jetson Nano2GB/4GB和TX2已经处于生命周期后期但二手市场保有量大很多教学项目还在用。真正值得重点关注的是Orin系列包括Jetson Orin Nano8GB、Jetson Orin NX8GB/16GB和Jetson AGX Orin32GB/64GB。我自己实际测试过的几个型号核心参数区别如下表型号GPU架构CUDA核心数内存内存带宽算力INT8稀疏典型功耗Jetson Nano 4GBMaxwell1284GB LPDDR425.6GB/s0.47 TOPS5W~10WJetson Orin Nano 8GBAmpere10248GB LPDDR568GB/s40 TOPS7W~15WJetson Orin NX 16GBAmpere204816GB LPDDR5102.4GB/s100 TOPS10W~25WJetson AGX Orin 64GBAmpere204864GB LPDDR5204.8GB/s275 TOPS15W~60W注意看内存带宽这一列。Jetson Nano的25.6GB/s带宽放到今天已经很难支撑稍微复杂一点的模型这也是为什么现在不建议再买Nano做新项目。Orin Nano的68GB/s带宽跑轻量级检测模型绰绰有余但如果你要部署7B级别的LLM8GB内存和68GB/s带宽就会非常吃力。Orin NX 16GB是我个人认为目前性价比最高的型号102.4GB/s的带宽配合16GB内存既能跑视觉模型也能用4bit量化方式跑中小规模大模型。AGX Orin 64GB则是真正能接近桌面级体验的设备适合做多模型并发或者需要大显存的场景。1.2 选型中容易被忽略的隐藏成本选型时还有三个容易被忽略的点。第一个是散热设计。Jetson Orin NX和AGX Orin在跑满负载时发热量很大官方散热套件只在开放环境下表现尚可一旦放进密封机箱很容易触发降频。我见过不止一个项目因为没考虑散热导致推理帧率从30FPS直接掉到个位数。如果产品是长时间高负载运行建议直接预留主动散热方案别指望被动散热能压住。第二个是存储。Jetson设备默认使用SD卡或NVMe SSD启动。SD卡在频繁读写日志和模型权重时寿命下降很快而且IO性能会直接影响推理时读取模型的速度以及训练时的数据加载效率。我现在的习惯是SD卡只用来做系统引导所有项目代码、数据集、模型文件全部放在外接SSD上。Orin系列开发套件都有M.2 Key M接口建议优先用PCIe Gen4的NVMe SSD性能差距感知非常明显。第三个是网络接口。AGX Orin Developer Kit自带千兆网口有些工业级载板还会集成2.5G网口或多个网口。如果项目涉及多路相机取流或者需要和上位机高频通信网口数量和速率比CPU性能更值得关注。Jetson Nano的老款载板只有一个千兆网口接相机和外网通信就需要USB转千兆网卡稳定性会差一些这也是老平台在实际项目中体验不佳的原因之一。2. 刷机与系统初始化JetPack版本的选择决定了后面所有环节Jetson的系统不像普通PC装Windows那么随意操作系统、CUDA、cuDNN、TensorRT是打包在一个叫JetPack的SDK里一起发布的。很多人前期忽略JetPack版本后面装Python依赖时出现一堆版本冲突根因往往是L4T内核和CUDA之间版本不匹配。2.1 JetPack、L4T、CUDA三者的绑定关系简单说L4TLinux for Tegra是Jetson的底层系统内核和用户空间基础JetPack是基于L4T之上的一整套SDK套件包含CUDA、cuDNN、TensorRT、DeepStream等组件。三者的版本是绑定的并不是说你想在Jetson Nano上装CUDA 12.4就能随便装。以Orin系列为例JetPack 5.x基于CUDA 11.4/11.8JetPack 6.x基于CUDA 12.2/12.6。如果你在JetPack 5.x环境下用PyTorch 2.0以后版本跑模型需要自己编译或寻找为L4T定制的wheel包直接pip install安装的x86_64版本是跑不了的。建议新项目全部使用JetPack 6.x也就是内置CUDA 12.x系列环境的版本。原因有两点一是最近两年NVIDIA官方以及社区预编译的PyTorch、ONNX Runtime、JAX的Jetson版本都以JetPack 6为主二是JetPack 6的驱动对Orin平台的新特性支持更完整例如DLA单元的初始化和TensorRT的版本兼容都做得更好。JetPack 5.x则可以作为老项目的兼容环境保留但新项目起步别选它。2.2 刷机流程的两种方式与关键参数给Jetson刷系统官方推荐用SDK Manager。SDK Manager会在x86主机上安装后通过USB线连接Jetson设备自动完成系统镜像烧录和SDK组件安装。这种方式最适合AGX Orin Developer Kit这种带USB Device口的产品。对于Orin Nano/NX这种使用SD卡或者NVMe启动的模块也可以用SDK Manager选择直接把系统烧到SD卡或NVMe里然后插到设备上启动不用每次都用USB线连接。手动烧写SD卡的流程也不复杂下载官方镜像压缩包后用balenaEtcher烧录到格式化好的SD卡首次开机进入系统后再用SDK Manager或命令行安装剩余SDK组件。这种方式的好处是快缺点是你需要自己管理依赖版本。初始化完成后别忘了做三件事。第一件事是检查运行模式sudo nvpmodel -m 0 # 0为最大性能模式在Orin系列上通常对应15W/25W/40W等不同档位 sudo jetson_clocks # 锁定CPU/GPU最高频率防止降频影响测试结果第二件事是确认基础环境nvcc -V # 查看CUDA版本 dpkg -l | grep TensorRT # 查看TensorRT版本 sudo apt-cache show nvidia-jetpack | grep Version # 查看JetPack版本第三件事是设置开机默认的电源模式并把nvpmodel服务设为自启动。如果不做这一步设备重启后可能退回低功耗模式导致推理性能大幅波动。这一点在交付项目时特别重要很多客户反馈重启后变慢八成就是默认电源模式没设置好。2.3 启动黑屏问题十有八九是电源和显示器兼容性热搜词里有jetson orin nano 启动后黑屏这个问题我在群里被人问了无数次。绝大多数情况不是板子坏了而是下面几个原因。电源不足排在第一位。Jetson Orin Nano的Developer Kit需要USB-C PD供电官方要求15W~25W功率的电源适配器有些劣质电源标注支持20W但实际电流输出不稳定开机瞬间电流拉不上去就会黑屏或者循环重启。判断方法很简单看电源适配器标签上的电流值USB-C PD模式下建议选20V/3.25A这个档位。如果是Orin NX模块配合第三方载板一定要查载板说明书确认需要的是12V还是5V供电电压搞错了有烧板子的风险。显示器兼容性排在第二位。Jetson的HDMI输出对部分4K显示器或特定分辨率支持不佳表现就是开机后指示灯正常但屏幕一直黑着。遇到这种情况先换一块1080P显示器试试或者用DP口输出。我遇到过Orin NX接某品牌4K显示器黑屏但换了一台老款1080P显示器后一切正常的情况属于驱动层面的兼容性瑕疵。还有一个容易忽视的点SD卡接触不良。插SD卡的瞬间如果没插到位开机自检过不去主板上的绿色指示灯会不亮或者闪烁。重新拔插SD卡听到咔哒声到位后再开机能解决一部分黑屏。如果以上都排查过了仍然黑屏可以接串口线看启动日志。Jetson的Developer Kit排针上有UART调试口用USB转TTL小板连接后在主机上用minicom或screen打开串口能看到内核启动到哪一步崩了——这比蒙着猜靠谱得多。能走到串口日志这一步排障思路基本就入了门。3. 视觉推理链路的完整搭建以YOLOv5在Jetson上的部署为例Jetson平台上最经典的任务就是目标检测。YOLOv5因为生态成熟、教程多、PyTorch权重转ONNX和TensorRT的资料齐全适合作为第一个跑通的完整项目。这个链路走通之后换成YOLOv8、YOLOv9或者自定义模型套路基本一致。3.1 从PyTorch到TensorRT模型转换的完整流程在Jetson上部署YOLOv5推荐路径是PyTorch模型先转ONNX再转TensorRT engine。有人会问为什么不直接用PyTorch做推理Jetson上PyTorch推理走的是CUDA性能其实能用但TensorRT在推理速度上通常有1.5倍到3倍的提升而且INT8量化后还能更快。对于边缘设备来说这差别可能就是能用和好用的距离。先说一下ONNX转TensorRT的方式。YOLOv5官方仓库里已有现成的export.py支持直接导出TorchScript、ONNX甚至TensorRT enginepython export.py --weights yolov5s.pt --include onnx engine --device 0 --half这里有个容易踩的坑直接在Jetson上用export.py导出engine走的是TensorRT Python API过程中极容易出现Dynamic shape设定的问题。因为YOLOv5默认的推理shape是动态的而TensorRT在构建engine时要固定最小、常规、最大三档shape。如果不指定默认可能是[1, 3, 640, 640]这种固定尺寸后续摄像头输入尺寸不同就会报错。更稳妥的做法是先导出ONNX再使用trtexec命令手动构建enginetrtexec --onnxyolov5s.onnx --saveEngineyolov5s_fp16.engine --fp16 --minShapesimages:1x3x640x640 --optShapesimages:1x3x640x640 --maxShapesimages:1x3x640x640trtexec是TensorRT自带的命令行工具用它可以方便地测试不同batch size、精度模式下的性能。也有人使用TensorRT的Python API构建engine灵活度更高但前期调试不如trtexec直观。3.2 推理脚本的改造不能直接套用桌面端代码拿到engine文件后推理代码不能直接套用桌面端的YOLOv5检测脚本因为engine的后处理部分需要自己处理。YOLOv5的TensorRT输出通常是一个[batch, 25200, 85]的张量25200是三个尺度预测框的总数85是box(4) objectness(1) class probabilities(80)。你需要自己解析这个张量做NMS非极大值抑制再把box坐标缩放到原图尺寸。这个解析过程很容易出错。我建议是直接参考YOLOv5仓库里utils/general.py的non_max_suppression函数自己实现一个纯TensorRT版本的NMS算子。Jetson的TensorRT支持EfficientNMS插件但版本之间API有变化前期为了跑通直接用PyTorch的NMS逻辑配合NumPy处理也未尝不可只是速度会稍慢顺畅跑通后再换成插件。在Jetson上有两个提升推理速度的额外手段第一个是启用CUDA Stream。TensorRT推理默认是同步模式意味着推理期间CPU在等待GPU计算完成。使用多线程或者CUDA Stream可以让图像预处理和推理重叠实际吞吐量能提升20%到40%。我的做法是开两个线程一个线程负责从摄像头拉流和图像预处理另一个线程负责推理中间用队列做缓冲。数据送到GPU显存之后把预处理和推理放进同一个CUDA Stream里减少host和device之间同步次数。第二个是使用内存池。反复调用TensorRT引擎时会频繁分配显存Jetson上显存和内存共享频繁的分配/释放会引入内存碎片。正确做法是engine构建时设置setMemoryPoolLimit给激活张量指定一个初始显存池运行时复用这块空间。3.3 实测性能对比FP16与INT8的使用场景用YOLOv5s在Jetson Orin NX 16GB上做了一组对比实验输入尺寸640x640情况如下推理方式平均延迟帧率单路相对PyTorch提升PyTorch FP32约19ms52FPS1xONNX Runtime FP32约15ms66FPS1.27xTensorRT FP16约6ms166FPS3.19xTensorRT INT8约4ms250FPS4.8x对大多数目标检测场景FP16已经够用精度损失在1%以内完全可接受。INT8需要额外准备校准数据集如果校准集和实际场景差异大会出现精度抖动例如漏检率偏高。我的建议是做产品优先用FP16推理速度不够再考虑INT8而且要准备500张以上能覆盖真实场景的校准图片不能随便抓几张图凑数。3.4 部署时的版本匹配问题YOLOv5部署中频繁出现的报错有一大半来自PyTorch、TorchVision、TensorRT的版本不匹配。Jetson上安装PyTorch建议使用NVIDIA官方发布的JetPack对应版本。JetPack 6.x对应的PyTorch wheel在NVIDIA论坛和官网Index中有提供不要从PyTorch官网直接下载x86_64包安装。判断当前PyTorch是否为Jetson对应版本可以在Python里执行import torch print(torch.__version__) print(torch.cuda.is_available()) print(torch.version.cuda)如果torch.cuda.is_available()返回False大概率装了CPU版本。如果是True但报算子不支持的错检查torch.version.cuda是否和nvcc -V的CUDA版本一致。Jetson上这两个版本不一致也是在所难免的事情最省事的办法是重新从NVIDIA官方渠道安装匹配的wheel包。为了不再被这块坑到我现在会把常用的PyTorch wheel下载后存放在本地换设备时直接安装省得每次都在网上翻找。4. 大模型和SLAM类任务上Jetson从Ollama跑Qwen到资源分配今年明显感觉到越来越多的Jetson项目开始把大语言模型部署到边缘设备上典型需求是语音助手、本地知识库问答、农业领域的边缘问答系统。同时无人机和机器人领域的视觉SLAM类任务比如热词里提到的AirSLAM Jetson部署也在Jetson平台上有不少实践。这两类任务和传统视觉检测相比资源分配逻辑差别很大。4.1 如何在Jetson Orin Nano/NX上跑Qwen在Jetson上部署Qwen这类大模型最简单的方式是使用Ollama。Ollama原生支持Jetson的CUDA加速安装后能自动识别GPU并利用JetPack环境。JetPack 6.x上的安装非常简单curl -fsSL https://ollama.com/install.sh | sh ollama run qwen2.5:7b但是注意Orin Nano 8GB直接跑7B模型默认会用Q4_K_M量化依然可能出现上下文较长时内存不足。跑大模型之前我建议先做一次内存和交换空间检查free -h # 查看内存和swap空间 cat /proc/meminfo | grep -E MemTotal|SwapTotal8GB内存的Orin Nano在跑7B模型时建议把上下文长度限制在2048以内。实测如果开4096上下文生成过程中显存的峰值会显著上升一旦超过物理内存系统就会疯狂swap速度从每秒20 token掉到每秒3 token左右几乎不可用。16GB的Orin NX则可以从容很多能跑7B模型加2048上下文同时还有余量做另一路视觉推理。如果Ollama跑Qwen7B速度不够满意可以换用更小的qwen2.5:3b或者qwen2.5:1.5b。3B模型在Orin NX上能跑到每秒40~60 token在Orin Nano上也有20~30 token用于对话和摘要完全够用。另外需要做残差量化切换时Ollama的GGUF模型文件也可以直接用ollama run配合OLLAMA_MODEL环境变量指定路径把模型放在SSD上能明显减少加载时间。4.2 SLAM类任务在Jetson上的部署要点我实际接触过的视觉SLAM部署项目最痛的点是实时性。AirSLAM这类基于视觉惯性导航的算法需要做特征提取、位姿估计、回环检测这些在x86 CPU上通过多核并行能跑下来但到了Jetson上如果不对GPU加速帧率很容易撑不住10FPS。部署SLAM类任务我的经验是先分清楚哪些模块是CPU密集、哪些是GPU可加速的。特征提取和描述子计算通常可以换成GPU版本比如使用Orb-SLAM的CUDA变体或者用TensorRT加速SuperPoint/SuperGlue这类深度学习特征模型。位姿优化和回环检测基本还是CPU任务Jetson的CPU在高负载下为了保GPU频率会限频所以需要在JetPack里配置CPU核心数和调度策略。Orin NX有8个Core的Cortex-A78AE我在部署时会把特征提取线程绑定到CPU4-7把后端优化线程绑定到CPU0-3避免线程频繁迁移造成缓存失效。内存占用也需要提前规划。SLAM通常需要保存历史关键帧的位姿、地图点和描述子长时间运行内存会线性增长。在Jetson上跑SLAM常采用两种手段控制内存一是设置滑动窗口只保留最近N帧关键帧超过就丢弃二是使用DBoW2词袋模型做回环检测同时不断压缩地图点数量。AirSLAM这类算法本身有内存管理机制但在部署时还是要做足压力测试防止长时间运行后内存耗尽导致进程被杀。4.3 多任务并发时的资源分配思路很多无人车和机器人项目并不只是单一模型的任务。一台Jetson Orin NX可能需要同时跑目标检测、语义分割、大模型语音交互、SLAM定位。这时候资源分配就是一个系统级设计问题。我常用的分配策略如下将GPU的CUDA核心和内存划分为多个上下文每个任务使用独立的CUDA Stream。不要把所有任务塞进同一个TensorRT上下文否则调度抖动会很大。CPU端使用taskset绑定核心对于周期性任务如SLAM设置实时优先级但要注意不要把CPU完全跑满留15%的余量给系统进程。内存方面需要预先统计每个任务的峰值内存如果总和超过物理内存就要做取舍例如将大模型量化进一步降低到3B级别或者降低检测模型输入分辨率。JetPack 6还提供了NVIDIA的nvpps工具NVIDIA Performance Profiling System可以监控每个进程的CPU、GPU、显存使用情况。部署前先用nvpps跑一轮压力测试找出哪个任务吃掉最多资源再针对性地优化比盲目改代码有效得多。5. TensorRT量化与推理优化把硬件性能榨干的关键前面提到FP16和INT8但真正想把Jetson硬件性能榨干光靠TensorRT自动优化是不够的。你还需要理解TensorRT的工作原理、量化方式以及如何从算法层面消减开销。5.1 TensorRT为什么能加速图层融合与内核自动调优TensorRT加速的核心有两个方向图层融合和内核自动调优。图层融合是指把多个连续的计算步骤合并成单一算子典型的是把ConvBatchNormReLU融合成一个CBR算子减少kernel启动和显存读写的开销。对于ResNet这类结构规整的模型融合后的网络可以减少30%到50%的运行节点。内核自动调优是TensorRT为每个算子选择最优的实现同一个卷积操作Tactics中可能有几十种不同的cuDNN/自定义kernel实现TensorRT会在构建engine时逐一评估挑选出当前shape下延迟最低的方案。这也是为什么TensorRT构建engine的时间往往很长因为它相当于在做一次穷举搜索。这个机制也解释了为什么TensorRT对固定输入shape的效果最好。如果输入shape频繁变化TensorRT不得不为多个shape保留多个kernel实现显存占用上升部分场景下反而比动态shape优化前更慢。5.2 INT8量化的完整流程校准数据决定精度TensorRT的INT8量化并不是直接把FP32权重收缩成8位整数那么简单它默认采用后训练量化PTQ需要一个校准步骤来统计激活值的分布范围然后据此计算量化缩放因子。命令行方式trtexec --onnxmodel.onnx --saveEnginemodel_int8.engine --int8 --calibcalibration.cache其中calibration.cache是校准缓存文件需要提前通过TensorRT Python API生成import tensorrt as trt def get_calibrator(calib_data): return trt.IInt8LegacyCalibrator(calib_data) # 构建INT8 engine时传入calibratorTensorRT会遍历校准集 # 计算每个激活张量的min/max或直方图分布生成calibration cache校准数据的选择是INT8量化成败的核心。一定不能只用ImageNet的自然图片对于工业检测场景要用你实际拍摄的生产环境图片且最好能覆盖光照变化、目标遮挡、背景多样性。我用YOLOv5s做过实验用500张检测工位实拍图校准的INT8模型mAP0.5只下降了1.2%但如果用自然图片校准同样模型在工位场景下的漏检率会翻倍。校准图片数量一般在100到1000张之间。太少统计不准太多校准时间过长且收益递减。校准完成后生成的cache文件要保留下次构建engine可以直接复用不必重新校准。5.3 常见的TensorRT精度与速度问题排查构建engine时会遇到性能不符合预期的情况。常见原因有两个第一个是动态shape把优化范围拉大了。如果minShapes和maxShapes跨度太大TensorRT会为每个范围生成多套优化导致engine体积变大推理速度可能反而下降。解决办法是尽量固定输入尺寸或者缩小动态范围。对于视频检测任务完全可以固定分辨率只在模型输入的预处理里做letterbox。第二个是batch size设置。TensorRT在batch size1时对算子做了深度优化但如果你的业务场景需要GPU满负荷试试batch大小设置为2或4。这里有一个平衡增大batch会提升吞吐量但单帧延迟会上升。实时视频流场景更关注延迟所以batch size1往往是正确的选择离线批量处理场景更关注吞吐可以适当增大batch。我习惯在构建engine后先用trtexec测一遍延迟曲线trtexec --loadEnginemodel_fp16.engine --shapesimages:1x3x640x640 --duration10如果平均延迟异常高再回头检查输入shape设定和是否启用了DLA。DLADeep Learning Accelerator是Orin系列保留的专用加速单元可以运行部分算子但只支持很少的算子类型如果是自定义算子或特殊层放到DLA上反而会拖慢。默认情况下把DLA留给固定结构CNN网络的部分层使用动态结构网络建议完全关闭DLA。5.4 DeepStream与高效后处理视觉项目中如果存在多路视频流可以考虑使用DeepStream框架。DeepStream是基于GStreamer和TensorRT构建的多路视频分析框架它能帮你管理多路流的硬件解码NVDEC、批处理、推理和编码输出。Jetson平台上硬解H.264/H.265的能力非常强Orin NX能同时解码20路以上1080P视频流这是CPU解码完全做不到的。不少人在单路摄像头项目里强行引入DeepStream反而是过度设计。DeepStream适合摄像头路数较多4路以上且需要统一管线的场景。如果只做单路或双路检测自己用GStreamer拉流加GstRtspOverlay等插件拼一条Pipeline可能更灵活。6. 稳定性与排障从启动黑屏到运行卡顿的排查思路最后这部分是实际交付项目时最容易被忽视、也最影响用户体验的环节。Jetson毕竟不是数据中心里的服务器供电、散热、存储都会在长时间运行时暴露问题。6.1 从电源到风扇运行不稳定的常见根因我在多个项目里遇到过同样的现象设备刚开机一切正常跑几分钟后帧率下降、风扇猛转甚至死机。排查思路按优先级排列先看温度再看电源。查看温度和功耗状态sudo tegrastatstegrastats输出里的CPU [email protected]和GPU [email protected]是当前实时的CPU和GPU占用率RAM项显示内存使用情况AO32C和GPU45C分别是各传感器温度。如果GPU温度超过85°C降频是必然的需要从散热层面解决。Jetson Orin NX在载板上有风扇接口BIOS中默认风扇策略可能偏保守可以用jetson-clocks配合自定义风扇控制脚本让温度超过60°C时自动拉满风扇转速。电源不稳的表现更隐蔽。Jetson设备在峰值功耗时如果电源输出电流不够电压会跌落系统表现为随机重启、USB设备认不到、模型推理突然中断。官网对每个型号都标了推荐的电源规格Orin Nano建议20WOrin NX建议25W以上AGX Orin根据负载可能要到60W。我建议直接买功率余量充足的电源例如给Orin NX配一台60W氮化镓适配器电压跌落的风险会小很多。6.2 Swap与文件系统长时间运行的内存问题Jetson的8GB/16GB内存在AI任务中非常容易紧张。如果内存不够Linux内核会触发OOM Killer直接杀掉占用最高的进程。这是部署大模型时进程莫名消失的头号原因。缓解方案有两种。第一种是加大swap空间官方推荐在NVMe SSD上创建swap文件sudo fallocate -l 8G /mnt/ssd/swapfile sudo chmod 600 /mnt/ssd/swapfile sudo mkswap /mnt/ssd/swapfile sudo swapon /mnt/ssd/swapfile注意swap不能放在SD卡上否则频繁交换会加速SD卡损坏。第二种是使用ZRAM。Jetson的Ubuntu系统在较新版本中默认启用了zram它利用压缩算法在内存中虚拟出更多空间。但ZRAM对CPU有额外消耗如果CPU已经满负载ZRAM会导致推理延迟上升。建议根据实际负载权衡我通常在纯推理场景用swap不用ZRAM在跑大模型场景两者都开启并把swap优先级调低。文件系统方面还有一个经验Jetson的eMMC或SD卡不宜长期写入高频率日志。生产环境建议将日志输出到tmpfs内存文件系统或者外接SSD上的指定分区并且启用logrotate做日志轮转否则一年半载后系统盘写满设备表现会越来越慢。6.3 开机自启与异常恢复机制交付设备时开机自启是必须做的。我的方案是编写一个systemd服务负责拉起AI推理主程序并配置自动重启[Unit] DescriptionAI Inference Service Afternetwork.target [Service] ExecStart/home/user/start_inference.sh Restartalways RestartSec5 [Install] WantedBymulti-user.target启动脚本里还需要检查GPU和关键服务状态比如等待Ollama服务就绪后再启动推理程序避免因依赖未启动导致崩溃。如果主程序发生段错误或OOM被杀systemd的Restartalways会自动拉起这对无人值守设备非常关键。再高级一点的做法是添加看门狗。Jetson支持硬件看门狗触发复位可以在系统无响应时自动重启。开启方式是把/etc/systemd/system.conf的RuntimeWatchdogSec设为30秒左右。这只用于兜底正常情况下程序卡死还是优先用systemd的进程级重启。6.4 一套实用的首轮排障清单结合我自己的使用经验Jetson设备出问题时按下面这个顺序排查效率最高指示灯状态。正常启动时电源灯常亮活动指示灯闪烁。如果灯不亮先排除电源线和适配器。串口日志。接上USB转TTL观察内核启动的最后输出是停在U-Boot、内核还是文件系统挂载。tegrastats观察温度、功耗、内存。查看内核日志dmesg | tail -50OOM、驱动加载失败、i2c错误都会在这里。查看systemd服务状态systemctl --failed。最后再看应用日志。这套顺序能把大部分玄学问题定位到具体层面避免重复刷系统。如果你是用Jetson做AI应用开发的新手我的建议是先把手上的板子按这篇文章梳理的链路完整走一遍——选型参考、刷JetPack 6、跑一个YOLOv5的TensorRT推理、再用Ollama跑通一个小模型。这个过程走完你对Jetson平台的核心知识就建立了体系感。后续遇到新模型新框架本质上都是在往这个框架里填细节。面试也好做项目也罢能讲清楚为什么在Jetson上要用TensorRT而不是纯PyTorch、为什么INT8需要校准集、启动黑屏如何排查就已经比大多数只在桌面端写过AI代码的开发者有优势了。有一点我在多个项目里反复验证过Jetson平台开发最大的壁垒不是模型算法本身而是对整个软硬件链路的把控能力。你能不能让模型在功耗约束下稳定跑起来能不能在内存紧张时保证长期运行不崩这才是边缘AI开发真正考验人的地方。把这篇串讲里的每个环节都亲手跑一遍你会少走很多弯路。
