具身智能端侧AI算力芯片选型实战指南：避开TOPS陷阱

如果你正在为自己的具身智能机器人项目挑选端侧AI算力芯片，大概率会经历和我一样的循环：打开几十个数据手册，翻遍所有测评，对比TOPS、TDP、内存带宽，最后把板卡装上车/机载体，实际跑起来却发现根本不是那么回事。我当初就吃过这样的亏——按标称算力去选板子，几万块的开发板装进机器人本体，结果一开机就降频，模型推理掉速一半，电机一启动电源电压猛地跳水，Debug到后半夜才意识到问题根本不在算法层面。这篇文章把我这两年做端侧AI硬件部署和具身智能车载/机载平台选型的经验完整梳理一遍，包括算力芯片怎么挑、硬件怎么验证、哪些参数是纸面指标、哪些才是真正的系统性瓶颈，以及一张可以直接拿去用的选型评分表。如果你是正在做车载/机载计算平台选型的工程师、机器人方向的团队负责人，或者是刚准备进入这个领域的在校学生，这篇指南应该能帮你把坑提前避掉。

1. 先想清楚:端侧AI算力选型为什么比攒台式机难这么多

1.1 端侧AI和云端AI完全是两码事

在云端做模型推理的时候，你有近乎无限的GPU集群，卡不够了可以随时加几张，电费和机房散热都有人替你操心，程序崩了大不了重启容器，环境变量随便造。但在具身智能本体的端侧，一切都是受限的:算力有限、内存有限、功耗有限、散热空间有限，而且系统跑起来之后不能随便重启，更不能指望网络连到云端去兜底。

我习惯拿"中央厨房和流动餐车"来打比方。云端的GPU集群是中央厨房，场地、水电、排烟设备都不愁，想做什么菜都可以敞开了做;端侧AI就是流动餐车，车上的燃气罐就那么大，灶台就那么大，能颠的勺也就那么大，你非要按中央厨房的规格配菜，那结果就是还没出摊就断电了。具身智能机器人尤其特殊，它不是一台固定摄像头对着一个固定区域做识别，而是要跟着本体一起移动，要在电机转动、轮子颠簸、供电波动的情况下连续完成感知、决策、控制，整个生命周期内所有算力都得在"餐车"上自己解决。

所以端侧AI选型的第一课是:先把"云端思维"丢掉。一个在GPU服务器上跑得飞快的模型，到了端侧可能连跑都跑不起来，或者说能跑起来但是帧率感人。你需要关注的不只是模型推理那一瞬间的算力，而是整个系统在真实运动过程中持续输出的有效算力。

1.2 车载/机载环境的约束比想象中苛刻得多

一个做纯室内边缘计算设备的人，可能很难理解车载/机载环境的恶劣程度。这里说的"车载/机载"泛指具身智能载体，包括轮式底盘、足式机器人、机械臂本体、无人机平台，这些环境有几个共同点:

温度范围广。室内实验室可能常年恒温，但机器人本体一旦去户外巡检，夏天车舱里温度可能到50摄氏度以上，冬天北方直接零下20度。很多民用级板卡的标称工作温度只有0到50度，装上车面对高温直接降频保护，算力自动衰减。我实测过某板卡在夏天密闭机箱里跑二十分钟，核心温度冲到85度，推理帧率掉了将近30%。

振动和冲击持续存在。轮式底盘过减速带、足式机器人落脚的瞬间、无人机起飞降落的震动，都会传导到计算板卡。如果散热器只用螺丝松散固定，或者内存条/硬盘没有做抗振处理，连续跑几天之后可能莫名其妙出现M.2硬盘掉盘、内存读写报错这类"玄学问题"。多轴机械臂运动时带来的高频振动更容易导致板卡接触不良。

供电非常不干净。这是新手最容易忽略的。机器人底盘里的驱动电机、舵机启动瞬间会产生很大的电流冲击，同一块电池母线电压可能被拉到很低，然后又弹回来。算力板卡对这种电压波动极其敏感，一秒钟几百毫伏的跌落都可能导致系统重启或者死机。后面我会专门用一个章节讲这个坑。

