1. 先把需求说清楚端侧算力选型为什么在具身智能里这么特殊1.1 云端算力解决不了的那个问题实时闭环我见过不少团队刚开始做具身智能项目时第一反应是“算力不够就上云端”。逻辑上没毛病模型大、参数多服务器 GPU 跑起来又快又稳。但真正把机器人放在物理世界里跑一圈你会发现这条路根本走不通。原因不复杂具身智能的每一个动作都依赖感知-决策-控制这条闭环链路。以一台轮式无人车为例摄像头采集一帧图像模型完成目标检测规划模块给出速度指令底盘执行转向和加减速。这个周期从传感器曝光到电机转动通常必须控制在 80-150ms 以内。多加一级网络通信哪怕内网延迟只有 10ms再加上云端排队、推理、回传整个周期很容易突破 300ms。300ms 是什么概念一台以 2m/s 行驶的车在这段时间里已经出去了 60 厘米足以在躲避障碍物时撞上去。这不是算法能不能跑的问题是物理世界不允许你等。所以端侧 AI 部署不是“本地能不能跑得动”的问题而是“移动设备必须自己完成实时推理”的硬约束。这也是我从一开始就把注意力从云端搬到端侧的原因具身智能的算力本质上买的是“确定性”——确定的延迟、确定的功耗、确定的可用性。1.2 车载/机载不是“装机箱”是一整套物理约束把同样的推理任务从机柜搬到车上、机上、机器人体内很多人只盯着算力芯片本身的算力数字忽略了部署环境带来的次生问题。我先列几个现实场景一台消杀机器人车体内部温度在夏天空调失效时能达到 50-60°C控制舱还是半密封的散热只能靠被动铝壳和风扇开孔。你选的那块“峰值 100 TOPS”的板卡风扇一转就是噪音客户现场直接投诉。一台农业巡检无人机载荷只有 3kg电池容量有限。推理板卡标称 10W 功耗但那是 AI 负载跑满 20 秒的平均值降落时要同时处理图像和数传瞬时功耗能拉到 18W电源模块不够就只能重启。一台机械臂调试间里跑得好好的部署到产线后每运行 2 小时就出现一次偶发丢帧。排查到最后发现是车间里没有空调芯片热降频后某个算子耗时从 12ms 涨到 28ms控制周期直接崩了。这些问题的共同点是峰值算力不是瓶颈持续可用算力才是。这台设备是在什么温度下跑、供电多大、能带走多少热量、CPU/NPU/内存之间数据搬运快不快、整个系统在连续负载下稳不稳定每一项都比“标称 TOPS”更接近真实的选型答案。所以这篇文章后续讲的都是围绕这些“坑”来的指标怎么读、约束怎么列、实测怎么做、方案怎么比。适合做机器人、无人车、无人机、机械臂的硬件工程师、算法工程师和项目负责人参考。2. 参数表上的 TOPS 不是全部真相先学会拆指标2.1 同一个 TOPS能差出 2 倍的真实性能先问一个问题某芯片标称 100 TOPS另一块标称 50 TOPS前者一定比后者强一倍吗答案是不一定。最典型的坑是精度标准不统一。TOPS 的全称是 Tera Operations Per Second但“一次操作”到底算多少位宽各家的口径完全不同。大部分消费级和嵌入式芯片标注的是 INT8 稠密算力有些标注的是 INT8 稀疏算力利用权重稀疏性最多算 2 倍还有些标注的是 FP16 算力。做个简单换算同一块芯片INT8 稠密算力如果是 100 TOPSFP16 通常是它的 50% 左右也就是 50 TFLOPS。如果标称是稀疏 INT8那么密集计算场景下要打五折只剩 50 TOPS。再往下到 FP32一般只剩 INT8 的 1/4 甚至更少。所以在对比两块芯片时先把它们换算到同一个标准和精度下再说。我整理过一个简化对照表方便快速估算标称指标实际等效 INT8 稠密算力估算标称 100 TOPS (INT8 稀疏)约 50 TOPS标称 50 TFLOPS (FP16)约 100 TOPS标称 25 TFLOPS (FP32)约 50 TOPS按 FP32 是 INT8 的 1/4 粗估这个换算很粗糙不同架构差异很大但至少能帮你避免被参数表牵着鼻子走。2.2 算力只是门槛内存带宽和容量才是真正的天花板这是一个我早期栽过跟头的点。当时我评估一块国产板卡官方标称 NPU 算力 6 TOPS跑一个 YOLOv8s 应该问题不大结果实际帧率只有预期的一半。后来用 profiler 一看瓶颈根本不在 NPU 计算单元而在内存。原因在于模型推理不是一个“算完就结束”的过程。每一层卷积、矩阵乘都要把权重和中间特征图从内存搬到计算单元算完再写回。对单帧 640×640 输入的检测模型来说中间特征图动辄几十 MB权重和激活反复搬运内存带宽一旦不够NPU 就处于“等数据”的状态算力再高也白搭。内存容量同样关键主要体现在三个地方模型文件本身。一个 YOLOv8m 的 INT8 模型大约几十 MBFP16 版本翻倍这个还好。运行时中间缓冲区。多路视频流 多模型并行时中间缓存会成倍增长。大模型/多模态模型的权重驻留和 KV Cache。一个 7B 模型做 INT4 量化后权重约 4GB推理时 KV Cache 还要额外占几百 MB 到几 GB。如果内存只有 4GB模型加载完就快满了系统直接触发 swap整个延迟曲线陡增。所以选型时我不只看 TOPS还会做一道简单验算模型权重大小 运行时缓冲 系统预留必须小于整板可用内存的 70%留出余量。2.3 算力利用率才是不同芯片拉开差距的地方同一款模型在不同芯片上跑出的实际有效算力差距比参数表大得多。我见过很典型的一组对比一块标称 32 TOPS 的 GPU 板卡跑一个小型检测网络换算下来有效算力利用率能到 50% 以上另一块标称 50 TOPS 的专用 NPU 板卡跑同一个网络因为算子没有完全落到硬件加速单元上有效利用率可能只有 25%。最后实测下来反而是标称 32 TOPS 那块的端到端帧率更高。造成利用率差异的原因包括推理框架与硬件是否深度适配、算子是否被融合优化、张量内存布局是否连续、驱动程序是否成熟、NPU 任务调度是否有明显空泡。这些在官方 demo 里通常看不出来——因为厂商会把自家芯片优化最好的几个网络放出来给你跑但你的真实业务模型往往是组合的、多路的、动态的。所以我给自己定了一条规矩参数表只用来初筛真实利用率必须靠实测。具体怎么测后面有专门章节讲。2.4 LLM/VLM 的“Token 算力需求”怎么估现在具身智能项目基本都在往多模态大模型方向走端侧跑 LLM/VLM 已经是常见需求。很多第一次接触这个的人看到 7B、13B 参数就焦虑这得多少算力其实可以算一笔账。以 7B 模型、FP16 推理为例每生成一个 token 需要的大致计算量约为参数量乘以 2 的一半也就是约 7B × 2 FLOPs ≈ 14 GFLOPs实际通常按每 token 约 3.5 GFLOPs 转运算考虑到 KV 缓存复用不同实现差异不小。如果目标速度是 20 tokens/s那需要的算力大约 70 GFLOPS也就是 0.07 TFLOPS。单看这个数字似乎任何端侧芯片都能跑。但大模型的瓶颈从来不是算力而是内存带宽。因为在自回归解码时每生成一个 token 都要把全部权重读一遍7B 模型 FP16 权重就是 14GB要跑 20 tokens/s内存带宽需要 14GB × 20 280GB/s。这个数字对绝大多数端侧板卡是遥不可及的——Jetson Orin NX 的内存带宽大约 102GB/sRK3588 大概只有 50GB/s 级别。所以端侧跑大模型的现实选择是量化到 INT4/INT8把权重降到 4-7GB同时用更小的输入、更长的 KV Cache 来换取体验。做这个评估时我建议先看内存带宽再看算力顺序反了容易得出“随便都能跑”的错误结论。3. 车载/机载环境里容易被忽略的约束供电、散热、振动与实时性3.1 供电标称功耗是“平均功耗”峰值功耗才是选电源的依据很多规格书只标一个“典型功耗”比如 Jetson Orin NX 写 10-25WRK3588 写 3-10W。但实际跑起来尤其是在系统启动、多核并行、NPU 满载瞬间功耗会有一个明显的尖峰。我用电流探头测过 Jetso Orin NX 在 15W 模式下的上电瞬间电流能到 3A12V 以上比稳态 1.25A 高出不少。如果整车电源线径细、稳压模块余量不足一上电就重启。这类问题在单板调试时不会出现因为电源是实验室线性电源或稳压模块整机联调时才开始“神秘重启”。选电源模块和线缆时建议按“标称持续功耗的 2 倍”来留余量并且用示波器或电流探头实测如下几个指标上电瞬间的浪涌电流NPU 从空闲到满载时的电流上升斜率板卡电压跌落幅度低于 5% 就要警惕电源纹波特别是 DC-DC 开关频率附近的纹波只要这些数据没测就不要在电源上省成本。整机无法稳定运行往往先怀疑软件最后发现是供电浪费大量排查时间。3.2 散热无风扇 高温环境连续跑性能可能降到标称的 70%散热是所有端侧选型里最容易被低估的环节。以一款标称 32 TOPS 的板卡为例它在 25°C 室温、风扇直吹的情况下连续跑满负载 20 分钟核心温度可能稳定在 65°C频率不掉帧率稳定。但把它放进密封舱体周围还有电机驱动器发热环境温度 45°C同样持续跑 20 分钟核心温度很容易冲到 85°C 以上这时候 SoC 会开始降频帧率可能掉到满帧的 70% 甚至更低。我自己的测试经验是选型阶段不能只看“能跑到多少 TOPS”要看“热稳态下能持续跑多少 TOPS”。一个简单的评估方法是做“温升测试”在室温环境下让板卡跑满推理负载。记录 30 分钟内的核心温度曲线和推理帧率曲线。观察帧率开始下降的“拐点温度”。再根据目标部署环境的最高环境温度估算热稳态下的可用性能。如果条件允许放到高温箱里做 65°C 或 70°C 的测试。很多所谓“过不了的坎”在高温箱里暴露得特别快也特别值得在选型阶段就发现。3.3 振动、结构、连接器小车一颠数据就断具身智能设备是运动的。车会过减速带机械臂会高速加减速无人机要扛气流。这些振动对板卡选型的影响远不止“拧几个螺丝固定”那么简单。有三个地方我踩过坑连接器。开发阶段大家都用 type-C 供电 USB 转调试但振动环境下type-C 这种弹片接触的接口很容易瞬时断连。车载/机载项目尽量用带锁扣的航空插头、M12 连接器或 FPC 加固座子接口处再点胶/加固定夹。板卡与外壳的固定。直接用铜柱单点支撑振幅一大板卡就共振导致内存颗粒虚焊、PCIe 链路报错。建议加减震支架或至少 4 点支撑。存储。趁早选工业级 eMMC/SD 卡别用消费级 TF 卡。我在无人机上遇到过几次“飞着飞着存储掉盘”最后都是卡本身锁死导致的。车载和机载场景对可靠性的要求本来就更高如果产品要走量产和认证ISO 16750、GB/T 28046、DO-160 这些标准都要提前调研。别等开发到一半才想起来改连接方案那时候的改动成本是最高的。3.4 实时性Linux 默认调度满足不了控制周期端侧推理板卡上一般跑的是 Linux 系统普通调度策略下CPU 任务、NPU 任务、中断处理会出现毫秒级抖动。对纯视觉检测来说单帧偶尔慢 20ms 也许无所谓但对机器人控制来说这就可能是致命的。举个例子机械臂的控制周期通常是 1ms 或 2ms视觉给到的是 30Hz 的检测结果这个环节通常不会硬同步。但一旦系统 CPU 瞬时过载控制指令下发被延迟几个毫秒机械臂就可能出现轻微抖动长期运行容易积累位置误差或触发安全保护。所以如果系统里有实时控制需求建议在选型阶段就确认芯片/板卡是否支持 PREEMPT_RT 实时内核补丁NPU/GPU 任务是否支持优先级配置是否有可用的 lock-free 或偏执内存分配机制相关驱动是否兼容实时环境做实测时不要只看平均延迟要看 P99 延迟和最大延迟。平均 10ms、最大 80ms 的方案在控制场景下不如平均 12ms、最大 15ms 的方案可靠。4. 实测过的几类方案SoC 模组、工业整机、国产 NPU 板卡的真实表现这部分我不会直接说“某某芯片秒天秒地”因为没有万能芯片只有适不适合你的场景。下面是我在不同项目里实测过的几类主流方案统一测试模型是 YOLOv8s640×640INT8、RT-DETR如果芯片跑得动、以及一个 2B 左右的 VLM 做 token 速度参考。环境统一为 25°C 室温主动散热持续运行 30 分钟取稳定值。4.1 NVIDIA Jetson Orin NX 16GB生态最省心功耗/散热压力最大Jetson 系列在端侧 AI 里的地位基本就是“默认选项”。TensorRT、DeepStream、Isaac ROS软件栈成熟度在嵌入式平台里没有对手。我实际测试在 20W 模式下跑 YOLOv8s INT8单帧延迟大约 10-15msFP16 大约 15-22ms稳定性很好。跑 2B 级别的 VLM量化后 token 速度大概在 20-40 tokens/s 之间这个表现目前其他平台很难追。但它有两个明显的坑价格过高。16GB 版本整体模组成本动辄大几千做量产设备很难受。功耗释放需要散热保障。如果整机只能被动散热且环境温度高20W 模式降频后性能可能反而不如一些主动散热的国产方案稳定。适合场景研发原型、算法快速验证、对软件生态依赖强且预算充足的量产项目。4.2 瑞芯微 RK3588/RK3576成本敏感型方案的起步选择瑞芯微这两年在端侧 AI 板卡里性价比很高。RK3588 标称 6 TOPS NPUINT8支持 RKNN 工具链。我实测同一款 YOLOv8sINT8RK3588 单帧延迟大约 18-28ms不同批处理和线程配置差异较大。坦率说这个性能和标称 6 TOPS 的“纸面算力”相比利用率不算高可能只有 30%-40%。但放在很多对实时性要求没那么苛刻的场景——比如机械臂抓取、巡检机器人、复合机器人——它能满足需求而且整板成本只有 Orin NX 的三分之一甚至更低。RKNN 工具链这几年进步明显支持的算子覆盖度已经能覆盖 YOLO 系列、RT-DETR、常见分割模型。但一旦遇到结构比较新、算子特殊的模型就可能需要手写自定义算子或做结构改写这个成本要在项目排期里预留。RK3576 是更低功耗更小算力的选择适合轻量视觉和电池供电产品。4.3 地平线征程系列、寒武纪、黑芝麻等车载/机器人专用芯片这几家是路线更“专用”的方案。以地平线征程系列为例BPU 架构对自动驾驶、机器人场景的视觉感知算子覆盖度很高像 BEV、OCC、Transformer 这类重量级网络理论上在专用工具链下能跑出不错的能效。但这类方案的实际情况是工具链和文档偏向“合作伙伴制”个人开发者、小团队拿不到完整资料社区生态也不如 Jetson 和瑞芯微。我尝试过用征程系列跑自定义模型算子转换过程中遇到问题FAE 响应周期长最终拖慢了项目进度。所以我的判断是这类芯片更适合有量产规模、有专门软硬件团队、与芯片原厂建立合作关系的公司。如果一个项目还是原型验证期用这类芯片的风险会偏高。4.4 工业整机/工控机方案验证最佳量产不合适很多团队早期喜欢买现成的工业整机比如带 RTX 4060 的工控机、带高性能 NPU 的盒子。这类方案的优点是即插即用性能强软件栈就是桌面生态随便折腾。我早期做无人车原型时就是一台工控机 GPU软件调试效率特别高。但它的缺点也很明显体积大、功耗高、价格贵而且整机内的 GPU 能力对最终量产芯片方案的参考价值有限。你的量产设备不可能塞一台 500W 的工控机进去。所以我的建议是原型阶段放心用整机验证算法和系统设计但不要因此拖后启动芯片方案的评估。趁着原型验证期同步把量产芯片方案拉通测试才能避免后面“算法跑得很顺硬件换不过来”的尴尬。4.5 实测对比小结方案标称算力参考YOLOv8s INT8 单帧延迟参考生态成熟度量产成本适合阶段Jetson Orin NX100 TOPS10-15ms高高研发/量产RK3588 板卡6 TOPS18-28ms中低成本敏感量产地平线/寒武纪等因型号而定需专项测试中低偏合作伙伴中规模化量产工业整机视 GPU/NPU5-20ms高高原型验证以上数据是我在固定环境下的实测参考不是基准测试不同驱动版本、推理框架、输入规模结果差异很大。重要的是方法不是具体数字。5. 可复现的选型与验证流程从需求分解到上机实测5.1 第一步把产品需求翻译成算力需求选型之前先花两天时间把产品需求拆成算力需求。别嫌麻烦这一步做得越细后面越不容易反复。我一般用一张表格来拆功能模块模型/算法输入尺寸单帧耗时预算运行帧率/频率并发路数精度要求障碍物检测YOLOv8s640×640≤30ms30 FPS4 路INT8语义分割RT-DETR512×512≤50ms10 FPS2 路INT8视觉问答2B VLMINT4图片文本≤2s流式1 路FP16/INT8运动规划规则/PPO-≤5ms100Hz-FP32然后做算力估算。以 YOLOv8s 640×640 为例它的计算量大约为 15 GMACs/帧。30 FPS 时需要的算力是15 GMACs × 30 FPS × 2MAC 转 OPS 900 GOPS 0.9 TOPS但这个数字只是“纯卷积计算”还要乘以一个利用率和系统开销系数。我通常按 30%-50% 的实际利用率来反推也就是0.9 TOPS ÷ 0.3 3 TOPS也就是说跑这一个模型至少需要标称 3 TOPS 以上的方案才稳。如果还要同时跑分割、VLM以及系统调度、传感器驱动、日志存储整体再乘 1.5-2 的并发冗余。估完需求后再列硬件约束表。比如供电范围 9-36V、功耗预算小于 30W、部署环境温度 -20~60°C、防护等级、接口需求几路 USB、几路网口、几路 CAN、以及单板成本上限。这些条件列完候选方案基本就筛掉一大半了。5.2 第二步:评估软件栈与工具链的“隐藏成本”这一步很多人会忽略但它往往是决定项目能不能按计划交付的关键。评估软件生态时我会实际去触摸几个问题官方推理框架对我要用的模型是否直接支持还是需要修改网络结构模型转换工具是否稳定有没有社区文档和示例驱动是否支持我需要的摄像头、激光雷达型号遇到算子不支持时我能否自己实现或绕过代价是什么官方 FAE/技术支持响应速度如何是邮件等三天还是当天能拉群这些问题的答案直接决定你的开发周期。硬件的坑坑两三天能解决工具链的坑可能一两周都填不完。尤其是做量产前还要确认芯片原厂的供货周期、BSP 长期维护计划和量产认证支持。5.3 第三步用最小系统做一次 48 小时上机实测候选方案缩小到 2-3 个后我会各买一块官方开发板或模组跑一轮标准化的“最小系统实测”。这部分内容我建议做成一套 checklist方便团队里每个人都按同样的口径执行性能测试用你的真实业务模型不是官方 demo分别测 FP16/INT8/INT4 的帧率、单帧延迟、P99 延迟。精度测试记录转换前后的 mAP 下降幅度。掉点超过 2%-3% 就要慎重可能需要混合精度或改动量化方案。内存测试监控运行 1 小时后的内存占用最大值、CPU 占用率、是否有内存泄漏。功耗测试用电流探头记录待机、满载、峰值三种状态的电流和电压计算稳态功耗与峰值功耗。温度测试在室温 25°C 下跑满负载 30 分钟记录核心温度和性能变化曲线有条件就进高温箱做 60°C、70°C 各 2 小时。稳定性测试7×24 长时间跑观察是否出现死机、重启、内存泄漏、NPU 资源释放异常。并发测试模拟真实多任务场景比如 4 路视频 1 路 VLM 控制程序并发看资源抢占和延迟抖动情况。一次完整的实测数据比十份规格书都有用。我在选型时往往会因为一个 P99 延迟数据而否决一个“纸面性能很强”的方案也会因为一个“7×24 不死机”的实测而接受一个算力略低的方案。5.4 第四步把“二次开发”纳入选型评估很多芯片/板卡拿到手之后不是直接能用的。BSP 定制、外设驱动、容器环境、调度策略、散热方案、电源管理、加密模块每一项都是“二次开发”。我见过有团队选了国产芯片硬件成本省了 2000 块结果工具链不成熟三个算法工程师调了一个月才把模型跑通人力成本远超省下的硬件钱。所以最后一步选型决策不只是看芯片规格还要看原厂/方案商是否支持二次开发是否是开放 SDK还是黑盒 APIBSP 是否提供源码kernel 版本和驱动是否能满足系统定制需求是否有成功落地的同行业案例资料是否齐全社区是否活跃遇到问题能否快速找到答案这个评估比参数对照表还重要。毕竟硬件是买一次软件栈是要养整个产品生命周期的。6. 选型决策里那些“想当然”的坑和我的应对习惯6.1 “峰值 TOPS”最大的坑宣传口径不等于连续运行我见过一个项目选芯片时只看官方宣传的“XX TOPS”整机设计时按 70% 的算力利用率排性能预算。结果真机跑起来只要环境温度超过 40°C芯片就开始降频很多算子执行时间翻倍最终系统帧率不达标。我的应对习惯是不管规格书怎么写一律按“热稳态有效算力”去估算。做法很简单查规格书里的热设计功耗TDP和最大结温结合自己的散热方案估算 70°C 结温下的持续频率再按这个频率去算实际算力。宁可前期低估不要后期返工。6.2 板卡便宜但散热垫和风扇偷工减料有段时间国产板卡价格战打得厉害市面上出现很多标称性能很高、价格极低的板卡。买回来实测才发现SoC 与散热器之间的导热垫用的是低劣材料厚度不够、导热系数虚标风扇也是普通滚珠轴承三个月后噪音变大、转速下降。所以即使是买现成板卡我也建议第一次拿到货就拆开看一眼散热设计用热电偶实测散热器表面温度和核心温度确认热阻是否符合预期。批量采购时要求供应商提供出厂满载老化测试报告。6.3 多路视频流不是“单路 × 路数”那么算很多平台标称“支持 8 路 1080p 解码”或“支持 4 路 DCU 视频流”但实际跑起来多路视频流的瓶颈通常不在解码器而在内存带宽、ISP 通路、预处理算力和 NPU 算子并行度。比如 4 路 YOLO 推理不是每路 20ms四路就 80ms而是所有路共享内存带宽和 NPU 资源延迟可能从单路的 20ms 涨到 35ms 甚至更高。我习惯在实测时专门加一个“并发路数递增”测试从 1 路逐步加到目标路数每加一路记录帧率、延迟、内存和 NPU 利用率观察是否存在非线性恶化。这个测试能早几个月暴露系统扩展性问题。6.4 选型检查清单我每次必过一遍的最终列表把散落上面的经验汇总成一个快速检查清单我在项目决策时至少会过两遍[ ] 是否换算过所有芯片到同一个精度口径[ ] 是否用实际业务模型跑过胜率/精度对比[ ] 是否实测过稳态功耗、峰值功耗和上电浪涌[ ] 是否做了高温箱测试确认热稳态性能[ ] 是否测过 P99 延迟而不是只看平均帧率[ ] 多路并发时是否存在非线性恶化[ ] 工具链是否覆盖全业务模型算子缺失成本有多大[ ] 原厂是否有 FAE 支持响应速度如何[ ] 是否确认长期供货和量产稳定每一项背后都是真实项目里踩过的坑。把它做成流程不是为了显得专业而是因为凭感觉选型真的是要付学费的。做端侧 AI 选型这几年我最大的体会是没有“最强”的算力芯片只有“最匹配需求”的方案。先把自己的场景摸透再谈选型顺序不能反。如果你正在为具身智能设备选型希望这份踩坑记录能帮你省下几周返工时间。按这个流程走下来你可能会发现很多原本纠结的问题在实测数据面前都会变得非常清楚。
端侧算力选型实战：具身智能设备如何绕过TOPS陷阱
1. 先把需求说清楚端侧算力选型为什么在具身智能里这么特殊1.1 云端算力解决不了的那个问题实时闭环我见过不少团队刚开始做具身智能项目时第一反应是“算力不够就上云端”。逻辑上没毛病模型大、参数多服务器 GPU 跑起来又快又稳。但真正把机器人放在物理世界里跑一圈你会发现这条路根本走不通。原因不复杂具身智能的每一个动作都依赖感知-决策-控制这条闭环链路。以一台轮式无人车为例摄像头采集一帧图像模型完成目标检测规划模块给出速度指令底盘执行转向和加减速。这个周期从传感器曝光到电机转动通常必须控制在 80-150ms 以内。多加一级网络通信哪怕内网延迟只有 10ms再加上云端排队、推理、回传整个周期很容易突破 300ms。300ms 是什么概念一台以 2m/s 行驶的车在这段时间里已经出去了 60 厘米足以在躲避障碍物时撞上去。这不是算法能不能跑的问题是物理世界不允许你等。所以端侧 AI 部署不是“本地能不能跑得动”的问题而是“移动设备必须自己完成实时推理”的硬约束。这也是我从一开始就把注意力从云端搬到端侧的原因具身智能的算力本质上买的是“确定性”——确定的延迟、确定的功耗、确定的可用性。1.2 车载/机载不是“装机箱”是一整套物理约束把同样的推理任务从机柜搬到车上、机上、机器人体内很多人只盯着算力芯片本身的算力数字忽略了部署环境带来的次生问题。我先列几个现实场景一台消杀机器人车体内部温度在夏天空调失效时能达到 50-60°C控制舱还是半密封的散热只能靠被动铝壳和风扇开孔。你选的那块“峰值 100 TOPS”的板卡风扇一转就是噪音客户现场直接投诉。一台农业巡检无人机载荷只有 3kg电池容量有限。推理板卡标称 10W 功耗但那是 AI 负载跑满 20 秒的平均值降落时要同时处理图像和数传瞬时功耗能拉到 18W电源模块不够就只能重启。一台机械臂调试间里跑得好好的部署到产线后每运行 2 小时就出现一次偶发丢帧。排查到最后发现是车间里没有空调芯片热降频后某个算子耗时从 12ms 涨到 28ms控制周期直接崩了。这些问题的共同点是峰值算力不是瓶颈持续可用算力才是。这台设备是在什么温度下跑、供电多大、能带走多少热量、CPU/NPU/内存之间数据搬运快不快、整个系统在连续负载下稳不稳定每一项都比“标称 TOPS”更接近真实的选型答案。所以这篇文章后续讲的都是围绕这些“坑”来的指标怎么读、约束怎么列、实测怎么做、方案怎么比。适合做机器人、无人车、无人机、机械臂的硬件工程师、算法工程师和项目负责人参考。2. 参数表上的 TOPS 不是全部真相先学会拆指标2.1 同一个 TOPS能差出 2 倍的真实性能先问一个问题某芯片标称 100 TOPS另一块标称 50 TOPS前者一定比后者强一倍吗答案是不一定。最典型的坑是精度标准不统一。TOPS 的全称是 Tera Operations Per Second但“一次操作”到底算多少位宽各家的口径完全不同。大部分消费级和嵌入式芯片标注的是 INT8 稠密算力有些标注的是 INT8 稀疏算力利用权重稀疏性最多算 2 倍还有些标注的是 FP16 算力。做个简单换算同一块芯片INT8 稠密算力如果是 100 TOPSFP16 通常是它的 50% 左右也就是 50 TFLOPS。如果标称是稀疏 INT8那么密集计算场景下要打五折只剩 50 TOPS。再往下到 FP32一般只剩 INT8 的 1/4 甚至更少。所以在对比两块芯片时先把它们换算到同一个标准和精度下再说。我整理过一个简化对照表方便快速估算标称指标实际等效 INT8 稠密算力估算标称 100 TOPS (INT8 稀疏)约 50 TOPS标称 50 TFLOPS (FP16)约 100 TOPS标称 25 TFLOPS (FP32)约 50 TOPS按 FP32 是 INT8 的 1/4 粗估这个换算很粗糙不同架构差异很大但至少能帮你避免被参数表牵着鼻子走。2.2 算力只是门槛内存带宽和容量才是真正的天花板这是一个我早期栽过跟头的点。当时我评估一块国产板卡官方标称 NPU 算力 6 TOPS跑一个 YOLOv8s 应该问题不大结果实际帧率只有预期的一半。后来用 profiler 一看瓶颈根本不在 NPU 计算单元而在内存。原因在于模型推理不是一个“算完就结束”的过程。每一层卷积、矩阵乘都要把权重和中间特征图从内存搬到计算单元算完再写回。对单帧 640×640 输入的检测模型来说中间特征图动辄几十 MB权重和激活反复搬运内存带宽一旦不够NPU 就处于“等数据”的状态算力再高也白搭。内存容量同样关键主要体现在三个地方模型文件本身。一个 YOLOv8m 的 INT8 模型大约几十 MBFP16 版本翻倍这个还好。运行时中间缓冲区。多路视频流 多模型并行时中间缓存会成倍增长。大模型/多模态模型的权重驻留和 KV Cache。一个 7B 模型做 INT4 量化后权重约 4GB推理时 KV Cache 还要额外占几百 MB 到几 GB。如果内存只有 4GB模型加载完就快满了系统直接触发 swap整个延迟曲线陡增。所以选型时我不只看 TOPS还会做一道简单验算模型权重大小 运行时缓冲 系统预留必须小于整板可用内存的 70%留出余量。2.3 算力利用率才是不同芯片拉开差距的地方同一款模型在不同芯片上跑出的实际有效算力差距比参数表大得多。我见过很典型的一组对比一块标称 32 TOPS 的 GPU 板卡跑一个小型检测网络换算下来有效算力利用率能到 50% 以上另一块标称 50 TOPS 的专用 NPU 板卡跑同一个网络因为算子没有完全落到硬件加速单元上有效利用率可能只有 25%。最后实测下来反而是标称 32 TOPS 那块的端到端帧率更高。造成利用率差异的原因包括推理框架与硬件是否深度适配、算子是否被融合优化、张量内存布局是否连续、驱动程序是否成熟、NPU 任务调度是否有明显空泡。这些在官方 demo 里通常看不出来——因为厂商会把自家芯片优化最好的几个网络放出来给你跑但你的真实业务模型往往是组合的、多路的、动态的。所以我给自己定了一条规矩参数表只用来初筛真实利用率必须靠实测。具体怎么测后面有专门章节讲。2.4 LLM/VLM 的“Token 算力需求”怎么估现在具身智能项目基本都在往多模态大模型方向走端侧跑 LLM/VLM 已经是常见需求。很多第一次接触这个的人看到 7B、13B 参数就焦虑这得多少算力其实可以算一笔账。以 7B 模型、FP16 推理为例每生成一个 token 需要的大致计算量约为参数量乘以 2 的一半也就是约 7B × 2 FLOPs ≈ 14 GFLOPs实际通常按每 token 约 3.5 GFLOPs 转运算考虑到 KV 缓存复用不同实现差异不小。如果目标速度是 20 tokens/s那需要的算力大约 70 GFLOPS也就是 0.07 TFLOPS。单看这个数字似乎任何端侧芯片都能跑。但大模型的瓶颈从来不是算力而是内存带宽。因为在自回归解码时每生成一个 token 都要把全部权重读一遍7B 模型 FP16 权重就是 14GB要跑 20 tokens/s内存带宽需要 14GB × 20 280GB/s。这个数字对绝大多数端侧板卡是遥不可及的——Jetson Orin NX 的内存带宽大约 102GB/sRK3588 大概只有 50GB/s 级别。所以端侧跑大模型的现实选择是量化到 INT4/INT8把权重降到 4-7GB同时用更小的输入、更长的 KV Cache 来换取体验。做这个评估时我建议先看内存带宽再看算力顺序反了容易得出“随便都能跑”的错误结论。3. 车载/机载环境里容易被忽略的约束供电、散热、振动与实时性3.1 供电标称功耗是“平均功耗”峰值功耗才是选电源的依据很多规格书只标一个“典型功耗”比如 Jetson Orin NX 写 10-25WRK3588 写 3-10W。但实际跑起来尤其是在系统启动、多核并行、NPU 满载瞬间功耗会有一个明显的尖峰。我用电流探头测过 Jetso Orin NX 在 15W 模式下的上电瞬间电流能到 3A12V 以上比稳态 1.25A 高出不少。如果整车电源线径细、稳压模块余量不足一上电就重启。这类问题在单板调试时不会出现因为电源是实验室线性电源或稳压模块整机联调时才开始“神秘重启”。选电源模块和线缆时建议按“标称持续功耗的 2 倍”来留余量并且用示波器或电流探头实测如下几个指标上电瞬间的浪涌电流NPU 从空闲到满载时的电流上升斜率板卡电压跌落幅度低于 5% 就要警惕电源纹波特别是 DC-DC 开关频率附近的纹波只要这些数据没测就不要在电源上省成本。整机无法稳定运行往往先怀疑软件最后发现是供电浪费大量排查时间。3.2 散热无风扇 高温环境连续跑性能可能降到标称的 70%散热是所有端侧选型里最容易被低估的环节。以一款标称 32 TOPS 的板卡为例它在 25°C 室温、风扇直吹的情况下连续跑满负载 20 分钟核心温度可能稳定在 65°C频率不掉帧率稳定。但把它放进密封舱体周围还有电机驱动器发热环境温度 45°C同样持续跑 20 分钟核心温度很容易冲到 85°C 以上这时候 SoC 会开始降频帧率可能掉到满帧的 70% 甚至更低。我自己的测试经验是选型阶段不能只看“能跑到多少 TOPS”要看“热稳态下能持续跑多少 TOPS”。一个简单的评估方法是做“温升测试”在室温环境下让板卡跑满推理负载。记录 30 分钟内的核心温度曲线和推理帧率曲线。观察帧率开始下降的“拐点温度”。再根据目标部署环境的最高环境温度估算热稳态下的可用性能。如果条件允许放到高温箱里做 65°C 或 70°C 的测试。很多所谓“过不了的坎”在高温箱里暴露得特别快也特别值得在选型阶段就发现。3.3 振动、结构、连接器小车一颠数据就断具身智能设备是运动的。车会过减速带机械臂会高速加减速无人机要扛气流。这些振动对板卡选型的影响远不止“拧几个螺丝固定”那么简单。有三个地方我踩过坑连接器。开发阶段大家都用 type-C 供电 USB 转调试但振动环境下type-C 这种弹片接触的接口很容易瞬时断连。车载/机载项目尽量用带锁扣的航空插头、M12 连接器或 FPC 加固座子接口处再点胶/加固定夹。板卡与外壳的固定。直接用铜柱单点支撑振幅一大板卡就共振导致内存颗粒虚焊、PCIe 链路报错。建议加减震支架或至少 4 点支撑。存储。趁早选工业级 eMMC/SD 卡别用消费级 TF 卡。我在无人机上遇到过几次“飞着飞着存储掉盘”最后都是卡本身锁死导致的。车载和机载场景对可靠性的要求本来就更高如果产品要走量产和认证ISO 16750、GB/T 28046、DO-160 这些标准都要提前调研。别等开发到一半才想起来改连接方案那时候的改动成本是最高的。3.4 实时性Linux 默认调度满足不了控制周期端侧推理板卡上一般跑的是 Linux 系统普通调度策略下CPU 任务、NPU 任务、中断处理会出现毫秒级抖动。对纯视觉检测来说单帧偶尔慢 20ms 也许无所谓但对机器人控制来说这就可能是致命的。举个例子机械臂的控制周期通常是 1ms 或 2ms视觉给到的是 30Hz 的检测结果这个环节通常不会硬同步。但一旦系统 CPU 瞬时过载控制指令下发被延迟几个毫秒机械臂就可能出现轻微抖动长期运行容易积累位置误差或触发安全保护。所以如果系统里有实时控制需求建议在选型阶段就确认芯片/板卡是否支持 PREEMPT_RT 实时内核补丁NPU/GPU 任务是否支持优先级配置是否有可用的 lock-free 或偏执内存分配机制相关驱动是否兼容实时环境做实测时不要只看平均延迟要看 P99 延迟和最大延迟。平均 10ms、最大 80ms 的方案在控制场景下不如平均 12ms、最大 15ms 的方案可靠。4. 实测过的几类方案SoC 模组、工业整机、国产 NPU 板卡的真实表现这部分我不会直接说“某某芯片秒天秒地”因为没有万能芯片只有适不适合你的场景。下面是我在不同项目里实测过的几类主流方案统一测试模型是 YOLOv8s640×640INT8、RT-DETR如果芯片跑得动、以及一个 2B 左右的 VLM 做 token 速度参考。环境统一为 25°C 室温主动散热持续运行 30 分钟取稳定值。4.1 NVIDIA Jetson Orin NX 16GB生态最省心功耗/散热压力最大Jetson 系列在端侧 AI 里的地位基本就是“默认选项”。TensorRT、DeepStream、Isaac ROS软件栈成熟度在嵌入式平台里没有对手。我实际测试在 20W 模式下跑 YOLOv8s INT8单帧延迟大约 10-15msFP16 大约 15-22ms稳定性很好。跑 2B 级别的 VLM量化后 token 速度大概在 20-40 tokens/s 之间这个表现目前其他平台很难追。但它有两个明显的坑价格过高。16GB 版本整体模组成本动辄大几千做量产设备很难受。功耗释放需要散热保障。如果整机只能被动散热且环境温度高20W 模式降频后性能可能反而不如一些主动散热的国产方案稳定。适合场景研发原型、算法快速验证、对软件生态依赖强且预算充足的量产项目。4.2 瑞芯微 RK3588/RK3576成本敏感型方案的起步选择瑞芯微这两年在端侧 AI 板卡里性价比很高。RK3588 标称 6 TOPS NPUINT8支持 RKNN 工具链。我实测同一款 YOLOv8sINT8RK3588 单帧延迟大约 18-28ms不同批处理和线程配置差异较大。坦率说这个性能和标称 6 TOPS 的“纸面算力”相比利用率不算高可能只有 30%-40%。但放在很多对实时性要求没那么苛刻的场景——比如机械臂抓取、巡检机器人、复合机器人——它能满足需求而且整板成本只有 Orin NX 的三分之一甚至更低。RKNN 工具链这几年进步明显支持的算子覆盖度已经能覆盖 YOLO 系列、RT-DETR、常见分割模型。但一旦遇到结构比较新、算子特殊的模型就可能需要手写自定义算子或做结构改写这个成本要在项目排期里预留。RK3576 是更低功耗更小算力的选择适合轻量视觉和电池供电产品。4.3 地平线征程系列、寒武纪、黑芝麻等车载/机器人专用芯片这几家是路线更“专用”的方案。以地平线征程系列为例BPU 架构对自动驾驶、机器人场景的视觉感知算子覆盖度很高像 BEV、OCC、Transformer 这类重量级网络理论上在专用工具链下能跑出不错的能效。但这类方案的实际情况是工具链和文档偏向“合作伙伴制”个人开发者、小团队拿不到完整资料社区生态也不如 Jetson 和瑞芯微。我尝试过用征程系列跑自定义模型算子转换过程中遇到问题FAE 响应周期长最终拖慢了项目进度。所以我的判断是这类芯片更适合有量产规模、有专门软硬件团队、与芯片原厂建立合作关系的公司。如果一个项目还是原型验证期用这类芯片的风险会偏高。4.4 工业整机/工控机方案验证最佳量产不合适很多团队早期喜欢买现成的工业整机比如带 RTX 4060 的工控机、带高性能 NPU 的盒子。这类方案的优点是即插即用性能强软件栈就是桌面生态随便折腾。我早期做无人车原型时就是一台工控机 GPU软件调试效率特别高。但它的缺点也很明显体积大、功耗高、价格贵而且整机内的 GPU 能力对最终量产芯片方案的参考价值有限。你的量产设备不可能塞一台 500W 的工控机进去。所以我的建议是原型阶段放心用整机验证算法和系统设计但不要因此拖后启动芯片方案的评估。趁着原型验证期同步把量产芯片方案拉通测试才能避免后面“算法跑得很顺硬件换不过来”的尴尬。4.5 实测对比小结方案标称算力参考YOLOv8s INT8 单帧延迟参考生态成熟度量产成本适合阶段Jetson Orin NX100 TOPS10-15ms高高研发/量产RK3588 板卡6 TOPS18-28ms中低成本敏感量产地平线/寒武纪等因型号而定需专项测试中低偏合作伙伴中规模化量产工业整机视 GPU/NPU5-20ms高高原型验证以上数据是我在固定环境下的实测参考不是基准测试不同驱动版本、推理框架、输入规模结果差异很大。重要的是方法不是具体数字。5. 可复现的选型与验证流程从需求分解到上机实测5.1 第一步把产品需求翻译成算力需求选型之前先花两天时间把产品需求拆成算力需求。别嫌麻烦这一步做得越细后面越不容易反复。我一般用一张表格来拆功能模块模型/算法输入尺寸单帧耗时预算运行帧率/频率并发路数精度要求障碍物检测YOLOv8s640×640≤30ms30 FPS4 路INT8语义分割RT-DETR512×512≤50ms10 FPS2 路INT8视觉问答2B VLMINT4图片文本≤2s流式1 路FP16/INT8运动规划规则/PPO-≤5ms100Hz-FP32然后做算力估算。以 YOLOv8s 640×640 为例它的计算量大约为 15 GMACs/帧。30 FPS 时需要的算力是15 GMACs × 30 FPS × 2MAC 转 OPS 900 GOPS 0.9 TOPS但这个数字只是“纯卷积计算”还要乘以一个利用率和系统开销系数。我通常按 30%-50% 的实际利用率来反推也就是0.9 TOPS ÷ 0.3 3 TOPS也就是说跑这一个模型至少需要标称 3 TOPS 以上的方案才稳。如果还要同时跑分割、VLM以及系统调度、传感器驱动、日志存储整体再乘 1.5-2 的并发冗余。估完需求后再列硬件约束表。比如供电范围 9-36V、功耗预算小于 30W、部署环境温度 -20~60°C、防护等级、接口需求几路 USB、几路网口、几路 CAN、以及单板成本上限。这些条件列完候选方案基本就筛掉一大半了。5.2 第二步:评估软件栈与工具链的“隐藏成本”这一步很多人会忽略但它往往是决定项目能不能按计划交付的关键。评估软件生态时我会实际去触摸几个问题官方推理框架对我要用的模型是否直接支持还是需要修改网络结构模型转换工具是否稳定有没有社区文档和示例驱动是否支持我需要的摄像头、激光雷达型号遇到算子不支持时我能否自己实现或绕过代价是什么官方 FAE/技术支持响应速度如何是邮件等三天还是当天能拉群这些问题的答案直接决定你的开发周期。硬件的坑坑两三天能解决工具链的坑可能一两周都填不完。尤其是做量产前还要确认芯片原厂的供货周期、BSP 长期维护计划和量产认证支持。5.3 第三步用最小系统做一次 48 小时上机实测候选方案缩小到 2-3 个后我会各买一块官方开发板或模组跑一轮标准化的“最小系统实测”。这部分内容我建议做成一套 checklist方便团队里每个人都按同样的口径执行性能测试用你的真实业务模型不是官方 demo分别测 FP16/INT8/INT4 的帧率、单帧延迟、P99 延迟。精度测试记录转换前后的 mAP 下降幅度。掉点超过 2%-3% 就要慎重可能需要混合精度或改动量化方案。内存测试监控运行 1 小时后的内存占用最大值、CPU 占用率、是否有内存泄漏。功耗测试用电流探头记录待机、满载、峰值三种状态的电流和电压计算稳态功耗与峰值功耗。温度测试在室温 25°C 下跑满负载 30 分钟记录核心温度和性能变化曲线有条件就进高温箱做 60°C、70°C 各 2 小时。稳定性测试7×24 长时间跑观察是否出现死机、重启、内存泄漏、NPU 资源释放异常。并发测试模拟真实多任务场景比如 4 路视频 1 路 VLM 控制程序并发看资源抢占和延迟抖动情况。一次完整的实测数据比十份规格书都有用。我在选型时往往会因为一个 P99 延迟数据而否决一个“纸面性能很强”的方案也会因为一个“7×24 不死机”的实测而接受一个算力略低的方案。5.4 第四步把“二次开发”纳入选型评估很多芯片/板卡拿到手之后不是直接能用的。BSP 定制、外设驱动、容器环境、调度策略、散热方案、电源管理、加密模块每一项都是“二次开发”。我见过有团队选了国产芯片硬件成本省了 2000 块结果工具链不成熟三个算法工程师调了一个月才把模型跑通人力成本远超省下的硬件钱。所以最后一步选型决策不只是看芯片规格还要看原厂/方案商是否支持二次开发是否是开放 SDK还是黑盒 APIBSP 是否提供源码kernel 版本和驱动是否能满足系统定制需求是否有成功落地的同行业案例资料是否齐全社区是否活跃遇到问题能否快速找到答案这个评估比参数对照表还重要。毕竟硬件是买一次软件栈是要养整个产品生命周期的。6. 选型决策里那些“想当然”的坑和我的应对习惯6.1 “峰值 TOPS”最大的坑宣传口径不等于连续运行我见过一个项目选芯片时只看官方宣传的“XX TOPS”整机设计时按 70% 的算力利用率排性能预算。结果真机跑起来只要环境温度超过 40°C芯片就开始降频很多算子执行时间翻倍最终系统帧率不达标。我的应对习惯是不管规格书怎么写一律按“热稳态有效算力”去估算。做法很简单查规格书里的热设计功耗TDP和最大结温结合自己的散热方案估算 70°C 结温下的持续频率再按这个频率去算实际算力。宁可前期低估不要后期返工。6.2 板卡便宜但散热垫和风扇偷工减料有段时间国产板卡价格战打得厉害市面上出现很多标称性能很高、价格极低的板卡。买回来实测才发现SoC 与散热器之间的导热垫用的是低劣材料厚度不够、导热系数虚标风扇也是普通滚珠轴承三个月后噪音变大、转速下降。所以即使是买现成板卡我也建议第一次拿到货就拆开看一眼散热设计用热电偶实测散热器表面温度和核心温度确认热阻是否符合预期。批量采购时要求供应商提供出厂满载老化测试报告。6.3 多路视频流不是“单路 × 路数”那么算很多平台标称“支持 8 路 1080p 解码”或“支持 4 路 DCU 视频流”但实际跑起来多路视频流的瓶颈通常不在解码器而在内存带宽、ISP 通路、预处理算力和 NPU 算子并行度。比如 4 路 YOLO 推理不是每路 20ms四路就 80ms而是所有路共享内存带宽和 NPU 资源延迟可能从单路的 20ms 涨到 35ms 甚至更高。我习惯在实测时专门加一个“并发路数递增”测试从 1 路逐步加到目标路数每加一路记录帧率、延迟、内存和 NPU 利用率观察是否存在非线性恶化。这个测试能早几个月暴露系统扩展性问题。6.4 选型检查清单我每次必过一遍的最终列表把散落上面的经验汇总成一个快速检查清单我在项目决策时至少会过两遍[ ] 是否换算过所有芯片到同一个精度口径[ ] 是否用实际业务模型跑过胜率/精度对比[ ] 是否实测过稳态功耗、峰值功耗和上电浪涌[ ] 是否做了高温箱测试确认热稳态性能[ ] 是否测过 P99 延迟而不是只看平均帧率[ ] 多路并发时是否存在非线性恶化[ ] 工具链是否覆盖全业务模型算子缺失成本有多大[ ] 原厂是否有 FAE 支持响应速度如何[ ] 是否确认长期供货和量产稳定每一项背后都是真实项目里踩过的坑。把它做成流程不是为了显得专业而是因为凭感觉选型真的是要付学费的。做端侧 AI 选型这几年我最大的体会是没有“最强”的算力芯片只有“最匹配需求”的方案。先把自己的场景摸透再谈选型顺序不能反。如果你正在为具身智能设备选型希望这份踩坑记录能帮你省下几周返工时间。按这个流程走下来你可能会发现很多原本纠结的问题在实测数据面前都会变得非常清楚。
