前阵子调试一台轮式机器人同一块 Orin 从 25 度的开放桌面挪进密闭机箱后端到端视觉吞吐肉眼可见地往下掉测下来只剩六成不到。这件事本身不新鲜真正让我头疼的是网上绝大多数端侧 AI 选型文章翻来覆去只会念叨板子标称多少 TOPS、支不支持某个框架真正到了把模型搬上整机、在车载或机载环境里稳定跑起来的阶段几乎没人提醒你功耗墙、散热、供电跌落和工具链稀疏算力这些“暗坑”。这篇东西就围绕具身智能领域的车载/机载算力芯片选型展开。我不会只给你列型号和参数我会把过去踩过的坑、做过的实测、以及现在团队内部默认的一套端侧硬件评估流程整理出来。无论你是做服务机器人、人形机器人预研还是给无人机、无人车配端侧感知盒子这篇都值得给你省几周调试时间。先提醒一句算力芯片选型从来不是单纯选芯片而是选一整套能跑通模型、扛得住环境、接得上机械和电气系统的方案。1. 别只盯 TOPS先给具身智能的算力需求画张分解图很多人选端侧 AI 芯片第一句话就是“我要多少 TOPS”。但具身智能系统和纯摄像头盒子不一样它身上跑的不是单一神经网络而是一整套感知、定位、规划、控制链路。每部分负载对计算资源的需求形态完全不同只在“TOPS 大不大”上较劲最后选回来的平台一定会在某个环节掉链子。1.1 感知、规划、控制三类负载吃的是三种“算力”先拆开看负载形态感知负载视觉目标检测、分割、BEV 构建、占据网络是典型的密集矩阵计算ONNX/TensorRT 里的卷积和 Transformer 算子占大头这部分的算力指标主要看 NPU/GPU 的 INT8/FP16 峰值吞吐。定位建图负载视觉 SLAM、激光 SLAM、VIO看起来也是“算法”但它里面有大量特征点提取、图优化、协方差更新这些逻辑既有矩阵运算也有大量分支和稀疏内存访问光靠 NPU 跑不干净很多时候得靠 CPU 拉满、GPU 打辅助。规划与控制负载MPC、NMPC、机械臂逆解、伺服插补对算力总量要求不高但对实时性极敏感。机械臂关节控制周期通常做到 1kHz意味着从传感器采样到控制指令输出必须控制在 1ms 甚至更低。你压根不该让这种任务和视频推理抢同一个 CPU 时间片。所以你在选型表里看到一颗 200 TOPS 的芯片时先别高兴。你要问的是这 200 TOPS 有多少能分配给视觉感知这颗芯片的 CPU 能不能同时扛住 SLAM 和调度它有没有独立的实时核或者锁核手段1.2 从标称算力到有效算力精度和稀疏性的门道继续说 TOPS 本身。很多芯片标称的 TOPS 是 INT8 精度、且假设模型结构支持 2:4 结构化稀疏之后的理论值。拿 NVIDIA Jetson AGX Orin 举例官方最显眼的数字是 275 TOPS但你要看小字——那是 INT8 稀疏算力。如果你部署的模型没有做结构化剪枝和稀疏化框架根本触发不了稀疏计算单元实际可用的 INT8 算力可能得按一半甚至更低来估。再往下抠还有频率稳定性的问题。芯片标称 TOPS 通常对应最高加速频率但端侧设备不是数据中心没有恒温恒湿环境。温度一高、功耗一到墙NPU 频率就会往下拉实际吞吐可能掉 20% 到 40%。这就是为什么我强调“有效算力”而不是“标称算力”有效算力 标称算力 × 精度折扣 × 稀疏支持折扣 × 长时间运行频率保持率。1.3 车载机和机载平台的物理约束差异同样一颗芯片放在车载和机载平台上选型逻辑也不同。车载场景最大优势是空间、重量和供电相对宽裕12V 或 24V 整车电源能给出几百瓦余量散热可以塞风冷甚至水冷算力板可以做得比较厚实。但车里温度环境更恶劣——仪表台在夏天暴晒后可以到 85 度以上而且没有主动散热时被动散热设计再强也有极限。机载无人机、eVTOL、系留机则完全是另一套逻辑。重量预算按克算散热不能靠大散热片功耗直接决定续航。每一瓦功耗对飞行器都是续航缩减很多机载平台甚至需要按峰值功耗跑到 40% 以下来换取控制器不过热。这种场景下“150 TOPS 板卡功耗 60W”和“100 TOPS 板卡功耗 30W”你会怎么选答案不一定但至少要考虑清楚环境边界而不是纸上谈兵比算力。2. 主流端侧平台横评哪些芯片能放进机器人而不是 PPT到现在为止市面上能真正买到开发板、有完整工具链、能在具身智能设备里跑起来的平台其实没有太多选择。我把主流方案拉一张表后面逐个说说它们各自的脾气。平台/芯片AI 算力典型典型配置典型功耗工具链特点适合场景NVIDIA Jetson AGX Orin 64GB275 TOPSINT8 稀疏64GB LPDDR5Ampere GPU15W–60WTensorRT 生态最成熟PyTorch 到部署链路短人形/轮式机器人原型、中高算力车载盒子NVIDIA Jetson Orin NX 16GB100 TOPSINT8 稀疏16GB LPDDR510W–25W同上支持载板定制机载、小型机器人、功耗敏感场景地平线征程 6 系列10 TOPS 到 560 TOPS 级LPDDR5内部集成 BPU依型号数瓦到数十瓦OpenExplorer 工具链车规量产验证多智驾、机器人域控、车规项目高通 SA8650P / Ride Flex 系列几十至数百 TOPS 级Adreno GPU Hexagon NPU功耗表现优秀QNN 工具链资料相对封闭舱驾一体、智能驾驶、对功耗敏感车型瑞芯微 RK3588/RK35763–6 TOPS 级8 核 CPU NPU ISP5–15W整板RKNN 工具链上手快资料多低成本轻量级任务、简单机械臂视觉算能 BM1684X / SG2300X 系列数十 TOPS 级PCIe/SOC 形态都有10–25W 级TPU-MLIR 工具链支持较多模型边缘盒子、低成本端侧推理2.1 NVIDIA Jetson/Orin生态最强但要先问功耗和成本如果你问我给具身智能做原型预研先用什么我大概率还是推荐 Jetson 系列原因是生态省时间。具身智能团队核心精力应该在算法和系统集成上而不是花三个月去解决算子兼容问题。TensorRT 对主流视觉模型的优化很成熟JetPack SDK 把驱动、CUDA、多媒体接口都打包好了连摄像头采集都有现成 pipeline。但 Jetson 不是没有代价。首先是功耗。AGX Orin 在高功耗模式下可以拉到 60W 附近这在整机里不是小数目。一块 60W 的板子加上散热风扇、外围电路整机功耗可能到 100W 以上对电池供电的移动机器人是巨大负担。其次是成本Jetson 模组价格不便宜而且自从很多端侧设备上量之后交期也飘忽不定。最后提醒一点Jetson 模组本身很多不是车规级如果项目要过车规或严苛工业认证你得自己去找载板方案和车规级加固设计不能把 Jetson 直接当成“车规芯片”用。2.2 地平线征程系列车规量产背景下的可行选择国内做车载/机器人端侧算力地平线征程系列这两年出镜率很高。征程 6 系列从征程 6B 到 6H 覆盖了从低阶到高阶的算力区间比如官方资料里 6H 达到数百 TOPS 级定位高阶智驾和机器人主控。它的 BPUBrain Processing Unit架构对 CNN、Transformer 算子做了专门的流水线优化在一些视觉场景里实际能效比不比同档 Orin 差。真正让它进入我们选型视野的是车规量产背景带来的系统稳定性验证。征程系列在国内乘用车上已经大批量出货工具链 OpenExplorer 对 PyTorch/ONNX 模型转换和量化支持比较完整也提供了性能仿真和板端 profiling 工具。对做具身智能的团队来说这意味着你不仅是在选一颗 SoC也在选一套经过车厂打磨的 BSP 和可靠性流程。不过要注意征程的开发板生态不如 Jetson 繁荣很多教程和第三方资料需要自己趟遇到问题更依赖原厂技术支持。2.3 高通 Ride 与骁龙平台能效比上的另一种解法高通在智能驾驶芯片上布局已久SA8650P/SA8775P 以及 Ride Flex 系列走的是 CPU GPU NPU 异构路线。高通的强项是能效比和多媒体处理它在手机端积累的 ISP、显示、低功耗调度经验放到车载座舱和辅助驾驶场景里优势很明显。如果项目对整机功耗、被动散热要求严格高通平台值得认真评估。但坦白讲高通的工具链开放性没 NVIDIA 那么好QNN SDK 资料相对封闭很多算子细节你不进原厂支持群根本问不到。对中小型机器人团队来说起步门槛偏高。比较理想的使用方式是已经有成熟算法团队、愿意投入工具链适配精力的公司或者本身就是从手机/智能座舱方案切过来的团队。2.4 RK3588 与国产轻量 NPU 方案小任务里的大价值端侧选型很容易犯“算力虚荣”的毛病明明只是做一台小型机械臂的抓取识别非得上 Orin。其实很多轻量任务RK3588 这种档位的 SoC 完全够用6 TOPS 的 NPU、8 核 CPU、丰富的 CSI/USB 接口RKNN 工具链对 YOLO 系列、分类网络、关键点检测支持很成熟整板功耗通常能做到 5W 到 15W成本只有 Jetson 的零头。我见过不少团队把安全帽检测、移动底盘的二维码识别、机械臂的粗略定位跑在 RK3588 上配合一块 MCU 做底层控制整体系统稳定性和性价比都很好。它的瓶颈也很明显跑不了稍大的 Transformer 模型视频编解码和 NPU 之间的数据搬运经常成为瓶颈多路高分辨率输入时 ISP 带宽也吃紧。还有算能 BM1684X、黑芝麻华山系列这些平台适合需要一定 AI 算力但对成本敏感、又希望走国产供应链的场景它们的问题是工具链成熟度参差需要做扎实的 PoC 验证再决定。第 3 章之前加个转折段不用H2 清楚了。3. 参数表不会写的三项实测功耗、散热、电压跌落所有芯片宣传材料都只会写“典型功耗多少瓦”“算力多少 TOPS”但没有一份 datasheet 会主动告诉你当你在 60 度环境里连续跑 4 小时视频推理时性能会跌到标称的几成。所以我一直觉得端侧 AI 硬件选型绝不能只看选型表必须把“电源—热—性能”作为闭环来做整机验证。3.1 功耗持续值比 TGP 更重要TGPTotal Graphics Power或者模块标称功耗通常代表的是某个负载下的典型值不是持续满载值更不是峰值值。像 AGX Orin 这类平台在不同功耗模式下性能差距极大低功耗模式可能只有 15W 供整颗 SoC高功耗模式可以跑到 60W 附近而你实际跑模型时功耗会随着场景复杂度剧烈波动——一次多目标检测密集帧就可能让 NPU 瞬间冲到峰值。我的习惯是直接用可编程电源给算力板供电让电源记录连续 1 小时以上的功耗曲线重点看三个数平均功耗、持续峰值、最大瞬态功耗。整机电源和电池选型要按峰值再加 20% 到 30% 的余量来设计线径和连接器额定电流也得按这个算。之前有台机器人总在底盘急加速时重启后来查出来就是算力板瞬时抽流把电源电压拉低触发了欠压保护不是软件问题。3.2 热设计不到位标称算力先打七折芯片降频不像断电那么明显它更像温水煮青蛙——温度到了阈值频率悄悄往下调你从日志里看到的是推理耗时变长但很难第一时间联想到散热。前面提到我遇到的那台轮式机器人就是典型Orin 模组装进密闭机箱后NPU 温度稳定在 80 度以上性能调度器自动降频端到端吞吐少了快一半。这里给个实在建议选型阶段就让整机结构工程师参与评审算清楚散热路径。风冷的话进出风口面积和风道方向设计远比风扇大小重要被动散热的话必须连接热管或导热垫到金属外壳并且实测 50 度高温环境下连续满载 2 小时的性能保持率。别信“理论上 85 度 junction 没问题”这类话温度墙到达前的性能衰减曲线才是真正决定体验的东西。3.3 供电跌落是端侧 AI 系统随机复位的隐形元凶做机器人系统集成时最诡异的问题不是蓝屏而是“时不时无规律重启”。排查了很久最后用示波器抓电源轨才发现问题出在供电跌落电机急加速或机械臂急停瞬间母线电压瞬态跌落超过 10%算力板电源管理 IC 侦测到欠压直接触发复位。所以选端侧算力平台时建议把供电设计当成重要一环来评审算力板最好有独立 DC-DC 电源树和电机驱动电源隔离或至少两级滤波输入侧要留足够的储能电容缓冲瞬态抽流有条件的话用隔离电源模块给传感器和通信接口单独供电。这些细节和 TOPS 无关但往往是决定整机能否在真实场景稳定跑起来的胜负手。4. 把模型搬上板子我常用的端侧算力实测流程选型不能靠翻芯片彩页得靠跑真实模型。我在团队里定了一套“算力实测流程”现在基本每次预研新品都会先走一遍。这套流程未必适合所有人但核心思路可以借鉴不测单一模型、不测新板首次跑出的最好成绩、不用不同芯片不同功耗模式下的数据做横向对比。4.1 准备标准镜像和固定频率环境变量先搞干净实测前最忌讳的就是环境不统一。不同 JetPack 版本、不同 PyTorch 版本、不同 TensorRT 版本跑同一个模型性能能差 30% 以上。所以我会先把所有被测板卡刷成同一个基线镜像驱动和推理框架锁版本然后用官方工具把 CPU/GPU/NPU 频率调到固定档位关掉动态调频避免测试过程中系统自己改变运行状态。NVIDIA 平台用 nvpmodel 和 tegrastats前者切模式、后者读实时功耗和温度地平线平台可以用 openexplorer 工具链里提供的性能测试工具。每块板至少连续跑 30 分钟记录稳定态数据才算数刚上电那几分钟的成绩没有参考意义。4.2 模型选样要覆盖真实负载检测、分割、VLM 一个不能少具身智能平台跑的模型有好几类我一般会挑这几个代表性负载压测目标检测模型YOLO 系列或 DETR 类吃 NPU 卷积算力能反映多数感知场景的性能基线语义分割或 BEV 类模型这类模型往往有较大张量和较高内存访问量能暴露内存带宽瓶颈关键点检测模型比如机械臂抓取用的 6D 姿态估计考察多输出头和小目标处理能力轻量级视觉语言模型VLM或端侧 LLM这测的不只是 NPU 算力还有内存容量和带宽跑起来通常几百毫秒到几秒主要看能不能满足交互决策的延迟要求。测试时还要把前后处理一起算进去——图像缩放、色彩空间转换、NMS 后处理都在 CPU/GPU 上跑在很多低端平台上这些前置后置处理耗时可能和 NPU 推理时间相当只看模型耗时会被误导。4.3 延迟、吞吐和稳态 FPS记录哪些数据才有效实测数据我建议固定记录这几个指标形成一套可复用的对比模板单帧 P50/P95/P99 延迟交互式任务看 P95控制系统看 P99别只看平均延迟平均延迟会被一堆快帧拉低稳态 FPS连续跑 10 分钟以上、排除前 100 帧预热后统计的吞吐温度墙前后性能变化率看长时间运行后性能掉了多少每瓦有效帧率FPS 除以整板功耗这是对比不同平台能效最公平的指标。把测试结果做成固定表格后你会发现一个很有意思的现象有些 100 TOPS 平台跑轻量检测模型时每瓦帧率能吊打标称 275 TOPS 的旗舰板但一换到 Transformer 类大模型内存带宽够不够马上见分晓。没有万能芯片只有匹配项目负载的最优解。4.4 量化工具链的“最后一公里”最容易翻车很多团队在公开数据集上测得准、跑得快一到自己私有模型就翻车主要原因都在量化环节。FP16/INT8 量化带来的精度损失在不同模型上表现差异很大尤其是小目标检测和分割任务INT8 后精度可能掉 3 到 5 个点这对抓取系统可能是致命的。我的建议是选型阶段就把“自己业务模型的量化后精度”作为一票否决项来做测试用同一份测试集分别在原平台跑 FP16、在目标芯片工具链跑 INT8对比 mAP 或关键误差指标。如果发现精度损失超预算尝试量化感知训练或混合量化如果工具链连这些都不支持那颗芯片基本可以提前出局。5. 具身智能整机选型的一些业务判断最后一章不谈芯片本身聊几件在具体项目里很容易被忽略、但直接影响选型成败的事情。5.1 先跑原型再谈车规最后做成本约束我看到不少团队选型顺序是反的先拿着预算表去卡芯片单价再看车规认证最后才考虑自己能不能把原型跑起来。结果就是买了一批看起来很“正规”的车规板算法团队却因为工具链难用、文档保密要求高三个月连 Demo 都没跑通。我的经验是先跑原型。用 Jetson 或其他生态好的平台把核心算法和系统架构验证完让团队对“我需要多少算力、多少内存、多少接口”有真实数据后再去看车规级或工业级替代方案是不是满足性能底线。这时候你会发现很多需求在原型阶段就被砍掉了——比如你以为需要 200 TOPS实际跑下来 50 TOPS 的轻量模型加一颗 MCU 就能闭环项目成本直接砍半。如果项目要面对整车厂或行业客户建议提前关注一些标准化文件。像现在行业里经常被提到的《人形机器人与具身智能标准体系(2026版)》对于接口规范、可靠性测试用例的定义就有参考价值你可以直接搜标准全名在标准牵头单位的官方渠道或公开媒体上查看原文和解读。把它当作项目需求评审的输入能少走很多对接弯路。5.2 接口和外设选型对整体可靠性影响非常大芯片选好了最后整机能不能稳往往由接口和外设决定。我吃过不少亏MIPI CSI 接多路摄像头时通道数和 lane 带宽要仔细核算不是板子上写了 8 路 CSI 就真能同时处理 8 路 1080P 50 帧ISP 和内存带宽会先卡死USB 摄像头虽然部署方便但 USB 线材质量和插拔次数会带来接触不良工业场景里最好用带锁扣的连接器或者转 MIPI/GMSLCAN 或 EtherCAT 这类实时控制总线的终端电阻、共地处理马虎一下就是偶发丢包和抖动。这些外设选型应该在软硬件设计评审阶段就定下来不能等板子画完再补。每个接口背后都有驱动、电源、信号完整性一堆细节选一个成熟的接口方案往往比选一颗 SoC 更影响交付进度。5.3 端侧大模型还没到“端到端包打天下”的阶段端侧 VLM/LLM 最近很热很多人幻想把视觉语言大模型整个塞进机器人实现“看到什么就理解什么”。实际跑过就知道现阶段端侧大模型首要问题是延迟太高一个动作决策等上两三秒抓取任务根本没法闭环。而且大模型的“幻觉”在物理世界会被放大——它说错一句话可能让机械臂去撞东西。所以现在具身智能落地比较稳妥的架构仍然是用轻量感知模型做实时闭环把 VLM/LLM 放在上层做任务规划、语义理解、异常判断再配合一层强实时控制框架。在这种混合架构下端侧算力板只需要能流畅跑基于 7B 以内量化模型的低帧率推理任务就够没必要为“装下更大模型”去盲目堆算力和内存。硬件选型要为整体系统架构服务而不是为某个技术热点服务。最后给一个很主观、但我自己觉得好用的选型顺序参考先明确算法负载和实时性边界确定算力下限再用生态成熟平台做原型验证拿到功耗和性能实测数据然后评估工具链对量化、私有算子的支持程度最后才是对比成本和供应链以及是否需要引入标准化的可靠性要求。按这个顺序走下来大多数算力选型坑其实在你落地之前就已经能提前避开了。