1.3 具身智能负载比传统边缘AI复杂得多

传统边缘AI设备往往只需要跑一路视频流，做面部识别或者车牌识别，负载是固定的，吃满算力也就那样。具身智能不一样，它同时要处理的东西太多了:至少一路到多路摄像头流做目标检测、语义分割，同时跑一个SLAM在做定位建图，还要有路径规划模块计算避障轨迹，如果有语言交互需求，还得挂一个端侧大模型，最后所有信息汇聚到一个运动控制节点，以50到500Hz的频率输出控制指令。

这些负载叠加在一起，对算力芯片的压力是"并发型"的，不是按顺序排队执行的。选型如果只算单个模型推理的TOPS，就会导致后期系统集成时CPU和NPU/GPU同时抢资源，互相拖累。我见过一个项目，选型时用YOLOv8单模型在开发板上跑到一百多FPS，以为性能绰绰有余，结果装上SLAM、导航规划之后整机帧率掉到二十几，根本没法用。所以具身智能的算力选型，一开始就得按"整机多任务并发"的需求去算账，而不是按单模型指标去算。

2. 选型第一步:把负载拆成一份可以量化的清单

2.1 从使用场景推导算力需求

很多团队选型失败，不是因为最后挑错板卡，而是因为他们根本没想清楚自己到底要跑什么任务。拿到需求之后，第一步不是对比板卡参数，而是先把"机器人要做的事情"拆成一个个可度量的算力单元。

举个实际例子。假设你要做一台园区巡检轮式机器人，那负载清单可能是这样的:

• 两路800万像素摄像头，做人员和障碍物检测，目标检测模型算力需求按实时20帧估算;
• 同时做语义分割，区分草坪、石子路、柏油路，按10帧估算;
• 跑VINS-Fusion或者ORB-SLAM3做视觉里程计，这部分主要吃CPU，也吃一点GPU做特征提取;
• 激光雷达数据融合和路径规划算法，主要吃CPU单核性能，算法复杂度跟地图大小相关;
• 如果需要语音告警或者语音交互，还需要预留一部分算力跑语音识别和TTS;
• 整机系统包括ROS2主进程、电机关机驱动、日志记录，又占掉一部分CPU。

把这份清单写好之后，再对应到具体模型的推理耗时，就能得到一个大致的算力需求区间。这里的核心原则是:不能拿峰值负载去选型，也不能拿平均负载去选型，要按"最恶劣任务并发场景"加20%到30%余量来选。

2.2 功耗、重量、体积、成本组成的硬约束

算力需求只是目标的第一步，紧接着就要面对功耗和成本约束。很多团队卡在这一步:选了一款理论上算力完全够用的板卡，结果发现机器人电池根本扛不住，或者板卡太大塞不进机壳。

功耗预算可以做一个很简单的估算。一块板卡标称TDP 25W，整机其他模块（传感器、工控机、电机驱动器、无刷电机本身）加在一起按60W算，整个机器人平均功耗大约85W。如果机器人要连续工作2小时，那么电池至少需要提供170Wh的容量。一块12V 15Ah的锂电池，可用能量大约在150到160Wh（锂电池不能放干），只够支撑不到两小时。如果选型时没算这笔账，最后机器人的续航能力会被用户骂死。

重量和体积同样关键。无人机对这种约束感受最深:每多100克，续航就肉眼可见地下降。针对机载场景，有时不得不牺牲一部分算力去换重量，比如用Orin Nano而不是Orin NX，用核心板加转接板而不是整块开发板。我自己的经验是，在做结构设计之前就要和机械工程师对齐板卡的三维尺寸、固定孔位和散热器高度，千万别等结构开模之后才发现板卡装不进去。

成本是另一个容易被忽视的硬约束。同样是工业级Jetson，Orin AGX的价格可能是Orin Nano的五六倍，如果项目本身是面向教学场景或者消费级产品，这个成本差距直接决定了选型方向。因此在选型清单里，一定要写清楚"整机量产BOM成本上限"，再反推算力板卡可接受的价格区间。

