WorkBuddy接入Ollama本地模型：从无输出到70 tok/s的完整优化指南

如果你最近在折腾 AI 工作台，肯定绕不开 WorkBuddy 和 Ollama 这两个名字。WorkBuddy 负责把日常编码、文档整理、问题检索都收拢到一个工作流里，Ollama 负责把这些工作流背后的推理能力跑在本地硬件上。把这两者接起来，意味着对话内容和代码片段都不用离开自己的机器。这篇记录讲的是我自己的完整接入过程：从配置好之后一句话都回不出来，到最终稳定在 70 tok/s，中间踩了不少坑，也把每个坑背后的原理摸清楚了。不管你是刚拿到 WorkBuddy 准备试本地模型，还是接好了但用起来很卡，这份记录都值得你照着过一遍。

1. 接入方案的选择：为什么用本地模型组合

1.1 WorkBuddy 与 Ollama 的分工

这里先说清楚两个角色。WorkBuddy 是一个 Agent 式的工作台，它本身不承担推理，负责的是需求理解、工具调用、上下文管理、结果整理。而 Ollama 是一个模型运行时，专门负责把 GGUF 格式的模型文件加载进显存或内存，提供标准的 HTTP 接口。Ollama 存在的意义在于：你不用自己处理 tokenizer、sampling、KV Cache、并发调度这些东西，一条命令跑起来就是一套完整的推理服务。

弄清楚分工之后，很多问题就好判断了。比如我在 WorkBuddy 里发出的提问没有回包，第一反应不应该是在 WorkBuddy 里反复改设置，而应该先去问 Ollama 本身：接口通不通？模型加载没有？响应耗时多少？把故障边界先画出来，再往两边排查，比盲目重装软件高效得多。

1.2 为什么要放弃云 API

本来我第一个想法是用现成的云模型 API，注册、充值、复制 key，五分钟就能跑通。但实际用起来有几个问题绕不开：第一是隐私，公司代码和实验数据往云端送，哪怕对方承诺不保存，心里始终不踏实。第二是延迟，长上下文时网络往返一次就要一两秒，加上服务端排队，流畅度反而没有本地模型好。第三是成本，本地模型跑一整天只是电费，云 API 按 token 计费，日常办公强度一个月下来不是小数目。

我还看重一点：本地模型是离线可控的。断网的时候，WorkBuddy 依然可以帮我查代码、总结文档，版本更新完全由自己掌控，不会被上游一次策略调整打乱节奏。当然，代价也非常明显：硬件决定天花板，7B 到 8B 左右的量化模型是性价比最高的档位。

1.3 模型选型与量化档位

本地模型不是越大越好。我测试过的组合主要是 7B 到 8B 参数量的模型，比如 qwen2.5:7b、llama3.1:8b，这两个是目前中文场景下最稳的选择。大于 14B 的模型即使能塞进显存，速度也会掉到个位数 tok/s，WorkBuddy 这种频繁多轮调用的场景根本等不起；小于 1.5B 的模型推理很快，但理解复杂指令的能力不足，经常答非所问。最终我留下的是 qwen2.5:7b-instruct-q4_K_M。

这里简单解释一下量化。同一个模型里有 Q4_K_M、Q8_0 这些 tag，Q4_K_M 是把权重压缩到约 4bit 精度，文件更小、显存占用更低、速度更快，代价是少量质量损失；Q8_0 是 8bit 精度，质量更接近原版，但体积和显存压力几乎翻倍。对于 7B 模型，Q4_K_M 在 12GB 显存的显卡上能做到约 4.5GB 的权重占用，给上下文留出充足空间，是甜点位。很多人一上来就拉 Q8_0，结果显存吃满，速度惨不忍睹，到手就后悔。

2. 环境准备与基础配置

2.1 安装 Ollama 与模型拉取

我的主力环境是 Windows 11 + i7-13700K + RTX 4070 12GB + 64GB 内存。Ollama 的安装本身很简单，官方安装包一路下一步就行。这里有个很现实的痛点：官方下载源在某些网络环境下非常慢。我后来的做法是搞一份离线安装包，在本地反复安装验证过，也方便同事在内网环境里复用。至于模型拉取，ollama pull qwen2.5:7b-instruct-q4_K_M一条命令就能搞定；拉取速度取决于模型文件，7B 量化版大概 4 到 5GB，网络不好时同样建议提前准备好模型文件，放到模型目录后让它自动导入。

提示：Ollama 的模型目录默认在系统用户目录下，如果你和我一样长期写代码，建议安装完第一时间把模型目录改到空间充足的其他盘。改法也很简单，在系统环境变量里加一个OLLAMA_MODELS，指向你希望存放模型的位置，然后重启 Ollama 服务即可。忘了这一步，一个 7B 模型就能悄悄吃掉系统盘 5GB 空间。

