最近圈子里不少人在问同一个问题RK3588这种ARM板子到底能不能跑得动OpenClaw这类智能体框架我的答案是能跑而且如果你只做本地意图识别和硬件控制流畅度完全是可用的。这篇文章就是我拿到项目到彻底跑通全流程的记录包括选型逻辑、环境搭建、配置细节、踩坑过程和最后的实测数据准备在这类板子上部署OpenClaw的朋友可以直接照着操作。先交代一下背景我的目标是让一台RK3588开发板通过OpenClaw接管本地推理、技能调度和外部设备控制通俗点说就是让大模型成为“大脑”让GPIO、USB外设、摄像头这些成为“手脚”。整个方案选择全本地模型不走外部API成本和隐私都更可控。接下来我按实际操作顺序把每一步拆开讲清楚。1. 方案选型为什么把OpenClaw和RK3588放到一起1.1 OpenClaw到底是个什么项目如果你最近刷到OpenClaw这个词但没搞清楚它具体解决什么问题我简单用一句话总结它是一个开源智能体控制框架核心设计目标是让大语言模型能“动手”而不仅仅是“说话”。和纯聊天机器人不同OpenClaw强调意图解析、技能编排和动作执行你给它下一条自然语言指令它会把它拆解成可执行的流程然后调用对应技能完成操作。这套设计非常适合跑在边缘设备上。比如你接一个机械臂、一台小车、一组传感器理论上都能通过OpenClaw用自然语言控制。它支持自定义“Skills”技能插件也就是说“看懂指令”和“执行动作”两部分被解耦了——前者交给大模型后者交给本地脚本或硬件接口。我选择在RK3588上部署是因为它不需要依赖高性能x86服务器。相比传统的PC方案RK3588有8个核心、最高支持32GB内存能本地跑量化后的小参数模型功耗却只有十几瓦。放在桌面、机柜、甚至做成无人设备都没问题。1.2 RK3588在这套方案里的定位RK3588是瑞芯微推出的旗舰级SoC8核CPU由4个A76大核和4个A55小核组成还有6 TOPS算力的NPU和Mali G610 GPU。它的CPU部分足够承担3B~4B参数大模型的CPU推理NPU则适合跑视觉任务比如物体检测、人脸识别而OpenClaw正好可以做调度层把NPU的视觉结果和LLM的决策能力串起来。对比同样很火的Jetson平台RK3588的价格便宜不少而且接口丰富双HDMI、MIPI-DSI、PCIe、USB3.0一应俱全。对比树莓派5RK3588的最大优势是内存可以选到16G乃至32G跑本地模型不捉襟见肘。树莓派5最高只有16G且芯片算力弱一档跑7B模型很难受。另外我特别看中RK3588的对从容错能力4个A76大核跑LLM推理4个A55小核跑系统服务、GPIO通信和日志采集互不抢占。这一点在做机器人控制时非常重要因为推理卡顿可以等但电机和传感器响应不能丢。1.3 为什么“全本地”是关键很多类似的机器人控制项目默认接云端API效果确实好但有不少现实问题一是延迟网络抖动会直接反映在动作响应上二是每次调用都花钱三是如果你做的是带摄像头的自主设备视频数据传云端在隐私上也是隐患。OpenClaw官方也支持API接入但在我这个RK3588场景下我坚持用Ollama跑本地模型。好处非常直观断网也能用延迟低推理数据不出设备。坏处也不是没有模型能力上限会比云端大模型低一截但针对“理解指令并触发技能”这个目标3B参数级别的小模型已经够用。别一上来就追求7B、13B先让链路跑通更重要。2. 硬件准备与基础系统搭建别在散热和存储上省2.1 开发板怎么选内存和型号踩坑市面主流的RK3588开发板非常多香橙派5系列、Radxa Rock 5B、友善电子NanoPC T6、鲁班猫5都是不错的选择。我的建议是首选支持NVMe SSD启动的板子别把系统和模型放在TF卡里否则训练时读模型文件会被IO卡脖子。内存方面我的结论是8G能装能跑16G舒服32G可以放开手脚。8G板子跑qwen2.5:3b这类模型还可以但想同时挂载OpenClaw服务、摄像头流、ROS节点的多个进程内存就会见底。我自己的主力机是16G版本跑完整个方案占用大概在6G到7G左右留有余量。开发板推荐内存参考特点香橙派5 Pro16G性价比高双HDMI带NVMe接口Radxa Rock 5B16G/32G做工好PCIe扩展丰富NanoPC T616G支持双2.5G网口接口全鲁班猫58G/16G国产生态支持较好资料中文多我用的是Rock 5B主要看中它的供电和散热设计长时间跑模型更稳定。还要注意不同板子的Type-C供电协议不同有些需要PD协议触发20V供电最好买原厂电源适配器很多不稳定问题其实都是电源不给力造成的。2.2 系统镜像选择与刷写我推荐用Ubuntu Server 22.04或24.04的ARM64官方镜像不要装桌面版省下来的内存全给服务进程。桌面环境在这里没意义OpenClaw的交互是通过Web界面和API完成的板子本身不需要显示器。刷写方法不复杂。可以下载官方镜像后用写卡工具烧录到NVMe或者TF卡。我个人习惯先烧到TF卡然后从TF卡启动把系统完整复制到NVMe最后再改成NVMe启动。这样能缩短后续反复刷写的时间。有不少板子支持直接在主板上的按键进入MaskROM模式再配合rkdeveloptool命令行工具烧录。第一次操作可能觉得门槛高但熟悉后很方便比拆机焊线那种方式文明得多。2.3 散热和电源是“跑模型专不专”的分水岭这部分我要重点说。很多人在RK3588上跑AI推理遇到了莫名奇妙的性能下降或者重启十有八九是散热问题。RK3588的高负载功耗能到接近10瓦以上被动散热片只适合轻负载跑OpenClaw这种持续推理的场景必须上主动散热。我最后的方案是铝合金散热外壳加一个5V PWM风扇风扇接在主板风扇接口上由系统自动调速。另外我在系统里配置了温度监控超过65度时日志会记录并提醒防止持续高温导致CPU降频。RK3588的降频策略很激进核心一旦过热点A76大核频率从2.4GHz掉到1.2GHz推理速度直接对半砍这是很多人觉得“板子跑不动模型”的真正原因。供电上还有一个容易踩的坑个别USB外设比如USB机械臂、大功率摄像头直接从板子取电会和CPU抢功率。建议外设一律用独立供电的HUB主板供电只管自己和NVMe。3. 部署推理服务Ollama模型选择和ARM64性能实测3.1 Ollama安装先确认架构在RK3588上装Ollama最顺的方式就是官方安装脚本curl -fsSL https://ollama.com/install.sh | sh注意观察安装日志中是否出现了arm64字样。如果日志显示检测为x86_64架构说明你下载了错误版本需要手动从GitHub releases页面下载linux-arm64版本。安装完成后用ollama --version验证版本。Ollama安装到ARM64设备上没有任何性能妥协官方对ARMv8架构支持得一直很好。安装后启动服务进程也可以用ollama serve后台跑但为了开机自启和崩溃恢复我建议配置成systemd服务。3.2 模型怎么选不要盲目上大参数OpenClaw这类智能体框架对大模型的“长上下文记忆”要求一般核心要求是快速理解用户意图并输出结构化动作指令。因此参数量权重小推理延迟权重高。我实测了qwen2.5:3b和llama3.2:3b前者在中文指令理解上明显更好后者英文和代码场景更稳。模型参数量量化格式加载后内存占用实测速度A76 4核qwen2.5:3b3BQ4_K_M约2.5G12-18 tokens/sllama3.2:3b3BQ4_K_M约2.3G11-16 tokens/sqwen2.5:7b7BQ4_K_M约4.8G4-6 tokens/sdeepseek-r1:8b8BQ4_K_M约5.2G3-5 tokens/s这个结果说明7B模型在RK3588上虽然能跑但生成速度已经开始让人着急配合OpenClaw做指令交互时视觉上会有一秒两秒的等待感。3B模型的12到18 tokens/s虽然和云端没法比但用在“指令-动作”这种短文本场景里一个指令通常只有几十个token一两秒出结果完全可接受。要在系统里拉取模型执行ollama pull qwen2.5:3b拉取时注意模型文件比较大2G到3G网络差的情况下可能中断可以用ollama pull --resume继续拉取。如果磁盘空间小先清理下系统日志或者把OLLAMA_MODELS环境变量指向NVMe挂载路径。3.3 Ollama建议开启局域网监听默认情况下Ollama只监听127.0.0.1如果OpenClaw和Ollama跑在同一台板子上这个配置没问题。但如果你的OpenClaw服务端和模型推理分别部署在不同机器比如用Windows作为客户端就要把监听地址改成0.0.0.0。我推荐采用systemd管理Ollama这样重启和日志管理都方便。编辑服务配置时把环境变量写进去[Service] EnvironmentOLLAMA_HOST0.0.0.0 EnvironmentOLLAMA_MODELS/data/ollama/models然后重启Ollama验证端口监听systemctl daemon-reload systemctl restart ollama ss -tlnp | grep 11434到这里RK3588这边的模型推理底座就算搭好了。接下来是OpenClaw本体的安装。4. OpenClaw本体部署Node.js环境、安装和配置详解4.1 Node.js环境准备OpenClaw的服务端依赖Node.js经测试需要18及以上版本我装的是20 LTS。Ubuntu系统仓库自带的Node版本通常比较旧所以我用NodeSource源安装curl -fsSL https://deb.nodesource.com/setup_20.x | bash - apt install -y nodejs node -v这里有一个小坑Node.js某些原生模块可能没有prebuilt ARM64二进制编译时需要build工具链所以提前装好构建依赖可以少折腾apt install -y build-essential python3 git net-tools4.2 OpenClaw两种安装方式选哪种OpenClaw既可以通过包管理器直接安装也可以拉取源码运行。我建议在RK3588上优先使用npm全局安装npm install -g openclaw这种方式干净简单后续升级也比较方便。不过因为OpenClaw还在快速迭代我实际是clone源码再执行本地签出固定在某个稳定版本上避免上游更新导致配置结构变化毕竟板子上调试一次的时间成本比x86高不少。如果代码仓库提供的ARM64预编译产物不完整还需要执行一次源码构建。在构建之前确认代码里引用的所有原生依赖是否有ARM64版本拿不准就预先编译好后面踩坑少很多。4.3 核心配置文件config.yamlOpenClaw启动时会读取配置文件。在我的Config目录里最关键的部分是推理后端和技能目录。下面是我在RK3588上使用的配置文件节选只保留了核心内容server: host: 0.0.0.0 port: 1860 llm: provider: ollama base_url: http://127.0.0.1:11434 model: qwen2.5:3b temperature: 0.2 timeout: 120 skills: directory: ./skills enabled: all logger: level: debug output: /var/log/openclaw.log注意到temperature我故意调低到0.2。OpenClaw这类框架不能让模型自由发挥需要的是稳定输出可解析的动作指令。温度越低模型越倾向于输出确定性的内容执行阶段的失败率会明显下降。如果你想要灵活一点的对话风格可以上调到0.7但控制场景下不建议。timeout: 120是必须的因为RK3588的CPU推理速度有限模型响应一次最长可能要等十几秒如果超时时间设太短OpenClaw会误判模型故障。在板子上跑服务任何“超时”配置都要适用于慢速硬件这是和x86环境最大的区别。4.4 Skills技能插件体系OpenClaw真正强大的地方在Skills。一个Skill就是一个可被LLM调用的工具或脚本模型根据用户意图选择技能并传入参数。对RK3588板子来说我写了很多硬件类的Skills比如GPIO点灯、读取温度、控制风扇等。下面是一个实际的技能定义功能是读取RK3588核心温度name: read_cpu_temp description: 获取当前RK3588 CPU核心温度没有参数。 execute: command: cat /sys/class/thermal/thermal_zone0/temp output: celsius原理很简单模型在收到“当前温度多少”这类指令时会从技能清单里选中read_cpu_temp然后执行该命令并把输出整理成自然语言回复。OpenClaw把这块封装成了很顺滑的流程把“找技能、执行技能、汇总结果”三步都自动化了。更复杂的技能可以写成脚本比如控制风扇持续一分钟name: fan_on description: 打开散热风扇持续运行指定秒数参数t表示秒数。 execute: command: /opt/scripts/fan_control.sh {t} output: text这些技能实际就是在硬件和模型之间搭桥。你可以把技能逐步增加让OpenClaw变成一套个人定制的边缘控制中心。5. 全流程实操记录从命令行到自然语言控制5.1 安装后的一次完整启动链路把前面的基础都搭好后启动顺序也有讲究。我每次都是这样# 1 确认Ollama进程正常 ollama list systemctl status ollama # 2 启动OpenClaw服务 openclaw server start # 3 查看服务和日志 openclaw status tail -f /var/log/openclaw.log如果服务起来后日志里出现“model not found”这类信息基本就是Ollama里没拉这项模型回头检查一下模型名配置是否完全一致连版本号后缀都不能差。启动后OpenClaw会监听在1860端口。可以用curl做一次健康检查curl http://127.0.0.1:1860/health刚启动到完全就绪大概需要几秒钟因为OpenClaw要预加载技能清单并和Ollama建连。这时候访问页面或API如果返回乱码或空响应不要急着重启等十秒再试大概率就好了。5.2 发一条自然语言指令验证数据流部署最核心的验证是端到端的闭环。我用curl直接向OpenClaw的API请求发送指令验证它会不会调用技能curl -X POST http://127.0.0.1:1860/chat \ -H Content-Type: application/json \ -d {message: 把散热风扇打开60秒}最终OpenClaw返回了类似这样的执行结果{ intent: fan_on, params: {t: 60}, result: 风扇已打开持续运行60秒 }这一步看到就说明整个链路是通的自然语言指令被LLM解析成技能调用请求参数正确技能执行成功。首次调用的等待时间会比后续几次更长因为模型推理要加载到内存预热完成后就顺滑了。调试阶段打开日志看每个环节的耗时特别有帮助能看出到底慢在理解、慢在执行还是慢在模型加载。我实测下来的分布大致是模型理解占2到4秒脚本执行几乎是瞬时所以如果你想优化端到端延迟重点还是在模型选型和推理参数上。5.3 Web UI和移动端远程连入OpenClaw提供了内置Web UI可以在浏览器打开http://RK3588的IP:1860直接用。RK3588板子本身不需要接显示器我都是手机或电脑连局域网访问性能够顺畅。Windows和安卓端也有配套的Companion程序可以作为远程终端。实际使用的时候我把RK3588放在房间角落用手机连Web界面给它下指令整个体验非常接近一个“私人家居机器人总管”。对远程访问场景有两点建议一是开启局域网固定IP在路由器里给板子绑定静态IP不然指令发到哪都不知道二是如果你一定要启用域名和HTTPS访问可以用自动部署证书的方案加密流量避免敏感配置明文裸奔。6. 踩坑记录ARM64环境下的专属问题与排查6.1 Windows上部署遇到的WSL报错如果你像我一样先在Windows上试过OpenClaw可能见过一个很烦人的提示openclaw无法安全验证sl2环境。请在powershell中运行wsl -- status。这个不是RK3588的问题是Windows上WSL版本太旧或者未正确处理。在PowerShell里依次执行wsl --status wsl --update把WSL内核更新到较新版本后这个问题就会消失。后来我基于稳定性和性能考虑直接切到了RK3588的Linux环境这部分问题就不存在了。如果你以后想在Windows上远程控制RK3588里的OpenClaw那WSL更新好之后只需要通过局域网访问不必在Windows里再装一套服务。6.2 Ollama进程OOM和模型加载闪退在8G内存的板子上如果同时开了多个模型Ollama很容易掉进OOM。症状就是拉取模型正常但一跑推理立刻退出日志里写着内存不足。解决办法有三个用OLLAMA_MAX_LOADED_MODELS1环境变量限制只加载一个模型换用更小的量化格式比如Q3_K_M在系统里增加swap分区给4G的swap缓冲。但要注意swap只能避免进程崩溃不能解决推理速度问题。如果模型被从内存换到swap生成速度会掉到个位数token/s体验很差。加swap是兜底方案不是优化方案。6.3 ARM64上npm原生模块编译失败OpenClaw依赖的部分模块需要原生编译而部分包的预编译产物只有x86_64版本在ARM64上就要现场编。如果你发现安装时报python、gyp相关的错误先确认装好了build-essential python3再尝试重新安装依赖。我编译一个模块大概需要十几分钟别急等就完了。如果实在编不过去可以用pnpm替代npm它的依赖解析逻辑有时候能避开一些奇怪的编译问题不是玄学而是pnpm对postinstall脚本的处理更干净。6.4 GPIO和USB设备权限问题RK3588访问GPIO和USB设备的权限很容易被卡。症状是程序运行一切正常但一调用硬件技能就报Permission denied。原因是当前用户不在dialout和video用户组里usermod -aG dialout,video $(whoami)改完后重新登录或重启一次才能生效。当时我用摄像头做视觉识别时也遇到过这个坑一直提示无法打开/dev/video0加上video组权限后立刻解决。另外访问GPIO可能需要配置对应板卡的内核驱动这个话题踩起来又是一篇长文建议先用简单的LED点灯验证通路。6.5 高负载下的温度和降频RK3588在连续跑模型时发热很快没有主动散热的情况下核心温度可以冲到85度以上。温度一高CPU调度器就开始限频推理速度骤降。我当时排查发现日志里明明模型没问题服务没问题但响应时间从3秒涨到15秒最终定位到降频。解决思路是散热的系统性优化从外壳、风扇、供电三个方向一起解决。也可以用命令行观察当前频率cat /sys/devices/system/cpu/cpu4/cpufreq/scaling_cur_freq正常的A76大核频率应该在2.2GHz到2.4GHz附近如果发现只有1.2GHz左右系统大概率已经在降频了。常见报错原因解决办法model not found模型未拉取或名称不一致用ollama list检查统一配置Permission denied用户缺少设备权限加入dialout和video组OOM killed内存不足限制模型加载、减小模型量化、加swap编译报gyp错误ARM64原生模块无预编译安装build-essential重新编译响应突然变慢CPU过热降频加强散热检查风扇转速7. 部署后的体会与值得继续折腾的方向这次部署里最深的体会是OpenClaw在RK3588上的价值不在于“跑一个大模型”而在于把本地硬件能力封装成可以对话的技能。我实际用下来最舒服的一点是“任何外设都只需要写一个技能就能纳入控制体系”完全不用改主程序逻辑扩展性非常强。对于硬件选型我坚持一个态度如果不是要做视觉推理和模型推理同时并行8G内存确实够用但如果你想把摄像头画面、传感器数据、LLM推理都放在一台板子上走16G是起步。我这台16G设备在同时跑Ollama 3B模型 OpenClaw服务 摄像头rtsp流的情况下内存还剩接近一半长期运行的稳定性有保障。下一步我准备把RK3588的NPU能力也接进来用RKNN工具链跑一个轻量的YOLO模型做目标检测检测结果通过技能喂给OpenClaw让模型知道“面前有什么”形成视觉-语言-行动闭环。这个方向如果跑通了价值会比现在单纯做指令控制大很多。最后分享一个最朴素的建议先别急着调优性能先把链路跑通。你第一次在RK3588上通过自然语言控制风扇和灯光转起来的时候对这个系统的理解会完全不一样。性能调优是在“已经有可用系统”的前提下进行的在链路都没通之前追求参数优化只会让人更崩溃。希望这篇记录能让你少走点弯路。