WorkBuddy接入本地Ollama：从零到70 tok/s的排查与调优

最近在折腾 WorkBuddy 接入本地 Ollama 模型，从最开始调用接口干脆没反应，到最终跑出 70 tok/s 的稳定速度，中间踩的坑攒起来估计能写一篇长文。这篇就当是个人排查记录的整理，给正准备把 WorkBuddy 和 Ollama 连起来用的朋友做个参考。我会把整个流程、排查思路、最终能跑通的关键决策全部拆开讲，每一步都标注了为什么这么做，毕竟这类问题如果不理解原理，换个配置可能又得重新踩一遍。

先说结论：问题基本都出在“模型名不匹配”“上下文参数没调”和“API 兼容性没验证”这三类上，性能瓶颈则集中在量化等级、上下文长度和并发数的取舍。下面按我实际操作的顺序来写。

1. 整体接入思路：为什么选 Ollama 而不是云 API

先说 WorkBuddy 这边。它本质上是一个 AI 代理工作台，可以挂各种 skill，也能调用不同后端的模型接口。默认配置走的是云 API，但对我来说有两个痛点：一是数据隐私，我把不少文档和代码片段丢给工作台处理，不希望内容经过第三方服务器；二是稳定性，云服务有时会抽风，而且响应速度随网络波动。所以接本地模型是刚需。

选 Ollama 而不是 LM Studio 或其他方案，主要看三点：

  • Ollama 对 OpenAI 兼容 API 的支持比较成熟，WorkBuddy 这类工具基本可以直接配 Base URL 和 API Key 就能用，不用额外写适配层。
  • 模型管理简单，一条命令就能拉模型、跑服务，不需要手写复杂的加载脚本。
  • 社区活跃，遇到问题基本都能搜到现成方案，这一点在踩坑时非常重要。

当然 LM Studio 也可以，但如果 WorkBuddy 的 skill 机制需要频繁切换模型，Ollama 的 CLI 比 LM Studio 的图形界面更顺手。另外 Ollama 原生跑 GGUF 量化模型，内存占用控制得不错，对一台没有顶级显卡的机器更友好。

我的目标很明确：先用 Ollama 把本地模型服务跑起来，再用 WorkBuddy 配置一个本地模型作为默认后端，最后在保证可用的前提下把速度拉到能舒服用起来的水平。整个流程就三步，但每一步都有不少细节。

2. 环境准备与安装避坑：存储路径、下载速度、离线迁移

2.1 安装 Ollama 前先想清楚装在哪

Ollama 模型文件体积不小，一个 7B 模型的 q4 量化版本也要 4GB 左右，8B 模型更是接近 5GB。如果系统盘比较小，默认装 C 盘很容易爆。我的做法是提前规划路径。

Windows 上很简单，安装包装好后，模型默认存储在C:\Users\用户名\.ollama\models。如果想把模型放别的盘，不是改安装目录，而是要设置环境变量OLLAMA_MODELS。这个变量需要手动新建，指向你想放模型的目录，改完重启 Ollama 才生效。

Linux 和 macOS 同理，只是路径不一样。Linux 下默认是/usr/share/ollama/.ollama/models（root 用户）或~/.ollama/models，同样通过export OLLAMA_MODELS=/your/path修改。

我这次是在一台 32GB 内存的机器上跑的，显存只有 8GB，所以策略很明确：模型放 SSD，小模型让 GPU 参与计算，大模型干脆纯走 CPU 内存。实测下来 7B q4 模型在纯 CPU 模式下也能有 40-50 tok/s，完全够用，关键是内存带宽不能太差。

注意：修改 OLLAMA_MODELS 之后，之前拉取的模型不会自动迁移，需要手动复制或重新拉取，或者直接在新目录里重新ollama pull。

2.2 下载速度慢的真正解法

