如果你也经历过这种场面：满心欢喜地在 WorkBuddy 里把模型地址改成localhost:11434，指望着用本地 Ollama 省下云端 API 的账单，结果点下发送之后对话框一片空白，转圈转到天荒地老，最后弹出一行红字报错——那这篇文章就是写给你看的。
这篇文章是我从 WorkBuddy 接入 Ollama 本地模型全过程的完整记录，包含环境搭建、对接配置、无输出问题排查、以及最终把生成速度稳定拉到 70 tok/s 的优化手段。里面没有那种“照着做就一定成”的假保证，有的全是真实踩过的坑和对应的排查思路。适合手里有张游戏显卡、想把代码托管给开源模型跑的人参考，也适合已经被各种 AI 助手的订阅费搞烦了、想试试本地模型到底能不能干活的朋友。
1. 为什么放着云端模型不用，非得接本地 Ollama
1.1 WorkBuddy 这类工具本质上是个“模型无关的壳”
WorkBuddy 和同类的 CodeBuddy、Cursor、Cline 这些 AI 工作台工具，底层结构都差不多。界面上你能看到文件树、编辑器、对话框、终端按钮，看起来像个完整的 IDE，但真正干活的其实是背后的语言模型。前端界面只做了三件事：把你的输入和项目上下文组装成请求，发给模型服务，再把模型返回的内容解析成对话框里的文字或代码操作。
这里的关键点在于，模型服务是可以更换的。官方默认给的可能是某个云端的闭源模型，但协议上只要你用的接口格式兼容（现在基本都兼容 OpenAI 风格的那套/v1/chat/completions接口），你就能把服务地址指向任何地方。本地起一个 Ollama，就等于把整个模型的推理从别人的服务器搬到了自己的显卡上。
这个“模型无关”的设计是 WorkBuddy 这类工具最值钱的地方之一。它意味着你不需要换工具就能换模型，等于把 AI 助手这个产品拆成了“界面壳”和“模型内核”两层，按需组合。我当时就是看中了这一点，决定用 Ollama 把模型内核这一层完全本地化。
1.2 本地模型真正的价值在隐私与离线，不全是省钱
很多人一听说本地模型，脑子里第一个词就是“免费”。确实省钱，但如果你用一段时间就会发现，省钱只是最肤浅的好处。
更深一层的价值是隐私和离线可用性。用云端模型的时候，你写的每一段代码、每一句业务描述，都会以 Prompt 的形式发到远程服务器。哪怕是这些服务宣称“数据不用作训练”，把公司核心代码或未公开的项目结构送到外网仍然让人不太舒服。本地模型不一样，推理全部在你自己机器的显存里完成，请求不出本机，等于给代码上了一道物理层面的保险。
另外就是离线可用。Ollama 把模型拉下来之后，之后的运行完全不需要联网。我实测过，断网环境下 WorkBuddy 依然能正常调用本地模型做补全和对话，这对在隔离环境里开发的人或者经常出差坐高铁的人来说意义很大——高铁上的网络本身就是玄学，指望云端 API 流畅响应纯属给自己添堵。
最后才是成本。云端模型按 token 计费，写代码这种场景一天的消耗量相当可观，一个月下来订阅费加 API 费用上百块很常见；本地模型只有一个电费成本，一张 RTX 4070 级别的显卡推理 7B 模型时功耗大概一百多瓦，简直可以忽略不计。
1.3 先对号入座：你的使用场景适不适合本地模型
不过我得说实话，本地模型不是万能的，接入之前先冷静评估一下自己的使用场景很重要。
我自己的判断标准是这样的：如果日常工作集中在函数补全、单元测试编写、简单 bug 修复、正则表达式生成、代码解释说明这类“单点任务”，那现在主流的 7B/8B 量化模型完全够用，体验感甚至比某些云端大模型还好——因为响应快、不磨叽。但如果你的工作高度依赖跨文件的全局理解、大规模重构、复杂架构设计这类需要大量上下文综合推理的任务，本地小模型会明显力不从心。这时候硬接本地模型，体验可能还不如用云端模型来得舒坦。
所以结论很直接：本地模型适合的是“轻量高频”的使用模式，不适合“深度烧脑”的重型任务。先把这个预期管理好，后面踩坑的时候心态会稳很多。
2. Ollama 装好了不代表能干活：三个基础坑提前避开
2.1 安装包和模型下载慢：GGUF 直装与镜像加速才是正路
Ollama 的安装本身不复杂，Windows 直接下载 exe 安装包运行就行，Linux 一条 curl 命令的事。真正的坑出现在下载环节——官方安装包和模型文件都托管在境外服务器上，国内下载速度不稳定，拉一个 4GB 的模型可能要等到天荒地老。
我的处理方案分两种。第一种是安装包层面，优先找网速快的时候再下载，或者用支持断点续传的下载工具，避免中途失败需要重来。第二种是模型文件层面，不要死磕ollama pull命令，我后面发现从 Hugging Face 这类模型托管站点直接下载 GGUF 格式的模型文件再导入 Ollama，很多时候比ollama pull稳定得多。
具体做法很简单：先下载对应模型的 GGUF 文件，然后写一个 Modelfile 文件，内容只有一行FROM ./模型文件名.gguf，接着运行：
ollama create qwen2.5-coder:7b -f Modelfile这个命令会把本地的 GGUF 文件注册成 Ollama 的模型。之后无论在命令行还是 API 调用里，模型名就变成了qwen2.5-coder:7b，跟用ollama pull拉下来的完全一致。这条路径的好处是下载过程不受 Ollama 官方仓库的速度限制，而且 GGUF 文件来源更可控，中途断了也能续。
2.2 Windows 与 Linux 下的模型存储路径迁移
默认情况下 Ollama 会把模型文件放在系统盘：Windows 在C:\Users\用户名\.ollama\models，Linux 在/usr/share/ollama/.ollama/models或者用户目录下。一个 7B 的 Q4 量化模型大约 4-5GB，14B 要到 9-10GB，如果系统盘空间紧张，这个问题就非常现实。
改动方法不复杂。Windows 上先找到系统环境变量设置，新增一个OLLAMA_MODELS变量，指向你想放模型的位置，比如D:\ollama\models，然后彻底退出 Ollama 进程再重启。Linux 上同理，在 systemd 服务里加环境变量，或者直接在 shell 配置里 export。改完可以用ollama list确认模型还在，如果之前已经拉过模型，旧的存储路径下的模型会被忽略，需要重新拉一遍或者手动迁移文件。
我一开始没在意这个，结果模型拉下来之后发现 C 盘快满了，又折腾了一遍迁移。建议从第一天就改好环境变量，这个习惯能省下后面好多麻烦。
2.3 启动后用这个命令确认 Ollama 真的活着
装好、配好路径之后，先不要急着打开 WorkBuddy，先用命令行确认 Ollama 服务本身是健康的。
启动服务后，打开浏览器或 curl 访问地址：
curl http://localhost:11434/v1/models如果 Ollama 正常运行，会返回一串 JSON，里面包含了当前可用的模型列表。这个步骤能一次性排除很多问题：服务是否启动、端口是否被占用、模型是否已经就绪。注意要用/v1/models这个路径，因为这是 OpenAI 兼容接口的探活地址，WorkBuddy 走的也是这一套。
另外顺便看一眼防火墙。如果 Ollama 和 WorkBuddy 在同一台机器上，走 localhost 不需要处理防火墙；但如果 WorkBuddy 在另一台设备上想远程调本机的 Ollama，那就要设置OLLAMA_HOST=0.0.0.0:11434并且放行端口。我后面遇到过一次 WorkBuddy 配好之后连接失败，排查到最后才发现是 Linux 服务器的防火墙没放行 11434 端口。
3. WorkBuddy 对接 Ollama 的核心配置：地址、模型名与鉴权
3.1 配置文件里的 Base URL 为什么必须以 /v1 结尾
WorkBuddy 的自定义模型配置界面里，最关键的一项是 Base URL，也就是模型服务的地址。我在这一步栽过跟头，一开始填的是http://localhost:11434，怎么连都报错。
问题在于，Ollama 的 OpenAI 兼容接口并不是挂在根路径上的，完整的路径是/v1/chat/completions。所以 Base URL 必须写成http://localhost:11434/v1，WorkBuddy 会在后面自动拼接上/chat/completions。如果你只填到端口号，它请求的实际地址就变成了http://localhost:11434/chat/completions，而这个路径在 Ollama 上是没有对应路由的，自然会报错。
这在协议对接里是个特别容易忽略的细节。Ollama 本身有两个接口体系：一个是原生接口/api/generate和/api/chat，另一个是 OpenAI 兼容的/v1/chat/completions。WorkBuddy 这类工具用的是后者，所以地址必须带/v1。
3.2 模型名不能靠猜：ollama list 与完整签名的对应关系
配置界面里除了 Base URL，还需要填一个模型名称。这个字段同样有讲究，不能想当然地填一个“大概的名字”。
正确做法是先在命令行跑ollama list，看输出里的 NAME 那一列。比如显示的是qwen2.5-coder:7b-instruct-q4_K_M，那配置里就要完整填这个名字，一个字符都不能差。如果你在 WorkBuddy 里填的是qwen2.5-coder，但本地只有带q4_K_M签名的版本，请求就会直接返回 404 类型的错误，提示模型不存在。
这里特别提醒一下，Ollama 的模型签名由两部分组成：冒号前面是模型名，冒号后面是标签。qwen2.5-coder:7b和qwen2.5-coder:7b-instruct-q4_K_M可能是完全不同的两个模型。很多教程里为了简洁省略了标签后缀，抄教程的时候容易踩坑，一切以你本地ollama list的实际输出为准。
3.3 API Key 的“假鉴权”逻辑：为什么随便填都能过
配置界面里通常还有一个 API Key 输入框。按照常规思维，没有密钥应该连不上，但实测发现 Ollama 的 OpenAI 兼容接口对这个字段并不严格校验，随便填一个占位符，比如ollama或者sk-local，都能正常通过。
这背后的原因很简单：本地服务的鉴权逻辑由 Ollama 自行处理，它默认监听在 localhost，只允许本机访问，天然不存在跨网络的安全风险，所以 API Key 字段基本只是走个形式。但如果你把OLLAMA_HOST设置成了0.0.0.0让局域网内其他设备访问，那就等于把模型服务暴露出来了，没有任何真正意义上的鉴权保护。这种情况建议不要直接裸奔，要么用防火墙限制来源 IP，要么在 WorkBuddy 前面加一层带 Key 校验的反向代理。
我现在的做法是：本机调试用 localhost，真正需要远程调用的时候用反向代理把/v1路径转到 Ollama，同时校验请求头里的自定义 Key。这样既兼容 WorkBuddy 的鉴权字段，又不会把服务直接裸露到局域网。
4. “无输出”问题完整排查链路：从 API 层到上下文层
4.1 第一层排查：绕开 WorkBuddy，用 curl 直接审讯 Ollama
配置完成，满怀期待地点了发送，结果映入眼帘的是无尽的转圈，最后界面空白，或者直接报一条连接错误。这时候别急着怀疑 WorkBuddy 坏了，先绕开它，用 curl 直接面向 Ollama 发一个最简单的对话请求：
curl http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2.5-coder:7b", "messages": [{"role": "user", "content": "用 Python 写一个快速排序，只输出代码"}] }'这个步骤的目的非常明确：验证 Ollama 和模型本身能不能正常产出内容。如果 curl 能正常返回带有content字段的 JSON，说明模型和服务都是健康的，问题出在 WorkBuddy 和 Ollama 对接的某一层；如果 curl 也返回空内容、报模型不存在、或者连接超时，那就往下继续排查 Ollama 这边。
我当时 curl 测试完全正常，模型响应速度还不慢，这让我一度非常困惑：单独调用没问题，为什么经 WorkBuddy 一转发就完全不输出？这个矛盾恰恰说明问题不在模型本身，而在请求的内容或格式上。
4.2 第二层排查：翻日志看请求真相，tools、system 和 stream 一个都不能少
既然 curl 直连没问题，接下来就要看看 WorkBuddy 到底发了什么样的请求。每一种这样的工具都会在本地留下日志，WorkBuddy 也不例外。找到当日日志文件，搜索关键词ollama、11434或者chat/completions，能看到它实际发出去的网络请求细节。
我在日志里发现了三个与 curl 测试明显不同的差异：请求体里多了一段很长的 system prompt，多了一个tools参数（数组格式，里面定义了 WorkBuddy 用于操作文件、执行命令的若干工具函数），以及stream字段被设成了true。
这三个差异，每一个都能成为“无输出”的元凶。我后来把这三点分别单独测试，终于定位到了真正的问题所在，详见下面几节。
4.3 第三层排查：本地小模型的“工具调用恐惧症”与模型替代方案
问题最核心的元凶，是tools参数。
WorkBuddy 这类 AI 代理工具的一大特点是能够通过调用工具来实际执行代码、读写文件、运行终端命令。为了实现这个能力，它在每次请求时都会附带一个tools数组，里面描述了一系列函数的结构，包括函数名、参数类型和说明。模型需要根据用户指令决定是否调用某个工具，以及怎么填参数。
听起来很顺理成章，但问题在于本地小模型并不都具备合格的 tool calling（工具调用）能力。我当时的测试结论是：我在本地拉的qwen2.5:7b通用对话模型，在收到带有完整tools数组的请求后，返回的choices里内容是空的，等于模型面对一份看不懂的“函数说明书”，直接选择了沉默。而复现实验同样验证了这一点：手动在 curl 请求里加上同样的tools数组，模型立刻返回空响应；去掉tools，模型恢复正常回复。
有人说用“qwen2.5:7b-instruct”可以解决，实测下来它确实支持 function calling，但对 WorkBuddy 这类复杂的工具描述遵循度依然一般。如果想要稳定的工具调用格式，当时的实测环境下更推荐qwen2.5-coder:7b-instruct或者llama3.1:8b，这两者在收到 tools 定义后能正确输出工具调用格式，而不是直接返回空白。
这个坑是“无输出”整个事件中最隐蔽的一点。它不会报错，模型在后台确实执行了推理，但吐出来的东西是空的。界面上看起来就是转圈后一片空白。
4.4 第四层排查：max_tokens 太小、上下文压迫与“系统提示词 PUA”
换掉模型之后，输出终于有了，但很快又出现了另一个变种问题：模型明明有回复内容，WorkBuddy 界面上却只显示几个字或者干脆空白。这个问题的来源是max_tokens设置。
WorkBuddy 在向模型发请求时，会携带一个输出长度上限参数。有些版本的默认值非常保守，可能只有 64 或者 128。本地小模型收到“只输出 64 个 token”的指令后，生成一句“好的我来看一下”就把配额用完了，剩余内容被截断。用户看起来就像“没有输出”。
这个排查起来特别容易忽略，因为接口层面完全正常，日志里也没有报错，只是生成内容长度被切断了。我的处理方式是：在 WorkBuddy 的自定义模型高级设置里，把 max_tokens 手动调大到 2048 甚至更高。代码生成场景非常消耗 token，一段稍复杂的函数就要 500+ token，64 的配额连开个头都不够。
另一个隐蔽的坑是 WorkBuddy 自带的系统提示词。它的系统提示词通常有上千 token，里面充斥着“你是专业程序员助手”之类的指令，还带了一大段工具使用格式说明。本地小模型对长系统提示词的服从度较高，但当系统提示词里出现“不要输出无关内容，直接调用工具”这类倾向时，模型可能真的选择什么都不说静默等待工具调用指令。这个问题的解法一个是在 WorkBuddy 设置里精简或修改系统提示词，另一个是保持合理的温度参数（我实测 0.5 到 0.7 比较合适，太高容易乱编，太低容易呆板）。
4.5 第五层排查：冷启动加载时间与 OLLAMA_KEEP_ALIVE
还有一类无输出会伪装成“连接超时”。具体表现是：第一次请求时等了很久，然后 WorkBuddy 报错；紧接着第二次请求又恢复正常了。如果你遇到的也是这种模式，那大概率是模型冷启动的问题。
Ollama 的默认行为是模型在空闲一定时间后从显存卸载。当你发出请求时，如果模型还在加载，Ollama 要先把模型文件读入显存，这个过程在机械硬盘上可能要十几秒甚至更久，而 WorkBuddy 的 HTTP 客户端超时时间没那么宽容，等着等着就弃了。
这个问题的解决方案有两个层面。第一，在向 WorkBuddy 发正式请求之前，先在命令行跑一次ollama run 模型名，让模型加载进显存预热；第二，设置环境变量OLLAMA_KEEP_ALIVE=5m或者更长，让模型在完成请求后继续驻留显存一段时间，避免频繁卸载和重新加载。我记得当时调整完这个参数之后，连续会话的响应速度明显稳定了很多。
5. 把速度从“写一行停三秒”拉到 70 tok/s 的优化组合拳
5.1 先看懂瓶颈公式：显存、量化与并发的关系
模型能正常输出之后，新的问题又来了，速度太慢。一行一卡，完全没法用。
生成速度这件事，用一个简单的公式就能看懂：每秒生成 token 数约等于 GPU 有效算力除以模型激活参数规模。模型越大越慢，这是物理规律。所以提速的大方向无非两条：要么换更小的模型，要么想办法榨干显卡现有的算力。
在 Ollama 的语境下，最有效的杠杆是量化等级。一个 FP16 精度的 7B 模型，显存占用大约 14GB，推理速度也慢；换用 Q4_K_M 量化后，显存占用降到 5-6GB，速度几乎翻倍。这就是为什么说量化等级比显卡型号还重要。我在尝到甜头后，把手里所有模型都换成了 Q4_K_M 版本。
5.2 实测几组模型配置的速度对比
我最后的测试环境是 RTX 4070（12GB 显存），直接把语言设置为qwen2.5-coder:7b-instruct-q4_K_M，记录不同配置下的实际速度：
| 模型 | 量化 | 上下文长度 | 实测速度 | 备注 |
|---|---|---|---|---|
| qwen2.5-coder:7b-instruct-q4_K_M | Q4_K_M | 4096 | 60-70 tok/s | 最终稳定方案 |
| llama3.1:8b-q4_K_M | Q4_K_M | 4096 | 50-60 tok/s | 可用，工具调用格式较稳 |
| qwen2.5:7b（默认） | 默认 | 8192 | 30-40 tok/s | 伴随工具调用空白问题 |
| deepseek-r1:7b-q4_K_M | Q4_K_M | 4096 | 15-25 tok/s | 带思维链，输出前反复推理 |
注意最后一行，deepseek-r1 这类推理模型在输出正式答案之前会先生成一大段思考内容，所以用户感觉上特别慢，即使模型本身的推理速度并不低。如果追求交互流程度，这种带深度思考的模型要慎选。
5.3 Ollama 环境变量与启动参数调优清单
在 Ollama 层面，有几个环境变量直接决定了运行效率和资源占用，值得专门整理一下。
第一个是OLLAMA_NUM_PARALLEL，控制同时并行处理的请求数。我把它设为 1，也就是一次只处理一个请求。很多人觉得并行越多越好，但在单显卡场景下，并行请求会吃满显存并增加单请求延迟，对 WorkBuddy 这种交互式使用反而有害。串行模式下每次请求都能占满全部算力，实际体感更快。
第二个是OLLAMA_MAX_LOADED_MODELS，默认可能同时驻留多个模型。如果你在 WorkBuddy 里配了多个本地模型，并且切来切去，这个参数直接限制同时加载的模型数量，设为 1 可以强制 Ollama 在切换模型时主动卸载旧模型，避免显存被多个模型瓜分导致单个模型性能下降。
第三个是反向辅助的OLLAMA_KEEP_ALIVE，我在上一节提过，设为5m或更长能让模型保持驻留。综合来看，这几个参数共同的目标就一句话：让显卡专注服务当前这一个小模型，不要分心。
最后别忘了确认 GPU 真的在工作。命令行下直接跑一次nvidia-smi，看显存占用和进程列表里是不是有 Ollama 的进程。如果显存没被占用，说明模型正在用 CPU 推理，那速度就只能是惨不忍睹的个位数 token 每秒。这个问题常见于 GPU 驱动和 CUDA 环境异常的场景。
5.4 WorkBuddy 侧的使用习惯优化：别让上下文成为拖累
除了 Ollama 本身的参数设置，WorkBuddy 这边的使用习惯同样影响速度。最容易被忽视的是上下文长度的隐性成本。
很多人以为上下文长度只是“能记住多少内容”的容量，但在推理性能上，输入内容的长度直接决定“预填充”阶段的耗时。每一轮对话，模型都需要先把整个历史消息重新处理一遍，再开始生成新内容。如果你把一条两万字符的文件整段贴进对话框，光预填充就要花掉好几秒，哪怕生成速度是 70 tok/s，体感还是慢。
所以我的使用习惯是：大文件不整段粘贴，而是先问 WorkBuddy 需要看哪部分，或者只贴关键代码片段。另外，单次会话不要无限延长，聊完一个任务就新开一个会话，让上下文长度保持克制。这是零成本的提速方式，比换显卡还划算。
温度参数的调整我放到最后说，因为它的影响不体现在速度上，而体现在“正确率”上。WorkBuddy 默认的温度如果过高，本地小模型的输出会开始放飞自我，生成大量格式不规范的代码。我在 0.5 附近找到了一个稳定点，代码准确率和创造性平衡得不错。
6. 稳定跑起来之后的真实体验与后续扩展
6.1 当前配置清单与实测效果
现在我的这份配置已经稳定运行了一段时间，贡献产出也比较稳定，具体如下：
- 模型：
qwen2.5-coder:7b-instruct-q4_K_M - 上下文长度：4096
- 基础 URL：
http://localhost:11434/v1 - 硬件：RTX 4070（12GB 显存）
- 速度：稳定 60-70 tok/s
- 温度：0.5
- max_tokens：2048
这个配置下 WorkBuddy 的表现已经能支撑日常开发了。让它生成独立的小工具脚本、写单元测试、把一段混乱代码整理成规范格式、解释某个接口的用法，这些任务的完成质量都在可用线以上。最让我满意的是响应速度，本地模型输出几乎是即时的，没有云端模型那种“思考中”的等待感。
当然，它的短板也很明显。跨文件的深度重构和复杂架构设计的建议质量不如顶级云端模型，偶尔会在工具调用格式上犯迷糊，需要手动纠正。但这些都在预期之内，毕竟这张 12GB 显存的卡跑 7B 模型已经是花小钱办大事了。
6.2 后续还可以尝试的方向
如果你也想走这条路，并且显卡显存比较宽裕，可以考虑几个扩展方向。显存在 16GB 以上的，可以试试qwq-32b这类更大参数的模型，Q4 量化后占用大约 20GB 以内的显存区间，推理质量会有明显提升；显存有限的，可以换个思路，在客户机使用 LM Studio 作为替代运行时，它的模型管理界面更直观，也提供了 OpenAI 兼容接口。本质上 Ollama 和 LM Studio 是同一类东西，选哪个只看你对哪个的工具链更顺手。
另外如果对模型格式协议熟悉，可以把 Ollama 的接口换成更专业的推理框架接给 WorkBuddy，不过这种方案配置成本高，收获相对有限，短期内没必要折腾。先把上面的配置跑起来，体验到本地模型的便利之后，再按需扩展也不迟。
最后分享一个个人体会：本地模型这条路，真正的门槛不是显卡性能，而是对 LLM API 交互方式的认知。理解了 Base URL、模型签名、工具调用、上下文长度这些概念之后，WorkBuddy 接什么模型都不再是问题。踩坑不可怕，只要能把“无输出”拆解成一个个可验证的环节，总能找到答案。
