1. 项目背景为什么非得把 WorkBuddy 接上本地 Ollama1.1 真实需求免费、私密、还能离线用先说结论我折腾 WorkBuddy 接 Ollama是因为受够了云端模型的三件事——按量计费烧钱、隐私数据不敢往上传、断网就歇菜。WorkBuddy 本身是个偏向智能体工作台的工具日常用来做任务拆解、写文献综述、整理项目材料经常会暴露个人信息和代码片段如果长期走云端 API第一是不放心第二是一趟活干完账单感人。还不如在本地部署一个 Ollama跑一个中等体量的开源模型把 WorkBuddy 的推理后端切成普通模型既保住了数据不出本机也把高频的简单任务从“按 token 计费”变成了“电费”。Ollama 的优势在于它把编译、量化、加载、缓存全都包了一个命令就能拉起一个兼容 OpenAI 格式的本地服务对 WorkBuddy 这类需要 HTTP 调用大模型接口的工具来说非常友好。不需要自己手搓推理框架也不用折腾 Python 环境只要把 API 地址从云端换成http://localhost:11434/v1理论上就已经完成了接入。1.2 核心链路WorkBuddy、Ollama、模型之间怎么连线整个接入过程其实是一条很直接的数据链路WorkBuddy发指令、收文本 ↓ OpenAPI 风格的 /v1/chat/completions Ollama 本地服务监听 11434 端口 ↓ llama.cpp 推理引擎 本地开源模型GGUF 量化格式WorkBuddy 只负责做任务编排和状态管理真正回答问题的能力来自模型。所以排查问题的时候要先分层是 WorkBuddy 参数没配对是 Ollama 服务没起来还是模型本身回答不出来。我在这次踩坑里学到最值钱的一句话就是——不要一上来就怀疑模型先验证链路每一段是否通。后面的所有排查记录基本都围绕这句话展开。2. 安装部署先让 Ollama 自己跑得足够稳2.1 下载安装、存储路径和环境变量Ollama 的安装本身没什么技术含量官方页面下载对应系统的安装包或者用包管理器装都行。但有两个细节容易被忽略。第一个是模型存储路径。Ollama 默认把模型放在用户目录下Windows 是C:\Users\用户名\.ollama\modelsLinux 是/usr/share/ollama或者~/.ollama。如果你图形工作站只有一块硬盘默认路径通常无所谓但如果系统盘是 256G 的小固态一个大模型动辄 5~8G用不了几个就把系统盘塞满了。所以我的建议是装完第一时间改存储目录Windows 在系统环境变量里新增OLLAMA_MODELSD:\ollama\modelsLinux 则是export OLLAMA_MODELS/data/ollama/models改完重启服务。这一步看起来 trivial但真等到硬盘报警再迁移就全是泪。第二个是镜像站下载。如果你在下载安装包时发现速度很慢别硬等可以去国内一些开源镜像站下载安装包体验会好很多。无论从哪里下载装完都要记得校验一下服务是否正常。2.2 模型选型与首次运行模型选型我走了不少弯路。最开始图省事直接ollama run qwen2.5:1.5b想快速跑通链路结果发现 WorkBuddy 里的任务稍微复杂一点1.5b 的回答质量就不够用了经常答非所问而且一旦要求它做“工具调用”它根本接不上。后来换成qwen2.5:7b效果好了很多。这里想顺便说一个教训在算力允许的情况下模型规模至少 7B 起步1.5B 和 3B 用来做本地 API 连通性测试可以拿来干正经活就太勉强了。执行下面的命令可以先把模型拉下来ollama pull qwen2.5:7b ollama run qwen2.5:7b首次运行会完成加载之后就可以在终端里直接对话测试一下模型的“基本智商”。如果终端里都答不出来那问题在模型层如果终端正常但 WorkBuddy 连接后没反应问题就在集成层。2.3 先验证 Ollama 服务本身可用模型跑起来之后用 curl 直接打一下接口确认服务是真的对外可用curl http://localhost:11434/api/generate -d { model: qwen2.5:7b, prompt: 你好, stream: false }正常情况下会返回一小段 JSON里面包含response字段和 token 消耗统计。这一步的意义是把 Ollama 从疑犯名单里摘出去后续出问题的时候就能笃定问题是出在 WorkBuddy 这一侧。3. WorkBuddy 侧配置把后端从云端切成 localhost3.1 添加自定义模型服务的操作路径WorkBuddy 默认接的是云端服务但它的模型管理里留了自定义端点入口。不同版本的菜单位置会略有差异但逻辑是一致的进入“设置 → 模型服务 / 自定义端点”然后添加一个新的服务配置。主要填这几个参数API 地址填http://localhost:11434/v1。有人只填http://localhost:11434那会走 Ollama 原生路由WorkBuddy 如果用 OpenAI 客户端格式请求会解析不到路径直接报 404这是第一坑。API KeyOllama 本地服务默认不鉴权随便填一个比如ollama或local-key只要不空着就行。模型名称要填qwen2.5:7b。这个名称必须和ollama list里显示的 tag 完全一致大小写和后缀都要对上。是否支持工具调用如果 WorkBuddy 的代理任务里需要用“工具调用”去操作文件、查数据库那么要勾选支持。qwen2.5 系列对工具调用的支持还行后面性能优化章节会展开讲。填完保存在模型下拉框里选中刚加的本地模型顺手把“目标模型”切过去就可以开始试了。3.2 几个容易跟云端 API 混淆的参数用云端服务的时候很多参数都是平台侧帮你兜底的换成本地 Ollama 之后这些参数全部暴露给你了含义完全不一样。我列一张表供参考参数云端习惯Ollama 本地行为建议设置请求超时通常几十秒本地也可能很慢调到 300 秒以上避免小模型思考超时被掐断最大输出 token常用 2048受num_predict控制至少给 4096复杂任务给 8192上下文长度平台自动处理受num_ctx控制默认 4096调到 8192 或 16384否则长任务被截断温度0.7 左右同样是 0.7写作任务 0.2~0.4思路拓展 0.8我后来遇到“无输出”问题本质上就是参数设置不协调导致的这块在下一章展开。4. 排查记录从“无输出”到正常识别的完整过程4.1 故障现场状态正常回复面板空空如也接入完成后的第一次实操我卡了整整一个晚上。现象非常诡异WorkBuddy 显示已经连接上了本地模型任务列表也在正常推进但回复内容一直是空白既没有报错也没有卡死的迹象就像模型在“装死”。一开始我以为是模型加载慢等了 10 分钟还是空的。后来我用 WorkBuddy 的日志功能抓取请求记录发现在每个任务的回包里内容字段确实是空的。这说明模型服务其实响应了但吐出来的内容有问题问题不在“通不通”而在“格式对不对”。日志里最关键的一行错误是这样的Invalid response: content field is None or empty. finish_reason: null.看到这个报错我反而踏实了——不是网络断了而是 WorkBuddy 收到的响应结构不符合预期。4.2 分层排查从模型到服务再到客户端排查的顺序按照之前说的链路来第一步直接在终端里跑 Ollama 原生对话确认模型本身能正常生成文本。这一步很顺证明模型没问题。第二步用 curl 以 OpenAI 兼容端点测试curl http://localhost:11434/v1/chat/completions -d { model: qwen2.5:7b, messages: [ { role: user, content: 说一句你好 } ], stream: false }这次返回正常能看到choices[0].message.content里有明确的文本。那我基本可以断定问题出在 WorkBuddy 的请求构造上。第三步回头去检查 WorkBuddy 的发送参数。我打开日志中的请求体发现 WorkBuddy 默认给请求里加了一段“工具函数定义”也就是告诉模型它可以调用哪些函数。而 qwen2.5:7b 在收到这种格式时如果参数里没有正确的tools声明或者工具定义太过复杂模型会直接回一个空的内容字段转而尝试“调工具”却调了个寂寞。4.3 真正的坑工具调用和流式响应叠加真相大白之后修复方案就很明确了。问题出在两部分第一Ollama 的上下文长度太小。默认num_ctx是 4096WorkBuddy 的一次任务会塞入系统提示词、历史记录、工具定义还没轮到真正的问题就已经接近上限。模型在生成时感觉“上下文是满的”就直接吐了个啥内容都没有的响应。这个现象特别隐蔽因为日志里没有任何显式报错只是空内容。解决方式是在启动 Ollama 服务时通过环境变量调大上下文set OLLAMA_CONTEXT_LENGTH16384 # 或者 Linux export OLLAMA_CONTEXT_LENGTH16384重启服务后再测空响应出现的频率明显下降。之后我又在 WorkBuddy 的请求参数里手动加了num_ctx: 16384把这个参数固定下来。第二禁用或精简工具调用。WorkBuddy 默认把它能用的工具全部塞给模型数量一多本地小模型的选择压力就大。我在实验阶段直接关掉了“自动工具调用”选项让它先走“纯对话”模式跑通链路确认正常之后再逐步打开文件操作、代码搜索这类高频工具。这样既保证链路可跑又不至于一开始就被复杂的工具定义怼懵。另外还有一个隐藏点WorkBuddy 默认开启流式输出而 Ollama 在流式输出时如果是通过代理转发就很容易出现“首帧为空”的现象客户端解析时会把首个空帧当作“结束帧”从而显示空白。我当时的处理方式是先把流式关闭确认模型能一次性吐完文本跑稳定之后再开启流式。如果一定要开着流式请确认 WorkBuddy 的底层 HTTP 客户端能正确聚合多个delta帧而不是一见空帧就中断。4.4 修复后验证与效果对比修复完这三个点上下文长度、工具调用、流式帧处理再跑同一个任务输出已经正常。首轮完整对话的实测数据是指标修复前修复后是否返回内容否是首 token 延迟—0.4 秒左右平均生成速度—约 30 tok/s任务完成率10%95%虽然已经能用了但 30 tok/s 只能算“凑合”离舒服还差得远。于是下一阶段进入性能调优。5. 性能调优从 30 tok/s 一路跑到 70 tok/s5.1 先确认 GPU 加速有没有生效很多人装了 Ollama 之后以为默认就会用显卡其实不一定。如果是纯 CPU 环境跑 7B 模型的 Q4 量化速度大概在 5~15 tok/s 之间体验非常难受。想要 70 tok/s关键就是把模型加载到 GPU 显存里去。一般情况下Linux 上直接执行ollama ps能看到模型当前跑在哪个设备上。输出里如果显示100% GPU说明已经走了 GPU 路径如果显示100% CPU就需要排查。Ollama 在 NVIDIA 显卡上基本不用额外配置装好驱动就能用。但 AMD 显卡用户需要设置环境变量set HSA_OVERRIDE_GFX_VERSION11.0.0 set OLLAMA_NUM_GPU1在 Windows 上还有一个常见坑OpenGL 和显卡驱动冲突导致 Ollama 识别不到显卡。我在自己机器上就遇到过更新显卡驱动之后立刻从 8 tok/s 跳到 45 tok/s提升巨大。5.2 三个关键参数num_ctx、num_predict、batch size跑通之后我又在 WorkBuddy 和 Ollama 两层配置里做了几个针对性调整第一把num_ctx固定为 8192。上下文太大显存占用暴涨而且首 token 延迟也会变长太小则容易截断导致生成质量下降。经过实际对比7B 模型在 8192 上下文下显存占用大概 6~7GB正好合适。第二合理设置最大输出 token。WorkBuddy 里默认的max_tokens有时只有 1024对于写文献综述这种任务根本不够用。我改成 4096 之后长文本能一次写完不用中途重试减少了大量重复开销。第三调整并发请求参数。如果你用的是 16G 以上显存GPU 还有余量可以考虑开启并行set OLLAMA_NUM_PARALLEL2 set OLLAMA_MAX_LOADED_MODELS2但 8G 显存建议不要碰并发否则多个请求争抢显存反而互相拖慢。我试过开 4 并行速度直接掉到 25 tok/s谁插队谁倒霉。5.3 实测记录与最终效果调优过程我记录了几个典型的数字配置平均速度说明纯 CPU1.5B12 tok/s能跑但没法工作CPUGPU1.5B35 tok/s测试链路用CPUGPU7B默认参30 tok/s上下文被截断频繁空响应GPU 驱动更新 num_ctx819255 tok/s已经可日常用了模型量化换成 Q4_K_M 固定参数70 tok/s最终稳定状态最终能到 70 tok/s其实是模型量化格式、驱动、上下文参数三者共同配合的结果。我在ollama pull的时候特意指定了qwen2.5:7b-q4_K_M这个量化等级的精度和速度平衡最适合日常任务。注意一个细节不要为了速度盲目上 Q2 量化那会让模型回答质量肉眼可见地下降节省的那些毫秒不值得。现在日常我用 WorkBuddy 本地 Ollama单轮对话的响应速度体感上不比云端慢多少而且完全离线访问记录也不会被任何平台收集这一点对我来说比 70 tok/s 更重要。6. 高频坑位速查与经验沉淀6.1 问题排查速查表把这段时间踩过的坑汇总成一张表遇到同样问题可以直接对号入座现象可能原因解决办法API 请求返回 404地址写错没加/v1改用http://localhost:11434/v1显示已连接但无输出num_ctx太小或工具调用冲突调大上下文关闭工具调用测试响应很慢卡在 5 tok/sGPU 未生效更新驱动检查ollama ps模型加载后立刻退出显存不足换更小的量化版本例如q4_K_M长文本写到一半就断num_predict太小调到 4096 或 8192多次请求后速度下降并发参数不当调小并行度重启服务报错llama-server process模型损坏或服务冲突删除模型重新 pull关闭其他服务再试6.2 日常使用中容易忽略的细节有几个细节是排查时非常容易忽略的单独拎出来说第一修改 Ollama 环境变量之后必须重启服务不是重启 WorkBuddy 就行的。而且如果在 Windows 上要把 Ollama 托盘图标彻底退出再从终端启动环境变量才会重新加载。我至少有一次改了OLLAMA_CONTEXT_LENGTH但忘了重启结果白调了半天。第二WorkBuddy 侧的日志开关一定要打开。出问题时没有日志就是瞎子。在设置里把日志等级调到debug排查完再调回去这个动作其实能省大量时间。第三本地模型对“长指令”的容错能力较弱。在 WorkBuddy 里写 prompt 的时候尽量把任务拆成小而明确的步骤不要一句话里既有背景又有要求还带着三个问题。本地模型不像云端大模型那样能一次消化复杂提示词合理的任务拆解能明显提升输出质量。第四一定要区分“请求通没通”和“回答好不好”。这两个问题经常被混为一谈。如果请求通了但回答质量差那是模型能力问题换更大的模型或者更好的量化版本才对如果请求都没通那是链路和配置问题。用这个标准去判断排查思路会清晰很多。6.3 我对 WorkBuddy Ollama 这套组合的几点判断这套组合适合什么场景呢我自己的核心场景是日常知识工作自动化让 WorkBuddy 帮我整理项目文档、写初稿、做资料汇总这些任务不需要顶级云端模型的理解力但需要大量次数用本地模型低成本反复跑非常合适。不适合的场景则是高难度全局推理任务尤其是涉及跨章节关联的复杂分析。7B 模型的推理深度确实有限这时候我会把任务切回云端大模型形成本地、云端双通道。实践下来最佳的使用模式是——简单高频任务全部丢给本地复杂任务才走云端两边各司其职成本和工作效率都最优。最后再分享一个小操作。日常使用中如果发现模型响应变慢不要急着重启 WorkBuddy先到 Ollama 所在机器的终端执行ollama stop qwen2.5:7b ollama run qwen2.5:7b手动把模型从显存里卸载再重新加载很多时候速度就回来了。这个操作比重启整个服务要快得多也是我调优之后用得最多的技巧。