RTX 3090 24G + Ollama + OpenClaw 本地模型测试总结（持续更新版）

本文基于当前实测环境：

  • GPU：RTX 3090 24GB
  • CPU：Intel i9-9820X
  • 系统：Ubuntu（Linux 6.8.0-87-generic）
  • Ollama：0.17.5
  • OpenClaw：2026.3.2（从 2026.3.1 升级）
  • 浏览器：google-chrome-stable（Headless，无显示器环境）
  • OpenClaw 默认配置关键点（已固化）：
    • 默认模型示例：ollama/qwen3.5:27b
    • num_ctx = 32768（32K 上下文）
    • KV Cache：q4_0（OLLAMA_KV_CACHE_TYPE=q4_0）
    • OLLAMA_NUM_CTX=32768、OLLAMA_MAX_LOADED_MODELS=1、OLLAMA_NUM_PARALLEL=1

本文只总结已经在这台 3090 24G 上真实跑过/踩过坑的模型和配置，方便后续整理成 CSDN 文章。后续你再测试新模型时，可以基于这个文档继续补充。

一、整体结论（当前阶段）

  • 目前综合表现最好的是：qwen3.5:27b（Q4_K_M，约 17GB）
    • 推理能力明显强于 14B 系列
    • 速度略慢但可接受（在 3090 上属于“可用但偏重”的档位）
    • 到目前为止长时间使用没有崩溃，浏览器工具调用也能正常跑
  • qwen3:30b-a3b 在这台 3090 上显存极限太紧 + 冷启动慢，实际一次推理可能要 5~6 分钟，不推荐作为主力模型
  • gpt-oss:20b 在当前 Ollama 版本下，工具调用格式与 Ollama 的 harmony parser 不完全兼容，在 OpenClaw 内经常出现 “Ollama API stream ended without a final response”，不建议目前在 OpenClaw 里作为主力
  • 纯 14B（qwen2.5:14b、qwen2.5-coder:14b 等）在这台机器上速度很好，但在复杂 Agent 场景下工具调用/事实性明显不够，有“瞎编”、“不用工具直接编故事”的情况，适合轻量任务，不适合作为主要自动化 Agent 模型

当前推荐（只看本机已测情况）：

  • 通用 Agent / 浏览器自动化 / 较复杂任务：
    • 首选：qwen3.5:27b
  • 代码生成 / 修复（本地 IDE 辅助）：
    • 暂用：qwen2.5-coder:14b（已经安装，实际效果中规中矩）
    • 正在准备：qwen2.5-coder:32b-instruct-q3_K_M（约 16GB，预计会成为 3090 上比较平衡的 32B 代码模型）
  • 轻量模型 / 资源紧张时：
    • 可以考虑：qwen3.5:9b（已在下载），作为 27B 的轻量备选

二、环境与基础配置

1. Ollama 配置（通过 systemd override）

/etc/systemd/system/ollama.service.d/override.conf 中关键环境变量：

  • OLLAMA_NUM_CTX=32768
  • OLLAMA_KV_CACHE_TYPE=q4_0
  • OLLAMA_FLASH_ATTENTION=1
  • OLLAMA_MAX_LOADED_MODELS=1
  • OLLAMA_NUM_PARALLEL=1

解释：

  • 32K 上下文是针对 24GB 显存的安全上限；再往上开（尤其是 32B 模型）KV cache 很容易把显存打满。
  • q4_0 KV Cache 让 32K 上下文 KV 占用大概 1GB 左右，比默认 f16 省了 3GB+。
  • MAX_LOADED_MODELS=1、NUM_PARALLEL=1 是为了保证显存尽量给单一模型使用，避免多个模型/并发请求互相抢显存导致崩溃。

2. OpenClaw 配置（openclaw.json）

/root/.openclaw/openclaw.json 中当前关键片段：

  • 默认模型示例：
agents: {
  defaults: {
    model: {
      primary: "ollama/qwen3.5:27b",
    },
    models: {
      "ollama/gpt-oss:20b": { params: { temperature: 0.6, num_ctx: 32768 } },
      "ollama/qwen3.5:27b": { params: { temperature: 0.6, num_ctx: 32768 } },
      "ollama/qwen3:14b":   { params: { temperature: 0.6, num_ctx: 32768 } },
      "ollama/qwen3:30b-a3b": { params: { temperature: 0.6 } },
    },
  },
},
  • 浏览器（为无显示器环境单独配置）：
browser: {
  enabled: true,
  headless: true,
  noSandbox: true,
  defaultProfile: "openclaw",
  profiles: {
    openclaw: {
      cdpPort: 18800,
      color: "#FF4500",
    },
  },
},

说明：

  • 一开始没有显式 browser 配置，OpenClaw 默认认为有“显示器”，Chrome 启动失败导致浏览器工具一直超时。
  • 显式设为 headless: true, noSandbox: true 后，Headless Chrome 可以在这台服务器上正常跑，解决了浏览器工具随机失效的问题。

