WorkBuddy 接入 Ollama 的“无输出”排查与 70 tok/s 调优

前阵子折腾 WorkBuddy 接入 Ollama 本地模型差点被“无输出”这三个字气到砸键盘。明明模型在终端里跑得好好的一接到 WorkBuddy 里就哑火日志看了一圈愣是没反应。后来一步步从调用链路、配置参数、模型加载方式排查下来不仅解决了无输出还把生成速度从最初的十几 tok/s 拉到了 70 tok/s 左右。这篇就把完整的排查过程、踩过的坑和最终的有效配置都整理出来给同样在 WorkBuddy 里接本地模型的朋友做个参考。先说下我的环境背景Windows 1132GB 内存显卡是 8GB 显存的甜品卡Ollama 0.5.x 版本模型用的是 Qwen3 系列 2B 量化版。WorkBuddy 配置里选了自定义 API 端点指向 Ollama 的默认地址。这套组合非常典型也是出问题的高发区。1. 接入前的环境准备与模型选型1.1 WorkBuddy 对接 Ollama 的原理WorkBuddy 本质上是一个 AI 代理工作台它本身不跑模型而是把任务拆分、工具调用、上下文管理等活儿接下来然后把补全请求发给后端模型。对接 Ollama 的逻辑很简单WorkBuddy 通过 OpenAI 兼容接口调用 Ollama。Ollama 从 0.1.29 版本开始支持/v1/chat/completions这个 OpenAI 兼容端点所以理论上只需要在 WorkBuddy 里填上Base URLhttp://127.0.0.1:11434/v1API Key随便填比如ollama本地服务不做鉴权但字段不能留空模型名称qwen3:2b或你本地拉取的具体模型 tag但理论归理论实际配置完点测试你会发现响应慢、报错、超时、无输出情况五花八门。原因就藏在这条调用链路的每一环里。1.2 Ollama 安装与模型选择Ollama 的安装没什么难度官网下安装包一路 Next 就行。但有两个细节我建议提前处理好安装路径不要放 C 盘系统盘。模型文件动不动几个 GB后续换盘迁移虽然能解决但不如开始就装到 D 盘或其他空间充裕的分区。用OLLAMA_MODELS环境变量可以直接改模型存储路径。模型优先选量化版本且参数量匹配显存。在 8GB 显存环境下Qwen3 的 2B、4B 量化版比较合适。如果你强行跑 14B 模型即使显存勉强放下推理速度也会跌到没法用而且很容易触发内存交换产生各种诡异超时。模型拉取命令很简单ollama pull qwen3:2b拉取完成后先直接在命令行里验证一下模型本身能不能正常输出ollama run qwen3:2b 你好介绍一下你自己这一步必须做。如果这里输出都断断续续或者报错不要急着甩锅给 WorkBuddy先把模型侧的问题解决。我在这一步就试过跑了几个小模型发现某些模型在低显存下会频繁回退到 CPU 推理导致速度极慢。1.3 端口与日志检查Ollama 默认监听127.0.0.1:11434。WorkBuddy 如果跑在同一台机器上直接填这个地址没问题。但有个容易忽略的点Windows 防火墙可能会拦截 Ollama 的本地端口。虽然 127.0.0.1 回环地址一般不受影响但如果你用的是局域网地址或者 WSL 环境就要注意放行11434端口。确认服务是否正常可以直接在浏览器访问http://127.0.0.1:11434/api/tags返回 JSON 列表表示服务正常。同时可以看 Ollama 的日志Windows 下日志在%LOCALAPPDATA%\Ollama\server.log如果日志里出现error级别的信息特别是关于llama-server process的崩溃记录那就是模型加载阶段出了问题。这些准备工作做完再开始接 WorkBuddy。2. 第一次接入遇到“无输出”的坑2.1 无输出的表面现象与实际原因我的第一次接入现象非常典型WorkBuddy 界面上能看到任务在跑工具调用也在执行但模型返回的内容永远是空的。既不报错也不超时就像一个大哑巴。排查第一步先绕过 WorkBuddy直接模拟它的请求。用 curl 打一下 Ollama 的兼容接口curl http://127.0.0.1:11434/v1/chat/completions -H Content-Type: application/json -d {\model\:\qwen3:2b\,\messages\:[{\role\:\user\,\content\:\你好\}]}如果这里能正常返回content说明 Ollama 侧没问题问题出在 WorkBuddy 的配置或者它解析响应的方式。我在实测中发现很多人配置的时候会填错 API Key 或者模型名带了无关后缀比如填qwen3:2b:latest或者写成了qwen3-2bOllama 找不到模型就会返回空消息或者 404而 WorkBuddy 对这类错误处理得特别保守界面只显示一个空回包不暴露底层错误。另一个非常隐蔽的原因是Ollama 的 OpenAI 兼容端点要求请求体里的model字段必须和ollama list显示的名字完全一致而 WorkBuddy 在一些版本里会自动给模型名加前缀或后缀。解决办法是在 WorkBuddy 的模型配置里直接写qwen3:2b不要多填别的东西。2.2 排查日志的三板斧遇到无输出我按下面这个顺序排查效率最高看 Ollama 日志。server.log里如果有post /v1/chat/completions的记录说明请求到达了 Ollama如果没有说明 WorkBuddy 压根没把请求发出来。这一步能快速定责。看 WorkBuddy 日志。WorkBuddy 的日志一般在用户目录下的.workbuddy/logs或logs文件夹。重点搜error、timeout、connection关键字。我在日志里见过最离谱的一条是 WorkBuddy 把 Base URL 自动追加了/v1导致最终请求变成http://127.0.0.1:11434/v1/v1/chat/completions直接 404。手动模拟请求并比对模型名。用 curl 分别请求/api/chat和/v1/chat/completions确认两个端点的行为一致。如果/api/chat正常而/v1/chat/completions异常说明兼容层出了问题考虑升级或重装 Ollama。2.3 配置文件的正确写法最终在 WorkBuddy 里能跑通的配置我记录下来供参考provider: custom base_url: http://127.0.0.1:11434/v1 api_key: ollama model: qwen3:2b stream: true max_tokens: 4096 temperature: 0.7注意几个关键点base_url结尾的/v1一定要写上Ollama 只有在/v1路径下才启用 OpenAI 兼容接口。stream: true要打开否则 WorkBuddy 会一直等到完整响应生成才渲染界面对于长输出会显得像“无输出”。实测很多所谓无输出其实是等太久界面没有任何流式反馈用户以为挂了。max_tokens不建议设太小否则长文档生成会在中途截断。WorkBuddy 默认值可能只有 512对于写作、分析类任务远远不够。配置改完后建议先在 WorkBuddy 里发一句“请回复 1”做快速连通性测试比直接跑完整任务能更快定位问题。3. 性能问题从龟速到 70 tok/s 的调优3.1 影响生成速度的关键参数“无输出”解决之后第二个大问题是慢。一开始只有十几 tok/s生成一小段话要转半天。要提速得理解影响 Ollama 推理速度的几个核心参数num_ctx上下文长度这个参数决定了模型可以“看到”多少历史内容。数值越大显存占用越高但并不是越大越好。过大的上下文会让模型浪费大量显存导致推理速度下降。num_gpuGPU 层数控制模型有多少层放在 GPU 上。如果设得太小模型大部分跑在 CPU 上速度会直线下降。num_threadsCPU 线程数当模型部分层在 CPU 上运行或者显存不足时线程数影响计算速度。但线程数不是越多越好太多反而会引发 CPU 争抢。keep_alive模型在内存中的保持时间。如果这个值设很大模型会一直驻留下次请求不用重新加载。如果设成 0每次请求都重新加载速度会非常惨。3.2 实测调优记录我的 8GB 显存跑qwen3:2b时默认配置下显存占用不高但速度只有十几 tok/s明显没有充分发挥硬件性能。后来通过修改 Ollama 的模型运行参数把速度提升了 4 倍。在 Ollama 中可以通过OLLAMA_NUM_GPU环境变量或创建 Modelfile 来指定这些参数。我采用的是环境变量方案在启动 Ollama 之前设置$env:OLLAMA_NUM_GPU 999 $env:OLLAMA_NUM_THREADS 8 $env:OLLAMA_MAX_LOADED_MODELS 1 $env:OLLAMA_KEEP_ALIVE 5mOLLAMA_NUM_GPU 999表示所有层都尝试加载到 GPU对于 2B 模型来说完全放得下。OLLAMA_NUM_THREADS 8匹配我当时 CPU 的物理核心数避免超线程带来的负优化。OLLAMA_KEEP_ALIVE 5m让模型在 5 分钟内常驻内存连发多次任务时不用反复加载。修改完重启 Ollama用同一个 prompt 测试tok/s 从 15 左右直接跳到了 60 上下。再把 WorkBuddy 里的max_tokens从 2048 调到 4096并确认stream打开最终稳定在 70 tok/s 附近。3.3 上下文长度对速度的隐藏影响还有一个容易被忽略的是 WorkBuddy 本身会不会额外塞入很多上下文。WorkBuddy 作为 AI 代理会在每次请求中把系统提示词、工具定义、历史对话一起发给模型。如果这些内容太长实际可用的num_ctx就会不够模型要么报错要么被迫压缩上下文导致输出质量下降、速度变慢。我在排查时发现Ollama 默认的num_ctx只有 2048而 WorkBuddy 单次请求很容易超过这个长度。解决方法是给模型配置更大的上下文可以写一个 ModelfileFROM qwen3:2b PARAMETER num_ctx 8192 PARAMETER temperature 0.7然后构建一个新模型ollama create qwen3-wb -f Modelfile之后 WorkBuddy 里模型名填qwen3-wb。这一步做完后长文档任务不再半路中断速度也没有明显下降。如果你发现模型总是只输出一小段就停大概率就是num_ctx太小导致的截断。4. 常见问题与排查技巧实录4.1 500 Internal Server Errorllama-server process热词里有人提到ollama run qwen3.5:2b error: 500 internal server error: llama-server process。这个我遇到过通常不是 WorkBuddy 的问题而是模型运行时崩溃。可能原因有三个显存不足模型加载到一半被系统杀掉。看日志会有CUDA out of memory字样。量化版本与当前 Ollama 版本不兼容某些新模型的 GGUF 格式需要更新的 llama.cpp 后端。解决方法是升级 Ollama 到最新版或者换成官方更稳定的量化版本。模型文件损坏通过ollama pull重新拉取即可修复。排查时先直接运行ollama run如果命令行都报 500说明与 WorkBuddy 无关先解决 Ollama 侧的问题。如果命令行正常只有 WorkBuddy 触发时报 500检查请求是否携带了 Ollama 不支持的参数比如logprobs、n等WorkBuddy 部分版本会在补全请求里追加这些参数。4.2 模型存储路径迁移Ollama 默认把模型放在C:\Users\用户名\.ollama\models很容易把系统盘塞满。迁移方法停止 Ollama 服务和所有相关进程。把models文件夹移动到目标盘比如D:\ollama_models。设置环境变量OLLAMA_MODELSD:\ollama_models。重新启动 Ollama运行ollama list确认模型还在。注意这一步容易踩坑如果直接复制正在运行的模型文件夹会出现文件占用错误所以务必先完全退出 Ollama包括任务栏图标的退出而不是只关窗口。在 Windows 上我看 Ollama 进程还在后台就很正常直接去任务管理器把 Ollama 相关的进程都结束再迁移。4.3 离线安装与国内镜像源问题Ollama 安装包本身不大但模型下载经常卡住或超时。网络条件不好的场景下有两个替代方案先在有条件的机器上ollama pull然后把整个models文件夹拷贝到目标机器。只要两个机器的 Ollama 版本一致模型拷贝过去就能直接识别。用环境变量指定国内镜像源。设置$env:OLLAMA_REGISTRY https://docker.1ms.run这类镜像地址有效性变化快需要自己测试。我自己用下来最稳的还是从其他机器拷贝模型文件夹省去下载等待的时间。4.4 WorkBuddy 本身的几个小坑结合网上的反馈和自己实测还有几个 WorkBuddy 使用上的细节值得注意系统缓存目录默认在 C 盘。WorkBuddy 会把工作日志、临时文件、技能包缓存在用户目录下时间长了也能占好几个 GB。软件设置里可以手动更改缓存路径提前改到其他盘避免后续迁移麻烦。Skill技能包不是越多越好。WorkBuddy 官方市场里有大量 skill装多了每个 skill 的工具定义都会塞进请求上下文里白白消耗num_ctx拖慢速度。按需安装不用的直接禁用。和 CodeBuddy 混淆的问题。网上不少人在问 WorkBuddy 和 CodeBuddy 的区别简单说 CodeBuddy 更偏向 IDE 内的代码辅助WorkBuddy 更像是通用的 AI 代理工作台能接各种模型和工具链。如果只是写代码两个都能胜任偏好智能体工作流的选 WorkBuddy偏好编辑器内联体验的选 CodeBuddy。Win7 兼容性。官方已经不支持 Win7 了别浪费时间在旧系统上折腾Ollama 新版也放弃了 Win7硬要跑只能找旧版本但维护成本太高。5. 从 15 到 70 tok/s 的实操复盘5.1 调试前后对比为了更直观地看到每一步的作用我把调试过程的主要节点列一下阶段配置调整tok/s 表现问题现象初始状态默认参数未开流式15 左右响应慢长任务像卡死开启 streamWorkBuddy 设置流式输出15 左右界面有反馈但仍慢GPU 全量加载OLLAMA_NUM_GPU99940 左右明显提速显存占用升高调整线程数OLLAMA_NUM_THREADS850 左右进一步提速CPU 不再拉满扩大上下文num_ctx 8192重新建模型70 左右长任务稳定无截断这里 tok/s 的数字受 prompt 长度、模型量化等级、硬件温度等因素影响不同跑法会有差异但趋势是一致的先把模型完全压到 GPU再调整 CPU 线程最后优化上下文和流式交互这套组合是性价比最高的调优路径。5.2 最终可复现的配置清单把整个过程沉淀成可复现的清单下次换机器或换模型照着做就行安装 Ollama设置OLLAMA_MODELS到非系统盘。拉取模型先在命令行验证ollama run能正常对话。创建 Modelfile设置合适num_ctx一般 4096 到 8192根据任务长度选如果需要更长上下文同时确认显存是否够。启动 Ollama 前设置环境变量OLLAMA_NUM_GPU999、OLLAMA_NUM_THREADS物理核心数、OLLAMA_KEEP_ALIVE5m。WorkBuddy 里配置 Base URL 为http://127.0.0.1:11434/v1API Key 随意非空模型名填自定义模型名开启流式。用最短 prompt 测试连通性再跑实际任务观察速度和截断情况。如果仍无输出按“WorkBuddy 日志 → Ollama 日志 → curl 手动请求”的顺序定位。这套流程我后来又在一台 16GB 内存的纯 CPU 机器上验证过虽然跑不了 70 tok/s但思路一致调大线程数、缩小模型到 1.5B 量化版也能从不可用提升到勉强能用的程度。5.3 一点个人体会折腾完这一趟我对本地模型接入智能体工具有个明显感受大部分“无输出”问题都不是模型本身的问题而是调用方配置与本地服务兼容性的问题。Ollama 作为一个轻量级模型运行框架提供了 OpenAI 兼容接口但这个兼容层在不同版本间表现差异很大。WorkBuddy 这类工具又在持续迭代两者的版本匹配经常出现代差。所以我现在的习惯是每次升级 Ollama 或 WorkBuddy先跑一遍最小连通性测试再恢复正常工作流能避开大多数隐形雷。如果非要说一个最值得分享的小技巧那就是遇到问题先手动 curl 一遍接口。这个动作能把问题快速二分到“服务端”还是“客户端”省掉大量无效排查。很多朋友一上来就翻 WorkBuddy 的配置项改来改去忙活半天发现是 Ollama 进程根本没起来或者模型名写错了。犹记得我第一次折腾的整个下午都在反复切换 API Key 格式、改网络设置最后才发现只是 Base URL 少了一个/v1这大概就是本地模型接入路上最经典的一课了。