前阵子折腾 WorkBuddy 接入 Ollama 本地模型，差点被“无输出”这三个字气到砸键盘。明明模型在终端里跑得好好的，一接到 WorkBuddy 里就哑火，日志看了一圈愣是没反应。后来一步步从调用链路、配置参数、模型加载方式排查下来，不仅解决了无输出，还把生成速度从最初的十几 tok/s 拉到了 70 tok/s 左右。这篇就把完整的排查过程、踩过的坑和最终的有效配置都整理出来，给同样在 WorkBuddy 里接本地模型的朋友做个参考。
先说下我的环境背景：Windows 11，32GB 内存，显卡是 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 URL：
http://127.0.0.1:11434/v1 - API 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-2b），Ollama 找不到模型就会返回空消息或者 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_gpu（GPU 层数）：控制模型有多少层放在 GPU 上。如果设得太小，模型大部分跑在 CPU 上，速度会直线下降。num_threads（CPU 线程数）：当模型部分层在 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 = "5m"OLLAMA_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 单次请求很容易超过这个长度。解决方法是给模型配置更大的上下文，可以写一个 Modelfile：
FROM 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 Error：llama-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_MODELS=D:\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 左右 | 响应慢，长任务像卡死 |
| 开启 stream | WorkBuddy 设置流式输出 | 15 左右 | 界面有反馈，但仍慢 |
| GPU 全量加载 | OLLAMA_NUM_GPU=999 | 40 左右 | 明显提速，显存占用升高 |
| 调整线程数 | OLLAMA_NUM_THREADS=8 | 50 左右 | 进一步提速，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_GPU=999、OLLAMA_NUM_THREADS=物理核心数、OLLAMA_KEEP_ALIVE=5m。 - WorkBuddy 里配置 Base URL 为
http://127.0.0.1:11434/v1，API 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，这大概就是本地模型接入路上最经典的一课了。
