搞过Jetson Nano的人应该都有这种体会板子本身不贵性能也不差但真正劝退你的往往不是算法而是配置环境时接二连三的坑。明明照着教程一步步走电源换了、镜像也烧了结果插上电还是黑屏或者好不容易进了系统一跑模型就死机。我前前后后在这块板子上折腾过不少时间也帮别人排过不少疑难杂症所以想把这个系列的排坑经验整理出来希望能让后面上车的朋友少走点弯路。这篇先覆盖我从烧录到跑通AI环境过程中遇到的高频坑供电、刷机、散热、环境配置以及对应的一套排查思路。1. 先认清Jetson Nano的脾气它和普通开发板不是一回事1.1 硬件定位它是一台带GPU的小电脑Jetson Nano的核心卖点是那块128核Maxwell架构的GPU官方宣传里常提到它能跑某些神经网络推理但这块板子的本质其实是一台完整的Linux电脑。它有四核ARM Cortex-A57 CPU内存是4GB LPDDR4存储靠Micro SD卡或USB设备扩展。也就是说它和树莓派在形态上有相似之处但工作方式完全不一样——它跑的是英伟达定制的JetPack系统里面预装好了CUDA、cuDNN、TensorRT这些组件是围绕GPU计算设计的。这个定位带来一个直接后果你没法像用树莓派那样随便下一个通用Linux镜像往里塞。Jetson Nano对软件栈的要求更苛刻系统、驱动、CUDA、库的版本必须匹配否则即便能开机后面跑模型也大概率会遇到找不到CUDAlib版本不对之类的问题。1.2 软件体系JetPack不只是个系统镜像很多人第一次接触Jetson Nano时会有个误解以为烧录系统和烧树莓派系统一样烧完就能像普通Ubuntu一样随便装软件。实际上英伟达提供的JetPack是一个完整的SDK套件它包含了Linux操作系统通常是Ubuntu定制版、CUDA工具链、cuDNN、TensorRT、多媒体API如VisionWorks、GStreamer插件等。镜像烧好之后这些组件已经躺在系统里了但路径、环境变量、版本配套如果不清楚后续配置会很痛苦。不同的JetPack版本对应的Ubuntu版本也不一样JetPack 4.x系列基于Ubuntu 18.04默认CUDA 10.2JetPack 5.x系列基于Ubuntu 20.04默认CUDA 11.4。很多教程里给的命令和安装包都是针对JetPack 4.4或者4.6的如果你用的是新镜像直接复制粘贴大概率会踩版本坑。1.3 为什么Jetson Nano配置容易出问题说白了有三个原因。第一是aarch64架构的软件生态比x86差很多很多第三方Python包没有现成的ARM64 wheel要么编译要么找别人编好的包。第二是板子的资源太紧4GB内存还要分给GPU跑大模型和编译代码时经常被OOM内存耗尽或卡死整崩溃。第三是电源和散热这两个物理问题板子功耗看着不高但供电和散热不达标会让系统表现得很玄学——有时候重启有时候掉USB设备有时候直接文件系统损坏。理解了这三点再回头看那些千奇百怪的问题基本都能归因到底层资源或系统匹配上。排坑的第一原则就是不要一上来怀疑代码先排查供电、散热、系统状态这些基础项。2. 供电不行一切白搭第一个高频坑的完整排查过程2.1 供电规格背后的功率计算Jetson Nano的官方供电要求是5V/4ADC圆头供电或者USB Type-C口供电注意是4A不是开发板刚发布时宣传的5V/2A。这是因为GPU满载运行时的功耗可以达到5W-10W整个板子加上外设USB键盘、鼠标、无线网卡瞬间电流很容易超过2A。有人会问我插一个5V/2A的手机充电头能不能用能开机但一跑GPU任务就出问题。我自己实测过用2A电源的时候开机进桌面没问题但一旦启动一个稍微大点的目标检测模型GPU频率还没拉满系统就自动重启了。这个现象在Jetson Nano上非常典型是因为供电不足导致电压跌落触发了板载的欠压保护。2.2 供电不足的典型症状列表供电不足不一定表现为立刻关机重启很多时候是间歇性抽风。我把常见症状列在这里方便大家对照开机一段时间后突然黑屏重启特别是在跑GPU负载时。USB设备间歇性掉线比如鼠标键盘用着用着没反应过几秒又恢复。Micro SD卡文件系统损坏开机后频繁出现fsck检查甚至直接无法挂载。系统卡顿异常CPU频率和GPU频率被压低性能明显下降。网络适配器USB无线网卡频繁断连ping不通或者延迟飙升。这些症状单独拎出来看很多人的第一反应是系统没装好驱动有问题卡不行但根因很可能就是电源端供电能力不够。我当时排一个无线网卡频繁掉线的问题折腾了快两天换驱动、改电源管理、关省电模式最后换了个5V/3A的电源问题直接消失——这就是供电问题的迷惑性。2.3 如何量化判断供电是否充足如果你怀疑自己的供电有问题可以用一个比较直接的方法万用表测电压。找一根可以剪开的DC电源线或者USB线把万用表打到直流电压档红表笔接5V线黑表笔接GND然后去跑一个GPU负载程序。观察电压数值的变化如果满载时电压跌到4.8V以下说明电源要么电流不够要么线材压降太大。质量好的电源在满载时电压应该稳定在5.0V-5.2V左右。另一个方法是直接在系统里看。用cat /sys/devices/system/cpu/cpu0/cpufreq/cpu_usage这类命令看频率没有直观参考比较实用的工具是tegrastats它可以实时显示CPU、GPU频率和温度。如果发现GPU频率一直卡在最低档大约76MHz-150MHz左右或者CPU被限制在低频率除了温控原因大概率就是供电或者电源管理策略的问题。提示Jetson Nano默认的电源模式有Max和5W两种前者性能完全释放后者以低功耗运行。如果当前是5W模式GPU性能会大打折扣。用sudo nvpmodel -m 0可以切到最大性能模式JetPack 4.x上通常0是MAXN1是5W再用sudo jetson_clocks把CPU/GPU频率拉满。2.4 供电方案的实际选型建议折腾一圈下来我的结论是首选官方原装5V/4A电源适配器省心。如果要用充电宝或普通充电头供电一定选支持PD协议且至少能输出5V/3A的单口标称2.4A那种基本不要想跑满。线材很重要。同样的电源线长了、线径细了压降就大。宁可用短粗线不要用又长又细的充电线。尽量让USB外设单独供电。USB键盘鼠标功耗不高但USB无线网卡、移动硬盘这种设备会显著增加板子的电流负担最好用带独立供电的USB HUB。3. 系统刷写与首次启动黑屏与卡死背后的排查链路3.1 镜像选择版本决定你后面省不省心JetPack系统镜像的选择看似简单其实也有讲究。如果只是跑一些经典视觉模型、用PyTorch做推理测试建议选择JetPack 4.6.1这是4.x系列里最完善的版本教程多、第三方库兼容性好PyTorch也有对应编译好的wheel。JetPack 5.x系列虽然Ubuntu版本更新但很多旧教程里的命令不适用部分第三方包需要重新编译对新手来说坑更多。如果要做CUDA相关开发还要留意JetPack里的CUDA版本JetPack 4.6.1是CUDA 10.2JetPack 5.0是CUDA 11.4。项目的依赖如果明确要求CUDA 11.x那选4.x镜像就得自己想办法装多版本CUDA会很麻烦。所以镜像版本的选择建议是先用4.6.1跑通全流程再按项目需要折腾5.x。3.2 烧录过程中的易错细节烧录这个步骤看着简单其实翻车率不低。我用的是balenaEtcher烧录工具选好镜像、选好SD卡、点Flash等待完成。但有几个细节容易被忽略第一烧录前最好把SD卡用SD Card Formatter格式化一遍尤其是一张卡以前装过其他系统或者被多次读写过。不格式化直接烧可能出现烧录成功但无法启动的怪问题。第二烧录完成后Windows通常会弹窗提示需要格式化磁盘千万别点。这是Windows不认识Linux分区导致的正常现象点了格式化SD卡就废了只能重新烧。第三烧录速度异常快或者异常慢都值得怀疑。我用Class 10的卡烧录4.6.1镜像写入速度大概在20MB/s左右如果几秒钟就提示完成多半是卡是假的或者读卡器有问题。烧完之后可以用balenaEtcher的校验功能或者重新插上卡看一下分区确认烧录完整性。3.3 首次启动黑屏的排查链路插上电电源灯亮了风扇转了一下停了但HDMI一直黑屏没信号。这是Jetson Nano新手最容易崩溃的场景。我的排查顺序是这样的第一步确认显示器接的是正确的HDMI口。Jetson Nano有两个HDMI接口位于USB接口同一侧靠近供电圆口的那一个才支持HDMI输出——不对更准确说是Jetson Nano只有一个HDMI口部分版本有DP口我见过很多人把显示器接到USB旁边的HDMI上以为开机失败了其实只是画面输出到了另一个显示接口。具体要看手里的板子是哪个版本有的开发板带HDMI和DP两个接口接错就不会有输出。第二步听风扇和看电源灯。如果电源灯常亮风扇转一下就停这是正常的自检行为如果电源灯都不亮检查电源。如果电源灯常亮但风扇完全没反应且HDMI黑屏试试按住板子上的Force Recovery键再上电看能不能进恢复模式。第三步换一个显示器或者电视机测试。Jetson Nano对HDMI线比较挑剔尤其是转接线、老显示器兼容性差会握手失败没有画面。我当时就遇到过一根正常的HDMI线第一次能显示重启后不显示的情况换线解决。第四步检查SD卡是否插到位。Micro SD卡槽有卡扣设计插到底之后要听到咔哒一声才算锁住如果没插到位接触不良会导致系统一半能启动一半不行。新手常见问题但确实有人卡在这里。如果以上都试过还是不启动那就需要用串口方式看启动日志了——这个放到后面排查方法论里详细说。4. 散热与风扇温度一高性能直接折半4.1 被动散热与主动散热的差距Jetson Nano原厂包装里有一个小散热片官方默认是让用户把散热片贴在CPU/GPU上方靠被动散热。如果只是跑跑轻量任务这个散热片勉强够用但一旦跑神经网络推理或者训练小模型核心温度会迅速飙升到85度以上GPU开始降频速度肉眼可见地变慢。我用热像仪看过满载运行时的核心区域温度能到80度往上此时CPU频率会被强制压低GPU也只能以低档位运行。反映到实际体验上就是同样的模型推理任务冷启动时跑20ms运行五分钟后变成40ms再过几分钟可能更慢。这个越跑越慢不是代码问题是温度墙在起作用。4.2 温度与降频之间的关系Jetson Nano的散热策略是这样的系统会持续监控芯片温度当温度超过某个阈值一般在60度到65度之间就开始降频85度以上会强制大幅降频时自动调低CPU/GPU的工作频率来保护硬件。这个逻辑本身没毛病但问题是板子默认的风扇策略不太合理——很多情况下风扇根本没接或者接了但转速很低导致温度一路走高。如果要让性能稳定主动散热是必须的。最省事的方案是买一个5V的涡轮风扇用胶柱固定在散热片上。更讲究的做法是买一个带PWM调速的风扇接到板子的GPIO口上让系统根据温度动态调整转速。后者的好处是安静温度低时风扇不转温度高时自动提速。4.3 风扇接线与软件调速实战我用的是一款5V三线PWM风扇接线方式比较简单红线接板子上的5V电源脚黑线接GND黄线PWM信号线接GPIO的PWM输出脚不同板子配置不太一样我用的是BOARD编号第33脚。接好后需要在系统里启用硬件PWMsudo /opt/nvidia/jetson-io/config-by-pin.py -l运行后会有一个交互式界面选择把对应的引脚配置为PWM功能。配置完成后重启就能在/sys/class/pwm/pwmchip0/下看到新的pwm通道。手动调速的话可以用这样的命令把风扇设置到50%占空比注意pwmchip和pwmX的编号可能不同先ls看一下echo 0 /sys/class/pwm/pwmchip0/export echo 1000000 /sys/class/pwm/pwmchip0/pwm0/pwm_period echo 500000 /sys/class/pwm/pwmchip0/pwm0/pwm_duty_cycle echo 1 /sys/class/pwm/pwmchip0/pwm0/pwm_enable更省心的方法是用nvfancontrol这个工具它是英伟达官方提供的一套用户态风扇控制服务可以设置温度阈值和对应的转速百分比。配置文件在/etc/nvfancontrol.conf改成适合自己的参数后sudo systemctl enable nvfancontrol sudo systemctl start nvfancontrol我自己设的是温度低于45度时风扇30%45-55度之间60%超过55度拉满100%。这样日常待机几乎听不到声音跑模型时风扇转速跟上温度基本稳定在65度以内性能也不会掉链子。4.4 常用温度与频率监控命令tegrastats是我用得最多的命令它默认输出一行实时信息包括CPU各核温度、GPU温度、CPU频率、GPU频率、内存占用等。sudo tegrastats比如看到某一行里CPU72C、GPU68C说明温度偏高如果GPU150MHz或者CPU300MHz这种低频出现基本可以断定是供电或温控策略在限频。配合watch命令可以持续观察sudo watch -n 1 tegrastats还有一个工具叫jtop它是基于Jetson的Python库做的一个交互式监控面板类似桌面上的任务管理器能看CPU/GPU占用、温度、功耗、内存、风扇转速安装方式很简单pip install jetson-stats sudo jtop这个工具对定位问题帮助很大我一般排查性能问题时第一步就是开jtop看温度、频率和内存占用省去翻一堆系统文件的时间。5. AI环境配置装上不等于能用版本坑逐个拆5.1 CUDA路径与环境变量JetPack系统里预装了CUDA但默认情况下nvcc命令行是找不到的因为CUDA的bin目录没有加到PATH里。很多人在这一步被卡住以为CUDA没装成功。实际上你只要打开终端执行ls /usr/local/大概率能看到一个cuda-10.2或者cuda-11.4的目录这就是系统自带的CUDA。需要手动把路径写进环境变量编辑~/.bashrc在文件末尾加export PATH/usr/local/cuda/bin:$PATH export LD_LIBRARY_PATH/usr/local/cuda/lib64:$LD_LIBRARY_PATH export CUDA_HOME/usr/local/cuda然后source ~/.bashrc再执行nvcc -V就能看到版本信息。这里要注意的是/usr/local/cuda是一个软链接指向实际的CUDA版本目录如果系统里装了多版本CUDA这个软链接指向哪个版本nvcc就是哪个版本。5.2 PyTorch for aarch64别用pip直接装这是Jetson Nano配置里最经典的一个坑。在普通x86电脑上pip install torch就能安装PyTorch但在Jetson Nano上直接敲这条命令pip要么找不到对应的wheel要么装到一个CPU-only版本性能和板载GPU的加速完全没戏。正确的做法是安装专门为Jetsonaarch64平台编译的PyTorch wheel包。JetPack 4.6.1对应的Python是3.6官方推荐的是PyTorch 1.8.0或1.9.0的预编译包命名类似torch-1.8.0-cp36-cp36m-linux_aarch64.whl。下载完成后pip install torch-1.8.0-cp36-cp36m-linux_aarch64.whltorchvision也一样需要下载对应的aarch64版本安装。这里特别提醒PyTorch和torchvision的版本是绑定的别装一个1.8的torch配一个0.11的torchvision会直接报版本不兼容错误。装好之后验证是否用了GPUpython -c import torch; print(torch.cuda.is_available()); print(torch.cuda.get_device_name(0))如果输出True和Jetson Nano说明GPU加速路径通了。如果输出False多半是装成了CPU版本卸载重装。5.3 Swap空间与内存不足的问题Jetson Nano只有4GB内存还要被GPU吃掉一部分可用内存经常只有2GB多。这时候跑数据处理或者编译一些大一点的库很容易出现内存耗尽被系统杀掉进程的错误OOM Killer。更尴尬的是因为内存不够系统会频繁清理缓存导致访问磁盘变得非常慢整个板子像死机一样。解决办法是加Swap交换空间。官方教程里有手动配置Swap的方法网上也有很多脚本。我的操作是分配4GB的交换文件sudo fallocate -l 4G /var/swapfile sudo chmod 600 /var/swapfile sudo mkswap /var/swapfile sudo swapon /var/swapfile为了让重启后自动挂载把/var/swapfile添加到/etc/fstab里/var/swapfile swap swap defaults 0 0加了Swap之后编译时不容易卡死了但要注意一点Swap使用的是SD卡的空间频繁读写对SD卡寿命有影响不建议把Swap设得过大。如果项目真的需要大内存还是优先考虑用USB固态硬盘或移动硬盘做系统盘把系统跑在SSD上内存和交换速度都会有明显改善。5.4 TensorRT与模型加速的基本认知JetPack自带TensorRT这是英伟达的深度学习推理加速引擎。很多人以为TensorRT是一个可以直接调用的库跑模型时直接import tensorrt就行但实际使用起来相对复杂。简单来说TensorRT要做的是将训练好的模型比如PyTorch的.pt或ONNX格式优化并序列化为一个TensorRT engine文件推理时加载这个engine来执行。不过在入门阶段通常不是直接用TensorRT的API而是通过一些上层工具间接使用它。比如英伟达官方提供的vision_trt示例程序可以把TensorRT和DeepStream整合起来做视频流分析。如果只是用PyTorch推理不追求极高的性能直接跑PyTorch的GPU推理也可以接受TensorRT这块可以等有明确性能需求之后再深入研究。环境配置的坑总结下来就一句话不盲目追求最新版本先确认你的JetPack版本、Python版本、PyTorch版本的兼容三角关系装好一个组件立一个Flag跑通了再做下一步。6. 通用排查方法论串口日志、系统监控与心态管理6.1 串口是最后的底牌当HDMI黑屏、系统完全无法启动的时候串口是你唯一能看到的眼睛。Jetson Nano板载了一个UART串口通过TTL转USB模块连接电脑可以在终端里看到完整的内核启动日志。连接方式是模块的TX接板子的RX、RX接板子的TX、GND接GND波特率通常是115200。在电脑上用screen或者minicom打开串口sudo screen /dev/ttyUSB0 115200如果板子上电后串口有大量日志输出说明系统和硬件基本正常问题可能在显示输出如果串口完全没反应那就是上电时序、卡或电源的问题。串口日志里出现mmc0: error -110、failed to mount、Cannot find device之类的关键词都是很好的定位线索。我排过一台插电后电源灯亮但完全黑屏的板子串口日志显示系统在尝试加载SD卡时一直报错换了一张卡之后正常启动——当时烧录用的卡是便宜的白牌卡号称64G实际读写速度连Class 4都达不到。这种卡表面能烧录但实际运行会因为随机读写性能太差而频繁出错。6.2 常用命令速查表这里把我日常排查的常用命令整理成一个速查表方便大家直接抄。场景常用命令预期结果查看系统版本cat /etc/nv_tegra_release显示JetPack版本信息查看内核版本uname -a显示核心版本号查看CPU/GPU温度与频率sudo tegrastats实时显示各部件温度和频率查看GPU驱动与CUDAnvcc -V/nvidia-smi显示CUDA版本Nano没有nvidia-smi有tegrastats查看内存与Swapfree -h显示物理内存和交换空间使用情况查看系统日志重点报错dmesg | tail -50显示内核日志排查硬件问题查看开机自检错误journalctl -b -p 3查看启动过程中error级别日志切换最大性能模式sudo nvpmodel -m 0切换MAXN模式解除功耗限制拉满CPU/GPU频率sudo jetson_clocks启动持续高性能模式安装jetson-stats监控面板pip install jetson-stats sudo jtop启动Jetson状态监控面板检查系统负载top -d 1查看CPU、内存占用大户这些命令不需要全记住收藏起来遇到问题时挨个试就行。排坑的本质就是缩小范围先确认电源再看启动状态再查温度最后才深入软件配置。6.3 我的排查顺序习惯每次有人带着板子来找我排查我基本都按这个顺序来第一步确认硬件状态。电源是否达标、卡是否正常、风扇是否在转、温度是否过高。这一环节可以排除60%以上的玄学问题。第二步确认系统能启动、能进终端。如果连终端都进不去先解决启动问题串口日志定位再谈其他。第三步确认基础软件环境。查看JetPack版本、CUDA版本、Python版本、pip源是否可用用nvcc -V和python -V这种命令快速过一遍。第四步复现具体问题。把报错信息完整拉出来去搜索引擎搜关键报错片段。这里有个建议搜英文比搜中文有效得多很多英文问题帖里直接有官方解答。第五步动手修。一次只改一个变量改完立刻验证。不要同时换电源、换卡、换镜像、改配置否则你永远不知道是哪个改动起了效果。这个流程看起来笨但最有效。我见过太多人绕来绕去最后发现是电源或卡的问题白白浪费一整天。这一系列的后续文章我打算分别深入写一写用USB固态硬盘做系统盘到底能带来多大的提升、TensorRT加速的实际体验、在Jetson Nano上部署目标检测模型的完整步骤。如果你正在配置过程中遇到了其他问题可以先按上面的排查顺序走一遍说不定答案就在某个命令的输出结果里。