企业官网建设流程全解析

做机器人这几年，我有一半的时间不是在调算法，而是在跟“端侧AI算力”这个词较劲。给无人车配过算力板卡，给机械臂选过主控，给无人机做过机上推理，几乎每一次硬件选型，都要重新踩一遍“标称参数和实际表现”之间的坑。网上都说40 TOPS的板卡随便跑，真到了车载环境里，供电一波动、温度一上来，帧率直接腰斩；有的芯片标称功耗很低，满载十分钟就过热降频，整机还不如一颗树莓派稳定。这些经历让我意识到，具身智能场景下的端侧AI硬件选型，根本不是一个“看参数买板子”的活儿，它拼的是对算力利用率的理解、对功耗和散热的把控、对工具链成熟度的判断。这篇文章我就把这几年做车载/机载端侧AI部署时形成的一套算力芯片选型方法和实测流程整理出来，给正在做具身智能二次开发、或者准备入行端侧AI项目的朋友做一份避坑参考，少花冤枉钱，少走弯路。

1. 先搞清楚：具身智能到底需要多少端侧算力

1.1 端侧AI和云端的算力逻辑不一样

很多人第一次接触端侧AI，习惯性地拿云端的思路来想问题：云端算力不够，那就多加几张卡，算力是越多越好的商品。但端侧AI，尤其是车载、机载这种场景，逻辑完全不是这样。端侧算力是一个“受约束条件下的多目标优化问题”，要在有限的功耗、散热、尺寸、成本内，满足实时性、稳定性和精度要求。

以一台室内轮式机器人为例，它要把多个摄像头的图像实时处理成障碍物信息，同时跑SLAM、路径规划和电机控制。这颗算力芯片不只要跑得动模型，还要在夏天车内60度、冬天零下十几度的环境里连续工作，不能因为散热差就罢工。更关键的是，整个感知到控制的闭环延迟必须压得非常低，如果一路从摄像头取帧、图像预处理、NPU推理、后处理、决策规划到电机输出，端到端超过100ms，底盘稍微跑快点就可能撞墙。

云端可以靠堆硬件、弹性扩容来解决吞吐量，端侧没有这个条件。一块板卡焊死了就那么大的散热面积，电池容量就那么一点，芯片位置就那么大。所以选型的第一步，不是看谁的TOPS数字大，而是先算清楚：我的系统到底需要多少毫秒完成一次感知闭环？这个机器人/车辆/飞行器能接受多大的功耗和重量？然后倒推出算力需求，再去找合适的芯片。

1.2 用感知延迟反推算力需求的估算方法

具身智能设备的算力需求，最好用“延迟预算”来反推。比如一台园区巡检车，设计指标是最高时速5m/s，需要能检测10米外的行人并刹停。假设底盘执行机构响应需要50ms，那感知部分最多只能占70ms。如果相机是30帧每秒，一帧的间隔是33ms，那感知管线至少要在2帧以内必须出结果，也就是66ms以内必须完成一次完整的检测流程。

拿YOLOv5s这个经典检测模型举例，它在640x640输入下大约有16 GMACs的计算量。INT8量化之后，一次前向计算大约要32 GOPs（因为一个MAC等于两次运算）。如果一颗芯片标称10 TOPS的INT8算力，理论上能做到3.2ms完成一次推理。但现实很残酷，NPU的算子利用率很难跑满，加上图像解码、颜色空间转换、缩放到模型输入、NMS后处理这些步骤，一整套感知管线下来常常要20到30ms。所以反推的时候，我会把理论算力先打三到五折，再和延迟预算对比。

还有一个现在越来越常见的需求：端侧跑大模型，也就是视觉语言模型VLM或者语音对话模型。这时候“算力”这个概念就变成了另一个维度的评估方式。很多人问“什么是算力”“token算力需求如何评估”，其实说得直白一点：算力是硬件每秒钟能做多少次运算，token是模型每生成一个词单位需要消耗的资源，API是别人把算力和模型封装好后卖给你的服务，三者根本不是同一个东西。端侧部署大模型时，真正卡脖子的往往不是TOPS，而是内存带宽。因为大模型解码阶段是一个一个token往外蹦的，每生成一个token，都必须把整个模型的权重读一遍。一个3B参数、INT4量化后的模型大约占2GB空间，如果内存带宽是51.2GB/s，理论上每秒最多只能读取25.6次完整权重，也就是说生成速度上限大约是25 token/s。这个速度做简单的语音回复够用了，但要做实时对话、复杂推理，就会觉得不太够。这个我会在第5章再展开细讲。