2.2 验证 Ollama 服务是否正常

安装完先别急着接 WorkBuddy，先把 Ollama 单独验证一遍。最简单的做法是打开终端跑ollama run qwen2.5:7b-instruct-q4_K_M，能正常对话就说明模型没问题。然后确认服务接口，Ollama 默认监听127.0.0.1:11434，我用 curl 验证一下：

curl http://127.0.0.1:11434/api/generate ^ -H "Content-Type: application/json" ^ -d "{\"model\":\"qwen2.5:7b-instruct-q4_K_M\",\"prompt\":\"say hi\",\"stream\":false}"

注意：Windows 的 cmd 对双引号转义比较麻烦，稍微写错就会让 Ollama 直接返回 400，这也是很多人误以为“模型坏了”的常见原因。建议在 PowerShell 或 Git Bash 里执行上述命令，少走弯路。

2.3 WorkBuddy 接入配置

WorkBuddy 的模型设置里可以添加自定义端点，支持接入符合 OpenAI 兼容协议的服务。这里有一个我踩过的最大的坑：地址到底填http://localhost:11434还是http://localhost:11434/v1。很多同类工具默认会往填写的地址后面拼/v1/chat/completions，如果你填的是根地址，实际请求会落到一个正确的兼容路径上；但如果你按照“OpenAI 地址”的直觉多填了/v1，某些实现会拼出/v1/v1/chat/completions，直接 404。

所以正确做法是：先看清 WorkBuddy 这个字段到底要 base URL 还是要完整端点。要 base URL 就填http://localhost:11434/v1；要完整端点就填http://localhost:11434/v1/chat/completions。如果你不确定，就先用 curl 把两种地址都测一遍，再用与测试完全一致的地址去配置 WorkBuddy。

模型名称同样要填完整，包括 tag 部分。qwen2.5:7b-instruct-q4_K_M一个字符都不能少，只填qwen2.5:7b会和本地已安装的模型 tag 对不上，Ollama 有可能尝试去远端拉取，结果大概率是失败或超时。

2.4 连通性验证与日志观察

配置完成后，我先在 WorkBuddy 里发一句最简单的“你好”，观察回复。同时打开 Ollama 的日志窗口（Windows 上 Ollama 是托盘程序，点击图标能看到日志入口；Linux 上直接用journalctl -u ollama -f），日志里会打印每一次请求的模型名、耗时、token 数。这一步极其重要：如果 WorkBuddy 界面显示“无输出”，但 Ollama 日志里明明有请求记录，问题就定位在 WorkBuddy 对响应内容的解析上；如果日志里压根没有请求，那就是 WorkBuddy 到 Ollama 的网络或配置链路出了问题。

一句“你好”，正常几秒内应该出结果。如果卡了几十秒还没反应，大概率是第一轮加载模型：7B 量化模型在 NVMe 上冷加载一般要 3 到 8 秒，在机械硬盘上可能要 15 秒以上。这个阶段的耐心容易被误判为故障，所以先单独跑一遍ollama run把模型预热起来，再接 WorkBuddy 测试，能省掉大量无谓的排查时间。

3. 从“无输出”到正常响应的排查实录

3.1 现象描述与初步判断

我第一次接入时遇到的现象非常典型：WorkBuddy 界面能显示模型已连接，但发出提问之后，等了十几秒，界面上既没有回复文字，也没有报错弹窗，就是干等着之后恢复到无输出的空白状态。一开始我以为是模型问题，重新 pull 了一遍，没用；以为是 WorkBuddy 问题，卸载重装，也没用。最后耐下心来做边界排查，才发现是几个问题叠加在一起造成的“复合故障”。这类故障最麻烦的地方在于：单看每一个环节好像都正常，联合起来就是不通。

3.2 排查路径总览

我总结了一套适合所有“客户端接本地模型”场景的排查顺序：先验证推理服务本身，再验证协议兼容性，再验证客户端配置，最后验证资源占用。对应到这次具体问题，排查点分别是：Ollama 能否独立对话；curl 直接调用 OpenAI 兼容端点能否返回；WorkBuddy 填写的地址和模型名与 curl 测试是否完全一致；显存和并发参数是否导致请求排队。我把每一步的验证结果都记录下来，发现了一个有价值的规律：80% 的“无输出”问题最后都指向两处，一是端点路径拼错，二是模型 tag 名称不一致。

3.3 关键节点逐一突破

先从协议兼容性说起。Ollama 从较新版本开始提供原生 OpenAI 兼容端点http://localhost:11434/v1/chat/completions，这让 WorkBuddy 这类第三方客户端对接起来非常顺滑。但兼容端点对请求结构是有要求的，model、messages这两个字段一定要符合规范。我用 curl 测试了一次：