2.3 内存带宽与算力的匹配:容易被忽略的一个数

我见过太多人选型只看TOPS，完全不看内存带宽。算力芯片的TOPS指标只代表它理论上能做多少次运算，但数据从内存搬运到计算单元、再从计算单元写回内存，这个通道的宽度往往才是真正的瓶颈。

可以看一个简单的类比:算力相当于一个厨师切菜的速度，内存带宽相当于传菜通道一次能端几盘菜。厨师刀法再好，传菜通道一次只能端一盘菜，整个出餐速度也被传菜速度卡死了。在模型推理场景里，卷积、矩阵乘法这类运算对数据复用率不低，但随着模型规模变大、输入分辨率变高，内存带宽的压力会急剧上升。

实测中这个问题特别明显。在Jetson Orin Nano上跑YOLOv8m，输入分辨率从640提升到1280，帧率不是跌一半，而是直接跌到原来的四分之一。TensorRT优化后有好转，但内存带宽仍然决定了推理耗时的下限。选型时建议把这三样东西放在同一张表里看:TOPS算力、内存带宽（GB/s）、内存容量。最优的组合不是某一项特别高，而是三者匹配。

2.4 工具链和生态的权重:决定开发周期

算力芯片最终要落地，靠的是开发工具链。同一款芯片，官方SDK写得好不好、社区资料多不多、有没有现成的ROS2包，直接决定了你的研发周期是从三个月变成三周还是从三周变成三个月。

NVIDIA之所以在端侧AI领域占据统治地位，核心不是它的硬件强到不可替代，而是CUDA生态和TensorRT推理框架实在太成熟了。PyTorch模型导出ONNX再到TensorRT，踩坑再少也有人帮你解决，社区里随便一搜就是一大把完整的工程案例。相比之下，一些国产算力芯片的推理框架还在快速迭代阶段，算子兼容性经常变化，可能这个月能转换的模型，下个月SDK更新之后反而报错了。

但生态的权重也要分场景。如果你的算法团队深度学习实力强，愿意在模型转换上花时间;或者你的模型结构固定，只需要转换一次;那么生态成熟度的权重可以稍微降低一点，因为你不需要频繁踩坑。反过来，如果团队主要精力都在业务逻辑上，那还是老老实实选一支工具链最成熟的芯片，少给自己找麻烦。

3. 主流算力芯片平台的实测对比

3.1 NVIDIA Jetson Orin系列:生态上限和过热表现

Jetson Orin系列是目前具身智能项目最常出现的平台，尤其是Orin Nano 8GB和Orin NX 16GB这两款，基本是大多数团队的优先考虑对象。

我实测下来，Orin Nano 8GB跑YOLOv8s，输入640×640，TensorRT FP16优化之后大约能到60到70FPS，在低功耗模式下功耗控制在10W到15W之间。这个性能对于轻量级感知任务是完全够用的。Orin NX 16GB则强一个档次，同样模型可以跑到140FPS以上，而且能同时挂一路语义分割模型、跑一个轻量级VLM，整机压力不会太大。Orin AGX当然更强，但它那功耗和体积在车/机载平台上并不讨喜，除非你做的本来就是无人车这种体量的载体。

Jetson Orin系列最大的坑是散热。官方数据手册上的TOPS是在理想散热条件下测出来的，实际放进密闭机箱，如果不做主动风冷或者液冷，持续高负载必然降频。我自己的Orin NX开发板在实验室开放式平台上能跑满，装进外包铁皮机壳里加了一路小风扇，温度和裸奔对比差了十几度，帧率稳定度明显提升。这个后面详细说。

3.2 瑞芯微RK3588:性价比和NPU的真相

RK3588是另一款在端侧AI硬件部署里非常常见的芯片，8核CPU配6 TOPS NPU，价格只是Jetson Orin Nano的一半甚至更低，功耗也低不少。对预算敏感的团队、教学场景、低成本消费级产品来说，它的吸引力非常大。

