WorkBuddy 接入 Ollama 本地模型：从无输出到 70 tok/s 的踩坑实录

先说一句，我前阵子把日常一直在用的 WorkBuddy 接上了本地 Ollama 模型，整个过程远比我想象的坎坷。最离谱的是，配置完成后界面上一片空白，日志里却明明白白显示请求已经到了 Ollama，模型也正常加载了，可它就是一个字都不输出。后来从模型名到参数一路排查，折腾了好几天才把速度从个位数 tok/s 拉到 70 tok/s。这篇文章就把这次完整踩坑过程记录下来，包括 WorkBuddy 怎么配置 Ollama、常见“无输出”问题出在哪、性能瓶颈怎么定位，以及那些文档里根本不会写的细节。如果你也准备把 WorkBuddy 这类 AI 工作台接到本地模型上，这篇应该能帮你省下不少时间。

1. 为什么把 WorkBuddy 接到 Ollama 本地模型

先说两个名词，避免后面看得一头雾水。

1.1 WorkBuddy 是做什么的

WorkBuddy 是一个以“技能包”为核心的 AI 工作台，你可以把它理解成一个能调用工具、能读写文件、能执行命令的编程/办公助手。跟直接用网页版对话不同，它更偏向“干活”：比如让它扫描一个目录、归纳 PDF、批量处理文本、自动跑脚本，甚至配合 Cursor、IDEA 这类编辑器做一些代码层面的辅助。它内置的 Skill 机制可以把一系列操作封装成语义化的技能，用的时候直接让 WorkBuddy 调用，不用每次重新描述需求。

它跟 CodeBuddy 通常是配套出现的，前者偏全栈助手，后者偏代码场景。我这里用的 WorkBuddy 是桌面客户端版本，底层通过配置对接不同的模型后端。默认情况下它会优先走云端服务，但如果你想保护数据、不想按 token 付费，或者只是想体验一下完全本地化运行的 AI 工作流，那把它切到 Ollama 本地模型是成本最低的方案。

1.2 Ollama 解决什么问题

Ollama 是目前把本地大模型“服务化”最省事的工具之一。它解决的核心问题有两个：一个是模型下载和版本管理，另一个是把模型包装成标准 HTTP 接口。你只要执行一条ollama pull qwen2.5:7b，它就会把模型拉到本地；执行ollama serve，它就会在 11434 端口暴露一个 API 服务。关键是它同时提供了原生接口/api/chat和 OpenAI 兼容接口/v1/chat/completions，后者让 WorkBuddy 这种为 OpenAI API 设计的工具几乎可以“零改造”接入本地模型。

当然，Ollama 并不是唯一的选择，像 LM Studio、llama.cpp 也都能做同样的事。但 Ollama 在模型管理、GPU 自动卸载、并发请求处理上做得更顺手，生态也最大，网上能搜到的坑基本都被踩过了。这也是我最终选它的原因。

1.3 方案选型思路

我这次的目标很简单：让 WorkBuddy 所有对话和工具调用都走本地模型，不依赖外部网络。这就意味着模型的指令跟随能力必须够用，因为 WorkBuddy 这类工具对模型有两个隐性的高要求：一是要能理解复杂指令，二是要支持函数调用，也就是 tool calling。如果模型不支持工具调用，WorkBuddy 可能在第一步就让模型“写文件”时卡住，因为它需要模型返回结构化的调用参数，而不是一段自然语言。

基于这个前提，模型选择大致划出这么个标准：7B 到 14B 尺寸、需要支持 function calling、量化等级优先考虑 Q4 或 Q5。为什么不是大模型？因为本地运行要考虑显存和速度。7B 模型 Q4 量化后大概 4GB 多，8GB 显存的显卡能完整塞进 GPU，速度能跑到 70 tok/s 左右；如果上了 14B，显存不够就会有一部分层跑到 CPU，速度立刻掉到个位数。这个取舍在后面性能章节会详细展开。

2. 环境准备：安装、下载、模型选择

这篇虽然是踩坑记录，但前置环节的坑也不少，而且后面很多怪问题的根源就在安装和模型选择上。

2.1 Ollama 安装细节

