1. 从第一讲到第九讲，这条学习曲线到底长什么样
很多人学嵌入式AI，最大的问题不是不够努力，而是学着学着就散了。今天看YOLO部署，明天搞Ollama跑大模型，后天又去折腾SLAM建图，每样都碰了一下，但真要串起来做一个完整项目，脑子里全是碎片。我带过不少做Jetson方向的朋友，几乎每个人在第三讲左右都会经历一次“信息过载”——板子型号太多、工具链太杂、教程之间互相矛盾，越学越焦虑。
这套课程从第一讲到第九讲，其实一直在做一件事：把边缘嵌入式的知识体系从“点”连成“线”，再从“线”织成“面”。第十讲作为总结，不是简单地把前九讲标题念一遍，而是要把每一讲背后的设计意图、技术选型逻辑、以及它们之间的依赖关系讲透。你学完这一讲，应该能做到：拿到一块Jetson板子，从系统烧录到模型部署到应用落地，心里有一条清晰的路径，而不是打开搜索引擎漫无目的地翻。
这篇文章适合谁看？如果你手上有Jetson Nano、Orin Nano、Orin NX或者AGX Orin，想认真把边缘AI这件事做扎实，那前九讲的内容你大概率都接触过，但可能没有系统梳理过。如果你刚入门，也可以把这篇当作一张学习地图，知道每个阶段该学什么、为什么学、学到什么程度算过关。
核心关键词就三个：Jetson、边缘嵌入式、课程总结。但我要做的不是复述，而是拆解——拆解每一讲为什么这样安排，拆解那些教程里不会写的坑，拆解从“能跑通”到“能交付”之间差了什么。
2. 前九讲的知识骨架：从裸板到能跑应用的完整链路
2.1 第一讲到第三讲：环境搭建与系统认知
前三讲的核心任务是“让板子活过来，并且知道它为什么能活”。第一讲通常是开箱和硬件认知，包括Jetson各型号的定位差异。这里有个很多人忽略的点：Jetson Nano、Orin Nano、Orin NX、AGX Orin这四块板子的算力差距不是线性的，而是代际性的。Nano是Maxwell架构，Orin系列是Ampere架构，Tensor Core的代际差异直接决定了INT8量化后的推理效率。第一讲如果不把这个讲清楚，后面选型就会踩坑。
第二讲一般进入系统烧录。Jetson的烧录方式和树莓派完全不同，它依赖NVIDIA的SDK Manager或者命令行flash脚本。这里的关键不是“怎么烧”，而是“烧哪个版本”。JetPack版本和L4T版本是绑定的，而L4T版本又决定了CUDA、cuDNN、TensorRT的版本。我见过太多人烧了一个旧版JetPack，结果发现TensorRT不支持某个算子，回头重烧，之前配的环境全废。所以第二讲的核心其实是版本管理意识。
第三讲通常讲远程访问和基础开发环境。SSH、VNC、JupyterLab这些是标配，但真正重要的是理解Jetson的电源管理模式和散热策略。Orin系列默认的功耗模式有多个档位，从7W到MAXN，不同档位下CPU和GPU的频率差异巨大。你在7W模式下跑YOLOv5，帧率可能只有MAXN模式的一半。这一讲如果不把nvpmodel和jetson_clocks讲透，后面做性能测试全是无效数据。
2.2 第四讲到第六讲：推理部署的核心工具链
这三讲是整个课程的技术核心。第四讲通常是TensorRT入门，第五讲是ONNX到TensorRT的转换，第六讲是实际模型部署。这条链路是Jetson上做推理的标准路径：PyTorch训练 → 导出ONNX → TensorRT优化 → 部署推理。
为什么一定要走TensorRT？因为Jetson的GPU算力有限，原生PyTorch推理在Orin Nano上跑YOLOv5s可能只有十几帧，经过TensorRT的FP16或INT8量化后，可以到四五十帧。这个提升不是“优化”，而是“能不能用”的区别。但TensorRT的坑也最多：算子不支持、动态shape处理、量化校准集选择、显存溢出，每一个都能卡你半天。
第五讲的ONNX转换是承上启下的关键。PyTorch导出ONNX时，opset版本的选择直接影响后续TensorRT能否解析。我一般建议用opset 11或12，太新的opset TensorRT可能不认，太旧的又缺少某些算子。另外，导出时的dynamic_axes设置决定了你是否支持动态batch和动态分辨率，这个在部署时非常关键——比如你需要在同一套代码里处理不同分辨率的输入。
第六讲进入实际部署，通常会涉及DeepStream或者直接用TensorRT的Python API。DeepStream适合视频流处理，但学习曲线陡峭；直接调TensorRT API更灵活，但需要自己写前后处理。两种方式没有绝对优劣，取决于你的应用场景。如果是多路视频分析，DeepStream的pipeline管理更省心；如果是单模型定制化推理，直接调API更可控。
2.3 第七讲到第九讲：应用层与系统集成
第七讲一般讲SLAM或者视觉应用，airslam jetson部署是热词之一。SLAM在Jetson上的难点不是算法本身，而是资源竞争。SLAM需要CPU做特征提取、GPU做位姿优化，同时还要跑目标检测，这时候内存带宽和功耗墙就成了瓶颈。Orin NX的16GB版本在这类场景下比8GB版本稳得多，因为SLAM的地图数据很容易把内存吃满。
第八讲通常涉及大模型部署，jetson orin nano部署qwen和jetson orin ollama是最近的热门方向。在边缘设备上跑LLM，核心矛盾是显存和量化。Qwen-1.8B经过INT4量化后可以在Orin Nano 8GB上跑，但推理速度大概在每秒几个token，适合做离线问答而不是实时对话。Ollama在Jetson上的部署相对简单，但要注意它的默认模型仓库可能不包含ARM64优化版本，需要自己编译或者找社区预编译包。
第九讲一般是综合项目实战，把前面的检测、SLAM、大模型串起来做一个完整应用。这一讲的价值在于暴露“集成问题”——单个模块跑通不代表系统能跑通。比如YOLOv5和SLAM同时运行时，GPU显存怎么分配？DeepStream的pipeline和ROS2的节点怎么通信？这些问题在单独模块的教程里不会出现，只有集成时才会冒出来。
3. 那些教程里不会写的选型逻辑与参数计算
3.1 Jetson型号选择的三个硬指标
选Jetson板子，不要只看算力TOPS。我一般看三个硬指标：显存带宽、内存容量、功耗墙。
显存带宽决定了模型推理的吞吐上限。Jetson Nano是25.6GB/s，Orin Nano是68GB/s，Orin NX是102GB/s，AGX Orin是204GB/s。这个差距在跑大模型时特别明显——带宽不够，GPU核心再强也得等数据。比如跑Qwen-1.8B INT4，模型权重大概1GB左右，每次推理需要把权重从内存加载到GPU，带宽直接决定token生成速度。
内存容量决定了你能同时跑几个模型。8GB的Orin Nano跑一个YOLOv5加一个轻量SLAM勉强够，但再加一个LLM就必然OOM。16GB的Orin NX可以同时跑检测、SLAM和1.8B模型，但需要仔细管理内存分配。
功耗墙决定了持续性能。Jetson的散热设计很重要，Orin Nano在10W模式下如果散热不好，会触发降频，实际性能可能只有标称的60%。我一般建议至少加一个主动散热风扇，尤其是要做持续推理的场景。
| 型号 | GPU架构 | 显存带宽 | 内存选项 | 典型功耗 | 适合场景 |
|---|---|---|---|---|---|
| Jetson Nano | Maxwell | 25.6GB/s | 4GB | 5-10W | 入门学习、简单检测 |
| Orin Nano | Ampere | 68GB/s | 4/8GB | 7-15W | 中等规模检测、轻量LLM |
| Orin NX | Ampere | 102GB/s | 8/16GB | 10-25W | SLAM+检测、1.8B LLM |
| AGX Orin | Ampere | 204GB/s | 32/64GB | 15-60W | 多模型并行、7B LLM |
3.2 TensorRT量化参数的实操计算
INT8量化是Jetson部署的必修课，但校准集的选择直接决定精度损失。我一般用500到1000张代表性图片做校准，太少会导致量化参数估计不准，太多则浪费时间。校准集要覆盖你的实际应用场景——如果你做的是夜间检测，校准集里就必须有夜间图片，否则量化后的模型在夜间场景下精度会崩。
具体操作上，TensorRT的INT8校准有两种方式：熵校准和最小化KL散度校准。默认用熵校准就行，大多数情况下精度损失在1%以内。但如果你发现量化后某些类别的检测率明显下降，可以尝试调整校准算法或者增加校准集数量。
显存占用估算也很关键。一个YOLOv5s模型，FP32大概27MB，FP16减半，INT8再减半。但推理时的显存占用不只是模型权重，还有中间激活值。对于1080p输入，YOLOv5s的激活值大概需要200-300MB。所以Orin Nano 8GB跑YOLOv5s INT8，显存完全够用，但如果你同时跑多个模型，就要仔细算了。
3.3 SLAM与大模型共存的资源分配策略
airslam在Jetson上的部署，最大的坑是它和检测模型抢GPU。SLAM的特征提取可以用CPU做，但位姿优化通常用GPU加速。如果同时跑YOLOv5，两个进程会争抢CUDA核心。
我的做法是给SLAM分配固定的GPU流（CUDA Stream），给检测模型分配另一个流，通过优先级调度让检测模型优先。但更稳妥的方案是用Orin NX 16GB，把SLAM和检测分别跑在不同的GPU实例上——Orin系列支持MIG（多实例GPU）吗？实际上Orin不支持MIG，但可以通过CUDA流和内存隔离来近似实现。
对于LLM部署，jetson orin ollama的方案适合快速验证，但生产环境我建议直接用TensorRT-LLM或者llama.cpp的CUDA后端。Ollama在Jetson上的性能调优空间有限，而且它的模型管理机制会占用额外内存。如果你只是做demo，Ollama够用；如果要集成到产品里，自己编译llama.cpp更可控。
4. 从“能跑”到“能交付”的实操跃迁
4.1 环境配置的版本锁定策略
前九讲如果只记住一件事，那就是版本锁定。Jetson的软件栈是层层依赖的：JetPack版本决定L4T版本，L4T版本决定CUDA版本，CUDA版本决定TensorRT版本，TensorRT版本决定你能否用某些算子。
我一般建议在项目开始时，先确定JetPack版本，然后所有依赖都围绕这个版本安装。不要混用pip和apt安装的CUDA相关包，很容易出现版本冲突。Python环境用conda或者venv隔离，但要注意Jetson的ARM64架构下，某些pip包没有预编译wheel，需要自己编译。
一个实用的技巧是：用jetson_release命令查看当前系统的完整版本信息，包括L4T、CUDA、cuDNN、TensorRT、OpenCV的版本。把这个信息记录下来，作为项目的基准配置。后面如果重装系统，直接对照这个清单恢复。
4.2 模型部署的性能调优 checklist
部署一个模型到Jetson，我一般按这个顺序调优：
- 确认模型输入输出格式，固定shape还是动态shape。固定shape性能更好，但灵活性差。
- 选择精度模式：FP32 → FP16 → INT8。每降一级，速度提升大概30-50%，精度损失需要评估。
- 调整batch size。Jetson上batch size不是越大越好，因为显存有限，batch太大反而会触发内存交换。
- 使用
trtexec做基准测试，记录推理延迟和吞吐量。 - 如果用了DeepStream，调整pipeline的batch-size和streammux参数。
- 最后用
tegrastats监控实际运行时的CPU、GPU、内存、功耗，确认没有瓶颈。
这个checklist看起来简单，但每一步都有细节。比如INT8量化时，如果校准集和实际输入分布差异大，精度会掉得很厉害。我一般会在量化后跑一遍验证集，对比FP16和INT8的mAP，如果掉超过3个点，就要重新考虑校准集。
4.3 多模型并行的内存管理
在Orin NX上同时跑YOLOv5和Qwen-1.8B，内存管理是核心。我的做法是：
- YOLOv5用TensorRT INT8，显存占用控制在500MB以内。
- Qwen-1.8B用INT4量化，显存占用大概1.2GB。
- SLAM用CPU模式，不占GPU显存。
- 系统预留2GB给操作系统和其他进程。
这样总算下来，8GB的Orin NX刚好够用，但余量很小。如果要做视频流处理，建议上16GB版本。另外，Jetson的共享内存架构意味着GPU和CPU共用物理内存，所以显存和内存不是独立的。tegrastats里看到的RAM就是总内存，GPU用的也是这部分。
一个容易忽略的点是：TensorRT的engine文件在加载时会占用显存，但推理时的激活值也会动态分配。如果多个模型交替推理，显存碎片化会导致OOM。解决办法是尽量让模型常驻显存，或者用TensorRT的--saveEngine和--loadEngine机制预加载。
5. 常见问题与排查技巧实录
5.1 TensorRT转换失败的典型原因
| 问题现象 | 可能原因 | 排查方法 | 解决方案 |
|---|---|---|---|
| ONNX解析失败 | opset版本不兼容 | 用polygraphy检查ONNX | 重新导出为opset 11/12 |
| 算子不支持 | TensorRT版本旧 | 查看TensorRT支持列表 | 升级JetPack或替换算子 |
| 量化后精度暴跌 | 校准集不具代表性 | 对比FP16和INT8的mAP | 增加校准集或换校准算法 |
| 推理时OOM | batch size太大 | 用tegrastats监控 | 减小batch或降低精度 |
| 动态shape报错 | optimization profile未设置 | 检查trtexec参数 | 设置min/opt/max shape |
5.2 SLAM部署中的资源竞争问题
airslam在Jetson上跑，最常见的报错是“CUDA out of memory”或者“GPU utilization 100% but frame rate drops”。这通常是因为SLAM和检测模型同时抢GPU。
我的排查步骤是：先用tegrastats看GPU利用率和内存占用，如果GPU利用率持续100%但帧率上不去，说明有资源竞争。然后分别单独跑SLAM和检测，记录各自的资源占用。最后调整优先级，或者把SLAM的特征提取放到CPU上。
另一个坑是SLAM的建图分辨率。高分辨率地图会占用大量内存，Orin Nano 8GB跑高分辨率SLAM很容易OOM。我一般建议把地图分辨率降到5cm，这样内存占用可以减少一半以上。
5.3 大模型部署的量化与推理速度
jetson orin nano部署qwen，最大的问题是速度。Qwen-1.8B INT4在Orin Nano上大概每秒3-5个token，这个速度做实时对话不现实，但做离线问答或者文本摘要够用。
提升速度的方法有几个：一是用TensorRT-LLM替代llama.cpp，TensorRT-LLM对Jetson有专门优化；二是减小上下文长度，上下文越长，KV Cache越大，推理越慢；三是用更小的模型，比如Qwen-0.5B，速度可以到每秒10个token以上。
Ollama在Jetson上的部署相对简单，但要注意它的默认模型可能不是ARM64优化版本。我一般会从社区找预编译的ARM64模型，或者自己用llama.cpp转换。Ollama的优势是模型管理方便，适合快速验证；劣势是性能调优空间小，不适合生产环境。
5.4 系统稳定性与散热问题
Jetson在持续高负载下，散热是绕不开的问题。Orin Nano的被动散热在25度室温下，跑满载推理大概10分钟就会降频。我实测过，加一个5V的小风扇，温度可以从85度降到65度，性能提升大概20%。
另外，Jetson的电源管理也很重要。用官方电源适配器，不要用手机充电器，电压不稳会导致板子重启。Orin系列支持宽电压输入，但电流要够。如果同时接多个USB设备，要注意总电流不要超过电源适配器的额定值。
6. 从第九讲到第十讲：下一步该往哪走
前九讲把Jetson的边缘AI链路走通了，但“走通”和“做好”之间还有距离。如果你已经能跑通YOLOv5、SLAM和Qwen，下一步可以考虑这几个方向：
一是模型优化。TensorRT的INT8量化只是开始，还可以尝试结构化剪枝、知识蒸馏、神经架构搜索。这些方法可以在保持精度的同时进一步压缩模型，让它在更低端的Jetson上跑。
二是系统集成。把检测、SLAM、LLM串成一个完整的应用，比如一个能理解自然语言指令的巡检机器人。这需要解决多进程通信、任务调度、异常恢复等问题，比单独跑模型复杂得多。
三是产品化。从demo到产品，需要做稳定性测试、功耗优化、外壳设计、认证合规。这些工作不性感，但决定了项目能不能落地。
我个人在实际操作中的体会是：Jetson的边缘AI，难点从来不在单个模型能不能跑，而在于整个系统的资源平衡和稳定性。前九讲教的是“怎么做”，第十讲要教的是“怎么想”——想清楚每个技术选型背后的权衡，想清楚你的应用场景到底需要什么，想清楚哪些优化值得做、哪些可以妥协。
最后分享一个小技巧：每次做完一个Jetson项目，把完整的配置清单、版本号、踩过的坑、解决方案整理成一个文档。下次再做类似项目，直接翻文档，能省掉80%的重复劳动。这个习惯我坚持了三年，现在手上有十几个项目的配置档案，新项目启动时基本不用重新试错。
