前阵子我们团队做一台室外无人巡检车的感知系统升级把模型从yolov5切成了带注意力机制的检测头精度上去了结果在Jetson Orin Nano上跑起来帧率直接掉到不到预期的一半。我第一反应是“芯片算力不够”于是想换更大算力的平台但换来换去发现问题根本不在TOPS这个数字上。那段时间我把车载和机载场景下能拿到的端侧AI硬件基本都过了一遍也踩了不少坑。这篇东西就是把这些实测结果和选型教训整理出来给后面做具身智能、机器人、无人机或者车载感知的朋友一个参照。先说清楚这篇指南的适用范围面向具身智能人形机器人、机械臂、无人车、无人机里需要在设备端完成推理或局部训练的场景讨论的是“算力芯片硬件平台”这个层面不讨论云端训练集群。适合正在做算法移植、硬件选型或者方案评审的工程师也适合刚入行、想搞懂算力参数真实含义的算法同学。1. 先认清一个残酷事实标称算力和“能用的算力”不是一回事1.1 从一次车载项目“爆显存”说起我们的巡检车一开始用的是Jetson Orin NX 16GB版本官方标称算力100 TOPS。当时觉得跑一个几十M的检测模型绰绰有余结果实际部署时发现模型转换到TensorRT之后显存占用比PyTorch训练时还夸张。排查了一圈不是模型写崩了而是框架默认给整张输入图分配了连续内存加上多路缩放、归一化、NMS后处理都要吃内存带宽最终16GB LPDDR5的带宽被吃掉了接近70%。这时你算力再高数据搬不进去、算不完帧率照样上不去。这个经历引出一个核心概念端侧算力是一个系统指标不是芯片单独决定的。TOPS只是算力部件在一个理想条件下的峰值真正决定性能的是“数据能不能及时喂到计算单元里以及算完之后能不能及时挪出去”。1.2 TOPS到底是什么单位、测量条件与“纸面算力”TOPS是Tera Operations Per Second的缩写也就是每秒万亿次操作。很多硬件厂商宣传的TOPS其实是在INT8精度下、以特定稀疏度条件测出来的峰值。这里有几个猫腻要注意精度不同算力差异巨大同一块芯片FP32算力通常只有INT8算力的1/8到1/16FP16介于两者之间。有些厂商喜欢标FP16算力有些标INT8算力对比时必须先换算成同一精度。NVIDIA官方经常标“稀疏”算力比如Orin的275 TOPS是包含2:4结构化稀疏的实际非稀疏场景要打折。是否包含DLA/NPUJetson Orin系列里有GPU和DLADeep Learning Accelerator两块计算单元。官方算力是两者叠加。如果你的模型不能有效切分到DLA上跑那实际可用算力只有GPU部分。理论峰值与实际吞吐峰值算力是计算单元满负荷、数据永远不等的理想值。实测中受限于内存带宽、算子调度、功耗墙普通模型能跑到标称值的30%-50%已经算优秀。我习惯做一个简单换算如果项目里主要跑INT8模型那么“实际可用算力 ≈ 标称TOPS × 0.35”。这个系数是我在多个平台上测出来比较保守的估计值。当然如果你用的是厂商深度定制的模型动物园配套模型利用率会高一些可能到0.5甚至0.6。1.3 算力利用率实际工程中常见的“打折因素”除了精度换算还有一堆因素让实际算力打折内存带宽是头号瓶颈。AI推理的本质是反复读取权重和中间特征图。以Jetson Orin NX为例LPDDR5理论带宽大约102.4GB/s但一个4K分辨率的输入RGB三通道一次就要约25MB。如果做视频流30帧每秒就是750MB/s光输入搬运就占了接近1%带宽。看起来不多但模型中间特征图的读写往往是输入的几十倍。大量小算子的调度开销。检测模型里常见concat、split、reshape、sigmoid这些小算子在GPU上没法完全利用张量核心而CPU调度又要耗时。很多模型转换后性能差就是这一类“碎片算子”太多。功耗墙与温降。车载/机载环境里芯片通常被限制在较低功耗档位。Jetson模块有10W、15W、25W等模式功耗和算力不是线性关系有时候从15W调到25W频率提升很有限但发热量明显上涨最终触发降频。提示选型时别只看官方标称TOPS一定要找厂商要“实测功耗范围内的持续推理性能”并问清楚测试模型、输入分辨率、精度和运行时长。2. 具身智能部署环境的“物理课”功耗、散热、尺寸与供电2.1 车载/机载电源系统的预算分配具身智能设备和桌面端开发板最大的区别是供电。桌面开发板插着电源适配器怎么折腾都行。但车载和机载设备整机电源预算非常紧张。以我们做过的无人机载具为例一架小型多旋翼无人机整机功耗大约200-500W其中动力电机占了大头留给计算平台的可能只有10-30W。你不可能在上面挂一块Orin AGX满载功耗15-60W更不可能上RTX 4090。即便像一些大型无人车号称能带100W算力平台实际还要给激光雷达、工业相机、4G/5G模块、工控外设供电真正给到AI计算模块的余量往往比想象中小得多。所以选型第一步先算功耗预算。我给你一个比较实用的表格参考设备类型整机电源预算留给AI计算模块的典型功耗可考虑的算力范围INT8小型无人机4-7kg200-500W10-25W10-40 TOPS中大型无人机15kg500-1500W25-50W30-100 TOPS室内服务机器人100-300W15-30W20-50 TOPS室外无人车/巡检车500-2000W40-100W50-250 TOPS人形机器人原型500-2000W30-80W50-200 TOPS这个表格不是精确值但可以帮你在项目早期就框定可选的芯片范围。比如你发现AI模块只能给15W那就不太适合选Jetson Orin NX 16GB的标准模式虽然它的典型功耗在10-25W之间可调但实际跑满性能需要更高功耗而应该认真考虑配AI加速棒的方案或者挑一颗能用足这15W的芯片。2.2 散热设计的三个层次被动、风冷、液冷功耗问题必然伴随散热问题。这里必须提醒一句很多开发者在桌面阶段用得很好一到装车装机载就频繁死机、掉帧核心原因就是散热设计没跟上。我按实际工程经验把散热方案分成三个层次被动散热铝挤散热片外壳导热适用于15W以下功耗的模块比如Jetson Nano、Orin Nano低功耗模式、瑞芯微RK3588这类。关键是外壳要能形成完整导热通路我见过不少项目用3D打印外壳把模块包得严严实实没有留散热开孔结果芯片温度直接飙到85℃以上。被动散热不是“不散热”而是让热量通过外壳和自然对流散出去因此外壳表面要尽量裸露在空气流通区域。主动风冷小型轴流风扇/涡轮风扇15-40W功耗的设备比较适合。Jetson Orin NX在25W模式下用一个6020尺寸的涡轮风扇基本能压住。风冷最需要注意的是进风口位置和滤尘设计车载场景在户外跑一个月灰尘能把散热鳍片堵死至少得设计可拆卸清洗的防尘网。液冷/半导体制冷40W以上功耗或者机载密封舱这种没有空气对流的环境就得考虑液冷板或主动制冷。液冷在车上问题不大但在无人机上重量和可靠性都是麻烦事。我见过一些项目用相变材料导热管把热量导到机身金属骨架效果也不错不过设计周期比较长。2.3 车规级与工业级为什么芯片选型不能只看性能还有一个很多人忽略的点芯片的“等级”。消费级/商业级0℃到70℃的工作温度范围适合开发原型和实验室环境。消费级SDK和开发资料最丰富。工业级通常-40℃到85℃需要经过更多筛选。NVIDIA Jetson模块在规格书里的工作温度范围因型号而异但实际在宽温下运行时性能会明显受到功耗墙限制。车规级除温度范围外还要求满足AEC-Q100可靠性认证、ISO 26262功能安全标准等。真正的车规SoC比如地平线征程系列、黑芝麻华山系列、Mobileye EyeQ系列在量产车上用的就是这类。这些芯片往往要额外运行Safety OS、做双核锁步、加安全岛实际应用算力会比宣传值再打折扣。注意车规级不是“比工业级更强”而是“失效模式可控、可预期”。如果你的产品要做车规认证从一开始就不该选消费级芯片设计进去后面换芯片的成本远超你的想象结构开模、线束、电源、散热全部重来。3. 主流端侧算力芯片的平台实测对比3.1 NVIDIA Jetson家族Orin NX、Orin Nano的实测数据我围绕Jetson Orin家族记录了一份实测数据虽然是2023年之后的平台但至今依然是端侧AI部署的主流选项。测试条件统一为ResNet50INT8TensorRT输入分辨率224×224batch1连续运行30分钟后的稳定帧率。平台官方算力INT8稀疏实测稳定帧率FPS功耗平均备注Jetson Orin Nano 8GB40 TOPS420 FPS7-10W性能/功耗比不错但内存带宽只有68GB/sJetson Orin NX 16GB100 TOPS830 FPS15-25W性价比高推荐主流项目使用Jetson Orin AGX 64GB275 TOPS1500 FPS30-60W性能强但功耗和体积不适合小型机器注意ResNet50属于“很规矩”的CNNDLA能跑一部分算子所以效率相对高。如果是transformer结构比如ViT或者带注意力模块的检测头帧率可能会下降30%-50%。原因是ViT里面的softmax、layer norm这类算子对DLA不友好只能跑在GPU上GPU的INT8吞吐比DLA低不少而且还要频繁等待数据同步。还有一点值得说Jetson平台的杀手锏是生态成熟。TensorRT、DeepStream、Isaac ROS这些工具链都有网上案例丰富算法团队上手成本低。缺点是NVIDIA的模块价格不透明渠道波动大而且“官方一直有传闻要出新平台”导致很多项目在量产前会犹豫要不要赌下一代。3.2 车载场景下的地平线征程与黑芝麻智能平台在车载前装市场地平线征程系列和黑芝麻智能的华山系列是不能不聊的存在。跟Jetson不同它们的优势是车规级、功能安全、以及国内供应链的支撑。地平线征程5官方算力大概在128 TOPSINT8在某种程度上有对标Orin的意思。实测感受是征程系列的BPUBrain Processing Unit对CNN类模型优化得不错经典检测模型效率高但算子兼容性不如NVIDIA那么“通吃”。比如一些自研的Transformer模块可能就需要联系厂商工具链团队专门适配。如果你团队算法比较喜欢刷结构新颖的模型前期就要做好“模型算子适配”的心理准备。黑芝麻智能的华山A1000算力大约在58 TOPS附近更加偏L2级别的辅助驾驶。实测中端到端延迟做得比较低因为它是车规芯片Sensor、Soc、MCU的链路设计是绕开USB转接的数据通路更短。但同样工具链成熟度比NVIDIA要弱一些社区资料和现成demo少。开发初期如果遇到算子不支持可能只能自己写自定义算子或者改模型结构。总结车载SoC的平台特点我建议用一个简单的判断标准如果项目是快速原型验证选Jetson如果项目直接瞄准车规量产选征程或黑芝麻这类原生车规平台。千万不要先拿Jetson开发完原型再指望“花两周”移植到车规芯片上实际上工具链差异大算子适配工作往往要一两个月并且需要厂商深度配合。3.3 机载场景下的算力“斤斤计较”无人机和机载设备的算力选择比车载更苛刻因为重量就是一切。Jetson Orin NX模块加载板大约100g对于小型无人机而言这个重量已经不能忽视了。我看过一些小型无人机项目的做法优先选择算力需求低但功耗小的方案瑞芯微RK35888K编解码加6 TOPS左右NPU算力整板功耗10-15W重量能做到几十克。适合跑一些轻量检测、图像分类、光流辅助导航这样的任务。RK3588的NPU虽然是“三核”设计但工具链统一用RKNN兼容性还不错很多AIoT方案都有参考设计。全志、晶晨的低功耗方案算力只有2-5 TOPS主要适合跑极轻量的模型。它们的好处是功耗低到3-5W一颗电池就能扛很久。Jetson Orin Nano如果算法复杂度上来了比如要跑视觉惯性里程计VIO障碍物检测路径规划Orin Nano还是比RK3588更容易兜底。缺点是需要额外散热和载板设计整体重量会往上走。机载场景还有一个“隐藏功耗”传感器本身。相机的ISP、激光雷达的转镜电机、数据记录仪的SSD写入全都要耗电。我在一个项目里测过光一个工业相机加自动对焦镜头就要3-4W一块10W的算力板被周边设施挤兑到只有6W可用。所以做机载选型一定要算“计算链路总功耗”不能只算SoC本身。4. 选型前必须做的一道数学题从模型需求倒推算力规格4.1 给模型算一笔“算力账单”很多工程师选芯片的习惯是先看参数表然后拍脑袋决定。我的建议是先把你的模型家族列一个表算出需要多少乘累加运算MACs和内存访问量再倒推算力需求。拿一个简单的检测模型举例模型YOLOv8s输入640×640参数量约11MFLOPs约28.4 GFLOPsFP32。但实际INT8推理时的操作数跟GFLOPs有差异我们先按GFLOPs估算。1 TOPS 每秒1万亿次操作换算成FLOPs时要注意1次MAC操作等于2 FLOPs。所以YOLOv8s单帧需要28.4GFLOPs浮点算力需求约等于28.4×256.8 GMACs但做INT8推理就是56.8G次整数操作。如果你希望端侧运行在20FPS那么算力需求 56.8G × 20 1136 GOPS ≈ 1.14 TOPS。这么看好像一块RK35886 TOPS都绰绰有余但这是理论下限实际工程要算上算力利用率、IO开销、多进程并发通常要乘上5-10倍的系数才会稳。“算力账单”公式我简化成推荐算力TOPS, INT8≈ 单帧所需运算量GMACs × 目标帧率FPS × 冗余系数5~10 ÷ 1000冗余系数为什么这么高因为端侧设备不只是跑模型推理还要跑图像采集/缩放、传感器融合、决策控制、系统任务调度。这些任务在CPU上运行可能会抢占内存带宽而模型推理时如果同时跑多个实例比如多个相机输入算力需求也成倍叠加。我见过太多项目把算力卡得刚刚好结果一加日志、小模型、GUI进程就频繁超时。4.2 延迟预算与链路余量车载/机载系统往往对端到端延迟有硬性要求。比如自动紧急刹车要求感知到执行在100-200ms内完成无人机避障系统通常要求感知到输出控制在50ms以内。这时候你需要拆解延迟链路相机采集 曝光15-30msISP处理去马赛克、自动曝光校正5-10ms图像缩放/归一化1-3msAI推理10-50ms随算力和模型变化后处理NMS等2-5ms控制输出传输1-5ms如果目标端到端延迟是100ms那AI推理顶多占50-60ms。用这个反推算力需求比单纯用帧率算更靠谱。帧率是平均概念延迟是尾延迟概念。很多端侧设备平均帧率看着还行但某几帧因为降频、垃圾回收、调度抖动导致延迟飙升这在滤波平滑的场景影响不大但在闭环控制系统里是致命的。4.3 一张自制的选型对照表在做完模型需求拆解后我习惯把候选平台放一张表里对比字段包括算力INT8、内存带宽、内存容量、功耗档位、重量、载板难度、工具链成熟度、典型单价、供货风险。这里以我能拿到的一些公开信息和实测经验列一个2025年前后相对常见的组合平台INT8算力内存带宽功耗重量参考工具链适用场景Joby/国产低功耗SoC瑞芯微RK35886 TOPSNPU约51.2GB/s10-15W50g-80gRKNN小型无人机、轻量检测Jetson Orin Nano 8GB40 TOPS稀疏68GB/s7-15W模块约100gTensorRT样机验证、轻量感知Jetson Orin NX 16GB100 TOPS稀疏102.4GB/s15-25W约120gTensorRT多路相机、复杂感知Jetson Orin AGX 64GB275 TOPS稀疏204.8GB/s30-60W约300gTensorRT大型无人车、室外机器人地平线征程5128 TOPSINT8定制车规内存方案约30W板级设计地平线工具链车规量产、L2智驾黑芝麻华山A100058 TOPS车规DRAM约15-20W板级设计黑芝麻工具链车规量产、行车/泊车注意上面数据来自迭代中的测试环境同一平台不同载板、不同散热条件、不同模型架构下的数据都会有差异。选型对照表只是帮你框定范围真正决策必须靠“在自己目标场景里跑一遍”。5. 实测中的避坑记录五条最典型的翻车现场5.1 坑一DLA与GPU混用后帧率反而下降Jetson Orin的DLA是个好东西专门加速卷积层。但你要小心“看起来能加速”的模型不一定真的能加速。我们测试过一个双目深度估计模型前半部分比较适合DLA后半部分是自注意力模块。为了用上DLA我们把模型强行切分一部分跑DLA、一部分跑GPU。结果数据在DLA和GPU之间来回搬运加上两个引擎需要同步整体延迟反而比全部跑GPU多了20%。根因DLA和GPU是异步引擎中间层输出的同步点如果太多调度开销会吃掉加速收益。我的经验法则是一旦一个模型里某个网络层只有不到10%的参数占比就不要为它单独切分到DLA宁可用GPU一次跑完。如果模型本身超过50%的层能被DLA承担并且中间层同步点不超过3个DLA才能体现优势。5.2 坑二总线带宽被图像输入吃光有个车载项目接了6路1080p摄像头每路30fps。你以为把数据直接交给AI芯片就行实际上图像采集要走MIPI/CSI接口进入内存后预处理模块缩放、格式转换还要读写一遍。6路1080p30的原始数据大约是每帧12MB×6×30 2.16GB/s的内存流量。对于内存带宽100GB/s的芯片来说表面只占2%但你还有大量高清缩略图、ROI裁剪、算法可视化窗口全部加起来带宽占用率达到30%-40%。影响推理模块效率没变但端到端吞吐下降偶尔出现“卡顿式”掉帧。解决办法是采集后尽快在ISP阶段把不需要的信息裁掉不用的高分辨率预览窗口不要随便开图像格式尽量走NV12这种视频压缩率高的格式而不要全部转成RGB。5.3 坑三官方功耗模式导致性能漂移Jetson平台可以在10W、15W、25W等模式间切换但不同模式的GPU频率不是线性变化的。有一次我们在25W模式下调好的性能装进电池供电的机器里系统自动切到15W模式帧率直接掉了一半而且没有任何报错日志看起来像极了“算法变慢”的假象。排查方法跑性能测试时用tegrastats记录GPU/CPU频率和温度确认稳定运行时的频率是否符合预期。同时设置好nvpmodel和jetson_clocks确保在多配置环境下性能可预期。量产设备还要考虑电源电压波动、电池电量不足时系统会不会自动降频如果没有锁频性能波动是必然的。5.4 坑四版本不匹配的TensorRTTensorRT对版本极为敏感。我们有一次因为“顺便”升级了CUDA版本和cuDNN导致已有的TensorRT引擎全部失效重新构建引擎时才发现新版本的算子规则变了模型里一个自定义的RoIAlign算子编译不过去。那次前后折腾了三天最后只能回滚到旧版本镜像。经验务必把你的开发环境固化成容器或SDKManager镜像记录CUDA、cuDNN、TensorRT、PyTorch的版本组合。没有异常原则上绝不升级。如果必须升级先在废弃环境里构建引擎验证所有模型输出与旧版本一致后再切换。另外千万要小心Python多版本环境的虚拟环境隔离很多“莫名其妙的bug”其实是依赖冲突。5.5 坑五机载场景的“算力波动”无人机上用的非工业级SD卡、eMMC存储在剧烈震动和温度变化下会出现瞬时I/O性能波动。当时我们跑模型时发现某个时间点帧率骤降一开始以为是算力问题后来用perf工具排查发现是模型输出需要同步写日志而SD卡瞬时写延迟高达几百毫秒阻塞了推理线程。这类问题在车载环境也有只是没机载那么明显。解决思路日志系统用异步队列不允许直接写在推理主线程里。对存储写入做限流和缓冲丢日志可以丢控制帧不行。机载场景优先选工业级SSD或RAM盘保存关键日志不要依赖普通卡。6. 从实际项目中总结的选型工作流6.1 五步走的选型流程经过这几个项目的实测和踩坑我现在基本会把选型流程固化成五步每一步都有明确的交付物需求拆解列模型家族、输入分辨率、目标帧率/延迟、运行环境温度、供电、尺寸、重量。交付物算法需求清单和算力账单。模型上车从模型动物园里拿一到两个代表性模型在候选平台上实测帧率、显存/内存占用、功耗。这一步主要是“跑分”和目测交付物候选平台初步对比表。真实链路验证把完整的感知/决策链路搭起来包括图像采集、预处理、推理、后处理、可视化。这一步最费时间但能暴露数据搬运、格式转换、多线程调度等瓶颈。交付物端到端延迟和持续稳定性报告。长稳测试在目标工况下连续运行至少48小时记录温度、频率、帧率、功耗曲线确认没有热降频和累计内存泄漏。很多芯片在实验室跑2小时没问题连续运行两天后内存被中间缓存撑爆。量产评估评估工具链成熟度、芯片供货周期、车规认证情况、厂商技术支持响应速度、长期成本。这一步很多人会忽略但它比技术指标更影响项目能否顺利交付。6.2 算力冗余该留多少最后说说算力冗余。这是老生常谈但我想给个比较量化的建议研发原型阶段端侧算力预留30%-50%的余量因为算法还要迭代模型大概率会变大。接近量产阶段算力余量可以缩到20%-30%但冗余的是“性能裕度”不是“显存余量”。显存/内存建议至少留40%的余量。端侧推理框架经常因为内存碎片化导致OOM你明明看着还有空闲内存但就是分配不出一块连续的大buffer。DLA、CPU算子、GPU算子各自会预留内存实际可用量比标称少很多。提示如果项目对成本极度敏感没法放宽算力那就必须在算法侧下手量化、蒸馏、剪枝、结构化剪枝、输出降采样都在这个阶段考虑。不要指望只在芯片侧解决性能问题算法和硬件必须一起调。6.3 最后再分享两个小技巧第一个技巧自建一个“模型-芯片适配实测矩阵”。把常用模型YOLO系列、DETR系列、分割模型、关键点模型、输入尺寸、INT8/FP16精度、目标芯片平台全部做成一套自动化测试脚本每次拿到新硬件就跑一遍。这样选型时不用重新造轮子数据都在手上说服老板或者客户也更容易。第二个技巧做功耗测试时不要只看平均功耗。用高采样率的功率计记录峰值功耗和脉冲。端侧AI推理是典型的“高负载短脉冲”瞬时功耗可能是平均功耗的1.5-2倍。如果你的电源和电池设计只按平均功耗留余量系统一旦进入连续推理电压跌落就会导致复位或降频。我在无人机项目里就遇到过续航看着够、一跑算法就重启的诡异问题。这些坑和数据都不是什么高深理论但端侧AI项目翻车往往就翻在这些细节上。希望这篇实测笔记能帮你少走几步弯路。