WorkBuddy接Ollama本地模型：无输出到70 tok/s完整配置指南

如果你也把 WorkBuddy 的模型端点从云端 API 切到本地 Ollama，大概率会碰到我遇到的第一个“惊喜”：界面转了几圈，模型名也填了，请求看起来也发出去了，结果回答区域干干净净，一个字都没有。作为把 WorkBuddy 当成日常生产力工具的人，我本来想让它完全跑在本地模型上，省掉 API 费用，也避免把文档内容送到外部。结果整整折腾了一天，从“无输出”到最终稳定跑出 70 tok/s，中间踩过的坑几乎能写成一本地图。这篇就按我的实际排查时间线来记，希望你能绕开我走的那几个小时弯路。

这篇内容适合谁？如果你正在 WorkBuddy 里配置 Ollama 本地模型，或者你只是想把任何一款带 OpenAI 兼容接口的应用接到 Ollama 上，本文都适用。我会把安装、模型选择、Base URL 填法、无输出问题、500 错误、速度优化这些关键环节全部拆开讲，给你能直接照抄的配置，也给你排查时用得到的命令。废话不多说，直接进入正题。

1. 为什么我在 WorkBuddy 里接 Ollama 而不是云端 API

1.1 这两张牌先摆到桌面上

WorkBuddy 本质上是一个“生产力工作台”，你可以把它理解成把提示词、技能、模型调用、工作流组合在一起的编排工具。很多人分不清 WorkBuddy 和 CodeBuddy，简单说，CodeBuddy 更偏代码场景，WorkBuddy 更通用，适合跑文档处理、科研辅助、日常事务管理这类流程。WorkBuddy 本身不带大模型能力，它需要接一个模型服务，默认接云端 API，也可以在模型管理里接外部服务。

Ollama 是目前最流行的本地模型运行时，底层用的 llama.cpp 那套推理方案，一句命令就能拉起 qwen、llama、gemma 这些开源模型，并且默认就提供 HTTP API。更重要的是，Ollama 兼容 OpenAI 的接口格式，所以 WorkBuddy 这类客户端只需要知道 Base URL、模型名、API Key 三个信息就能工作。这也是我选它的核心理由：不用额外写中间层，不用改 WorkBuddy 的代码。

1.2 本地模型和云端 API 的真实差异

我先把丑话说在前面：本地模型不是万能的。我坚持接 Ollama，主要看中三件事。

第一是数据隐私。我经常拿 WorkBuddy 处理内部文档和文献材料，这些内容如果走云端 API，等于要把文本片段发到别人的服务器上。虽然各大厂商都有隐私协议，但内容敏感时心里总有根刺。接本地模型后，请求全程在本机 11434 端口上完成，只要你的机器没被入侵，数据不会出本机。

第二是成本。云端 API 按 token 计费，日常草稿、批量总结、重复实验这些场景，花钱跟流水一样。本地模型运行一次，电费几乎可以忽略，模型文件也是免费下载的开源权重。

第三是可玩性。Ollama 换模型就是一条命令的事，今天跑 qwen2.5，明天跑 llama3.2，完全不用改 WorkBuddy 的配置，只改模型名就行。这对喜欢反复试模型参数的人来说是刚需。

但本地模型的短板也很明显：参数量小的模型，复杂逻辑处理能力弱；参数量大的模型，对内存和显卡要求高；如果机器没有 GPU，速度会很难看。我最后选择了 qwen2.5 的 3B 量化版，跑在 M 系列芯片上，速度和质量的平衡点刚好够用。如果你要跑 70B 那种模型，请先确认自己的显存，别被“本地免费”四个字冲昏头。

1.3 什么时候不建议用本地模型

我也把劝退条件写在这里。如果你的工作流重度依赖 function calling，也就是把“调用工具”“操作文件”“访问网页”这些动作交给模型自动决策，那么 3B、7B 这些小模型会表现得很吃力。它们可能无法稳定输出结构化的工具调用参数，导致 WorkBuddy 的 Skill 流程中断。

