如果你最近在折腾 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/sWorkBuddy 这种频繁多轮调用的场景根本等不起小于 1.5B 的模型推理很快但理解复杂指令的能力不足经常答非所问。最终我留下的是 qwen2.5:7b-instruct-q4_K_M。这里简单解释一下量化。同一个模型里有 Q4_K_M、Q8_0 这些 tagQ4_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_PARALLEL1、OLLAMA_MAX_LOADED_MODELS1让 Ollama 一次只专心服务 WorkBuddy 的请求。修复之后“无输出”彻底消失。提示如果你改了地址和模型名仍然无输出可以把 WorkBuddy 的输出日志等级调到调试模式看它实际发出的请求路径和错误码。这一步能省掉一半的瞎猜时间。4. 性能调优从十几 tok/s 到 70 tok/s4.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 之间的数据搬运会严重拖慢整体速度。我的显存 12GB7B 模型完全能全部塞下所以必须确保日志里显示“全部层在 GPU”。如果模型太大塞不下优先换成更小体量的模型而不是让 CPU 参与推理后者速度会断崖式下降。第三个调优项是上下文长度num_ctx。Ollama 默认是 4096WorkBuddy 这种 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 上的实测数据配置组合显存占用平均速度Q8_0 4096上下文 部分CPU层9.2GB15 tok/sQ8_0 4096上下文 全GPU9.2GB34 tok/sQ4_K_M 4096上下文 全GPU4.6GB62 tok/sQ4_K_M 8192上下文 全GPU5.8GB58 tok/sQ4_K_M 8192上下文 全GPU 关闭并发抢显存5.8GB70 tok/s最后一步提速来自并发参数和环境变量优化。我在系统环境变量里增加OLLAMA_NUM_PARALLEL1、OLLAMA_KEEP_ALIVE1h、OLLAMA_MAX_LOADED_MODELS1。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 高频问题速查表把这段时间遇到过的所有问题整理成一张速查表按现象排查比从头读日志快得多现象可能原因处理方案WorkBuddy 完全无输出base URL 拼错/模型名 tag 不全用 curl 验证端点和客户端配置逐一比照请求返回 404路径多了一层/v1按字段语义填 base URL 或完整端点请求返回 500模型文件损坏/Ollama 版本过旧/llama-server 崩溃重新ollama pull升级 Ollama 到最新版检查显存余量首次回复特别慢模型冷加载中先ollama run预热再设OLLAMA_KEEP_ALIVE驻留显存多轮对话后卡死上下文塞满或显存被多模型抢占调大num_ctx限制OLLAMA_MAX_LOADED_MODELS回复里带大段思考过程模型自带 thinking 机制在请求参数里关闭思考或选择非思考版本 tag生成速度掉到个位数模型放到了 CPU 上跑确认num_gpu显式指定全部层或换更小量化档位有些朋友在终端里执行ollama run qwen3.5:2b时遇到过500 internal server error: llama-server process这类问题我也碰到过本质上就是模型文件不完整、Ollama 版本和模型格式不兼容或者显存不足导致推理进程启动失败。处理顺序很简单先升级 Ollama再重新 pull 模型最后检查显存剩余空间三步走完基本能解决。另外“回复里带大段思考过程”这一点多说一句。很多新模型比如 gemma、qwen3 系列默认会输出 reasoning 内容WorkBuddy 如果没做解析会把这一大段“想法”原样当成回复展示出来体验很怪。处理方案是在 WorkBuddy 的模型参数里加thinkfalse或者直接换不带思考过程的 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 的流畅状态。