企业官网建设流程全解析

搞过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、库的版本必须匹配，否则即便能开机，后面跑模型也大概率会遇到"找不到CUDA""lib版本不对"之类的问题。

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.2；JetPack 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/4A（DC圆头供电，或者USB Type-C口供电），注意是4A，不是开发板刚发布时宣传的5V/2A。这是因为GPU满载运行时的功耗可以达到5W-10W，整个板子加上外设（USB键盘、鼠标、无线网卡）瞬间电流很容易超过2A。

有人会问：我插一个5V/2A的手机充电头能不能用？能开机，但一跑GPU任务就出问题。我自己实测过，用2A电源的时候，开机进桌面没问题，但一旦启动一个稍微大点的目标检测模型，GPU频率还没拉满，系统就自动重启了。这个现象在Jetson Nano上非常典型，是因为供电不足导致电压跌落，触发了板载的欠压保护。

2.2 供电不足的典型症状列表

供电不足不一定表现为立刻关机重启，很多时候是"间歇性抽风"。我把常见症状列在这里，方便大家对照：

1. 开机一段时间后突然黑屏重启，特别是在跑GPU负载时。
2. USB设备间歇性掉线，比如鼠标键盘用着用着没反应，过几秒又恢复。
3. Micro SD卡文件系统损坏，开机后频繁出现fsck检查，甚至直接无法挂载。
4. 系统卡顿异常，CPU频率和GPU频率被压低，性能明显下降。
5. 网络适配器（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是MAXN，1是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.2，JetPack 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脚）。接好后，需要在系统里启用硬件PWM：

sudo /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

比如看到某一行里CPU@72C、GPU@68C，说明温度偏高；如果GPU@150MHz或者CPU@300MHz这种低频出现，基本可以断定是供电或温控策略在限频。配合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的加速完全没戏）。

正确的做法是安装专门为Jetson（aarch64平台）编译的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.whl

torchvision也一样，需要下载对应的aarch64版本安装。这里特别提醒：PyTorch和torchvision的版本是绑定的，别装一个1.8的torch配一个0.11的torchvision，会直接报版本不兼容错误。

装好之后验证是否用了GPU：

python -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 常用命令速查表

这里把我日常排查的常用命令整理成一个速查表，方便大家直接抄。

这些命令不需要全记住，收藏起来遇到问题时挨个试就行。排坑的本质就是缩小范围：先确认电源，再看启动状态，再查温度，最后才深入软件配置。

6.3 我的排查顺序习惯

每次有人带着板子来找我排查，我基本都按这个顺序来：

第一步，确认硬件状态。电源是否达标、卡是否正常、风扇是否在转、温度是否过高。这一环节可以排除60%以上的"玄学"问题。

第二步，确认系统能启动、能进终端。如果连终端都进不去，先解决启动问题（串口日志定位），再谈其他。

第三步，确认基础软件环境。查看JetPack版本、CUDA版本、Python版本、pip源是否可用，用nvcc -V和python -V这种命令快速过一遍。

第四步，复现具体问题。把报错信息完整拉出来，去搜索引擎搜关键报错片段。这里有个建议：搜英文比搜中文有效得多，很多英文问题帖里直接有官方解答。

第五步，动手修。一次只改一个变量，改完立刻验证。不要同时换电源、换卡、换镜像、改配置，否则你永远不知道是哪个改动起了效果。

这个流程看起来笨，但最有效。我见过太多人绕来绕去，最后发现是电源或卡的问题，白白浪费一整天。

这一系列的后续文章，我打算分别深入写一写"用USB固态硬盘做系统盘到底能带来多大的提升"、"TensorRT加速的实际体验"、"在Jetson Nano上部署目标检测模型的完整步骤"。如果你正在配置过程中遇到了其他问题，可以先按上面的排查顺序走一遍，说不定答案就在某个命令的输出结果里。