安装本身不复杂，Windows 下直接下载安装包一路下一步，macOS 和 Linux 也都有对应安装方式。但有几个点容易被忽略：

第一，安装完成后ollama serve会以系统服务的形式后台运行，默认监听127.0.0.1:11434。如果你改了 OLLAMA_HOST 或防火墙策略，后面 WorkBuddy 连不上时，优先怀疑这里。

第二，模型存储目录。Windows 默认在C:\Users\你的用户名\.ollama\models，Linux 在~/.ollama/models。这个目录非常吃硬盘，一个 7B 模型加量化文件要 4-6GB，如果你装几个模型，C 盘很快就被塞满。我建议在安装之后立刻设置环境变量OLLAMA_MODELS指向其他盘，实测迁移现有模型也没那么麻烦，先把 ollama 服务停掉，移动目录，再改环境变量，重新ollama serve就能识别。

第三，下载慢的问题。ollama pull拉模型时，如果发现速度极慢，别急着反复重试。我用支持断点续传的下载工具配合官方命令会稳很多，另外挑网络空闲时段操作也有效。下载本身是分块进行的，中断后重新ollama pull会从断点继续，不会从头开始。

2.2 本地模型怎么选

这里直接给结论，后面有问题再细说。如果你是想让 WorkBuddy 能干活而不是单纯聊天，优先从下面几类里选：

• qwen2.5:7b：我对这个模型的评价是“本地工具调用最稳的 7B”，指令遵循能力强，函数调用失败率低，中文场景尤其舒服。
• qwen2.5:14b：显存 12GB 以上的可以考虑，理解能力更强，但速度会比 7B 慢一截。
• llama3.1:8b：英文场景的经典款，tool calling 设计很规范，但中文能力明显弱于 qwen。
• gemma3:4b/gemma3:12b：轻量，可在某些场景会进入思考模式，如果你不想看到冗长的思考过程，需要在配置里做处理，后面会提到。

我最后选的是qwen2.5:7b，量化标签默认就是 Q4_K_M，兼顾体积和质量。如果你对速度有更高要求，也可以试qwen2.5:7b:q4_0，体积更小速度更快，但回复质量会略有下降。

2.3 先让 Ollama 自己跑起来

在接入 WorkBuddy 之前，一定要先在 Ollama 层面验证模型能否正常工作。这个验证步骤能帮你把问题范围缩小一半。我习惯分三步：

第一步，确认服务在跑。浏览器访问http://localhost:11434/api/tags，如果能看到 JSON 格式的模型列表，说明服务正常。

第二步，命令行直接跑模型。执行：

ollama run qwen2.5:7b "把这句话翻译成英文"

能正常回复，说明模型本身没问题。

第三步，用带速度统计的方式跑一次：

ollama run --verbose qwen2.5:7b "讲一个冷笑话"

--verbose会在输出结束后打印eval rate，也就是每秒生成 token 数。如果这一步只有个位数 tok/s，那后面对接 WorkBuddy 再快也快不到哪去，性能问题要先在 Ollama 层面解决。

这三步做完，Ollama 这个“后端服务”就是健康的。接下来才轮到 WorkBuddy 的配置。

3. WorkBuddy 对接 Ollama：配置与参数理解

WorkBuddy 的配置界面和文件结构可能因为版本不同略有差异，但核心概念是一致的：添加一个自定义 Provider，告诉它模型的 API 地址、API Key、模型名，然后调整一些生成参数。

3.1 Provider 与 Base URL

WorkBuddy 添加模型提供商时，一般会要求填 Base URL。这里要填的是 Ollama 的 OpenAI 兼容接口地址，不是原生接口。也就是：

http://localhost:11434/v1

注意一定要带/v1。我见过很多教程让填http://localhost:11434，结果 WorkBuddy 内部会用这个地址拼出/v1/chat/completions路径，如果你漏掉了/v1，它就变成了http://localhost:11434/v1/chat/completions的前半段不对，404 是轻的，有时候会请求超时。

如果你打算让局域网里的另一台设备连这台机器上的 Ollama，需要先给 Ollama 加上OLLAMA_HOST=0.0.0.0:11434环境变量，再重启服务。此时 WorkBuddy 里的 Base URL 填http://局域网IP:11434/v1。但这么做要小心，等于把本地模型服务直接暴露给了局域网，建议只在可信网络里开。

