WorkBuddy 接入 Ollama 本地模型：零积分运行与数据不出本机实战

1. 为什么要在 WorkBuddy 里接本地模型1.1 从“积分焦虑”说起用 WorkBuddy 有一段时间的人大概都有这种体会功能确实顺手工作台、技能、自定义指令这些设计把日常琐事串得很顺但一旦调用云端模型频繁一点积分就像沙漏里的沙子肉眼可见地往下掉。尤其是做批量文本处理、反复调试提示词、或者让代理助手跑长链路任务的时候积分消耗速度会让人下意识地“省着用”反而不敢放开手脚去试。本地模型这条路恰好戳中了这个痛点。把 Ollama 跑在自己机器上WorkBuddy 通过 OpenAI 兼容协议去调用整个过程不经过任何云端计费环节也就谈不上消耗积分。你唯一付出的成本是本地那点电费和显存占用。对于经常做重复性调试、或者对数据不想出本机的人来说这个组合的性价比高得离谱。这篇内容就是把我自己从零把 WorkBuddy 接到 Ollama 的完整过程拆开讲清楚。三步走的框架听起来简单但中间踩过的坑不少——models.json 的字段格式、base_url 的写法、模型名对不上的报错、接入后反应慢的排查这些细节才是真正卡人的地方。适合已经装好 WorkBuddy、想进一步榨干本地算力的朋友也适合刚接触本地模型、想找个真实场景练手的新手。1.2 这套方案到底解决了什么问题先把价值说透免得你花时间看完发现不是自己想要的。第一零积分运行。WorkBuddy 调用本地 Ollama 服务时请求走的是本机回环地址不触发任何云端计费逻辑。你可以在 WorkBuddy 里反复让代理助手跑任务、反复改提示词积分纹丝不动。第二数据不出本机。所有推理都在本地完成输入的内容、生成的文本都留在自己硬盘和内存里。对处理一些不方便外发的材料来说这一点比省钱更重要。第三模型可换可调。Ollama 上能拉的模型很多从轻量的 7B 到能跑得动的更大参数版本你可以根据自己机器的显存和任务类型随时切换。WorkBuddy 那边只需要改一个模型名。第四离线可用。模型拉下来之后断网也能跑。出差、断网环境、或者单纯不想被网络波动影响的时候这套组合的稳定性反而比云端更好。需要提前说清楚的是本地模型的能力上限取决于你的硬件。显存小、内存少就只能跑小参数模型复杂推理任务的表现会和云端大模型有明显差距。这不是配置问题是物理限制心里要有预期。2. 动手前的环境盘点与工具选型2.1 硬件和系统的基本门槛在动手之前先花两分钟确认自己的机器能不能扛得住。Ollama 本身很轻但模型跑起来吃的是实打实的显存和内存。硬件项最低可跑推荐配置说明内存16GB32GB 及以上7B 模型量化版约需 5-8GB显存6GB12GB 及以上有独显优先用 GPU 推理硬盘20GB 空闲50GB 以上模型文件单个动辄几个 GB系统Win10 / macOS 12 / 主流 Linux同上三平台都有官方安装包如果你只有核显或者显存很小也不是不能跑Ollama 会自动回退到 CPU 推理。但速度会明显下降7B 模型在纯 CPU 上生成一段几百字的内容可能要等十几秒甚至更久。这一点在“接入后反应非常慢”的排查里会再展开。系统层面Windows 用户建议用官方安装包macOS 用 dmg 或者 brew 都行Linux 用官方脚本。国内下载慢的问题后面单独讲。2.2 Ollama 与 WorkBuddy 的版本匹配版本这块有个容易被忽略的点WorkBuddy 调用本地模型走的是 OpenAI 兼容协议而 Ollama 从较早版本开始就提供了/v1兼容端点。所以理论上只要 Ollama 不是特别老的版本都能对接。我实测下来Ollama 用近一年内的稳定版基本没问题WorkBuddy 用当前正式版即可。真正需要注意的是模型名的大小写和标签。Ollama 里模型名是qwen2.5:7b这种格式冒号后面是标签WorkBuddy 的配置里如果只写qwen2.5而本地实际是带标签的版本就会报模型找不到的错。这个坑后面会详细说。另外提醒一句别去追所谓的“从入门到精通 pdf”之类的资料版本迭代快很多截图和字段早就过时了。以官方文档和你自己机器上的实际输出为准最靠谱。2.3 为什么选 Ollama 而不是别的本地方案本地跑模型的工具不少LM Studio、AnythingLLM 这些也常被提到。我选 Ollama 作为 WorkBuddy 的后端主要基于三点考虑。一是命令行友好、服务化清晰。Ollama 装完就是一个常驻服务默认监听本地端口WorkBuddy 直接连就行不需要额外开图形界面。LM Studio 更适合手动加载模型、点点点操作做后端服务反而多一层。二是OpenAI 兼容协议开箱即用。Ollama 的/v1/chat/completions端点格式和 OpenAI 一致WorkBuddy 那边配置起来几乎零改动。AnythingLLM 更偏向知识库场景做纯模型后端有点重。三是模型管理简单。ollama pull拉模型、ollama list看列表、ollama rm删模型几条命令搞定。对经常换模型试效果的人来说这个体验比图形界面拖来拖去高效。当然如果你已经用惯了 LM Studio也不是不能接只要它暴露了 OpenAI 兼容端点配置思路是一样的。工具是次要的协议对得上才是关键。3. 三步走实操从装 Ollama 到 WorkBuddy 跑通3.1 第一步装好 Ollama 并拉取模型先说安装。Windows 和 macOS 直接去官网下安装包双击一路下一步。Linux 用官方提供的一键脚本终端里执行即可。国内下载慢是普遍问题我的经验是错峰下载或者找找有没有可用的镜像源但镜像源的可用性经常变这里不具体推荐你自己搜一下当前能用的就行。装完之后验证一下服务是否正常ollama --version ollama list第一条看版本第二条看当前有哪些模型。如果ollama list报连接错误说明服务没起来。Windows 上一般装完自动起macOS 和 Linux 可能需要手动ollama serve或者检查服务状态。接下来拉模型。选哪个模型取决于你的硬件和任务类型。做通用对话和文本处理7B 级别的量化模型是甜点区。命令格式ollama pull qwen2.5:7b拉取过程中会显示进度。如果卡住不动多半是网络问题CtrlC 中断后重试Ollama 支持断点续传不会从头再来。拉完之后再ollama list确认一下记下完整的模型名包括冒号后面的标签这个后面配置要用。提示拉模型之前先想清楚要哪个。硬盘空间有限的话别一口气拉好几个大模型删起来也麻烦。先拉一个跑通流程再按需增加。拉完模型建议先在命令行里测一下确认模型本身能正常推理ollama run qwen2.5:7b进入交互界面后随便问一句能正常回复就说明模型没问题。输入/bye退出。这一步很关键能把“模型本身的问题”和“WorkBuddy 配置的问题”提前分开省得后面排查时两头猜。3.2 第二步确认 Ollama 的 OpenAI 兼容端点Ollama 默认监听11434端口。它的原生 API 和 OpenAI 兼容 API 是两套路径WorkBuddy 要连的是兼容那套。先在浏览器或者用 curl 验证一下端点是否活着curl http://localhost:11434/v1/models如果返回一个 JSON里面列出了你本地的模型说明兼容端点正常工作。这个返回里的模型 id 就是你在 WorkBuddy 配置里要填的名字直接照抄别自己改。有时候你会看到返回的模型名和ollama list里显示的略有差异以/v1/models返回的为准。这是最权威的因为 WorkBuddy 实际请求的就是这个端点。如果 curl 报连接被拒绝检查两件事Ollama 服务是否在跑以及端口有没有被占用或改动。默认端口是 11434如果你改过配置里也要跟着改。注意有些环境里 Ollama 只监听127.0.0.1这是正常的本机调用足够。不要为了“让别的机器也能连”去改成监听所有网卡那会带来不必要的暴露风险本机用完全没必要。3.3 第三步在 WorkBuddy 里配置本地模型这一步是核心也是报错最集中的地方。WorkBuddy 的模型配置通常落在一个叫models.json的文件里或者通过界面里的“自定义模型 / 本地模型”入口填写。两种方式本质一样都是往配置里加一条 OpenAI 兼容的模型定义。关键字段有这么几个字段填什么说明name / modelqwen2.5:7b必须和/v1/models返回的一致base_url / api_basehttp://localhost:11434/v1注意结尾的/v1不能少api_key任意非空字符串本地不校验但不能留空provider / typeopenai或兼容类型告诉 WorkBuddy 走兼容协议api_key这一项是很多人卡住的地方。本地 Ollama 根本不校验密钥但 WorkBuddy 的配置校验逻辑可能要求这个字段非空。随便填一个字符串比如ollama或者local就能过。别留空留空会报配置保存失败。base_url的写法也有讲究。有人填http://localhost:11434少了/v1结果请求打到原生 API 上格式对不上就报错。正确写法是带上/v1因为兼容端点的完整路径是/v1/chat/completions。配置保存后在 WorkBuddy 里选这个模型发一条测试消息。如果一切正常你会看到回复而且积分没有任何变化。到这一步三步走就算跑通了。4. 配置细节深挖与参数选择逻辑4.1 models.json 到底该怎么写虽然不同版本的 WorkBuddy 配置界面长得不一样但底层都是往models.json这类文件里写结构。给一个我实测可用的参考结构你对照着自己版本调整字段名{ models: [ { name: qwen2.5:7b, provider: openai, base_url: http://localhost:11434/v1, api_key: ollama, context_length: 8192 } ] }这里context_length是可选项但建议填。它告诉 WorkBuddy 这个模型能吃多长的上下文。填得比模型实际能力大会导致超长输入被截断或者报错填得太小又浪费了模型能力。7B 级别的模型一般支持 8K 到 32K 上下文具体看你拉的版本拿不准就填 8192 保守一点。字段名这块要提醒不同版本可能用base_url也可能用api_base用name也可能用model。别硬套先看一眼你本地已有的配置里其他模型是怎么写的照着格式加最稳。4.2 模型名对不上导致的报错怎么破“workbuddy 调用本地模型报错”这个搜索词背后十有八九是模型名对不上。表现通常是 WorkBuddy 弹一个错误报告里面提到 model not found 或者 404。排查顺序是这样的先跑curl http://localhost:11434/v1/models看返回里的 id 到底是什么。把 WorkBuddy 配置里的模型名改成和返回完全一致包括大小写和冒号标签。保存后重启 WorkBuddy让它重新读配置。我遇到过一种情况本地拉的是qwen2.5:7b但配置里写成了Qwen2.5:7B大小写不一致直接报错。Ollama 的模型名是大小写敏感的这点要记住。还有一种情况是拉模型时用了默认标签比如ollama pull qwen2.5实际存下来的可能是qwen2.5:latest。配置里写qwen2.5就找不到。所以拉模型时养成习惯明确写标签别偷懒。4.3 上下文长度与显存的平衡上下文长度和显存是直接挂钩的。上下文越长模型需要缓存的状态越多显存占用越大。7B 模型在 8K 上下文下可能占 6-8GB 显存拉到 32K 可能就爆了。我的做法是先按模型默认能力填一个中间值跑起来看显存占用。如果还有余量再往上调如果一跑就爆显存或者疯狂往内存里换页就往下调。这个没有万能公式得看你自己的卡。实操心得调上下文长度的时候别只看能不能跑起来还要看生成速度。显存吃紧时即使没爆速度也会明显下降因为部分计算被挤到 CPU 上了。宁可上下文短一点、速度快一点体验反而更好。5. 接入后反应慢的排查与优化5.1 先分清是模型慢还是链路慢“workbuddy 接入本地模型后反应非常慢”是高频问题。排查第一步是分清瓶颈在哪。在命令行里直接ollama run同一个模型问同样的问题看响应速度。如果命令行里也慢那就是模型和硬件的问题跟 WorkBuddy 无关。如果命令行里快、WorkBuddy 里慢那问题出在 WorkBuddy 这一侧可能是配置、可能是并发、也可能是它在做额外的处理。这个对比测试能帮你省掉大量瞎猜的时间。我见过有人一直在调 WorkBuddy 配置结果发现是模型本身在 CPU 上跑怎么调都快不了。5.2 常见的速度杀手按影响从大到小排大概有这几个没用上 GPU。这是最常见的。Ollama 默认会尝试用 GPU但驱动没装好、CUDA 版本不匹配、或者显存不够时会静默回退到 CPU。跑ollama ps能看到模型加载在哪个设备上。如果显示的是 CPU那速度慢就是必然的。模型太大。14B、32B 的模型在消费级显卡上跑速度会明显低于 7B。如果任务不复杂换小模型是最直接的提速手段。上下文开太大。前面说过上下文越长显存压力越大速度越慢。适当调小能立竿见影。首次加载冷启动。模型第一次被调用时要加载进显存这个时间可能几秒到几十秒。第二次调用就快了。别把冷启动当成“一直很慢”。并发请求。如果 WorkBuddy 同时发多个请求本地模型是排队处理的看起来就像卡住了。减少并发或者等前一个跑完再发下一个。5.3 一个实用的排查速查表现象可能原因处理方式命令行快、WorkBuddy 慢配置或并发问题检查 base_url、减少并发命令行也慢硬件或模型问题查ollama ps是否用 GPU首次慢、之后快冷启动正常现象预热即可一直报错 model not found模型名不一致对照/v1/models改配置配置保存失败api_key 为空填任意非空字符串生成到一半卡住显存不足换页调小上下文或换小模型这张表基本覆盖了我遇到过的绝大多数情况。遇到新问题先往这几类里套能快速定位方向。6. 进阶玩法与长期使用建议6.1 多模型切换与场景分工跑通一个模型之后很自然会想多拉几个换着用。我的建议是按场景分工而不是盲目堆模型。轻量任务比如文本改写、格式整理、简单问答用 7B 级别的小模型快且省资源。复杂一点的推理、代码理解可以拉一个能力更强的版本但只在需要时加载。Ollama 支持按需加载不用的模型不会一直占显存这点比想象中省心。WorkBuddy 那边可以配置多个模型条目用的时候在下拉里切换。切换时注意新模型第一次调用会有冷启动延迟别以为是卡了。6.2 把本地模型和云端模型搭配着用本地模型不是要完全取代云端。更聪明的用法是搭配日常高频、对质量要求不极致的任务走本地省积分真正需要强推理、长上下文、高质量输出的任务再走云端。这样既控制了积分消耗又保证了关键任务的效果。WorkBuddy 支持多模型配置切换成本很低完全可以按任务类型手动选或者用自定义指令做简单的路由规则。6.3 长期使用的几个习惯第一定期ollama list清理不用的模型硬盘空间比想象中宝贵。第二模型更新后配置里的模型名可能变化升级前先确认。第三把models.json备份一份。配置调好了不容易别因为一次误操作重来。第四关注显存占用长期高负载运行对硬件有损耗该休息就休息。最后分享一个小技巧如果你经常在多个项目间切换可以给每个项目配一套独立的模型配置用的时候整体切换比每次改字段省事得多。这个习惯我用了大半年确实省心。这套 WorkBuddy 接 Ollama 的方案核心就是三步装好 Ollama 拉模型、确认兼容端点、在 WorkBuddy 里填对配置。真正花时间的从来不是这三步本身而是中间那些字段格式、模型名、显存占用的细节。把这些坑提前填平剩下的就是享受零积分、数据不出本机的本地推理体验了。