但RK3588的NPU和NVIDIA的GPU是完全不一样的架构，编程模型受限于瑞芯微的RKNN工具链。实测RK3588跑YOLOv5s，RKNN-Toolkit转换优化后大约能到35到45FPS，跑YOLOv8s的话因为某些算子限制，效果会差一些。注意，这个性能是在INT8量化前提下测出来的，如果你需要的精度级别不允许量化为INT8，那RK3588的NPU优势就大打折扣，你可能只能退回去用CPU/GPU跑FP16，性能会崩得很厉害。

RK3588另一个优势是接口非常全，网口、USB3.0、PCIe、CAN都有，作为机器人主控板来用很方便。很多机器人主板就是围绕RK3588做的，整机集成度高，不用自己去画转接板。适合的场景是"任务负载相对固定、模型不大、预算有限"的具身智能项目。

3.3 算能、地平线、昇腾:国产算力芯片的真实水平

除了NVIDIA和瑞芯微，国产算力芯片最近两年确实在快速追赶，我在一些特殊项目里也实测过，说点真实感受。

算能BM1684X标称32 TOPS INT8，峰值算力比RK3588高不少,实际跑YOLOv5系列模型帧率不错,但问题在于SDK和文档的成熟度。它的推理框架支持ONNX转BModel,对于比较标准的检测模型转换成功率尚可,一旦模型结构复杂一点,算子兼容性就会让你头疼。而且社区案例相对少,出了问题能搜到的解决方案不多。它适合大平台团队,有足够的内部AI工程师去填坑。

地平线的征程系列严格来说更偏向车载场景,征程6系列算力标得很高,而且对Transformer类型的模型做了一些深度优化。但征程的开发和部署工具链相对封闭,OpenExplorer要申请、文档不够开放,如果团队对它不熟悉,学习成本相当高。它在车规级量产项目里的确很强,但放在创客型的具身智能项目里,可能不是最顺手的选择。

昇腾平台的Atlas 200I DK A2也是可以看的方案,标称算力不错,配套的CANN工具链文档很多,有昇腾社区官方维护。但是我实测下来,CANN的上手曲线比TensorRT陡不少,很多跑在PyTorch里的算子需要通过昇腾的算子适配层转换,中间可能因为算子不匹配报错。如果你的团队主力是PyTorch深度用户,上昇腾之前一定要留足踩坑时间。

3.4 实战对比指标表

我把这几款平台在"端侧AI硬件部署和具身智能选型"场景下比较关心的指标整理成了一个表，里面是个人实测和项目复盘的结论，只能代表我接触到的硬件版本和固件版本，实际数字会因环境、散热、模型、固件不同而有差异，但量级和规律是稳定的。

选型时一定要记住:表中的帧率都是单模型优化后的结果，真到具身智能整机上要打折。我自己的经验是，整机多任务并行的情况下，这个帧率打六到七折才是真实可用值。

4. 实测中踩过的那些坑:从散热、供电到推理框架兼容

4.1 散热方案决定"纸面算力"能用出几成

这是我在具身智能硬件部署中感受最深的一个坑。Jetson Orin这类芯片的降频策略非常激进，核心温度一过温度墙，跑分立刻掉一个台阶。我在实验室裸板上测试Orin NX，边跑边顺手敲了下tegrastats，能看到CPU和GPU频率在温度上来之后自动往下调，整机功耗也从25W附近一路滑到12W左右。

分享一段我常用的温度监控命令:

watch -n 1 cat /sys/class/thermal/thermal_zone0/temp

这条命令每秒读一次当前主热区的温度，数值是毫摄氏度，除以1000就是摄氏度。我在实测中发现，密闭机箱里温度爬到85度以上以后，YOLOv8s的推理帧率会从稳定帧率掉到开盘帧率的三分之二以下，而且掉的幅度和温度是线性相关的。那段时间我一度以为是模型优化出了问题，后来把机壳侧盖拆开，拿个小风扇对着板卡吹，帧率立刻回来了——问题根本不在代码。