官方源下载模型经常卡住，尤其是几十 GB 的大模型。我碰到的情况是下载到一半就断，重试还是断，非常折磨。这里有一个很实用的组合办法：

  • 设置代理环境变量（如果有条件），HTTPS_PROXY指到本地代理端口，Ollama 会走这个通道下载。
  • 如果不想依赖代理，可以用 HuggingFace 上的 GGUF 版本，手动下载后用ollama create导入本地文件。
# 示例：手动导入 GGUF 模型 ollama create my-model -f Modelfile

Modelfile 内容很简单，指向你本地下载好的 GGUF 文件即可。这个方式的好处是下载过程可控，支持断点续传工具，而且能顺便把模型文件整理到统一目录。

2.3 离线安装包的迁移动线

如果目标机器完全没网，或者下载死活拉不动，先在一台网络通畅的机器上把 Ollama 安装包和模型文件都下好，然后拷贝过去。Windows 下直接把.ollama目录整个拷贝到目标机器的用户目录，设置好OLLAMA_MODELS环境变量，启动 Ollama，ollama list就能看到模型已经就位。

这块有一个容易踩的细节：模型文件里包含了索引信息和 blob 文件，拷贝的时候要保证整个.ollama目录完整，不能只拷贝一部分。我见过有人只把 models 子目录考过去，结果ollama list能看到名字但一调用就报 manifest 错误。

3. WorkBuddy 接入配置与“无输出”问题全排查

3.1 WorkBuddy 的模型配置长什么样

WorkBuddy 的模型配置入口通常是在设置页面，或者配置文件里指定 Base URL 和模型名。以 OpenAI 兼容接口为例：

  • Base URL:http://127.0.0.1:11434/v1
  • API Key: 随便填一个占位符，比如ollama
  • 模型名: 必须和ollama list里的名字完全一致

很多人“无输出”的第一个原因就是模型名没匹配。比如ollama list显示的是qwen2.5:7b，但 WorkBuddy 里填了qwen2.5-7b，这俩就差一个冒号的问题，API 直接给你 404 或者空响应。最好的习惯是先去终端跑一遍ollama list，把模型名原样复制过去。

API Key 这个点也有讲究。Ollama 默认不校验 key，但 WorkBuddy 可能要求非空，所以填什么都能过。如果后面配了 Nginx 反代加上自定义鉴权，那 key 就要和反代层对应起来，这部分到第五节再说。

3.2 无输出的第一层排查：先验证底层 API

WorkBuddy 界面上看不到输出，先把 WorkBuddy 丢一边，直接用 curl 测试 Ollama 接口是否正常。这一步非常重要，能把问题切成两半：Ollama 的问题还是 WorkBuddy 的问题。

# 测试聊天补全接口 curl http://127.0.0.1:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2.5:7b", "messages": [{"role": "user", "content": "说一句话"}] }'

如果 curl 返回正常 JSON，里面有content字段，说明 Ollama 这边没问题，问题出在 WorkBuddy 的配置。如果 curl 直接报错，那就要看 Ollama 服务日志。

这个验证动作看起来简单，但真的能省大量时间。我排查无输出问题时，前两次都以为是 WorkBuddy 配置问题，后来一 curl 才发现 Ollama 服务根本没起来，只是因为 Windows 服务里显示正在运行，实际进程已经僵死。

3.3 无输出的第二层排查：Ollama 服务日志

如果 curl 都挂了，看日志是唯一高效路径。Windows 下 Ollama 日志在%LOCALAPPDATA%\Ollama\server.log，Linux 下看 systemd 日志：

journalctl -u ollama -f

或者直接前台跑：

ollama serve

前台模式的好处是日志直接打到终端，排查起来最直观。常见日志错误大概有这几类：

  • 显存不够，模型加载失败，进程直接退出
  • 模型文件损坏或 manifest 缺失，加载时报错
  • 端口被占用，Ollama 起不来

我这次碰到的问题就是：Ollama 服务起来了，但模型加载到一半显卡显存爆了，服务直接退出，WorkBuddy 那边显示的就是“无输出”。因为 WorkBuddy 对连接断开没有特别明确的报错，就把我误导到了配置方向上。