curl http://localhost:11434/v1/chat/completions ^ -H "Content-Type: application/json" ^ -d "{\"model\":\"qwen2.5:7b-instruct-q4_K_M\",\"messages\":[{\"role\":\"user\",\"content\":\"say hi\"}],\"stream\":false}"

这一步通过之后，基本可以断定 Ollama 侧没问题。接下来检查 WorkBuddy 的模型配置，结果发现问题出在我对地址栏语义的判断上：我按直觉填了http://localhost:11434/v1，而 WorkBuddy 把“基础地址”理解成了会继续拼接路径的前缀，实际请求被拼成了/v1/v1/chat/completions，接口报 404，客户端又把错误吞掉了，界面看起来就是“无输出”。

把地址修正后，WorkBuddy 终于有输出了，但时断时续，经常前几轮正常、多轮对话之后就卡住。进一步调日志观察，发现 Ollama 日志里有排队等待，而且显存占用显示模型被反复换入换出。这是另一个坑：我机器上同时加载了 7B 和 5B 两个模型，Ollama 默认的并发加载策略会把显存争抢放大，导致请求排队时间超过 WorkBuddy 的等待时限，界面再次表现为“无输出”。

3.4 根因确认与修复总结

最终问题定位在三个因素叠加：第一，base URL 语义理解错误，导致端点 404 被客户端当作无响应；第二，模型名 tag 没写全，Ollama 试图远端拉取而超时；第三，多模型同时驻留显存，频繁换入换出导致请求排队。修复动作分别是：按字段语义填对地址和完整端点；模型名改回带完整 tag；设置OLLAMA_NUM_PARALLEL=1、OLLAMA_MAX_LOADED_MODELS=1，让 Ollama 一次只专心服务 WorkBuddy 的请求。修复之后，“无输出”彻底消失。

提示：如果你改了地址和模型名仍然无输出，可以把 WorkBuddy 的输出日志等级调到调试模式，看它实际发出的请求路径和错误码。这一步能省掉一半的瞎猜时间。

4. 性能调优：从十几 tok/s 到 70 tok/s

4.1 先判断瓶颈在哪

故障解决后，速度又成为新的问题。最初跑 qwen2.5:7b-instruct-q4_K_M 时，实际速度只有 12 到 15 tok/s，生成一段 300 字的正文要等半分多钟，完全没法当日常工具用。性能调优第一步不是乱调参数，而是先定位瓶颈。对于本地推理，瓶颈通常只有三种：显存带宽不足、显存容量不足、CPU 算力兜底。用ollama ps命令可以随时查看当前模型的显存占用和 GPU 利用率。我观察到的结果是：模型权重占了约 4.5GB，速度仍旧上不去，这说明问题不在算力本身，而在模型加载方式和推理参数配置上。

4.2 关键调优项逐个试

第一个调优项是量化档位。我一开始为了追求质量用了 Q8_0 版本，换成 Q4_K_M 之后，权重占用从接近 8GB 降到 4.5GB，显存带宽压力明显缓解，速度直接翻了一倍。对大多数办公场景，Q4_K_M 的质量差距在可接受范围，这是通行做法，不需要犹豫。

第二个调优项是 GPU 层数。Ollama 里对应参数是num_gpu，表示把模型的多少层放到 GPU 上计算，默认是-1表示尽量全部放 GPU。但我发现有些模型默认并没有充分利用 GPU，原因值得留意：当显存不足以装下全部层时，Ollama 会自动把一部分层放回 CPU 计算，而 CPU 和 GPU 之间的数据搬运会严重拖慢整体速度。我的显存 12GB，7B 模型完全能全部塞下，所以必须确保日志里显示“全部层在 GPU”。如果模型太大塞不下，优先换成更小体量的模型，而不是让 CPU 参与推理，后者速度会断崖式下降。

第三个调优项是上下文长度num_ctx。Ollama 默认是 4096，WorkBuddy 这种 Agent 工具经常要把代码上下文、文档片段一起塞给模型，4096 很快就被塞满。我把num_ctx调到 8192。这一步是把双刃剑：上下文翻倍，KV Cache 显存占用也会增加，反而影响 tok/s。实测在 4096 上下文时速度约 62 tok/s，调到 8192 后略微降到 58 tok/s，但生成质量和工作流完整性明显更好；再往上调到 16384，速度会降到 45 tok/s 左右。对于日常编码场景，8192 是平衡点。

4.3 实测数据与最终结果

经过几轮调整，我整理出了这套配置在 RTX 4070 上的实测数据：