2. 算力芯片怎么选：不被TOPS数据带着走

2.1 TOPS到底怎么算出来的，为什么跑分不可信

先拆一个网上最容易误导人的概念：TOPS。TOPS全称是Tera Operations Per Second，每秒万亿次运算。问题出在“运算”这两个字上——是稠密运算还是稀疏运算？是INT8还是INT4还是FP16？MAC阵列是不是全都算进去了？这里的门道非常多。

最典型的例子是“稀疏算力”。AI推理中，如果权重矩阵有大量零元素，理论上可以跳过这些计算，于是很多芯片宣传“稀疏算力”是“稠密算力”的两倍。但实际部署的模型经过剪枝和稀疏化的并不多，常规模型跑出来的就是稠密性能。还有的芯片宣传的是“等效算力”，意思是用了某些特殊的数据复用方法之后，等效于多少TOPS，但真实跑一个MobileNet或者ResNet，根本到不了那个数字。前阵子社区里流传的那张“8797算力”排行图，我反复找过原始测试条件，发现根本说不清楚到底测的是什么精度、什么负载、什么功耗墙，这种脱离场景的跑分，拿去当选型依据非常危险。

我自己的习惯是：TOPS只是用来划定大范围的筛选条件，比如我要找一块10 TOPS级别的芯片还是100 TOPS级别的芯片，可以看标称值。但到了具体选型阶段，必须跑真实模型、在真实功耗墙下、采集长时间运行数据，然后才能做判断。类似“显卡AI算力TOPS排行”“TOPS对照表”这类榜单，参考一下产品定位可以，千万别当成性能承诺。

2.2 真正决定体验的几个硬件参数

抛开跑分，端侧算力芯片真正决定实际体验的，是下面这几个参数。

第一是内存带宽。卷积、Transformer、图像处理全都是数据密集运算，算力再高，数据搬运不过来也是白搭。我测过同一颗SoC用LPDDR4x和LPDDR5的差异，跑同一份量化的YOLOv5s，帧率能差出20%还多。大模型推理更是被带宽卡得死死的，带宽不够，TOPS再高也只能干瞪眼。

第二是功耗墙和热设计。大多数端侧SoC是有“功耗墙”概念的，芯片可以在短时间跑到最大算力，但功耗冲到峰值之后发热，几秒钟之内就必须降频保护。如果整机的散热结构跟不上，长期运行的性能会远低于标称值。选型时一定要问清楚：这颗芯片在持续满载情况下，允许的功耗是多少，需要什么样的散热条件才能稳住性能。

第三是内存容量。具身智能设备往往要同时跑多个模型：一个检测模型、一个分割模型、一个深度估计模型，甚至一个端侧语言模型。8GB内存的板卡看起来够用，但多模型叠加、系统占用、数据缓存之后，内存吃紧是常态。大模型一上，内存不够比算力不够更致命。

第四是存储速度。模型文件动不动几GB，从eMMC加载和从NVMe SSD加载的延迟差距很大。很多机器人开机后要等十几秒才能进入正常工作状态，瓶颈往往就在存储上。

第五是接口资源。车规/机载场景要接多路相机、激光雷达、CAN总线、串口、GPIO、PWM。如果不能同时提供足够的MIPI CSI、PCIe、USB、CAN接口，算力再强也很难贴合实际安装场景。

2.3 市面主流端侧算力方案分类与对照

根据我这几年趟过的坑，把市面上的端侧算力方案大致分成三类，表格里列的是典型代表，供选型时参考。

这个分类不是严格的性能梯队，更多是“定位差异”。Jetson系列的开发体验最好，性能也最强，但功耗高、价格贵、供货周期波动大；RK3588这类国产SoC性价比很高，但工具链和算子支持需要花时间磨合；MCU级方案适合做非常简单的反馈控制，跑不了复杂模型。

选型建议很直接：如果团队算法能力强、追求快速原型验证，Jetson系列是最省心的；如果做量产产品、对成本功耗敏感，认真调研国产NPU SoC；如果只是给执行机构做个简单避障，别把系统搞得过于复杂，一颗带NPU的MCU就够了。