正确的做法是在结构设计阶段就留好风道：进风口在低处，出风口在高处，风扇对着散热鳍片吹而不是对着散热器侧面吹。如果空间实在紧张，可以考虑用均热板把芯片热量导到机壳金属外壳上，让整个外壳变成散热器。另一个很有效的操作是给系统设置功耗上限，比如在Jetson上用nvpmodel切换到更低的功耗档位:

sudo nvpmodel -m 8

-m 8对应的具体档位因设备而异，但原理是一样的:把最大功耗限制住，温度就不会一路狂飙，综合下来系统能维持一个更稳定的帧率。对于长时间运行的任务，稳定比瞬时峰值更重要。

4.2 供电不稳导致的"随机死机":排查了一周才找到原因

还有一个几乎能让人崩溃的坑是供电。我在一台轮式底盘上装了一块Orin NX开发板，实验室空载怎么测都稳定，一旦上底盘跑起来，每次连续运动十几分钟必定随机重启一次。一开始我怀疑是软件问题，把系统日志翻了个底朝天也没找到关键报错，后来无意中用一个直流稳压电源单独给板卡供电，跑了两个多小时都没重启，才定位到是底盘母线供电的问题。

这里面的物理机制其实很简单:底盘电池同时给驱动电机和算力板卡供电，电机启动瞬间需要大电流，电池内阻和线缆电阻上有压降，母线电压会瞬间被拉低。如果压降超过了板载电源模块的输入范围，板卡就会触发欠压保护或者直接掉电重启。

解决这个问题的方案有三种，成本从低到高排列:

1. 在板卡电源入口并联一个大容量电解电容和几个陶瓷电容的组合，给瞬态电流一个缓冲;
2. 用一个带一定余量的DC-DC电源模块独立给算力板卡供电，让前级电压波动不要直接传导到板载DC-DC的输入;
3. 如果条件允许，干脆给算力板卡用一块独立的小电池，彻底和电机母线隔离。

我当时在板卡供电线上加了一个输入范围9到36V、输出恒定5V/20W的隔离电源模块，之后车载实测就再也没有随机重启过。这个问题如果能早一点怀疑供电，能少熬好几天夜。

4.3 内存带宽瓶颈:为什么模型跑起来比纸面算力慢一半

前面提到过内存带宽问题，这里展开说说实测的感受。算力芯片标出来的TOPS，通常是在连续计算、数据全部加载到寄存器或片上缓存里测出来的，但真实模型推理时，每一层都要从内存读取中间特征图。

我在Jetson Orin Nano上实测过同一个YOLOv8s模型，FP16和INT8推理时延差异比预期的明显。FP16模型虽然精度好，但中间特征图占用的显存带宽大，推理帧率有时候只有INT8量化模型的一半左右。不能说FP16一定不好，但如果你对精度不是极度敏感，建议把INT8量化作为优先考虑方向，特别是端侧算力本来就是紧绷的情况下。

TensorRT可以做层融合和显存池优化，能把带宽利用率提上去不少。我在工程里通常先导出一个静态batch的TensorRT engine，而不是在运行时做动态shape推理，动态shape虽然灵活，但实测会多出不少显存分配和算子调度开销。固定输入分辨率、固定batch size，对端侧系统来说往往能带来百分之二三十的帧率提升。

4.4 模型转换与算子兼容:ONNX/TensorRT的边界问题

模型转换是具身智能端侧AI部署绕不开的最耗时环节。PyTorch模型在GPU上跑得好好的，导出成ONNX，再转TensorRT或者RKNN，中间可能因为一个不支持的算子卡住。最常见的坑包括:自定义算子、动态shape、torch.where、einsum、某些注意力机制的变形实现，这些在端侧推理框架里经常找不到对应实现。

我的建议是:算法选型和硬件选型同步进行，在定算法模型结构之前就去查目标推理框架支持的算子列表。如果发现目标模型里有不支持的算子，提前和算法同学沟通，用等价的结构替换掉——比如把一些复杂的注意力改成标准的torch.nn.functional.scaled_dot_product_attention，或者把动态shape改成固定shape填充，损失一点灵活性但换来部署顺畅。

