端侧AI算力选型实战：从TOPS到具身智能硬件，避坑指南与方案对比

1. 项目概述：为什么端侧 AI 算力选型会成为具身智能落地的第一道坎

我最早接触具身智能相关的硬件选型，是在一个轮式巡检机器人的预研项目上。当时团队讨论的第一件事不是算法、不是传感器，而是主控板用哪家的芯片。做云端大模型的人往往以为，只要模型跑通了，硬件就是顺手部署一下的事。真等设备上车、上机，你会发现端侧 AI 算力这件事，坑比想象中多得多。

所谓端侧 AI，指的是把模型推理放在设备本体完成，而不是把数据传回云端再拿结果。具身智能（Embodied AI）这个词这两年很热，凡是让机器拥有感知、决策、行动能力的系统，基本都可以归到这个范畴。落在具体的载体上，常见的形态就是车载和机载设备——比如配送小车、巡检机器人、农业无人车、工业 AGV、无人机吊舱，甚至人形机器人的计算单元。

这篇文章要解决的，就是这类项目里“算力芯片和硬件选型”的实际问题。目前市面上能选的端侧算力芯片很多，有嵌入式 GPU 路线的，有 NPU 路线的，也有 FPGA 和异构 SoC 路线的。每一类都有自己的逻辑，也都有自己的坑。如果你正在做具身智能项目的硬件选型，或者准备把已有的模型搬到终端设备上跑，这篇文章会帮你少走不少弯路。

需要说明的是，这不算一篇评测机构的报告，更像是我个人在多个项目里反复“踩坑”之后的记录。数据来自实际测试，结论来自项目复盘，不一定适用所有场景，但大概率能帮你避开一些常见的坑。

2. 需求拆解：算力不等于显卡，TOPS 也不等于实际性能

2.1 算力指标的真相：为什么 100 TOPS 跑不动一个小模型

先聊一个最常见的误区：看宣传册选芯片。很多做算法出身的人，第一次接触硬件选型时，看到“200 TOPS”这种数字就觉得稳了。实际拿到板子一跑，发现连一个 6 亿参数的语言模型都推不满 20 FPS，甚至比本地 XV6 服务器还慢。

一个非常重要的结论摆在前面：TOPS 这个指标，反映的是算力理论上限，而且是特定精度、特定稀疏度下的上限。很多芯片标称的算力是 INT8 精度、50% 稀疏度下测出来的。你实际部署时跑的是 FP16 模型，甚至是混合精度，性能直接掉一半以上。就算精度对齐了，实际能利用的有效算力通常只有标称值的 30% 到 60%。

拿我做过的轮式巡检机器人项目举例。当时选了一款标称 32 TOPS 的 NPU 芯片，结果跑 YOLOv8s 只到了 18 FPS。后来换了另一款标称 16 TOPS 的芯片，居然跑到了 32 FPS。为什么？因为后者有独立的视频编解码单元和更聪明的数据搬运机制。这说明算力不是唯一的变量，数据通路和配套单元常常比算力更关键。

2.2 车载与机载场景的差异：算力需求完全不同

车载和机载虽然都算移动平台，但约束条件差异很大。车载对功耗和体积相对宽容，一般有几瓦到几十瓦的余量，整机可以做到无风扇或者小风扇；机载特别是无人机吊舱，则把功耗、重量、散热卡得非常死，往往只有 5 到 15 瓦的预算。

以无人机避障场景为例，常见的需求是：实时处理双目相机或光流数据，在 30 毫秒内输出障碍物距离信息。这个场景实际上不一定需要大算力，更需要的是低延迟和确定的推理时间。而车载场景更多是融合多路摄像头加激光雷达，跑目标检测加语义分割，偶尔还要带一个语音交互模型。这种组合对算力的需求就膨胀得非常快。

实话说，很多团队在做硬件选型时，并没有严格分析计算需求就拍脑袋定了芯片，结果不是性能不够推倒重来，就是性能过剩多花了很多钱和功耗。所以第一步一定是梳理清楚自己的场景需求，再谈选哪颗芯片。

2.3 从“跑得动”到“跑得好”：三个容易忽略的变量