同样，如果你需要处理 20 万 token 以上的超长文档，本地小模型的上下文窗口根本撑不住，硬开长上下文只会让显存爆掉、速度掉到个位数 tok/s。这种需求就别折腾本地了，老老实实接云端大模型，至少省时间。

我的建议是：把本地模型用在小而明确的场景，比如单篇文档总结、格式化的写作辅助、固定模板的问答。复杂场景留给 WorkBuddy 调用云端 API 作为兜底，两边并存是最好的状态。

2. 环境准备与模型选择

2.1 安装 Ollama 和“下载慢”的处理办法

Ollama 的安装本身不复杂，去官网下载对应平台的安装包就行。但很多人栽在下载这一步，原因很简单：安装包默认从境外 CDN 分发，速度不稳定是常态，有时进度条动都不动。

我试过几种可行的办法，亲测有效：

• 优先走 GitHub Releases 里的离线安装包。Ollama 的 Windows 版和 macOS 版都有对应的安装包文件，直接下载比在线安装器稳定。
• 如果官网和 GitHub 都慢，就找知名高校或开源社区维护的镜像站。一定要认准官方文件名，比如 Windows 下的OllamaSetup.exe，下载完成后比对文件大小，防止下到损坏的半截包。
• Linux 下的安装建议直接看官方脚本内容，确认不会被自带脚本下载超时卡住后再执行。安装完第一时间验证版本。

这里有个很实际的坑：Windows 装完 Ollama 后，模型默认存在C:\Users\你的用户名\.ollama\models下。一个 3B 量化模型大约 2 到 3GB，7B 模型大约 4 到 5GB，多下几个模型 C 盘很容易爆红。我建议安装完立刻做一件事：在系统环境变量里新建OLLAMA_MODELS，值指向一个空间足够的大分区，比如D:\ollama_models，然后重启 Ollama。之后所有模型都会落到那个目录，以后删模型也方便。

2.2 模型选型：别听名字好听，要看实际用途

Ollama 的模型库一大堆，但能配合 WorkBuddy 干活的其实就那么几个方向。我按自己的使用场景来选型，你可以参考：

• 如果你主要做中文问答、文献综述、文档总结，qwen2.5 系列是最省心的选择。它的中文分词和指令跟随能力在开源小模型里属于第一梯队。
• 如果只是英文对话或简单 JSON 抽取，llama3.2 和 gemma 系列也够用。
• 如果追求极限速度，可以考虑 qwen2.5 的 1.5B 或 3B 版本，Flash Attention 加持下，轻载运行能到 70 tok/s 以上。
• 如果追求质量，7B 或 14B 的量化版可以试，但请确保内存充足。7B 的 Q4 量化模型大约 4.7GB，14B 大约 9GB，和你的业务场景匹配才是关键。

这里必须澄清一个热搜里的错误名词：很多人搜 “qwen3.5:2b”，但 Ollama 官方仓库里没有这个 tag。如果你按照这个名字填写模型名，大概率会触发500 internal server error: llama-server process，本质上是模型加载失败。正确做法是先执行ollama list查看本机已下载的模型，再在 WorkBuddy 里填和列表一致的 tag。

2.3 先用命令行把模型跑通，再谈接入

磨刀不误砍柴工。我建议所有人在打开 WorkBuddy 之前，先在终端里验证 Ollama 本身是好的。执行：

ollama run qwen2.5:3b

等模型下载完成后，输入一句简单中文，比如“你好，介绍一下你自己”。如果终端正常返回内容，说明模型推理逻辑没问题。然后按Ctrl+D退出对话。接着执行：

ollama ps

这个命令会显示当前加载的模型、它占用的显存、以及运行在 CPU 还是 GPU 上。如果PROCESSOR列显示100% GPU，说明推理加速正常工作。如果显示100% CPU，则后续速度大概率不乐观。你需要在 WorkBuddy 配置前先解决驱动或内存问题，否则后面排查速度问题时会被绕晕。

3. WorkBuddy 接入配置的完整流程

3.1 找到模型设置入口

WorkBuddy 的版本差异可能带来菜单名称不同，但一般都在“设置”或“模型管理”里。我用的版本路径是“设置 → 模型服务 → 添加自定义服务”。如果没有“自定义服务”选项，找找有没有“OpenAI 兼容接口”或“本地模型”相关入口。思路是一样的：填一个服务地址和模型标识，然后保存。

