故障排除

在带有 NVIDIA/CUDA 的 WSL2 上，官方 Ollama Linux 安装程序会创建一个 ollama.service systemd 单元，并设置 Restart=always。如果该服务 在 WSL2 启动时自动启动并加载基于 GPU 的模型，Ollama 在加载过程中可能会固定 主机内存；Hyper-V 内存回收并不总能回收 这些页面，因此 Windows 可能会终止 WSL2 虚拟机，systemd 会重启 Ollama，循环随之重复。

证据：WSL2 反复重启/被终止，WSL2 启动后 app.slice 或 ollama.service 的 CPU 占用很高，并且来自 systemd 的 SIGTERM 而不是 Linux OOM killer。

OpenClaw 在检测到 WSL2、ollama.service 已启用且设置为 Restart=always，并且存在可见的 CUDA 标记时，会记录一条启动警告。

缓解措施：

sudo systemctl disable ollama

在 Windows 端，将以下内容添加到 %USERPROFILE%\.wslconfig，然后运行 wsl --shutdown：

[experimental]
autoMemoryReclaim=disabled

或者缩短 keep-alive / 仅在需要时手动启动 Ollama：

export OLLAMA_KEEP_ALIVE=5m
ollama serve

参见 ollama/ollama#11317。

确认 Ollama 正在运行，并且位于 agent 的模型范围内。对于自动发现本机 localhost，请设置 OLLAMA_API_KEY（或一个认证配置）。非空的手动 模型列表会跳过发现；显式的自托管端点配合 models: [] 则不会：

ollama serve
curl http://localhost:11434/api/tags

在本地拉取模型，或在 models.providers.ollama 中显式定义它：

ollama list  # See what's installed
ollama pull gemma4
ollama pull gpt-oss:20b
ollama pull llama3.3     # Or another model

请从运行 Gateway 的同一台机器和运行时环境中验证：

openclaw gateway status --deep
curl http://ollama-host:11434/api/tags

常见原因：

• baseUrl 指向 localhost，但 Gateway 运行在 Docker 中或另一台主机上。
• URL 使用了 /v1，选择的是 OpenAI 兼容行为，而不是原生 Ollama。
• 远程主机需要防火墙或局域网绑定更改。
• 模型在你的笔记本守护进程中，但不在远程守护进程中。

通常 provider 处于 OpenAI 兼容模式，或者模型无法处理 工具 schema。请优先使用原生模式：

{
  models: {
    providers: {
      ollama: {
        baseUrl: "http://ollama-host:11434",
        api: "ollama",
      },
    },
  },
}

如果小型本地模型仍然无法处理工具 schema，请在该模型条目上设置 compat.supportsTools: false 并重新测试。

对于托管的 Kimi/GLM 响应，如果包含长串非语言符号，会被视为 provider 调用失败，而不是成功回复，因此正常的重试/回退/错误处理会接管，而不是将 损坏的文本持久化到会话中。

如果问题反复出现，请记录模型名称、当前会话文件，以及 本次运行使用的是 Cloud + Local 还是 Cloud only，然后尝试新建 会话并使用回退模型：

openclaw infer model run --model ollama/kimi-k2.5:cloud --prompt "Reply with exactly: ok" --json
openclaw models set ollama/gemma4

大型本地模型可能需要较长的首次加载时间。可将超时范围限定到 Ollama provider，并可选择在多轮之间保持模型加载：

{
  models: {
    providers: {
      ollama: {
        timeoutSeconds: 300,
        models: [
          {
            id: "gemma4:26b",
            name: "gemma4:26b",
            params: { keep_alive: "15m" },
          },
        ],
      },
    },
  },
}

如果主机本身接受连接较慢，timeoutSeconds 还会 延长该 provider 的受保护连接超时。

许多模型宣称的上下文大于你的硬件能够舒适运行的范围。原生请求会转发有效的 contextTokens，除非 params.num_ctx 覆盖它。为获得可预测的首 token 延迟，请同时限制 OpenClaw 的预算和 Ollama 的请求 上下文：

{
  models: {
    providers: {
      ollama: {
        maxTokens: 8192,
        models: [
          {
            id: "qwen3.5:9b",
            name: "qwen3.5:9b",
            contextTokens: 32768,
            params: { num_ctx: 32768, thinking: false },
          },
        ],
      },
    },
  },
}

如果 OpenClaw 发送的 prompt 过多，请降低模型条目的 contextTokens。如果 Ollama 的运行时上下文对机器来说过大，请降低 params.num_ctx。 如果生成时间过长，请降低 maxTokens。