多年前我还在用 CPU 跑本地模型当聊天机器人结果经常一句话等半分钟同事问“这 AI 是不是睡着了”。后来把整个 OpenClaw 部署切到 GPU再接入飞书和 Discord体验完全变了群里 一下两三秒就能收到回复而且数据全在自己手里不用担心敏感信息被第三方记走。这篇东西不是概念科普是我实际搭建和跑了一段时间后的记录。我会把 GPU 部署 OpenClaw 的完整链路拆开讲为什么选这个方案、环境怎么准备、飞书和 Discord 分别怎么接、跑起来之后遇到哪些坑、怎么排查。无论你是想给自己搭个私人 AI 助手还是给团队搞一个能查资料、写周报、写小说的机器人都可以直接照着参考。1. 内容整体设计与思路拆解1.1 OpenClaw 到底解决什么问题OpenClaw 本质上是一个跑在你自己设备上的 AI 代理框架它把大模型和各类消息平台、工具连接起来。大模型只是“大脑”光有大脑没法替你收发消息、读文件、执行命令OpenClaw 就是那个“神经系统”接收来自飞书、Discord 等平台的消息转成模型能理解的指令调用模型推理再把结果发回对应的对话窗口。听起来很像“套壳聊天机器人”但区别在于它不只是接一个模型 API 就完事。OpenClaw 还能挂工具让它读文件、查资料、调搜索引擎、操作本地命令、根据上下文写小说。这意味着你在飞书群里让它“总结一下本周项目进展”它能真正去读取相关文档然后组织语言回复而不是凭空编造。选择 GPU 部署的核心原因有两个。一是推理速度。大模型每生成一个字都需要大量矩阵计算CPU 虽然也能算但速度差了十倍甚至几十倍交互体验完全不在一个量级。二是数据归属。用第三方平台托管对话内容会经过别人的服务器很多团队接受不了尤其是涉及内部业务数据时。1.2 为什么本地 GPU 部署是当前最优解市面上的 AI 代理服务并不少云厂商也提供现成的托管方案但“本地 GPU 开源模型 自建适配器”这条路依然值得走核心逻辑就这么几条第一长期成本可控。GPU 是一次性投入或按需租用模型本身是开源的不需要按 token 计费。如果团队里几十个人高频使用一个月下来的 API 账单会非常可观本地部署跑得越久省得越多。第二上下文隐私有保障。对话内容、上传的文件、工具调用的结果都留在自己的机器或内网里不会出边界。这对企业用户来说几乎是刚需。第三模型可自由替换。本地部署意味着你想用 Qwen、Llama、Mistral 还是微调过的垂直模型改个配置就行。云端方案往往是“平台给你什么你就用什么”灵活度差很多。当然这条路也有门槛你得有一张足够显存的 GPU需要处理驱动、依赖、端口映射这些问题。但这恰恰是下面要展开讲的重点。1.3 整体架构拆解模型、代理、平台三层我习惯把整套系统拆成三层来理解排查问题时也是按层定位的第一层是推理引擎。本地最常见的是 Ollama也有用 vLLM、LM Studio 的。它负责加载模型、处理请求、生成答案对外暴露一个 HTTP API。这一层好不好用直接决定整体延迟。第二层是 OpenClaw 核心。它负责调度接收消息、维护会话上下文、调用模型、触发工具。核心进程还会起一个 Web 控制台方便你直观地看日志、改配置、测试对话。第三层是平台适配器。飞书、Discord 这些消息平台通过各自的 API 与 OpenClaw 对接收到用户消息后转成统一格式送给核心处理。平台适配器出问题最常见的表现是“机器人不回复”。这三层是相互独立的所以排查时可以先在控制台测试核心对话是否正常再测平台接入一步步缩小问题范围而不是在同一个地方瞎猜。2. 环境准备与部署前检查2.1 硬件配置与系统选择建议GPU 部署的第一优先级是显存。显存决定你能跑多大的模型而模型大小直接决定回复质量。我自己的经验是这样划分的8GB 显存可流畅跑 7B~8B 参数的量化模型Q4 量化级别适合体验、个人助手、简单问答。12GB~16GB 显存可以尝试 13B~14B 模型推理速度尚可回答质量明显提升。24GB 以上可以跑 32B 或更大模型甚至能做多用户并发适合团队生产使用。如果你的 GPU 显存不够但卡的数量多也可以用多卡方案但配置复杂度会上升。此外内存建议至少 32GB硬盘建议留 50GB 以上因为模型文件体积不小7B 的量化模型大约 4~5GB34B 的量化模型可能超过 20GB。系统方面Ubuntu 22.04 是最省心的选择驱动和 CUDA 生态最完整。Windows 用户建议用 WSL2 跑 Docker这样能复用大量 Linux 镜像。macOS 用户尤其是 Apple Silicon也能跑用 Docker Desktop 即可但模型生态和性能优化不如 N 卡直接。2.2 驱动、CUDA 与 Docker 环境安装这一步没有太多玄学按顺序装就行。首先装 NVIDIA 驱动。Ubuntu 下可以直接用sudo apt install nvidia-driver-535版本号按当前稳定版选装完重启后用nvidia-smi验证能输出 GPU 信息表就说明驱动正常。然后装 Docker。官方源或镜像源都行关键是装完以后要把当前用户加入 docker 组否则每次都要 sudosudo usermod -aG docker $USER newgrp docker接着配置 NVIDIA Container Toolkit这样 Docker 容器内部才能访问 GPU。安装完以后用一行命令验证容器内 GPU 是否可见docker run --rm --gpus all nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi如果能看到 GPU 列表说明容器 GPU 环境已经打通。如果报Failed to initialize NVML或者GPU access blocked by the operating system基本都是宿主机驱动和容器运行时版本不匹配优先检查驱动是否最新、NVIDIA Container Toolkit 是否重装过。注意nvidia-smi里显示的 CUDA Version 只是驱动支持的最高 CUDA 版本不代表容器里实际装了 CUDA。容器里跑什么 CUDA 版本取决于镜像标签一般不用自己装拉对镜像就行。2.3 获取 OpenClaw 与模型权重OpenClaw 的部署方式现在很成熟官方提供 Docker 镜像也可以用一键脚本。我个人推荐 Docker 方式升级、回滚都方便而且不会污染宿主机环境git clone https://github.com/openclaw/openclaw.git cd openclaw cp .env.example .env docker compose up -d首次启动会拉取镜像时间取决于网络。启动后等服务初始化完成打开http://localhost:3000看控制台是否正常。模型方面建议先用 Ollama 拉一个小模型跑通全流程再逐步换大的docker run -d -v ollama:/root/.ollama -p 11434:11434 ollama/ollama ollama pull qwen2.5:7b ollama pull llama3.1:8b如果后续要用 OpenClaw 接 OpenAI 兼容接口这里只需确认模型已经能通过curl http://localhost:11434/v1/chat/completions正常返回。3. 核心部署实操5 步跑通 OpenClaw3.1 第一步编写主配置文件OpenClaw 的所有核心配置都集中在一个文件中路径一般在~/.openclaw/openclaw.json或项目目录下config/openclaw.yml不同版本字段可能略有差异但核心结构类似。我用的是 JSON 格式关键配置如下{ llm: { provider: ollama, model: qwen2.5:7b, baseUrl: http://localhost:11434, temperature: 0.7, maxTokens: 2048 }, platforms: { feishu: { enabled: true, appId: cli_xxxx, appSecret: xxxx, eventMode: long_connection }, discord: { enabled: true, token: bot_token_here } }, bot: { name: Claw, triggerPrefix: ! } }这里有几个容易踩坑的点baseUrl要写宿主机可访问的地址。如果 OpenClaw 和 Ollama 各自跑在独立容器里应该写http://host.docker.internal:11434或对应的服务名写localhost会因为容器网络隔离而连不上。triggerPrefix是机器人响应的前缀。如果设置了!那么群里只有消息以!开头时机器人才回降低误触发概率。temperature控制回答随机性。写代码、查数据建议调低到 0.3 左右写小说、头脑风暴可以调到 0.8 以上。3.2 第二步启动服务并确认 GPU 被调用配置写好后启动 OpenClawdocker compose restart然后重点观察日志docker logs -f openclaw如果模型正常加载日志里会出现类似model loaded的提示。此时另开一个终端执行nvidia-smi往下翻进程列表如果能看到ollama或对应的推理进程占用了显存说明 GPU 确实在工作。如果显存没变化赶紧回去检查baseUrl和容器网络配置大概率是模型没真正被加载或者 OpenClaw 还在用 CPU 后端。我自己就犯过这个错OpenClaw 部署成功控制台也通了但第一次跑对话发现 CPU 占用拉满、GPU 空转查了半天才发现是 Ollama 那边开启了 CPU 模式环境变量没设置对。在容器里跑 Ollama 时记得确认启动命令中没有OLLAMA_HOST127.0.0.1这类误导性配置。3.3 第三步在控制台完成一次对话闭环OpenClaw 的 Web 控制台通常默认监听3000端口。打开后应该能看到一个聊天界面或测试入口以不启用任何平台适配器的模式直连模型。我在控制台里会先问一个简单问题比如“用一句话介绍你自己”。如果能得到流畅回复说明核心链路消息输入 → LLM 推理 → 输出已经打通。这时候再看平台接入就可以把“模型问题”和“平台问题”区分开避免后面接飞书时失败却去怀疑模型。如果控制台都无法回复先查两件事一是模型有没有下载完整二是 OpenClaw 进程日志里有没有报错。常见的是模型路径不存在、端口被占用、Ollama 服务没起来。3.4 第四步用命令行接口做一次快速验证控制台界面正常后我还会用 curl 直接命中 OpenClaw 的本地 API做一次无 UI 的验证。这一步很多人省略但排查问题时特别有用因为可以精确控制请求参数curl -X POST http://localhost:3000/api/chat \ -H Content-Type: application/json \ -d {message: 你好请回复一句话}返回内容里应该包含模型生成的文本。如果这一步通过说明 OpenClaw 核心服务完整可用接下来配置任何平台都能确定是平台侧的问题而非后端问题。这一步其实也是后续写自动化脚本的基础。比如我想在飞书群里定期让机器人汇总某份文档本质上就是定时调用这个 HTTP 接口再把结果推送到群里和 OpenClaw 的适配器机制是同一套道理。4. 接入飞书与 Discord具体可落地的配置4.1 飞书自建应用与机器人创建飞书的接入是整个流程里稍显繁琐的一环主要因为它需要你在开放平台做不少配置。下面按顺序来第一步打开飞书开放平台创建一个“企业自建应用”。这里需要管理员权限个人开发者账号也能建只是部分权限受限。第二步在应用详情页找到“凭证与基础信息”拿到 App ID 和 App Secret。这两个值要填进 OpenClaw 的配置里。第三步开启应用能力中的“机器人”能力。这一步不开启应用只是个空壳无法收发消息。第四步配置事件订阅。飞书支持两种模式长连接和回调 URL。长连接模式最省事不需要公网暴露端口OpenClaw 会主动和飞书服务器建立连接。我强烈建议用长连接因为回调 URL 模式要求你的服务必须能被飞书服务器访问到本地部署一般不具备这个条件。第五步在“权限管理”里开通必要权限最关键是im:message和im:message.receive_v1这两个。没开通权限机器人能收到消息但无法回复这是一个人人都会踩的坑。拿到 App ID 和 App Secret 后填入 OpenClaw 配置文件的platforms.feishu部分重启服务。然后在飞书群里添加机器人直接 它发消息测试。4.2 Discord 机器人创建与 Token 获取Discord 的接入比飞书简单因为不需要配置回调 URL一切通过 Bot Token 认证。先打开 Discord Developer Portal创建一个 Application。然后在左侧菜单找到 Bot点击 Add Bot 创建机器人。这里会生成一个 Token注意这个 Token 要保密泄露了别人就能控制你的机器人。把 Token 复制到 OpenClaw 配置的platforms.discord.token字段。然后还要把机器人邀请进你的服务器在 OAuth2 页面选择bot权限范围并勾选Send Messages、Read Message History等基础权限打开生成的邀请链接选择目标服务器即可。Discord 通常不需要额外配置事件订阅因为 OpenClaw 的适配器会通过 Gateway 长连接方式接收消息。启动后在 Discord 频道里发一条带触发前缀的消息比如!hello机器人应该会回复。注意Discord 官方对机器人消息频率有限制如果 OpenClaw 同时接入多个频道并频繁触发可能会导致消息被 API 限流表现为偶尔不回复。生产环境建议在配置里加一个冷却时间参数。4.3 消息路由与多平台同时接入一个 OpenClaw 实例可以同时接飞书和 Discord这是它很实用的一点。你不需要跑两个进程只需要在配置里同时启用两个平台即可。但有一个细节要处理不同平台的消息如何区分上下文。OpenClaw 会为每个对话窗口维护独立的会话状态通常以平台 群组/频道 ID作为会话 key。所以同一个模型、同一个配置在飞书 A 群和 Discord B 频道的对话是互相隔离的互不干扰。如果你想给不同群组配置不同人设或工具OpenClaw 也支持基于会话 ID 的规则路由。比如飞书“项目周报群”里启用总结工具Discord“闲聊群”里不启用。这类配置通常在platforms下的channels或routes字段里定义具体字段名看版本但思路是一样的。多平台同时接入后最需要注意的是并发。如果多个群同时有人发消息模型只能串行处理后面的请求会排队。显存越大、模型越小排队现象越不明显。实测下来24GB 显存跑 8B 模型时5 个并发群聊基本无感知如果 8GB 显存跑 13B 模型并发一多就会看到明显的延迟上升。5. 性能表现与调优经验5.1 实测数据不同显存下的真实表现以下数据是我在自己机器和租来的机器上实测的结果模型均为 4-bit 量化单轮对话输出 200 字左右显存模型生成速度token/s首字延迟适用场景8GBQwen2.5-7B30~45约 1s个人助手、轻量问答12GBLlama3.1-8B35~50约 0.8s个人多群、轻度团队使用16GBQwen2.5-14B25~35约 1.5s团队生产需要较高质量回答24GBQwen2.5-32B15~25约 2s高质量写作、复杂任务速度只是体验的一半更关键的是首字延迟。群里发一条消息超过 3 秒没回应大家就会觉得“机器人挂了”。8B 模型在 8GB 显存上基本能满足“秒回”的感知14B 以上模型开始会有明显等待感。如果觉得速度不够优先检查量化等级是否过高Q8 比 Q4 慢很多但回答质量提升有限。是否开了大上下文窗口上下文越长首字延迟越高尽量不要无脑拉满。模型是否加载在共享显存上部分笔记本的 GPU 共享内存会导致速度骤降查看nvidia-smi是否显示有大量共享内存使用。5.2 让 OpenClaw 更“好用”的调优技巧跑通只是第一步真正让它变得好用离不开几个调优动作。第一细化 system prompt。OpenClaw 支持配置基础人设这个不写的话模型就是“自由发挥”状态。我给自己搭的助手写了一段简短但明确的人设“你是一个严谨的助手回答要简洁直接不确定的内容要说明不确定。”效果立竿见影回答质量和稳定性都好了很多。第二学会用工具调用。OpenClaw 支持让模型决定是否调用外部工具比如搜索、读文件。这个功能开启后你可以直接在飞书群里说“读一下 docs 目录里最新的需求文档总结成三点发给我”模型会自己找到文件去读。前提是在配置里挂好工具的路径和权限范围不建议开放所有目录否则模型可能读到不该读的东西。第三配合自动化监控。OpenClaw 服务跑久了偶尔会因为内存泄漏或模型进程异常导致不可用。我习惯用 uptime-kuma 这类监控工具定时探测控制台端口一旦发现服务异常立刻通过飞书 Webhook 推通知到运维群。这样不必等用户报障自己就先知道服务挂了。5.3 长会话与多用户并发的内存管理本地部署最容易被忽视的问题是长对话导致显存持续增长。每轮对话结束后OpenClaw 会把历史消息拼接到上下文里一起发送给模型这是为了让模型记住前文。但上下文越长KV Cache 占用的显存就越多跑几十轮之后显存很容易被撑爆导致CUDA out of memory模型进程直接崩溃。解决方案是在配置里限制上下文长度或历史消息轮数{ context: { maxHistory: 30, maxTokens: 2048 } }maxHistory表示最多保留多少轮历史消息超出后自动丢弃最早的消息。这样会话还能保持连贯但不会无限吞噬显存。多用户并发时还需要注意队列长度。OpenClaw 默认串行处理请求如果同一时间有大量消息后面的请求会长时间排队。我遇到过一次飞书群里 10 个人同时 机器人结果最后一个人等了 3 分钟才收到回复。后来我在配置里把并发处理关掉改为固定的串行队列虽然还是排队但至少不会因为资源竞争导致进程崩溃。6. 常见问题与排查技巧实录6.1 高频报错与解决方案速查表实际操作中下面这些问题是出现频率最高的我整理成了速查表按“现象—原因—解法”三列对号入座现象原因解法服务启动报Failed to initialize NVML容器运行时无法访问 GPU驱动或 Container Toolkit 版本不匹配宿主机运行nvidia-smi确认驱动正常重装 NVIDIA Container Toolkit并重启 Docker 服务运行时报CUDA out of memory模型太大或上下文过长换更小模型、降低量化等级或调小maxHistory与maxTokens飞书群里 机器人没反应事件订阅没配对或机器人权限不足检查应用是否开启长连接模式确认im:message.receive_v1权限已开通Discord 机器人没反应Token 填写错误或机器人未加入目标服务器在 Developer Portal 重新复制 Token确认邀请链接包含目标服务器控制台能聊但飞书/Discord 不能聊平台适配器配置有误分开排查先确认平台侧权限和 Token再查看 OpenClaw 日志中平台连接状态服务启动后 Control UI 打不开端口被占用或前端资源未加载检查3000端口是否被占用ss -lntp看监听情况必要时换端口回复速度特别慢模型在跑 CPU 后端或显存不足触发交换nvidia-smi查看进程是否使用 GPU确认 Ollama 容器是否启用 GPU 参数6.2 我踩过的三个大坑说几个我自己实际踩过、特别值得注意的坑。第一个坑是 CPU 伪装 GPU。第一次部署时我把 Ollama 跑在容器里OpenClaw 也跑在容器里配置也写了 GPU但忘了给 Ollama 容器加--gpus all参数。结果模型跑在 CPU 上显存一点没占回复慢到让人怀疑人生。后来用nvidia-smi看进程才发现问题。这个教训是每个需要 GPU 的容器都要单独声明 GPU 权限一个漏掉就白搭。第二个坑是飞书事件订阅的长连接模式没有在配置里显式开启。飞书开放平台默认让你填回调 URL如果本地环境没有公网填了也白填。后来在 OpenClaw 配置文件里找到eventMode字段改成long_connection瞬间就通了。关键点是本地部署必须用长连接模式不要试图用内网穿透暴露回调端口那样既不稳定也不安全。第三个坑是上下文无限增长。最初我把maxHistory设为-1以为“不限历史”效果最好结果跑了一个上午显存从 6GB 涨到 11GB直接 OOM 崩溃。这也提醒我长会话的显存管理比想象中重要得多。机器人在生产环境是持续运转的不是演示完就关掉的必须从一开始就规划好资源上限。6.3 排查思路从外到内分层定位遇到问题不要慌我的排查顺序是固定的先看平台侧。飞书、Discord 后台里能看到机器人是否在线、事件投递是否成功。飞书开放平台有“调试工具”可以直接模拟事件推送用来验证适配器是否正常工作非常方便。再看 OpenClaw 日志。docker logs -f openclaw会输出所有平台的连接状态、消息接收记录和错误堆栈。关键词重点看ERROR、WARN、retry、timeout大部分问题在这一步就能定位。最后才看模型层。如果日志显示“消息已收到但模型调用超时”那问题大概率在推理引擎或 GPU 资源上。用ollama ps查看当前加载的模型和显存占用如果模型被卸载或显存不足就会表现为“偶发不回复”。这套顺序能避免 90% 的无效排查。不要一上来就怀疑模型有问题多数时候其实是平台配置或服务连接出的问题。最后再分享一个心法本地部署 AI 代理这件事最难的不是安装而是“跑起来之后怎么让它稳定地持续工作”。给团队用之前最好先在个人环境压测一周把并发、日志、监控都跑熟了再上生产。毕竟机器人挂一次大家对它的信任度就会掉一截。
