端侧AI算力选型实战:从标称TOPS到真实吞吐的避坑指南

📅 发布时间:2026/9/9 2:23:24
端侧AI算力选型实战:从标称TOPS到真实吞吐的避坑指南 去年帮客户落地一台园区巡检机器人整车方案选得很快最后卡在计算盒子这一步。客户最初看中的板卡标称 200 多 TOPS真正装车一跑供电回路受限加上散热条件不给力核心直接降频YOLOv8s 硬是跑不到 11 帧每秒。类似的事情这些年我遇到过太多而且几乎每次都有人把“端侧 AI 算力”理解成“芯片标称算力”最后在实物交付阶段不得不返工重新选型。这篇文章就是把我在具身智能车载/机载场景里做端侧 AI 硬件选型的经验做一次系统复盘。我会从“算力到底该怎么定义”讲起横向对比几款我实际测试过的算力芯片再给出一套可以直接套用的选型评估方法。内容主要面向正在做机器人、自动配送车、无人机边缘计算盒或者准备进入端侧 AI 项目开发的朋友。如果你也吃过“标称算力高、实机跑不动”的亏这篇文章应该能帮你少走不少弯路。1. 端侧 AI 算力到底该怎么理解先丢掉 TOPS 焦虑1.1 “算力越高越好”是选型最大的坑每次聊到端侧 AI 硬件总有人直接抛出一个问题“这颗芯片有多少 TOPS”好像 TOPS 数字越大这东西就越高级。但实际上TOPS 只代表芯片在理想条件下、以特定精度和特定算子组合跑出的峰值计算能力。它更像是发动机铭牌上的“最大功率”可你的车能不能跑到那个速度还得看变速箱、轮胎、风阻、路况。真正影响端侧 AI 落地的是一整套系统内存带宽、缓存层次、算子适配度、功耗墙策略、散热设计甚至供电回路。举个实测案例。我们测试过一块标称 110 TOPS INT8 的 AI 模组跑 ResNet50 系列分类网时吞吐量确实还不错但只要换成带跨层连接的目标检测网络帧数直接掉了三成多。原因不在算力不够而是 NPU 对这类网络结构的算子融合做得不好数据在内存和计算单元之间反复搬运算力被白白浪费。这种现象不是个例越是标称算力高的芯片实际性能越容易受网络结构影响。所以第一步一定是摆脱“唯 TOPS 论”把思考重心放到“系统能跑出多少有效吞吐”上。1.2 具身智能的三种典型负载画像要做选型得先搞清楚具身智能系统到底在算什么。以我接触过的车载和机载项目为例负载大致可以分成三类。第一类是环境感知类对应目标检测、语义分割、BEV 感知、点云处理这类任务。特点是计算密集程度高且对单帧延迟有明确要求。比如自动驾驶场景里的视觉感知链路从图像输入到输出目标框通常需要控制在 30-50ms 内无人机避障场景更苛刻关键决策路径可能要求 20ms 级别。这类负载最适合用 GPU 或带强力 SIMD 单元的 NPU 来跑。第二类是决策规划类典型的如基于端到端模型的路径规划、VLA 模型、部分具身智能大模型。这类负载的算力要求不一定比感知高多少但对内存带宽和容量极其敏感。我们测过在一个 8GB 内存的板卡上跑 2B 参数级别的多模态模型算力完全够内存却先爆了频繁触发换页单次推理时间从几百毫秒拖到几秒。第三类是控制类任务包括轨迹插补、伺服控制、状态机管理。这类任务计算量不大但是对实时性和确定性要求极高通常需要独立的 CPU 核和实时操作系统来保证。选型时很容易忽略这一类负载因为它的浮点运算量看起来不值一提可一旦 CPU 被感知链路占满整个系统就持续出现调度抖动。1.3 端侧 AI 的“三重约束”功耗、散热与确定性在很多人的理解里选型就是对比参数表挑一个“算力最高、价格合适”的芯片。但放到车载/机载环境下必须同时满足三重约束。功耗约束是最直观的。车载场景里计算盒子通常从 12V/24V 蓄电池取电整机可用的功率预算往往只有 30W-100W机载场景更紧张一个树莓派级别的空载平台能分给计算单元的功率常常不到 20W。这就意味着你选了一块 60W 的板卡不是给它接上电就能跑满要先把供电、散热、系统预留都算进去。散热约束紧随其后。芯片的功耗最终都会变成热量。一块长期跑 60W 的板卡如果不做主动散热核心温度很快就会冲到 85℃ 以上然后触发降频。机载场景尤其麻烦很多无人机封闭舱体几乎没有风道被动散热器的散热效率极其有限夏天户外一晒太阳降频问题就会在几分钟内出现。确定性约束则是机器人行业特有的要求。工业机械臂的控制周期可能是 1msAGV 的制动决策不允许有 50ms 的随机延迟。消费级芯片在面对满负载时往往会出现任务调度的随机抖动这在 PC 上无所谓但在具身智能系统里可能直接导致安全事故。所以选型不仅要看平均性能还要保证关键路径上的响应时间可预测。2. 车载/机载算力芯片横评我实测过的几款架构2.1 NVIDIA Jetson / DRIVE生态成熟但功耗墙要自己调NVIDIA Jetson 系列应该是端侧 AI 项目里最常见的平台了。我在不同项目里用过 Orin Nano、Orin NX 和 AGX Orin也接触过 DRIVE Orin 的车规版本。先说结论它的软件生态确实是最好的CUDA、TensorRT、DeepStream 这条链路非常成熟从 PC 上的模型到端侧部署资金成本和时间成本都相对低。Orin NX 是我用得比较多的一款模组标称算力从 70 TOPS 到 100 TOPS 不等实际工程中常以 8GB/16GB 内存版本区分。它的优势是尺寸小、功耗档位灵活可以通过配置供电模式工作在 10W 到 25W 之间。但我必须提醒一点默认的“最高性能模式”和你的整机功耗预算经常打架。实测中我们把 Orin NX 设到 25W 模式跑一个分割模型帧数比 15W 模式只提升了 35%但整机温度很快从 65℃ 升到 80℃以上。如果散热条件一般倒不如选一个折中的功耗模式换来更稳定的长时间运行表现。AGX Orin 那块 64GB 版本就是另一回事了。它的峰值算力确实高能跑到 200 TOPS 以上适合做多路感知融合、大模型推理这类重负载。可它的功耗也是真的大正常部署大多在 40W-60W 跑。我们在一台户外巡检车上测过夏天 35℃ 环境、密闭控制箱里就算有工业风扇持续吹核心温度还是压不住最后不得不换用带空调的控制箱。所以选 AGX Orin 前一定要想清楚你的车/机舱里究竟能不能给它一个凉爽的“家”。2.2 地平线征程、寒武纪、昇腾工具链适配决定真实体验最近几年国产算力芯片在端侧 AI 赛道上存在感越来越强地平线征程系列、寒武纪 MLU 系列、昇腾系列我都有实际测试经验。先说一个总体感受这些芯片的硬件规格很多已经和国际品牌持平甚至更高真正的差距或者说真正的难点在软件工具链上。地平线征程 5/6 系列走的是 BPU 架构对视觉感知类网络的支持相当不错特别是针对车载场景做了很多算子优化。我们曾把一套 BEV 感知模型从 NVIDIA 平台迁移到征程平台模型的量化工具使用起来比预期顺手但前提是网络的算子必须落在工具链的支持范围内一旦遇到自定义算子就得花时间手写或改网络结构。而且迁移后的精度要仔细校验INT8 量化在某些检测头里会掉点 1%-3%对精度要求高的场景可能无法接受。寒武纪和昇腾系列在服务器端的表现我不多提单论端侧寒武纪 MLU220 这类边缘加速卡的功耗控制不错对标一些视觉任务时吞吐量可观昇腾系列的计算能力很强支持的大模型生态也在快速扩展。但实际项目里大家更关心的是能否顺利把 PyTorch/ONNX 模型跑起来这部分体验各家差异很大。我的建议是如果团队没有充裕时间做算子移植和性能调优尽量选择工具链更成熟、社区案例更多的平台省下的都是真实交付时间。2.3 TI TDA4VM、高通 8295、瑞芯微 RK3588非 GPU 形态的嵌入式路径除了上述两类平台车载/机载领域还有一些偏嵌入式风格的方案它们没有动辄几百 TOPS 的宣传但胜在稳定、功耗低、实时性好。TI TDA4VM 是我在低速无人车上用过最多的芯片之一。它集成了异构计算单元有通用 DSP、C7x DSP、MMA 深度学习加速器标称算力只有 8 TOPS 左右但跑视觉感知前处理、雷达数据处理这些任务效率很高。更重要的是它支持 QNX、RT-Linux 这类的实时系统很多车厂级项目选它是冲着“确定性”来的。缺点也很明显工具链相对封闭学习成本高做复杂模型部署的效率不如 NVIDIA。高通 8295 常见于座舱域控制器但这两年也有不少机器人项目拿它做域控主芯片。它的优势是 CPU 性能很强、GPU 也不错适合需要跑座舱交互、视觉感知和部分 AI 推理的一体化设备。但我们测试下来它在 AI 负载上的性能释放受功耗管理策略影响很大跑长时间连续推理的时候容易降频而且 NPU 的软件生态相对难上手。瑞芯微 RK3588 在端侧 AI 项目里算是性价比之选自带 6 TOPS NPU虽然单看算力不高但胜在平台整体便宜、外设接口多、开发资料丰富。很多教育机器人、轻量级巡检机器人拿它当作主控跑一些轻量化的检测模型勉强够用。可一旦负载超过 4-5W散热压力也会明显上涨所以它更适合对算力要求不高的低成本项目。2.4 标称算力和实际吞吐差在哪把这几类芯片放在一起看会发现一个规律标称算力最高的板卡实测性能不一定对应最高。实际决定吞吐量的因素包括API 能够调用的计算单元效率、内存带宽是否足够、编译器对模型的优化程度、以及运行时的功率策略。我用一组数据说明。同样是跑 YOLOv5s INT8 模型某国产加速卡标称算力 32 TOPS实测吞吐量约 90 FPS另一个平台标称 26 TOPS但 TensorRT 优化得非常好实测能到 130 FPS。差距的核心就是软件栈成熟度。所以“标称 TOPS”只能用来做初筛真正的对比还是要把同一份模型拿到各平台上去实测。3. 硬件选型的实操方法论从需求反推芯片3.1 先跑模型再选芯片跳过这一步一定会后悔我见过太多项目是先定硬件再跑模型结果模型部署时发现算子不支持或者性能差到没法用只能返工。正确做法是反过来把项目里最核心的 3-5 个代表性模型准备好在候选芯片的开发者套件上先跑出真实性能数据再决定买哪款。具体步骤大概是这样的。第一整理出项目中的关键模型列表。比如自动驾驶场景至少包含目标检测模型、语义分割模型如果涉及多传感器还要准备点云模型。第二确定推理精度和延迟目标。对机器人来说导航避障的检测延迟目标一般低于 30ms如果是主动安全类功能要求就更苛刻。第三把模型转换成目标平台支持的格式在官方开发套件上跑出性能数据。这一步很重要但也要提醒一句开发套件上的数据和你量产板卡上的数据可能有差异尤其是散热和供电环境不同的时候数据只能作为参考。3.2 功耗、散热、供电怎么量化计算很多项目拿到一块板卡看到的功耗“典型值”是 15W于是想当然以为 15W 电源就够了。实际上典型功耗往往是用某种固定负载模式测出来的真实 AI 负载的瞬时功耗能高出典型值 30%-50%。我之前测过一块标注 25W 的模组在跑双路视频分析时峰值跑到 38W如果电源选小了系统就会在关键时刻触发欠压保护或重启。选型时可以拿这个公式做粗略估算系统总功耗 ≈ 计算单元平均功耗 × 1.3峰值余量 传感器功耗 控制单元功耗 散热风扇功耗。假设你选定了一块平均 20W 的 AI 板卡其他外设加起来 10W那电源至少要做到 20×1.310 36W再留 20% 的余量建议选择 45W 以上、具备持续输出能力的电源。散热方面简单来说每 1W 功耗需要一定散热面积。以被动散热为例经验值大约 1W 需要 20-30 平方厘米的散热器面积还要看风道和环境温度。一块 20W 的板卡光是被动散热器就得做到 400-600 平方厘米这个体积在紧凑的机载舱内往往放不下。如果空间受限就得考虑主动风扇或热管方案。3.3 内存带宽和 IO 带宽是隐藏瓶颈我最初选型时也只看芯片的 TOPS后来发现很多场景真正卡脖子的不是算力而是数据搬运能力。一个简单的计算1920×108030fps 的 RGB 图像原始数据量约等于 1920×1080×3×30 ≈ 186MB/s。如果系统要同时处理 4 路摄像头外设 IO 就要吃 744MB/s再加上模型中间特征图的读写内存带宽需求很容易超过 10GB/s。一些低功耗 SoC 的内存带宽只有十几 GB/s这意味着处理器经常在等待数据实际利用率非常低。所以选型时一定要看三个参数内存类型和通道数、外设接口带宽MIPI/PCIe/GbE、NPU/DSP 与内存之间的互联带宽。同级别的芯片内存通道数多一档实际性能可能差出 20%-30%。这也是为什么有些算力不高的板卡在视频流处理场景下反而比纸面上更强的芯片表现更好。3.4 写一张属于自己的选型权重表与其到处问“哪款芯片最好”不如自己做一张权重表。我常用的是下面这个结构你完全可以按项目需求调整权重。评估维度权重建议测试/评估方式备注有效吞吐量25%跑实际模型测 FPS/延迟比标称 TOPS 更可靠功耗与散热20%满负载连续跑 30 分钟测功耗与温升关注峰值功耗内存/IO 带宽15%对比多路视频流场景多传感器融合必看软件工具链成熟度20%试编译、量化、推理部署算子覆盖是重点实时性与确定性10%测量 P99 延迟和抖动对控制类任务很重要成本与供货10%综合 BOM 和交期车规/工规供货差别大每个维度按满分 5 分打分最终加权求和。这样选出来的硬件不一定是最便宜的也未必是算力最高的但大概率是最贴合你实际项目需求的。4. 一轮完整的选型实测复盘从样片到上车的距离4.1 测试环境怎么搭才可信做过一次测试环境搭建具体场景是给一款室内物流 AGV 选计算平台。我们先搭了三种测试环境桌面开放环境、密闭控制箱环境、模拟夏季高温环境。桌面开放环境用来快速验证模型兼容性和基础性能跑通了再搬到密闭环境。密闭控制箱模拟真实车载环境温度控制在 50℃ 左右观察板卡在持续负载下的降频曲线。高温环境则是把整机放进恒温箱设置到 60℃模拟夏天暴晒后舱内温度。如果你预算有限至少也要做桌面环境和密闭环境两轮测试因为二者数据差异可以非常明显。为了测准功耗和温度我用到了直流电源带电压电流显示和记录功能、K 型热电偶、红外热成像仪。软件方面NVIDIA 平台的 tegrastats 可以输出各核心频率、温度和功耗国产平台也要尽量找类似的监控命令没有的话就用功率计直接测整机功耗。4.2 实测数据从标称 TOPS 到真实速度那次测试一共对比了三款板卡A 款是某国产 32 TOPS 加速卡B 款是 Orin NX 16GB25W 模式C 款是 RK3588。测试负载是同一份 YOLOv5s 模型输入分辨率 640×640量化精度 INT8结果如下平台标称算力实测 FPS平均延迟整机功耗满载核心温度密闭50℃环境国产加速卡 A32 TOPS92 FPS10.8ms约 18W84℃Orin NX100 TOPS128 FPS7.9ms约 27W78℃RK35886 TOPS35 FPS28.5ms约 9W72℃有意思的是国产加速卡 A 标称算力远高于 RK3588但实际 FPS 只有 Orin NX 的七成左右。主要原因还是在算子优化和推理框架的成熟度。所以单看这颗芯片“能算”没多大意义还是要落到“能跑多少帧”上来判断。4.3 热管理实战机载盒子的降频修复案例有一次做无人机机载边缘计算盒选了一款 20W 级模组整机封装成被动散热。刚开始在实验室 25℃ 环境测试一切正常一到户外烈日下飞行不到 3 分钟就开始降频检测帧率从 40 FPS 掉到 15 FPS。排查下来其实不复杂外壳是黑色铝合金阳光直射时表面温度能到 65℃加上舱内封闭没有风道热量全堆在芯片附近。后来重新设计了结构外壳改成浅色喷涂减少辐射吸热内部增加均温板和导热硅脂把热量导到外壳大平面再加上一个微型涡轮风扇在起飞阶段辅助散热。改造后同样在户外高温环境跑了 15 分钟核心温度始终在 75℃ 左右没有再出现明显降频。这个案例给我一个教训选型阶段不要只看芯片的“工作温度范围”还要评估实际整机的热流路径。无人机、机器人这类密闭设备电气设计再好散热方案不合格一样白搭。4.4 软件栈的隐藏成本工具链调试是最大的时间黑洞硬件选型还有一个很容易被忽略的成本软件适配时间。我在一个项目里把一套点云处理算法从 NVIDIA 平台迁移到国产芯片光算子适配和精度调试就花了三周。原本以为量化工具支持 ONNX 就万事大吉实际遇到两个问题零散的自定义算子不支持转换只能改写网络结构INT8 量化后检测框偏移又需要重新准备校准数据集。这种成本没法直接写在硬件 BOM 里但它实实在在地影响项目交付周期。我的建议是选型阶段就做一个“算子覆盖度小实验”把项目里最重要的两三个模型用官方工具链完整走一遍转换、量化、部署流程如果发现问题尽早评估是换模型还是换平台。5. 常见问题与选型避坑清单5.1 常见问题速查表现象、根因、对策这些年在端侧 AI 选型与部署中积累了不少排查经验整理成表格更好用。现象可能原因对策标称性能很高实测 FPS 上不去算子优化差、内存带宽不足换用低延迟模型结构或直接换平台长时间运行后帧率波动芯片降频检查散热和功耗模式增加主动散热系统上电后偶发重启电源余量不足换用更大功率电源加缓冲电容INT8 量化后精度掉点校准集代表性不够加大校准集规模尝试混合精度量化模型转换时报不支持算子工具链算子覆盖不全改写算子或用官方支持算子替换多路视频输入后 CPU 占用异常高前处理未用硬件加速把缩放、格式转换放到 GPU/NPU 上处理5.2 “车规级”不等于“上得了车”很多朋友一听芯片是“车规级”就觉得随便装。实际上“车规级”背后是一整套标准体系比如温度范围、抗振动、 EMC 特性、功能安全等级、长期供货承诺等等。一块芯片达到了车规认证不等于你在系统集成时不做任何可靠性设计。车载和机载场景里我更关注几个容易被忽视的点一是整机的工作温度范围尤其是夏天密闭控制箱内可能远超一般消费级芯片的承受能力二是供电系统的抗浪涌能力车辆启动瞬间的电压跌落和浪涌都可能让计算单元重启三是长期稳定供货和生命周期管理消费品项目换芯片无所谓但机器人、汽车项目一款硬件往往要稳定供应 5 年以上。所以选型时一定要把“长期可获得性”摆到和性能同样重要的位置。5.3 标准体系与开放生态带来的新变量最近行业内出现了不少标准性文件包括《人形机器人与具身智能标准体系(2026版)》这样的参考资料也在圈内流传。这类标准虽然不会直接告诉你选哪颗芯片但会逐步影响硬件接口、通信协议、软件框架的规范化程度。以后做具身智能二次开发硬件兼容性和软件可复用性大概率会比现在强很多选型时也可以适当关注目标平台对行业标准的支持情况。另一个趋势是大模型正在进入端侧。以前我们只在端侧跑 CNN 类模型现在越来越多项目开始尝试把 1B-3B 参数的多模态模型部署到机器人上这就对内存容量和带宽提出了新要求。做端侧 AI 硬件部署的朋友如果项目有长期演进需求建议优先选择内存规格可以扩展、NPU 架构对大模型算子有支持的平台。5.4 面向二次开发与学习路线的建议最后一个板块写给准备入门的朋友。我在后台经常看到“具身智能学习路线怎么规划”这类问题就选型这件事而言我的建议是先从一个低门槛平台开始比如 Orin Nano、RK3588 或带 NPU 的开发板把图像分类、目标检测、关键点检测这类基础负载完整跑一遍。在这个过程中重点理解三件事模型如何从训练框架导出并量化、推理引擎如何调用硬件加速单元、整个链路的延迟分布在哪。等基础链路跑通了再慢慢引入传感器融合、实时控制、复杂模型部署等项目这时候再谈“具身智能机械臂”“自动驾驶小车”之类的应用都有了支撑。选型这个东西数据集、模型、散热和实时性远比硬件本身的“纸面算力”重要很多坑只有自己踩过才会真正刻进脑子里。我最终的体会还是那句话把测试环境搭准用真实负载做对比比看一百份产品彩页都有用。