3.2 API Key 和模型名怎么填

接着是 API Key。Ollama 自己压根不校验 Key，所以你随便填一个字符串占位即可，WorkBuddy 只是需要这个字段存在。

模型名就重要了。这里填的模型名必须和ollama list输出里的 tag 完全一致，包括冒号和版本。比如qwen2.5:7b，多一点少一点都会导致模型加载失败。而且注意别在 WorkBuddy 里填完整路径，它不需要你填~/.ollama/models/...那种路径。

如果填错了，现象通常是：请求发出去，Ollama 返回 HTTP 400 或 404，WorkBuddy 界面上表现为“无输出”，或者弹一个模型不存在的报错。有个小技巧：先在 WorkBuddy 里选完模型后，用 WorkBuddy 自带的“测试连接”功能，看返回内容里是否包含了模型列表。如果测试成功但对话没反应，那问题大概率出在模型的实际推理上。

3.3 上下文长度和生成参数

Ollama 的默认上下文长度其实是 2048 或 4096，不同版本不太一样。WorkBuddy 这类工具在分析长文件、读 PDF 时，往往需要更长的上下文。如果上下文不够，你让 WorkBuddy 读一个长文本，它会“卡住”，随后输出被截断，或者干脆只字不出。

我建议直接把上下文长度调到 8192 起步，具体做法是在 Ollama 的服务环境变量里加：

OLLAMA_CONTEXT_LENGTH=8192

注意，这个变量是服务级别的，作用于所有模型。改完之后需要重启ollama serve进程才能生效。

还有一个参数是num_predict，它控制模型最多生成多少 token。Ollama 默认只有 128，这在短对话里够用，但让 WorkBuddy 写一段完整代码时会戛然而止。在 OpenAI 兼容接口里，这个参数对应max_tokens。WorkBuddy 的配置界面一般也有 Maximum Tokens 或 Max Output Tokens 选项，我直接设到了 4096，避免长回答被腰斩。

至于 temperature，建议别调太高，0.3-0.7 之间比较适合任务型工具。温度太高会让模型“发挥过度”，函数调用参数偶尔会生成错格式。

3.4 验证连通性的三种方法

配置完成后，先用三种方法验证，避免直接进 WorkBuddy 里瞎猜。

第一种，用curl直接测 OpenAI 兼容接口：

curl http://localhost:11434/v1/models

看看能不能正常返回模型列表。

第二种，发一条真实对话请求，关闭流式输出：

curl http://localhost:11434/v1/chat/completions -H "Content-Type: application/json" -d '{ "model": "qwen2.5:7b", "messages": [{"role": "user", "content": "你好"}], "stream": false }'

注意看返回里有没有choices[0].message.content字段。如果这里能正常输出，说明 WorkBuddy 连接之后理论上也能拿到内容。

第三种，在 WorkBuddy 里跑一条最简单的指令，比如“用中文回复‘测试成功’”。如果这一步都不出字，再回头检查前两种测试，基本能定位问题在 WorkBuddy 侧还是 Ollama 侧。

4. 实战复盘：从“无输出”到 70 tok/s 的完整排查记录

这一章是重头戏，我把我遇到的所有故障按顺序贴出来，包括当时的判断和修复方式。

4.1 故障一：配置完成后完全无输出

先说现象。WorkBuddy 里配置好了 Base URL、模型名，点击发送后，界面没有任何输出，既不报错也不生成文字。反观 Ollama 的日志，服务端确实收到了请求，模型也加载了，看起来一切正常。

我的排查路径是这样的：

第一步，确认 WorkBuddy 日志。在它的日志里看到请求返回了 HTTP 200，但响应体异常。这说明请求已经打通，问题出在响应内容的解析上。

第二步，用curl手动模拟同样的请求，返回值是完好的。这时候我意识到，WorkBuddy 发送的请求格式跟我的curl不一样。我回头一看，发现 WorkBuddy 在请求里默认带了tools参数（函数调用定义），而某些模型或者某些版本的 Ollama 在处理工具定义时，会返回异常的响应结构：要么把工具调用放在空的message里，要么整个content字段为空。

