端侧 AI 最折磨人的不是模型训练而是把模型塞进一块巴掌大的板子上让它能在车里、机上、机器人里稳定跑起来。我这两年一直在做具身智能相关的车载和机载视觉系统从四轮小车到机械臂、从室内巡检到半户外作业实打实摸过一轮又一轮的算力板子之后最大的感受是搞硬件选型光会看 TOPS 是不够的真正决定项目生死的往往是一堆参数表上看不见的细节。这篇文章不聊高大上的架构设计就讲我在端侧 AI 项目中踩过的坑、测过的数据、以及反复迭代之后整理出的一套算力芯片选型与验证方法。如果你正在为无人车、无人机、机械臂或者任何准移动机器人平台挑选端侧算力硬件这篇文章应该能帮你少走不少弯路。1. 端侧算力选型的第一课先把账算清楚再看芯片1.1 具身智能的负载没有你想的那么单一很多团队选芯片的时候习惯性思维是“先定平台再写代码”这个顺序在端侧项目里是大忌。具身智能和纯云端 AI 项目最大的区别是它往往同时挂着好几类完全不同性质的计算任务。以我做过的一台室内轮式巡检机器人为例这台设备实际跑的东西包括4 路 1080p 摄像头输入其中两路做目标检测一路做 QR 码识别一路做人脸/姿态分析一个轻量级激光雷达点云预处理加 2D SLAM 定位一个 IMU 数据和轮式里程计融合的卡尔曼滤波节点自主导航的路径规划算法包含 A* 全局规划和 DWA 局部规划远程后台的消息推送和视频流上传服务。这个项目没有跑任何大模型看起来“负载很轻”但实际测下来树莓派级别的算力完全撑不住主要卡在四路视频的同时解码和多传感器的并发处理上。所以做选型的第一步不是看芯片参数而是把你项目的负载一项一项列清楚。每一路传感器的分辨率、帧率、编码格式每一个算法的输入输出尺寸、调用频率、延迟预算都要写到一张表里。这张表就是后面所有选型决策的依据。1.2 别被 TOPS 忽悠了稀疏、精度、带宽三个大坑TOPS 可能是端侧芯片宣传里最误导人的数字。厂商标一个 100 TOPS很多非硬件背景的算法工程师就以为这块板子能轻松跑任何模型。但实际用下来真实吞吐量和标称值之间能差出 3 到 5 倍。第一个坑是稀疏和稠密的区别。NVIDIA Orin 系列常说的 275 TOPS实际是 50% 稀疏度下的理论值。如果你的模型是普通卷积没有做结构化剪枝或稀疏化那真实能用的稠密算力大约只有一半也就是 130 多 TOPS。我第一次拿 Jetson AGX Orin 去做推理压力测试时就曾被这个差值惊到以为哪里配置错了反复查了半天才反应过来是稀疏算力的宣传套路。第二个坑是不同精度的算力差异。端侧推理普遍用 INT8因为 INT8 在绝大多数芯片上都能跑满。但如果你有些算子或者数值敏感的算法需要 FP16那么算力可能只剩 INT8 的 1/2 甚至 1/4。更麻烦的是 FP32基本很多端侧芯片都不是为它设计的跑起来性能和能效都很难看。第三个坑是内存带宽。算力是“每分钟能算多少次”带宽是“每秒能把多少数据搬进芯片”。很多端侧板子算力看着不差但内存带宽被卡得很死。比如 Orin Nano 的算力号称 40 TOPS稀疏实际使用中一旦输入分辨率提高、多路视频并发带宽 68GB/s 就成瓶颈了。我在跑 2560×1440 输入的检测模型时Orin Nano 的帧率并没有比 1920×1080 高多少因为数据搬运时间已经占了管线的大头。1.3 端侧 LLM 推理Token 才是最实际的口径最近大家都在讨论端侧跑大模型很多人开口就问“这个芯片能不能跑 7B 模型”。能不能跑是能跑但体验完全不一样。这里真正该关心的指标是 token/s也就是每秒生成多少个 token。同样是 7B 量级量化模型在不同端侧硬件上的生成速度可以从每秒几个 token 到每秒几十个 token差一个数量级都很正常。评估 token 需求其实有个简单的公式可以套如果你的交互场景需要 2 秒内返回一句 30 个字的答复中文粗略按 1.5 个 token 一个字算那你至少需要 30×1.5/2≈22.5 token/s 的生成速度。要是模型还要先处理一大段视觉上下文或者系统提示词prompt 处理阶段也得算进去。所以选型的时候不要只看“能不能跑”要落到具体交互场景里去算 token/s 需求。还有一个经常混在一起的概念是 API、Token 和算力的关系。云端 API 模式下你按 token 付费算力由云端承担端侧部署则是你一次买断硬件之后每次推理不再单独付费但所有算力负担都在本地。这也是为什么“算力、token、API 三者是否相同”会变成热搜问题它们本质上是同一个计算需求的不同交付形态选型时要想清楚你是要走纯端侧、云侧还是端云协同。2. 车载/机载算力芯片横评几代平台的实测体会2.1 Jetson Orin 系列从入门到旗舰的真实表现NVIDIA Jetson 系列在端侧 AI 圈子里基本是事实标准我的大多数项目也都是在这套平台上落地的。这里把 Orin 三个主要型号的实测记录做个整理给大家一个参考。Orin Nano 8GB 是入门首选标称 40 TOPS 稀疏、20 TOPS 稠密但它的 DRAM 带宽只有 68GB/s所以更适合轻负载场景。我用它跑 YOLOv8s 的 INT8 模型640×640 输入大约能到 50~60 FPS单纯看这个数字确实够用。但一旦跑 1080p 四路视频流再加其他传感器节点CPU 会先成为瓶颈整体帧率掉到 20 以下。Orin Nano 的 CPU 是 6 核 Arm频率不算高多传感器并发场景确实有些吃力。还有一点Orin Nano 没有 ECC 内存保护长时间高负载运行偶尔会出现 CUDA 错误这在工业环境里是个隐忧。Orin NX 16GB 是我自己用得最多的型号也是我认为大部分具身智能项目的甜点。标称 100 TOPS 稀疏、50 TOPS 稠密内存带宽 102GB/s配主动散热后能稳定跑 25W~40W 的负载。我在一台室外巡检小车平台上用 Orin NX 同时跑了 4 路 1080p 检测、2D SLAM、局部路径规划和基于 MQTT 的状态上报稳定负载大概在 60% 左右。这个余量对迭代开发来说非常宝贵后面加新功能基本不用换硬件。不过要提醒一句Orin NX 这块板子没有内建视频编码器实时推流或录制视频需要外接编码设备或用 CPU 软编这个不少人都踩过坑。AGX Orin 64GB 属于“一步到位”的选择256GB/s 内存带宽和 64GB 大内存单板就能跑 7B 量化大模型的端侧推理。实测 7B Q4 模型大约在每秒生成 20~30 token/s虽然不算快但对很多具身智能交互场景已经够用。这个板子的代价是功耗和散热。空载待机约 10W 出头满载能拉到 60W 左右。我在一台医疗物流机器人上用了 AGX Orin 工业版为了被动散热的外壳设计头疼了很久最后还是在底部加了导热板和微型风扇才压住温度。2.2 国产平台和车载专用方案不是不能选是得会用地平线征程系列在车载前装市场很有存在感征程 5 的标称算力是 128 TOPS征程 6 系列更高能效比在纸面上甚至优于 Jetson。我实际调试下来的感受是它的工具链在快速进步但离 NVIDIA CUDA 生态的成熟度还有一段距离。如果你的团队都是熟悉 PyTorch 和 TensorRT 的工程师转过去大概率需要一个适应期。常见的问题是部分自定义算子不支持快速部署需要等官方迭代或者自己做算子迁移。量产阶段选它问题不大但研发验证阶段效率确实会受影响。高通 SA8295P 和 Snapdragon Ride 平台在座舱域和智驾域融合的场景里很有优势跑端侧语音助手、人脸识别这些交互类任务很稳。但这个生态更偏向车厂私有化定制第三方开发者能拿到的公开资料相对有限验证周期往往比 Jetson 长不少。如果你的项目不是直接跟车厂绑定初期还是建议先用 Jetson 做验证再考虑迁移到高通平台。瑞芯微 RK3588、全志 T527 这类低功耗低成本平台我见过一些团队拿来做简单的视觉检测或 QR 识别单一负载、低并发的情况下确实够用而且价格优势明显。但到了多传感器融合、实时 SLAM 这个量级它们的内存带宽和软件生态就会拖后腿。我个人的判断标准是如果这个项目的负载和验证阶段可以精简到“单输入、单模型、低帧率”低成本平台的可行性就高只要有并发和实时性要求别在这上面省成本后面省下的钱都会变成人力成本补回去。2.3 消费级、工业级、车规级别在原型阶段犯的错很多团队喜欢在原型阶段直接买消费级开发板但车载/机载环境的特殊约束迟早会让这笔“节约”变成更大的支出。消费级芯片通常只保证 0°C~70°C 的工作温度而工业级要覆盖 -40°C~85°C车规级除了温度还有振动、湿度、EMC、AEC-Q100 认证等一堆要求。我给的建议是分阶段决策研发验证阶段用消费级 Jetson 开发套件便宜、灵活、迭代快到路测/飞行测试阶段换成工业级模组并配合主动散热和减震结构如果项目真的要做量产这时候再切换到车规级方案。关键是一开始就要把整个项目的硬件架构和软件栈确定好确保后续换芯片型号时代码迁移成本可控。这里有个经验算法代码尽量用 ONNX Runtime 或 TensorRT 之类的中间层接口而不是直接写 CUDA 自定义核函数这样未来换平台时能省下大量移植时间。3. 实测流程从纸面参数到实机对比3.1 先搭一个最小负载原型别一上来就上完整项目纸面参数再好看不如实际跑一轮。我的习惯是拿到一块新板子后先搭一个最小的可运行负载原型而不是直接把完整系统搬上去。这个原型包括三部分一张固定的测试图片或视频流、一个经典的检测模型比如 YOLOv8s、一个循环记录帧率和功耗的脚本。跑 4 个小时看板子的温度曲线和帧率曲线是否稳定有没有周期性掉帧或降频。这个阶段最重要的是把“能不能跑”和“能稳定跑多久”分开看。有些板子刚上电时表现很好跑 20 分钟后温度上来就开始降频帧率可能直接掉 40%。如果连最小的负载都扛不住长时间运行那基本可以排除这块板子了不用浪费后面的时间。反过来如果最小负载稳定再逐步加上摄像头、SLAM、路径规划等模块每加一个模块跑 1 到 2 小时观察系统的变化。这样做可以减少变量出了问题也能准确定位到某个模块在某个环节导致的资源冲突。3.2 基准测试统一模型、统一数据、统一记录做横向对比的时候必须保证所有板子跑的是完全相同的模型、相同的数据和相同的记录方式。我自己常用的测试矩阵包含四项YOLOv8s 目标检测从 PyTorch 导出 ONNX再转成各平台的推理引擎、1080p 视频流的端到端延迟包括解码、预处理、推理、后处理、编码整个管线、同一份 7B 量化模型的 token/s 测试、以及同一份 SLAM 序列数据集的里程计耗时。在记录工具上我一般用 nvidia-smi 或者板子自带的电源管理接口去采样功耗用红外测温枪记录外壳温度再用一个日志脚本把所有数据按时间戳汇总成 CSV。这里有一个重要细节功耗测试要在整机状态下测也就是包括摄像头、WiFi 模块、串口设备等所有外设都接上因为外设的功耗在整机功耗里占比不小。另外测 LLM 推理的时候记得区分 prompt 处理阶段和 token 生成阶段这两个阶段在大部分端侧平台上差异很大有些硬件处理长 prompt 特别慢但生成 token 倒还凑合这个特性会直接影响交互体验。3.3 老化与可靠性测试实验室跑不通的都是隐患移动机器人平台和实验室桌面的最大区别是持续运行时间和物理环境。我在正式部署前都会做一轮至少 72 小时的老化测试模式大概是12 小时高负载推理、12 小时循环启停每分钟重启一次、48 小时不同负载交替切换。每 6 小时记录一次温度、功耗和错误日志最后汇总成一份可靠性报告。这轮测试往往会暴露出一些很实的问题。比如某次测试中我发现一块 Orin NX 在连续运行 30 多个小时后系统的 USB 3.0 接口开始随机丢设备重启后恢复但过几小时又复现。排查了很久才发现是电源波纹问题车上用的 DC-DC 电源在高负载时电压纹波偏大影响了 USB 供电稳定性。这个在实验室里根本测不出来因为桌面电源比较干净。类似的坑还有车载环境下点火瞬间的电压跌落导致板子重启、电机运转时产生的电磁干扰导致摄像头信号闪断。这些东西实验室很难完全模拟所以要尽可能早做整机级别的可靠性摸底而不是等到现场联调才暴露。4. 功耗、散热与连接稳定性项目翻车的重灾区4.1 标称功耗和实际功耗之间差着一个电源设计端侧开发板的标称功耗大多是“芯片本体功耗”而实际部署在移动平台上时你要考虑的是整机功耗。我第一次给一台机器人小车配电源时按照 Orin NX 标称的 25W 去算电池容量结果装上之后发现整机在满负载时轻轻松松超出 40W多出来的功耗主要是四路 USB 摄像头、4G 模块、WiFi 模块和外围传感器。不到半小时电池就见底了后来重新设计电源和电池容量才勉强满足作业时长要求。这里想提醒大家供电不仅仅是“容量够不够”的问题还有瞬时峰值和电压纹波。车载/机载环境下电机启动、转向等瞬间会产生很大的电流波动如果电源转换器没有足够的裕量和滤波能力板子很容易出现异常重启或者随机死机。我给移动平台的电源设计要求是转换器峰值功率至少是整机平均功耗的 1.5 倍关键负载必须加足够容量的滤波电容。另外12V 转 5V 的 DC-DC 转换效率通常在 85%~90% 左右算功耗预算的时候要把转换损耗也算进去。4.2 散热设计被动散热不是“不用散热”端侧板子的散热设计是整个项目中投入产出比最高的一环也是最容易被低估的一环。很多开发板在实验室里开着盖子跑温度看着还行但一装进密封机壳散热条件立刻恶化。我在某次项目里把 Orin Nano 装在密封金属壳中以为搭配铝底板就行结果满负载跑 20 分钟后背面铝板超过 90°CGPU 频率直接掉了一半。后来重新设计了散热方案加了导热硅脂、铜热管和一只低转速微型风扇把热空气导向壳体外部温度才压到 65°C 左右。这里有个经验如果你的整机功耗超过 15W被动散热的成功率很低务必在设计阶段就把风道和风扇位置考虑进去。对于机载应用风扇的可靠性和噪音也是问题优先考虑温控风扇并选择质量可靠的滚珠轴承型号。另外散热设计和功耗是联动的板子温度每降 10°C半导体寿命理论上能延长一倍降频风险也小很多。如果你不想在部署后反复返工散热这事一定别省。4.3 线束、EMC 和物理连接在移动平台上都得当回事车载和机载场景还有一个实验室里不常注意的问题线束和电磁兼容。USB 3.0 高速信号线如果过长且没有屏蔽在电机运转时很容易受到电磁干扰导致摄像头画面偶尔花屏、网络设备断连。我在一台装配了无刷电机的机器人上反复遇到“照片随机丢失”的问题最后定位到 USB 线的屏蔽层在电机驱动线附近重新走线并加了磁环后问题才解决。物理连接的可靠性同样重要。NVMe 固态硬盘的插脚在持续振动下可能松动内存条在有震动载荷时也可能接触不良。我给长时间运行的平台都要求使用螺丝固定的转接板和锁扣式连接器并在关键的组件上打了固定胶或增加了减震结构。如果你做的是无人机这类高振动场景建议优先选择板载 eMMC 存储或者焊接式方案而不是依赖可插拔模块。5. 避坑清单与不同场景的快速选型建议5.1 一张清单帮你快速筛掉 80% 的错误选项我把这几年选型踩坑的经验整理成了一张决策清单每次接手新项目都会先过一遍负载清单是否列全每一路传感器的分辨率、帧率、编码格式每一个算法的输入输出和调用频率算力余量是否足够按峰值负载估算后留出 30%~50% 的余量给迭代内存带宽是否匹配多路视频或大分辨率输入优先看带宽而不只盯 TOPS精度需求是否锁定INT8 够用就千万别用 FP16 作为选型基准外围功耗是否计入摄像头、无线模块、传感器、转换效率全部算进整机预算散热方案是否可行超过 15W 的整机负载提前设计风道和主动散热生命周期是否明确消费级芯片可能 3~5 年就停产量产项目慎选。这在很多项目里能筛掉 80% 的备选方案剩下的再进入实测流程效率会高很多。5.2 常见误区复盘算力越大越好选贵的就没错我在论坛和朋友圈里经常看到类似“算力越大越好”和“预算够就上最顶配”的说法但实际项目里真不是这么回事。算力大的代价是功耗、散热、体积和成本同步上升而移动平台的电池能量密度是有限的热管理空间也是有限的不可能无限堆参数。另外一个常见的误区是只看 GPU 算力忽略了 CPU。具身智能系统里有大量调度、IO、路径规划逻辑需要在 CPU 上跑CPU 性能不够GPU 再强也发挥不出来。Orin Nano 就栽在这个上面GPU 有 40 TOPS但 CPU 只有 6 核 Arm 中低频核心多进程并发时经常成为系统瓶颈。持续性能比峰值性能更值得关注。很多板子的“标称算力”是在理论最高频率下测出来的实际负载跑几分钟后就因为温度墙而降频。选型时一定要关注“持续算力”也就是长时间满载后还能保持的性能水平。这需要实测来确认所以千万不要只看厂商给的峰值数据。5.3 场景化选型建议三类典型项目的推荐方向室内轮式巡检机器人和轻量级机械臂这类项目负载相对可控Orin Nano 8GB 或者瑞芯微 RK3588 作为起步平台问题不大。如果你的算法栈已经定型、负载也不重国产低成本平台能显著降低整机成本如果还在算法迭代期Orin Nano 的 CUDA 生态会让你开发效率高很多。室外无人配送车、巡检车和高动态无人机这类项目我建议 Orin NX 16GB 起步。它提供的算力余量足够覆盖多传感器融合和实时规划同时功耗也没有高到离谱。关键是这类平台经常在室外跑对环境温度的耐受能力必须特别注意散热设计要按极端工况去做。条件允许的话用工业级模组替代消费级开发板可靠性的提升非常明显。对于涉及端侧大模型交互、人形机器人这类高算力项目比如要在机器人本体内跑视觉语言模型或者做复杂动作规划的内存容量和带宽是第一优先级。AGX Orin 64GB 是当前比较可靠的选择。如果功耗限制很严可以考虑通过模型量化和剪枝把需求压下来而不是直接上更大算力的硬件。我在人形机械臂抓取项目里通过把视觉语言模型量化到 4bit输入图像分辨率从 1280 降到 960成功在 Orin NX 上跑通了原本以为只有 AGX 才能带的负载。6. 最后说点跑题但很重要的话很多人问做具身智能硬件选型到底有什么诀窍。我自己的答案是硬件选型不是一个一次性的决策而是和整个研发周期绑定的持续过程。最开始我也追着 TOPS 和参数跑后来发现真正决定项目是否顺利落地的往往不是芯片参数而是工具链顺不顺手、散热能不能压住、供电稳不稳定、和团队的软件栈匹不匹配。这些维度只有通过实机测试和长时间运行才能被验证。如果你现在正站在选型的岔路口我的建议很简单拿你最典型的一两个负载跑到你要选的每一块板子上用统一的数据说话。别急着下单实测一轮比看十篇评测都管用。端侧 AI 的坑千千万但大多数坑早踩总比晚踩好。祝大家的机器人在路上跑得稳、在空中飞得久。