过去一个月我一直在折腾一套移动机械臂的视觉抓取方案，设备从树莓派换到x86工控机，最后落在了NVIDIA Jetson Orin Nano上。朋友问我为什么选这个，我说得很直接：入门级边缘AI设备里，它把算力、功耗、价格和生态这几个关键维度平衡得最好。尤其是Orin Nano Super发布之后，16GB内存、最高67 TOPS算力、25瓦以内的功耗，直接把实体AI（Physical AI）项目的落地门槛拉下来一大截。
这篇文章我不会去复述官方规格书，而是从实际项目出发，聊聊为什么这个平台适合入门级边缘AI和实体AI规模化落地，怎么把环境搭起来、把模型跑起来，以及我在过程中踩过的坑。无论你是准备入坑机器人、打算给产线加装视觉检测，还是单纯想在移动设备上跑大模型推理，这篇文章都能给你一个相对完整的参考。
1. 为什么Orin Nano 2是入门级边缘AI的“甜点位”
1.1 从参数看定位：算力、功耗、价格三者如何平衡
先说硬指标。Jetson Orin Nano系列最新的Super模式把AI算力推到了67 TOPS（INT8稀疏），内存也从8GB提升到16GB LPDDR5，带宽从68GB/s涨到102GB/s。这是一个很微妙的分界线：在它之前，入门级设备要么是树莓派这种算力只有个位数TOPS的板子，要么是动辄几万块的工业级GPU设备。Orin Nano刚好卡在中间，让你能以两三千块的成本拿到一块能跑现代深度学习模型的完整计算平台。
功耗方面，Super模式下满载大约25瓦，默认模式下7到15瓦。这意味着它不需要额外的主动散热方案就能稳定运行，工业场景里塞进密封机箱也没问题。我用一个12V 5A的电源供一台带摄像头、激光雷达和机械臂控制板的整机，实测下来还有超过20%的余量。这种能效比是x86方案很难做到的，也是它在实体AI场景里受欢迎的根本原因。
接口方面，它提供PCIe、USB 3.2、MIPI CSI相机接口、千兆网口和40Pin GPIO，基本覆盖了机器人、视觉检测和边缘网关的常见需求。尤其是MIPI CSI接口，可以直接接全局曝光工业相机，延迟比USB摄像头低一个量级。加上支持NVMe SSD启动，系统的IO瓶颈也能得到缓解，这对跑大模型和数据库类应用都有实际帮助。
1.2 实体AI为什么需要这种“小盒子”
实体AI，或者叫Physical AI，简单说就是让AI系统能在物理世界中感知、决策、行动。机械臂抓取、AGV导航、无人机巡检、产线缺陷检测，这些都属于实体AI的范畴。这类场景有一个共同特点：计算必须发生在设备本地，不能依赖云端。原因有三个，第一是延迟，机械臂的抓取动作从相机取帧到发出控制指令，端到端延迟必须控制在几十毫秒以内，走云端来回一趟就超时了；第二是带宽，多路工业相机每秒产生几百兆数据，全传到云端不现实；第三是隐私和可靠性，很多产线数据不能出车间，网络断连的时候设备也必须能独立工作。
但本地方案也有历史难题。工控机加独立显卡的方案性能足够，但体积大、功耗高、价格贵，一个机械臂项目光计算单元就要一两万。树莓派之类的方案便宜省电，但跑不动现代模型，一张640x640分辨率的YOLOv8推理都要几百毫秒，根本做不到实时。Orin Nano的出现恰好补上了这个缺口：性能能达到实时推理的要求，功耗能承受，价格也到了个人开发者和中小团队能接受的范围。
我做了个简单的对比，目前主流方案的实际情况大致是这样的：
| 方案 | 算力（INT8） | 功耗 | 参考价格 | 适合场景 |
|---|---|---|---|---|
| 树莓派5 | 0.5 TOPS左右 | 5-10W | 500元左右 | 原型验证、轻量控制 |
| Jetson Orin Nano Super | 67 TOPS | 7-25W | 2500元左右 | 入门级边缘AI、机器人、视觉检测 |
| Jetson Orin NX | 100-157 TOPS | 10-25W | 6000-8000元 | 多路视觉、SLAM、更复杂的AI负载 |
| x86工控机+RTX显卡 | 几十到上百TOPS | 150W+ | 1.5万元以上 | 传统视觉、GPU通用计算 |
从这个表能看出来，Orin Nano 2的定位非常精准。它不是性能最强的，也不是最便宜的，但它在“能实时跑AI模型”和“个人/小团队买得起”这两个条件之间找到了平衡点，这也是为什么它在入门级边缘AI和实体AI项目里被反复提及。
2. 环境搭建：刷机、驱动与系统调优
2.1 刷机与启动：SDK Manager和SD卡镜像两条路
拿到板子第一件事是把系统刷进去。Jetson平台有两种主流刷机方式，我两种都试过，说下各自的特点。
第一种是NVIDIA官方推荐的SDK Manager，适合有Ubuntu主机（x86环境）的情况。它会自动下载JetPack SDK，把系统镜像、CUDA、cuDNN、TensorRT、DeepStream这些组件一次装好。整个流程是：板子进入Force Recovery模式（按住Recovery键再通电），用USB线连接主机，SDK Manager识别到设备后选择要安装的组件和版本，然后自动写系统、自动安装SDK。这种方式最省心，不容易出错，第一次玩Jetson的人建议直接用这个。
第二种是直接烧录SD卡镜像，适合Windows用户或者不想装SDK Manager的情况。到NVIDIA官方下载JetPack对应的SD卡镜像文件，用balenaEtcher或Rufus把镜像写到至少64GB的高质量SD卡里，插入板子启动即可。启动后系统自带CUDA和TensorRT，但不包含DeepStream等额外组件，需要手动用SDK Manager补装，或者用apt命令安装。这个方式的优点是快，缺点是缺少SDK Manager的组件管理功能，后续增删组件比较麻烦。
刷完系统开机之后，第一件事是确认版本对应关系。在终端执行：
cat /etc/nv_tegra_release nvcc --version/etc/nv_tegra_release显示的是L4T（Linux for Tegra）版本，nvcc --version显示CUDA版本。这两个版本必须和JetPack版本匹配，比如JetPack 6.x对应CUDA 12.x和L4T 36.x。如果后面安装第三方库时出现编译错误，八成就是版本对应关系出了问题。建议把这三者的对应关系记到项目README里，省得过几个月回来维护时抓瞎。
首次启动还有一个必做的操作：把系统迁移到NVMe SSD。SD卡的随机读写性能太差，跑大型模型加载权重或者读写日志时会明显卡顿。做法是用dd命令把SD卡系统克隆到NVMe硬盘，或者直接用SDK Manager选择“Storage Device”为NVMe重新刷写。我用的是后者，刷完后系统启动时间从40多秒缩短到了15秒左右，模型加载时间也提升了近一倍。如果你要在板子上做正经项目，这一步真不建议省。
2.2 驱动验证：Jetson上到底怎么确认GPU能用
很多从PC转型过来的朋友习惯性地先查“nvidia-smi”，结果在Jetson上发现直接报错，就开始怀疑驱动没装好。其实Jetson的GPU驱动跟PC是完全不同的体系。Jetson底层使用的是集成在L4T内核里的NVIDIA GPU驱动，不需要像台式机那样单独安装.deb驱动包，也没有独立的nvidia-smi输出格式（至少默认情况下是不同的）。
在Jetson上确认GPU工作状态，用的是Jetson特有的工具。最常用的是：
sudo jetson_clocks sudo tegrastatstegrastats命令会实时输出CPU/GPU频率、内存使用、温度、功耗这些信息，相当于Jetson版的“任务管理器”。如果你在终端看到类似GPU 1300MHz、CPU 4@2457MHz这样的输出，就说明GPU驱动和频率调度都正常工作。jetson_clocks的作用是把CPU和GPU频率锁定在最高值，避免系统在轻载时自动降频导致推理速度不稳定。在需要跑基准测试或者保证推理延迟稳定时，这个命令非常有用。
还有一个容易踩坑的点是CUDA Sample的验证。很多人想跑一下deviceQuery确认GPU可用，但编译会报错。原因是新版JetPack里CUDA Sample不再预装源码，需要手动从GitHub拉取：
git clone https://github.com/NVIDIA/cuda-samples.git cd cuda-samples/Samples/1_Utilities/deviceQuery make ./deviceQuery如果deviceQuery能正常显示你的GPU型号（Orin Nano的GPU一般是Ampere架构），说明CUDA环境没问题。看到类似CUDA Device Query ... PASSED的输出，就可以放心继续往下走了。
2.3 三大必备调优：性能模式、SWAP和存储清理
系统跑起来之后，有三个调优动作我建议每个Orin Nano用户都做一遍，都是影响实际使用体验的关键项。
第一，设置性能模式。默认情况下系统跑在15瓦的功耗档，Super模式需要手动开启。执行：
sudo nvpmodel -m 0-m 0对应Super模式（25瓦），-m 1是15瓦模式，-m 2是7瓦模式。改完用nvpmodel -q确认当前模式。注意，Super模式对散热有要求，如果你的板子是裸奔状态，最好加一个主动散热风扇再开，否则芯片在重载时过热降频，实际性能反而比15瓦模式更差。我在实测中发现，25瓦模式下如果散热不良，跑推理任务时温度会迅速冲到80度以上，然后频率从最高值掉下来，整个推理速度反而波动很大。加了5V风扇之后温度稳定在60度左右，推理帧率就非常稳定了。
第二，扩展SWAP。项目后面跑多路摄像头或者大模型时，16GB内存很可能被吃满。这时候SWAP如果太小会导致OOM（内存耗尽）被杀进程。Jetson默认提供了zram，但压缩后的交换空间只有大约3GB，不够用。推荐的做法是在NVMe SSD上做一个8到16GB的swapfile：
sudo fallocate -l 12G /mnt/ssd/swapfile sudo chmod 600 /mnt/ssd/swapfile sudo mkswap /mnt/ssd/swapfile sudo swapon /mnt/ssd/swapfile为了重启后自动挂载，还要在/etc/fstab里加一行。这个操作能显著减少OOM概率，代价是SSD使用寿命和略微的性能下降，但在实战中非常划算。我用的是三星980 500GB，开机加载模型时系统内存占用经常到17GB左右，没有大SWAP根本跑不起来。
第三，清理JetPack预装组件。JetPack默认安装了非常多的库和示例代码，很多是日常用不到的。比如/opt/nvidia/vpi下的样例、/usr/src/tensorrt下的示例代码等。清理前先看清楚哪些是你需要的，我从不建议新手一上来就删组件，但等系统稳定后，可以把apt list --installed里的非必要包筛一遍，尤其是那些占用几个GB的示例和文档。空间有限的小容量SSD用户做这个清理能多出不少余量。
3. 模型部署工作流：从x86训练到Jetson推理
3.1 模型导出与量化：ONNX到TensorRT的关键跳板
在Jetson上部署深度学习模型，最绕不开的环节就是TensorRT。简单理解，TensorRT是NVIDIA的推理优化引擎，它能把训练框架产出的模型做层融合、精度校准、内核自动调优，最终生成一个高度优化的推理引擎。同样的YOLOv8模型，在PyTorch里跑一次推理可能需要60毫秒，用TensorRT优化后能压到20毫秒以内，提速效果非常明显。
但TensorRT不能直接吃PyTorch的权重文件，需要通过ONNX作为中间格式。整个链路是：
PyTorch模型 → 导出ONNX → ONNX优化 → TensorRT引擎构建 → 推理
以YOLOv8为例，导出ONNX的操作在训练主机上完成：
yolo export model=yolov8n.pt format=onnx opset=13 simplify=True dynamic=False有几个导出参数要注意。opset版本会影响算子兼容性，Jetson上JetPack 6自带的TensorRT 10对ONNX opset 13到17都能支持，建议用13以上。dynamic=False表示固定输入尺寸，尺寸固定对TensorRT构建引擎更友好，性能也更高。我建议在部署阶段把所有输入分辨率固定下来，比如统一用640x640，不要图省事保留动态尺寸。
拿到ONNX文件之后，有两种方式转TensorRT。第一种是直接用trtexec命令行工具：
/usr/src/tensorrt/bin/trtexec --onnx=yolov8n.onnx --saveEngine=yolov8n.engine --fp16--fp16启用半精度推理，这是性价比最高的一步。在Ampere架构上，FP16的算力是FP32的两倍，而精度损失对视觉检测任务来说基本可以忽略。如果用INT8量化还能再进一步提速，但需要准备校准数据集，流程相对复杂，新手可以先跳过。
第二种方式是用Python API在代码里动态构建引擎：
import tensorrt as trt logger = trt.Logger(trt.Logger.WARNING) builder = trt.Builder(logger) network = builder.create_network(1 << int(trt.NetworkDefinitionCreationFlag.EXPLICIT_BATCH)) parser = trt.OnnxParser(network, logger) with open("yolov8n.onnx", "rb") as f: parser.parse(f.read()) config = builder.create_builder_config() config.set_flag(trt.BuilderFlag.FP16) config.set_memory_pool_limit(trt.MemoryPoolType.WORKSPACE, 1 << 30) engine = builder.build_engine(network, config) with open("yolov8n.engine", "wb") as f: f.write(engine.serialize())第一次构建引擎时耗时可能比较长，几秒到几分钟不等，之后再加载序列化的.engine文件就很快了。我在板子上构建YOLOv8n的FP16引擎大约花了20秒，加载只需要不到1秒。
3.2 推理框架选择：直接用TensorRT还是套一层推理库
很多初学者在部署时会纠结一个问题：到底是用原生TensorRT API写推理代码，还是用DeepStream、ONNX Runtime、TorchScript这些上层方案。我的建议分场景。
如果你做的是以摄像头视频流为主的应用，比如缺陷检测、安防监控、客流统计，直接用DeepStream最合适。DeepStream是NVIDIA官方的视频流分析框架，它把视频解码、批处理、推理、目标跟踪、物体分类这些环节都封装好了，在Jetson上用硬件解码单元做视频解码，CPU占用率极低。我在一个检测项目中用DeepStream跑四路1080p视频流，CPU占用只有30%左右，这在原生TensorRT方案里很难做到。
如果你的应用不是视频流，而是单帧图片、雷达点云或者其他传感器数据，用原生TensorRT或者ONNX Runtime就够了。ONNX Runtime相对简单，代码量少，适合快速验证。我把YOLOv8转成ONNX后，在Jetson上用ONNX Runtime加CUDA Execution Provider推理，速度大约42毫秒每帧，这个速度适合非实时任务。但同样的模型转到TensorRT FP16后只需要11毫秒，差距确实很大。所以只要是追求实时性能的场景，我都推荐直接用TensorRT。
PyTorch的TorchScript方案我不太推荐。虽然Jetson上能装PyTorch，但Python解释器的开销在边缘设备上会被放大，推理速度和TensorRT不是一个量级。我的经验是，PyTorch用来做“CPU上的后处理和业务逻辑”可以，真正吃性能的推理环节一定要落到TensorRT引擎上。
3.3 NIM与容器化部署：把边缘AI服务化
近几年NVIDIA在推NIM（NVIDIA Inference Microservice），在Jetson平台上也逐步支持。用一句话概括，NIM就是把常见模型的推理服务打包成标准容器，通过HTTP/GRPC接口对外提供服务。这样做的最大好处是：你的应用代码和推理引擎解耦了。模型迭代时，只替换NIM容器镜像，不需要重新编译整个应用。
我搭过一个基于NIM的视觉检测服务，大致是这样的流程。先在Jetson上安装NVIDIA Container Toolkit：
sudo apt-get install nvidia-container-toolkit sudo systemctl restart docker然后拉取对应的NIM容器镜像，启动容器时指定使用GPU和映射端口，应用侧直接通过HTTP请求发送图片，拿到检测结果。这种方式特别适合多人协作的项目：算法同学负责训练和优化模型，嵌入式同学负责业务逻辑和传感器接入，两者通过接口对接，互不阻塞。
容器化还能解决环境依赖问题。Jetson上Python环境极其容易搞乱，我见过不止一个人在Jetson上重装系统，原因就是把conda环境搞崩了，导致系统Python也被影响。用Docker隔离后，宿主机环境可以保持干净，出问题直接销毁容器重建就行。不过要注意映射GPU时用--gpus all参数，Jetson上Docker的GPU支持依赖nvidia-container-toolkit，如果容器内看不到GPU，先查这个包是否正常安装。
4. 实体AI落地案例与规模化实践
4.1 一个机械臂视觉抓取项目的典型架构
我最近帮朋友做的是一个桌面机械臂的视觉抓取项目，硬件包括一台Orin Nano Super、一个USB工业相机、一台六自由度机械臂（通过串口控制）。任务是把传送带上的零件识别出来，通过机械臂抓取到指定位置。这个项目非常有代表性，算是实体AI入门级落地的经典组合。
整体软件架构分成四层。第一层是感知层，相机每100毫秒采集一帧图像，送到TensorRT引擎做目标检测和位姿估计；第二层是决策层，根据检测结果计算目标的三维坐标，通过标定把像素坐标转换成机械臂基座坐标系下的空间坐标；第三层是控制层，把目标坐标转换成机械臂的关节角度，通过串口下发指令；第四层是反馈层，机械臂夹爪上的传感器检测是否抓取成功，失败则触发重试逻辑。
在Orin Nano上跑这个流程，感知层的检测延迟大约15毫秒，决策层计算大约5毫秒，控制层机械臂动作一般需要200到500毫秒，所以整体瓶颈在机械臂本体而不在计算平台。这也说明了为什么Orin Nano这种级别的算力对入门级实体AI项目已经足够。如果换成检测模型更大的YOLOv8s，推理时间会到40毫秒左右，依然在可接受范围内。
这个项目里最有价值的经验是坐标系标定。很多新手在机械臂抓取项目里翻车，不是模型精度不够，而是像素坐标到空间坐标的变换没做好。我的做法是先用棋盘格标定相机内参，再做手眼标定（相机安装在机械臂外，是“眼在外”模式），把变换矩阵保存下来，在决策层直接用矩阵运算完成坐标变换。整个过程用OpenCV的calibrateCamera和solvePnP就能实现，不需要额外的标定设备。
4.2 多机部署与远程管理：规模化落地的关键一步
当你的边缘AI项目从一个设备扩展到几十台甚至上百台时，单机SSH管理的方式就不现实了。每台设备手动更新模型、手动改配置，不仅效率低，而且极容易出错。我第二次部署项目时就吃了这个亏，用了整整两天在十几台板子上重复刷模型，结果发现有两台的模型版本漏更新了，产线上跑的还是旧版本。
后来我采用了容器加轻量编排的方案。每台Jetson上安装Docker，用K3s作为集群管理工具，模型和业务应用都打包成镜像，通过中央仓库统一分发版本。更新模型时，只需要重新构建镜像并推送给K3s，它会自动滚动更新所有节点。这个方案在几十台设备的规模下非常稳定，我用它管理过一个18台Orin Nano的集群，跑了一个多季度没出过版本混乱的问题。
还有一个容易忽略的点是设备监控。我遇到过一台设备因为风扇停转导致芯片过热，推理性能跌了一半，但系统并没有崩溃，线上业务还在跑，只是追帧越来越严重。后来我在每台设备上加了一个轻量监控脚本，定期采集tegrastats的关键指标，包括温度、CPU/GPU占用率、内存余量，上报到中央服务端，设置温度超过75度就触发告警短信。这样的小工具成本很低，但对规模化维护帮助巨大。
4.3 数据回流与持续迭代：让边缘AI越用越准
实体AI项目上线只是开始，模型在真实环境里的表现大概率低于实验环境，持续迭代是必然的。这里的关键是数据回流。我在机械臂项目里做了一个简单但实用的闭环：推理阶段把低置信度的检测结果和对应的原始图像自动保存到本地缓冲区，每天通过定时任务压缩上传到训练服务器；算法同学定期用这些难例数据训练新模型，验证精度提升后发布新版本，再通过K3s推送到设备端。整个周期从原来的一周缩短到一天，模型的性能提升非常明显。
在Jetson上做数据回流的硬件要求不高，重点是存储策略。我建议在NVMe SSD上单独划一个目录存放原始数据，每天压缩上传后清理，避免SD卡或小容量SSD被塞满。另外，上传数据必须脱敏，去掉个人信息和敏感区域，避免数据合规风险。Orin Nano的带宽虽然不大，但上传典型的难例数据（每天几百MB）完全没有问题。
5. 常见问题速查与避坑技巧实录
5.1 驱动与容器运行时：最容易被卡住的两个环节
Jetson开发中遇到的坑，很大一部分集中在驱动和容器运行时。先说一个非常典型的问题：在x86 Ubuntu主机上卸载重装NVIDIA驱动后，重启时偶尔会看到类似“an nvidia kernel module 'nvidia-uvm' appears to be already loaded in your kernel”的提示。这个问题的本质是模块没有完全卸载干净。解决方法是进安全模式或字符界面，先执行sudo rmmod nvidia-uvm nvidia-drm nvidia-modeset nvidia，把旧的模块全部卸载，再重新安装驱动。如果rmmod提示模块正被占用，用lsof查一下是哪个进程在使用GPU，关掉进程再卸载。
另一个高频问题是nvidia-smi报错has failed because it couldn't communicate with the nvidia driver。这个错误在PC和Jetson上含义略有不同。在PC上，基本可以确定是驱动和内核版本不匹配，常见原因是系统内核升级后驱动没有跟着重新编译。解决办法是安装对应内核版本的headers，然后重新执行sudo dkms install -m nvidia -v <版本号>，或者干脆用--no-opengl-files重新装一遍驱动。在Jetson上如果遇到这个报错，一般不是驱动缺失，而是当前环境里根本没有加载GPU模块，执行sudo modprobe nvidia-uvm再验证即可。
容器相关的坑也很多。最常见的是Docker容器里跑程序报找不到GPU，但宿主机GPU明明正常。这通常是因为容器没有注入GPU设备，启动容器时没有加--gpus all参数，或者宿主机缺少nvidia-container-toolkit。有时候nvidia-container-toolkit装了但Docker运行时没有重启，也需要执行sudo systemctl restart docker才能生效。还有个别情况是JetPack版本和容器镜像的CUDA版本不匹配，比如JetPack 6自带的CUDA 12.x容器跑了CUDA 11.x的镜像，大概率会报libcudart.so找不到，重新选择匹配版本即可。
5.2 性能与散热：为什么你的Orin Nano跑不满
很多用户看网上评测说Orin Nano Super能跑到67 TOPS，自己实测跑模型却只有一半性能，第一个反应是“买到假货”。其实大概率是散热和功耗设置的问题。
先说散热。Super模式（25瓦）持续满载时，芯片功耗密度很高，如果只靠被动散热片，温度会迅速攀升到85度以上，然后触发频率下调。我在机械臂项目里一开始用自带的小散热片，跑模型十几分钟后GPU频率从1.3GHz掉到800MHz左右，推理延迟直接翻倍。换成5V主动风扇加加厚散热片之后，温度稳定在60度附近，帧率曲线变得非常平滑。如果你的设备要长时间满载运行，散热设计绝对是第一优先级。
其次是频率策略。jetson_clocks会把CPU和GPU频率锁到最高，但有些版本的JetPack里，运行jetson_clocks后如果系统进入低负载状态，频率依然会被DVFS（动态电压频率调整）拉下去。解决办法是把nvpmodel和jetson_clocks组合使用，并且用jetson_clocks --store保存当前配置，必要时用jetson_clocks --restore恢复。在我实测的JetPack 6版本里，nvpmodel -m 0加jetson_clocks的组合效果最稳定。
还有一个导致性能不佳的隐藏原因是供电不足。Orin Nano的USB-C或DC电源接口如果接的是杂牌电源，电压不稳定时系统会自动降频保护硬件。我建议选择官方电源适配器或者正规品牌的12V 4A以上电源，尽量不用USB供电。有过一次在面包板上用劣质电源跑模型，频繁卡顿且偶发重启，换了电源后所有问题消失。
5.3 网络与外设：看似简单却频繁翻车的细节
Jetson板卡的网络问题很让人头疼，尤其是使用SD卡启动时，首次开机经常连不上Wi-Fi。先检查是不是没有启用Wi-Fi，用nmcli radio wifi on开启，再用nmcli dev wifi list扫描热点，最后用nmcli dev wifi connect <SSID> password <密码>连接。如果信号弱或者掉线频繁，建议直接用USB网卡或者千兆有线连接，稳定性比板载Wi-Fi好很多。
显示方面，很多人在Orin Nano上接显示器没画面，第一反应是板子坏了。其实Orin Nano的HDMI口对显示器的兼容性一般，尤其是高分辨率高刷新率的显示器，可能出现检测不到信号的情况。我遇到过一次相关的问题，参考当时的网络热词“nvidia jetson orin nx 16gb 开发套件 如何连接显示器、鼠标和键盘”，解决思路是按顺序排查电源、HDMI线、显示器接口、系统启动状态。多数情况是HDMI线质量差或者转接头兼容性问题，换一根高质量的HDMI 2.0线就好了。如果没有显示器，也可以直接用Headless模式通过SSH远程连接，在路由器后台找到板子IP，用ssh <用户名>@<IP>登录即可。
入手Orin Nano后，建议不要先用摄像头这种“看起来简单”的外设。摄像头在Jetson上的兼容性问题极多，尤其是MIPI CSI接口的相机模块，必须匹配官方支持的型号和JetPack版本。USB摄像头相对省心，即插即用，但部分工业相机需要安装厂商提供的V4L2驱动，装之前一定要确认是否支持ARM64架构。很多厂家的SDK只提供x86版本，在Jetson上根本装不了，采购前一定要问清楚。
最后的几点心得
这个平台我前后用了一个多月，整体体会是：Jetson Orin Nano 2的定位确实精准，它不一定是最强或最便宜的，但绝对是最适合入门级边缘AI和实体AI项目规模化的选择之一。算力够用、功耗可控、生态完善、成本合理，这四个条件在同一个板子上同时满足，在当下的设备选择里很少见。
如果你正准备上手，我的建议是别急着跑大模型，先把刷机、性能模式、SWAP基础三步做完，用自带的示例程序确认GPU工作正常，再去部署自己的模型。遇到问题先查驱动时区和网络，这两个最基础的外部条件往往就是最坑人的元凶。等你的模型能在TensorRT上稳定实时推理，再考虑多设备部署和设备群管理，一步步来，踩坑的概率会低很多。
