1. 先说结论：WorkBuddy 接 Ollama，到底值不值得折腾
WorkBuddy 这个工具，我最早是在折腾 AI 工作台自动化的时候接触到的。简单说，它就是一个把大模型能力编排进日常工作的智能代理平台，支持按任务搭"工作台"、挂"技能"（skill），也能接入外部模型后端来驱动整个流程。而 Ollama 则是目前跑本地大模型最省事的运行时，一条命令就能把模型拉下来，暴露一个和 OpenAI 兼容的接口给上层应用调用。把这两个接在一起，等于让 WorkBuddy 的所有自动化流程跑在完全本地、完全免费的模型上。
我为什么非要折腾本地模型？三个现实需求逼的：一是公司项目数据不能出内网，任何云端 API 都过不了合规这关；二是每天高频调用云端接口的费用确实肉疼，测试阶段动不动就烧掉几十块；三是离线环境的客户现场演示，总不能现场直播"连接超时"。如果你也有这几类场景，那 WorkBuddy 接 Ollama 就是一条绕不开的路。
这篇文章的定位不是官方文档复读，而是把我从"界面点了没反应"到最终稳定跑出 70 tok/s 的完整排查过程摊开来讲。适合两类人看：一类是刚把 WorkBuddy 装好、正准备接本地模型的新手；另一类是已经能跑通但速度上不去、或者偶尔报各种诡异错误的老手。下文所有步骤和参数都是我实测过的，照着抄基本能复现。
2. 先把角色理清楚：WorkBuddy 和 Ollama 各管哪一段
2.1 WorkBuddy 的定位和"技能"机制
WorkBuddy 的核心逻辑是"工作台 + 技能"。你可以把它理解成一个搭积木的 AI 自动化环境：先定义目标（比如"整理本周会议纪要"），然后把能力拆成一个个 skill 挂上去，每个 skill 本质上是一段精心设计的提示词加处理逻辑，负责调用模型完成某一小步。模型在这里扮演的是"推理引擎"角色，本身不存储业务数据，也不掌握流程，一切编排都发生在 WorkBuddy 侧。
这个架构最大的好处是模型可替换。WorkBuddy 对模型的调用接口做得比较通用，支持按 OpenAI 兼容格式指向任意后端。你既可以在本地开发时用便宜的模型快速验证流程，也能在正式环境切到更聪明的云端模型。我个人的建议是：流程调试阶段全部走本地模型，只有最终效果评审才切云端,这样既省钱又能保证开发节奏。
2.2 Ollama 在整条链路里的位置
Ollama 的作用是帮你把模型权重跑起来，对外提供一个标准接口。默认监听127.0.0.1:11434，其中/v1/chat/completions这个路径完全兼容 OpenAI 的消息格式，WorkBuddy 甚至不需要做任何协议转换就能直接调用。你可以把 Ollama 理解成一个"模型插座"——任何支持 OpenAI 格式的客户端，插上这个插座就能用本地模型。
这里要特别强调一个认知：Ollama 不是模型，它是一个运行时。同样一个qwen2.5:7b，在不同硬件、不同量化版本、不同启动参数下，跑出来的速度和效果天差地别。后面所有调优本质上都是在跟这个运行时讨价还价。
2.3 我的硬件环境参考
先说我的配置，方便你对照自己的机器判断。我用的是一张 24GB 显存的 RTX 4090，CPU 是 24 核，内存 64GB，系统是 Ubuntu 22.04。这个配置在本地大模型玩家里算中等偏上，24GB 显存意味着 14B 以下量化的模型都可以完整放进显存里跑，不需要部分卸载到内存。如果你的显卡是 8GB 或 12GB，也别灰心，后面讲模型选型的时候我会给出对应建议。
3. 环境准备：装 Ollama、拉模型、配 WorkBuddy
3.1 Ollama 安装和模型仓库准备
Ollama 的安装本身没什么好说的，Linux 一条命令，Windows 和 macOS 有安装包。真正卡人的是拉模型这一步。国内网络环境下载模型经常超时，我实测的解决办法是配置镜像源——这个细节后面专门讲。先说你最需要记住的几条命令：
# 查看 Ollama 服务状态 ollama serve # 拉取模型（以 qwen2.5 7B 量化版为例） ollama pull qwen2.5:7b-instruct-q4_K_M # 列出本地已有模型 ollama list # 查看模型详细参数 ollama show qwen2.5:7b-instruct-q4_K_M选模型有个铁律：显存允许的前提下，优先选最新系列的量化版本，而不是老模型的高精度版。比如 7B 量级，qwen2.5的 q4_K_M 量化版在绝大多数任务上的表现，都明显好过两三年前的 13B 模型。模型不是越大越好，是越新越聪明,这在资源受限的本地场景里尤其重要。
3.2 模型下不动的解决办法：镜像源的配置
这一步是很多人的第一道坎。ollama pull默认从官方仓库拉权重，国内网络经常卡在几十 KB/s，甚至直接中断。我的处理方式分两步：
第一步，先看系统是否有环境变量控制下载地址。Ollama 实际是把模型文件从 registry 地址下载到本地，你可以设置代理镜像。这里不讲任何特殊工具，单纯说配置方法：在启动 Ollama 之前，用export把镜像地址指到可用的国内源。不同地区的可用源变化很快，我不建议直接写死某一个地址，而是给你一个排查思路：拉不动的时候先看报错是网络超时还是 404，网络超时就换镜像，404 就检查模型 tag 写没写对。
第二步，下载慢还有一种取巧的办法——去模型仓库网站手动下载 GGUF 量化文件，然后用ollama create从本地文件创建模型。这个操作适合网络实在没救的情况：
# 手动下载 qwen2.5-7b-instruct-q4_k_m.gguf 到本地后 # 写一个 Modelfile FROM ./qwen2.5-7b-instruct-q4_k_m.gguf # 创建模型 ollama create qwen2.5-local -f Modelfile3.3 WorkBuddy 侧添加 Ollama 模型
WorkBuddy 的模型管理界面里，添加自定义模型时选择"OpenAI 兼容"类型，填入两个关键信息：接口地址填http://127.0.0.1:11434/v1，模型名称填你在ollama list里看到的完整名字，比如qwen2.5:7b-instruct-q4_K_M。这里最容易踩的坑是模型名漏了 tag 的部分。很多人只填了qwen2.5，结果 Ollama 会去找默认 tag，如果你拉的模型没有latest标签，就直接报 model not found。
还有一个细节：API Key 这一栏随便填什么都行，比如ollama三个字母。Ollama 本地接口默认不校验密钥，但 WorkBuddy 的表单可能会要求非空，填个占位符就能过。千万不要因为这个报错就以为配置失败了。
3.4 连通性自检：先别急着点 WorkBuddy 的发送按钮
我每次配置完新模型，都先用 curl 直接打 Ollama 接口，确认模型本身没问题，再回 WorkBuddy 排查。这一步能帮你把问题域切分清楚：如果是 curl 都报错，那是 Ollama 侧的问题；如果 curl 正常但 WorkBuddy 没输出，那问题在 WorkBuddy 的配置或请求拼接上。
curl http://127.0.0.1:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2.5:7b-instruct-q4_K_M", "messages": [{"role": "user", "content": "你好，用一句话证明你在工作"}], "stream": false }'正常情况下几秒内会返回一个 JSON，里面有choices[0].message.content字段。这一步过了，才轮到 WorkBuddy 去接。
4. 踩坑实录：从"无输出"到能用的完整排查记录
4.1 症状一：WorkBuddy 界面点了没反应，模型完全无输出
这是我最开始遇到的，也是最多人问的第一个问题。现象很统一：WorkBuddy 里配置好了模型，发送任务后界面一直转圈或者直接空白，日志里也没有明显报错。排查下来，背后原因有好几种，按发生频率排序：
第一种，Ollama 服务根本没起来。很多人装了 Ollama 就以为它在后台跑，实际 Linux 下如果没设成 systemd 服务，终端一关服务就没了。验证方法很简单：重新执行ollama serve看输出，或者再跑一遍上面的 curl。如果 curl 提示 connection refused，那就确认是服务没起来。
第二种，WorkBuddy 请求走了流式但本地处理超时。WorkBuddy 默认可能开启 stream 模式，而本地模型首次加载响应时间远比云端慢。7B 量化模型首次冷加载可能要 10 秒以上，如果 WorkBuddy 侧的请求超时设置只有 5 秒，就会表现为"无输出"。解决办法是在 WorkBuddy 模型配置里把超时调大，我一般设 120 秒；同时检查stream参数，如果 WorkBuddy 支持关流式就关掉，调试期关掉能少很多麻烦。
第三种，模型上下文参数太小导致推理中断。这个我单独开一节讲，因为它埋得太深。
4.2 症状二：上下文一长就崩，报错五花八门
有一次我在 WorkBuddy 里跑一个处理长文档的技能，内容大概三千字，结果模型生成到一半直接报500 internal server error，日志里能看到llama-server process相关的字样。这个报错熟悉吧？Ollama 跑 llama.cpp 系模型时进程崩溃，十有八九跟上下文长度有关。
原因在于 Ollama 默认的num_ctx只有 2048（某些新版本是 4096），超过这个长度的输入会被截断或者直接触发显存分配问题。你的业务文档一长，模型自然就崩。解决办法是在调用时显式指定上下文长度：
curl http://127.0.0.1:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2.5:7b-instruct-q4_K_M", "messages": [...], "options": { "num_ctx": 8192 } }'注意：num_ctx不是越大越好。我实测 7B 量化模型在 24GB 显存下，8192 上下文没有问题，但如果调到 32768，显存占用会暴涨，反而可能触发 OOM。上下文翻倍，KV cache 显存开销近似线性增长，你自己心里要有一笔账：8GB 显存老老实实 4096，12GB 可以试 8192，24GB 上 16384 基本是极限。
如果你的 WorkBuddy 技能里不方便直接传 options，那就用 Modelfile 把模型默认参数改掉：
FROM qwen2.5:7b-instruct-q4_K_M PARAMETER num_ctx 8192 # 用这个配置重建一个模型 ollama create qwen2.5-ctx8k -f ./Modelfile4.3 症状三：生成速度慢到怀疑人生
接通的下一步就是速度问题。我一开始用的时候，输出速度只有个位数 tok/s，那种感觉就是每等一分钟只蹦出几个字，根本没法用。排查下来，速度慢的根源无非四个：模型太大超出显存、量化精度太高拖慢计算、没有开启加速特性、服务端并发参数不合理。
先说模型太大的问题。如果你用 8GB 显卡跑 14B 模型，Ollama 会把一部分层卸载到内存，CPU 推理的速度大概是显存推理的十分之一，个位数 tok/s 太正常了。判断方法很简单：跑生成的时候用nvidia-smi看显存占用，如果显存占满了还在涨内存，那就是在卸载推理。这种情况要么换更小的模型，要么换更激进的量化,我在下一节展开讲。
再说别的问题：我发现默认情况下 Ollama 没有开启 Flash Attention，而这个是白送的性能。Ollama 0.5 版本之后可以通过环境变量OLLAMA_FLASH_ATTENTION=1开启。还有 KV cache 量化，设置OLLAMA_KV_CACHE_TYPE=q8_0能显著降低显存占用，相当于间接给模型腾出了更多空间。这两个变量需要在启动 Ollama 之前设好，改完重启服务才生效。
4.4 一个特别隐蔽的坑：模型第一次请求特别慢
还有一个现象值得一提：每次 WorkBuddy 重启后第一次调用模型，等待时间特别长，有时超过 30 秒，但是第二次就正常了。这不是故障，是模型冷加载。Ollama 在内存里缓存已加载的模型，默认策略是"最近使用过的模型保持驻留"。如果你的场景是高频短交互，建议把OLLAMA_KEEP_ALIVE调大，让模型常驻显存：
export OLLAMA_KEEP_ALIVE=30m这样 30 分钟内反复调用都不会重新加载模型。代价是显存一直被占着，如果你还同时跑别的需要显存的应用，要权衡一下。
5. 性能调优：把速度从个位数拉到 70 tok/s
5.1 模型选型与量化等级的取舍
性能问题的根源，八九成出在"模型和硬件不匹配"。我最后能稳定跑到 70 tok/s，靠的不是什么魔法参数，而是选对了模型规模和量化级别。
当时我在 WorkBuddy 里跑的是较为复杂的技能链，需要模型有不错的理解能力，所以一开始选了 14B 模型。实测速度大概 20 tok/s 出头，勉强能用但不够爽快。后来我做了个对比测试，同样任务分别跑 14B q4_K_M、7B q4_K_M、7B q8_0，结果很有意思：14B q4 的准确率比 7B q8 高一些，但速度差了两倍；而 7B q4 和 7B q8 的准确率差距很小，速度却差了将近 30%。
所以最终方案是：日常流程用 7B q4_K_M，追求极致速度；对理解要求高的场景临时切换到 14B。不要试图用一个模型打天下，WorkBuddy 支持配置多个模型源，不同技能挂不同模型才是最优解。
量化等级说明一下：q4_K_M 是 4-bit 量化的一种改进版，质量均衡；q8_0 是 8-bit，质量更高但显存占用翻倍。我的经验是 7B 这个规模，q4 和 q8 的效果差距在大部分任务上感知不明显，但速度差距很实在。建议先用 q4 跑通全流程，有余力再试 q8 对比效果。
5.2 三个真正拉满速度的参数
我最终把速度干到 70 tok/s，核心就动了三个地方。
第一个是 Flash Attention。刚才说过，环境变量OLLAMA_FLASH_ATTENTION=1必须开。这个特性对长上下文的加速尤其明显，短上下文也有收益，实测 7B 模型能提升 15% 到 25%，而且完全不影响输出质量，白赚的。
第二个是 KV cache 量化。OLLAMA_KV_CACHE_TYPE=q8_0让 KV cache 以 8-bit 存储，显存占用直接砍半。显存腾出来之后，模型可以用更大的 batch size 并行计算，吞吐自然上去。代价是极轻微的质量损失，在实际对话场景中几乎不可感知。
第三个是并发参数。Ollama 默认OLLAMA_NUM_PARALLEL=1，也就是同一时刻只处理一个请求。如果你在 WorkBuddy 里开多个技能并行跑，后面的请求全在排队。我把这个值调到 4，同时把OLLAMA_MAX_LOADED_MODELS设成 2。注意，并行度不是越高越好，并行会平分显存给各个请求的 KV cache，并行太高每个请求的有效上下文反而缩水。4 这个值是我试出来的甜点，你根据自己的显存微调。
这三个参数加起来，同样的qwen2.5:7b-instruct-q4_K_M，速度从最初的 8 tok/s 干到了稳定 70 tok/s。整个调优过程没花一分钱，就是反复试环境变量、重启服务、看日志。
5.3 用数据说话：调优前后的对比
我整理了一张自己实测的对比表，硬件是 4090 24GB，模型是 qwen2.5 7B q4_K_M，上下文 8192：
| 配置组合 | 首 token 延迟 | 平均速度 | 显存占用 |
|---|---|---|---|
| 默认参数 | 约 3s | 8-12 tok/s | 约 6.5GB |
| 开启 Flash Attention | 约 1.8s | 25-30 tok/s | 约 6.5GB |
| FA + KV cache 量化 | 约 1.2s | 40-45 tok/s | 约 4.2GB |
| FA + KV 量化 + 并行 4 | 约 1s | 65-70 tok/s | 约 5.8GB |
注意最后一行显存反而升了，因为并行 4 意味着同时给 4 个请求准备 KV cache 空间。如果你的场景是单请求大吞吐，并行保持 1 反而显存更省。
6. 日常使用避坑清单
6.1 高频问题速查表
我把这几个月被问得最多的几个问题整理成了一张速查表，每个都是我亲手踩过的：
| 现象 | 大概率原因 | 最快解法 |
|---|---|---|
| WorkBuddy 点击无输出 | Ollama 服务没起 / 请求超时 | 先 curl 验证，再调大超时到 120s |
| 报 500 internal server error / llama-server process | 上下文超限或模型文件损坏 | 调大 num_ctx；损坏就删了重新 pull |
| 生成内容乱码或答非所问 | 模型名填错，加载了没微调的基础版 | 核对 ollama list 里的完整名称 |
| 速度个位数 tok/s | 模型超出显存，部分层在 CPU 跑 | 换小模型或更激进量化 |
| 首次调用等 30 秒 | 冷加载，正常现象 | 调大 KEEP_ALIVE 让模型常驻 |
| 多任务排队缓慢 | OLLAMA_NUM_PARALLEL 太小 | 调到 2-4，注意显存余量 |
| 显存 OOM | 上下文太长或并行太高 | 降 num_ctx，关掉并行 |
6.2 我后来养成的几个使用习惯
踩坑踩多了，慢慢会形成一套肌肉记忆。我现在每次配置新的本地模型，都固定走四步：先ollama serve确认服务，再 curl 打接口验证模型，然后用一段长文本测试上下文上限，最后才连 WorkBuddy 跑真实技能。这套流程看起来多花了五分钟，实际上帮我省掉了后面数小时的排查时间。
还有一个小习惯值得分享：模型文件不要全堆在系统盘。Ollama 默认把模型权重存在~/.ollama/models，路径可以通过OLLAMA_MODELS环境变量改。我因为 C 盘不够用，踩过一次"拉完模型后磁盘满了导致无法生成"的坑，后来把模型目录专门挪到了一块大容量盘上。
6.3 安全提醒和合规边界
既然是博客分享，最后还是要多说一句边界问题。本地模型虽然把数据留在本地，但不代表可以随便用。公司的数据合规审查该走还是要走，模型本身的输出也可能存在偏见或错误信息，尤其在科研、文献综述这类场景下，AI 生成的内容必须人工复核。WorkBuddy 跑出来的结果，最终责任在操作者身上，这一点任何工具都替代不了你自己的判断。
7. 关于 WorkBuddy 接 Ollama，我最后的体会
Linode 上跑服务那套逻辑在本地模型上完全不适用,这是我折腾完之后最大的感慨。云端大模型像自来水，打开就有，但每吨都要钱；本地模型更像自己打井，前期挖井的过程费时费力，但出水之后用着是真踏实。WorkBuddy 和 Ollama 的组合，本质上就是帮你把"打井"这个事变得不那么痛苦,Ollama 把复杂的模型运行封装成一条命令，WorkBuddy 又把复杂的流程编排变成可视化的技能配置，两者一拼，普通用户也能拥有完全私有化的 AI 工作流。
最后再分享一个小技巧：如果你跟我的场景类似，主要用 WorkBuddy 做日常文档处理和自动化流程，7B 模型加 8192 上下文已经覆盖 90% 的场景。别一开始就追求大模型、长上下文，先把小模型全流程跑顺，让业务逻辑验证通过，再逐步升级模型规模,这才是最稳的路线。我个人的经验是：70 tok/s 的 7B 模型，实际使用体验远比 20 tok/s 的 14B 模型顺畅得多，而两者在大多数任务上的效果差距，远没有速度差距那么明显。