最后一步提速来自并发参数和环境变量优化。我在系统环境变量里增加OLLAMA_NUM_PARALLEL=1、OLLAMA_KEEP_ALIVE=1h、OLLAMA_MAX_LOADED_MODELS=1。OLLAMA_KEEP_ALIVE表示模型在显存中常驻的时间，设为 1 小时可以避免每次请求都重新加载模型；OLLAMA_NUM_PARALLEL设为 1 看似限制了并发，实际上避免了多个请求争抢显存而导致的不稳定降速。这组配置下，实测速度稳定在 70 tok/s，生成一段 500 字的中文说明大约 10 秒，配合 WorkBuddy 已经达到“可以用”的流畅程度。

4.4 不同硬件下的期望值

顺带说一下不同硬件能达到的速度期望，方便你对号入座。8B 量化模型在 RTX 4070 上跑到 70 tok/s 已经接近甜点；RTX 4090 能到 100 以上 tok/s，瓶颈主要是显存带宽和算力余量。Apple Silicon 的 M 系列芯片表现也不错，M2 Pro 或 M2 Max 跑 7B 量化大约在 40 到 60 tok/s，优势是内存统一，模型可以做得比较大，劣势是长时间高负载下带宽会有波动。如果只有 CPU，比如一台老笔记本，7B 模型速度通常在 5 到 15 tok/s，勉强能对话，但基本没法当 Agent 工具用，这种情况下建议改用 3B 模型，把速度换回来。

4.5 服务端环境变量与请求参数中的隐藏选项

除了前面几个大项，还有一些容易被忽略的隐藏选项。比如OLLAMA_HOST可以改为0.0.0.0:11434，让局域网内其他机器也能访问 Ollama 服务，多机共享一块显卡很实用；OLLAMA_ORIGINS则控制跨域请求来源，WorkBuddy 如果以 Web 方式运行，跨域配置不对也会导致请求被拦。请求参数层面，temperature、top_p、num_predict这些采样参数同样会影响最终表现。我遇到过一个很隐蔽的问题：客户端请求里带了max_tokens: 0，兼容端点把它理解成“最多生成 0 个 token”，直接返回空内容，界面上又是一次“无输出”。后来我在 WorkBuddy 配置里把输出上限明确写成 256 这类正数，才彻底解决。

5. 常见问题速查与日常运维建议

5.1 高频问题速查表

把这段时间遇到过的所有问题整理成一张速查表，按现象排查，比从头读日志快得多：

有些朋友在终端里执行ollama run qwen3.5:2b时遇到过500 internal server error: llama-server process，这类问题我也碰到过，本质上就是模型文件不完整、Ollama 版本和模型格式不兼容，或者显存不足导致推理进程启动失败。处理顺序很简单：先升级 Ollama，再重新 pull 模型，最后检查显存剩余空间，三步走完基本能解决。另外“回复里带大段思考过程”这一点多说一句。很多新模型比如 gemma、qwen3 系列默认会输出 reasoning 内容，WorkBuddy 如果没做解析，会把这一大段“想法”原样当成回复展示出来，体验很怪。处理方案是在 WorkBuddy 的模型参数里加think=false，或者直接换不带思考过程的 instruct 精简版 tag，实测后者最省事。

5.2 日常使用建议

最后给几个长期使用这条链路的心得。第一，Ollama 和 WorkBuddy 建议都设成开机自启，减少“忘记启动 Ollama 导致 WorkBuddy 全部请求失败”的低级事故。Windows 上可以把 Ollama 的桌面启动项放进启动文件夹，WorkBuddy 自己就有开机启动选项。第二，模型缓存目录和系统缓存目录分离，长期跑下来系统盘空间会非常紧张，建议把OLLAMA_MODELS和 WorkBuddy 的缓存路径都改到数据盘。第三，模型版本不是越新越好，新模型刚发布时 Ollama 兼容层往往跟不上，容易出现接口字段解析问题；我现在的做法是等一个稳定周期再升级，日常工作始终用验证过的固定版本。

WorkBuddy 的 skill 功能也提一句：接入本地模型后，每个 skill 调用本质上都是一次完整推理，加上工具调用链，耗时通常比单轮对话长很多。我给自己的建议是，在 WorkBuddy 里把同类型的 skill 合并，减少来回推理次数，效果比单纯调高 token 速度更明显。本地模型跑 Agent 场景本身就是个工程问题，模型能力只占一半，另一半是合理的场景设计和参数控制。

这次从“无输出”到 70 tok/s 的完整排查，我最大的体会是：本地模型方案的成败往往不在模型本身，而在工程配置。WorkBuddy 和 Ollama 都是好工具，但两者之间的协议细节、资源参数、生命周期管理，每一环都可能变成拦路虎。按照“服务层自测、协议层验证、配置层比对、资源层调优”这个顺序走一遍，绝大多数问题都能自己解决。最后再分享一个小技巧：把上面那张速查表和 curl 验证命令存成一份本地笔记，下次无论在哪个机器上重搭这套环境，十分钟就能回到 70 tok/s 的流畅状态。