机器人本地跑大模型：RK3588/3568嵌入式主板硬件选型指南

这几年总有人问我：机器人到底要不要在本地跑大模型？我一般不会直接给答案，而是先反问一句：你的机器人断网之后，还能不能正常干活？

这个问题背后，是机器人行业正在发生的一轮真实变化。过去机器人项目的智能决策基本放在云端，本地主板的职责就是跑运动控制、传感器采集、视觉识别这类确定性任务。但大模型LLM的能力越来越强之后，很多团队开始把自然语言理解、任务拆解、多轮对话甚至语义导航直接塞进机器人本体。于是问题就来了：一台机器人要在本地跑LLM大模型，对主板硬件到底有什么硬性要求？

这篇文章就以瑞迅科技的RK3588与RK3568两代嵌入式主板方案为参照，把端侧跑LLM涉及的硬件选型逻辑讲透。包括CPU、NPU、内存带宽、存储、外设资源这些核心指标分别影响什么，两颗芯片到底差在哪，以及一套从模型选型到板卡落地的实操路径。如果你正在做ROS2机器人、服务机器人或巡检机器人，也在纠结“本地到底能不能跑大模型”，这篇文章应该能帮你省下不少踩坑时间。

1. 机器人本地跑LLM，到底划不划算

1.1 为什么机器人团队开始考虑端侧大模型

机器人本体跑大模型，最直接的动机通常来自三个场景。

第一个场景是延迟敏感。机器人不像手机聊天，用户说一句“去把桌上的杯子拿过来”，语音识别、意图理解、任务规划、路径下发需要在一个可控时间内完成。如果每一步都走云端，往返延迟至少几百毫秒，再叠加网络抖动，整体响应可能超过两三秒，这对交互式机器人是不可接受的。更别提执行环节里实时避障、动态调整这类毫秒级决策，根本不能依赖外部网络。

第二个场景是环境依赖。很多机器人部署在厂房、仓库、园区、地下空间，网络覆盖并不理想。一台AGV在货架通道里突然断网，本地没有推理能力就只能停车等待，整个产线跟着停滞。端侧LLM的价值不在于替代云端大模型，而是确保在断网、弱网环境下机器人仍然具备基础的语义理解和决策能力。

第三个场景是隐私与成本。机器人采集到的图像、语音、轨迹数据一旦上传云端，就涉及数据合规问题，尤其是医疗、教育、政企类项目。本地推理让数据封闭在设备内部，省掉了云端传输和存储的成本。从长期运营看，如果一台机器人每天要调用上万次云端接口，推理费用会非常可观，而端侧方案是一次性硬件投入。

这些因素叠在一起，机器人团队开始认真评估“本地跑LLM”的可行性。但本地跑大模型从来不是软件层面加一个Python依赖那么简单，硬件的每一项指标都在限制你能跑多大参数量、跑多快、并发撑不撑得住。

1.2 端侧大模型能做什么、不能做什么

说实话，现阶段机器人端侧能跑的LLM，和ChatGPT那种千亿参数的大模型完全不是一个量级。端侧更现实的目标是：用1B到4B参数的量化模型，完成“语言理解+任务控制”这一类确定性较强的工作。

能做的事情包括：

• 自然语言指令解析：把“去充电桩充电”拆解成导航目标点，把“把机械臂抬到传送带上方”转成轨迹规划指令。
• 多轮对话与状态问答：配合语音模块，做一个能回答设备状态、报警原因、操作步骤的本地语音助手。
• 结构化输出：让模型直接输出JSON格式的控制指令，比如{"action": "navigate", "target": [3.2, 1.8], "speed": 0.5}，这样下游控制程序可以直接消费。
• 意图分类与槽位抽取：即便不跑全量生成式对话，用LLM做意图识别也比传统BERT类模型更自然，泛化能力更强。

不能做或者做不好的事情也很清楚：复杂长程推理、大规模知识问答、高质量开放域对话，这些都需要数十亿以上参数配合海量知识，本地板卡跑不动也不值得硬跑。另外，如果任务本身只需要固定分类，比如判断前方是“人”还是“货架”，传统视觉模型比LLM更快更省。

所以我的看法是，端侧LLM应该定位成机器人的“副脑”或“技能触发器”，接替的是原本需要规则引擎和意图分类器完成的那部分工作，而不是要把整个AGI塞进主板。

2. 把LLM装进主板之前，先搞清楚这6个硬件指标

2.1 CPU：LLM的“搬运工”，不仅看核数更要看内存带宽