如果需要简化ONNX模型，我常用的工具是onnx-simplifier:

python3 -m onnxsim input.onnx output.onnx

onnx-simplifier能做常量折叠、冗余节点消除，很多时候能解决转换失败的问题。如果转出来的模型算子仍然不兼容，再用推理框架自带的调试模式去看具体是哪个节点不支持，不要傻乎乎地猜。踩过一次坑之后的最深体会是，模型转换的工具链要早试，不要在机器人整机集成之后再发现转不过去，那时候的返工成本是灾难级的。

5. 具身智能典型负载在端侧的实际部署表现

5.1 视觉目标检测与分割模型在端侧的表现

视觉感知是具身智能最基本也最刚性的算力消费模块。我自己的习惯是先把视觉模型按"主干网络大小"分成三档:轻量级(YOLOv8n/YOLOv5s)、中量级(YOLOv8s/RT-DETR-l)、重量级(YOLOv8m或更高)。在Jetson Orin Nano上，轻量级模型配合TensorRT FP16可以轻松跑到100FPS以上；中量级模型以我前面提到的YOLOv8s为基准就是60到70FPS；重量级模型已经非常吃力，经常只有20到30FPS。在RK3588上轻量级模型量化后可以跑出不错的帧率，但重量级模型的量化转换往往伴随着精度掉点，需要花时间做校准集迭代。

对机械臂这种需要非常精准抓取位姿的场景，视觉模型通常不只需要语义类别，还需要关键点热图或者边界框的亚像素精度，这类模型推理成本高，对输入分辨率也敏感。我建议在这种场景下优先选择支持TensorRT FP16同时带DLA加速的Jetson平台，或者干脆把高分辨率感知任务拆成"低分辨率全局检测+高分辨率局部裁剪精修"两级流水线，降低端侧推理压力。

5.2 SLAM与局部感知的实时性

SLAM大概是具身智能任务里最容易被低估算力开销的一块。很多团队选型的时候只盯着视觉检测模型，觉得TOPS够了就行，忘了VINS-Fusion、ORB-SLAM3这类算法同样需要不小的CPU算力。实测中，一个400×400分辨率、50Hz相机输入的VINS-Fusion，光特征提取和状态估计就可能占用两个到四个小核，整机CPU负载直接飙升。

无人机悬停或者车辆低速行驶，SLAM频率还能忍;但一旦本体运动速度快、场景纹理稀疏，算法对帧率的要求更苛刻，视觉惯性紧耦合还要求IMU数据在毫秒级内到达，这就很考验计算板卡的中断响应和多线程调度能力。在端侧跑SLAM我学到的经验是把预览、特征提取和状态估计分线程布置，给关键线程配上实时调度优先级，然后在整机上反复调一遍内存分配，因为SLAM的卡顿往往不是算力不够，而是内存分配和调度延迟导致的。

5.3 端侧跑大语言模型(VLM)和视觉语言动作模型的现实选择

这应该是去年以来最热的技术话题，很多团队希望直接在机器人本体上跑7B甚至13B参数的大语言模型或者视觉语言动作模型(VLA)。我的首要建议是:先算算显存账。7B模型即使4bit量化，权重也要占用约3.5到4GB显存，再加上KV Cache和中间激活，至少需要6GB以上可用显存。在Orin NX 16GB上勉强装得下，但推理速度大概率只能在每秒几到十几个token，对于实时决策来说还是太慢，根本没法让机器人React快。

实际上，我更偏向"大小模型结合"的方案:用一个轻量级的视觉感知模型做物体定位和状态估计，用一个1.5B到3B参数左右的小语言模型处理语义指令和任务规划，只在遇到特别复杂的场景时，才短暂调用更大规模模型，而且往往只把它部署在远程或者允许接受更高延迟的环节。具身智能本体对动作响应的实时性要求太高，端侧跑大模型这件事，目前更适合做"离线辅助决策"而不是"实时刻画"。

