端侧AI算力选型实战：从Jetson到国产芯片的车载机载部署指南

这篇稿件我花了不少时间折腾，测过的芯片从NVIDIA Jetson全家桶到国产的瑞芯微、算能、地平线，台架从桌面机箱一路搬到车载供电环境，中间踩过的坑能写满一本小册子。今天这篇就当成一份端侧AI算力选型的实测记录，重点讲车载和机载这种移动场景下的硬件选型逻辑、测试方法，以及那些文档里不会明说的坑。

先说结论：具身智能的算力选型，跟做服务器推理是完全两码事。你不能只看TOPS（每秒万亿次操作）这个数字，功耗墙、内存带宽、工具链成熟度、供电稳定性、散热设计，每一项都可能让标称性能大打折扣。我见过太多团队拿着高算力开发板做demo很顺利，一上车就频繁降频、掉栈、画面撕裂，最后排查下来全是硬件选型阶段欠的债。

1. 先给需求画像：端侧AI部署到底要解决什么问题

1.1 为什么具身智能绕不开端侧算力

具身智能和传统互联网AI最大的区别，就是它一定要有一个物理本体，这个本体可能是轮式底盘、四足机器人、双足人形，也可能是农业无人机、物流小车甚至水面无人艇。不管形态如何，都有一个共同点：它必须在移动中实时感知环境、做出决策。如果所有推理都要回传云端，任何风吹草动的网络波动都会让机器人变成瞎子。哪怕是5G，在城市峡谷、地下车库、农田果园里也保不住稳定低延迟。

所以端侧AI算力不是“要不要”的问题，而是“选择多少”的问题。端侧部署可以做到实时的目标检测、语义分割、深度估计、路径规划，还不用承担流量的带宽成本。在车载和机载场景里，带宽约束更严格，一块1080P摄像头30帧每秒的数据量就要差不多1.5Gbps，如果还要多路双目相机、激光雷达点云，那数据量是惊人的。要么在传感器端就把数据压缩了，要么在本地完成推理，只传结构化结果，这是端侧算力存在的核心意义。

1.2 车载/机载和桌面端的三个本质差异

第一，供电环境完全不一样。桌面开发板插电源适配器就完事了，车载环境要面对12V/24V蓄电池的电压波动，发动机启动瞬间电压甚至会掉到9V以下，无人机上的锂聚合物电池放电曲线在高负载下也会明显下跌。没有任何一块算力板能靠稳压模块硬扛这种波动。

第二，散热环境苛刻得多。车内封闭空间夏天温度可以飙到70度以上，无人机在高空低温高风速和悬停低风速之间切换，散热条件不稳定。桌面端你可以堆一个大铝鳍片加风扇，车/机载场景一要防尘防水，二要考虑重量和风道，很多板子在这个环节性能直接打折。

第三，可靠性和寿命要求不同。开发板拿来跑demo，死机大不了重启。车规/机载设备一旦运行中宕机，轻则任务失败，重则设备损坏。所以选型时不能只看峰值性能，要关注器件的工作温度范围、接口的电气防护、闪存的可靠性，还要看工具链是否支持你实现看门狗、异常恢复这类功能。

1.3 用算法链路反推算力需求

很多人在选型初期就跑偏了，一开始就问“哪个板子算力最高”，这是本末倒置。正确的做法是从算法链路反推。我通常先把要做的事情拆成这几环：

• 传感输入：几路摄像头、什么分辨率帧率，是否有点云输入，选用什么接口（MIPI、USB3.0、GMSL）。
• 感知模型：用什么网络结构（YOLO系列、Transformer类、纯视觉BEV），输入尺寸是多少，单帧推理耗时需要多少毫秒。
• 决策与规划：是否需要同时跑语义地图构建、路径规划、运动控制模型，这些任务是否与感知并发执行。
• 系统开销：操作系统、ROS/ROS2、显示输出、数据日志记录各自要占多少CPU和内存。