很多人选型时只看CPU核心数，认为8核一定比4核好，这个直觉在跑LLM时并不完全成立。

大模型推理是一个典型的内存带宽瓶颈型任务。每次生成一个token，都要把模型权重从头到尾扫一遍。以1.5B模型INT4量化为例，权重约1GB，每生成一个token内存系统至少要吞吐1GB以上的数据。这时候CPU的算力反而不是第一瓶颈，内存带宽往往先被吃满。你可以把这个过程想象成查字典：CPU是大脑，内存带宽决定你翻页的速度，如果翻页慢，脑速再快也白搭。

具体到两个平台，RK3588的四颗Cortex-A76大核明显强于RK3568的四颗A55小核。A76是高性能大核，单核性能大约是A55的2到3倍，这对逐token生成的decode阶段影响很大。而且RK3588支持LPDDR5，内存带宽比RK3568支持的LPDDR4X高不少。实测中，同样的1.8B量化模型，RK3588上生成速度能比RK3568快一倍以上，差距基本就来自CPU核心规格和内存带宽这两项。

2.2 NPU：端侧推理的胜负手，但别只看TOPS

NPU是嵌入式平台加速神经网络推理的专用单元，RK3588标称6TOPS算力，RK3568只有1TOPS左右，看起来差距很大，但TOPS这个数字有迷惑性。

TOPS代表理论峰值算力，实际能用出多少取决于三点：模型算子是否被NPU支持、量化精度是否匹配、工具链是否成熟。比如有些平台宣传的TOPS很高，但你想跑的LLM算子恰好不在支持列表里，实测速度甚至不如CPU。反过来，一些老旧的GPU或NPU在INT4量化模型上支持不好，被迫跑FP16，效率大打折扣。

对机器人项目来说，我建议把NPU当成“加分项”而不是“必须项”。RK3588可以通过瑞芯微的RKLLM组件在NPU上跑部分小型LLM，但目前的算子覆盖面还比不上CPU方案灵活。更多团队的实际路径是先用llama.cpp在CPU上跑通GGUF量化模型，后续再迁移到NPU优化。如果项目周期紧，不要赌NPU对目标模型的兼容性，CPU方案最稳。

2.3 内存：模型放得下，对话才能跑得起来

内存容量是决定“能否跑”的硬门槛。公式很简单：模型权重 + KV Cache + 运行时开销 + 机器人其他进程，全部加起来不能超过物理内存，否则就是Kernel杀进程或者OOM崩溃。

粗略估算一下：1.5B模型INT4量化权重约1GB，开2K上下文大概还要几百MB的KV Cache，加上ROS2、视觉节点、导航节点占用2到3GB，整机建议至少8GB起步。如果目标模型是3B到4B，INT4权重约2.5GB左右，加上系统其他进程，16GB内存会更从容。32GB预算充足的话，可以留给未来模型升级。

内存类型同样重要。RK3588支持LPDDR4X和LPDDR5，其中LPDDR5的频率更高、带宽更大，实测跑LLM时token生成速度有明显提升。RK3568最高支持LPDDR4X，带宽上限较低，就算把模型缩小到0.5B，生成速度也有限。这也是为什么我更倾向于用RK3588做端侧LLM主力的原因，内存带宽决定了上限。

2.4 存储与接口：机器人外设才是隐藏的门槛

很多做软件出身的朋友选主板，只看CPU和内存，忽略了存储和接口，结果买回来发现摄像头接不上、CAN总线没有、串口数量不够，整个机器人底盘根本控制不起来。

存储方面，模型文件本身动辄1到5GB，加上系统镜像、日志、地图数据，64GB eMMC勉强够用，128GB或以上更稳妥。如果有大量视觉数据要缓存，NVMe SSD是值得选的配置，RK3588支持PCIe 3.0，可以接NVMe固态盘，加载模型和冷数据时快很多。

接口资源是机器人和普通开发板最大的区别。机器人底盘一般需要CAN总线连接电机驱动和IMU，需要多路UART接激光雷达、GPS、传感器，需要USB 3.0接深度相机，需要千兆以太网接上位机或交换机，还可能用到GPIO控制报警灯、继电器。选型时一定要把外设清单拉出来，对照主板的接口资源逐项核对，缺一个CAN口可能导致整个载板方案重做。

2.5 功耗、散热与环境耐受：产品化阶段最容易翻车

实验室里用开发板跑模型，坏了就重启；但到了产品阶段，一台在户外巡检的机器人可能顶着太阳连续工作8小时，主板如果散热设计不足，高温降频会让LLM推理速度骤降，甚至触发保护关机。