这就是“无输出”的根源之一：WorkBuddy 把工具调用请求发给 Ollama，Ollama 返回了一个空的工具调用结果，WorkBuddy 以为模型还在生成，一直在等，界面自然一片空白。

解决方案有几个，按优先级排列：

• 换一个支持工具调用的模型，比如qwen2.5:7b。这是最省事的。
• 如果模型本身支持但表现不稳定，尝试在 WorkBuddy 里关闭工具调用功能。
• 更新 Ollama 到较新版本，旧版本在函数调用兼容性上有一些坑。

我最终选的是换qwen2.5:7b，从那以后这种“空响应”问题基本消失。

4.2 故障二：有输出但只有一小段，然后被截断

换模型之后，WorkBuddy 能出字了，但是回复经常停在很尴尬的位置，感觉像是正说到一半突然闭嘴。一开始我以为是模型能力不行，后来实测发现是num_predict默认值太小，模型生成到 128 个 token 就被叫停了。在 WorkBuddy 里表现就是：它可能只输出半句代码注释，或者一条命令只写了一半。

解决方式就是前面提过的，把 WorkBuddy 里最大输出 token 调到 4096，同时给 Ollama 服务端设置更大的上下文长度。这里有个容易踩的坑：很多人只在 WorkBuddy 里改了max_tokens，但 Ollama 侧的服务级上下文长度没改，结果长对话仍然会报错或者截断。两个地方需要同步调整，缺一不可。

4.3 故障三：输出正常但不回应工具调用

还有一个非常隐蔽的问题：WorkBuddy 输出文字正常，但在让它“读文件”或者“执行命令”时，它只是描述自己接下来要做的事，而不会真正调用工具。比如我说“扫描当前目录下的 md 文件并总结”，它会说“好的，我准备扫描了”，然后就没有下文。

这个问题的本质是模型不会生成工具调用结构。检查方式很简单，在 WorkBuddy 日志里看单个请求，如果返回内容里没有任何tool_calls字段，只出现在content里，就说明模型把“调用工具”理解成了“描述调用”。此时如果你在模型列表里用的是通用聊天模型，它就可能不具备工具调用的能力。

解决办法就一条：换成专门支持 function calling 的模型。实测下来，qwen2.5:7b和llama3.1:8b这类模型在 Ollama 的 OpenAI 兼容接口下都能稳定返回tool_calls字段。如果你用的是很老的模型，或者是一些 0.5B、1.5B 的小玩具模型，它们在工具调用上的表现会非常差，会出现“说了要调用却不调用”的尴尬情况。想让 WorkBuddy 真正干活，模型能力下限不能放太低。

4.4 故障四：速度只有个位数 tok/s，怎样才能跑到 70 tok/s

功能全部打通之后，速度问题浮出水面。最开始我用默认参数跑qwen2.5:7b，速度只有 8 tok/s 左右，一句话要等半天。这种速度拿来聊天都费劲，更别说干活。我后来把速度提到 70 tok/s，靠的是下面几个调整。

第一步，看模型是否完整跑在 GPU 上。执行：

ollama ps

这个命令会显示当前加载模型的处理器占用情况。如果PROCESSOR列显示100% GPU，说明显存足够，模型全在显卡里跑；如果显示100% CPU或者XX% GPU / XX% CPU，说明有部分计算落到了 CPU 上，速度必然上不去。

我当时的机器是 8GB 显存，跑 7B Q4 模型显存占用大概 4.5GB，理论上是够的，但ollama ps居然显示部分层在 CPU。查了一下原因，原来是同时加载了其他模型，显存被占了一部分，Ollama 自动把新模型的一部分层溢出了。解决方案很简单：用ollama stop停掉不用的模型，再重新加载目标模型。

第二步，检查上下文长度。上下文越长，KV Cache 占的显存就越多。如果你把OLLAMA_CONTEXT_LENGTH设得太大，比如 32768，7B 模型也可能会因为显存不足而被迫把部分计算挪到 CPU。经验值：8GB 显存跑 7B 模型，上下文 8192 到 16384 是比较稳妥的范围，再往上就要看显卡脸色了。

