企业官网建设流程全解析

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] Environment="OLLAMA_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

进入交互界面后随便问一句，比如“用一句话解释什么是递归”。能正常返回就说明模型加载和推理都没问题。这时候可以按 Ctrl+D 退出。

这一步很关键，因为如果模型本身有问题，后面 WorkBuddy 报错你会以为是配置问题，白白浪费时间排查。命令行能跑通，才说明问题不在 Ollama 这一侧。

4. 第三步：配置 WorkBuddy 对接本地模型

4.1 找到配置文件的位置

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 连接类问题速查

连接类问题占了报错的大多数。我踩过的一个坑是：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 协议的工具做补充。整套跑下来，本地模型承担了大概七成的日常请求，积分消耗降到了原来的三成左右，而体验上除了极端复杂的推理任务，基本感觉不到差别。如果你也在为积分发愁，这套三步走的方案值得花一个下午完整搭一遍。