RK3588满负荷功耗不低，四颗A76大核跑满再加上NPU同时工作，整板功耗可能超过15W，必须考虑主动散热或大尺寸散热片。瑞迅这类方案商的问题在于，整机设计和散热结构是否成熟，整板有没有做过温度曲线测试。另外，工业机器人经常面临振动、宽温、电源波动，主板是否支持宽压输入、是否带防反接和过流保护，这些都是产品化必须过问的细节。

2.6 生命周期与供货能力：选型不是选完就跑

最后一条，也是最容易被个人开发者忽略的。机器人产品从原型到量产往往要一两年，主板方案如果频繁改版、芯片停产、供货不稳，整个项目会陷入极大的被动。瑞芯微平台本身生命周期比较长，但具体到方案商的设计能力、备料策略、软件维护周期，都需要在选型阶段就问清楚。这也是为什么很多团队宁愿选瑞迅这类有工控背景的方案商，也不自己去画板，因为BSP适配、量产交付、长期供货这些坑，远比跑通一个Demo模型复杂。

3. RK3588与RK3568深度对比：一颗旗舰一颗够用

3.1 RK3588规格拆解：为什么它成了端侧LLM的“甜点位”

RK3588是瑞芯微目前面向边缘AI的旗舰级SoC，硬件配置相当能打：

• CPU：4核Cortex-A76@2.4GHz + 4核Cortex-A55@1.8GHz，大小核架构。
• GPU：Mali-G610 MP4，支持OpenGL ES 3.2、Vulkan，可以辅助推理。
• NPU：6TOPS@INT8，3个独立NPU核心，支持INT4/INT8/INT16混合量化。
• 内存：支持LPDDR4/LPDDR4X/LPDDR5，最高32GB。
• 存储：eMMC 5.1、支持SATA、PCIe 3.0 NVMe。
• 接口：双千兆以太网、USB 3.1、HDMI/DP、MIPI-CSI/DSI、CAN、多路UART/SPI/I2C/GPIO。

这套配置放在机器人主板上非常均衡。四颗A76大核对LLM的decode阶段很关键，6TOPS NPU可以分担视觉模型推理，最高32GB LPDDR5又给大参数模型留出了余地。加上视频编解码支持和丰富的显示接口，一台机器人主板上既能跑LLM，也能跑视觉SLAM，还能同时输出多路摄像头画面，真正实现了“一板多能”。

在我接触的端侧LLM项目里，RK3588其实是最容易跑出实际效果的平台之一。资源不算顶配，但恰恰因为均衡，很多模型转换工具和推理框架都对它做了适配，踩坑成本低。

3.2 RK3568规格拆解：低功耗场景的务实选择

RK3568定位是主流性价比平台，规格明显低一档：

• CPU：4核Cortex-A55@2.0GHz。
• GPU：Mali-G52，显示能力足够，算力有限。
• NPU：1TOPS@INT8。
• 内存：最高支持8GB LPDDR4/LPDDR4X。
• 存储：eMMC 5.1、SATA、PCIe 3.0。
• 接口：千兆以太网、USB 3.0、CAN、多路UART。

RK3568不太适合跑生成式LLM，但并不是没有用武之地。如果任务只是意图识别、关键词提取，或者跑的是0.5B~0.6B级别的超小模型，RK3568依然能做一个轻量级的本地语义节点。更常见的设计是把RK3568用作运动控制板或者传感器采集板，把LLM推理放在RK3588主板上，两者通过Ethernet或CAN通信。

这里忍不住多说一句，即便拥有1TOPS NPU，也建议开发者在RK3568上优先考虑传统基于BERT或TextCNN的文本分类方案。对于固定领域的意图识别，BERT模型只有几百MB，推理速度快，语义理解效果完全够用。生成式LLM在3568上的体验是“能跑但用起来受罪”，token一秒蹦一两个，交互体验实在谈不上好。

3.3 一张表看懂两个平台对LLM场景的支持差异

4. 瑞迅科技RK3588/3568方案选型解析

4.1 从机器人产品化角度看待主板厂商的价值

很多开发者觉得，芯片规格摆在那里，买谁家的开发板不都一样？实际上从芯片到可用主板，中间还隔着PCB设计、电源管理、散热结构、接口布局、BSP适配、认证测试这一长串工作。瑞迅科技这类方案商的价值，就在于把这些工程化问题提前解决。

