机器人上跑本地大模型这件事最近半年被问到的频率明显高了起来。很多人一上来就问RK3588和RK3568到底选哪个然后紧接着第二句就是NPU是6TOPS还是0.8TOPS。老实说如果你只盯着TOPS做选型大概率会在样机阶段就翻车——机器人本地跑LLM大模型对主板硬件的要求真正卡脖子的往往不是算力峰值而是内存带宽、内存容量、持续散热能力和NPU的资源调度。我自己上手调过几套方案也见过不少团队拿着一块接口很漂亮的板子结果模型加载进去了、对话也能出字但一问三不知或者聊两句话就开始卡顿掉帧。这篇就把机器人本地LLM这条链路拆开从硬件账本讲到RK3588、RK3568这两套主流方案各自的位置把选型逻辑和部署踩坑一次说透。适合正在做机器人主控选型的硬件工程师、做端侧AI落地的算法同学以及想搞清楚本地大模型到底需要什么样的板子的产品负责人。1. 先把机器人本地跑LLM拆成可量化的硬件需求1.1 从交互链路倒推一次对话里硬件到底在忙什么机器人上跑LLM绝大多数场景不是让它写代码或者做长文摘要而是做一个能听懂话、能决策、能回话的交互与任务中枢。这条链路通常是麦克风阵列拾音 → 唤醒词检测 → 本地ASR语音转文字→ LLM做意图理解与回复生成 → TTS文字转语音→ 扬声器输出同时LLM还可能要把结构化指令发给运动控制或视觉模块。硬件在这条链路上承担的压力是脉冲式的。拾音和唤醒长期占用极少的CPUASR是一次几十到几百毫秒的突发计算LLM的推理则是典型的两段式负载——你按下说话结束的那一刻GPU或NPU要先把整段prompt吃进去prefill阶段算力密集然后一个token一个token往外吐decode阶段访存密集TTS再吃一波。一次交互的总延迟用户能容忍的舒适区间大概在1.2秒到2秒之间超过2.5秒就会明显觉得这机器人在发呆。把这个预算拆开你会得到一组很硬的约束ASR预留300毫秒TTS预留200毫秒留给LLM的大概只有600到1000毫秒。如果模型吐字速度只有3 token/s而一句回复平均需要30个中文字符约40个token光生成就要13秒交互体验直接归零。所以token/s这个指标比TOPS重要得多它是选型的第一把尺子。1.2 参数量、量化位宽与内存账本大模型在端侧跑权重全部要装进内存这是最基础的一笔账。粗略估算公式是权重占用GB ≈ 参数量B × 位宽bit ÷ 8按这个公式1.5B参数的模型在INT8下约1.5GBINT4下约0.9GB3B模型INT8约3GB、INT4约1.8GB7B模型INT8要7GB、INT4也要3.8GB左右。这还没算KV Cache——也就是对话上下文缓存。KV Cache的大小跟层数、KV头数、上下文长度成正比1.5B级别模型在4K上下文下通常占用100MB到200MB7B级别在同样上下文下能吃掉1GB以上。把这些叠加起来一块8GB内存的板子跑3B INT4模型加上系统和中间件空间已经相当紧张跑7B基本就是能加载、不能聊。而机器人主板本身还要跑ROS2节点、相机采集、SLAM、通信中间件这些进程会稳定吃掉1.5GB到3GB。所以内存容量不是够装下模型就行要留出至少2GB的系统余量否则进程被OOM Killer干掉的时候你会以为是程序写错了。1.3 内存带宽决定token/s天花板的那条横线这是最容易被忽略、也最致命的一环。LLM的decode阶段每生成一个token都要把全部权重从内存里读一遍自回归特性决定的。所以理论token/s上限可以这样估内存实际带宽GB/s ÷ 每token需要读取的权重体积GB ≈ 理论token上限举个例子1.5B模型INT8量化后权重1.5GB如果板子的实际可用内存带宽是15GB/s那理论上限就是10 token/s。你NPU再强、TOPS再高decode阶段也突破不了这条线。这就是为什么端侧LLM的优化重点在量化位宽和内存带宽而不是堆算力。对机器人选型来说这条结论非常实用想让1.5B模型跑到15 token/s以上权重得压到INT4同时板子得是双通道LPDDR4x/LPDDR5。单通道或者低频LPDDR4的板子就算标称算力相同实际吐字速度可能只有一半。2. RK3588的硬件底牌逐项对上LLM的口味2.1 三丛集CPU与内存子系统的真实手感RK3588这套平台是4×Cortex-A76最高约2.4GHz 4×Cortex-A55约1.8GHz的三丛集架构配Mali-G610 MP4 GPU制造工艺8nm。把它放到LLM场景里看CPU的角色其实比很多人想象的重要——prefill阶段、采样逻辑、tokenizer、prompt拼接、以及NPU不支持的算子全都要靠CPU兜底。实测下来的感受是A76大核对首字延迟影响明显。同样是1.5B模型把推理线程绑到A76上首字延迟能比全丢给小核快出一半以上但大核跑满时功耗和发热也上得很快机器人外壳如果没有做导热设计几分钟后就会触发降频性能曲线开始往下掉。我的做法是prefill用大核冲长时间decode阶段适当让它跟小核分摊用taskset绑核配合DVFS调频反而能拿到更稳的长跑表现。内存子系统是RK3588相对3568最大的优势。它支持LPDDR4/4x/5双通道32位实际带宽在十几个GB/s这个量级。对LLM来说这就是前面那条token/s天花板抬高的直接来源。选型时一定要问清楚板子用的是LPDDR4x还是LPDDR5、跑在什么频率上同样叫RK3588这两个配置的实测吐字速度能差20%以上。2.2 6TOPS NPU能干什么、不能干什么RK3588的NPU标称6TOPSINT8内部是三个独立核心可以并行调度。这对LLM来说是个好消息主流做法是把LLM的矩阵乘部分丢给NPUCPU只负责调度和采样。1.5B级别的模型在NPU上跑配合W8A8或者W4A16量化实测能到十几到二十个token/s的数量级具体取决于量化方案、散热和上下文长度不同板子差异不小。但NPU有明确的边界这里必须说清楚否则会踩坑算子支持是有限的。动态shape、某些注意力变体、非常规激活函数都可能被拒绝或者退化成CPU执行一退化速度就断崖式下跌。上下文长度影响显存式占用。NPU侧也要缓存KV长上下文会显著拉低速度4K以上要谨慎评估。三个核心不是无限并发的。大模型推理本身会尽量占满这时候你要同时跑YOLOv8做视觉检测就得排队。2.3 内存容量怎么选8GB起步、16GB够用、32GB为并发留后手这是选型里最实际的一刀。按我自己的经验可以这样划内存适合的模型规模典型场景注意事项8GB0.5B~1.5B INT4单一语音交互、指令解析系统余量紧张别开太多视觉任务16GB1.5B~3B INT4/INT8语音视觉导航并行推荐甜点配置性价比最高32GB3B~7B INT4、多会话多模态、长上下文、多路并发散热和供电要同步升级16GB是我最常推荐的档位原因很直接它能把系统中间件3B INT4模型KV Cache一路视觉检测全塞进去而且还有余量应对突发。32GB版本的价值主要体现在两个地方一是跑7B模型或者多模态视觉编码器本身要占内存二是需要维持长上下文或者多轮并发会话。如果你的机器人只是做语音问答和任务规划32GB大概率是浪费但如果要做边看边说的多模态交互那这笔钱省不下来。3. RK3568的位置它不是LLM主板但它是机器人主板的另一半3.1 0.8TOPS与4×A55的真实边界RK3568是4×Cortex-A55最高约2.0GHz Mali-G52 0.8TOPS NPU的组合。单从LLM角度看它的能力边界很清晰NPU基本帮不上大模型的忙只能靠CPU硬扛而4个A55的算力和内存带宽都不够。我实际测过在RK3568上跑0.5B级别的INT4小模型勉强能出字但速度在个位数token/s以下且CPU占用接近满载板子温度上升很快这时候其他业务基本别想跑了。1.5B级别就算内存装得下速度也没法支撑真实对话交互。所以如果有人问RK3568能不能跑LLM我的回答是能加载、能演示但不适合作为机器人产品的交互主脑。它的NPU不是没用只是定位在别处——跑轻量分类、人脸检测、关键词唤醒、小型视觉模型0.8TOPS是够的。把它用在正确的任务上它的能效比其实相当好。3.2 RK3568的强项在工业接口与实时性RK3568真正的价值在于接口丰富度和工业属性。它通常带双千兆网口、多路CAN、多路UART、PCIe、SATA、大量GPIO和PWM非常适合做运动控制、执行器驱动、传感器汇聚和通信网关。很多做机器人底盘的团队会在它上面跑带实时补丁的内核把EtherCAT主站跑起来控制周期做到1毫秒甚至更低。这一点非常关键LLM是慢思考运动控制是快反射这两件事本来就不该塞在同一颗芯片上抢资源。你在RK3588上跑大模型的时候NPU和内存带宽都被啃掉一大块如果运动控制也在同一颗芯片上一旦GC或者模型加载导致周期抖动机械臂可能就直接抖出去几毫米。把实时控制隔离出去是工程上最稳妥的做法。3.3 35883568双芯架构的分工与通信于是就有了我认为目前最合理的一种机器人主板组合RK3588做上层智能RK3568做下层实时控制。RK3588负责语音链路、LLM推理、视觉感知YOLOv8目标检测、视觉SLAM、任务规划、人机界面、网络通信。RK3568负责电机与执行器控制、EtherCAT/CAN总线主站、IO采集、安全逻辑、急停回路。两者之间用千兆以太网或者高速串口通信跑一套轻量的自定义协议或者直接用ROS2的DDS跨主机通信。这里有个实操细节值得强调跨芯片通信的消息设计要以指令为单位不要以原始数据为单位。让RK3588下发移动到坐标(x,y)这样的高层指令由RK3568在本地做轨迹插补和闭环控制而不是让3588每毫秒发一次位置设定值——后者的网络抖动和调度延迟会直接变成控制误差。4. 按机器人产品形态做选型四类典型场景的对照4.1 语音交互型桌面、陪伴、导览机器人这类产品的核心诉求是能聊天、能应答、响应快视觉需求很轻最多做个人形检测或者人脸识别。模型通常选1.5B到3B级别的中文对话模型INT4量化。推荐配置RK3588 16GB LPDDR4x 64GB eMMC单板方案即可。NPU大部分时间给LLM空闲时跑一个轻量人脸检测。散热用一块铝制散热片加小风扇或者直接靠外壳做传导散热。这个组合能做到1.5秒以内的端到端响应体验是能接受的。如果预算非常紧张可以考虑RK3568 云端协同但要接受离线不可用这个前提。纯靠RK3568本地跑模型我不推荐。4.2 移动操作型AMR、AGV、复合机器人这类场景的硬件压力最大视觉SLAM要一直跑可能还有激光雷达点云处理同时要接入LLM做任务理解还要有实时控制。推荐配置RK3588 16GB/32GB NVMe存储另配RK3568或专用MCU做实时控制。关键点是NPU的分时复用策略SLAM和检测模型是持续负载LLM是突发负载两者会抢NPU。我的做法是把SLAM放在CPUGPU上跑RK3588的Mali-G610做特征提取和稠密建图其实挺够用把NPU尽量留给LLM和检测模型避免三方互抢。4.3 视觉引导型机械臂上料、质检、分拣这类场景LLM的角色偏弱主要是做自然语言指令解析和异常说明真正吃算力的是视觉。RK3588跑YOLOv8这类模型很轻松可以做到几十帧同时还能留出一部分NPU给1.5B小模型做交互。RK3568在这个场景里可以独立承担一个工位的视觉前端成本更低。4.4 选型对照表维度RK3568RK3588CPU4×A55 2.0GHz4×A76 4×A55NPU0.8 TOPS6 TOPS三核内存LPDDR4/4x常见2~8GBLPDDR4/4x/5常见8~32GB本地LLM实用上限0.5B级演示不适合产品化交互1.5B~3B实用7B可试但体验受限实时控制强项接口丰富适合跑EtherCAT/CAN可以跑但会被AI任务干扰不推荐独担典型定位运动控制、IO网关、视觉前端智能中枢、语音交互、视觉主算力成本低中高一句话总结这张表RK3568是手脚RK3588是大脑。想用一颗芯片兼顾两者通常会在某一头妥协。5. 从模型到板子部署链路上最容易翻车的几个环节5.1 量化方案W8A8、W4A16与混合量化怎么挑量化是端侧LLM的第一道关。常见选项有这么几类W8A8权重8位、激活8位精度损失最小速度稳定但权重体积大对内存带宽压力大。1.5B模型在RK3588上跑W8A8吐字速度大概在十几token/s这个量级。W4A16权重4位、激活16位权重大幅压缩带宽压力骤降速度提升明显但精度会有可见下降尤其是在需要精确数值推理、结构化输出比如生成JSON指令的场景里容易出错。混合量化把对精度敏感的部分比如第一层、最后一层、Embedding保留高精度其余压到4位。这是目前端侧最实用的折中方案。我的实际经验是如果机器人要输出结构化指令给控制系统别一上来就W4A16。先跑W8A8看看指令正确率再试混合量化最后才考虑全4位。因为一次错误的指令解析代价可能远大于那点速度收益。5.2 模型转换与runtime的实操细节以RK3588为例典型流程是在x86主机上用工具链把HuggingFace格式的模型转成RKNN/RKLLM格式配置量化参数然后拷贝到板子上用runtime加载。大致的操作链路是这样# 在开发主机上做量化与转换示意 python convert.py \ --model_path Qwen2-1.5B-Instruct \ --quant_type w8a8 \ --target_platform rk3588 \ --output qwen2-1.5b-w8a8.rkllm # 拷到板子上运行 scp qwen2-1.5b-w8a8.rkllm rootrobot:/data/models/ ./llm_demo /data/models/qwen2-1.5b-w8a8.rkllm 4096 4096这段流程里最容易出问题的地方有三个。第一是量化校准数据集如果用的是一堆英文语料中文输出质量会明显塌陷一定要用贴近业务场景的中文样本最好就是你机器人实际会遇到的那类指令。第二是上下文长度参数配置得太大会让内存占用暴涨配置得太小会在多轮对话里被截断建议按实际业务的最长对话轮次来定。第三是tokenizer和chat template模板不匹配会导致模型答非所问这类问题看起来像模型能力不行实际上是格式问题。部署完成后我建议第一时间做两件事用脚本压测连续对话观察内存是否随时间缓慢上涨有没有泄漏同时读NPU和温度的节点cat /sys/kernel/debug/rknpu/load cat /sys/class/thermal/thermal_zone*/temp前者能告诉你三个NPU核的实际占用后者能告诉你什么时候开始降频。5.3 NPU抢占LLM和视觉模型不能只顾自己这是机器人场景特有的坑。桌面场景里LLM独占NPU没问题但机器人上通常还要跑检测、分割、SLAM。当LLM在做prefill、NPU满载的时候检测模型的帧率会掉如果这个检测结果被用来做避障掉帧就意味着安全隐患。几个可行的处理方式一是时间分片让LLM只在收到语音唤醒后才强占NPU其余时间让给视觉二是空间分片用NPU的三个核做物理隔离一个核给LLM一到两个核给视觉这个能力在RK3588上是有的值得用起来三是降级策略当检测帧率低于阈值时主动降低LLM的并发或者切到更小的模型。这些策略听起来简单但需要在系统设计阶段就规划好临时打补丁很难做干净。5.4 供电、散热与DVFS长跑稳定性的隐形杀手机器人是电池供电电压会随电量下降而波动。RK3588在NPU满载的瞬间电流冲击不小如果电源设计余量不足会出现一种非常难查的现象模型跑到一半突然重启或者NPU报错。我用示波器抓过这种情况满载瞬间的电压跌落相当可观。所以供电建议留出至少30%的余量核心电压轨的电容要足别用那种能点亮就行的最小设计。散热方面RK3588在NPU持续满载时功耗会明显上去没有散热设计的话几分钟内就会触发降频。表现就是刚开机对话很流畅聊了五分钟开始变慢。解决办法很朴素一块靠谱的散热片不是那种薄薄一片的贴片、必要时加小风扇、或者把主板通过导热垫贴到金属外壳上做整机散热。如果机器人是金属结构件这个方案最省心。DVFS调频也值得提一句。默认的调频策略偏保守在负载切换时会来回抖。对于LLM这种持续负载把调频策略调到performance模式实测能拿到更稳的吐字速度代价是功耗和温度上升。这个取舍要结合整机散热能力来定。5.5 存储与启动时间别忽视模型加载这几十秒模型文件动辄1GB到4GB。eMMC的读取速度大概在200~300MB/s这个量级加载一个3GB的模型要十几秒如果模型放在文件系统上每次冷启动都读一遍用户等得会很难受。两个优化方向一是用NVMeRK3588有PCIe通道读取速度能提升到GB/s级别加载时间大幅缩短二是常驻内存把模型加载后一直保持不要每次请求都重新加载。还有一个细节如果模型放在可写分区设备异常断电时有概率损坏文件。建议模型放在只读分区或者在加载前做一次校验校验失败就回退到备份副本。6. 踩坑实录与几条能直接抄的配置建议6.1 三个真实故障的排查链路故障一能出字但答非所问。排查顺序是这样的先确认模型文件本身在开发机上用相同prompt是否正常排除模型问题再抓取runtime实际喂进去的完整prompt这一步最容易被跳过但往往就是问题所在最后发现是chat template没有正确拼接系统提示词和用户输入之间少了分隔符。修复方式是改用官方推荐模板问题消失。这个坑的教训是端侧部署里格式问题伪装成能力问题是最常见的误判。故障二聊几分钟后开始卡顿。第一步看温度发现已经接近降频点第二步看NPU频率确实在降第三步把外壳拆开裸板测试卡顿消失。结论很明确是散热问题。加装散热片和风扇后连续对话一小时的吐字速度基本保持在初期的90%以上。故障三偶发重启。一开始怀疑是软件崩溃查日志发现是掉电重启。用示波器抓电源轨发现NPU满载瞬间有较大跌落原因是电源模块选型余量不足。换成更大电流能力的电源模块后问题解决。这个坑最值得记机器人上的稳定性问题先怀疑供电再看软件。6.2 不同预算档次的具体配置清单档次主控内存/存储模型方案适用产品入门RK3588 单板8GB / 32GB eMMC0.5B~1.5B INT4简单语音应答、指令解析主流RK3588 单板16GB / 64GB eMMC1.5B~3B 混合量化语音交互轻视觉高配RK3588 NVMe32GB / 256GB NVMe3B INT4 或 7B 尝鲜多模态交互、长上下文控制分离RK3588 RK3568各自独立LLM在3588控制在3568AMR、复合机器人、机械臂这张表可以直接拿去跟硬件供应商对需求。需要提醒的是入门档适合做Demo和验证如果产品要长期在线8GB往往会比较吃力我见过太多项目因为省内存最后被迫重构整个软件栈。6.3 选型时最该问供应商的几个问题不要只问是不是RK3588、多少TOPS这几个问题更值得问清楚内存是LPDDR4x还是LPDDR5频率多少是不是双通道NPU的三个核是否都能被runtime调用有没有实测的LLM token/s数据满载时的功耗和散热方案是什么能不能连续跑一小时不掉速PCIe通道是否引出支不支持NVMe有没有CAN、RS485、多路网口EtherCAT方案是硬件还是软件实现内核版本和实时补丁情况如何有没有长期维护的BSP这几个问题问下来方案成熟度大概就能判断个七八成了。最后分享一个我自己的调优习惯拿到板子先别急着跑大模型。先用一个1.5B的INT4模型跑满一小时记录温度曲线、频率曲线和吐字速度曲线把这块板子的长跑基线摸出来。因为机器人是7×24小时设备短时间的峰值性能参考价值有限真正决定用户体验的是第60分钟时的那个数字。我踩过的所有性能坑几乎都能通过这一个小时的基线测试提前暴露出来。