WorkBuddy 接 Ollama,当时我一度以为是自己姿势不对。配好之后对话框里干干净净,一个大模型该有的样子都没有——既不报错,也不打字,就像对面坐了个已经下班的客服。后来从无输出一路查到 70 tok/s,中间踩的坑比预想的多,但每一个都值得写下来。这篇文章适合两类人:一类是刚把 WorkBuddy 装好、想让它用上本地模型的,另一类是已经配通了但速度感人、或者跟我一样遇到静默无输出的。我不打算只给你一份能抄的配置,更想还原整个排查思路——因为在本地大模型这条路上,配置错了不可怕,可怕的是它连错误都不告诉你。1. 先说结论:这套组合适合谁,最终配置长什么样1.1 本地模型到底解决了什么实际问题先回答一个基本问题:为什么放着好好的云端模型不用,非要在自己电脑上折腾一个跑得慢、能力还弱一点的本地模型。我的核心诉求有三个。一是隐私,有些文档和代码不方便出本机,云端对话意味着数据要经过别人的服务器,哪怕是正规服务商,很多团队也过不了这一关。二是免费额度,AI 助手的订阅费用一年下来不便宜,本地模型只要硬件允许,推理成本几乎为零。三是离线可用,高铁上、断网环境里,云端再强也跟你没关系,本地模型随时能干活。WorkBuddy 的优势在于它把模型服务抽象成了可配置项,你可以在设置里把它指向任意一个 OpenAI 兼容的服务地址。Ollama 恰好就提供了一个 OpenAI 兼容层,端口是 11434。所以 WorkBuddy 加 Ollama 的组合,本质上是客户端抽象层加本地推理引擎的对接,这也是它能成立的架构前提。1.2 我实测环境的最终配置表直接给结论,这是我反复验证过、已经稳定跑了一段时间的最终形态。项目配置主机Windows 台式机,RTX 4060 Laptop GPU(8GB 显存)Ollama 版本0.6.x(升级前踩过 0.5.x 的模型崩溃坑,后面细说)模型qwen2.5:3b,Q4_K_M 量化上下文长度4096WorkBuddy 指向地址http://127.0.0.1:11434/v1API Key随意填(本地服务不校验,但必须非空)实测速度70 tok/s 上下,长文本生成稳定在 60 以上这个速度对小模型来说已经算是跑起来了。注意我用的不是最新最花哨的模型,而是已经非常成熟的 qwen2.5:3b。本地模型生态里,稳定性比追新更重要,后面在排查 500 错误那节你会看到追新踩坑的代价。2. 装 Ollama 最容易卡住的三个环节:下载、存储路径与拉模型2.1 下载慢与离线安装:别跟网络较劲Ollama 的安装其实没难度,真正的门槛在于下载。官方安装包不大,但下载过程经常卡在中间,进度条走一半就不动了,重试一次可能又从零开始。我的做法是优先找离线安装包。从官方渠道拿到下载链接后,不要直接下载,把文件链接丢到能用取回或者断点续传的下载工具里面,这样断了还能续,不会被浏览器下载器搞崩溃。另外注意别只看一个平台,Windows、macOS、Linux 的包格式完全不同,认准自己系统的版本再拿。安装完成之后先启动服务,命令行验证一下:ollama serve再开一个新终端:ollama list能列出空列表,说明服务已经正常起来了。这一步很多人跳过,结果后面所有问题都从根本没服务开始。2.2 模型存储路径:不要默认装在系统盘Ollama 默认把模型文件存放在~/.ollama/models,Windows 下就是 C 盘的用户目录。一个 3B 模型量化后大概 2GB 左右,看起来不夸张,但如果你后续上了 7B、14B,甚至 embedding 模型一起放,几十 GB 是常态。C 盘一旦告急,模型加载会变慢,而且重装系统时这些模型全部报废。修改路径的方案很简单,Windows 上设置系统环境变量OLLAMA_MODELS,指向你想放的大目录,然后重启 Ollama 服务。Linux 下如果你是用 systemd 启动的,需要改 service 文件里的环境变量。提示:改完环境变量以后,记得把旧的模型目录整体搬过去,否则新路径下ollama list会显示空,又要重新拉,浪费流量。我当时就因为这个空列表差点重新下一遍模型,后来意识到只是路径迁移后还没同步。把原目录下的模型文件直接拷贝到新目录,重启服务,一切回归正常。2.3 拉取模型:名字写错最常见,版本新旧也会坑拉模型看起来只是一行命令:ollama pull qwen2.5:3b但名字写错的话,它会提示找不到模型,而不是给你一个模糊的请求失败。我见过很多人把qwen2.5:3b写成qwen3.5:2b——这个标签根本不存在,因为 Qwen 系列压根没有 3.5,只有 Qwen3 和 Qwen2.5。拉取时报错还算好的,更麻烦的是另一种:命令拉下来了(因为标签写对了),但模型内部结构和当前 Ollama 版本不兼容,运行的时候直接崩溃。对新手阶段,我建议先选已经在 Ollama 模型库验证过的经典版本,比如qwen2.5:3b、llama3.2:3b,然后量化级别直接用默认的 Q4_K_M。这些配置组合经过无数人踩过,基本不会出大问题。3. 无输出问题的完整排查链路:从 curl 探测到配置修正3.1 第一层:先确认 Ollama 服务和模型真的活着遇到无输出,第一步永远不是改 WorkBuddy 配置,而是先确认下游的 Ollama 到底正不正常。我把排查思路分成四层,一层层排除,哪一层先露馅就是哪一层的问题。先检查模型列表和服务状态:ollama list ollama psollama list能列出模型说明服务活着。ollama ps会显示当前已加载的模型和占用情况,如果跑过对话,这里应该能看到一条记录。如果 ps 输出为空,说明没有模型驻留在内存里,大概率你的请求根本没有到达 Ollama,或者刚进来就被请走了。接着用 curl 直接打接口,这一步可以把 WorkBuddy 完全隔离在外:curl http://127.0.0.1:11434/api/chat -d { model: qwen2.5:3b, messages: [{role: user, content: 说一句你好}] }如果这条命令能返回内容,那么 Ollama 本身就是好的,问题在 WorkBuddy 侧的配置。如果这条命令都无响应或报错,那问题在 Ollama 侧,WorkBuddy 只是个被牵连的受害者。3.2 第二层:WorkBuddy 的 endpoint、key、model 到底怎么填WorkBuddy 的模型服务配置界面里,通常需要填三样东西:服务地址(Base URL)、模型名(Model)、API Key。这三样各有各的坑。服务地址:正确写法是http://127.0.0.1:11434/v1,注意是带/v1的。Ollama 的 OpenAI 兼容端点挂在这个路径下,如果不带/v1,工具尝试访问http://127.0.0.1:11434/chat/completions,结果就是 404,但很多客户端在你没开详细日志时,404 的表现就是无输出,而不是弹一个错误框。API Key:本地 Ollama 不校验 Key,但你最好填一个非空字符串,比如ollama。有个别客户端在 Key 为空时根本不会发起请求,直接在本地就中断了,表现同样是无输出。模型名:一定要和ollama list里显示的完全一致。而且这里有一个容易忽略的点——有些工具支持指定数字上下文,如果你填的上下文远超模型的默认配置,加载会变慢甚至失败。我始就栽在这:模型名填错,客户端没报错,字节静悄悄,我还以为是模型生成能力为零。3.3 第三层:500 错误的真凶——llama-server 进程崩溃排到这一层时,curl 请求 Ollama 已经能返回正常结果了,但 WorkBuddy 里一发消息,过一会儿提示 500 错误。我翻日志才看到关键的一行:500 internal server error: llama-server process terminated。这个报错在 Ollama 0.5.x 版本上特别容易复现,尤其是跑 Qwen3 系列模型。原因是旧版 Ollama 对 Qwen3 的自定义对话模板支持不完善,模型生成时模板渲染崩溃,背后的llama-server进程直接干掉。表现就是你请求了一个模型,它加载了,但生成到一半整个过程崩了,客户端拿到 500。解决办法很简单:升级 Ollama。我把版本升到 0.6.x 之后,同样的模型、同样的 WorkBuddy 配置,再也没遇到这个崩溃。如果你用的 Ollama 版本比较新但还是 500,先跑一次ollama run qwen2.5:3b在本地命令行对话试试,如果命令行都崩,说明问题在模型文件本身,删掉重新 pull 一次。3.4 第四层:从 500 修好之后为什么还是无输出——超时与冷启动修好 500 之后,我以为万事大吉,结果 WorkBuddy 里又恢复了安静。这时候我意识到问题不在错误侧,而在等待侧。本地模型有个不同于云端模型的固有特征:冷启动慢。模型被拉取之后,如果没有驻留在内存里,第一次请求需要从磁盘加载权重,这个过程可能长达 20 到 40 秒。WorkBuddy 作为一个设计给云端服务的客户端,默认的响应超时时间往往只有几十秒。模型还在加载中,客户端已经不耐烦了,直接把这次请求判定为超时,界面上什么都不显示,或者显示一个空白会话。这个问题的解法有三个层面。第一,在 WorkBuddy 设置里把请求超时调到 90 秒以上,给足冷启动时间。第二,让 Ollama 把模型常驻内存,别每次都重新加载。在 Ollama 侧可以设置OLLAMA_KEEP_ALIVE,比如-1表示永久驻留,或者一个长一点的时间,比如30m。第三,先预热模型:启动 Ollama 之后,先用命令行ollama run qwen2.5:3b随便说句话,让模型加载好再打开 WorkBuddy 干活。提示:排查无输出时,最有效的习惯是先开 Ollama 服务窗口,边操作边看日志。客户端静默失败的时候,服务端的日志会老老实实告诉你请求来没来、崩没崩、超没超时。服务端日志才是第一现场。4. 从半天吐一个字到 70 tok/s 的调参记录4.1 先分清楚瓶颈在哪个环节:prefill、decode 还是网络无输出解决之后,新的烦恼来了:模型能回答,但没有那种哗哗往外冒的痛快感,反而像挤牙膏。想要提速,先要分清瓶颈在哪个环节。大模型生成一句话的时间 读入所有输入的时间(prefill) 逐个生成每个输出字符的时间(decode) 网络传输时间。对本地模型来说,prefill 受模型大小和算力影响,decode 几乎完全受内存带宽支配,而 WorkBuddy 和 Ollama 都在本机,本地回环网络延迟可忽略。怎么判断到底是哪个环节慢?看 Ollama 服务的日志或者ollama ps里的指标。如果你发现模型首字延迟很长,但后续字符很快,说明 prefill 阶段吃满了,常见原因是输入内容太长(上下文拉满)、模型量化太重、或者跑在 CPU 而不是 GPU 上。如果你发现是每个字都慢,那不是计算快慢的问题,而是内存带宽已经在极限了,只能换更小的模型或者更激进的量化。4.2 量化等级、上下文长度、并行度怎么搭配才是最优解我试了几组参数组合,最终稳定在 70 tok/s。这里把我的调参记录整理成对比表,方便你对照自己的硬件条件判断。参数项我踩过的慢配置最终采用的快配置原因模型版本qwen2.5:3b 原版qwen2.5:3b (Q4_K_M)量化到 4bit 后显存占用降一半,速度提升明显上下文长度81924096上下文越长,prefill 计算量越大,3B 模型没必要开太大并行请求默认 1OLLAMA_NUM_PARALLEL4单请求时 GPU 利用率不饱和,多开能提升吞吐驻留时间默认临时驻留OLLAMA_KEEP_ALIVE-1避免每轮对话都要重新加载模型平台CPU 模式GPU 加速CPU 跑 Q4 大概只有 8~10 tok/s,GPU 直接起飞其中量化这一步最值得展开。Ollama 拉取模型时默认给的是 Q4_K_M,但如果你手动指定了更高的量化,比如 Q8_0,显存占用会大很多,速度也跟着掉。3B 模型体积不大,Q4 精度损失基本可以忽略,没必要追求高量化。很多人的本地模型慢,不是机器不行,而是选了个和显卡不匹配的精密度。4.3 实测中的环境变量调整与最终验证Windows 下环境变量的设置,直接修改系统环境变量然后重启 Ollama 服务即可。Linux 下如果你是用 systemd 管理的,需要在 service 文件里添加:[Service] EnvironmentOLLAMA_NUM_PARALLEL4 EnvironmentOLLAMA_KEEP_ALIVE-1改完重启 Ollama,再验证一次最核心的指标——看真实的生成速度。用 curl 请求时加个stream: false,或者直接在命令行里:ollama run qwen2.5:3b命令行输出的最后会带一行类似于eval rate: 70.12 tokens/s的数据,这就是当前配置的真实速度。如果你发现eval rate只有个位数,那基本可以断定问题出在 CPU 推理上,检查一下 Ollama 服务日志里有没有识别到 GPU,而不是对着参数表反复调。顺带提醒一个与速度相关的隐性坑:有些模型默认带思考过程,输出一堆长段的思维链,你会感觉模型输出得很慢,其实它是把你的算力花在了 CoT 上。如果你不需要它思考,可以在 WorkBuddy 的请求里,或者在 Ollama 模型配置里,关掉思考模式。以 Qwen3 为例,跑 2B 这种小尺寸时思考链很容易频繁触发,关掉之后体感速度直接翻倍,实测就是这个环节让我从 40 多 tok/s 的感觉直接拉满到 70。5. 稳定之后可以往哪儿扩展,以及我说句实在话5.1 接多模型和 embedding:WorkBuddy 的本地生态扩展WorkBuddy 之所以值得折腾,不只是因为它能跑一个大模型,而是它可以配置多个模型服务,在不同场景下切换。比如写作类任务用 qwen2.5:3b 这种速度快的小模型,复杂推理切到 7B 甚至 14B;另外再挂一个 embedding 模型,比如 bge-m3,用来做本地文档检索。WorkBuddy 的 skill 体系配合本地模型,有一个边界需要心里有数:本地小模型的指令遵循能力是有限的。云端大模型能听懂复杂的多步指令,3B 模型往往会漏掉中间的某个条件。所以给 WorkBuddy 写 skill 时,我会刻意把提示词拆细,一次只给一个明确任务,而不是让它一口气做三件事。如果你在 skill 里塞了一堆外部工具调用(比如查数据库、跑脚本),建议在小模型上先跑通单步,再做组合,否则出了错你都不知道是哪一步出的问题。5.2 局域网共享与反向代理:不只是本机玩法Ollama 默认只监听127.0.0.1,意思是只有本机能访问。如果你的 WorkBuddy 跑在另一台电脑,或者你想在平板上用,需要把监听地址放开。设置环境变量OLLAMA_HOST0.0.0.0:11434之后,局域网内其他设备就能通过http://你的IP:11434/v1访问了。但注意,单纯放开监听意味着整个局域网的人都可以调你的模型,这既不安全也容易被别人白白占资源。我的建议是前面加一层反向代理,代理里做基本的安全校验,比如要求请求头里带上一个固定的 API Key,WorkBuddy 侧填好这个 Key,其他没有 Key 的请求一律拒绝。这个 Key 本地虽然不强制校验,但在代理层做校验能挡住局域网里手滑的邻居。5.3 和 LM Studio、云端模型的横向对比,以及什么时候该放弃本地模型接入本地模型这条路,不是只有 Ollama 一个选择。LM Studio 也能提供 OpenAI 兼容 API,而且它的交互界面更友好,适合纯新手;Ollama 的优势在于命令行生态好、可以用脚本批量管理模型、环境变量控制精细。它们定位是重叠的,选一个深入就行,不用反复切换。但我必须把丑话说在前面:本地模型和云端模型之间,现在还有一道肉眼可见的差距。WorkBuddy 本来是为云端模型设计的,很多特性和高阶能力依赖云端模型强大的推理水平。本地 3B 模型写个周报、抽个摘要、跑个代码片段完全够用,让它做深度的文献综述、复杂的代码重构,就会显得心有余而力不足。你可以在 WorkBuddy 里同时配置本地和云端两个服务,根据任务难度手动切换,这就是最务实的用法。最后再分享一个我反复用的小技巧:任何配置改动之后,先用 curl 验证再进 WorkBuddy 操作。WorkBuddy 的界面日志有限,而 curl 是你能掌控的最直接的测试工具:curl http://127.0.0.1:11434/v1/models如果这一步返回了模型列表,再接对话接口,每次改动只测一层,不要一次性改多个配置再测试。层级隔离、单点变更、服务端日志,这三件事贯穿了我这次整个排查过程。70 tok/s 不是终点,而是这套流程跑通之后自然而然的结果。
