1. 为什么要在 WorkBuddy 里接入本地模型1.1 从“积分焦虑”说起用 WorkBuddy 有一段时间的人大概都有体会云端模型确实省事但积分消耗速度经常超出预期。尤其是做批量代码审查、长文档摘要、多轮对话调试这类任务时积分就像沙漏里的沙子肉眼可见地往下掉。我自己的使用习惯是每天固定跑几轮代码重构建议和文档整理一个月下来积分消耗相当可观。本地模型的价值就在这里。把 Ollama 跑起来之后WorkBuddy 通过 OpenAI 兼容协议对接本地推理服务所有请求都走本机回环地址不经过任何外部接口自然也就不消耗积分。对于日常高频、对模型能力要求不是极端苛刻的场景本地模型完全够用。像 Qwen 系列的中小参数版本、Llama 系列的量化版本在消费级显卡甚至纯 CPU 上都能跑出可接受的速度。这个方案适合几类人一是积分预算有限但使用频率高的重度用户二是对数据隐私有要求、不希望内容离开本机的开发者三是想折腾本地推理、顺便把 WorkBuddy 当成统一入口来管理多个模型的人。如果你属于其中任何一类接下来的三步走流程值得完整走一遍。1.2 整体思路三步走的逻辑所谓“三步走”本质是把整条链路拆成三个独立可验证的环节装 Ollama、拉模型、配 WorkBuddy。每一步都能单独测试出问题也容易定位。很多人一上来就把三件事混在一起做结果报错了根本不知道是 Ollama 没起来、模型没拉下来还是 WorkBuddy 的配置写错了。我建议的顺序是先确保 Ollama 服务本身能正常响应再用命令行验证模型能对话最后才去动 WorkBuddy 的配置文件。这样每一步都有明确的验收标准不会出现“全配完了但不知道哪坏了”的情况。提示整个流程的核心是 OpenAI 兼容协议。Ollama 默认在 11434 端口暴露了一个兼容 OpenAI 接口规范的服务端点WorkBuddy 只要把 base_url 指过去、填一个占位的 api_key就能像调用云端模型一样调用本地模型。2. 第一步把 Ollama 装好并跑起来2.1 各平台的安装方式选择Ollama 的安装在不同系统上差异不小选对方式能省很多事。Windows 用户直接去官网下载安装包双击一路下一步即可。安装完成后 Ollama 会常驻在系统托盘默认开机自启。这里有个细节Windows 版的模型默认存放在C:\Users\你的用户名\.ollama\models如果 C 盘空间紧张一定要在拉模型之前改掉存储路径否则后面几个大模型下来几十 GB 就没了。macOS 用户同样下载 dmg 安装包拖进 Applications 就行。Apple Silicon 芯片的机器跑 Ollama 体验相当好统一内存架构让模型加载和推理都比较顺畅。Linux 用户推荐用官方的一键脚本安装curl -fsSL https://ollama.com/install.sh | sh装完之后用systemctl status ollama检查服务状态。如果显示 active (running) 就说明后台服务已经起来了。注意Linux 上如果遇到服务起不来的情况先看journalctl -u ollama -n 50的日志。常见原因是显卡驱动没装好或者端口被占用。2.2 验证服务是否正常装完之后别急着拉模型先确认服务本身是通的。打开终端执行curl http://localhost:11434/api/tags如果返回一个 JSON里面是空的 models 列表说明服务正常只是还没拉模型。如果连接被拒绝那就是服务没起来回去检查安装步骤。另一个验证方式是直接跑ollama list这个命令会列出本地已有的模型。能正常输出就说明命令行工具和服务之间的通信没问题。2.3 修改模型存储路径可选但推荐前面提到 C 盘空间的问题这里给出具体做法。Windows 上设置系统环境变量OLLAMA_MODELS指向你想要的目录比如D:\ollama-models。设置完重启 Ollama 服务生效。Linux 上则是编辑 systemd 服务文件sudo systemctl edit ollama在打开的编辑器里加入[Service] EnvironmentOLLAMA_MODELS/data/ollama-models保存后sudo systemctl daemon-reload sudo systemctl restart ollama。这个改动一定要在拉模型之前做已经拉下来的模型不会自动迁移得手动搬。3. 第二步拉取适合你的本地模型3.1 模型选型的几个维度Ollama 上的模型成百上千选哪个直接决定了后续体验。我一般从三个维度考虑参数量、量化等级、任务类型。参数量决定了模型的基础能力上限但也直接决定了显存占用和推理速度。7B 到 9B 这个区间是消费级硬件的甜点区8GB 显存基本能跑量化版本。14B 以上就需要 12GB 甚至 16GB 显存了。如果只有 CPU那建议从 3B 到 4B 起步否则速度会让你怀疑人生。量化等级用 Q4、Q5、Q8 这样的标记表示数字越大精度越高、体积越大。Q4_K_M 是性价比最高的选择精度损失很小体积却比 Q8 小一半左右。任务类型方面代码相关任务优先考虑 Qwen 系列和 DeepSeek 系列的代码版本通用对话和文档处理Qwen 的通用版本表现均衡如果要做英文为主的任务Llama 系列也是稳妥选择。3.2 拉模型的命令与国内加速基本命令很简单ollama pull qwen2.5:7b但国内直接拉经常慢得让人抓狂几十 GB 的模型下几个小时是常事。解决办法是配置镜像源。Ollama 支持通过环境变量指定镜像具体地址可以在社区里找当前可用的配置方式是在启动服务前设置OLLAMA_HOST或者使用支持镜像的拉取工具。另一个思路是找离线安装包。有些社区会打包好常用模型的完整文件下载后放到OLLAMA_MODELS目录下对应的文件夹里Ollama 启动时能直接识别。这个方式适合网络条件实在不行的场景。提示拉模型的时候可以另开一个终端跑ollama list看进度或者直接观察模型目录的大小变化。大模型拉取中断是常事Ollama 支持断点续传重新执行 pull 命令会接着下。3.3 验证模型能正常对话模型拉完之后先用命令行确认它能跑ollama run qwen2.5:7b进入交互界面后随便问一句比如“用一句话解释什么是递归”。能正常返回就说明模型加载和推理都没问题。这时候可以按 CtrlD 退出。这一步很关键因为如果模型本身有问题后面 WorkBuddy 报错你会以为是配置问题白白浪费时间排查。命令行能跑通才说明问题不在 Ollama 这一侧。4. 第三步配置 WorkBuddy 对接本地模型4.1 找到配置文件的位置WorkBuddy 的模型配置通常放在用户配置目录下的models.json文件里。不同系统路径不一样系统典型路径Windows%APPDATA%\WorkBuddy\models.jsonmacOS~/Library/Application Support/WorkBuddy/models.jsonLinux~/.config/WorkBuddy/models.json如果找不到这个文件可以在 WorkBuddy 的设置界面里找“模型管理”或“自定义模型”相关的入口通常会有“打开配置文件”的按钮。实在找不到就全局搜一下models.json。4.2 models.json 的写法配置文件的核心是声明一个 OpenAI 兼容的模型条目。结构大致如下{ models: [ { name: local-qwen, provider: openai, base_url: http://localhost:11434/v1, api_key: ollama, model: qwen2.5:7b } ] }几个字段的含义需要说清楚。provider填openai是因为 Ollama 暴露的是 OpenAI 兼容接口WorkBuddy 会按 OpenAI 的协议去发请求。base_url指向 Ollama 的 v1 端点注意结尾的/v1不能少。api_key随便填一个非空字符串就行Ollama 不校验这个值但 WorkBuddy 可能要求字段存在。model字段必须和ollama list里显示的模型名完全一致大小写和标签都不能错。4.3 保存后重启与验证改完配置文件后一定要完全退出 WorkBuddy 再重新打开光关窗口不够得确保进程真的结束了。重启后在模型选择列表里应该能看到local-qwen这个条目选中它发一条消息如果正常返回就说明整条链路通了。如果报错先看 WorkBuddy 的错误提示。常见的error report里如果提到连接失败多半是 Ollama 服务没起来或者端口不对如果提到模型不存在就是model字段和实际模型名对不上。5. 常见问题与排查技巧实录5.1 连接类问题速查现象可能原因排查方法连接被拒绝Ollama 服务未启动curl localhost:11434/api/tags测试404 错误base_url 缺少 /v1检查配置里的路径超时端口被防火墙拦截检查本机防火墙规则模型不存在model 字段名不匹配ollama list核对名称连接类问题占了报错的大多数。我踩过的一个坑是Windows 上 Ollama 装完后服务是起来了但 WorkBuddy 用的是另一个用户账户运行的导致访问 localhost 时解析到了不同的网络上下文。解决办法是确认两者在同一用户会话下运行。5.2 性能类问题“接入本地模型后反应非常慢”是高频反馈。原因通常有三个模型太大硬件带不动、量化等级选太高、或者上下文长度设置过长。先看硬件。用nvidia-smi看推理时显存占用如果显存爆了会退到内存甚至 CPU速度断崖式下跌。这时候要么换更小的模型要么换更低的量化等级。上下文长度也是隐形杀手。WorkBuddy 默认可能给很长的上下文窗口本地模型处理长上下文时显存占用会线性增长。在配置里把上下文限制调小比如 4096 或 8192速度会明显改善。5.3 配置保存失败的处理“保存本地模型配置失败”通常和文件权限有关。Linux 和 macOS 上检查models.json的属主是不是当前用户Windows 上检查文件是不是被其他进程占用。另一个可能是 JSON 格式写错了比如多了个逗号或者少了引号用 JSON 校验工具过一遍就能发现。提示改配置文件前先备份一份改坏了能快速回滚。这个习惯在折腾各种配置时能救命。5.4 几个实操心得第一模型名里的标签别省略。qwen2.5:7b和qwen2.5在 Ollama 里可能是不同的东西配置里写全最保险。第二如果同时用多个本地模型可以在 models.json 里配多个条目用不同的 name 区分WorkBuddy 的模型列表里就能切换。第三本地模型不消耗积分这一点在批量任务里优势特别明显。我习惯把代码格式化、注释生成、简单重构这类重复性工作全部交给本地模型云端模型只留给真正需要强推理的任务积分消耗直接降了一个数量级。第四Ollama 的日志在排查问题时很有用。Linux 上用journalctl -u ollama -f实时看Windows 上在托盘图标右键能找到日志入口。请求进来时日志里会有记录能确认 WorkBuddy 的请求到底有没有到达 Ollama。6. 把本地模型用出效率的几个进阶思路6.1 按任务分配模型本地模型和云端模型不是替代关系而是分工关系。我的做法是在 WorkBuddy 里同时保留本地和云端两个模型条目简单任务切本地复杂任务切云端。判断标准很简单如果这个任务你自己看一眼就能给出答案本地模型基本够用如果需要多步推理或者涉及大量背景知识交给云端。这种分工带来的积分节省是实打实的。以前一个月积分不够用现在同样的工作量还能剩下一半。6.2 模型文件的复用与迁移Ollama 的模型文件是自包含的整个models目录可以直接拷贝到另一台机器上复用。换电脑或者给团队其他成员部署时把目录拷过去、配好环境变量省去重新下载的时间。这个技巧在批量部署时特别有用。6.3 保持 Ollama 更新Ollama 的迭代速度很快新版本经常带来推理性能优化和新模型支持。定期更新能白嫖到不少性能提升。Linux 上重新跑一遍安装脚本就是更新Windows 和 macOS 下载新安装包覆盖安装即可。更新前记得确认模型目录不会被清掉正常情况下模型文件是保留的。6.4 关于 OpenAI 兼容协议的更多可能理解了 Ollama 暴露的是 OpenAI 兼容接口这一点之后你会发现很多工具都能接进来。任何支持自定义 OpenAI 端点的应用理论上都能把 base_url 指向http://localhost:11434/v1来使用本地模型。这意味着你搭好一套 Ollama能同时服务多个工具边际成本几乎为零。这也是我推荐优先用 Ollama 而不是其他本地推理方案的原因之一——生态兼容性带来的复用价值太高了。我自己现在的配置是Ollama 常驻后台WorkBuddy 作为主力入口偶尔用其他支持 OpenAI 协议的工具做补充。整套跑下来本地模型承担了大概七成的日常请求积分消耗降到了原来的三成左右而体验上除了极端复杂的推理任务基本感觉不到差别。如果你也在为积分发愁这套三步走的方案值得花一个下午完整搭一遍。