三、已测试模型清单与表现（按时间与重要性）

1. qwen2.5:14b（Ollama tag：qwen2.5:14b）

  • 大小：约 9GB
  • 上下文：32K（Ollama 默认；实际通过 num_ctx=32768 控制）
  • 用途场景：通用对话、简单任务
  • 实测表现：
    • 速度：非常快，单轮响应通常在 2～3 秒内完成。
    • 工具调用能力偏弱：
      • 在“注册一个不用手机验证的邮箱”这类复杂 Agent 任务中，几乎不使用工具，而是直接胡编步骤和结果。
      • Agent 日志里可以看到没有 tool 调用记录，说明策略完全偏向“直接回答”，不适合作为自动化执行 Agent。
    • 事实性/稳定性：
      • 简单问答还凑合，但在需要查信息、访问网页、操作浏览器时严重“瞎编”。
      • 多轮对话后容易自相矛盾。

结论：在 3090 上性能很轻松，但 Agent 能力明显不够，只适合作为轻量聊天模型，不建议作为 OpenClaw 主力模型。

2. qwen3:30b-a3b（Ollama tag：qwen3:30b-a3b）

  • 大小：约 18GB（MoE，激活参数少于总参数）
  • 上下文：32K（通过 num_ctx=32768 设置）
  • 用途场景：通用 Agent、推理任务
  • 实测表现：
    • 首轮运行耗时极长：
      • 日志中有一次典型运行：
        • embedded run agent start → embedded run agent end 耗时约 345 秒（近 6 分钟）。
      • 整体给人的体验是“在转很久”。
    • 显存占用：
      • 在 RTX 3090 24GB 上，Ollama 进程显存占用约 23.5GB/24GB，基本打满。
      • KV cache + 模型权重 + 其他开销叠加后，属于“勉强能跑”的状态。
    • 工具调用：
      • 能够调用工具（例如 node.list），说明 Agent 能力和工具集成都没问题。
      • 但整体延迟过高，不适合作为日常交互主力。

结论：

  • 理论上 MoE 结构应该兼顾大模型能力与速度，但在 24GB 显存上整体仍然过重。
  • 可以作为“偶尔用来跑高难度任务”的备选，但不适合作为长期默认模型。

3. gpt-oss:20b（Ollama tag：gpt-oss:20b，MXFP4 MoE）

  • 大小：约 14GB（MXFP4 量化，MoE：总 20.9B，激活约 3.6B）
  • 上下文：128K（理论）；实测同样限制在 32K 以内使用
  • 特点（来自官方与评测）：
    • 专为 Agent / 工具调用 / Web 浏览 场景设计。
    • MoE + MXFP4，理论上在 3090 上能达到 20～30 tok/s 的速度。
  • 实测问题（关键）：
    • 在 OpenClaw 内，多次出现：
      • Ollama API stream ended without a final response
    • Ollama 日志出现：
      • harmony parser: no reverse mapping found for function name "send"
    • 现象：
      • 第一轮对话成功，并能调用工具（例如 send、message 等）；
      • 但从第二轮开始，经常在 2～30 秒后直接“空流结束”，OpenClaw 只能报错，UI 上显示“在转圈然后没反应”。
  • 原因分析：
    • gpt-oss 使用 OpenAI 风格的 function calling 格式输出工具调用（函数名如 send）。
    • Ollama 当前版本的 harmony parser 对这种格式支持还不完整，无法在后续轮次正确解析历史工具调用记录，导致流式输出直接终止。
    • 这属于 Ollama 与 gpt-oss 集成层面的兼容性问题，暂时不是 OpenClaw 自己能规避的。

结论：

  • 单独用 curl 调 Ollama Chat API 时，gpt-oss:20b 是正常的。
  • 但在 OpenClaw + 工具调用 场景下，目前不稳定，不建议作为主力 Agent 模型，等待 Ollama 后续修复 harmony parser 再尝试更合适。

4. qwen3.5:27b（Ollama tag：qwen3.5:27b，当前最佳）

  • 大小：约 17GB（Q4_K_M 量化）
  • 架构：qwen35，混合架构（Gated Delta + sparse MoE），支持文本+图像
  • 上下文：理论 256K，实际在本机以 32K 为上限配置运行（num_ctx=32768）
  • 用途场景：
    • 通用 Agent
    • 浏览器自动化（如邮箱注册/操作）
    • 较复杂的推理 + 工具调用任务
  • 实测表现：
    • 速度：
      • 明显慢于 14B，但远好于 30B 密集模型。
      • 在 3090 上属于“略慢但可接受”的等级（可以用来跑真实任务）。
    • 工具调用：
      • 能稳定调用 OpenClaw 的工具（消息发送、浏览器、节点管理等）。
      • 没有出现类似 gpt-oss 的空流/解析错误。
    • 稳定性：
      • 截止目前长时间使用，没有出现因为显存不足导致的崩溃。
      • 在浏览器工具方面，主要问题来源于 Chrome 启动方式（已通过 headless 配置解决），与模型无关。
    • 整体体验：
      • 在 事实性、推理力、工具调用配合 之间达到了比较好的平衡。
      • 对于 3090 24G 来说，是一个现实可用、并且“没有明显短板”的选择。

