这几年做端侧AI相关项目的朋友应该都有一个共识硬件选型这件事往往比模型本身更让人头疼。尤其是具身智能这个方向车载、机载平台的环境约束和算力需求都跟纯数据中心场景完全是两回事芯片标称的TOPS数字看着挺唬人真正上机跑起来才发现“算力”这两个字的水分比想象中大得多。这篇内容是我在多个端侧AI落地项目里踩坑、填坑之后整理的实测记录围绕算力芯片选型、硬件部署、算力评估这些关键词展开希望能给正在做或者准备做车载/机载端侧AI的朋友提供一份可以直接抄作业的参考。先说清楚这篇适合谁看如果你正在做机器人、无人机、无人车相关的感知和控制项目或者准备把大模型、视觉模型部署到边缘设备上又或者只是对“端侧AI硬件部署”这个方向感兴趣想搞明白算力到底应该怎么评估、芯片怎么选这篇文章应该都能给你一些实在的参考。我会从算力需求评估讲起到主流芯片方案对比、实测方法论、常见坑点一条线拉下来。1. 先搞清楚端侧AI算力选型到底在选什么1.1 为什么这件事这么容易翻车很多团队在项目立项的时候最先做的事情就是查各家芯片的“算力”参数比如某某芯片标称200 TOPS听起来很强就直接拍板用了。这个思路本身没问题但问题出在“TOPS”这个单位实在太容易被误读了。TOPS全称是Tera Operations Per Second也就是每秒万亿次操作。但这里有个关键点大多数芯片宣传的TOPS数值都是基于INT8精度算出来的有些甚至是用稀疏化之后的理论峰值来计算的。而实际跑模型的时候你用的可能是INT8、FP16、FP32混合精度算力利用率往往只有理论值的30%到60%。这就解释了为什么一个标称200 TOPS的芯片实际部署一个中型视觉模型时帧率可能还不如一个标称100 TOPS但编译器优化做得更好的芯片。我在多个项目里测试过不同厂家的芯片这一点几乎是通病。所以做硬件选型的第一个原则就是不要看宣传页要看实际测出来的有效算力。项目启动之前至少要拿目标模型在候选芯片上跑一遍用真实的帧率、功耗、延迟数据来做决策参考。另外还需要注意端侧AI和云端AI的算力评估逻辑不太一样。云端你关注的主要是吞吐量和并发能力而车载、机载端侧场景更关注的是单帧延迟、峰值功耗、持续功耗、散热表现、确定性。一辆车或者一架无人机不可能给你装一个像服务器那么大、风扇呼啸的散热系统芯片的实际功耗表现直接决定了系统能不能稳定运行。1.2 TOPS不是唯一的标尺做选型的时候除了TOPS至少还有四个维度需要同步考虑。第一是能效比也就是每瓦算力。车载和机载平台对功耗极其敏感无人机的电池容量本来就有限如果芯片满载功耗高到50W甚至100W那续航会非常难看。业界现在比较认可的能效比区间是2 TOPS/W到8 TOPS/W按照这个标准去筛选基本能排除一批功耗失控的产品。第二是软件工具链的成熟度。这颗芯片到底支持哪些深度学习框架量化工具好不好用算子库覆盖全不全有没有可视化调试工具这些问题在选型阶段很容易被忽视但到了开发阶段才发现工具链不好用那真的会让人崩溃。我见过一个团队因为工具链问题一个简单的模型移植花了三周而同类芯片上半天就能搞定。第三是内存带宽和容量。算力再高如果内存带宽跟不上数据搬运就会成为瓶颈。尤其是在跑视频流处理、点云处理这类数据密集任务时内存带宽往往比算力更关键。第四是生态兼容性和供应链稳定性。车载、机载这类产品的生命周期很长动辄五到十年芯片厂商能不能保证长期的供货和软件维护这也是硬指标。1.3 具身智能场景的真实算力消耗画像具身智能这个词最近特别热但它背后的算力需求其实和传统的视觉识别、语音交互不太一样。具身智能的核心特征是“感知-决策-控制”闭环也就是说设备不仅要知道自己看到了什么还要实时做出决策并控制机械臂、轮子、桨叶等执行机构动作。这个闭环对端侧算力提出了三个维度的要求多模态感知的并行处理能力、决策模型的推理延迟、以及控制指令的实时性。我自己在做项目的时候总结过一个粗略的算力消耗画像供大家参考。一个基础的视觉SLAM加上目标检测大约需要20到40 TOPS的INT8算力如果加上语义分割和深度估计就需要50到80 TOPS如果还想在端侧跑一个VLA模型或者类VLA的决策模型那就得上到100 TOPS以上甚至200 TOPS。这还只是推理如果要做端侧训练或者在线微调需求就更高了。当然这些数字只是经验范围不是绝对标准但它至少能给你一个初步感知。还有一个容易被忽略的点算力需求是动态的。一段路面平整的公路和一段颠簸土路上的视觉算法复杂度完全不同白天和夜晚、晴天和雨天的感知负载也不一样。做硬件选型的时候不能只按“平均负载”来评估必须按峰值负载加安全余量来约束。我通常建议按预估峰值算力的1.3到1.5倍去选芯片。2. 车载/机载场景对算力芯片的特殊约束2.1 功耗墙、散热墙和空间墙车载和机载平台的物理约束是选型时绕不开的三堵墙功耗墙、散热墙、空间墙。功耗墙比较好理解电源系统的设计容量是有限的。一辆电动车的低压供电系统大约是12V或48V架构能给智能驾驶域控制器分配的总功率通常是几百瓦但你不能全给算力芯片其他传感器、执行器、屏幕都要用电。无人机就更严苛电池放电能力直接决定了能带动多大负载的芯片。散热墙和功耗墙是两位一体的。你可能选了一个算力够高、功耗也能接受的芯片但它在长时间满载运行时会迅速升温一旦触发降频保护实际可用算力会断崖式下降。车载场景尤其要注意高温环境夏天的车内温度可能达到70度以上如果散热设计不到位芯片很容易就热降频了。比较好的做法是在选型报告中专门加一个“持续满载温升测试”项用红外热像仪记录芯片表面温度和机构内空气温度变化。空间墙相对隐蔽但也很致命。嵌入式设备的主板面积是寸土寸金的芯片本体尺寸、外围电路复杂度、所需散热器件的大小都会影响整机结构设计。有些芯片标称性能很好但它需要外挂多颗DDR、需要PCIe switch、需要大面积铜片散热算下来占用的空间和重量远超预期。2.2 端侧部署和云侧部署怎么选过去很多团队的做法是设备端只负责采集数据通过网络上传到云端由云端大模型做推理再把结果返回。这种方案的优点是算法迭代灵活但对车载和机载场景来说网络延迟和通信可靠性是两个致命问题。我在一次路测中就遇到过这样的情况车辆经过地下隧道时网络信号全断云侧推理完全瘫痪视觉算法瞬间失效。那一刻就能明白为什么具身智能场景必须强调端侧算力。端侧部署的核心优势就是确定性——无论网络条件如何推理延迟和决策输出都是可控的。但这不意味着云侧就没用了。我的实践经验是在端侧和云侧之间做合理的任务切分。实时性要求高、数据敏感度高的任务放在端侧比如障碍物识别、碰撞规避、机械臂的实时控制而全局规划、语义理解、场景重构这类对延迟要求不那么敏感的任务可以放到云端做端侧保留结果缓存。这种分层架构既控制了功耗又保证了系统的鲁棒性。2.3 算力需求评估的基本方法聊到算力评估很多人第一反应是直接比较芯片的TOPS但更科学的做法是从具体任务反推。我这里分享一个自己在项目里总结的四步法履新项目基本上都能套用。第一步列出所有需要跑在端侧的任务清单包括感知类、决策类、控制类并估计每个任务在目标帧率下的计算强度。第二步为每个任务选择代表性的神经网络模型或算法原型比如目标检测用YOLO系列、分割用DeepLab系列然后在开发板上做一次benchmark拿到单次推理的实际耗时和内存占用。第三步把所有任务叠加起来考虑并发执行的时候存在的资源竞争得出总需求。第四步乘上安全系数。这里面有一个容易犯的错误很多人只统计了AI算力却忘了CPU、GPU、NPU、ISP、编解码单元等不同计算单元之间的负载均衡。比如你选了一个NPU很强的芯片但CPU较弱结果图像采集、预处理、调度逻辑全都堆在CPU上CPU满载而NPU闲置整体帧率还是上不去。所以算力评估一定要看整机系统的算力而不是单看某一个单元的峰值。3. 主流端侧算力芯片方案实测对比3.1 当前值得关注的主流方案目前市面上能用于车载/机载端侧AI的算力芯片大致可以分成三个梯队。第一梯队是高性能自动驾驶芯片典型代表包括英伟达的Orin/Thor系列地平线的征程系列以及Mobileye的EyeQ系列。这类芯片的算力范围通常在100 TOPS到1000 TOPS以上定位就是高阶智能驾驶和具身智能的主控平台。Orin的好处是CUDA生态成熟模型迁移成本低几乎任何PyTorch模型都能跑坏处是功耗相对偏高不是所有项目都能接受。第二梯队是面向摄像头、无人机、机器人等设备的边缘AI芯片典型代表包括英伟达的Jetson系列、瑞萨的RZ/V系列、恩智浦的i.MX 8M Plus、全志、瑞芯微等。这类芯片的算力范围从几TOPS到几十TOPS功耗控制做得较好适合轻量级视觉任务或者作为主控之外的协处理器使用。第三梯队是AI加速卡或者模块化产品比如一些基于FPGA或ASIC的方案它们的灵活性和定制化程度很高但开发难度也大。对于大多数中小团队来说我建议优先考虑第一梯队和第二梯队中生态成熟度高的产品先把项目跑通再考虑定制化优化。3.2 实测方法不只看跑分要看真实负载选型阶段做芯片实测我的建议是要有一套标准化的测试流程不然不同芯片之间的数据没法横向对比。首先统一测试模型集。不能A芯片用YOLOv5s测试B芯片用YOLOv8m测试那比出来的数据没有任何参考价值。建议准备三个维度的测试模型轻量级参数量5M以下、中量级参数量20M-50M、重量级参数量100M以上分别覆盖低、中、高负载场景。其次统一输入数据。最好用一段真实场景的录屏视频或者传感器数据包而不是随便几张测试图片。真实数据的时空分布更贴近实际场景测出来的性能更有说服力。第三统一精度设置。在同等精度INT8或FP16下测试避免有的芯片用INT8跑出高分但实际应用时需要FP16保精度导致性能大打折扣。第四记录完整指标。至少要记录四组数据峰值算力、持续算力、端到端推理延迟、功耗曲线。尤其是功耗曲线能直接反映芯片在长时间运行中的稳定性。3.3 算力、token、API到底是不是一回事这两年聊端侧AI常常会蹦出“token”“API”这些词很多人把它们和算力混在一起闹出不少误会。其实这三者是完全不同层面的概念。算力是硬件能力通俗说就是芯片每秒钟能完成多少次运算。Token是模型处理文本时的最小语义单元一个汉字在中文大模型里通常算1到2个token。API是软件接口是你调用模型服务的方式。打个比方算力相当于汽车的发动机功率token相当于油耗API相当于驾驶舱里的方向盘和仪表盘。发动机功率大油耗可能高但你通过方向盘API怎么开直接决定了实际体验。在端侧AI硬件选型时如果你打算部署大语言模型或者多模态大模型需要特别关注两个指标一是模型参数量与内存容量的匹配关系二是每秒能处理的token数也就是推理吞吐量。同样是100 TOPS的芯片由于内存带宽和架构差异跑同一个大模型的token/s可能差出一倍以上。所以在大模型部署场景下我会更关注“能跑多快”而不是“标称多大”。4. 实测流程与工具链实操4.1 搭建一套可复用的端侧算力测试环境关于实测环境我最常用的方案是一块待测开发板、一个可控温的测试间或恒温箱、一台用于远程监控的PC、一套功率采集装置。别小看这个组合它能帮你把硬件底细摸得一清二楚。第一步固定环境温度。不同温度下芯片性能差异非常大不要在空调房的桌上测完一个又到户外暴晒的车里测另一个没有可比性。我一般建议统一在25度室温下实验条件允许的话再做一组65度高温对照实验。第二步搭建远程监控通道。在开发板上装好SSH服务和监控脚本采样CPU/GPU/NPU占用率、内存占用、芯片温度、整板功耗定时写入日志。这样测试期间你不需要频繁插拔显示器数据也更客观。第三步准备标准化的压测脚本。脚本要覆盖纯AI负载、AI加传感器IO负载、AI加通信负载三种模式分别模拟不同运行场景。纯AI负载测的是芯片本身的能力上限加IO负载才更接近真实业务。4.2 用实际模型跑一遍完整流程下面我用一个具体例子说明整个流程怎么走。假设我们要评估一块芯片能不能在无人机上跑目标检测加语义分割两个模型目标帧率是30 FPS。先把模型分别转换为端侧推理框架支持的格式例如ONNX转TensorRT或者ONNX转RKNN。转换过程中会遇到算子不支持的问题这就要看工具链的完备程度了。转换完成后使用真实的航拍视频作为输入分别记录模型单独跑的帧率和叠加运行的帧率。单独跑目标检测时某个芯片可能能达到40 FPS单独跑分割可能只有25 FPS但如果要两个模型叠加并行实际能跑到的可能只有18 FPS。这就是因为NPU资源、内存带宽、CPU调度的竞争在叠加时暴露出来单模型benchmark根本看不出来。我手上有一组实测数据可以作为案例某款标称100 TOPS的芯片单独跑YOLOv8s INT8时帧率能做到35 FPS功耗稳定在18W左右但叠加上语义分割模型之后帧率掉到20 FPS整板功耗升到25W芯片温度在15分钟内爬升到83度开始出现降频迹象。另一款标称80 TOPS的芯片单模型帧率是32 FPS叠加后帧率反而能保持在26 FPS温度曲线也更平稳。这个案例很能说明问题纸面算力不等于有效算力工具链优化和散热设计有时候比堆TOPS更关键。4.3 算力服务器和集群管理的基本命令如果你的项目规模稍大单块开发板不够用需要管理多台算力服务器或者算力集群那还得掌握一些基本的运维命令。这里分享几个我最常用的操作。NVIDIA系列设备最常用的是nvidia-smi可以实时查看GPU型号、显存占用、利用率、温度、功耗。配合watch -n 1 nvidia-smi可以每秒刷新一次观察负载变化。再高级一点可以用nvidia-smi dmon进入动态监控模式查看更细粒度的性能指标。如果是多台服务器统一管理建议直接用容器化方案。给每台机器装好Docker和NVIDIA Container Toolkit之后用docker ps和docker stats来查看各容器的运行状态和资源占用。如果需要跨多台机器联合管理Kubernetes加上NVIDIA Device Plugin是主流方案部署之后可以用kubectl get nodes、kubectl top nodes来统一查看各节点的算力资源和调度情况。在写这套环境的初始化脚本时有一个经验很重要把驱动版本、CUDA版本、容器运行时版本、框架版本全部记录下来形成一个版本清单。多台机器的环境如果不一致排查问题时会非常痛苦。我有一次在新机器上复现项目折腾了整整两天才发现是CUDA小版本不一致导致的算子编译失败。5. 常见问题与排查技巧实录5.1 高频问题速查表这里整理了一份我这两年做端侧AI项目遇到的高频问题列表你可以直接收藏当作checklist用。问题现象可能原因排查方法标称算力很高但实际帧率低内存带宽瓶颈或工具链优化不足跑内存带宽benchmark对比同芯片官方示例模型的帧率测试时正常实际工作时频繁卡顿散热不足触发降频或电源供电不足监控芯片温度和输入电压检查散热器和电源适配器模型转换时报算子不支持目标框架算子库覆盖不全更换模型变体或用通用算子替换不支持的层多模型叠加后帧率急剧下降NPU资源竞争CPU调度瓶颈分时复用方案或为不同模型分配专属计算核心长时间运行后精度漂移模型量化校准数据不足增加校准集数据量或改用混合精度方案设备重启后性能表现不一致固件或驱动版本回退固定版本号统一升级策略5.2 实测中最容易踩的几个坑除了表格里的高频问题还有几个坑是我反复踩过、花钱买到教训的单独拿出来展开说。第一个坑是只测峰值算力不测持续算力。芯片刚开机或者刚上电的时候温度低能跑出的性能会虚高。真正考验能力的场景是连续运行一小时之后芯片能不能保持住性能。我现在做选型测试都会强制跑一小时以上的长稳测试只把长稳测试通过的产品纳为候选。第二个坑是忽视数据带宽和接口带宽。芯片算力再高如果输入数据接口带宽受限比如只有千兆网口或者USB 2.0接口那高分辨率视频流在入口处就已经堵住了。有一个项目里我们测试了一块算力很强的板子但相机接入用的是USB 2.0实际能跑到1080P 15帧就已经满负载了算力再高也没用。第三个坑是忽视工具链的专业服务。开源社区的帮助文档和官方技术支持的质量在选型时也应该纳入评估。有些芯片虽然参数很好但遇到问题连个问的地方都找不到官方社区响应一周才回复那开发节奏就被完全拖垮了。5.3 标准与文档的参考价值最近行业内流传的《人形机器人与具身智能标准体系(2026版)》这类文档很多人问有没有必要去读。我的态度很明确标准文档不是拿来背的而是拿来对齐沟通语言的。当你的团队需要和供应链、客户、合作伙伴沟通接口规范和数据格式时标准能避免很多互相听不懂的情况。标准文档里通常包含硬件接口规范、软件架构建议、性能测试方法、安全要求等几个部分。其中跟算力选型相关性最高的可能是性能测试方法和指标定义的部分。它往往定义了在什么条件下测算力、在什么精度下算TOPS、如何对比不同方案的性能。这些定义看似基础但如果你没有按照统一口径去测数据后面跟别人比参数的时候就会陷入鸡同鸭讲的局面。我个人建议在选型文档的附录里加一个“测试条件说明”章节把自己的测试环境、精度设置、输入数据来源、温度控制方法都写清楚。这样将来不管是谁拿到这份选型报告都能知道你的数据是在什么条件下得到的避免数据被误用。6. 关于未来扩展的一些想法最后从个人经验角度聊几句这个方向还可以怎么往下走。我自己的体会是硬件选型只是端侧AI项目的第一步但却是最不能走偏的一步。芯片选错了后面软件优化做得再漂亮天花板也是固定的。反过来芯片选对了开发效率和系统性能上限都能得到保障。我现在每做一个新项目都会在正式开发之前预留至少两周的硬件评估时间专门用来跑实测数据这个时间投入非常值得。另外具身智能这个方向还在快速演进新的芯片方案和算法结构层出不穷。去年还觉得很宽裕的算力今年可能就不够用了。所以选型的时候除了满足当前需求也要考虑后续迭代的扩展性。同一款板卡平台上有没有更高算力的升级型号内存能不能扩展接口有没有预留这些都是影响项目生命周期的重要问题。还有一个值得尝试的思路是异构计算。不要把所有的负担都压在唯一芯片上可以用CPU加NPU加MCU的组合把实时控制碎片任务和高算力负载做切割。这样既能保证关键控制的实时性又能让大模型任务有一个集中的算力池整体效果往往比单一大算力芯片更好。踩过这么多坑之后我的经验是不要迷信任何一个单一指标也不要轻信任何一张宣传页让数据和实测说话才是端侧AI选型最靠谱的方法论。