除了算力，还有三个变量在实际选型中容易被忽略。第一是内存带宽。我见过不少项目，模型推理速度提不上去，最后一句分析发现瓶颈全在内存带宽上。小模型尤其如此，权重反复读写，带宽不够时，哪怕 NPU 再快也只能干等。第二是内存容量。跑大模型时，容量不够只能做量化或者模型切片，但这又会带来精度损失或推理延迟。第三是软件工具链的成熟度。芯片再好，工具链一团糟，算子不支持，编译器生成低效代码，开发周期会拉长到不可接受的程度。

这里我有个经验之谈：选芯片，本质上是选“芯片 + 工具链 + 生态”的组合。芯片本身的指标只是 30%，另外 70% 看的是你能不能在上面高效地跑起来。

3. 主流端侧算力芯片横向对比：我实测过的方案与体验

3.1 嵌入式 GPU 路线：NVIDIA Jetson 系列有多能打

NVIDIA Jetson 系列是端侧 AI 硬件里绕不开的存在。Orin NX、Orin Nano、AGX Orin 我都实际用过，整体体验是：生态最完善，踩坑最少，但价格和功耗也较高。

我常用的配置是 Jetson Orin NX 16GB 版本，标称 100 TOPS（INT8 稀疏），实际深度优化后跑 YOLOv8m 可以在 40 FPS 左右，跑 7B 参数的量化语言模型（Q4 量化）能做到首 Token 延迟 800 毫秒左右。这在端侧已经是不错的水平。不过需要注意的是，这颗芯片满负载时的功耗能冲到 25 瓦，如果不做功耗限制，整个系统的供电和散热压力都不小。

还有一个细节：Jetson 系列的性能模式和功耗设置有讲究。默认模式往往不是最优的。我一般会把设备调成“MAXN 模式”跑推理测试，但如果要长时间稳定运行，反而建议降低频率与功耗墙，否则局部热点会让性能衰减得特别快。

3.2 专用 NPU 路线：地平线征程系列与瑞萨等方案的取舍

国产芯片这两年进步非常大。地平线征程系列是专用在智能驾驶场景的 NPU，我在地平线征程 3 和征程 5 上都做过移植。征程 5 标称 128 TOPS，实际跑车载视觉模型的效果相当好，工具链对 CNN 类网络优化得比较到位，一些算子甚至比 Jetson 上的同款跑得快。

但专用 NPU 有一个共同特点：通用性较弱。征程系列对 Transformer 类网络的支持，我测试时感觉明显不如 CNN 顺手。如果你要跑多模态模型、语音模型甚至大语言模型，可能需要手工做大量算子适配，工程量不小。类似的问题在瑞萨、安霸的方案上也有，只是程度不同。

工具链是专用 NPU 路线的重中之重。地平线的工具链更新节奏快，社区资料也越来越丰富，整体可玩性在国产方案里算第一梯队。但如果你团队里没有专门的编译器工程师，我还是建议谨慎，评估清楚工具链的学习成本。

3.3 国产通用 SoC 路线：算能、瑞芯微、晶晨的性价比之争

如果你的需求是“够用就好”，不必追最新的旗舰芯片，那算能、瑞芯微、晶晨这些厂商的 SoC 会让你眼前一亮。以瑞芯微 RK3588 为例，它自带 6 TOPS NPU，整板功耗可以控制在 10 瓦以内，价格只有 Jetson 方案的几分之一。我曾在 RK3588 上跑轻量级的目标检测和关键点检测，优化后能达到实时性，完全够一些低速巡检场景使用。

算能的 BM1684X 我也测过，标称 32 TOPS，板卡形态比较丰富，支持 PCIe、SoC 两种模式，对 Transformer 的支持比瑞芯微成熟一些。它的工具链对 ONNX 模型的支持做得不错，基本可以做到训练后直接转模型，对工程团队比较友好。

如果你做的是低成本、大批量的产品，这类国产 SoC 是很现实的选择。但要做好性能调试的心理准备——同样的模型，在这些芯片上要跑出理想性能，一般需要在算子融合、数据布局、量化策略上花时间调优。

3.4 其他值得关注的方案：FPGA 与 RISC-V 的差异化定位

