最近帮朋友把一个宇树Go2的视觉感知模块从实验室原型搬到正式部署目标很明确在Jetson Orin上把YOLOv5目标检测模型跑起来而且要跑得够快、够稳能直接融入机器人的行为决策链路。这个项目前后折腾了小两周从刷机、配环境、训练模型到TensorRT加速再到和Go2的SDK打通中间趟过的坑比想象中多得多。很多问题网上答案零散甚至互相矛盾我觉得有必要把整个流程和踩坑记录写下来给正在做四足机器人视觉、边缘AI部署的朋友们一个完整的参考。这篇文章会覆盖硬件选型、JetPack刷机、PyTorch与YOLOv5环境配置、模型训练与转换、TensorRT部署、以及与宇树Go2实时对接的完整闭环。不管你是刚接触Jetson的小白还是已经踩过不少坑的开发者里面都有可以直接抄作业的内容。1. 项目思路为什么非要在边缘跑YOLOv51.1 先从设备选型说起宇树Go2作为一台消费级和科研级通吃的四足机器人本体自带的主控算力有限跑跑运动控制、SLAM轻量任务还行但要做到实时的目标检测、行人跟随、安全帽识别这类视觉任务算力明显不够。最常见的扩展方案就是外挂一台边缘计算设备Jetson Orin系列就是首选。Go2的扩展接口设计得比较开放机身预留了USB、网口以及供电接口主控与扩展设备可以走UDP或者共享内存通信。官方有开源的Unitree SDK和ROS2支持这意味着我们可以在Jetson上独立跑视觉推理然后把检测结果以Topic或者Socket方式发给Go2主控再由主控控制四足运动。这种“感知在边缘算、决策在主控做”的分层架构是当前四足机器人视觉落地的标准做法。关于Jetson Orin的型号很多人在选型阶段就犯了难。Orin Nano、Orin NX、AGX Orin三个产品线性能差距非常大价格也差了好几倍。我这次用的是Orin NX 16GB版本原因是它在性能、功耗、体积三者之间最均衡。如果你只是做原型验证Orin Nano 8GB勉强够用如果要跑多路相机或者提前预留大模型部署空间建议直接上AGX Orin 64GB。1.2 为什么选YOLOv5而不是其他目标检测模型目标检测模型非常多YOLO系列、SSD、Faster R-CNN、DETR等等各有优劣。在边缘部署这个约束下YOLOv5几乎是综合成本最低的选择。首先是部署生态成熟。YOLOv5从发布到现在经历了很多版本迭代官方仓库对Jetson平台的适配做得非常好不管是PyTorch导出ONNX还是TensorRT引擎都有现成的脚本。其次是模型体积和推理延迟可控YOLOv5s权重文件只有14MB左右FP16量化后在Orin NX上推理一张640×640的图单次推理时长能做到5毫秒级别这在机器人实时控制场景里是决定性的优势。第三是社区资源丰富遇到问题搜一下基本都有答案。当然YOLOv8甚至最新的YOLOv11检测精度和训练便捷性更强但从边缘部署的稳定性角度看YOLOv5的工程化程度最高Bug最少部署资料最多。这个项目追求的是“能稳跑”而不是“追新”所以我坚定不移地选了YOLOv5。2. 环境准备Jetson Orin刷机与版本矩阵2.1 刷机前你必须知道的一组版本关系Jetson上的深度学习环境和普通Linux服务器是完全两回事。普通服务器上你可以随意用Anaconda创建独立环境但在Jetson上因为底层库CUDA、cuDNN、TensorRT都跟随JetPack系统镜像一起锁定所以有一个严格的版本依赖关系。我这次用的JetPack版本是5.1.2对应L4TLinux for Tegra35.4.1默认系统是Ubuntu 20.04。之所以选5.1.2而不是最新的JetPack 6.x是因为当时测试下来JetPack 6系列对TensorRT的API改动比较大YOLOv5官方仓库的export脚本并没有第一时间兼容为了稳定性我选择了更保守的版本组合。下面是本次部署用的版本矩阵建议直接抄组件版本JetPack / L4T5.1.2 / 35.4.1系统Ubuntu 20.04 LTSCUDA11.4跟随JetPackcuDNN8.6跟随JetPackTensorRT8.5.2跟随JetPackPython3.8PyTorch2.0.0NVIDIA JetPack定制版torchvision0.15.0源码编译YOLOv57.0版本最新release这个矩阵踩过很多雷才定下来。尤其是PyTorch和torchvision的版本咬合如果从PyPI直接pip install torch torchvision出来的版本默认是没有针对Jetson的CUDA优化的甚至可能直接报CUDA不可用。Jetson上安装PyTorch必须使用NVIDIA官方发布的预编译wheel包。2.2 刷机过程中的三个大坑刷机这块我不想浓墨重彩写太多因为NVIDIA官方文档已经比较详细我只讲我实际遇到的、最容易让人崩溃的问题。第一个是电源功率不足导致的异常。Jetson Orin NX的功耗比较高如果供电不足会在系统高负载瞬间黑屏重启而且没有任何日志。我用的是官方推荐的19V电源适配器但一开始偷懒用了航模电池经DC-DC降压供电结果每次跑到模型加载环节就直接掉电。如果你也自己搭供电方案一定要确认电流余量留够至少是官方规格的1.5倍以上。第二个是SD卡镜像烧录完成后首次开机黑屏。这个问题的原因很复杂但最常见的就三种镜像损坏重新烧录、不支持显示器的分辨率换HDMI直连或者DP线、或者是系统初始化还没完成等待5到10分钟后再观察。针对“jetson orin nano启动后黑屏”这个高频问题我的建议是烧录完成后不要插SD卡直接开机先接好显示器和键鼠再上电系统首次启动会进行分区扩展和驱动加载需要一些耐心。第三个坑是SDK Manager刷机模式。如果你用的是带有预安装系统的NVMe固态或SD卡直接用Etcher烧录镜像就好不要去SDK Manager里执行全量刷机那会把整个系统重刷反而更容易在驱动安装环节卡住。我实验证明SD卡镜像方式最稳换NVMe固态作为系统盘的迁移方案后续再说。3. 搭建PyTorch与YOLOv5运行环境实录3.1 NVIDIA定制版PyTorch的安装细节在Jetson上安装PyTorch千万不要去pytorch.org下载通用Linux版本也不要直接在conda里创建新环境之后pip安装大概率会遇到CUDA不可用或者AVX指令不支持的诡异报错。正确姿势是从NVIDIA官方镜像仓库获取torch-2.0.0-cp38-cp38-linux_aarch64.whl文件这是专门为aarch64架构、JetPack 5.x平台编译的。安装命令很简单sudo apt-get update sudo apt-get install -y python3-pip libopenblas-base libopenmpi-dev libomp-dev pip install torch-2.0.0-cp38-cp38-linux_aarch64.whl注意这里不要加-U参数不要顺手把numpy、opencv这类依赖升级到最新否则很容易造成CUDA版本错位。实测下来Jetson系统自带的OpenCV 4.5.4是跟着JetPack走的老版本依赖的是系统Python3.6的某些库如果强行升级会牵连一堆传感器驱动出问题。安装完成后用下面这个命令快速验证CUDA和GPU是否正常import torch print(torch.__version__) print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))如果输出True和Orin表示环境正常。3.2 torchvision源码编译记torchvision的处理是整个环境搭建里最耗费时间的一步。PyPI上提供的torchvision二进制包不支持aarch64和Jetson的CUDA加速必须自己从源码编译并把TORCH_CUDA_ARCH_LIST设置为针对Orin架构的值。Orin系列的GPU架构是Ampere架构对应的计算能力是8.7。编译命令export TORCH_CUDA_ARCH_LIST8.7 git clone -b v0.15.0 --recursive https://github.com/pytorch/vision.git cd vision python setup.py install --user如果你用的是Orin Nano或AGX Orin计算能力同样都是8.7所以可以直接用这个参数。编译时间取决于设备负载我用完Orin NX满负载跑大约25分钟。这里有个血的教训编译期间不要开太多其他任务否则很容易因为内存不足直接报Killed然后又得重新编译。最好在编译前用jtop查看一下内存和Swap情况Jetson默认的ZRAM Swap在内存占用到70%以上时就开始吃不消了。3.3 YOLOv5源码准备YOLOv5的官方仓库托管在GitHub上直接拉取v7.0版本即可git clone --branch v7.0 https://github.com/ultralytics/yolov5.git cd yolov5 pip install -r requirements.txt这里有个重要提醒requirements.txt里会安装最新版的opencv-python、matplotlib、pandas等一堆包最新版的opencv会尝试卸载系统自带的老版本OpenCV。这在Jetson上会导致系统里依赖OpenCV的GStreamer插件异常尤其是摄像头读取会直接黑屏。我的解决方案是先安装requirements.txt里除opencv以外的所有依赖等所有东西都装好之后再单独安装一个不带CUDA支持的opencv到venv或者虚拟环境里。或者更简单一点直接用Jetson系统自带的OpenCV只需要在运行YOLOv5脚本前手动指定pip install -r requirements.txt --no-deps python detect.py --weights yolov5s.pt --source 0如果用到摄像头建议排查一下依赖冲突否则你会看到VIDEO0: failed to grab frame的报错这个不是硬件问题就是OpenCV/GStreamer的版本冲突。为了避免污染系统环境我强烈建议在Jetson上使用venv虚拟环境。实测venv完全兼容官方whl包后续安装ROS2网关时也不会互相干扰。很多新人习惯直接装到系统目录后面卸载升级时痛不欲生。4. 模型准备从官方权重到自己的数据集4.1 官方预训练权重与自定义数据集的取舍YOLOv5官方提供了在不同COCO数据集上预训练好的权重文件包括yolov5s.pt、yolov5m.pt、yolov5l.pt、yolov5x.pt。每个模型的大小和推理速度差异很大在Go2这种需要实时响应的场景我建议至少从yolov5s.pt起步如果你的检测目标类别过于复杂再考虑yolov5m.pt。但预训练权重只能识别COCO的80个类别人、车、猫狗等做安全帽识别之类特定场景时精度会惨不忍睹。这时候就需要用自己的数据集重新训练模型。热搜榜上的“yolov5安全帽数据集”就是这种场景的典型代表。数据集的组织方式是YOLO标注格式目录结构如下dataset/ ├── images/ │ ├── train/ │ └── val/ ├── labels/ │ ├── train/ │ └── val/ └── data.yaml其中data.yaml文件里写清楚训练验证图片路径、类别数量和类别名称。比如安全帽检测的任务配置文件是这样的train: dataset/images/train val: dataset/images/val nc: 2 names: [helmet, person]标注文件是txt文本每一行代表一个目标class_id center_x center_y width height坐标都是归一化到0-1之间的值这个格式用LabelImg或者Roboflow标注导出时都会自动生成。4.2 训练自己的数据集与超参数微调训练命令本身很简单python train.py --data dataset/data.yaml --weights yolov5s.pt --epochs 100 --batch-size 16 --img 640但训练过程中有几个超参数边缘部署场景下需要特别注意。--img参数决定输入分辨率。默认是640×640也可以改成416×416来换取更快的推理速度代价是检测小目标比如远距离的安全帽的精度下降。Go2按常规室内巡检的速度跑20米内的小目标其实不算特别小416也能用但你如果要做密集行人检测建议还是用640。--batch-size要结合GPU显存调整。Orin NX 16GB的显存训练YOLOv5sbatch size设16没问题如果是Orin Nano 8GB建议降到8或4。训练阶段显存溢出报错是家常便饭可以打开--cache参数缓存数据减少内存碎片python train.py --data dataset/data.yaml --weights yolov5s.pt --epochs 100 --batch-size 16 --img 640 --cache训练出来的权重会保存在runs/train/exp/weights/目录下包含best.pt和last.pt部署时肯定用best.pt。超参数文件YOLOv5也提供了很多预设都在data/hyps/目录下。默认的hyp.scratch-low.yaml是比较保守的方案在边缘设备上训练和部署都相对安全。如果你需要提高小目标检测能力可以调整hyp.scratch-med.yaml里的box、cls、cls_pw等参数但如果数据量不大很容易过拟合不建议新手乱调。想跑得更快配合--multi-scale做多尺度训练会让模型泛化性更好但也更吃显存。5. 部署的关键一步模型转换与TensorRT加速5.1 绕不开的TensorRT在Jetson上部署深度学习模型TensorRT几乎是绕不开的一环。PyTorch模型的原始推理速度太慢CPU上甚至没法做实时推理即便用GPU跑网络计算图里的很多冗余层没有被优化速度也只是将将能用。TensorRT做的事情就是对训练好的模型做计算图优化、层融合比如ConvBatchNorm激活函数融合成一个算子、精度校准FP16/INT8量化从而大幅提升推理速度和降低显存占用。实测对比数字最有说服力。同一个YOLOv5s模型在Orin NX 16GB上处理640×640输入推理方式平均延迟FPSPyTorch FP32 GPU推理约32ms约31PyTorch FP16 GPU推理约18ms约55TensorRT FP16推理约7ms约143这组数据说明TensorRT的优化绝不是玄学是肉眼可见的倍增级提升。对于Go2这种需要融合运动控制、传感器反馈的实时系统来说这大概是“能不能用”和“用得好不好”的区别。5.2 从PT权重导出TensorRT EngineYOLOv5官方仓库提供了非常方便的导出脚本只需要一条命令就能把.pt权重转换成TensorRT可用的.engine文件python export.py --weights best.pt --include engine --device 0 --half但这背后的原理值得了解一下。--include engine会依次完成pt → ONNX → TensorRT Engine的转换流程这个过程中涉及ONNX导出、解析器解析、网络构建和序列化存储几个阶段。如果中间任何一步出错排查起来都必须分步走。我在实际操作中遇到过两个高频报错。第一个是AssertionError: torch.onnx.export not supported说明PyTorch导出ONNX时模型有某些算子不支持遇到这种情况可以把YOLOv5升级到新版本或者给导出函数加--dynamic参数尝试动态输入。第二个是TensorRT在构建Engine时直接报OOM这是因为构建Engine阶段需要额外的显存空间解决办法是临时降低模型尺寸或者用命令行指定最大工作空间MAX_WORKSPACE_SIZE4GB python export.py --weights best.pt --include engine --device 0 --half--half参数的意思是开启FP16半精度。FP16量化后模型体积减半推理速度提升一倍精度损失通常极小对于安全帽、行人这类常见目标检测任务完全够用。至于INT8量化可以把模型压到更小但需要进行校准数据集和精度验证难度较大在YOLOv5s这种小模型上的性价比不高。6. 在Jetson Orin上把推理跑起来并与Go2对接6.1 推理脚本的工程化改造训练好的TensorRT Engine文件是没法直接用PyTorch代码来调用推理的我们需要用TensorRT的Python API来写一个推理引擎。YOLOv5官方仓库的detect.py支持直接推理.engine文件但如果要做工程化部署强烈建议自己封装一个推理类因为机器人项目里需要把检测框架嵌入到消息循环里。伪代码结构大概是这样的import tensorrt as trt import pycuda.driver as cuda class YOLOv5TRT(): def __init__(self, engine_path): self.logger trt.Logger(trt.Logger.WARNING) # 加载序列化engine文件 with open(engine_path, rb) as f: self.engine self.runtime.deserialize_cuda_engine(f.read()) self.context self.engine.create_execution_context() # 分配输入输出绑定缓冲 self.buffers [] for binding in self.engine: size trt.volume(self.engine.get_binding_shape(binding)) dtype trt.nptype(self.engine.get_binding_dtype(binding)) # 分配host端和device端内存 ... def infer(self, img): # 把img预处理成NCHW格式的float32/float16数组 # 拷贝到device buffer # 调用self.context.execute_async_v2 # 取回输出做NMS后处理 ...这里注意TensorRT的输入输出数据格式不是普通的NCHW float32在开启了FP16之后输入也可以直接给FP16数据省掉一层类型转换。另外execute_async_v2是异步推理需要配合CUDA Stream使用否则它跟同步的execute_v2在性能上没有本质区别。我在把这个模型集成到Go2的感知环路时遇到一个比较隐蔽的问题Jetson上的推理线程和图片采集线程如果都是纯PythonGIL锁会限制CPU多核利用导致帧率上不去。我的解决办法是用OpenCV的VideoCapture在自己的线程里抓帧然后丢到queue.Queue中推理线程从队列里取帧这样把I/O等待和推理计算解耦开。6.2 与宇树Go2的通信方式宇树Go2提供了两套常用的开发接口。一套是底层的unitree_sdk2通过UDP直连主控另一套是ROS2接口封装了更丰富的Topic和服务。实际部署中我优先推荐unitree_sdk2因为它的实时性最好与边缘推理的调度联动更方便。Go2主控默认的IP地址是192.168.123.18Jetson通过网线直连或连接同一个局域网交换机即可通信。通信的核心逻辑是这样的建立UDP套接字绑定Go2主控的IP和端口。持续订阅Go2的状态消息包括机身的IMU、关节角度、速度等。视觉推理线程把检测到的目标类别、置信度、边界框坐标打包成自定义消息结构体。通过unitree_sdk2的运动控制接口把目标信息与运动指令联动起来。比如检测到前方有行人距离小于安全阈值时下发减速停止指令检测到安全帽目标则下发跟踪指令以保持指定距离跟随。我这里做了一个简化的示意性代码不是完整的Go2控制代码只展示逻辑框架from unitree_sdk2py.core.channel import ChannelFactoryInitialize from unitree_sdk2py.idl.unitree_hg.msg.dds_ import LowCmd_ import numpy as np # 初始化通道 ChannelFactoryInitialize(0, eth0) # 假设已经有det_result [(cls, conf, bbox), ...] # 数据装配示例 low_cmd LowCmd_() if det_result is not None: obstacle_dist calculate_distance(det_result) if obstacle_dist 0.8: low_cmd.motor_cmd[0].q 0.0 # 这里只是示意真实控制要通过完整指令集真正跑起来的时候你会发现底层控制逻辑远比这个复杂因为还要做步态规划、姿态平衡、避障决策等。我的经验是把感知模块的控制意图输出为“高级指令”——比如停止、前进、左转、右转、跟踪目标而不是直接去控制某个关节的角度。这样既能充分利用Go2原有运动控制的能力也让自己视觉系统的扩展性更好。比如检测到人形目标后发布类似这样的结构化指令cmd { target_class: person, confidence: 0.92, center: (320, 240), box: (280, 200, 380, 310), action: follow, # stop / follow / evade / inspect timestamp: current_time_ms }Go2主控收到这个指令后只需要做一个布尔判断和优先级仲裁再加运动决策这种分层架构非常稳。6.3 端到端链路性能实测整条链路打通后我做了压测数据记录很能说明问题。在Orin NX 16GB上使用YOLOv5s 640输入、TensorRT FP16引擎开启异步推理环节耗时毫秒相机采集与预处理约8TensorRT推理单帧约7NMS后处理约3通信与指令下发约2总计约20这意味着系统可以跑到50FPS左右检测到的目标从看到到Go2开始动延迟在100毫秒以内人完全感觉不到延迟。在真实机器人系统中这个延迟水平已经达到了可用的标准。6.4 关于连接到宇树Go2相机的补充Go2的相机数据流有两种方式获取一种是直接读取Go2机身相机的RTSP流或ROS2图像Topic另一种是在Go2上外接一个USB相机或者Intel RealSense D435i深度相机通过USB线连接到Jetson Orin。我强烈建议在初期调试时采用外接相机的方案因为这样调试起来更简单不依赖于Go2主控的相机驱动是否兼容Jetson的GStreamer环境。等所有逻辑都调通之后再切换回Go2自带相机只需要把RTSP流地址换成Go2的IP地址即可。7. 高频踩坑与排雷手册7.1 启动黑屏、供电与常见硬件故障“Jetson Orin Nano启动后黑屏”这个热搜词背后其实是很多新手会遇到的通用问题。除了前面提到的电源问题、HDMI线材问题、首次启动初始化慢之外还有一种情况是NVMe固态硬盘里装过系统SD卡也存在另一个系统两者引导顺序冲突导致开机后黑屏或者反复重启。排查套路我总结了一个顺序看电源指示灯是否为正常绿色如果闪烁或变色优先怀疑供电。换一根HDMI线优先用DP转HDMI成功率更高。拔掉所有USB外设除了必须的鼠标键盘。长按电源键强制关机再重新上电。如果还不行换一张SD卡重新烧录系统。7.2 显存不足与OpenCV版本冲突Jetson的共享显存机制比较特殊GPU和CPU共享同一片物理内存可以通过/etc/nv_tegra_reduce_tegra_memory或者/etc/nvtuftmanager.conf来调整内存分配比例。如果推理时报CUDA out of memory除了降低batch size还可以调低系统为GPU预留的内存上限给推理循环留出更多空间。OpenCV版本冲突是我这次项目里最闹心的一个问题。YOLOv5的requirements.txt默认安装了opencv-python它直接覆盖了系统自带的OpenCV 4.5.4导致GStreamer插件无法正常加载。解决方法是安装时跳过OpenCV的自动安装并显式保留系统版本pip install -r requirements.txt --no-deps pip install numpy1.24.4 # 匹配python3.8 # 注意不要再装opencv-python如果你一定要用新版OpenCV请务必在虚拟环境内操作并在推理脚本最前面加一行检查cv2.getBuildInformation()确认当前加载的OpenCV是否带有GStreamer支持。7.3 推理速度不达标的性能定位很多人跑起来之后发现用的TensorRT engine推理速度还是很慢第一时间怀疑是TensorRT没配置好。但实际上大部分情况下瓶颈不在推理本身而在数据预处理和后处理。我的性能定位方法很简单在关键代码段前后打上time.perf_counter()时间戳分别统计图像采集、预处理resize、归一化、CHW、推理执行、NMS后处理的耗时。之前就遇到过一个案子预处理耗时达到15毫秒远远高于推理的7毫秒最终定位出来是OpenCV的cv2.resize()默认插值方法在高分辨率输入下计算量非常大改用INTER_LINEAR并配合固定尺寸输入之后预处理耗时降到了3毫秒以内。NMS后处理如果使用纯Python循环也会很慢一个常见优化技巧是先用torchvision.ops.nms或者改成向量化的方式处理可以节省好几毫秒。7.4 常见报错速查表报错现象可能原因解决方案AssertionError: Torch not compiled with CUDA enabled安装了官方PyTorch而非NVIDIA定制版重装NVIDIA版PyTorchFailed to find GStreamerOpenCV版本冲突或插件缺失恢复系统自带OpenCV或补装gstreamer相关库Unable to open camera 0相机权限或设备号冲突检查ls /dev/video*用v4l2-ctl --list-devices确认CUDA out of memory显存不足降低batch、调低输入分辨率、腾出GPU内存配额Bad file descriptor网络连接断了或IP不对检查Go2主控IP和端口确认网线接口eth0python: Killed内存不足触发OOM Killer加大Swap空间或减少并发任务Error parsing text-encoded ONNX fileONNX导出异常用--dynamic导出或用TensorRT的ONNX解析器单独调试7.5 一个从底层到上层的综合排查案例我分享一个完整的排查案例这个问题融合了多处踩坑。现象是在Jetson上跑推理脚本Go2偶尔会跟不上检测结果整机明显卡顿CPU占用率飙到90%以上。最开始以为是TensorRT推理太慢但时间戳统计显示单帧推理只要7毫秒瓶颈完全不在GPU。后来发现问题出在Python端的UDP消息发送上。unitree_sdk2在默认情况下是同步发送且发送频率完全跟随推理频率。当检测目标数量变多时每一帧都要把目标列表打包成字符串再走一次UDP这个序列化和发送过程阻塞了推理循环。我的解法是把“检测”和“发送”解耦新建一个独立线程专门负责把最新的检测结果缓存并周期性地发送给Go2主控推理线程只负责更新缓存。这样处理后CPU占用率降到30%左右整体帧率恢复稳定。这种“生产者-消费者”模式在机器人系统里几乎处处要用从图像采集到推理再从推理到通信层层解耦才是稳定性的关键。8. 项目总结与后续扩展思考做完这个项目后我感觉最大的收获不是把YOLOv5在Jetson上跑通这件事本身而是理解了整个边缘部署链路中“版本锁定”的重要性。在Jetson这种特殊环境里JetPack版本、CUDA版本、PyTorch版本、TensorRT版本、YOLOv5版本之间是一环扣一环的。安装任何东西之前先画出版本矩阵整个过程会顺畅很多。系统跑通之后我还在持续做一些扩展尝试。一个方向是探索YOLOv8和YOLOv11在Jetson上的部署核心思路完全一样只需要把模型导出部分的代码换成对应框架即可。另一个方向是把视觉检测结果与Go2的深度相机点云做融合这样就不会仅仅有2D的边界框还能得到目标的三维位置配合Go2的避障模块可以实现更智能的跟随、巡检和交互功能。另外很多人在考虑在Jetson上部署大语言模型比如在Orin Nano上跑Qwen其实这个思路和部署YOLOv5是类似的只是多了模型量化、显存占用和推理框架选型的问题。如果你已经有Jetson上YOLOv5的部署经验会发现接触Ollama、vLLM这类工具时上手速度非常快因为底层优化思路是相通的。最后说一句体己话这类边缘部署项目真正花在算法上的时间往往不超过三分之一剩下的时间都在和版本兼容、驱动、网络、供电这些问题打交道。当你被一个报错折磨到烦躁时不妨先把电脑合上理一遍版本矩阵和日志时间线大多数问题其实都有规律可循。坚持过去你会发现从零到一的这段路虽然泥泞却是成长最快的一段路。希望这篇实战记录能帮你少走一些弯路。