结论：

  • 目前这台机器上的 首选主力模型。
  • 后续可以搭配 qwen3.5:9b 作为轻量备选、qwen2.5-coder:32b-instruct-q3_K_M 作为代码专用模型。

5. qwen3:14b（Ollama tag：qwen3:14b）

  • 大小：约 9.3GB
  • 上下文：同样以 32K 运行
  • 表现（相对 qwen2.5:14b）：
    • 工具调用、指令理解较 qwen2.5:14b 有明显提升。
    • 在复杂任务上仍然不如 27B、32B 级别稳，但作为中档模型已经能满足不少需求。

总结定位：

  • 作为“中档通用模型”是可用的，但在你目前的体验中，主观感觉仍然是 14B 不够用，所以被 27B 取代。

6. qwen2.5-coder:32b-instruct-q3_K_M（Ollama tag：同名，正在下载/计划测试）

  • 大小：约 16GB（Q3_K_M）
  • 用途场景：代码生成、代码修复、工程类 Agent 任务
  • 原因与预期：
    • 官方 32B Instruct 模型在代码生成/修复 benchmark 上接近 GPT-4o。
    • 对 3090 24G 来说，16GB 的 32B 量化模型属于“勉强舒适区”，比 20GB 的 32b-instruct-q4_K_M 余量更大。
    • 预计会比 14B 编程模型有明显提升，且不会像 30B Dense 那样拖到 5～6 分钟一轮。

目前状态：已开始拉取，尚未完成全面测试，后续可以在此文档下追加“代码任务实测结果”。

7. qwen3.5:9b（Ollama tag：qwen3.5:9b，正在下载/计划测试）

  • 大小：约 6.6GB
  • 用途场景：3090 资源紧张时的轻量通用模型
  • 预期定位：
    • 作为 qwen3.5:27b 的“小弟”，在某些对延迟要求更高、但对能力要求略低的场景中，可能更合适。
    • 若实际表现理想，可以作为“默认轻量模型 + 27B 重型模型”的双配置方案。

同样等待后续实测数据进行补充。

8. deepseek-r1:32b（Ollama tag：deepseek-r1:32b-qwen-distill-q4_K_M 等，尚未在本机正式测试）

  • 大小：约 20GB（32B Qwen Distill）
  • 特点：Reasoning 能力非常强，原版 DeepSeek-R1 接近 O3 / Gemini 2.5 Pro 级别；32B Distill 版本是在 Qwen2.5 上蒸馏。
  • 在 3090 24G 上的推测：
    • 显存余量会比 27B 更紧（20GB + KV cache + 其他），风险类似 qwen2.5-coder:32b 正式版。
    • 需要继续保持 32K 上下文限制，并尽量避免并发调用。

目前主要停留在理论分析/准备阶段，还未在本机上做完整任务测试。

四、可以直接用于 CSDN 的结构建议

你后面写 CSDN 文章时，可以大致按照下面结构展开，并把本文件内容拆分/润色：

  1. 硬件与环境介绍

    • 3090 24G + Ubuntu + Ollama 0.17.5 + OpenClaw 2026.3.2
    • Headless Chrome + OpenClaw 浏览器配置（headless: true, noSandbox: true）

  2. Ollama 与 OpenClaw 的关键配置

    • OLLAMA_NUM_CTX / OLLAMA_KV_CACHE_TYPE 等
    • OpenClaw openclaw.json 中的 primary 模型与 models 列表

  3. 各模型实测表现（逐个小节）

    • qwen2.5:14b：速度快但 Agent 能力不足
    • qwen3:30b-a3b：MoE 但在 24G 上太重，6 分钟一轮
    • gpt-oss:20b：Ollama 工具调用兼容性问题
    • qwen3.5:27b：当前综合表现最平衡
    • 以及后续你测试的 qwen2.5-coder:32b-instruct-q3_K_M、qwen3.5:9b、deepseek-r1:32b 等

  4. “3090 24G 如何选模型”的实战建议

    • 优先选择 Q4 / Q3 量化，控制单模型显存在 18～20GB 内
    • 上下文建议控制在 32K，一般足够 Agent 使用
    • 严格限制同时加载的模型数量与并发请求数
Logo
2048 AI社区

有“AI”的1024 = 2048，欢迎大家加入2048 AI社区

更多推荐

cover

【电商剪辑如何人效提升效率？分镜素材库智能匹配替代人工繁琐剪辑】

avatar 2048 AI社区
cover

18节点精准感知：Minktec形变传感器如何全天候记录你的脊柱动态？

avatar 2048 AI社区
cover

小白实操 OpenClaw2.7.9，5 分钟完成本地 AI 环境部署指南

avatar 2048 AI社区