FPGA 在端侧 AI 里属于小众但稳定的存在。Xilinx（现在是 AMD）的 Kria 系列和 Intel 的 Cyclone 系列在一些定制化场景中非常有用。FPGA 的优势是确定性延迟和灵活的接口，比如你需要同时接入多路相机并且做底层预处理，FPGA 可以在数据进入 NPU 之前就完成尺寸缩放、色彩空间转换、ROI 裁切等操作，主芯片计算压力小很多。

RISC-V 在端侧 AI 的布局也在加速。目前 RISC-V 方案在生态和应用性上还比较初期，主要适合有自研能力的团队。如果你所在的团队足够大，也有意愿深度定制内核，RISC-V 的潜力很大。但小团队不建议现在入场当小白鼠。

3.5 实测数据汇总：一个表格看清各方案的实际表现

为了让你对上述方案有一个更直观的对比，我整理了一张实测数据的表格。数据来自我过去一年内做的多个项目测试，不保证绝对精确，但趋势很有参考价值。

4. 硬件选型实操：关键指标、搭配避坑与决策方法

4.1 指标解读：除了 TOPS，你还要盯紧这六个参数

• 内存带宽：单位是 GB/s。通常大模型对带宽的敏感度高于算力。一般建议带宽不少于 50 GB/s，跑多模态模型建议 100 GB/s 以上。
• 内存容量：如果你要跑 7B 参数模型，INT8 量化后大约需要 8 GB 左右的内存私有占用。加上系统、框架、输入输出缓冲，建议 16 GB 起步。
• I/O 接口：相机通常走 MIPI-CSI 或 USB3.0，激光雷达走 Ethernet 或 UART，需要提前确认芯片原生支持哪些接口，避免后期加转接板增加成本和故障点。
• 视频编解码单元：如果你需要同时处理多路视频流，硬编解码单元能省下大量算力。很多 NPU 芯片都带 VPU，但不同芯片的 VPU 能力差异很大。
• 功耗与散热设计：不要只看芯片的 TDP，要结合整板的电源转换效率、散热方案来看。很多板子在宣传时说的是芯片功耗，实际整板功耗会高出 30% 以上。
• 量产可获得性：这一点在消费电子缺货时代尤其重要。有的芯片性能好，但交期 52 周，产品根本等不起。选型时一定确认好供货情况。

4.2 散热与供电：端侧设备最容易翻车的两个环节

我说句实在话，做了这么多项目，散热和供电引发的故障，比芯片本身的问题多得多。

散热方面，车载和机载环境温度往往很高。夏天车内仪表台附近温度可以到 70 摄氏度，无人机在太阳下悬停时机身表面也很烫。如果你的散热设计只考虑 25 摄氏度的实验室环境，上了真机必然过热降频。我的经验是，散热设计至少按环境温度 50 摄氏度来做余量。可以选择带风扇的主动散热，但注意风扇本身也是故障点，在粉尘、雨淋场景下容易坏。如果能选大尺寸散热片加被动散热，稳定性会好很多。

供电方面，端侧设备最容易出问题是瞬间电流拉垮。NPU 在启动大任务时电流会突然飙升，如果你的电源设计余量不足，电压跌落会导致系统重启，甚至是文件系统损坏。我建议系统电源至少留出 1.5 倍峰值电流的余量，并且在板上加足够容量的储能电容。

4.3 工具链评估：拿到开发板后先做这四步测试

在最终拍板选定芯片之前，我强烈建议你按下面四步做一轮快速评估。这个流程筛选下来，能帮你过滤掉 70% 的不合适方案。

第一步，环境搭建。确认芯片的 SDK、交叉编译工具链、模型转换工具是否能在半天内顺利跑通。如果这一步就卡住，后面大概率也是坑。第二步，跑通一个你已经训练好的模型。挑一个你项目中比较有代表性的模型，按官方文档完成转换到部署的全流程，记录转换时的报错和需要手工调整的算子数量。第三步，压测极限性能。把模型跑起来，用工具监测芯片温度、功耗、帧率，连续跑 12 小时，看是否出现性能衰减或崩溃。第四步，模拟真实环境。如果条件允许，把整机放到高温箱或者振动台上做个简单的鲁棒性测试。这一步做不了的话，至少要在户外实际跑一跑，看整机在不同温度下的表现。

4.4 一个可复用的选型决策流程