第三步，适度降低量化等级。默认的q4_k_m已经不错，但如果你追求速度，可以换q4_0，它体积更小、计算量更低。不过这会带来一点点质量损失，实测在 WorkBuddy 的普通指令场景里感知不强。

第四步，避免并发抢算力。如果同时开着多个请求，Ollama 会把模型并发执行，tok/s 会明显波动。WorkBuddy 如果没有特殊需求，把并发数保持在 1 就行。多个模型同时加载也尽量别做，Ollama 虽然支持，但多模型共享显存时，单个模型速度会被拖累。

整套调整完，我重新执行ollama run --verbose，速度显示 70 tok/s 左右，WorkBuddy 里的体感也明显变快。整个过程的核心逻辑就是：让模型完整留在 GPU 里，并且别让上下文长度把显存吃光。

4.5 最终成绩单

最后给个直观的数据参考。我的环境如下：

• 系统：Windows 11
• 显卡：RTX 4060 Laptop 8GB
• 模型：qwen2.5:7b (Q4_K_M)
• 上下文长度：8192
• 负载：单用户、单并发
• 平均生成速度：稳定在 65-72 tok/s
• 首次响应延迟：约 0.3-0.6 秒

这个速度对日常 WorkBuddy 使用已经相当舒适，写一段 500 字的总结大概 7-8 秒，读文件做归纳也不会有明显的“卡顿感”。如果你机器比我强，比如 12GB 或 16GB 显存，可以考虑直接用qwen2.5:14b，速度和理解能力都会更均衡。

5. 常见问题速查与避坑实录

最后一个部分，把踩过的坑和听朋友踩过的坑整理成速查，方便以后直接翻。

5.1 常见问题速查表

5.2 值得记住的几个隐藏参数

除了上面提到的OLLAMA_MODELS、OLLAMA_HOST、OLLAMA_CONTEXT_LENGTH，还有两个参数在实战里很有用。

第一个是OLLAMA_DEBUG=1。把它设为 1 后，Ollama 会打印详细的调度和显存信息。当你怀疑某个请求没走 GPU 时，打开这个日志能直接看到每层的调度位置，比猜快了太多。

第二个是OLLAMA_NUM_PARALLEL。它控制单个模型允许的并行请求数，默认值可能因版本而异。如果你发现多个请求排队很严重，可以适当调大，但代价是每个请求的速度会下降。我建议 WorkBuddy 单用户使用就保持默认。

另外，关于关闭 Gemma 系列模型思考过程的问题，我实测过一种做法：在 Ollama 较新版本中可以通过环境变量或请求参数关闭推理思考，但不同版本支持程度不一样。如果懒得折腾，直接换qwen2.5:7b是最省心的，它默认不会输出冗长的思考过程。

5.3 我的习惯操作与经验心得

折腾完这一圈，我形成了一套固定的操作习惯，每次换机器换环境都按这套来：

第一步，装完 Ollama 立刻设三个环境变量：OLLAMA_MODELS指向数据盘、OLLAMA_CONTEXT_LENGTH=8192、OLLAMA_DEBUG=1。调试一段时间后再关掉 DEBUG，避免日志刷太多。

第二步，先拉两个模型：qwen2.5:7b作为主力，再拉一个 1.5B 小模型专门用来测试连通性。小模型加载快，排查配置问题时能省不少时间。

第三步，所有配置改动都按“先测 Ollama，再测 WorkBuddy”的顺序来。也就是说，任何参数修改后，先用ollama run --verbose验证模型行为和服务端性能，再回 WorkBuddy 里重试。这个顺序能让我快速分清问题是模型层的还是工具层的。

个人体会是，WorkBuddy 接本地模型这件事，真正的门槛不在工具配置，而在模型选型和硬件匹配。如果你愿意在这两步上多花点时间，后面的使用体验会顺畅很多。

最后再说一个小技巧：如果你在 WorkBuddy 里换了好几次模型配置还是觉得不稳定，不妨把 Ollama 彻底重启一次，同时把所有无关模型停止加载。很多“配置没问题但就是用不了”的诡异现象，其实就是模型缓存加载状态乱了，重启一下就能解决。这个操作很朴素，但它真是我这次踩坑记录里用得最多的“解药”。