举个例子，我最近做的一个轮式机械臂项目，要求同时跑YOLOv8目标检测、语义分割、机械臂运动学解算，外加两路1080P视频录制。算下来感知部分需要单帧在30毫秒内完成，分割任务在80毫秒内完成，整体CPU占用率不能超过50%。按这个链路去推，才能真正确定你需要多少TOPS、多少内存带宽。盲目堆算力只会让功耗和成本失控。

2. 市面上主流端侧算力芯片，哪些真能上车/上机

2.1 NVIDIA Jetson系列：生态最成熟，坑也最经典

Jetson系列在端侧AI领域确实是标杆级的存在，尤其是Orin系列。我用过Orin NX 16GB、Orin Nano 8GB和AGX Orin 64GB，算是把这条产品线的脾气摸了一遍。

Orin NX 16GB标称算力100 TOPS（INT8稀疏），但这是极限模式下的数据。我实测在常温环境、风冷散热条件下，跑MobileNet类小模型能接近标称值的七八成；一旦跑重模型让CPU和GPU同时高负载，功率墙会很快触发，系统自动降到次一级功耗模式，算力会掉到六成左右。Orin Nano 8GB标称40 TOPS，实际部署YOLOv8s输入640分辨率，在15W功耗模式下单帧耗时大约25到35毫秒，这个成绩在端侧已经算很能打了。

Jetson最大的优势是CUDA生态，PyTorch模型通过TensorRT转换非常顺滑，几乎每个主流模型都有现成的优化案例。这也是为什么大多数具身智能团队的首选方案都是Jetson，因为它能让你把注意力集中在算法本身而不是底层移植。

但Jetson也有一些典型的“富家子弟”毛病：整板功耗偏高，Orin NX在20W到40W之间波动，对电池供电的无人机来说压力不小；价格也不便宜，Orin NX 16GB模组就要三千块以上，加上载板、散热、外壳整套下来是一笔不小的预算。另外，NVIDIA在车规认证这块主要推自家的Drive系列，Jetson更多是“工业级”定位，长期在振动、宽温环境跑的可靠性需要自己做额外的筛选和加固。

2.2 瑞芯微RK3588/RK3576：性价比党的主力选择

如果预算是唯一硬约束，瑞芯微的RK3588绝对是绕不开的选项。它内置6 TOPS算力的NPU（神经网络处理单元），8核CPU，双ISP（图像信号处理器），支持多路摄像头接入，整板功耗可以控制在10W左右。这个配置在端侧机器人项目里非常实用，尤其是需要多传感器融合的中低算力场景。

RK3588的NPU走的是自家RKNN工具链，模型转换需要先把PyTorch模型导出为ONNX，再用RKNN-Toolkit2做量化、编译、验证。早期版本对Transformer类模型支持得不好，很多算子需要手写自定义OP，不过这两年迭代得很快，YOLO系列、PP系列、部分轻量级Transformer都已经支持得很好了。

另一个兄弟型号RK3576也很有竞争力，算力同样是6 TOPS，但能耗比更好，功耗可以做到5W级别。如果你做的是小型无人机或者轻量化手持设备，RK3576会比RK3588更合适。我在一个农业病虫害识别项目里用过RK3576，TinyML模型量化后跑得很稳，整机续航比之前用Jetson Nano的方案延长了将近一倍。

瑞芯微方案的优点是生态比想象中完善，Rockchip官方提供了丰富的驱动资料和示例代码，国内开发者社区活跃度高，遇到问题容易搜到解决方案。缺点是它的NPU工具链的调试体验和TensorRT还有差距，性能和精度的调试需要一点耐心。另外，RK3588的内存带宽只有约17GB/s左右，比Jetson Orin的102GB/s差了一个数量级，这对高分辨率多路视频处理会有影响，选型时需要重点评估。

2.3 国产算力芯片：算能、地平线、寒武纪各有各的脾气

