做具身智能这两年我踩过最大的坑不是算法训不出来而是算力板卡选错了。从室内轮式底盘到室外无人车再到带机械臂的复合机器人每换一个载体算力方案就要重做一遍。最近把车载、机载场景下用过的芯片平台和硬件方案从头到尾复盘了一遍想把这些真实的选型经验和实测数据写出来给正在做端侧 AI 部署、尤其是做具身智能硬件选型的朋友一个参考。这篇不是厂商软文也不是参数罗列就是我自己花钱、花时间、踩坑踩出来的实操记录。先说明一点这里的“端侧 AI”指的就是把神经网络推理放到机器人、车辆、无人机这些移动硬件上完成而不是把数据传到云端去算。具身智能对算力的要求很特别它不像手机端跑一个视觉模型那么简单要同时处理多路摄像头、激光雷达、惯性测量单元还要跑检测、分割、轨迹规划、决策控制往往还要挂一个大语言模型或多个小模型。算力芯片选得好不好直接决定了整机能不能稳定跑起来、续航能撑多久、量产成本压不压得住。这篇文章我会按照选型的真实流程来写先讲场景需求和算力评估再拆解算力指标里的坑然后对比主流芯片平台的实测表现接着给出一套自己验证过的选型测试流程最后整理一份排错避坑清单。内容不追求大而全但保证每一条都是我自己在项目里试过、测过、翻过车的。1. 先搞清楚场景再谈算力车载/机载端侧AI的真实需求1.1 车载和机载到底差在哪很多人一上来就问“这块板子多少TOPS”我觉得顺序反了。同样的 TOPS放在车载和机载上完全是两个玩法。车载场景的最大特点是供电稳定、空间相对宽裕。12V或24V车载电源可以给到几百瓦散热也更容易做能在底盘上装风扇、装均热板甚至上水冷。但车载的难点在安全等级和时延——自动驾驶系统里从传感器采集到控制指令输出整个链路一般要控制在100毫秒以内感知部分最好能压到30到50毫秒。你用一块推理很猛但延迟抖动很大的板卡哪怕平均帧率高一旦出现偶发卡顿那就是安全事故。机载场景无人机、物流小车、空中机器人的约束要苛刻得多。重量、体积、功耗、散热是全链路瓶颈。我之前在一台六轴无人机上试过一块高功耗的工控机算力是够了但整机重量直接超限电池续航从35分钟掉到18分钟现场测试时电机还出现过热保护。后来换成低功耗 SoC重量轻了1.2公斤续航才回到28分钟以上。所以选型的第一步不是看芯片而是先搞清楚两个问题装在哪、能给它多少电、多少重量、多大散热空间。这三个物理条件直接决定了你的可选范围。1.2 选型前的需求清单用这张表把需求说清楚我现在的习惯是任何项目动手前先填一张需求清单然后再拿着清单去选型。表里这七项是我踩了多次坑之后总结出来的算力规模实际要跑的模型总计算量。不能只看单个模型的算力要把视觉模型、激光雷达点云模型、机械臂运动规划模型全部加起来还要考虑同时跑多个模型时的峰值。内存需求模型参数量和输入分辨率决定最低内存。YOLOv8 1亿参数量级在INT8下大约需要300到500MB模型文件但推理时还要给中间张量留空间建议是2到4倍模型体积。传感器路数和接口几路USB摄像头、几路GMSL车规相机、有没有激光雷达和毫米波雷达这决定了主板需要哪些接口很多低端开发板接口数量根本不够。工作温度范围户外机器人夏天车内温度能到60度以上无人机在高空低温环境下又要考虑加热问题。消费级芯片标称0到40度工业级一般是负40到85度这个差距会直接淘汰一批板卡。供电波动容忍度车辆启动时电压会剧烈波动无人机的电池电压会随放电下降板卡必须能接受10%甚至更大的电压波动否则频繁重启。工具链成熟度模型能否从PyTorch、ONNX顺利转换到目标芯片的推理框架支持哪些算子是否支持INT8量化这些比芯片标称算力更重要。供货与生命周期做样机随便买做产品必须考虑芯片的供货周期、最少起订量、长期供货承诺。消费级芯片可能在两年内就停产车规级的生命周期通常能到5到7年。这张表看着简单但真填起来会暴露很多问题。我最常见的情况就是项目负责人只写了“需要200 TOPS算力”问他具体跑哪些模型、什么输入分辨率、要求多少帧率一概答不上来。这种需求到了选型阶段必然翻车。1.3 算力不是越大越好得匹配“端侧”约束这是我反复强调的一点。选算力芯片不是买车不是马力越大越好。车载和机载场景里算力每提升一倍往往意味着功耗、体积、成本都成倍上升而这三样东西恰恰是嵌入式系统最缺的。举个真实例子我朋友的项目里用了一款高端车载域控标称算力达到500 TOPS性能确实强悍但整板功耗超过150瓦必须上水冷。结果机器人的电池容量被迫加大整机重量增加了几十公斤原本设计的室内安静工作场景直接没法用。后来换了算力只有三分之一但功耗不到40瓦的方案优化了一下模型结构把多路模型做了时序调度最终效果反而更符合产品需求。所以在任何项目开始前我都会跟团队算一笔账到底需要实时跑多少个模型、每个模型的多大输入分辨率、要求多高的帧率、允许的端到端时延是多少。把这些量化之后再反推需要的算力范围而不是拍脑袋说“我要上大算力平台”。2. 算力指标别只看TOPS真正要盯的6个维度2.1 TOPS只是标称值实测掉一半很正常TOPS即每秒万亿次整数运算是衡量AI芯片比较常用的单位但很多人在选型时被这个数字坑了。TOPS通常是在特定条件下测出来的比如稀疏模型、极低精度、高时钟频率、纯卷积运算。你实际跑一个Transformer结构的模型可能连标称值的一半都达不到。我实测过一块标称275 TOPS的板卡英伟达Jetson AGX Orin用官方自带的推理框架跑YOLOv8m模型1080p输入批量大小为1实测大约是700到900 FPS。但如果换成一个多模态的Transformer模型加上注意力机制和动态形状性能会骤降到100 FPS以下。原因在于芯片的定点运算单元、张量核心、内存访问模式在跑不同类型算子时效率差异巨大。所以当你看到某款芯片宣传“200 TOPS”时不要直接跟另一个“100 TOPS”的做除法。正确做法是拿自己实际要跑的模型在目标板卡上做一次完整推理测试记录真实吞吐量和时延再换算成有效算力这比任何宣传纸面参数都靠谱。2.2 内存带宽、时延和功耗这三个坑最容易被忽略除了TOPS至少有六个维度要一起看计算算力、内存带宽、内存容量、功耗、时延、工具链成熟度。其中内存带宽是最容易翻车的坑。我做双目立体匹配模型时模型本身计算量不大但需要频繁读取左右两幅图像和中间视差图内存访问非常密集。在标称50 TOPS的板卡上跑由于内存带宽不到30GB/s帧率只有不到10 FPS。同样的模型放到算力略低但内存带宽多一倍的芯片上帧率反而到了18FPS。这就是典型的内存带宽瓶颈TOPS高但喂不饱数据等于白搭。时延这块也不能只看平均时延要看P99或者P99.9时延。自动驾驶场景里连续几帧的响应时间如果出现一次超过200毫秒的尖刺哪怕平均响应只有50毫秒也可能导致危险。我习惯在测试时记录推理时延的分布直方图如果P99时延超过平均时延的3倍基本可以判定芯片的实时性不达标。功耗更不用说了车载还可以靠大电池扛机载的每一瓦都是从续航里挤出来的。一块标称10瓦的板卡实际满载跑到25瓦这在无人机上是致命的。下面的章节我会详细讲功耗实测的方法。2.3 模型越大越吃“算力密度”token算力需求怎么评估最近具身智能项目里越来越多团队开始把大语言模型或多模态模型部署到端侧这就引出一个新问题token算力需求怎么评估。这里的token指模型处理的最小文本或语义单位大模型输出答案时每生成一个token都需要经过一次完整的前向计算。评估端侧大模型算力需求的公式可以简化成推理算力需求TOPS≈ 参数量 × 每个token计算量系数 / 生成速度要求举例来说一个7B参数的模型每生成1个token大约需要140亿次浮点运算约2×参数量。如果希望每秒生成10个token则算力需求大约为1400亿次每秒即140 GOPS换算成INT8大概是0.14 TOPS。听起来不高但注意这个只是单路生成的算力如果要做流式输入处理、多轮对话、上下文缓存计算量会再涨几倍。我在一个桌面具身智能原型机上做过实测Jetson Orin NX在8位量化下运行7B模型的int8版本每秒只能输出6到8个token勉强能满足简单的语音控制指令。而同样条件下在功耗更高的独立显卡上能到每秒30到40个token体验完全不一样。所以在选型前务必要根据实际要部署的大模型参数量和期望的响应速度把token算力需求算出来再匹配合适的芯片。很多项目死在“模型能加载进去但生成速度太慢没法用”这个环节上。3. 主流算力芯片平台横评我实测过的和踩过的坑3.1 英伟达系Jetson Orin到Thor成熟但贵英伟达的Jetson系列应该是目前做端侧AI开发的用户最多、资料最全的平台。我最早用的还是Jetson Xavier NX后来迭代到Orin系列包括AGX Orin、Orin NX和Orin Nano它们共享CUDA生态从PyTorch模型到TensorRT部署的链路非常顺滑官方文档和社区案例也多遇到问题大概率能搜到解法。在实测表现上Orin NX 16GB版本是我比较推荐的一个平衡点标称100 TOPS算力功耗区间在10瓦到25瓦之间可以灵活配置。在一台轮式底盘机器人上我用Orin NX同时跑4路1080p输入的三套检测模型加上一个点云分割模型整体帧率能稳定在15到20帧端到端控制时延在60毫秒左右满足室内低速导航的需求。但英伟达平台也有硬伤首先是价格高Orin NX模组单独采购成本在4000元以上整板系统做下来更贵。其次功耗默认偏激进如果不主动做功率限制温度很容易冲到85度以上触发降频。还有一个问题是供货周期波动大做产品时如果没有提前锁货很可能出现断货风险。至于Thor目前还是面向高性能自动驾驶的高端方案单片算力标称达到2000 TOPS级别但价格和供应周期都不是普通创业团队能轻易消化的。我目前的项目里还没有机会实际上车测试只做过一些静态评估结论是性能天花板确实高但要把它降级用到低速机器人上功耗和成本都过于奢侈。3.2 国产SoC征程、昇腾、RK3588的实际表现国产芯片这几年进步非常快我在不同项目里也实测了地平线征程、昇腾边缘设备和瑞芯微RK3588这三类代表性的平台各自的侧重点很不一样。地平线征程系列的强项在自动驾驶场景对车载传感器接口和算子的支持比较完善。我测试过基于征程5开发的一套域控制器标称算力128 TOPS实际跑11个视觉模型加1个激光雷达模型总帧率能做到相对稳定功耗在30瓦左右。但它的工具链目前对Transformer类模型的支持还有提升空间某些算子需要手工改写网络结构才能完成转换部署周期比英伟达平台长不少。昇腾边缘设备我在某电力巡检机器人项目里用过它的模型转换工具和推理框架对视觉模型支持很好同时空域网络结构在国产化要求较高的项目里有明显优势。实测跑YOLOv7模型INT8量化后推理时延和Jetson Nano处于同一档次但功耗控制得更好整板散热压力小。不过它对于社区开源模型的预适配度不如CUDA生态很多模型需要手动写预处理和后处理算子。瑞芯微RK3588是另一个极端便宜、低功耗、集成度高整板成本可以做到几百元8纳米制程内置6 TOPS算力的NPU。我用它做过一个轻量级送餐机器人的视觉方案部署了经过剪枝量化后的YOLOv5s模型720p输入能稳定跑到30 FPS功耗只有3到5瓦。但它适合跑轻量模型的固定场景如果模型稍微大一点或者需要同时跑多个模型内存带宽和计算能力很快就不够用了。它更适合低成本的入门级产品不适合复杂任务的旗舰机器人。3.3 车规级与工业级的区别别用消费级硬扛很多第一次做车载项目的朋友会问能不能直接拿Jetson开发板上车我的回答是如果你只是做算法原型验证没问题如果你要做量产产品必须慎重对待车规级和消费级的差异。车规级芯片和开发板的核心区别在于工作温度范围、抗振动冲击能力、电磁兼容性能、生命周期和失效模式。Jetson Orin系列的工业版工作温度可以覆盖负25度到85度但消费级版本在负10度到35度附近就比较吃力这在北方冬天的室外场景直接没法用。我亲身踩过这个坑。冬天在露天停车场测试一台自动驾驶物流车用的是一块消费级工控机结果环境温度零下15度车辆启动没问题但板卡上的SSD和内存颗粒在低温下出现了随机读写错误导致推理进程间歇性崩溃。后来换成了标注宽温的工业级主板和车规级存储模块问题才彻底解决。当然车规级不是万能的它的算力往往比同代的消费级产品落后一到两代因为车规认证周期长芯片一旦流片定型就很难快速迭代。所以选型时要明确自己的真实需求是做快速迭代的原型验证还是做苛刻环境下的量产产品两者选型逻辑完全不一样。3.4 工具链和生态比芯片本身更“锁人”在这个行业待久了会发现一个规律芯片选型到最后往往不是选算力而是选工具链。工具链就像操作系统的生态平台一样一旦你的算法团队熟悉了某一个框架部署链路迁移成本高得吓人。英伟达的TensorRT之所以很多人逃不掉就是因为它的算子和优化器非常成熟你在PyTorch里写得再花哨的模块大部分都能直接转出来跑得很快。而一些新兴芯片的编译器对常见网络结构支持不全碰到一个不支持的算子要么改写网络要么想办法替换遇到复杂的注意力机制甚至要等官方更新工具链版本。我见过最极端的案例是某个团队花了两个月把一套视觉感知模型迁移到一款国产AI芯片上结果发现三个核心算子在不支持列表里不得不重写网络结构精度掉了3个百分点部署周期又拉长了一个月。这就是典型的工具链成本被严重低估。所以在评测芯片时我建议至少留出两周时间专门做工具链验证把项目里最复杂的模型走一遍转换、量化、编译、运行全流程统计算子支持数量、编译耗时、推理精度损失、开发文档完整度。工具链体验不好哪怕算力再高也要慎重纳入选型池。4. 硬件选型实测流程从纸面参数到上车/上机4.1 第一步用真实模型跑标准benchmark拿到候选板卡之后我不会去看厂商的演示demo而是立刻把项目里最真实、最复杂的模型和数据集拿过来跑一遍基准测试。这个环节叫“用生产负载做验收”一定要避免只用官方自带的模型做测试那些模型通常经过了特殊优化跟你的业务场景差了十万八千里。我一般准备三个负载一个中等规模的检测模型比如YOLOv8m一个注意力机制较重的分割或Transformer模型比如RT-DETR或者MobileViT还有一个模拟大模型的自动化回归模型比如经过量化的BERT分类器或7B模型的一小段推理。每个模型分别跑FP16和INT8精度输入分辨率按实际传感器配置批量大小设置为1并分别记录单帧推理时延、FPS、峰值内存、功耗和温度。需要强调的一点是测试前必须先把芯片固定在稳定的工作模式下手动锁定功耗档位和GPU/CPU频率否则跑分过程中芯片自动调度频率得出的结果波动很大很难横向对比。我在测试时会在板卡上禁用自动调频服务然后固定到中等功耗档这样可以减少变量。4.2 第二步功耗与散热联合测试功耗测试是载具平台选型最容易忽视、却最容易翻车的环节。标称功耗和实际满载功耗往往有巨大差距而且系统跑不同的模型时功耗差异也很大。我碰过一块板卡官方文档写平均功耗10瓦实际跑一个多路模型满载时瞬间峰值能干到28瓦而且持续输出直接把电源接口烧了。正确的功耗测试方法是在板卡的供电输入端串联高精度功率计同时记录电流和电压波形观察峰值功耗和持续功耗。需要注意的是有些板卡在启动瞬间会有很高的浪涌电流这时候如果供电模块余量不够就会出现“插电重启”或者“供电不足导致USB设备挂掉”的诡异问题。散热测试同样重要尤其是机载场景。我会把板卡放进机箱或整机结构里在靠近散热器的位置贴热电偶然后跑压力测试至少30分钟记录从冷态到热稳态的温度曲线。因为很多板卡的散热设计只考虑了芯片本体没有考虑周边电源模块和存储颗粒的散热热量堆积之后系统会整体降频性能下降可能超过30%。4.3 第三步时延抖动和长时间压力测试很多开发者测完FPS之后兴高采烈地觉得板卡性能足够了然后一上整机就发现系统在运行半小时后变得越来越卡。这通常是因为缺少长期压力测试和时延稳定性测试。我建议对每款候选板卡至少做连续24小时的压力跑测负载设置为实际项目中最恶劣的多模型并发场景同时记录每帧推理时间、系统温度、可用内存变化和进程是否有崩溃或重启。这里我会额外关注一个单次“卡顿”现象在长时间运行后内存碎片可能增加显存池管理可能出现问题导致部分帧的推理时延翻好几倍。时延抖动方面我会统计每分钟的P50、P90、P99时延如果P99时延长时间超过30毫秒且反复出现这块板卡就很难满足自动驾驶类的实时控制需求。无人机场景里这个问题更明显飞控需要实时性如果推理输出迟到哪怕几百毫秒整机就可能撞树或坠地。4.4 第四步工具链与部署周期评估工具链评估不能靠看文档一定要让算法工程师亲自在目标板卡上从零部署一个项目。我的固定流程是把项目中的核心模型通过官方推荐流程实现从PyTorch到芯片推理框架的转换完成量化、编译和运行然后评估三个指标转换成功率、编译耗时、量化精度损失。转换成功率就是看模型里的算子有多少能被芯片编译器直接支持遇到不支持的算子需要手工替换或者改写结构这直接决定开发周期。我见过某些新锐芯片转换成功率只有70%意味着算法团队要花大量时间做网络改造项目进度会受到严重影响。编译耗时这个指标也很有意思。某些工具的AOT编译静态编译动不动就要一晚上迭代部署时每次改个预处理都要重新编译体验极差。我自己比较倾向于编译耗时控制在几分钟以内这样才能支持高频率的算法迭代。量化精度损失一般要求控制在2%以内如果超过5%就需要考虑混合精度或重新训练模型对整个算法流程成本影响很大。这个测试应该用团队的标准测试集来评估而不是只跑几个demo图。4.5 我的一套选型打分表测试做完之后所有数据放到一张选型打分表里统一比较。这张表是我自己设计的按项目优先级分配权重也分享给大家参考性能实际吞吐量权重20%满分100分按需求帧率达标情况打分。时延稳定性权重15%根据P99时延和最大值评估。功耗与散热权重20%按整机可用功耗预算和实测满载功耗打分。工具链与开发效率权重25%按转换成功率、编译耗时、文档质量综合打分。供货与成本权重15%按单板成本、最小起订量、交期综合评估。生态与社区权重5%按资料丰富度、案例数量、第三方组件支持度打分。没有一款芯片能在所有维度得满分最后选型一定是根据项目优先级做取舍。比如对于量产产品供货和成本权重往往更高对于研发原型机性能和工具链权重更高。这套打分表让我能跟团队就选型理由达成一致避免后面出现“当初为什么要选这个方案”的甩锅争论。5. 常见问题与排查技巧实录5.1 散热翻车标称功耗和实际功耗是两回事我遇到最频繁的问题是散热设计跟着官方标称功耗走结果到了实测阶段发现满负载功耗远超预期。一块标称12瓦的SoC板卡在跑高负载视觉模型时SOC和内存模块一起能达到25瓦散热器不够几分钟内开始降频最终实际性能只有标称的60%。排查思路不要只看芯片热设计功耗TDP要看整个底板的实测功耗包括内存、网络芯片、USB控制器这些外围器件。同时要留意芯片在不同负载下的功耗切换速度有些芯片在脉冲式负载下功耗波动非常大峰值持续时间虽然短也足以让电源管理模块措手不及。我在实际项目中的做法是预留30%到50%的散热余量也就是如果实测满载功耗是20瓦散热系统至少按照28到30瓦设计。无人机这种重量敏感的平台上我会在电机和电池散热允许的前提下选一个比理论需求大一档的散热风扇加上温控风扇转速策略平时低速安静满载时自动提速。5.2 内存带宽不够模型量化后反而更慢这是一个反直觉的坑。很多人以为量化到INT8之后模型变小了速度应该更快才对。但在某些芯片上INT8量化后推理速度反而变慢了原因就是内存带宽或编译器把INT8数据打包得不好访问次数反而更多。我测试过一个目标检测模型在Jetson平台上从FP16切到INT8通过TensorRT优化后速度提升了约60%很理想。但在另一款国产芯片上做同样操作量化后推理时延几乎不变甚至有时慢5%。后来分析发现该芯片的编译器对INT8算子使用的是一种非向量化读取方式导致内存访问效率降低。排查这类问题的方法是用厂商提供的算子分析工具看每层的耗时分布找出耗时异常增长的网络层。如果某个卷积层或全连接层在INT8下反而更慢就要考虑为该层保留FP16或混合精度执行同时关闭某些可能造成数据重排的融合优化。这个调优过程很熬人但对于追求性能上限的项目来说是必须做的。5.3 工具链断点算子不支持让你怀疑人生工具链的断点问题几乎每个新平台都会遇到。最典型的就是某个模型里有一个很冷门的算子比如某种自定义注意力机制或特殊的归一化层芯片编译器直接报“不支持”整个模型转换流程卡住。这种问题没有捷径只能靠排查。我的建议是先定位到具体不支持算子的位置然后看这个算子是否能被替换成等价的多个基础算子组合。很多框架都支持可以修改算子注册表的方式需要的时候可以自己写插件算子也可以用ONNX中间表示来做算子融合。如果找不到等价替代最后的选择就是把这个算子放到CPU上执行把计算量小的部分跑在NPU上。如果计算量大的算子放到CPU性能必然下降所以策略应该是尽量重写网络结构。这里有一个经验尽量选用常见的主流模型结构例如使用标准卷积、标准注意力和通用激活函数的模型在端侧平台的兼容性会好很多。花哨的自定义结构在PC上效果很好到了嵌入式平台往往就是灾难。5.4 供应链与供货周期也是选型的一部分另一个容易被忽略的坑是供应链。我做产品时遇到过不止一次选型时看中一款性能不错的芯片小批量样机做得很顺利结果到了准备量产阶段代理商告知该芯片交期要12周以上或者已经收窄了样品供货小团队根本拿不到货。所以现在选型时我会额外花时间确认三点一是该芯片是否处于产品生命周期的稳定期二是是否有替代封装或第二货源三是代理商能否给出明确的交期承诺。不要等产品设计冻结后才意识到供应链问题那会直接葬送整个项目。同时也要关注开发板、核心板这些外围模块的供货情况。芯片本身有货但配套的核心板停产了一样没法量产。我见过一个项目因为核心板厂商停产被迫重新做一版底板光走线和适配就耽误了整整两个月。6. 写给自己也写给后来者的一些话这篇内容整理下来我感觉与其说是分享选型经验更不如说是记录了自己这两年被现实教育的过程。端侧AI和传统的云端AI最大的区别在于它没有一个拿来就能用的“标准答案”每一款芯片在功耗、算力、工具链、成本之间都有自己的取舍没有一款方案是万能的。我在实际工程中最深的体会是选算力芯片本质上是在选一个长期合作的“技术生态伙伴”而不是在买一颗处理器。你以后每一次模型升级、算法迭代、故障排查都在跟它的工具链打交道这个过程顺不顺利直接决定项目是按时交付还是无限延期。最后再分享一个小技巧当你真的难以判断两块板卡谁更适合的时候就把两块板卡同时买回来放在同一个测试环境里用你自己的数据集跑同样的任务看谁先让你省心。账面参数再漂亮都不如亲手跑一轮测试来得诚实。便宜有便宜的理由贵也有贵的道理只有在真实负载面前芯片才算得上有“真算力”。希望这篇内容能让更多做具身智能硬件的朋友少走一些弯路少踩一些我已经替你们踩过的坑。