以瑞迅围绕RK3588和RK3568做的方案为例，我关注几个点。第一是板型设计，比如PICO-ITX或3.5寸紧凑板型，适合直接嵌入机器人内部，而不是实验室里那种带一堆排线和杜邦线的评估板。第二是接口资源，机器人常用到的多路CAN、RS485、宽压电源输入，这些在标准开发板上往往需要额外扩展，但在工规主板上应该直接板载。第三是工业级可靠性，包括宽温、抗振、ESD防护、浪涌保护，这些参数决定了产品在客户现场的使用寿命。

另外，方案商的技术支持能力也要纳入考量。跑LLM不是插上电就能跑，底层需要适配特定版本的NPU驱动、工具链和推理框架。瑞恒微官方RKLLM组件是否被完整移植、BSP是否持续更新，都是直接影响开发效率的因素。选择有Deep本地化支持能力的方案商，比单纯买便宜板子重要得多。

4.2 核心板还是整板？不同结构形式的选型考量

瑞迅这类厂商往往提供多种结构形态，常见的有三种：

我的建议是，项目早期先用整板或开发板把算法跑通，重点验证LLM在目标硬件上的真实速度和稳定性。等到产品需求明确、接口清单定了，再基于核心板设计自己的载板。这样既有灵活性，又不会在原型阶段被硬件问题拖住。

这里要给初次接触的团队提个醒：一定要在Demo阶段就使用与量产接近的主板形态。我见过不止一个项目，开发阶段用大板子跑得好好的，换到量产小板上因为散热空间不足导致降频，LLM推理速度掉了一半。越早验证真实硬件环境，后面越少返工。

4.3 基于瑞迅方案的两种典型机器人LLM架构

架构一：单板全能型。以瑞迅RK3588主板为整机主控，同时承担LLM推理、语音处理、视觉感知和底盘控制。这种架构适合交互型服务机器人，硬件拓扑简单，成本更集中。AK3588上可以同时挂麦克风阵列、摄像头、激光雷达和电机驱动板，系统资源分配给LLM推理、ROS2节点和视觉SLAM三方，内存建议直接上16GB以上。

架构二：主从协同型。RK3588主板作为“大脑”，负责LLM、全局规划和视觉理解；RK3568主板作为“小脑”，负责实时运动控制、传感器采集和关节驱动。二者通过Ethernet或CAN总线通信。这种架构适合巡检机器人和复合机械臂，因为运动控制实时性要求高，不能和LLM推理抢占CPU资源；RK3568的低功耗特性也适合靠近传感器和执行器部署。

两种架构没有绝对优劣，主要看机器人形态和任务复杂度。设计时把通信链路画清楚，把不同任务的实时性门槛写明白，再决定哪些算法放在哪个处理器上，才是关键。

5. 在RK3588上跑LLM的实操记录

5.1 环境准备与编译llama.cpp

纸上谈兵这么多，还是要落到实际操作。我自己在瑞迅RK3588主板上跑通LLM的路径是这样的。

系统层面，我推荐使用官方或瑞迅适配的Ubuntu/Debian桌面系统，内核版本不用太新，稳定优先。确认系统识别到8GB以上内存之后，先安装基础编译工具：

sudo apt update && sudo apt install -y git cmake build-essential

然后拉取llama.cpp源码编译。这里有一点要注意，默认的构建可能没有启用适用于ARM平台的优化，建议手动指定：

git clone https://github.com/ggerganov/llama.cpp cd llama.cpp cmake -B build -DCMAKE_BUILD_TYPE=Release -DLLAMA_NATIVE=OFF cmake --build build -j$(nproc)

编译完成后，可以用./build/bin/llama-cli来加载GGUF模型。我的习惯是先跑一个1.5B模型验证整个链路，避免一上来就加载3B以上模型把内存吃满导致系统卡死。下载模型可以用Hugging Face上的GGUF版本，比如Qwen2-1.5B-Instruct的Q4_K_M量化文件，文件大小大概1GB左右，放在NVMe或eMMC上都能接受。

5.2 用量化模型实测推理效果

加载模型并生成一段文本的示例命令如下：

./build/bin/llama-cli -m models/qwen2-1.5b-instruct-q4_k_m.gguf \ -p "把以下指令解析为JSON: 去坐标点3.2,1.8，速度0.5" \ -n 64 -t 4

这里-n 64表示生成最多64个token，-t 4表示使用4个线程。在RK3588上，我有意只用4个线程，因为这正好对应四颗A76大核，避免把任务调度到A55小核上拖慢速度。