3. 实测流程与关键方法论：别只看跑分

3.1 我建议的端侧AI实测四步法

选型阶段必须实测，但实测不能瞎测，要有流程。我每次拿到新的算力开发板，会固定跑一套四步测试流程。

第一步是固定基准模型。我通常选一个轻量检测模型如MobileNetV3-SSD、一个常规检测模型如YOLOv5s/YOLOv8s、一个分类模型如ResNet50，全部转为目标平台的INT8格式。如果产品方向涉及端侧语言模型，还会加一个1.5B到3B的量化LLM。固定模型的好处是不同平台之间可以横向对比。

第二步是跑平台自带的benchmark工具。Nvidia有trtexec，瑞芯微有rknn_benchmark，地平线有自己的模型转换和性能评估工具。这一步能快速知道模型在硬件上的理论吞吐上限和单帧耗时，但它反映的是“理想状态”，因为benchmark通常只统计NPU/GPU的纯推理时间，不包括图像预处理和后处理。

第三步是跑真实感知管线。把相机接上，做完整的解码、缩放、归一化、推理、NMS、话题发布链路。这一步才能看出芯片在实际系统中的表现。很多板卡跑benchmark很好看，一旦接上多路相机和ROS节点，帧率立刻暴跌。

第四步是做持续压力测试。让板卡满负荷运行至少3小时，记录温度、功耗、帧率的变化曲线，观察是否出现热降频。这一步最关键，因为在车载和机载环境里，系统要长时间开机，散热问题会直接暴露性能衰退。

3.2 实测数据怎么看：延迟分位、温升曲线和功耗波动

很多人看实测数据只会看“平均帧率”，这是一个很大的误区。具身智能系统是闭环控制，更关心的是“最坏情况下的表现”。我会重点看三个数据维度。

第一个是延迟分位数。平均帧率70FPS的板卡，如果p99延迟冲到400ms以上，在高速运动的机器人上就是灾难，因为几帧之间的延迟抖动会把控制周期打乱。我见过最典型的案例：一块Jetson板卡在室温下跑感知管线，平均推理耗时12ms，但每几十秒就会有一个200ms以上的尖峰，查下来是CPU调度、内存带宽争抢造成的。平均指标好看没有用，必须盯p95甚至p99。

第二个是温升曲线。记录板卡从冷启动到热平衡过程中，算力芯片的表面温度和满载推理耗时的变化。有的板卡冷启动时YOLOv5s单帧9ms，半小时后掉到14ms，再往后稳定在15ms左右，这种就是要靠高热容量硬扛的被动散热方案，长时间运行性能下降不可避免。用这个数据来决定要不要加强散热、要不要把功耗墙调低。

第三个是功耗波动。端侧设备往往是电池供电，SoC瞬时功耗如果频繁出现尖峰，会拖垮电源系统。我测过一块宣称8W功耗的板卡，实际跑模型时瞬时电流冲到3A以上，在锂电池供电条件下，电压跌落导致整机重启。所以选型时要确认芯片的功耗包络，而不是只盯TDP标称值。

3.3 具身智能场景独有的压力测试清单

通用评测只会测单模型性能，但具身智能场景有几个独有的压力项，是普通评测根本不会覆盖的。

我整理了一份高频压力测试清单，每次换硬件平台我都会跑一遍：

• 多路视频流同时接入：至少接4路以上RTSP或MIPI摄像头，确认芯片的解码能力和NPU推理能同时扛住；
• 多模型并发运行：检测、分割、追踪模型同时加载，验证内存带宽和算力分配是否够用；
• 电源循环测试：模拟车载环境下反复上电下电，连续循环300次，看系统是否稳定启动，会不会出现死锁；
• 环境温度冲击：把板卡放进温箱，在-20℃到60℃之间循环，测冷启动时间和高温长期稳定性；
• 供电波动测试：用可编程电源模拟车辆启动瞬间的电压跌落，看板卡是否会重启；
• 振动和连接器可靠性测试：车载/机载场景有持续振动，提前确认接插件不会松脱、SD卡不会接触不良。