除了瑞芯微之外，国内做端侧AI芯片的还有好几家，我实际接触过的有算能、地平线、寒武纪，简单聊聊使用感受。

算能的产品线覆盖比较广，从几十TOPS的BM1684/BM1688到更低功耗的CV181x系列都有。BM1688是一颗很典型的边缘计算芯片，16 TOPS算力，约15W功耗，工具链是tpu-mlir，支持PyTorch模型转ONNX再转bmodel。我在地面无人车项目里用过BM1688，在算力、功耗、成本之间找到了一个不错的平衡点。它的PCIe和千兆以太网接口都比较齐全，方便做多传感器接入。

地平线的征程系列（Journey）在智能驾驶前装市场占有率很高，车规级的安全性做得很扎实。但地平线对开发者社区的开放程度不如其他几家，很多时候需要通过他们的合作渠道申请开发资料，SDK的完整文档也不太容易直接获取。如果你做的是前装量产项目，这条路可以走；如果是高校实验室或者小型创业团队快速做原型验证，可能会遇到不少沟通成本。

寒武纪的思元MLU220我在一款工业巡检机器人上试过，算力有8 TOPS，功耗低至8W，支持FP16和INT8。不过寒武纪的工具链对PyTorch的版本比较敏感，模型移植时遇到过几次算子兼容问题，最终是通过改写部分网络结构绕过去的。这说明一个问题：在选国产芯片前，一定要把你自己的模型跑到目标开发板上跑通，拿“标称兼容”当依据是会有大麻烦的。

2.4 主力芯片横向对比表

这几款是我用得相对多的，整理成一张表，方便你按自己的需求快速对照。需要提醒的是，理论算力只是参考值，实际效果要以实测为准。

从这张表能看出来，Jetson系列主打高算力加成熟生态，国产芯片主打性价比和特定场景优化。选型时不要直接对标参数，要考虑整个系统——你的供电能力、散热空间、成本预算、团队对工具链的熟悉程度，这些因素综合起来，才能真正筛选出适合你的硬件平台。

3. 实测环节：从实验室到车/机载部署的关键动作

3.1 先把测试台架搭起来：供电、散热、基础系统

芯片到手不要急着跑模型，先把测试台架搭好。第一步就是确认供电方案。我建议准备一台可调直流稳压电源，带电压电流显示的那种，大概两百块就能买到。先设置一个接近实际使用场景的电压，比如车载环境模拟12V，观察板子在空载、满载时电压和电流的变化。用示波器看电压跌落幅度更好，如果跌落超过5%就要考虑加储能电容或者换更大功率的DC-DC模块。

散热设计在测试阶段就要对标目标场景。如果你最终要装在密封机箱里，现在就拿密封机箱测试；如果目标是车载，就模拟车内的气流环境。我见过太多团队在桌面用大风扇吹着测，一到实际工况就过热降频。测试时用温度记录仪贴在芯片表面、散热片、电感等关键位置，连续跑2小时压力测试，观察温升曲线。之前测RK3588，在自然对流环境下跑NPU满负载，10分钟内温度就冲到85度，再往上芯片会主动降频保护，推理帧率直接掉了四成。后来改了铝合金外壳配合导热硅脂，问题才算解决。

基础系统方面，Jetson刷NVIDIA官方SDK Manager的镜像就好，桌面版Ubuntu、JetPack版本选最新的LTS即可。RK3588系列国内很多开发板厂商都会提供定制镜像，推荐直接在板厂官网上找最新的镜像，省去自己折腾底板适配的麻烦。开机后先做好三件事：关闭不必要的桌面服务、设置日志轮转、配置systool。这一步看着很基础，但在长期无人值守的车载/机载运行场景里，这些设置能减少大量不稳定的概率。

3.2 模型导出、量化和编译的完整链路