当然，如果是做实验性质的机器人，不追求实时控制闭环，那么在Orin NX/AGX上跑一个量化后的7B模型完全可行，但要接受它的推理延迟。做产品、做服务的团队，建议以稳定可靠的小模型组合为主，VLA模型先放在实验室环境里跑。

5.4 运动控制和高频通信对算力主机的系统开销

还有一个容易忽略的点:算力芯片不只是给AI模型用的，它同时还得当整车的"大脑"，跑运动控制、传感器驱动、无线通信、日志记录。ROS2在这类系统中的开销比很多人想象中大得多，尤其当你用默认的DDS配置开一堆话题、加很多节点的时候，CPU占用率高得离谱。

我见过一个项目，一台Orin NX整机CPU占用率长期在80%以上，怎么优化AI模型都没用，后来发现是ROS2的底层通信栈默认配置开了太多不必要的发现协议，导致每个节点都在广播。调小话题频率、按需配置QoS之后，CPU占用率降了二十个百分点，AI推理的实时性也明显改善。所以选型时不能把算力全部分配给AI，要留出一部分CPU余量给系统本身，这个余量我觉得至少要有百分之二十到三十。

高速运动场景下，如果你还有多路传感器和运动控制单元要同步，那整个系统的实时性往往还会受限于通信架构，而不是芯片算力。车载/机载算力板卡的GPIO、CAN、串口、EtherCAT接口的稳定性和实时性能，也要在选型时纳入评估，别只看AI算力。

6. 最终的选型决策方法:一张评分表解决纠结

6.1 不同具身智能场景的推荐配置参考

根据我接触过的项目，整理几种常见场景的参考配置:

低成本教育机器人、竞赛机器人:如果预算有限，RK3588方案最合适，核心板加扩展底板方案成熟，价格低，功耗友好，带CAN口，适配大学生机器人竞赛和STEM教育场景。如果预算稍高，Jetson Orin Nano 8GB是体验更平滑的选择，因为它可以直接用CUDA/TensorRT生态，学生毕业后衔接工业项目也更容易。

园区巡检、配送机器人:建议直接选Jetson Orin NX 16GB。这类机器人传感器数量多、任务并发度高，需要同时跑感知、SLAM和导航，Orin NX的16GB统一内存和较高的内存带宽在这种并发场景下优势非常明显。散热做好、电源隔离做好，整机稳定性会很高。

无人机、小型机载平台:重量和功耗是第一约束。可以考虑Jetson Orin Nano低功耗模式配合专门设计的载板，或者算能BM1684X如果团队SDK能力强、需要国产化。为了减轻重量，可以适当牺牲输入分辨率而不是牺牲帧率，因为无人机控制对延迟极敏感。

工业机械臂、产线具身智能:如果追求稳定和实时性，且算力需求中等，Orin NX系列仍是稳妥选择;如果涉及车规/工规认证，尤其未来要量产上车，可能要考虑地平线征程这类车规级方案，但要预留足够的工具链消化时间。

6.2 一张评分表模板:把选型从玄学变回工程

面对多块板卡纠结时，与其每天晚上看各种测评文章，不如把它当成一道打分题。我自己习惯用下面这张评分表，按具体项目情况调整权重。

每一项按1到10打分，乘以权重后求和，总分高的就是当前项目相对合适的平台。权重怎么设?取决于项目的真实优先级——如果你的团队对工具链完全陌生，那工具链的权重就应该提到30%以上;如果项目再过三个月要量产，成本权重就应该拉满。

我最后想分享一个笨但特别有用的建议:选型阶段一定要同时买两块候选板卡回来，用你未来项目里最核心的几个模型，在板卡上跑一份真实的整机压力测试，记录帧率、功耗、温度随时间的曲线，至少连续跑24小时以上。很多纸面上看起来不错的板卡，跑过24小时高温连续性测试之后就会原形毕露。这个测试花费的时间和买板子的钱，相比整机集成后再出问题的返工成本，简直不值一提。我在个人项目里的习惯也是先做通这个小流程，再决定批量方案，结果省下的麻烦远超预期。