现在行业里也在推动一些端侧算力和机器人硬件的可靠性标准建设，大家选型时可以多关注这类公开的标准体系文件，里面通常会有关于性能评估方法、可靠性测试的参考条款，对制定自己的验收标准很有帮助。

4. 多平台实操记录：Jetson / RK3588 / 地平线 / 爱芯

4.1 英伟达Jetson Orin系列：生态最强，但要会控功耗

Jetson系列是端侧AI最主流的平台，尤其是Orin Nano和Orin NX，几乎是机器人和无人车项目的标配。好处不用多说：PyTorch训练完模型之后，用TensorRT转换部署，整个链路非常顺滑，网上教程多到看不完。但Jetson有几个非常折磨人的点，第一是功耗，第二是散热，第三是供电。

先说功耗和散热。Orin NX这种级别的板卡，不设功耗墙的时候，满载功耗能冲到25W以上，一个小风扇根本压不住，几秒钟就热降频。正确做法是用nvpmodel显式设定功耗模式，比如15W模式或者20W模式，让芯片在可控的功耗范围内运行。我实测过，Orin NX在15W功耗墙下，跑一个完整的YOLOv5s INT8感知管线，端到端单帧耗时大约30到45ms，对于10Hz量级的闭环控制完全够用，而且温度能稳定在70℃以下。

再说供电。Jetson对电源质量非常敏感，我以前有一块Orin NX，电机一启动就重启。排查到最后发现是电机驱动器启动瞬间，车载电源的电压跌落触发了板卡的欠压保护。解决方式是给算力板单独走一路DC-DC电源，前面加一个大容量电容和稳压电路，之后再也没有无故重启过。

最后是管理调试。Jetson自带的tegrastats命令可以查看实时功耗、温度、内存占用，配合nvpmodel -m参数切换功耗挡位，CPU频率和GPU频率都可以手动锁定。我每次上车调试，第一件事就是把功耗墙设好，用tegrastats把日志开着，方便事后回顾整车的运行状态。

4.2 瑞芯微RK3588/RK3576：性价比高的NPU方案

如果项目对功耗和成本敏感，又不需要太高的算力，瑞芯微的RK3588/RK3576是我用得比较多的国产方案。RK3588的NPU标称6 TOPS，实际跑YOLOv5s INT8 640输入，单帧推理耗时大约15到25ms，整机功耗比Orin NX低一大截，很多被动散热的方案都能稳住性能。RK3576定位更低一点，适合更轻量的巡检小车和无人机载机。

RK3588最大的难点是工具链。rknn-toolkit2负责把PyTorch/ONNX模型转换成RKNN格式，整个转换流程里有几个高频坑：一是算子兼容性，模型里只要出现NPU不支持的算子，转换就会失败或者被迫切到CPU执行，性能直接崩；二是量化校准，PTQ量化时如果校准数据集选得不好，转换后的模型精度会急剧下降；三是模型输入尺寸必须对齐，很多模型在转换过程中对分辨率有对齐要求。

我的经验是，用RK3588做量产项目，一定要尽早把模型确定下来并冻结，然后花时间做算子层面的适配。模型结构里如果用了比较新的模块，比如某些注意力机制、可变形卷积，先确认rknn-toolkit2是否支持，不支持的话要么换结构，要么自己拆算子。虽然折腾，但成本和供应链的自主性优势非常明显。

4.3 地平线征程系列：面向车规的BPU方案

地平线的征程系列这几年在车企里供货量很大，其BPU（Brain Processing Unit）架构是专门为自动驾驶设计的，工具链也是围绕车规场景打磨的。我接触过它的开发板和量产级模组，整体印象是：算力利用率高，尤其是卷积类网络跑得非常稳，车规级的温度范围和寿命设计也让人放心。

但地平线的工具链对开发者的要求要高一些，它有自己的模型转换、量化、编译流程，算子支持范围跟业界通用框架有一定的交集和比较明显的差异。调模型的过程需要仔细看文档，社区资料比Jetson少，遇到问题经常要啃英文手册和官方FAQ。

如果做量产级的园区物流车、巡检车，征程系列很值得考虑。它的一些中低算力的芯片在功耗上比Jetson NX更有优势，而且车规背书意味着长期的供货稳定性和功能安全支持，这在项目量产阶段是很重要的加分项。

4.4 低功耗与图传场景的替代方案