模型部署是整个测试的核心环节，工具链不同，链路也不同，但思路是共通的：训练好的浮点模型要经过导出、转换、量化、编译，最终在目标硬件上高效运行。

Jetson的路子相对平滑。PyTorch模型先导出ONNX，再用TensorRT的trtexec工具根据GPU型号做engine编译。TensorRT支持FP16和INT8量化，FP16基本是无损的，INT8需要用真实数据做校正集，避免精度损失。我习惯用约300张覆盖各种光照条件的图像做INT8校正，单张图推理的精度下降基本能控制在1%以内。

RKNN-Toolkit2要先在Ubuntu上安装Python环境，然后按官方文档把ONNX模型转成RKNN模型。转换过程中有几个选项要重点调：量化模式（normal、weight_only、hybrid）、量化粒度（per-channel还是per-tensor）、target_platform（要选中你的具体芯片型号）。刚开始用默认参数转换，发现模型输出相比浮点版本误差偏大，检查后发现是量化粒度设成per-tensor导致的，改为per-channel后精度恢复明显。

算能的tpu-mlir工具链流程有些类似，但它的编译目标是把ONNX模型编译成bmodel格式，过程中同样有量化选项。这个工具链对PyTorch新版本算子的支持更新速度慢一些，如果你用了比较新的模型结构，建议先检查算子兼容性清单，不支持的算子尽早想替代方案。我在用BM1688时把Mamba类模型编译就遇到了算子缺失问题，最后只能把部分层改成卷积近似，精度代价还算可接受。

3.3 延迟、吞吐、功耗的实测方法

模型部署完成后，要做三类指标的实测：单次推理延迟、吞吐能力（多路并发）、整机功耗曲线。这三类指标的测量方法看似不难，但细节决定了数据的可靠性。

单次推理延迟，要区分预热后的延迟还是冷启动延迟，前者代表系统稳定运行时的性能，后者常被低估。我用Python写一个循环，先预热20帧，再连续跑200帧，记录每一帧的推理耗时，计算P50、P90、P99分位数。为什么看分位数而不看平均值？因为端侧系统的调度抖动很大，偶发的长尾延迟才是体验杀手。P99值如果超过你的帧预算，在关键时刻就会丢帧。

吞吐能力的测法取决于业务形态。如果是单路高性能场景，重点看单帧延迟；如果是一个芯片处理多路传感器，要测试同时跑2路、4路感知任务时的总吞吐和相互干扰程度。我之前测Orin NX同时跑两个检测模型，整体吞吐量接近线性扩展，但内存带宽接近瓶颈后，第二路模型的延迟明显上升，这说明在规划算力时一定要给内存带宽留余量。

功耗测量用可调电源的实时电流电压数据即可，一秒记录一次。更细的方法是通过板卡自带的传感器读取芯片功耗，比如Jetson的tegrastats工具能直接看到CPU/GPU的实时频率和功耗。我测Orin Nano跑YOLOv8s，发现空载功耗约3W，满载约18W，功耗爬升的曲线非常陡峭。如果你在做纯电池供电的无人机，这个功耗会直接影响续航，需要在整机设计阶段就纳入预算。

3.4 把台架“搬到车上”：震动、温度、供电波动实测

实验室测完，只是完成了第一步，真正过硬的还必须真实环境实测。我的做法是装一台移动测试车，把设备固定在减震支架上，跑一段包含铺装路、减速带、颠簸土路的路线。重点观察三件事：第一是接口松动和电源接触问题，很多开发板在震动环境下USB摄像头画面会周期性断开，多半是接头接触不良；第二是闪存写入错误率，车载振动环境下SD卡和eMMC的性能会波动，要尽量选车规级存储，或者全程用内存文件系统记录日志；第三是长期运行稳定性，让设备连续跑24小时以上，观察是否有程序崩溃或硬件复位。

