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/sOrin Nano是68GB/sOrin NX是102GB/sAGX 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 NanoMaxwell25.6GB/s4GB5-10W入门学习、简单检测Orin NanoAmpere68GB/s4/8GB7-15W中等规模检测、轻量LLMOrin NXAmpere102GB/s8/16GB10-25WSLAM检测、1.8B LLMAGX OrinAmpere204GB/s32/64GB15-60W多模型并行、7B LLM3.2 TensorRT量化参数的实操计算INT8量化是Jetson部署的必修课但校准集的选择直接决定精度损失。我一般用500到1000张代表性图片做校准太少会导致量化参数估计不准太多则浪费时间。校准集要覆盖你的实际应用场景——如果你做的是夜间检测校准集里就必须有夜间图片否则量化后的模型在夜间场景下精度会崩。具体操作上TensorRT的INT8校准有两种方式熵校准和最小化KL散度校准。默认用熵校准就行大多数情况下精度损失在1%以内。但如果你发现量化后某些类别的检测率明显下降可以尝试调整校准算法或者增加校准集数量。显存占用估算也很关键。一个YOLOv5s模型FP32大概27MBFP16减半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上的性能调优空间有限而且它的模型管理机制会占用额外内存。如果你只是做demoOllama够用如果要集成到产品里自己编译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增加校准集或换校准算法推理时OOMbatch size太大用tegrastats监控减小batch或降低精度动态shape报错optimization profile未设置检查trtexec参数设置min/opt/max shape5.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.cppTensorRT-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%的重复劳动。这个习惯我坚持了三年现在手上有十几个项目的配置档案新项目启动时基本不用重新试错。