实测下来，1.5B Q4模型在纯CPU推理下，生成速度大致在5到15 token/s之间。这个区间受内存类型、系统负载和固件调度影响很大，但无论如何，单次指令解析和短对话的等待时间可以控制在两三秒内，对机器人交互来说是可以接受的。

如果追求更高速度，可以考虑瑞芯微官方的RKLLM组件，它能利用NPU对支持的模型做加速。部分公开示例显示3B模型在RK3588上能跑到10token/s以上，但代价是需要在模型转换阶段做好算子兼容性验证。我建议先把CPU方案跑通，再评估是否值得投入NPU适配。

5.3 让LLM接上ROS2的控制链路

跑通单机对话只是第一步，机器人项目里LLM一定要和控制闭环联动。我常用的做法是写一个ROS2 Service节点，把LLM封装成可被调用的服务，输入是自然语言指令，输出是结构化的控制指令。

Python节点大致长这样：

import rclpy from rclpy.node import Node from std_srvs.srv import Trigger import subprocess import json class LLMQueryService(Node): def __init__(self): super().__init__('llm_query_service') self.srv = self.create_service(Trigger, 'llm_query', self.query_callback) self.publisher = self.create_publisher(String, 'cmd_vel_text', 10) def query_callback(self, request, response): prompt = request.message if hasattr(request, 'message') else "go forward 1m" result = self.run_llm(prompt) parsed = json.loads(result) self.publisher.publish(String(data=json.dumps(parsed))) response.success = True response.message = result return response def run_llm(self, prompt): cmd = ["/path/to/llama-cli", "-m", "/path/to/model.gguf", "-p", prompt, "-n", "64", "-t", "4", "--no-display-prompt"] return subprocess.check_output(cmd, text=True).strip()

这个节点只是示例，但思路很清晰：LLM负责把自然语言翻译成结构化指令，下游导航或运动模块只消费JSON。这样即使更换模型或者调整prompt，控制链路完全不用改。真正产品化时，建议用更稳定的llama-server而不是每次启动子进程，并做好请求排队和超时管理。

实测跑下来，RK3588结合1.5B模型做指令解析，从语音识别结果输入到控制指令发布，端到端延迟在2到4秒。对于非紧急的导航指令、状态查询类交互，这个延迟可以接受；如果需要毫秒级响应，LLM就不是正确工具，应该回到规则引擎或直接传感器联动。

6. 选型避坑与常见问题速查

6.1 我踩过的坑和选型建议

第一个坑是只看TOPS选平台。早期我也觉得RK3588的NPU这么强，跑LLM不是轻松加愉快？实际RKLLM对模型的支持列表、量化格式、上下文长度都有要求，有些模型转换下来算子不支持，最后还是回到CPU推理。后来我学乖了，任何平台都先跑一遍llama.cpp验证基线性能，再谈NPU优化。

第二个坑是内存容量卡太死。我试过用8GB内存的板子跑3B量化模型，模型加载进去系统还剩2GB，ROS2节点一启动就卡成PPT，最后OOM重启。如果预算允许，RK3588直接选16GB以上，给KV Cache和视觉节点留够余量。8GB版更适合只跑1.5B以下模型或做传统视觉。

第三个坑是在RK3568上硬跑生成式LLM。0.5B模型虽然能跑，但每秒钟蹦两三个字，交互体验很难受，团队成员用了几天就没耐心了。后来我们把RK3568改作运动控制板，只跑传统文本分类，体验立刻变得顺滑。有些任务是“非LLM不可”，但更多任务是“传统方法更合适”，选型时一定要回到需求本身。

第四个坑是散热和供电没提前设计。RK3588满负荷跑LLM时发热明显，如果整机做小体积无风扇设计，必须提前规划散热片和风道。供电方面，电机驱动和主控共用一个电源时，电压跌落可能让主板重启，我建议用宽压输入主板加隔离模块，把动力电源和逻辑电源分开。

6.2 常见问题速查表

这些坑在项目开发里几乎都会遇到，提前知道至少能节省几周调试时间。把硬件选型和软件调试放在一起考虑，而不是分阶段各做各的，是我这几年最深的体会。

最后说点掏心窝的话。做机器人端侧LLM这件事，最难的不是模型，也不是主板，而是想清楚“哪一部分智能必须留在本地”。我的经验是：从最容易被在线能力限制的痛点出发，比如断网下的语音交互、关键指令的快速响应，先用RK3588这类板卡配上1.5B到4B的量化模型跑通一个端到端Demo，再做选型和量产。平台本身不是瓶颈，选型过程中的认知差往往才是。