机载环境还要额外测试低温和低压环境。不少芯片标称工作温度是-20度到70度，但低温启动时电源纹波会明显增大，低温从冷的存储芯片读取数据有可能触发校验错误。飞控和算力板之间的通信在这种环境下也会出现丢包。我之前测试无人机载方案时，把整套系统放进温箱做过一轮-10度到50度的循环测试，抓出来一个低温下LTE模块无法注册网络的bug，这种问题如果在空中才暴露，代价就太大了。

4. 避坑清单：我这两年踩过的硬件选型坑

4.1 散热降频：标称算力会“打折”

散热降频是所有算力板都会遇到的问题，只是程度不同。Jetson在默认模式下有完整的功耗和温度管理策略，温度到达阈值会自动降频；RK的NPU同样有温度保护，但触发策略没那么细腻，有时会出现性能突然掉到很低再到恢复的“锯齿状”波动。

应对思路有三层：第一层在选型阶段，预留足够散热设计余量，把目标环境的极端温度纳入考量；第二层在软件层面，提前锁定功耗模式，比如Jetson用nvpmodel选择一个保守档位，并配置jetson_clocks固定性能策略，避免系统在高低功耗之间频繁跳变；第三层在系统层面，给关键任务设置超时保护，一旦检测到推理延迟超限就主动降级任务，而不是等系统自己崩溃。散热降频不是bug，它是物理规律，我们要做的是把它纳入系统设计考量范围。

4.2 内存带宽与数据搬运能力

这是最容易被忽略的指标。很多人在选型时只看TOPS，但端侧AI的真实瓶颈往往在内存带宽。你可以把TOPS理解为“计算工厂”的日产能，内存带宽是工厂里运输货物的道路宽度，产能再高，原料和成品运不进来运不出去也是白搭。

Jetson Orin系列内存带宽非常高，能够支撑多路高分辨率视频和多模型并发；而RK3588的内存带宽只有约17GB/s左右，跑单路模型问题不大，一旦多路数据同时涌入，数据搬运就会成为瓶颈。实测RK3588同时跑3路1080P解码加一个分割模型时，CPU占用率和内存延迟明显上升，推理帧率掉了将近一成半。所以在高分辨率、多路传感器场景下，优先考虑高内存带宽方案；而在模型本身较小、输入分辨率不高的场景下，国产平台的高性价比优势就体现出来了。

4.3 工具链和生态陷阱

工具链的成熟度决定了你的开发效率，这一点怎么强调都不过分。同样是模型部署，TensorRT的成熟度高，社区案例多，遇到问题一搜就有答案；国产工具链这几年进步很快，但在模型覆盖、调试工具、文档完整性上还有差距。选型前一定要用你真实的模型跑通整个链路，包括转换、量化、部署、精度验证，这个测试做得越早，后期项目返工的风险就越小。

还要警惕“半开源”生态陷阱。有些芯片厂商宣传支持PyTorch，实际上只支持旧版框架，或者只支持模型结构中有限的一部分算子，遇到不支持的算子要么等官方更新，要么自己写自定义算子。我的经验是，凡是冷门模型结构或者刚发不到半年的大模型，都不要假设它能顺利部署到端侧，优先选择流行的、久经验证的骨干网络，等产品跑通后再逐步升级模型结构。

4.4 选型前的风险评估清单

根据自己的实测经验，整理了一份选型前的风险评估清单，供参考：

这张清单看着简单，但每一条我都付出过真金白银的代价。尤其是工具链兼容性和散热方案这两项，一旦选错，后期的返工成本远超过硬件本身的差价。

我在实际选择硬件时，最后的判断标准其实很朴素：团队里谁最熟悉这个平台，谁就能把项目带到终点，算法的人、部署的人、嵌入式的人坐在一起，用真实模型完整测试一遍，比看一百遍参数表都管用。端侧AI硬件选型没有绝对的“最好”，只有“你的场景下最合适”。多花一周在选型测试台架上，可能省下后面三个月的联调时间，这笔账怎么算都划算。