OpenClaw故障诊断：ollama-QwQ-32B服务异常排查手册

1. 当OpenClaw遇到ollama-QwQ-32B时

那天深夜，我的OpenClaw突然停止了工作——它本该自动整理我积压的会议纪要，却卡在"正在连接模型服务"的状态。控制台不断刷新的错误日志让我意识到，ollama-QwQ-32B这个刚部署的本地模型服务出了问题。作为经历过无数次AI工具故障的老手，我决定系统性地记录这次排查过程。

OpenClaw与ollama这类本地模型服务的配合，本质上是通过HTTP接口完成的自动化协作。当出现"模型服务异常"时，问题可能出现在：网络连通性、服务状态、配置参数、权限控制等环节。本文将分享如何用openclaw doctor这把"听诊器"，快速定位ollama-QwQ-32B服务异常的根源。

2. 诊断工具链准备

2.1 基础检查三板斧

在深入日志前，建议先执行这三个基础检查：

# 检查OpenClaw核心服务状态
openclaw gateway status

# 查看ollama服务进程
ps aux | grep ollama

# 测试模型服务端口连通性
curl -v http://localhost:11434/api/generate

如果ollama服务未运行，需要先启动服务（假设使用默认端口）：

ollama serve &

2.2 openclaw doctor的妙用

openclaw doctor是OpenClaw自带的诊断工具，它能检查：

• 配置文件语法有效性
• 模型服务连通性
• 必要依赖项完整性
• 权限与路径可访问性

执行后会生成类似这样的报告：

[✔] OpenClaw核心服务运行正常 (PID: 78521)
[✖] 模型服务连接失败 (provider: ollama-qwq)
[!] 配置文件存在警告: models.providers.ollama-qwq.baseUrl缺少尾部斜杠
[✔] 飞书通道凭证有效

重点关注带有[✖]和[!]的条目，它们直接指向问题根源。

3. 典型错误场景解析

3.1 错误码ECONNREFUSED

当看到连接被拒绝的错误时：

Error: connect ECONNREFUSED 127.0.0.1:11434

这通常意味着：

1. ollama服务未启动
2. 服务监听的端口与配置不符
3. 防火墙阻止了连接

排查步骤：

# 确认ollama是否在运行
ollama list

# 检查实际监听端口
lsof -i :11434

# 临时关闭防火墙测试（仅诊断用）
sudo ufw disable

3.2 模型加载超时

ollama日志中出现：

[ERROR] 加载模型 qwq:32b 超时 (超过300秒)

可能原因：

• 模型文件损坏
• 磁盘空间不足
• 内存不够（32B模型通常需要64GB+内存）

解决方案：

# 重新拉取模型
ollama pull qwq:32b

# 检查磁盘空间
df -h

# 查看内存占用
free -h

3.3 配置不匹配

OpenClaw的openclaw.json中如果出现：

{
  "models": {
    "providers": {
      "ollama-qwq": {
        "baseUrl": "http://localhost:11434",
        "models": [{
          "id": "qwq-32b"  // 实际模型名为qwq:32b
        }]
      }
    }
  }
}

冒号与横杠的差异就会导致模型找不到。修正为：

"id": "qwq:32b"

4. 日志分析实战技巧

4.1 三明治日志分析法

1. OpenClaw侧日志：

   journalctl -u openclaw -n 50 --no-pager
   

2. ollama服务日志：

   tail -n 100 ~/.ollama/logs/server.log
   

3. 网络中间层日志：

   sudo tcpdump -i lo -nn port 11434 -w ollama.pcap
   

交叉比对三个日志源的时间戳，可以精准定位问题发生的环节。

4.2 关键日志模式识别

遇到这些日志要特别注意：

• "error":"context deadline exceeded" → 模型响应超时
• "status":"invalid request" → API参数不合法
• "message":"CUDA out of memory" → 显存不足
• "code":503 → 服务不可用

5. 模型服务专项检测

5.1 连通性测试脚本

保存为test_ollama.sh：

#!/bin/bash
API_URL="http://localhost:11434/api/generate"

curl -sS -X POST $API_URL \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwq:32b",
    "prompt": "test",
    "stream": false
  }' | jq .

这个脚本可以测试：

• 服务是否响应
• 模型是否加载
• 基础推理功能是否正常

5.2 性能基准测试

使用ollama自带的benchmark：

ollama run qwq:32b "这是一段性能测试文本" --verbose

关注两个关键指标：

• 首token延迟（TTFT）
• 每秒生成token数（TPS）

如果TTFT超过5秒或TPS低于10，可能需要：

• 检查GPU驱动
• 调整ollama的num_ctx参数
• 降低并发请求数

6. 复杂问题排查框架

当问题无法通过简单命令解决时，建议按这个框架逐步排查：

1. 隔离问题范围：

   • 是OpenClaw的问题还是ollama的问题？
   • 通过直接调用ollama API验证

2. 最小化复现：

   • 用最简单的curl命令测试
   • 排除Skill和复杂工作流干扰

3. 环境对比：

   • 在另一台干净机器上测试相同配置
   • 确认是环境问题还是配置问题

4. 版本矩阵测试：

   • 尝试ollama和OpenClaw的不同版本组合
   • 特别注意版本兼容性公告

7. 预防性维护建议

经过这次排查，我养成了这些好习惯：

1. 配置版本化：

   # 备份OpenClaw配置
   cp ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.bak
   
   # 备份ollama模型列表
   ollama list > ~/ollama_models.txt
   

2. 资源监控看板：

   watch -n 1 "echo 'GPU:'; nvidia-smi | grep 'Default'; echo 'CPU:'; top -bn1 | head -5"
   

3. 自动化健康检查： 创建cronjob每天运行：

   openclaw doctor --json > ~/healthcheck/$(date +%Y%m%d).json
   

这些方法不仅适用于ollama-QwQ-32B，对于OpenClaw连接其他本地模型服务也同样有效。记住，好的故障排查不是找到问题，而是建立一套可复用的诊断方法论。

---

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。