首次配置时，我建议先把 WorkBuddy 里的 Skill 全部停用，只保留一个最基础的空白对话。为什么？因为 WorkBuddy 的 Skill 本质上是把一大段系统提示词和工具定义塞给模型，本地小模型面对这么复杂的上下文，可能压根不干活。先排除这个变量，后面接进去再逐个恢复。

3.2 三个关键字段的正确填法

WorkBuddy 的模型服务配置一般就三项：Base URL、API Key、模型名。这三项错一个，表现都不是“报错”而是“玄学”。

Base URL 一定要填http://127.0.0.1:11434/v1。注意三点：第一，IP 用127.0.0.1或localhost都行，但两者在部分系统上有 IPv6 解析差异，求稳就写127.0.0.1。第二，端口是11434，这是 Ollama 默认端口，除非你改过环境变量。第三，URL 结尾要带/v1。Ollama 的 OpenAI 兼容接口是挂在/v1路径下的，WorkBuddy 会自动在后面拼接/chat/completions，如果你只填http://localhost:11434，它就会请求到不存在的路径上，表现就是请求看起来成功，但返回是空。

API Key 填什么？本地服务不做鉴权，按道理可以不填。但 WorkBuddy 这类客户端在构建请求时，如果检测到 API Key 为空，会直接不发起 HTTP 请求。所以你需要给它一个非空字符串，填ollama、local都可以，服务端不会校验内容。

模型名必须和ollama list输出的 tag 完全一致。比如你执行ollama list看到的是qwen2.5:3b，那么在 WorkBuddy 里就写qwen2.5:3b。如果你自定义过 Modelfile（后面会说），那就写你创建出来的自定义名字，比如qwen2.5-3b-fast。不要自作聪明只填qwen2.5，虽然 Ollama 有时会补全默认 tag，但 WorkBuddy 不一定按你的预期去补，零星错误就是这么来的。

3.3 用 curl 做一次连通性测试

在 WorkBuddy 里点保存之前，先在终端里模拟一次客户端请求，这一步能帮你把问题锁定在“Ollama”还是“WorkBuddy”侧。执行：

curl http://127.0.0.1:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2.5:3b", "messages": [ {"role": "user", "content": "用一句话介绍你自己"} ], "stream": false }'

正常的返回是一个 JSON，里面包含choices数组，choices[0].message.content就是模型回复。如果这一步返回正常，说明你的 Ollama 完全兼容 OpenAI 格式，接下来问题基本只在 WorkBuddy 侧。如果这一步报错，就把注意力放在 Ollama 的模型是否跑起来、端口是否通、模型名是否存在这三个点上，不要急着去 WorkBuddy 里瞎点。

4. 从“无输出”到稳定生成：排查过程实录

4.1 现象一：请求通了，但回答一直是空字符串

我第一次把配置填进 WorkBuddy 后，界面上的模型状态是“已连接”，发一句话也看到进度条转了一圈，可回复内容是空的。这种“无输出”最折磨人，因为不是硬报错，是让你觉得快成功了却什么都没出。

我当时的排查顺序：

• 先确认 Base URL。我把http://127.0.0.1:11434/v1错填成了http://127.0.0.1:11434，后面少了/v1。WorkBuddy 请求的完整路径变成http://127.0.0.1:11434/chat/completions，Ollama 对这个路径做了兼容性兜底吗？实际返回了404还是一个空结构，取决于版本，但客户端没有直接弹出错误。
• 再确认 API Key。留空时 WorkBuddy 不发请求，填了一个ollama后，请求就能正常到达。
• 最后确认模型回复内容结构。有些模型，特别是有思考模式的模型，会在返回里多一个reasoning字段，而正常的内容content是空的。WorkBuddy 如果只解析content，你看到的自然就是空白。这种情况不是 WorkBuddy 坏了，是你选的模型不支持你想用的交互方式。

