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 4090CPU 是 24 核内存 64GB系统是 Ubuntu 22.04。这个配置在本地大模型玩家里算中等偏上24GB 显存意味着 14B 以下量化的模型都可以完整放进显存里跑不需要部分卸载到内存。如果你的显卡是 8GB 或 12GB也别灰心后面讲模型选型的时候我会给出对应建议。3. 环境准备装 Ollama、拉模型、配 WorkBuddy3.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 显存老老实实 409612GB 可以试 819224GB 上 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_ATTENTION1开启。还有 KV cache 量化设置OLLAMA_KV_CACHE_TYPEq8_0能显著降低显存占用相当于间接给模型腾出了更多空间。这两个变量需要在启动 Ollama 之前设好改完重启服务才生效。4.4 一个特别隐蔽的坑模型第一次请求特别慢还有一个现象值得一提每次 WorkBuddy 重启后第一次调用模型等待时间特别长有时超过 30 秒但是第二次就正常了。这不是故障是模型冷加载。Ollama 在内存里缓存已加载的模型默认策略是最近使用过的模型保持驻留。如果你的场景是高频短交互建议把OLLAMA_KEEP_ALIVE调大让模型常驻显存export OLLAMA_KEEP_ALIVE30m这样 30 分钟内反复调用都不会重新加载模型。代价是显存一直被占着如果你还同时跑别的需要显存的应用要权衡一下。5. 性能调优把速度从个位数拉到 70 tok/s5.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_ATTENTION1必须开。这个特性对长上下文的加速尤其明显短上下文也有收益实测 7B 模型能提升 15% 到 25%而且完全不影响输出质量白赚的。第二个是 KV cache 量化。OLLAMA_KV_CACHE_TYPEq8_0让 KV cache 以 8-bit 存储显存占用直接砍半。显存腾出来之后模型可以用更大的 batch size 并行计算吞吐自然上去。代价是极轻微的质量损失在实际对话场景中几乎不可感知。第三个是并发参数。Ollama 默认OLLAMA_NUM_PARALLEL1也就是同一时刻只处理一个请求。如果你在 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 延迟平均速度显存占用默认参数约 3s8-12 tok/s约 6.5GB开启 Flash Attention约 1.8s25-30 tok/s约 6.5GBFA KV cache 量化约 1.2s40-45 tok/s约 4.2GBFA KV 量化 并行 4约 1s65-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 模型顺畅得多而两者在大多数任务上的效果差距远没有速度差距那么明显。