3.4 无输出的第三层排查：WorkBuddy 侧的工具调用问题

如果 curl 正常但 WorkBuddy 仍然没输出，问题就坑了。我发现 WorkBuddy 这类代理工具在调用模型时，并不是简单发一个 user 消息，它可能会带上 tool call 相关的结构化要求，比如让模型输出特定 JSON 格式，或者声明支持 function calling。

Ollama 对不同模型的 tool calling 支持程度不一致。有些模型虽然能对话，但 tool call 能力很弱，API 返回的 content 是空的，只返回tool_calls字段，而 WorkBuddy 又没能正确解析这个字段，结果界面上一片空白，看起来就是“没反应”。

这种问题怎么快速判断？还是回到 curl，但这次要模拟 WorkBuddy 的请求，加上tools参数：

curl http://127.0.0.1:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2.5:7b", "messages": [{"role": "user", "content": "调用工具做某件事"}], "tools": [{"type": "function", "function": {"name": "search", "description": "搜索", "parameters": {"type": "object", "properties": {}}}}] }'

看返回结果是正常回复还是空 content。如果空 content，基本可以断定是 tool call 兼容问题。我的解法是：不干掉 tool call，而是换一个 tool call 能力强的模型，实测 qwen2.5 系列对 tool calling 支持得不错，部分 8B 以下的旧模型确实拉胯。

提示：Ollama 的 tool calling 兼容性取决于模型本身是否训练过 function calling 数据。不要指望所有模型都能在 WorkBuddy 里完美工作。

4. 性能调优记录：从几十秒回一个词到 70 tok/s

4.1 影响输出速度的关键因素

先明确一个概念：tok/s 是每秒生成的 token 数。70 tok/s 意味着一个 500 字的回答大概 7 秒能生成完，这个速度在对话场景已经可以让人比较自然地阅读。影响这个数字的因素从大到小排列：

  • 模型参数量与量化等级：7B 和 32B 的速度差距接近 4 到 5 倍。
  • 上下文长度：上下文越长，KV Cache 占用越大，计算量也越大。
  • 并发请求数：多个请求同时进来，单请求速度会被稀释。
  • 硬件平台：GPU 显存带宽、内存带宽、是否支持 bfloat16 等。

我最终的配置是：qwen2.5:7b 量化版，上下文 4096，并发 4，走OLLAMA_FLASH_ATTENTION=1和 GPU 加速。这个组合在 8GB 显存下刚好放得下模型加 KV Cache，GPU 推理的速度就上来了。

4.2 关闭思考过程模型：一个容易忽略的香饽饽

如果用的是带思考过程的模型，比如 gemma4 这类，默认情况下每回答一个问题，模型会先输出一大段内部思考内容，再输出正式回答。对 WorkBuddy 来说，这段思考过程会占掉大量 token，而且速度看着很慢——因为你把思考时间也算进等待里了。

关闭思考过程的方法因模型而异。在 Ollama 里，有些模型通过 prompt 里加特殊标记控制，有些支持 API 参数。实测更靠谱的方式是用 Modelfile 定制一个关闭思考的版本。

# Modelfile 示例 FROM gemma4:latest PARAMETER temperature 0.7 SYSTEM "You are a helpful assistant. Do NOT show your internal reasoning. Provide final answer directly."

然后执行ollama create gemma4-direct -f Modelfile，在 WorkBuddy 里用这个新模型名。这一招直接把速度翻了一倍不止，因为思考过程通常占整段输出的一半以上。

4.3 调优后终见 70 tok/s

经过上面一轮修改，我的ollama list里有两个 gemma 系模型，一个是原始的，一个是关闭思考的。WorkBuddy 里挂的是关闭思考的版本。最终实测输出速度稳定在 68-72 tok/s 之间，和网上类似配置的评测数据基本一致。