结合我自己的项目经验，我总结了一个选型决策流程，仅供参考。首先，列出项目的核心计算任务清单，包括模型类型、输入分辨率、实时性要求、并发路数。其次，根据任务清单估算最低算力和内存需求，注意这里用实际测试值的 1.5 到 2 倍来做安全余量。接着，考虑环境约束，比如功耗上限、体积限制、温度范围、防护等级。再其次，考察工具链成熟度和团队自身能力。最后，核算全生命周期成本，包括芯片采购成本、开发人力成本、量产维护成本，而不是单看 BOM 成本。

5. 实战部署与问题排查：我踩过的坑和解决方案

5.1 部署实测：从模型转换到推理性能调优的完整链路

以一个典型的目标检测模型部署为例。我们在 Jetson Orin NX 上部署 YOLOv8s，模型来自 PyTorch。完整链路大概是：先把 PyTorch 模型导出为 ONNX，再用 TensorRT 做 FP16 转换，最后在引擎基础上写推理代码。整个过程听起来简单，实际操作时几个环节都需要注意。

第一个坑是 ONNX 导出时的动态尺寸问题。YOLOv8 默认导出可能是固定输入尺寸，如果你的项目需要多分辨率输入，导出时务必带上动态轴参数，否则后面转换 TensorRT 时只能固定尺寸，非常不灵活。

第二个坑是 TensorRT 转换时的精度下降。FP16 转换后，检测框的置信度往往会有 0.5% 到 1% 的波动，这在大多数场景下可以接受。但如果你做的是高精度测量类任务，建议先做转换前后模型的逐层输出对比，确认哪些层精度偏差大，再决定是否对这些层保留 FP32。

推理代码层面，我强烈建议用 C++ 或 Rust 写生产环境的推理服务，而不是 Python。Python 在原型验证时很舒服，但正式产品上线后，Python 的开销和依赖管理会成为问题。我们当时把 Python 推理服务改成 C++ 后，端到端延迟下降约 30%，内存占用也明显降低。

5.2 问题排查实录：多个典型问题与解决思路

下面是我在多个项目里遇到的高频问题，整理成速查表，你可以直接拿来对照排查。

5.3 关于安全的提醒：合规与可靠性设计

在写这篇内容的时候，我特别想提醒一点：任何端侧 AI 设备的部署，都要把安全设计放在第一位。车载机载环境不同于实验室，一旦系统失效，可能造成设备损坏甚至安全事故。

可靠性设计上，至少要保证三点。一是关键模块的冗余设计。比如视觉感知模块失效时，系统能自动降级到超声或雷达避障，而不是直接“失明”。二是看门狗机制。主控芯片需要与独立的看门狗或协处理器联动，遇到系统卡死能自动重启。三是有完善日志记录。端侧设备出现问题时，没有日志几乎无从排查。建议日志写入独立的存储分区，循环覆盖，避免日志写满导致系统异常。

5.4 后续扩展：这套选型经验如何复用到大模型与多模态场景

最后聊聊可扩展性。具身智能正在从单一感知发展到多模态理解，越来越多的设备需要在边缘跑视觉语言模型（VLM）甚至大语言模型。这类模型对显存带宽和容量的要求比传统 CNN 高出一个量级。

如果你预测未来 1 到 2 年内要在设备上跑大模型，选型时建议优先考虑支持大内存带宽的芯片，比如 LPDDR5 或 LPDDR5X 平台，带宽最好到 100 GB/s 以上。同时要考虑大模型量化方案的兼容性，比如是否支持 INT4 量化。当前很多端侧芯片对 INT4 的支持还在完善中，选型前建议实测一下跑 7B INT4 模型的实际效果。

我的经验是，具身智能项目的硬件选型，最好眼光放远一点。不要只看当下跑得动，更要看未来一年内模型的迭代对硬件会不会提出新的要求。硬件换型的成本极高，宁可多花一点成本买性能余量，也不要为了省几颗芯片的钱把整个项目拖入返工的泥潭。

做硬件选型这件事，急性子做不了，但过度求稳又会错失机会。我的体会是：多测、多记录、多复盘，选型能力会随着项目经验逐渐积累。希望这份实测记录能帮你少踩几个坑，少熬几个夜。