解决思路很简单：先把模型换成不带思考模式的 instruct 版本。如果你一定要用带思考能力的模型，请检查 WorkBuddy 版本是否支持读取reasoning字段，或者干脆在客户端侧关闭思考模式。别在这上面死磕，Emmy实测下来，换一个普通 instruct 模型是最省时间的。

4.2 现象二：弹出 500 Internal Server Error，提示 llama-server process 崩溃

这个问题出现的典型时机是：我刚把模型名填成qwen3.5:2b并发出请求，Ollama 日志里立刻出现500 internal server error: llama-server process。很多人看到“llama-server process”就以为是 Ollama 安装坏了，其实大部分原因是模型 tag 不存在，或者模型文件损坏。

正确做法是执行：

ollama list

看列表里有什么 tag，再把你填的名称和列表做精确匹配。如果确实没有 qwen3.5 这个系列，改用实际的qwen3:2b或qwen2.5:3b。

还有一种情况是显存不足导致 llama-server 进程被系统杀掉。我用ollama ps看到模型已经加载，但请求一多就崩溃。此时要么换更小的模型，要么在 Modelfile 里把num_ctx调小，减少 KV Cache 占用。注意，即使你的模型只有 3B，如果上下文长度开到 32768，显存占用也会涨得飞快。崩溃之前没有任何前兆，点击发送后一两秒直接报 500。

排查时不要盯着 WorkBuddy 的弹窗看，去看 Ollama 的服务日志。Windows 下用任务管理器或者 Ollama 的托盘菜单，Linux 下用journalctl -u ollama，macOS 下直接从终端运行ollama serve看前台输出。日志里会告诉你到底是模型加载失败，还是显存分配失败。

4.3 现象三：本地模型能跑，但 WorkBuddy 的 Skill 一多就“失智”

模型接入成功之后，我开始测试 WorkBuddy 的“文献综述” Skill。这个 Skill 要求模型遵循一套很长的输出模板，还要输出特定格式的引用。结果模型要么胡言乱语，要么干脆输出空。

排查后我才意识到，这不是模型“坏了”，而是系统提示词太复杂。WorkBuddy 的 Skill 会把预设的规则、示例、工具说明全部放进上下文，小模型的注意力很容易被这些内容带偏。你可以想象成让一个新员工看了员工手册再加三份操作 SOP，然后让他立刻写报告，他大概率会卡壳。

解决办法有几条：第一，精简 Skill 的系统提示词，把目标描述压缩到两句话以内，把“不要做什么”改成“要做什么”。第二，给模型降低负载，在 WorkBuddy 里把并发数设为 1，防止多个任务抢占一个模型实例。第三，如果 Skill 必须用到工具调用，建议本地模型选择 7B 以上并确认它支持 function call，否则趁早切云端大模型。

4.4 现象四：速度慢得像乌龟，怎么提到 70 tok/s

这是让我最崩溃的环节。一开始我在 WorkBuddy 里问一个简单问题，要等十几秒，体感速度大概只有 10 tok/s 出头。后来我逐步做了四个调整，才把速度拉到稳定 70 tok/s。

第一个调整：确认 GPU 加速是否生效。在终端执行ollama ps，看PROCESSOR列。如果显示100% CPU，说明 Ollama 没有使用 GPU，可能是显卡驱动没装好，也可能是安装时没有正确选择硬件加速后端。macOS 上要注意 Ollama 需要 Metal 支持，Windows 上要注意对应显卡驱动。没有 GPU 加速，再小的模型也快不起来。

第二个调整：使用量化版模型。Ollama 默认下载的模型 tag 对应的是量化版本，但我之前从别处导入过一个 fp16 的 GGUF 文件，体积大速度快不了。建议用ollama pull qwen2.5:3b拉取官方量化版，或者用 4-bit 精度的 GGUF 自己导入。

第三个调整：控制上下文长度和批处理大小。这里就需要用 Modelfile 做参数覆盖。我在项目目录下创建一个文件，内容如下：

FROM qwen2.5:3b PARAMETER num_ctx 4096 PARAMETER num_batch 512 PARAMETER temperature 0.7

然后在终端执行：

ollama create qwen2.5-3b-fast -f Modelfile

