如果你也把 WorkBuddy 的模型端点从云端 API 切到本地 Ollama大概率会碰到我遇到的第一个“惊喜”界面转了几圈模型名也填了请求看起来也发出去了结果回答区域干干净净一个字都没有。作为把 WorkBuddy 当成日常生产力工具的人我本来想让它完全跑在本地模型上省掉 API 费用也避免把文档内容送到外部。结果整整折腾了一天从“无输出”到最终稳定跑出 70 tok/s中间踩过的坑几乎能写成一本地图。这篇就按我的实际排查时间线来记希望你能绕开我走的那几个小时弯路。这篇内容适合谁如果你正在 WorkBuddy 里配置 Ollama 本地模型或者你只是想把任何一款带 OpenAI 兼容接口的应用接到 Ollama 上本文都适用。我会把安装、模型选择、Base URL 填法、无输出问题、500 错误、速度优化这些关键环节全部拆开讲给你能直接照抄的配置也给你排查时用得到的命令。废话不多说直接进入正题。1. 为什么我在 WorkBuddy 里接 Ollama 而不是云端 API1.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 到 3GB7B 模型大约 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.7GB14B 大约 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等模型下载完成后输入一句简单中文比如“你好介绍一下你自己”。如果终端正常返回内容说明模型推理逻辑没问题。然后按CtrlD退出对话。接着执行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/completionsOllama 对这个路径做了兼容性兜底吗实际返回了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 ollamamacOS 下直接从终端运行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_PARALLEL1 OLLAMA_MAX_LOADED_MODELS1让 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:\WorkBuddyCacheWindows 用mklink /JmacOS 和 Linux 用ln -s。这个操作本质上是给系统一个“假路径”让 WorkBuddy 还以为缓存还在原处但实际数据已经写到大分区。这样做能解决磁盘告急但不要在执行过程中频繁移动先退出 WorkBuddy 再操作。5. 常见问题速查与避坑心得5.1 高频问题对照表把前几节的问题汇总成一张表方便你直接对照症状可能原因处理办法请求转圈但无输出Base URL 少了/v1改为http://127.0.0.1:11434/v1请求完全不发API Key 留空填任意字符串如ollama返回空内容模型只输出思考字段客户端不识别换 instruct 版模型或关闭思考模式500 错误模型 tag 不存在或显存不足ollama list核对 tag换小模型速度非常慢没有 GPU 加速上下文太长ollama ps看处理器调小num_ctx模型反复加载慢同时加载多个模型设OLLAMA_MAX_LOADED_MODELS1C 盘空间爆满模型和缓存都在系统盘改OLLAMA_MODELS移动 WorkBuddy 缓存这张表是我踩坑后的最终浓缩版。你可能不会全遇到但遇到任何一个都能按表里的思路先排查一圈。5.2 我最后留下的稳定配置给出一份可直接抄作业的配置清单方便你照配Ollama 版本官方最新稳定版模型qwen2.5:3b通过 Modelfile 自定义为qwen2.5-3b-fastModelfile 参数num_ctx 4096num_batch 512temperature 0.7环境变量OLLAMA_NUM_PARALLEL1OLLAMA_MAX_LOADED_MODELS1OLLAMA_MODELSD:\ollama_modelsWorkBuddy 模型配置Base URLhttp://127.0.0.1:11434/v1API Keyollama模型名qwen2.5-3b-fast这份配置在我的场景下跑了一天没再出现过空输出和 500。如果你第一次接入就是这套配置大概率能免掉大部分折腾。5.3 最后一条保命经验我最大的体会是本地模型和客户端之间的“适配”远比“模型质量”坑多。WorkBuddy 不会直接告诉你它内部请求用的是什么完整 URL也不会替你做模型 tag 归一化它只忠实于你填的字段。所以遇到问题先别怀疑 WorkBuddy 是不是坏了先用 curl 把 Ollama 接口测通再逐项核对自己的配置。把每一步都拆成可验证的独立模块问题通常会在半小时内露出马脚。另外如果你准备用 Ollama 接 Dify、Cherry Studio 或者其他工具这套排查思路同样通用核心永远是先验证底层 API再调上层配置。本地模型这条路一旦跑通工作和写作都不用再被云端绑定那种踏实感是值得折腾这一天的。