结合 Ollama 使用本地 LLM（大语言模型）来运行 OpenClaw 代理。包含真实的 GPU 基准测试、那些会破坏一切的上下文窗口陷阱，以及在生产环境中真正有效的模型推荐。
上下文窗口陷阱
结合 Ollama 使用 OpenClaw 听起来很简单。安装 Ollama，将 OpenClaw 指向它，选择一个模型，搞定。每个教程都把它展示成一个 10 分钟就能完成的任务。
事实并非如此。
经过几个月在消费级 GPU 上运行本地大模型来驱动 OpenClaw 代理，真实发生的情况是：你跟着教程做，在交互式测试中一切似乎都正常运行，然后当你设置了定时代理任务后，它们却开始产生语无伦次的输出。没有错误，没有警告，纯粹是垃圾数据。
罪魁祸首几乎总是 Ollama 默认搞错的一个设置。Ollama 默认将上下文 tokens 设置为 2048。但 OpenClaw 代理最少需要 16K-24K。
这不是一个建议。代理的对话包含了系统提示词 (system prompts)、工具定义、对话历史以及工具调用的结果。在模型开始推理当前任务之前，哪怕是一个中等复杂度的单次代理交互都可以轻易消耗 8,000 到 12,000 个 token。
如果上下文窗口只有 2048 个 token，Ollama 会静默截断超出该限制的所有内容。模型看到的可能只有实际对话的 10%。它只会对这个片段做出响应。输出看起来是不对的，而不是坏掉了。你会花好几个小时调试你的代理逻辑，而真正的问题只是一个环境变量。
将 OLLAMA_NUM_CTX 设置为 24576。这正好匹配了 OpenClaw 的 contextTokens 设置，并为工具定义保留了余量。这绝对是首先要做的。现在就去设置。
OLLAMA_NUM_CTX=24576
为什么选择本地部署？
- 成本：每次推理 $0。如果你跑的代理每个任务需要进行几十次大模型调用，API 的计费会迅速叠加。除了硬件成本之外，本地推理是免费的。
- 隐私：你的数据永远不会离开你的网络。对于受监管的行业或敏感操作来说，这比性能基准测试重要得多。
- 延迟：无需网络往返。对于简单、快速的代理任务，本地推理可能比等待 API 响应更快。尤其是当你的代理正在进行快速连发的工具调用时（每次网络往返会增加 200-500ms 的延迟）。
大多数“本地部署”指南忽略的一点是：本地模型在复杂任务上会使用更多的 tokens。它们会陷入循环，不断重试工具调用。它们消耗上下文的速度更快，因为它们需要更多推理步骤，才能达成单个 Claude API 调用一遍就能得出的结论。我们曾观察到一个本地 30B 模型在一个任务上尝试了 6 次工具调用，而 Sonnet 一次就能搞定。虽然推理确实免费，但额外消耗的上下文却不容忽视。
对于简单的流程化工作（归档、排序、格式化、数据提取、监控等），本地大模型是正确的选择。如果涉及多步推理链、复杂的工具编排或需要前沿水平的思考，请将它们路由到 API 模型。了解一种工具会在哪里崩溃，比假装它完美无瑕更有价值。
没人公开的生产环境配置
每一个 Ollama 教程都只演示 ollama serve 并认为大功告成。下面是一个真正的生产环境配置应该有的样子：
OLLAMA_HOST=0.0.0.0 OLLAMA_KEEP_ALIVE=1h OLLAMA_NUM_CTX=24576 OLLAMA_FLASH_ATTENTION=1 OLLAMA_KV_CACHE_TYPE=q8_0 OLLAMA_NUM_PARALLEL=2 NVIDIA_VISIBLE_DEVICES=all CUDA_VISIBLE_DEVICES=0
每个参数的作用解释：
OLLAMA_NUM_CTX=24576设置上下文窗口。使其与 OpenClaw 的contextTokens设置加上留白相配合。默认的 2048 对代理工作负载来说毫无用处。OLLAMA_FLASH_ATTENTION=1启用 Flash Attention 以加快推理速度。这也解锁了 KV 缓存量化功能，也就是下一个变量的作用。OLLAMA_KV_CACHE_TYPE=q8_0将 KV 缓存量化为 8 位，这样可以在质量下降极小的情况下把缓存内存占用削减约一半。在一块 24GB 的显卡上，这将决定你的模型能否加载上去。OLLAMA_NUM_PARALLEL=2允许两个并发的代理请求。如果你运行了多个代理，它们可以在无需排队的情况下共享模型。请根据你的显存余量进行设置，因为每增加一个并行槽都会消耗额外的 KV 缓存内存。OLLAMA_KEEP_ALIVE=1h设置在最后一次请求后，模型仍保留在 VRAM 中一小时。默认只有 5 分钟，这意味着如果你的代理在任务间暂停，每次都必须重新经历冷启动。CUDA_VISIBLE_DEVICES=0将 Ollama 绑定到特定的 GPU。如果你有多块显卡，请分配专用的硬件资源。多个服务在高负载下共享 GPU 会导致 CUDA 内存不足 (OOM) 而崩溃。OLLAMA_HOST=0.0.0.0在所有网络接口上暴露 Ollama，使得 OpenClaw 可以从容器中访问它。
身份验证的变通方法
OpenClaw 的网关（Gateway）要求每个 Provider 都要有 API Key，即使是根本不需要密钥的 Ollama 也不例外。尝试设置 type: "none" 会在热重载时被剥离。
修复方案： 在 provider 配置中设置一个虚假的 apiKey 值（任何字符串都可以），并将其配上 authHeader: false。根本没人记录这点，如果没有它，系统会静默阻止你的代理运行。
apiKey: "dummy-key"
authHeader: false
哪些模型真正有效
并非所有的模型都能胜任代理任务。“工具调用 (Tool calling)” 的支持是不可商量的条件。如果没有它，OpenClaw 代理无法执行操作，模型只会描述出“它打算做什么”，而不是“实际去执行它”。
在测试了几十个模型之后，这些是能稳定处理 OpenClaw 代理的模型：
qwen3:30b-a3b：这是我们一直使用的首选。它是一个混合专家 (MoE) 模型：总量 300 亿个参数，但每次推理只有 30 亿参数激活。你能获得 30B 级别的推理能力，却不需要承担密集型 30B 模型高昂的显存代价。工具调用非常稳定，即使是复杂的代理调用链也能完成而不会陷入无限重试死循环。qwen2.5:14b：中端替代选项。如果你 GPU 装不下上述模型，那么 14B 模型足以处理更简单的代理任务。但在多步复杂工作上，预期它会有更多重试。qwen3:0.6b：一个轻量级的效用模型。适合用作轻量级的预处理或嵌入任务。切勿将其用于需要逻辑推理的代理功能。
我们丢弃了 Reddit 上极其热门的几个模型，因为它们在测试中要不在工具调用上失败，要不就在工具参数上产生幻觉 (hallucinate)。Reddit 上的炒作往往与生产环境的现实不符。直到其他模型家族在结构化输出和工具调用上追平差距之前，应对代理工作负载还是老老实实坚持使用 Qwen。
GPU 现实检查
模型卡上的理论 VRAM (显存) 数据其实没有把 KV 缓存的开销算进去。真实数据看起来是这样的：
qwen3:30b-a3b(2个并行槽位和 q8_0 缓存)：在 RTX 3090 上大约需要 21GB。这留下了约 3GB 的余量。虽然很紧凑，但在启用 flash attention 时，满载情况下相当稳定。qwen2.5:14b(2个并行槽位)：大约需要 12GB。能在 RTX 3090 上绰绰有余地运行，或者甚至能勉强挤进配备 12GB 显存的 RTX 4070。
Docker 陷阱
docker restart 不会应用你的 docker-compose 文件中所做的更改。如果你更改了环境变量，必须执行 docker compose down && docker compose up -d。这其实是一个 Docker 基本常识，但它绊倒了所有配置 Ollama + Docker 的人，因为你会通常只是改变了 OLLAMA_NUM_CTX，重启容器，然后疑惑什么都没有发生变化。
多 GPU 分配
如果你运行了多个需要使用 GPU 的服务，请务必使用 CUDA_VISIBLE_DEVICES 为每个服务分配专门的显卡。将同一个 GPU 混用（在 Ollama 和其他 CUDA 服务之间共享）会导致偶发的、根本无法一致性重现的显存溢出 (OOM) 崩溃。
五个会破坏你系统的问题
以下内容绝非纸上谈兵。每一个都来自实际的生产级故障。
1. MULTIUSER_CACHE 崩溃
当设置了 OLLAMA_NUM_PARALLEL 为 2 或更高时，OLLAMA_MULTIUSER_CACHE 会导致 GGML_ASSERT 崩溃。模型能顺利加载、完成一个请求服务，随后在介入第二个并发请求时就会崩溃。
解决办法： 不要设置 OLLAMA_MULTIUSER_CACHE。作为福利，不开启这个能帮你大概省下 0.8GB 的 VRAM。这其实在 Ollama GitHub 的 Issue #12150 已经被记录。这不是你那里的配置错误，而是一个已知 Bug。
2. 模型白名单静默失败
OpenClaw 的模型白名单是最令人挫败的坑。交互式会话可以绕过白名单检查！ 因此当你测试代理时，完美无瑕毫无报错，但当你把它发布为 cron 定时周期性任务时，它却会静默失败。
你必须把使用的模型显式添加到 OpenClaw 的模型白名单中，计划任务才能去使用它。千万别再被能够跳过这个检查的“交互式会话”迷惑了。
3. 网关配置的竞态条件
OpenClaw 的网关会在启动时将其配置加载进内存中，并会周期性地将其同步回磁盘上。如果你在网关运行期间手滑编辑了你的配置文件，你的变更将在几秒内被直接覆盖踩掉。
解决办法： 修改完配置信息后，即刻重启网关。永远不要采用“编辑然后等待”的策略，网关在下次同步周期必将覆盖你辛辛苦苦修改好的内容。
4. 无密钥提供商的身份验证
在上文我们提到过这点，但强调一下是非常值得的：Ollama 不需要 API key。但 OpenClaw 网关对每一个提供方却坚决要求要有一个。设置 type: "none" 会在其进行热重载 (Hot-reload) 时直接丢失。你必须使用带有虚拟验证值的 apiKey 值配合 authHeader: false 进行处理。
5. 上下文截断
这是在文章开头我们深聊过的问题。没有错误提示、日志里亦没有任何警告。模型单纯收到被截断过半的残缺对话，并对着那点可怜零碎的片段进行推测作答。把 OLLAMA_NUM_CTX=24576 安排上，并检查是否已奏效（看 Ollama 日志中的模型加载阶段）。
附赠：OLLAMA_NUM_GPU 并不存在
你会在大量教程、博客博文及 Stack Overflow 的答案上看到 OLLAMA_NUM_GPU 这个环境变量的存在。它不是真正的 Ollama 环境变量！ 设置它做不了任何事。分配 GPU 要且只用 CUDA_VISIBLE_DEVICES。这一设定已在 Ollama 源代码里再三获得了证实。若你一直在排查显卡分配缘由且配置里有这个量，那如今谜团解开了。
什么时候不应该使用本地模型
本地模型并非永远是最优选。有很多时候 API 反而更便宜：
- 复杂多步骤推理： 如果你的代理需牵扯起 5-10 档携着条件逻辑的工具调用穿梭，API 模型干成这事儿既快且整体更实惠。本地模型重试得更多、烧去大量上下文还需更长时间才能聚合成功。同样的一件事一个请求 API 处理一次的事，如果是本地这边可能耗了 3 倍之余的 Token 量。的确推理可以0元购，但浪费的上下文窗口是不讲道理的。
- 对时间敏感的任务： 如果输出要求首次回答就得是一击必杀，切莫去跟本地模型去对赌。API 模型在把控复杂运转和要求时一次通关率要优秀得多。当你无法承担任何重来或循环试错的余地时，乖乖用 API 方案。
- 需要“前沿”级别思维的任务： Opus 级别的推理压根未见降落到这等本地部署级别。那些具备庞然体积（70B+ 等）的模型会十分靠拢，却无情地索求高达 40GB+ 以上的巨大 VRAM。若是任务需求极高强度统筹与思考逻辑的参与，直接转交给 API 代工。
最务实的策略是架构一个路由层 (Routing layer)。 简单和注重流程的工作（比如格式化、提取筛选或是排版处理）统统导给 Ollama 纯免费跑。复杂的逻辑推演及关键核心工作流的全量交接给 API 代劳处理。你能在这个模式基础把不必要的经费砍下来，同时保证最重要的命脉任务高质量。
核心要点
- 率先设置
OLLAMA_NUM_CTX=24576。 默认的 2048 会静默破坏很多代理任务。 - 最适配的模型。
qwen3:30b-a3b是运行 OpenClaw 代理任务验证过最优的模型选择：兼顾 MoE 的高效与 30B 测试输出级别，并有靠谱的工具支援。 - 杜绝使用
OLLAMA_MULTIUSER_CACHE。 面对并发请求时百分百引发GGML_ASSERT阻断崩溃。 - 注意添加你的白名单 (Allowlist)。 由于本地交互会暗度陈仓绕开这道校验，但 crons 任务绝然逃脱不了这项严格检查。
- 路由分配机制。 把繁杂琐细的工作丢给本地 Ollama 当作打工人，把复杂的逻辑决策留给专业 API。
常见问题解答 (FAQ)
- 使用 Ollama 跑 OpenClaw 我们到底准备多大的上下文视窗？
本着底线，它最少需要 16K-24K 的运行容量设定。我们建议将其配置成
OLLAMA_NUM_CTX=24576。Ollama 默认那 2048 枚代币的量只会悄无声息得将你宝贵的代理对话记忆无情截留，而且你抓破头都可能查不到任何显式错误反馈记载。 - 针对 OpenClaw ，哪个版本哪一家的 Ollama 模型为最优解推演？
首推当打之选
qwen3:30b-a3b。一个体量 30B 雄厚架构但常驻激活只需要调用 3B 总参数的优秀 MoE 模型（满打满算的 VRAM 消耗约在 18.6GB 的标准），而且工具支援表现尤为亮眼出众。 - 本地运行得掏空多少显存空间？
当装配启动2个平行工作且采用降频 q8_0 级缓存配置的
qwen3:30b-a3b时粗略评估会锁下 21GB 之多空间。至于诸如后备补充模型小体量如qwen2.5:14b也最好乖乖预留个打底的 12GB 显存给足它。 - 何解我运行搭配的 OpenClaw 老是产出不堪入目的错误指引和胡说八道？
基本百分之百的元凶源起正是那万恶被默认锁死的 上下文窗口 (Context window) 遗害！去翻找配置看眼可怜巴巴还锁着少数值域的
OLLAMA_NUM_CTX参数吧！ OLLAMA_NUM_GPU这个配置有任何正面效用加成么？ 没有。纯无稽之谈而已。这是广在各个教学帖子或是问答板乱讲的一个流传谬谈级变量口号。- 为何我测试时一切相安无非顺顺利利只要放养扔定时任务执行就会全盘嗝屁？ 受害于“模型白名单”特有的背刺交互体验使然！交互试检有最高赦免路权可以全境无阻跳此门禁。反观那些幕后台操作按时出动的定时执行 cron 则皆卡在这硬性红线里败下阵来。
关于
📬 关注我获取更多资讯