创建成功后，ollama list会多出一个qwen2.5-3b-fast模型，在 WorkBuddy 的模型名里填这个名字。这里的原理很简单：num_ctx是模型能看到的上下文长度，默认往往是 2048，如果开大了会成倍增加计算量。num_batch是每次推理时一次喂给 GPU 的 token 数量，batch 太小会让 GPU 大部分时间在等待，batch 太大又容易爆显存。对于 3B 模型，4096 上下文和 512 batch 是比较甜的配置。

第四个调整：限制 Ollama 的并发和缓存占用。修改系统环境变量：

OLLAMA_NUM_PARALLEL=1 OLLAMA_MAX_LOADED_MODELS=1

让 Ollama 同一时间只加载一个模型、每个模型只服务一个请求。这对 WorkBuddy 这种单用户操作场景是合理的，避免多个模型实例在内存里抢占资源，反而拖慢单个请求。

做完这四个调整，我在 WorkBuddy 里再次测试，输出速度稳定在 70 tok/s。需要强调，这个数字和硬件强相关，我是在 M 系列芯片的 Mac 上跑 3B 量化模型得到的。你的电脑如果是 CPU 推理，或者跑 7B 以上模型，数字会不同，但优化方向完全一样。

4.5 现象五：系统缓存目录爆满，WorkBuddy 越来越卡

接上本地模型后，WorkBuddy 本身也会产生不少缓存，包括模板缓存、历史会话和索引数据。默认位置经常在系统盘，时间一长就会占用好几个 GB。如果你的机器 C 盘空间紧张，建议在 WorkBuddy 设置里找“高级设置”或“缓存目录”，把它改到其他盘。

如果 WorkBuddy 的设置项里没有这个开关，也可以直接对文件夹做目录联接。比如把原缓存目录里的内容复制到D:\WorkBuddyCache，然后删除原目录，再以管理员身份打开终端执行：

mklink /J "C:\Users\你的用户名\AppData\Roaming\WorkBuddy\Cache" "D:\WorkBuddyCache"

Windows 用mklink /J，macOS 和 Linux 用ln -s。这个操作本质上是给系统一个“假路径”，让 WorkBuddy 还以为缓存还在原处，但实际数据已经写到大分区。这样做能解决磁盘告急，但不要在执行过程中频繁移动，先退出 WorkBuddy 再操作。

5. 常见问题速查与避坑心得

5.1 高频问题对照表

把前几节的问题汇总成一张表，方便你直接对照：

这张表是我踩坑后的最终浓缩版。你可能不会全遇到，但遇到任何一个，都能按表里的思路先排查一圈。

5.2 我最后留下的稳定配置

给出一份可直接抄作业的配置清单，方便你照配：

• Ollama 版本：官方最新稳定版
• 模型：qwen2.5:3b，通过 Modelfile 自定义为qwen2.5-3b-fast
• Modelfile 参数：num_ctx 4096，num_batch 512，temperature 0.7
• 环境变量：OLLAMA_NUM_PARALLEL=1，OLLAMA_MAX_LOADED_MODELS=1，OLLAMA_MODELS=D:\ollama_models
• WorkBuddy 模型配置：Base URLhttp://127.0.0.1:11434/v1，API Keyollama，模型名qwen2.5-3b-fast

这份配置在我的场景下跑了一天，没再出现过空输出和 500。如果你第一次接入就是这套配置，大概率能免掉大部分折腾。

5.3 最后一条保命经验

我最大的体会是：本地模型和客户端之间的“适配”远比“模型质量”坑多。WorkBuddy 不会直接告诉你它内部请求用的是什么完整 URL，也不会替你做模型 tag 归一化，它只忠实于你填的字段。所以遇到问题，先别怀疑 WorkBuddy 是不是坏了，先用 curl 把 Ollama 接口测通，再逐项核对自己的配置。把每一步都拆成可验证的独立模块，问题通常会在半小时内露出马脚。

另外，如果你准备用 Ollama 接 Dify、Cherry Studio 或者其他工具，这套排查思路同样通用，核心永远是先验证底层 API，再调上层配置。本地模型这条路一旦跑通，工作和写作都不用再被云端绑定，那种踏实感是值得折腾这一天的。