不是所有具身智能设备都需要跑大模型。我做过一个无人机项目，机上只需要做简单的目标检测，然后通过图传把结果和视频回传地面站。这种情况下用Jetson这种级别的板卡太奢侈了，功耗大、重量高、续航短。后来换成了一款主打AI ISP和低功耗NPU的国产方案，型号是爱芯AX650N，跑轻量检测模型的同时承担视频编码，整体功耗比Jetson降了一大半，而且AI ISP可以自动处理光照变化，在逆光场景下识别率比普通方案稳定很多。

还有一些微型机械臂、桌面级设备，连独立的NPU SoC都用不上。STM32N6这类内置NPU的MCU，功耗控制在1W以内，直接跑轻量模型，搭配简单的电机控制，非常适合做教育机器人和玩具级具身智能。选型的时候不要把系统想得太复杂，有时候“够用”比“性能强”更合适。

4.5 端侧设备统一管理：常用命令与监控

车机上有多台算力设备、多块板卡的情况很常见，这就涉及到统一管理的问题。很多做云端的人习惯用容器和集群管理，但端侧设备没有这么重的条件，我的做法是分三层：SSH远程管理、系统指标采集、OTA升级。

Nvidia平台我会用tegrastats、nvpmodel、jtop三个工具，tegrastats看实时状态，nvpmodel切功耗模式，jtop可以网页图形化监控。RK3588平台上没有这么统一的工具，我会通过读取/sys/class/thermal/thermal_zone*/temp和/sys/kernel/debug/rknpu/load来获取温度和NPU负载，配合自己写的一段采集脚本汇总到监控面板。

OTA升级方面，车载/机载设备最忌讳升级失败变砖。我建议采用A/B双分区方案：系统镜像放在两个分区里，启动时优先从A分区启动，一旦A分区启动失败或者校验失败，自动回退到B分区。加上硬件看门狗，升级中途断电也能恢复。这一套体系配合好，后期维护成本能低很多。

5. 具身智能二次开发的真实现状与坑点

5.1 工具链成熟度决定开发效率

选端侧算力芯片，本质上选的是“模型部署工具链”。同样的模型，在Jetson上用TensorRT一天就能部署完，在国产NPU平台上可能要花一周，差别就在工具链的成熟度上。

常见的部署链路是：训练好的PyTorch模型导出为ONNX，然后用平台SDK完成量化、转换、编译，最后在板端通过推理框架运行。整个过程里最容易出问题的环节是量化。PTQ（训练后量化）简单快速，但精度损失比较大；QAT（量化感知训练）精度好，但需要重新训练模型，开发周期长。实战中我的经验是：先跑PTQ看精度，如果掉点超过可接受范围，再用混合精度，把敏感层保留为FP16，最后才考虑QAT。

另一个高频坑是算子兼容性。模型里出现自定义算子、或者平台不支持的算子，是整个转换失败的常见原因。我在RK3588上遇到过模型用了某个较新的注意力实现，NPU不支持，只能拆成矩阵乘法和Softmax分步实现，折腾了大半天。所以做具身智能模型的时候，算法团队最好提前知道部署平台的算子支持列表，从模型选型阶段就避开不支持的算子。

如果你是准备做具身智能二次开发的工程师，我的建议是学习路线一定要从工具链入手：先选一个平台，把自己熟悉的模型完整部署一遍，再去做复杂的感知逻辑。很多初学者一上来就搞多传感器融合、搞SLAM、搞大模型，结果模型根本跑不动，白费功夫。

5.2 大模型端侧部署：token算力需求怎么估算

现在端侧跑大模型是热门话题，但很多人的预期是不切实际的。先明确一个概念：算力、token、API不是同一个东西。算力是硬件的计算能力，token是模型处理文本的最小单位，API是别人把算力、模型和接口封装好后给你的服务。端侧部署大模型，涉及的是前两者：硬件能不能在规定时间内支撑模型的token生成速度。

估算token生成速度有一个非常实用的简化公式：token/s约等于内存带宽除以模型权重大小。一个3B参数的模型，INT4量化后权重约2GB，在LPDDR5 51.2GB/s的带宽下，理论上限约25 token/s。实际部署中还要处理KV Cache、系统调度、显存/内存分配等开销，能稳定跑到15到20 token/s就算不错。如果要用7B模型，INT4量化后约4GB，同样的带宽下最高才12 token/s左右，对话速度会明显偏慢。

