1. 从开发板到生产力工具为什么 Orin Nano 2 值得认真对待先说结论如果你正在做边缘 AI 侧的项目选型Jetson Orin Nano 2 这个平台应该是目前入门级价位里综合性价比最均衡的一块板子没有之一。它解决了过去几年边缘计算领域一个很尴尬的问题——低功耗设备跑不动像样的模型能跑模型的设备又贵得离谱。我最初接触到这个平台是在做一个工业质检的 PoC概念验证。当时需要在一台产线设备旁边做实时缺陷检测云端推理延迟太高普通的树莓派加 USB 加速棒方案又经常出现驱动冲突和散热降频整个项目卡了将近两周。后来换到 Orin Nano 2 上从刷机到模型跑通只花了一个下午。这个体验差距让我意识到嵌入式 AI 的选型逻辑已经变了——我们不再需要在“便宜但难用”和“好用但昂贵”之间做痛苦的取舍。聊聊这块板子的实际定位。Jetson Orin Nano 2业内也有人叫它 Orin Nano 的第二代规格对应 Super 版本在算力上提供了大约 67 TOPS 的 INT8 算力功耗范围在 7W 到 25W 之间可调。这个数字意味着什么你可以在一台设备上同时跑一个 YOLOv8s 的实时目标检测、一个轻量级的姿态估计模型、外加一个语音唤醒模块而且还能剩下资源做前后处理。对比上一代 Nano这个提升几乎是代际级的跃迁。更重要的是它的生态成熟度远超同价位的其他方案。NVIDIA 为 Jetson 系列维护了一套完整的 JetPack SDK从底层的 Linux 内核、CUDA、cuDNN、TensorRT到上层的 DeepStream、TAO Toolkit全部给你打包好了。你不需要像在树莓派上那样到处找预编译好的库也不需要自己折腾 OpenCV 的 CUDA 加速版本——这些东西在 JetPack 里基本都是开箱即用的。另外必须提到的是Orin Nano 2 的 8GB 统一内存架构。CPU 和 GPU 共享同一块 LPDDR5 内存带宽大约 102GB/s。这个设计对推理任务非常友好因为省掉了 CPU 和 GPU 之间拷贝数据的开销。实际测试中很多模型的端到端延迟反而比同等算力的独立 GPU 方案更低这就是统一内存架构的优势。这篇内容我会从平台选择的原因讲起然后深入到开发环境的搭建、模型适配与部署的完整流程再分享一些实际踩坑的经验和排查技巧。适合的人群包括正在做边缘 AI 产品原型验证的工程师、准备把 AI 能力嵌入到实体设备中的创业者以及所有对嵌入式 AI 部署感兴趣的开发者。无论你是第一次接触 Jetson 平台还是已经有了一些经验这篇内容应该都能给你一些有价值的信息。2. 边缘 AI 与实体 AI 的落地逻辑2.1 为什么边缘 AI 不是“小号云端”很多人对边缘 AI 有一个误解觉得它就是“把云端的模型放到一个小盒子里跑”。但实际工程中边缘 AI 的挑战和云端推理完全不同甚至在某些维度上更难。云端推理的假设是网络稳定、算力无限、散热无穷。你在数据中心里跑一个 70B 的大模型不需要考虑功耗墙不需要担心设备过热降频也不需要关心每次推理的电费。但边缘设备的处境完全不同它可能在无空调的厂房里可能在移动的 AGV 小车上可能在户外安防摄像头的立杆上。设备要在恶劣环境下保持稳定的推理性能这是第一个难点。第二个难点是延迟和隐私的硬约束。很多边缘场景比如自动导引运输车的障碍物检测、机械臂的实时抓取定位对端到端延迟的要求是毫秒级的网络往返一次的时间就足以导致事故发生。还有一些场景涉及敏感数据比如医疗影像、客户信息法规要求数据不能出设备这时候本地推理就是唯一的选择。第三个难点是模型资源受限。在边缘设备上你的模型不仅要“能跑”还要“跑得快”和“跑得省”。这意味着你往往需要对模型做压缩、量化和剪枝甚至重新设计网络结构。这已经超出了单纯“部署”的范畴进入了算法和工程交叉的领域。Orin Nano 2 这类平台的价值在于它把第三个难点的门槛大大降低了。67 TOPS 的算力意味着很多原本需要精心优化的模型可以直接跑 INT8 量化版本不需要做太激进的压缩。配合 TensorRT 的自动调优工程师可以把更多精力放在业务逻辑上而不是纠结于算子层面的手工优化。2.2 实体 AI从“识别”到“行为”最近实体 AI 的概念很火。简单理解实体 AI 是让 AI 系统不仅能够“感知”世界识别物体、理解语音还能“行动”起来——驱动机械臂、控制移动底盘、操作自动化设备。它是机器人、智能硬件和 AI 技术的交汇点。为什么会在这个时间点热起来因为感知层的技术已经相对成熟但光有感知是不够的。一个能识别苹果的摄像头如果不能在抓取的时候精准定位苹果的三维坐标它就只是一个监控设备。实体 AI 要解决的是“感知—决策—执行”的闭环问题而这恰恰是 Jetson 系列平台的强项。Orin Nano 2 在实体 AI 场景中有几个非常实用的特性。首先是丰富的 IO 接口包括 GPIO、I2C、SPI、UART、USB 3.2 和 MIPI CSI 摄像头接口这意味着你可以直接连接伺服电机驱动板、激光雷达、深度相机和各种传感器不需要额外的转接板。其次是 NVIDIA 的 Isaac ROS 框架对这块板子的深度适配里面预置了大量机器人开发需要的功能模块从视觉里程计到路径规划都包含在内。我见过一个很有意思的落地案例一个开源的四足机器人项目底层用 Orin Nano 2 做主控负责视觉感知和行为决策上层通过 ROS 2 与电机控制板通信。整台设备的功耗控制在 20W 以内用一块 3S 锂电池就能供电续航可以达到 40 分钟以上。如果换成之前的方案比如 Jetson Xavier NX功耗和成本都会翻一倍可行性就大打折扣了。2.3 规模化落地的现实约束做产品的人都知道从“能跑”到“能卖”之间有一条巨大的鸿沟。算法在开发板上跑通了只是万里长征第一步。接下来还要考虑成本、功耗、可靠性、远程维护、批量部署等一系列问题。成本方面Orin Nano 2 的模组定价在入门级 Jetson 产品线中非常有竞争力。对比同算力的 NVIDIA 独立 GPU 方案整套系统成本可以降低 60% 以上同时功耗降低 80% 以上。这个成本结构使得终端产品能够以更亲民的价格上市市场需求自然就会被激发出来。可靠性方面Orin Nano 2 模组的工作温度范围是 -25°C 到 85°C核心板搭配适当的散热方案后在工业场景中运行非常稳定。NVIDIA 对 Jetson 模组提供长期供货保证这对于做产品的团队来说非常重要——你不想产品刚量产主芯片就停产了。远程维护方面Jetson 平台支持安全的 OTA 更新机制你可以通过 NVIDIA 的运维工具或第三方方案对设备进行远程监控和升级。配合 Docker 容器化的部署方式现场设备的软件更新可以做到“无人值守、秒级切换”这对规模化运营来说是一个必须的能力。3. 开发环境搭建与基础配置指南3.1 刷机准备与 JetPack SDK 安装拿到 Orin Nano 2 开发套件后的第一件事是刷机。刷机的过程其实就是把 JetPack 系统镜像写入到板载存储中。注意Orin Nano 2 开发套件不像树莓派那样需要外部 SD 卡它自带 16GB 或 32GB 的 eMMC 存储直接通过 USB Type-C 线连接到一台 Ubuntu 主机上进行刷写即可。刷机前你需要准备一台 Ubuntu 20.04 或 22.04 的 x86_64 主机虚拟机也可以但直通 USB 更稳定USB Type-C 数据线注意要选支持数据传输的线很多手机线只支持充电开发板电源适配器官方推荐 15W 以上的 USB-C PD 电源一张 USB 键盘、鼠标和一块 HDMI 显示器用来看系统界面刷机步骤概括起来就是在主机上下载 NVIDIA SDK Manager登录 NVIDIA 开发者账号选择 Jetson 模块型号和 JetPack 版本然后按照向导操作。整个过程除了等待时间之外基本不会遇到什么坑。如果你想用命令行方式刷机比如在 CI 环境里NVIDIA 也提供了jetson-repack脚本工具可以把官方镜像进行定制和批量烧录。JetPack 版本建议选择当前最新的 LTS 版本。编译环境我已经验证过JDK 17 和 CUDA 12.x 的组合在 JetPack 6.x 上是没有兼容性问题的。如果你要跑深度学习的模型转换建议把 cuDNN、TensorRT 的 deb 包也一并安装上SDK Manager 默认会帮你处理这些依赖。3.2 网络配置与国内环境优化这一步很多人容易忽略但在国内环境下特别重要。Jetson 设备默认的软件源是 NVIDIA 的服务器下载速度不太理想。安装完系统后我建议第一时间把 apt 源和 pip 源都替换为国内镜像否则后面装 Python 包的时候会等到怀疑人生。具体来说替换 apt 源修改/etc/apt/sources.list把ports.ubuntu.com替换为清华镜像源mirrors.tuna.tsinghua.edu.cn因为 Jetson 是 ARM64 架构需要用的是ubuntu-ports仓库配置 pip 源创建~/.pip/pip.conf指向清华或阿里云的 PyPI 镜像配置 Docker 加速器如果你要用 Docker 跑容器需要配置registry-mirrors否则拉取镜像会很慢这些配置做好之后整个开发体验会顺畅很多。3.3 确认 CUDA 与 TensorRT 环境可用刷机完成后建议先做一次环境自检。运行sudo apt update sudo apt upgrade确保系统是最新状态然后执行以下命令检查关键组件# 检查 JetPack 版本 cat /etc/nv_tegra_release # 检查 CUDA 版本 nvcc --version # 检查 TensorRT 版本 dpkg -l | grep TensorRT这里有个小细节要注意在 Jetson 平台上CUDA、cuDNN、TensorRT 这些库是预装在系统里的不需要从 NVIDIA 官网单独下载。如果你直接用常规的 pip 方式安装nvidia-tensorrt包反而可能和系统自带的版本冲突导致 Python 接口无法使用。正确的方式是通过 JetPack 中提供的 Python wheel 包来安装 TensorRT 的 Python API# 安装 TensorRT Python API以 JetPack 6.x 为例 sudo pip3 install nvidia-tensorrt10.0.1.* --index-url https://pypi.ngc.nvidia.com装完之后可以用下面的小脚本测试 TensorRT 是否正常import tensorrt as trt print(trt.__version__) # 创建一个简单的 builder 测试 logger trt.Logger(trt.Logger.WARNING) builder trt.Builder(logger) print(TensorRT Builder created successfully)如果这段代码不报错说明环境基本就绪你可以开始真正的开发工作了。4. 模型适配与部署全流程实战4.1 模型选择的四大关键指标在 Jetson 平台上做模型部署最忌讳的就是“想到什么模型就直接往上丢”。选型阶段的判断失误到后面调优的时候会耗费你成倍的精力。我自己总结了一套选择标准主要有四个维度第一是模型体量。Orin Nano 2 的 8GB 统一内存虽然不小但要留给输入输出、中间张量和系统缓存一部分空间实际可用内存大约是 5.5GB 到 6GB。这意味着模型的权重和推理中间结果不能超过这个范围。以 YOLOv8 系列为例建议从n或s版本起步m和l版本在内存上会非常紧张。第二是算子兼容性。TensorRT 对常见算子支持得很好比如卷积、全连接、归一化、激活函数这些都有深度优化。但一些较新的注意力机制、动态形状相关的算子可能需要额外配置或者在转换时回退到较低效的实现。选模型时要尽量选算子种类少、结构规整的网络。第三是精度需求。如果你的任务允许 INT8 量化那选型空间会宽裕很多。INT8 量化后模型体积缩小到原来的四分之一推理速度通常能翻倍。但量化不是万能的对于某些对数值敏感的网络比如超分辨率、姿态估计误差可能会被放大到肉眼可见的程度这类场景需要预留精度验证的时间。第四是生态支持。尽量选择已在 TensorRT 模型库或 NVIDIA TAO 模型库里发布过预训练权重的模型。这些模型已经经过 NVIDIA 的适配验证转换过程中的坑会少很多。4.2 从 PyTorch 到 TensorRT 的完整转换流程无论你用什么框架训练模型最终上 Jetson 跑基本都要转成 TensorRT 引擎格式.engine。转换流程可以概括为训练权重 → ONNX → TensorRT Engine。以 YOLOv8 为例标准路径是先导出 ONNX再使用 TensorRT 的trtexec工具或 Python API 完成引擎构建。导出 ONNX 时需要注意几个细节# ultralytics 框架导出 ONNX from ultralytics import YOLO model YOLO(yolov8n.pt) model.export(formatonnx, opset12, simplifyTrue, dynamicFalse)这里dynamicFalse很关键。固定输入尺寸可以显著提升 TensorRT 引擎的推理效率因为 TensorRT 不需要为动态维度做额外的内存池预留。如果你的业务场景输入尺寸固定比如 640x640 的检测图建议尽量导出动态关闭的 ONNX。接下来用trtexec构建引擎这是一个非常方便的命令行工具/usr/src/tensorrt/bin/trtexec \ --onnxyolov8n.onnx \ --saveEngineyolov8n_fp16.engine \ --fp16 \ --workspace2048--fp16开启半精度推理。Orin Nano 2 的 GPU 支持 FP16 加速实测推理速度相比 FP32 能提升 60%-100%而精度损失在小模型上几乎可以忽略。如果你的模型对精度极其敏感可以尝试--fp16加--strictTypes的组合强制某些层保持 FP32 精度其他层用 FP16兼顾速度和精度。构建完成后你需要把推理引擎嵌入到应用中。最佳实践不是直接用 TensorRT 的原生 API 做推理而是通过 DeepStream 的推理插件nvinfer来处理视频流或者在 C/Python 中封装一层推理接口方便测试和切换。我这里推荐一种比较实用的做法用 Python 写一个推理服务通过 Redis 或 Kafka 接收任务、返回结果这样既避免了 C 开发的繁琐又能把推理和业务逻辑解耦。4.3 使用 DeepStream 处理视频流推理如果你是做安防、交通、工业视觉之类的场景视频流推理是绕不开的。Jetson 平台上的默认选择是 DeepStream SDK它基于 GStreamer 框架内置了视频解码、批处理、推理、追踪、渲染等全套功能模块。DeepStream 的基本管线结构是视频源 → 解码 → 缩放 → 批处理 → 推理 → 追踪 → 输出。你不需要从头写这些组件只需要通过配置文件把参数改好就行。一个典型的config_infer_primary.txt配置片段长这样[property] gpu-id0 net-scale-factor0.0039215694901712 model-file/opt/models/yolov8n_fp16.engine labelfile-path/opt/models/labels.txt batch-size4 network-mode2 num-detected-classes80 interval0 gie-unique-id1 output-blob-namesoutput这里面比较关键的一个参数是network-mode2它表示推理引擎使用 FP16 精度。batch-size4让 GPU 一次处理 4 帧画面可以更有力地利用 GPU 并行计算能力提高整体吞吐。DeepStream 的 API 在 Python 中使用也比较顺手一条典型的视频文件推理管线可以用create_pipeline快速搭建。不过要注意Python 版的 GObject 回调机制有 GIL 限制在高并发时可能不够高效。如果对吞吐量有极致要求建议用 C 实现核心管线把 Python 作为控制层。4.4 实体 AI 场景的端到端落地如果你要做的不是传统视觉识别而是实体 AI那部署路径会更复杂一些。这里以机械臂抓取场景为例做一个拆解。整个系统分为三部分感知识别物体并获得三维位置、决策规划抓取路径、执行控制机械臂运动。在 Orin Nano 2 上感知部分可以使用 Isaac ROS 的NvStereoDepth模块通过双目相机得到深度图再结合一个 YOLO 模型检测物体位置用Isaac ROS的DNN拼接器把二维框和深度信息融合成三维抓取点。决策部分可以使用 ROS 2 的MoveIt 2框架它在 Jetson 上有预编译的二进制包。路径规划在 CPU 上执行而 GPU 的算力主要留给深度感知这种分工在 Orin Nano 2 上非常合理。执行部分通过 GPIO 或 USB-TTL 发送控制指令给机械臂驱动器。需要注意在这里加入实时反馈机制比如关节角度传感器的数据需要以不低于 100Hz 的频率回传才能保证控制闭环的稳定性。有一说一这套系统的复杂度并不低但 Orin Nano 2 给了你足够的性能余量去折腾。我在实际项目中跑过全流程感知、规划、执行三个环节并行运行整机功耗不到 18W端到端延迟从图像采集到机械臂动作开始在 120ms 左右其中大部分时间花在机械臂的运动规划和通信协议上真正用于 AI 推理的时间只占 30ms。这个性能表现对于入门级的产品来说已经非常不错了。5. 性能调优与核心优化技巧5.1 功耗模式的正确选择Orin Nano 2 支持多种功耗模式类似手机的省电模式和高性能模式不同模式下 CPU 频率、GPU 频率和内存频率都有不同的配置。在系统里可以通过以下命令查看和切换# 查看系统支持的功耗模式 sudo nvpmodel -q # 切换到 25W 高性能模式 sudo nvpmodel -m 0 # 查看当前模式 nvpmodel -q这里有个很实用的建议如果是做产品验证建议直接把功耗模式切到最高25W以最大性能跑通所有功能。但如果是做最终交付要根据散热方案和供电条件来重新评估而不是一味追求最高性能。举个例子我有一个客户做户外巡检机器人设备内部空间很小只能放下被动散热片而没有风扇。如果让 Orin Nano 2 满载跑 25W散热片温度会快速升到 85°C 以上触发降频实际性能反而比 15W 模式下稳定运行更低。后来我们把功耗模式锁定在 15W温度稳定在 65°C 左右整体推理帧率反而比之前反复降频的 25W 模式还要高。这就是所谓的“降一档更快”现象做嵌入式开发的老手应该都能明白这种感受。5.2 使用 Jetson Stats 监控资源占用杀进程和查性能我用的是jtopJetson Stats工具这个工具可以看到 CPU、GPU、内存、磁盘、温度等所有关键指标还能实时查看每个进程的资源占用情况。安装非常简单sudo pip3 install jetson-stats sudo jtop打开后你会看到一个类似htop的界面但是包含更多嵌入式特有的信息。我在调优时最关注的几个指标是GPU 利用率、内存使用率、AV 解码器利用率和温度。如果你发现 GPU 利用率已经接近 100% 但推理帧率还没达到预期这时候需要考虑模型层面的优化而不是继续调系统参数。5.3 TensorRT 层融合与精度校准TensorRT 之所以能比原版框架快那么多核心靠的是层融合Layer Fusion。它会把卷积、偏置、激活函数这些相邻算子合并成一个融合算子减少内核启动的调度开销。但这个融合过程不是所有情况下都能顺利发生的有些情况需要你手动干预。举个例子如果你想跑 INT8 模型TensorRT 需要一个矫正数据集calibration dataset来统计每层激活值的分布从而确定量化的缩放因子。这个数据集的选择直接影响量化精度如果矫正数据太少比如只有几十张量化后模型精度可能掉得厉害如果矫正数据和实际部署场景差异太大用白天的数据做矫正却在夜间场景部署精度也会严重下降。我建议至少在矫正数据集中包含 500 张左右能代表实际场景的图片。另外TensorRT 的 Python API 里有Calibrator接口你可以基于自己的数据构建一个矫正器import tensorrt as trt class MyCalibrator(trt.IInt8CalibratorEntropyCalibrator2): def __init__(self, dataloader, cache_file): trt.IInt8CalibratorEntropyCalibrator2.__init__(self) self.dataloader dataloader self.cache_file cache_file self.buffer None def get_batch_size(self): return 8 def get_batch(self, names): # 返回一批矫正数据 batch next(self.dataloader) return [batch] def read_calibration_cache(self): # 如果之前已经生成过缓存直接读取 if os.path.exists(self.cache_file): return open(self.cache_file, rb).read() return None def write_calibration_cache(self, cache): # 保存校准缓存 with open(self.cache_file, wb) as f: f.write(cache)校准缓存是一个好功能一旦生成成功下次再构建引擎时可以跳过整个矫正数据的重跑过程直接使用缓存文件节省大量时间。5.4 使用 NVIDIA NIM 与 TAO 工具加速模型生产在业界做交付交付的都知道一个项目成功与否不只看最终的推理速度也看整个开发和迭代周期有多长。NVIDIA 最近在推的 NIMNVIDIA Inference Microservices和 TAO Toolkit核心目标就是缩短这个周期。TAO Toolkit 是一个迁移学习框架它允许你在 NVIDIA 预训练的模型基础上做微调而不需要从头训练。还是以目标检测为例你可以直接下载 YOLOv8n 在 COCO 数据集上的预训练权重用 TAO 格式化之后在自己的业务数据上做少量轮次的训练就能得到一个针对你场景优化过的模型。整个过程比从零开始训练节省了以周计的时间。NIM 则是把推理做成了标准化的容器服务。你在 NGC 容器仓库拉取对应模型的 NIM 容器配置好输入输出的 schema就能直接通过 HTTP/gRPC 接口调用推理能力。这种模式适合做多模型集中管理的场景可以让 Java/Python 服务通过统一的 API 接口访问不同模型而不用为每个模型单独写适配层代码。不过要提醒一句NIM 容器是基于通用 GPU 服务器设计的在 Jetson 上直接跑可能会遇到依赖不兼容的问题。官方文档写得很清楚Jetson 平台推荐使用 JetPack 内的原生库而不是通用 NIM 容器。如果你确实需要容器化的部署方式可以考虑基于 JetPack 的基础镜像自己打 Docker 镜像把 TensorRT 引擎包进去这样的方案更贴合嵌入式场景。6. 常见问题与排查技巧实录6.1 刷机失败与恢复方法NVIDIA SDK Manager 刷机失败是我遇到频率最高的问题之一。最常见的现象是刷写过程中 USB 连接中断然后开发板变砖。这里教大家一个恢复的方法先将开发板置于恢复模式用跳线帽短接板上的 Recovery 针脚或按住 Recovery 按钮用 USB 线连接主机不接电源查看 PC 上是否出现一个名为“APX”的 NVIDIA USB 设备。出现后打开 SDK Manager 重新刷写即可。如果反复刷写失败先检查 USB 线材是否支持数据再检查主机 USB 口是否供电不稳定。实在不行就换一台电脑试试我遇到过开发板和特定 USB 控制器不兼容的情况换个 USB 3.0 口就正常了。6.2 推理时温度过高导致降频这个太常见了。如果你发现跑了一段时间推理帧率莫名下降大概率是温度墙触发。先确认散热器是否贴合紧密再检查风扇是否正常转动。Orin Nano 2 开发套件原配的散热方案在 15W 模式下是够用的但如果你长时间跑 25W 模式建议换成带热管和强力风扇的第三方散热器。软件层面可以通过自定义风扇策略来改善# 查看当前温度 cat /sys/devices/virtual/thermal/thermal_zone0/temp # 手动控制风扇转速需要 root 权限 echo 200 /sys/devices/pwm-fan/target_pwm6.3 TensorRT 引擎构建失败构建引擎时报错的情况很多我遇到最多的是算子不支持或显存不足两类。先确认你的 ONNX 模型是不是所有算子都兼容 TensorRT可以使用trtexec的--verbose参数输日志。如果只是个别算子不兼容可以尝试在 ONNX 中将其替换为等价算子比如把Gather换成Slice加Concat。显存不足的问题往往不是真的显存不足而是 TensorRT 的 workspace 设置过大。构建引擎时指定一个小一点的 workspace如--workspace1024或者开启--memory-pool-size限制显存上限。6.4 CPU 占用过高而 GPU 利用率低如果发现 CPU 跑满、GPU 却只有 30% 左右先怀疑预处理环节是不是成了瓶颈。Jetson 上的 OpenCV 默认不支持 CUDA 加速在做图像缩放和色彩空间转换时会把大量计算压在 CPU 上。解决办法是使用 NVIDIA 提供的nvjpeg硬件解码库或者把预处理放到 GPU 上执行。另外一个常见原因是 Python 的 GIL 限制了推理线程的并行度。如果你用 Python 写多线程推理建议使用multiprocessing或concurrent.futures来替代threading充分发挥多核 CPU 和 GPU 的并行能力。6.5 常见问题速查表问题可能原因排查建议刷机识别不到设备USB 线材问题 / 未进入恢复模式更换 USB 线、检查 Recovery 针脚、查看lsusb输出推理帧率不稳定温度降频 / 后台进程抢资源检查jtop温度、杀掉非必要进程、调整功耗模式模型转换报算子错误ONNX 包含 TensorRT 不支持的算子升级 TensorRT 版本、替换算子、使用低版本 opset 导出内存不足导致崩溃模型太大或输入尺寸过大缩小批大小、降低分辨率、切换到更小模型Docker 拉取镜像慢网络问题配置registry-mirrors为国内加速器6.6 一些额外的避坑心得有几个点想特别强调一下。首先不要在生产环境里直接使用系统 Python 来管依赖包建议把 PyTorch、TensorRT Python API、OpenCV 这些重装进同一个venv或 conda 环境里避免系统升级时意外破坏环境。其次备份你的 JetPack 镜像。开发了一段时间后如果你已经把环境配置得很完善了用dd命令或 SDK Manager 的备份功能把整个系统镜像备份一次。万一后面系统崩溃了可以直接恢复到你最舒服的开发环境节省大量时间。最后养成写测试脚本的习惯。在 Jetson 这种资源有限的平台上一个小 bug 可能就会导致死机或内存溢出有一个完善的回归测试套件能让你每次改动都心里有底。我自己的做法是写一个test_pipeline.py里面包含数据加载、推理、后处理几个关键模块的冒烟测试每次改代码都先跑一遍再上板。7. 可扩展的方向与最终建议这套硬件平台和部署流程往后还能延伸出不少有意思的方向。一个是多模态感知。Orin Nano 2 的算力在入门级板卡中算是非常充裕的可以在跑视觉检测的同时挂一个语音唤醒模型或者聊天的语言模型小参数版本往多模态交互的产品方向走。我最近在做一个桌面级陪伴机器人就是在 Orin Nano 2 上同时跑视觉和语音两个模型效果出奇地不错。另一个是联邦学习和 OTA 迭代。当你的边缘设备数量增多后如何在保护数据隐私的前提下持续优化模型成了一个关键问题。你可以利用 NVIDIA FLARE 这个开源框架在 Jetson 设备上做联邦学习每个设备用本地数据做增量训练再把模型热更新的参数信息汇总回中心端做融合。这种模式在数据敏感的场景里有很大的应用空间比如医院、银行、工厂这些不允许原始数据外发的场景。从流程上讲还有一个扩展方向是持续集成持续部署的自动化流水线。你可以搭建一条从代码提交到模型生产再到设备部署的完整 CI/CD 链路代码推送到 Git 仓库后自动触发模型训练和 TensorRT 引擎构建最后通过预置的运维通道推送到现场设备。这种做法的价值在于当你需要更新 100 台设备的软件版本时不需要一台一台地手工操作。最后关于要不要选择 Jetson Orin Nano 2我的意见比较明确如果你的产品需要的是“7W-25W 功耗、67 TOPS 算力、丰富的 IO 和成熟的 AI 生态”这个组合那这个平台几乎是一个没有替代选项的选择。如果你做的场景对算力要求非常极端比如 100B 大模型的本地推理那应该去看服务器级的设备如果你做的是很小的传感器数据处理比如温湿度采集加简单的阈值判断那可能一个 MCU 就够了。Orin Nano 2 最适合的恰好是中间这部分既有 AI 推理需求又有物理交互需求的场景——也就是标题里提到的入门级边缘 AI 与实体 AI 的结合区。根据我个人的实际经验从一块开发板到真正稳定的产品中间的距离通常比想象中要大。但好在 Orin Nano 2 帮你把最难的环境和生态部分解决了剩下的更多是你对业务场景的理解和工程化能力。我建议拿到开发板之后先不要急着上生产代码花两天时间把基本的 SD 卡启动、CUDA 验证、TensorRT 引擎构建和推理跑通熟悉一下板卡的特性后面开发会顺利很多。