这个数值说明：本地模型在消费级硬件上已经完全能胜任对话和轻量写作任务。如果你也需要做代码补全或者多步推理，建议选 7B-14B 区间的 qwen2.5 或 llama3.1 系列，性价比最高。再往上，没大显存直接就崩了。

5. 高频问题速查与最终配置参考

5.1 常见问题速查表

现象可能原因解决方案
Ollama 500 Internal Server Errorllama-server 进程启动失败看日志，通常是显存或内存不足，换更小模型或降低上下文
WorkBuddy 无输出模型名错误、tool call 不兼容用 curl 验证 API，确认模型名完全一致
下载慢/下载中断网络问题使用代理、离线导入 GGUF、HuggingFace 手动下载
模型路径错误OLLAMA_MODELS 未设置新建环境变量指向目标目录，重启服务
速度慢没关思考过程、上下文过长定制 Modelfile 关闭思考、调低 num_ctx
模型加载失败Ollama 服务未启动前台跑ollama serve看日志

这个表是我个人排障的顺序。先看服务，再看 API，最后才怀疑应用配置，这个顺序可以帮你快速定位 80% 的问题。

5.2 Nginx 反向代理加 API Key 鉴权

如果 WorkBuddy 和 Ollama 不在同一台机器，或者你想要一层访问控制，可以用 Nginx 反代。热词里有“nginx 代理 ollama 设置 apikey cherrystudio”，这个思路和 cherrystudio 类似，本质都是让 Ollama 暴露一个带鉴权的地址。

location /v1/ { proxy_pass http://127.0.0.1:11434/v1/; proxy_set_header Host $host; if ($http_authorization != "Bearer your-secret-key") { return 401; } }

这个配置要注意一点：Ollama 的 API 本身不校验 key，所以必须靠 Nginx 这层来挡。WorkBuddy 那边填的 API Key 就填your-secret-key，Base URL 填 Nginx 的地址。实测下来很稳，但这层会引入一点点网络开销，局域网内基本感知不到。

5.3 WorkBuddy 系统缓存目录修改

WorkBuddy 的 skill 和会话记录会占不少空间，默认放系统盘的话也会有容量焦虑。热词里提到“workbuddy怎么更改系统缓存目录”，我实测的设置方式是在配置文件里指定缓存路径。操作方法类似大部分桌面工具：找到设置里的存储/缓存选项，手动指向新目录，改完重启应用。

如果找不到图形入口，直接在新路径下建目录，然后看配置文件里的绝对路径字段有没有，有就改。这个操作对大多数人来说够用了。

5.4 WorkBuddy 与 CodeBuddy 的关系

网上不少人会问这两个是不是同一个东西。简单说：CodeBuddy 定位是编码助手，WorkBuddy 更像一个通用 AI 工作台，偏向文档处理、流程编排这类的 agent 场景。两者可以配合使用，但不要混为一谈。如果你想在自己的工作流里都用本地模型，两个工具接 Ollama 的思路是一样的，就是配 Base URL 和模型名，所以这篇里的排查思路完全通用。

6. 最后一公里的经验总结

跑通一次完整流程后，我个人的体会是：接入本地模型的难点不在配置本身，而在“沉默的失败”太多了。云 API 挂了会明确报 4xx、5xx，本地 Ollama 进程崩了你可能就只看到一个空白对话。所以好用的习惯是，任何改动之后先去终端里用 curl 打一发，确认底层 OK 再回应用层看。

另外一个小技巧：如果 Ollama 服务频繁崩，先不要怀疑 WorkBuddy，把num_ctx从默认的 2048 提到目标长度之前，先在 config 里把上下文调低试跑，稳定了再往上加。这个顺序能帮你把“模型加载失败”和“性能不足”两类问题分清楚。

最后再分享一个从这次折腾中受益的决策：WorkBuddy 的 skill 配置里，把普通对话和代码生成分成两个模型入口。对话用关闭思考过程的高速度小模型，代码生成用能力更强的大一点模型。虽然切换有成本，但整体体验比一个模型打天下舒服得多。