所以端侧到底用多大的模型，核心约束条件不是TOPS，而是内存带宽和内存容量。我做过一个机器人语音交互项目，最初想上7B模型，测试后觉得响应速度太慢，后来换成3B量化模型，速度能接受，交互效果也不会差太多。如果你的场景需要理解图像、做复杂的多轮对话，就要认真考虑8GB以上内存的板卡，甚至上Orin NX 16GB这个级别。

另一个容易被忽略的问题是多个模型同时跑的资源争抢。视觉感知模型和语言模型同时运行时，两者都在抢内存带宽，结果是检测帧率下降、token生成变慢。我的做法是给视觉任务和语言模型做时间片错峰，或者把不同任务绑到不同CPU核心上，尽量降低互相干扰。

5.3 车机环境下的电源波动与散热设计

车载和机载环境的供电条件，比实验室电源恶劣得多。车辆启动瞬间、电机加减速、电磁阀动作，都会在电源线上制造很大的冲击和纹波。算力板卡如果直接和电机驱动共用电源，几乎必然出现问题。

我遇到过最典型的情况是：机器人关节电机一启动，NPU推理时间从8ms直接跳到30ms，模型本身没问题，是电源纹波导致NPU供电不稳，芯片自动降频保护。后来做了两件事解决问题：给算力板卡单独增加一路低纹波的DC-DC电源，并在输入端并联大容量电解电容和陶瓷电容，吸收瞬态冲击；同时将电机驱动的电源回路与算力板的地线、电源线物理分离，减少耦合干扰。

散热也是车载/机载选型里最容易被低估的一环。无人机上不能用主动风扇，只能靠被动散热，所以芯片的功耗墙必须对应到被动散热能力。汽车夏天在阳光暴晒下，座舱内温度可以到70℃以上，这时候SoC的结温余量就非常关键。选型时要查清SoC允许的最大结温，再看整机散热方案能不能在极限工况下压得住。

还有一个小坑是连接器。车机振动环境下，普通的USB座、SD卡座非常容易接触不良，导致外设掉线。我建议在样机阶段就用带锁扣的航空接头或者车规级连接器，并做振动测试，否则后期返工很痛苦。

6. 常见问题速查与避坑清单

6.1 高频问题与排查思路

这几年在社区和实际项目里，被问得最多的问题可以整理成一张速查表。遇到类似情况的时候，按表里的思路排查，多半能快速定位。

6.2 我的选型决策自检表（五问法）

选型到最后，我都会用五个问题做一次自检，任何一块板卡只要有一项不过关，就直接Pass。

第一问：工作温度范围和供电环境是什么样？如果设备在户外暴晒或者车舱内使用，必须确认芯片和整机在极限温度下的稳定性，不能只看常温测试数据。

第二问：感知决策管线的端到端延迟预算是多少？把控制频率、执行机构延迟算进去，反推感知部分能占多少毫秒，再对照实测数据，看留没留余量。

第三问：主力模型INT8量化后，在目标平台上实测多少毫秒？这个数据必须自己跑出来，不能看官网或者评测文章的数字，因为模型的算子结构、输入尺寸、并发路数都会影响结果。

第四问：内存带宽和内存容量能不能支持未来半年的模型迭代？如果大概率要上大模型，内存至少预留一倍余量，带宽要当作硬性指标考核。

第五问：供应商的工具链、社区和二次开发资料，能不能支撑团队现有的研发节奏？工具链不成熟的产品，即使性能再强，也容易把项目拖垮。

这五问看起来简单，但每一条都是真金白银换来的教训。很多项目翻车，不是算力不够，而是在选型阶段忽略了其中某一个维度。

最后分享一个我自己的习惯。拿到任何一块新的端侧算力板卡，我不会先跑全家桶benchmark，而是固定把YOLOv5s、MobileNetV3、一个1.5B的量化语言模型轮着跑一遍，然后直接接上真实传感器和电机控制器，在整车上连续跑三天。跑分是给人看的，能稳定扛住整车环境、还能留出调试余量的板卡，才是真正适合具身智能的硬件。希望这份避坑指南能帮你少花一笔冤枉钱。