最近给 WorkBuddy 接入 Ollama 本地模型前前后后折腾了两天。一开始以为就是填个地址、选个模型的事结果栽在“无输出”这个坑里爬了半天后面又为速度折腾了一轮最后才摸到一套能稳定跑到 70 tok/s 的配置。如果你也想把 WorkBuddy 这类 AI 工作台接到本地 Ollama 上这份完整踩坑记录应该能帮你省下不少时间。先说清楚这篇记录的定位它适合正在用或打算用 WorkBuddy 搭个人工作台、做科研辅助、整理知识库又不想把对话数据交给云端 API 的人。全文只讲本地部署不涉及任何云端依赖。我会从方案选型开始讲完安装部署、“无输出”的完整排查过程最后聊聊我是怎么把速度从“半天不出字”优化到 70 tok/s 的。1. 方案选型为什么 WorkBuddy 要配 Ollama1.1 先搞清楚 WorkBuddy 在整套流程里的位置WorkBuddy 不是模型运行者它是调度者。你可以把它理解成一个装配车间的工位台WorkBuddy 负责任务编排、技能Skill管理、上下文组织而真正的“发动机”是底层的模型推理服务。我选它的核心原因是它能让我把多个操作串成一个工作流而不是每次都手动复制粘贴 prompt 去调用命令行。这种组合特别适合几类场景。比如科研辅助我需要模型帮忙整理文献摘要、提炼论文结构WorkBuddy 可以把这些步骤固定成技能下次直接触发再比如搭个人工作台把日报生成、代码片段审查这类重复劳动变成半自动流程。甚至有些人用它来做小程序教学应用案例的开发辅助把学生的问题分类、生成示例答案。关键点在于WorkBuddy 这类工具通常默认让你配置云厂商的 API但它真正有意思的地方是支持自定义模型接口。配好之后数据完全不出本机生成的内容再敏感也不会往外送。1.2 本地推理引擎怎么选Ollama、LM Studio 还是 vLLM市面上常见的本地推理方案就那几类Ollama、LM Studio、vLLM/SGLang还有直接裸跑 llama.cpp。我一开始在 LM Studio 和 Ollama 之间犹豫过。LM Studio 的图形界面确实好上手下载模型、调参数都有可视化按钮但对命令行和外部 API 的集成不如 Ollama 利索。vLLM 性能很强但配置门槛高个人场景属于大材小用。方案上手难度模型管理API 兼容适合场景Ollama低命令一行搞定OpenAI 兼容WorkBuddy 单机接入、个人使用LM Studio低图形界面完成也兼容 API想纯 GUI 操作、不想碰命令行vLLM/SGLang高需要自己组织模型OpenAI 兼容高并发、多用户服务裸 llama.cpp中全手动自己封装深度定制、学习底层原理我最后选 Ollama 的理由很直接它对模型的管理足够省心ollama pull就能拉模型ollama list看模型列表而且原生提供 OpenAI 兼容接口WorkBuddy 只需要按 OpenAI 的配置方式填地址就行。对单机工作台来说Ollama 的性能已经足够将来如果真要跑到多用户高并发再迁移到 vLLM 也不迟。1.3 我的硬件与初始选型测试环境是一张 12GB 显存的消费级显卡配 64GB 内存和 8 核 CPU系统是 Windows 和 Ubuntu 双环境都跑过。最初我直接拉了 14B 的 Qwen2.5 量化版想着模型越大质量越高。这个选择后来证明是“无输出”和速度慢的重要诱因之一。14B 模型做 4-bit 量化后体积大约 9GB听起来 12GB 显存条理上够但一旦上下文长度调大KV Cache 会额外吃掉 2GB 以上显存很容易爆。显存一爆Ollama 就退回 CPU 推理速度直接掉到每秒几个 tokenWorkBuddy 那边很容易判定超时表现就是“没有任何输出”。现在回头看这个教训值得单独拎出来讲。2. 环境部署Ollama 安装、存储路径与模型导入2.1 安装与最基础的环境变量Ollama 的安装本身没什么难度。Windows 版本下载安装包双击就行Linux 用官方脚本安装。真正容易踩坑的是环境变量尤其是模型存储路径和监听地址。默认情况下模型会装在系统盘我第二次部署就遇到 C 盘空间告警。Windows 下解决办法是先设置用户环境变量setx OLLAMA_MODELS D:\ollama\models然后完全退出 Ollama 再重新启动。Linux 下不要直接改启动脚本官方推荐用 systemd 的 override 文件sudo systemctl edit ollama.service写入[Service] EnvironmentOLLAMA_MODELS/data/ollama/models EnvironmentOLLAMA_HOST0.0.0.0:11434然后执行sudo systemctl daemon-reload sudo systemctl restart ollama。这里有个很关键的细节如果 WorkBuddy 和 Ollama 在同一台机器上OLLAMA_HOST保持默认的127.0.0.1:11434就行如果 WorkBuddy 装在另一台电脑想访问这台机器的模型服务才需要把监听地址设为0.0.0.0。改完环境变量必须重启服务否则看似改了其实没生效这是“改了半天没用”的头号原因。2.2 模型下载慢手动拉文件再导入下载模型是另一大痛点ollama pull在部分网络环境下能慢到让人怀疑人生。我第一次拉 14B 模型挂着等了一晚上还是断断续续的。解决思路很简单不通过ollama pull而是手动把模型文件下载到本地再通过 Modelfile 导入。GGUF 格式的模型文件在模型社区里到处都有找到对应版本的 4-bit 量化文件放到一个固定目录然后写一个 ModelfileFROM ./qwen2.5-7b-instruct-q4_K_M.gguf TEMPLATE {{- if .System }}|im_start|system {{ .System }}|im_end| {{- end }} |im_start|user {{ .Prompt }}|im_end| |im_start|assistant PARAMETER temperature 0.7 PARAMETER stop |im_end|然后执行ollama create qwen2.5-7b -f Modelfile等它提示成功再用ollama list确认模型已经注册。这里有个细节自定义导入的模型名可以自己定但这个名字就是 WorkBuddy 里要填的模型名两边必须完全一致包括中间的冒号和版本号错一个字符都连不上。需要多说一句Modelfile 里的 TEMPLATE 部分最好直接参考模型官方仓库里的模板不要自己乱写。模板不对会出现一种非常隐蔽的问题——接口返回正常但模型输出前言不搭后语或者输出被截断。2.3 服务自测curl 与 ollama ps把模型导入之后先别急着去 WorkBuddy 里配置先用命令行确认服务本身正常。这一步能省掉后面大量无意义的反复尝试。先看服务是否起来ollama serve正常情况下前台会输出日志。另开一个终端测接口curl http://127.0.0.1:11434/api/tags返回 JSON 里应该能看到你已经导入的模型列表。再看模型是否成功加载到显存ollama ps如果列表为空说明模型还没有加载。真正加载是发请求时才发生所以可以顺手打一次生成请求curl http://127.0.0.1:11434/api/generate -d { model: qwen2.5-7b, prompt: 你好 }我自己第一次测试时就发现日志里有类似 “no suitable GPU” 的提示模型退回 CPU 跑了。这说明显卡驱动或依赖有问题这种问题如果不在服务侧发现进了 WorkBuddy 界面里看就只剩一个“无输出”排查难度会翻好几倍。3. WorkBuddy 接入与“无输出”问题的完整排查3.1 WorkBuddy 配置界面里最容易填错的三个点WorkBuddy 接入自定义模型时核心配置项就三个接口地址、API Key、模型名。其他高级参数先不要动。接口地址最典型的问题是到底带不带/v1。Ollama 同时提供原生接口和 OpenAI 兼容接口WorkBuddy 这类工具走的是 OpenAI 协议地址要填到/v1也就是http://127.0.0.1:11434/v1如果你填成不带/v1的地址很多工具会拼出http://127.0.0.1:11434/chat/completions而 Ollama 原生接口根本没有这个路径结果就是 404 或者连接莫名失败。API Key 这里有个反直觉的坑。Ollama 默认不做鉴权理论上随便填一行字符串都能用。但有些客户端把 API Key 留空时会直接不发 Authorization 头或者干脆认为配置未完成而拒绝请求。最稳妥的做法是填一个任意字符串比如ollama占住这个字段。模型名必须和ollama list输出完全一致。比如你导入的名字是qwen2.5-7b就别在 WorkBuddy 里填成qwen2.5。少一个版本号接口直接返回 404这看起来像“连接失败”实际是模型名不匹配。3.2 “无输出”定位方法论先把 WorkBuddy 踢出局“无输出”是我这次遇到最迷的现象任务能创建请求看起来也发出去了但回答区域一直空白或者转几圈就默默失败。排查这类问题我的经验是先不要把时间花在图形界面上反复重试而是把 WorkBuddy 踢出局直接用命令行模拟请求。这里的核心方法论很简单先证明服务侧能正常输出再怀疑客户端配置。我建议按这个顺序来第一步用浏览器直接访问http://127.0.0.1:11434/v1/models看能否返回模型列表。这一步能确认服务进程活着且 OpenAI 兼容接口正常。第二步在终端用 curl 发一个完整的对话请求curl http://127.0.0.1:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5-7b, messages: [{role: user, content: 你好}] }如果这一步能返回内容说明模型服务完全正常问题出在 WorkBuddy 的配置上。第三步检查系统里有没有装网络调试类、加速类的工具这类工具常驻后台时偶尔会拦截本机回环地址的请求。表现出来的现象很迷惑命令行里 curl 一切正常WorkBuddy 里就是不行。我当时就遇到这种情况排查了半天才发现是常驻工具拦了127.0.0.1的流量。第四步翻 WorkBuddy 的日志。日志里通常会写实际请求的 URL、超时时间、报错原因。这一步比在界面里瞎试高效得多。3.3 我这次遇到的实际故障我在这个阶段一共碰到了三层问题每一层都足以让 WorkBuddy 表现为“无输出”。第一层是模型名填错。我把导入的qwen2.5:14b填成了qwen2.5-14b接口返回 404WorkBuddy 把报错吞掉之后界面就是一片空白。这个修复最没技术含量但因为界面不报错反而卡了我很久。第二层是模型根本没成功加载。ollama ps显示为空日志里提示显存不足模型退回 CPU。14B 模型权重加 KV Cache 把 12GB 显存吃满了Ollama 没法全层 GPU 加载只能用 CPU 跑首字延迟长得超过 WorkBuddy 的超时阈值从用户视角看就是“永远没有第一个字”。这个我到最后才意识到因为在命令行里直接 curl 虽然慢但当时没有耐心等到它出结果。第三层是驱动问题。有一次升级 Ollama 之后GPU 加载直接失效日志里写着只用了 CPU。重启、重装都没用最后更新显卡驱动才恢复。这类问题如果只看界面你永远只能看到“无输出”但服务侧日志会直接告诉你瓶颈在哪。排查“无输出”问题一定记住先看服务侧日志再查客户端配置最后才考虑重装软件。3.4 验证打通用脚本确认输出正常经过上面几轮修复我用一段 Python 脚本确认服务已经能正常返回import requests resp requests.post( http://127.0.0.1:11434/v1/chat/completions, json{ model: qwen2.5-7b, messages: [{role: user, content: 你好}], stream: False }, timeout120 ) print(resp.status_code) print(resp.json()[choices][0][message][content])脚本跑通之后我再回 WorkBuddy 界面重新测试回答正常出现。这里有个很实用的心得把这段脚本保存成check_ollama.py以后不管是换模型、改端口还是升级工具先跑一遍脚本能快速区分“服务坏了”和“客户端配置坏了”。4. 性能调优从“能出字”到 70 tok/s4.1 量化等级与模型选择能出字之后我又开启了新一轮折腾速度太慢。最初 14B 模型在 CPU 上只有每秒 4 个 token就算回到 GPU 也就 20 出头WorkBuddy 里每问一句都要等半天。这里的关键是模型量化等级。GGUF 格式的量化等级直接用体积换质量常见的有 q2_K、q4_K_M、q5_K_M、q8_0。我实际测下来q4_K_M 是性价比最高的档位质量接近原始模型体积和速度都可接受。q2_K 太小了实测回答经常丢信息q8_0 接近全精度但体积和显存占用高速度掉一截。量化等级7B 模型体积加载后显存占用质量实测速度参考q2_K约 2.8GB约 4GB偏差明显快q4_K_M约 4.8GB约 6GB接近原始较快q5_K_M约 5.4GB约 7GB更高中等q8_0约 7.8GB约 10GB接近全精度较慢如果你也是 12GB 显存日常任务用 7B 级别模型是最舒服的。想追求质量换 14B 时上下文长度一定不要拉太高否则又会退回 CPU。4.2 上下文长度与 KV Cache 的取舍速度问题的另一大来源是上下文长度。WorkBuddy 的工作流往往需要多轮对话维持上下文但这个上下文不是免费的。模型权重占显存是固定的但 KV Cache 会随着上下文长度线形增长。以 7B q4_K_M 为例模型权重大约 5GB4K 上下文时 KV Cache 大约需要 0.5 到 1GB如果把上下文拉到 16KKV Cache 会涨到 2GB 以上。显存一满Ollama 又开始被迫卸层给 CPU速度直接跳水。WorkBuddy 里如果提供上下文长度参数记得和服务端保持一致。不要盲目追求大上下文个人工作台场景 8K 通常够用只有处理长文档时才需要临时调高。4.3 关键环境变量Flash Attention 与 KV Cache 量化提速过程中最有用的两个环境变量是OLLAMA_FLASH_ATTENTION和OLLAMA_KV_CACHE_TYPE。Flash Attention 能显著减少显存带宽压力对长上下文帮助很大。KV Cache 量化则是把缓存从全精度压缩到 8-bit进一步降低显存占用和读写压力。Windows 下设置用户环境变量setx OLLAMA_FLASH_ATTENTION 1 setx OLLAMA_KV_CACHE_TYPE q8_0Linux 下还是在 systemd override 里加[Service] EnvironmentOLLAMA_FLASH_ATTENTION1 EnvironmentOLLAMA_KV_CACHE_TYPEq8_0设置完重启 Ollama。这两个参数对速度的影响在我机器上很明显尤其是上下文超过 4K 之后差距能到一倍以上。4.4 最终配置与实测速度最后我把模型换成了 7B q4_K_M上下文设为 8K开 Flash AttentionKV Cache 用 q8_0模型全层加载到 GPU。速度从最初几十秒出不来一个字到最终稳定在 70 tok/s 左右。阶段配置实测速度最初14B q4_K_MCPU 推理约 4 tok/s修复 GPU 后14B q4_K_MGPU 推理约 22 tok/s最终7B q4_K_M全层 GPUFlash Attention8K 上下文约 70 tok/s70 tok/s 是什么概念每秒 70 个 token中文大约对应每分钟 1500 到 2000 字。在 WorkBuddy 里逐字输出时肉眼看着是流畅的日常问答和任务处理完全够用。当然速度跟硬件强相关同一套配置换到不同显卡上结果会差很多。但这个调优思路是通用的先保证模型能完整加载到 GPU再调上下文和缓存参数最后才考虑换模型大小。5. 常见问题速查表与避坑备注5.1 服务侧问题速查我在折腾过程中整理了一份速查表按“服务侧”和“客户端侧”分开遇到问题先对号入座。服务侧最常见的是ollama serve直接段错误。这通常跟 CPU 指令集兼容有关新版本 Ollama 有时会带默认的运行库老 CPU 上不兼容。解决办法是先升级 Ollama 到最新版如果还崩设置OLLAMA_LLM_LIBRARY指向兼容运行库比如强制用不带特殊指令集的版本。端口被占用也比较常见。如果 11434 起不来先查端口netstat -ano | findstr 11434找到占用进程后决定是换端口还是清掉旧进程。修改了OLLAMA_HOST不生效的坑前面说过十有八九是改了环境变量但服务没重启。5.2 客户端侧问题速查WorkBuddy 显示模型列表为空先用/v1/models测一遍接口返回正常就是模型名或地址配置问题。请求超时的话先确认是不是模型在 CPU 上跑是的话要么缩小模型要么降低上下文长度。还有一个很特殊的问题如果你拉了 Gemma 系列默认版本Ollama 的模板里可能带了思考reasoning环节输出会先给一大段内部推理再给正式回答。WorkBuddy 这类工具如果只取message.content而忽略推理字段就会出现“输出很长但看起来像乱码”或者“一直等待正式回复”的现象。解决方法是换用 instruct 版本模型比如带-it后缀的版本或者在自制 Modelfile 里把模板中要求逐步思考的提示删掉。WorkBuddy 缓存目录想换到其他盘先看设置里有没有存储位置选项找不到就关掉程序后做目录联接Windows 用mklink /JLinux 用ln -s把旧位置指到新硬盘。5.3 局域网共享时的 API Key 前置Ollama 本身没有内置的 API Key 机制如果只在本机用不需要任何鉴权配置。但如果你想把它共享给局域网里其他机器的 WorkBuddy 用等于把端口裸奔在网络上这个风险得自己兜住。一个轻量做法是用 nginx 在前面加一层校验。比如配置一个静态 API Key请求带对了才转发给 Ollamaserver { listen 8080; location / { if ($http_x_api_key ! your-secret-key) { return 403; } proxy_pass http://127.0.0.1:11434; proxy_set_header Host $host; } }这样 WorkBuddy 一侧填的地址就变成http://你的IP:8080/v1API Key 填your-secret-key。但我的建议是单机自用时别开0.0.0.0更别做公网端口映射。本地工具的价值就是本地跑暴露出去只会增加不必要的风险。5.4 快速验证脚本留档最后再分享一个实际排查技巧把前面那段 Python 脚本改名成check_ollama.py存好每次动配置后先跑一遍。很多时候你觉得“WorkBuddy 连不上”其实 Ollama 服务根本没加载模型你觉得“模型太慢”其实是上下文参数开太大。脚本能在一分钟内告诉你答案在服务侧还是客户端侧。结尾踩完这一圈坑我最大的体会是本地模型接入这类问题多数时候不是你不会配置而是不知道坑藏在哪一层。WorkBuddy 界面越是“友好”它就越擅长把真实的错误信息藏起来。所以排查的第一步永远是绕开图形界面直接跟服务对话。再一个小经验就是把最终打通的接口地址、模型名、上下文参数、环境变量全部存成一份配置清单每次升级工具或换机器都照着恢复一次能少绕很多弯。希望这份记录对你也有用。 
长河君 · 2026/10/8 10:25:24 · 阅读 1.2k WorkBuddy接入Ollama本地模型：从无输出到70 tok/s的完整踩坑指南
最近给 WorkBuddy 接入 Ollama 本地模型前前后后折腾了两天。一开始以为就是填个地址、选个模型的事结果栽在“无输出”这个坑里爬了半天后面又为速度折腾了一轮最后才摸到一套能稳定跑到 70 tok/s 的配置。如果你也想把 WorkBuddy 这类 AI 工作台接到本地 Ollama 上这份完整踩坑记录应该能帮你省下不少时间。先说清楚这篇记录的定位它适合正在用或打算用 WorkBuddy 搭个人工作台、做科研辅助、整理知识库又不想把对话数据交给云端 API 的人。全文只讲本地部署不涉及任何云端依赖。我会从方案选型开始讲完安装部署、“无输出”的完整排查过程最后聊聊我是怎么把速度从“半天不出字”优化到 70 tok/s 的。1. 方案选型为什么 WorkBuddy 要配 Ollama1.1 先搞清楚 WorkBuddy 在整套流程里的位置WorkBuddy 不是模型运行者它是调度者。你可以把它理解成一个装配车间的工位台WorkBuddy 负责任务编排、技能Skill管理、上下文组织而真正的“发动机”是底层的模型推理服务。我选它的核心原因是它能让我把多个操作串成一个工作流而不是每次都手动复制粘贴 prompt 去调用命令行。这种组合特别适合几类场景。比如科研辅助我需要模型帮忙整理文献摘要、提炼论文结构WorkBuddy 可以把这些步骤固定成技能下次直接触发再比如搭个人工作台把日报生成、代码片段审查这类重复劳动变成半自动流程。甚至有些人用它来做小程序教学应用案例的开发辅助把学生的问题分类、生成示例答案。关键点在于WorkBuddy 这类工具通常默认让你配置云厂商的 API但它真正有意思的地方是支持自定义模型接口。配好之后数据完全不出本机生成的内容再敏感也不会往外送。1.2 本地推理引擎怎么选Ollama、LM Studio 还是 vLLM市面上常见的本地推理方案就那几类Ollama、LM Studio、vLLM/SGLang还有直接裸跑 llama.cpp。我一开始在 LM Studio 和 Ollama 之间犹豫过。LM Studio 的图形界面确实好上手下载模型、调参数都有可视化按钮但对命令行和外部 API 的集成不如 Ollama 利索。vLLM 性能很强但配置门槛高个人场景属于大材小用。方案上手难度模型管理API 兼容适合场景Ollama低命令一行搞定OpenAI 兼容WorkBuddy 单机接入、个人使用LM Studio低图形界面完成也兼容 API想纯 GUI 操作、不想碰命令行vLLM/SGLang高需要自己组织模型OpenAI 兼容高并发、多用户服务裸 llama.cpp中全手动自己封装深度定制、学习底层原理我最后选 Ollama 的理由很直接它对模型的管理足够省心ollama pull就能拉模型ollama list看模型列表而且原生提供 OpenAI 兼容接口WorkBuddy 只需要按 OpenAI 的配置方式填地址就行。对单机工作台来说Ollama 的性能已经足够将来如果真要跑到多用户高并发再迁移到 vLLM 也不迟。1.3 我的硬件与初始选型测试环境是一张 12GB 显存的消费级显卡配 64GB 内存和 8 核 CPU系统是 Windows 和 Ubuntu 双环境都跑过。最初我直接拉了 14B 的 Qwen2.5 量化版想着模型越大质量越高。这个选择后来证明是“无输出”和速度慢的重要诱因之一。14B 模型做 4-bit 量化后体积大约 9GB听起来 12GB 显存条理上够但一旦上下文长度调大KV Cache 会额外吃掉 2GB 以上显存很容易爆。显存一爆Ollama 就退回 CPU 推理速度直接掉到每秒几个 tokenWorkBuddy 那边很容易判定超时表现就是“没有任何输出”。现在回头看这个教训值得单独拎出来讲。2. 环境部署Ollama 安装、存储路径与模型导入2.1 安装与最基础的环境变量Ollama 的安装本身没什么难度。Windows 版本下载安装包双击就行Linux 用官方脚本安装。真正容易踩坑的是环境变量尤其是模型存储路径和监听地址。默认情况下模型会装在系统盘我第二次部署就遇到 C 盘空间告警。Windows 下解决办法是先设置用户环境变量setx OLLAMA_MODELS D:\ollama\models然后完全退出 Ollama 再重新启动。Linux 下不要直接改启动脚本官方推荐用 systemd 的 override 文件sudo systemctl edit ollama.service写入[Service] EnvironmentOLLAMA_MODELS/data/ollama/models EnvironmentOLLAMA_HOST0.0.0.0:11434然后执行sudo systemctl daemon-reload sudo systemctl restart ollama。这里有个很关键的细节如果 WorkBuddy 和 Ollama 在同一台机器上OLLAMA_HOST保持默认的127.0.0.1:11434就行如果 WorkBuddy 装在另一台电脑想访问这台机器的模型服务才需要把监听地址设为0.0.0.0。改完环境变量必须重启服务否则看似改了其实没生效这是“改了半天没用”的头号原因。2.2 模型下载慢手动拉文件再导入下载模型是另一大痛点ollama pull在部分网络环境下能慢到让人怀疑人生。我第一次拉 14B 模型挂着等了一晚上还是断断续续的。解决思路很简单不通过ollama pull而是手动把模型文件下载到本地再通过 Modelfile 导入。GGUF 格式的模型文件在模型社区里到处都有找到对应版本的 4-bit 量化文件放到一个固定目录然后写一个 ModelfileFROM ./qwen2.5-7b-instruct-q4_K_M.gguf TEMPLATE {{- if .System }}|im_start|system {{ .System }}|im_end| {{- end }} |im_start|user {{ .Prompt }}|im_end| |im_start|assistant PARAMETER temperature 0.7 PARAMETER stop |im_end|然后执行ollama create qwen2.5-7b -f Modelfile等它提示成功再用ollama list确认模型已经注册。这里有个细节自定义导入的模型名可以自己定但这个名字就是 WorkBuddy 里要填的模型名两边必须完全一致包括中间的冒号和版本号错一个字符都连不上。需要多说一句Modelfile 里的 TEMPLATE 部分最好直接参考模型官方仓库里的模板不要自己乱写。模板不对会出现一种非常隐蔽的问题——接口返回正常但模型输出前言不搭后语或者输出被截断。2.3 服务自测curl 与 ollama ps把模型导入之后先别急着去 WorkBuddy 里配置先用命令行确认服务本身正常。这一步能省掉后面大量无意义的反复尝试。先看服务是否起来ollama serve正常情况下前台会输出日志。另开一个终端测接口curl http://127.0.0.1:11434/api/tags返回 JSON 里应该能看到你已经导入的模型列表。再看模型是否成功加载到显存ollama ps如果列表为空说明模型还没有加载。真正加载是发请求时才发生所以可以顺手打一次生成请求curl http://127.0.0.1:11434/api/generate -d { model: qwen2.5-7b, prompt: 你好 }我自己第一次测试时就发现日志里有类似 “no suitable GPU” 的提示模型退回 CPU 跑了。这说明显卡驱动或依赖有问题这种问题如果不在服务侧发现进了 WorkBuddy 界面里看就只剩一个“无输出”排查难度会翻好几倍。3. WorkBuddy 接入与“无输出”问题的完整排查3.1 WorkBuddy 配置界面里最容易填错的三个点WorkBuddy 接入自定义模型时核心配置项就三个接口地址、API Key、模型名。其他高级参数先不要动。接口地址最典型的问题是到底带不带/v1。Ollama 同时提供原生接口和 OpenAI 兼容接口WorkBuddy 这类工具走的是 OpenAI 协议地址要填到/v1也就是http://127.0.0.1:11434/v1如果你填成不带/v1的地址很多工具会拼出http://127.0.0.1:11434/chat/completions而 Ollama 原生接口根本没有这个路径结果就是 404 或者连接莫名失败。API Key 这里有个反直觉的坑。Ollama 默认不做鉴权理论上随便填一行字符串都能用。但有些客户端把 API Key 留空时会直接不发 Authorization 头或者干脆认为配置未完成而拒绝请求。最稳妥的做法是填一个任意字符串比如ollama占住这个字段。模型名必须和ollama list输出完全一致。比如你导入的名字是qwen2.5-7b就别在 WorkBuddy 里填成qwen2.5。少一个版本号接口直接返回 404这看起来像“连接失败”实际是模型名不匹配。3.2 “无输出”定位方法论先把 WorkBuddy 踢出局“无输出”是我这次遇到最迷的现象任务能创建请求看起来也发出去了但回答区域一直空白或者转几圈就默默失败。排查这类问题我的经验是先不要把时间花在图形界面上反复重试而是把 WorkBuddy 踢出局直接用命令行模拟请求。这里的核心方法论很简单先证明服务侧能正常输出再怀疑客户端配置。我建议按这个顺序来第一步用浏览器直接访问http://127.0.0.1:11434/v1/models看能否返回模型列表。这一步能确认服务进程活着且 OpenAI 兼容接口正常。第二步在终端用 curl 发一个完整的对话请求curl http://127.0.0.1:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5-7b, messages: [{role: user, content: 你好}] }如果这一步能返回内容说明模型服务完全正常问题出在 WorkBuddy 的配置上。第三步检查系统里有没有装网络调试类、加速类的工具这类工具常驻后台时偶尔会拦截本机回环地址的请求。表现出来的现象很迷惑命令行里 curl 一切正常WorkBuddy 里就是不行。我当时就遇到这种情况排查了半天才发现是常驻工具拦了127.0.0.1的流量。第四步翻 WorkBuddy 的日志。日志里通常会写实际请求的 URL、超时时间、报错原因。这一步比在界面里瞎试高效得多。3.3 我这次遇到的实际故障我在这个阶段一共碰到了三层问题每一层都足以让 WorkBuddy 表现为“无输出”。第一层是模型名填错。我把导入的qwen2.5:14b填成了qwen2.5-14b接口返回 404WorkBuddy 把报错吞掉之后界面就是一片空白。这个修复最没技术含量但因为界面不报错反而卡了我很久。第二层是模型根本没成功加载。ollama ps显示为空日志里提示显存不足模型退回 CPU。14B 模型权重加 KV Cache 把 12GB 显存吃满了Ollama 没法全层 GPU 加载只能用 CPU 跑首字延迟长得超过 WorkBuddy 的超时阈值从用户视角看就是“永远没有第一个字”。这个我到最后才意识到因为在命令行里直接 curl 虽然慢但当时没有耐心等到它出结果。第三层是驱动问题。有一次升级 Ollama 之后GPU 加载直接失效日志里写着只用了 CPU。重启、重装都没用最后更新显卡驱动才恢复。这类问题如果只看界面你永远只能看到“无输出”但服务侧日志会直接告诉你瓶颈在哪。排查“无输出”问题一定记住先看服务侧日志再查客户端配置最后才考虑重装软件。3.4 验证打通用脚本确认输出正常经过上面几轮修复我用一段 Python 脚本确认服务已经能正常返回import requests resp requests.post( http://127.0.0.1:11434/v1/chat/completions, json{ model: qwen2.5-7b, messages: [{role: user, content: 你好}], stream: False }, timeout120 ) print(resp.status_code) print(resp.json()[choices][0][message][content])脚本跑通之后我再回 WorkBuddy 界面重新测试回答正常出现。这里有个很实用的心得把这段脚本保存成check_ollama.py以后不管是换模型、改端口还是升级工具先跑一遍脚本能快速区分“服务坏了”和“客户端配置坏了”。4. 性能调优从“能出字”到 70 tok/s4.1 量化等级与模型选择能出字之后我又开启了新一轮折腾速度太慢。最初 14B 模型在 CPU 上只有每秒 4 个 token就算回到 GPU 也就 20 出头WorkBuddy 里每问一句都要等半天。这里的关键是模型量化等级。GGUF 格式的量化等级直接用体积换质量常见的有 q2_K、q4_K_M、q5_K_M、q8_0。我实际测下来q4_K_M 是性价比最高的档位质量接近原始模型体积和速度都可接受。q2_K 太小了实测回答经常丢信息q8_0 接近全精度但体积和显存占用高速度掉一截。量化等级7B 模型体积加载后显存占用质量实测速度参考q2_K约 2.8GB约 4GB偏差明显快q4_K_M约 4.8GB约 6GB接近原始较快q5_K_M约 5.4GB约 7GB更高中等q8_0约 7.8GB约 10GB接近全精度较慢如果你也是 12GB 显存日常任务用 7B 级别模型是最舒服的。想追求质量换 14B 时上下文长度一定不要拉太高否则又会退回 CPU。4.2 上下文长度与 KV Cache 的取舍速度问题的另一大来源是上下文长度。WorkBuddy 的工作流往往需要多轮对话维持上下文但这个上下文不是免费的。模型权重占显存是固定的但 KV Cache 会随着上下文长度线形增长。以 7B q4_K_M 为例模型权重大约 5GB4K 上下文时 KV Cache 大约需要 0.5 到 1GB如果把上下文拉到 16KKV Cache 会涨到 2GB 以上。显存一满Ollama 又开始被迫卸层给 CPU速度直接跳水。WorkBuddy 里如果提供上下文长度参数记得和服务端保持一致。不要盲目追求大上下文个人工作台场景 8K 通常够用只有处理长文档时才需要临时调高。4.3 关键环境变量Flash Attention 与 KV Cache 量化提速过程中最有用的两个环境变量是OLLAMA_FLASH_ATTENTION和OLLAMA_KV_CACHE_TYPE。Flash Attention 能显著减少显存带宽压力对长上下文帮助很大。KV Cache 量化则是把缓存从全精度压缩到 8-bit进一步降低显存占用和读写压力。Windows 下设置用户环境变量setx OLLAMA_FLASH_ATTENTION 1 setx OLLAMA_KV_CACHE_TYPE q8_0Linux 下还是在 systemd override 里加[Service] EnvironmentOLLAMA_FLASH_ATTENTION1 EnvironmentOLLAMA_KV_CACHE_TYPEq8_0设置完重启 Ollama。这两个参数对速度的影响在我机器上很明显尤其是上下文超过 4K 之后差距能到一倍以上。4.4 最终配置与实测速度最后我把模型换成了 7B q4_K_M上下文设为 8K开 Flash AttentionKV Cache 用 q8_0模型全层加载到 GPU。速度从最初几十秒出不来一个字到最终稳定在 70 tok/s 左右。阶段配置实测速度最初14B q4_K_MCPU 推理约 4 tok/s修复 GPU 后14B q4_K_MGPU 推理约 22 tok/s最终7B q4_K_M全层 GPUFlash Attention8K 上下文约 70 tok/s70 tok/s 是什么概念每秒 70 个 token中文大约对应每分钟 1500 到 2000 字。在 WorkBuddy 里逐字输出时肉眼看着是流畅的日常问答和任务处理完全够用。当然速度跟硬件强相关同一套配置换到不同显卡上结果会差很多。但这个调优思路是通用的先保证模型能完整加载到 GPU再调上下文和缓存参数最后才考虑换模型大小。5. 常见问题速查表与避坑备注5.1 服务侧问题速查我在折腾过程中整理了一份速查表按“服务侧”和“客户端侧”分开遇到问题先对号入座。服务侧最常见的是ollama serve直接段错误。这通常跟 CPU 指令集兼容有关新版本 Ollama 有时会带默认的运行库老 CPU 上不兼容。解决办法是先升级 Ollama 到最新版如果还崩设置OLLAMA_LLM_LIBRARY指向兼容运行库比如强制用不带特殊指令集的版本。端口被占用也比较常见。如果 11434 起不来先查端口netstat -ano | findstr 11434找到占用进程后决定是换端口还是清掉旧进程。修改了OLLAMA_HOST不生效的坑前面说过十有八九是改了环境变量但服务没重启。5.2 客户端侧问题速查WorkBuddy 显示模型列表为空先用/v1/models测一遍接口返回正常就是模型名或地址配置问题。请求超时的话先确认是不是模型在 CPU 上跑是的话要么缩小模型要么降低上下文长度。还有一个很特殊的问题如果你拉了 Gemma 系列默认版本Ollama 的模板里可能带了思考reasoning环节输出会先给一大段内部推理再给正式回答。WorkBuddy 这类工具如果只取message.content而忽略推理字段就会出现“输出很长但看起来像乱码”或者“一直等待正式回复”的现象。解决方法是换用 instruct 版本模型比如带-it后缀的版本或者在自制 Modelfile 里把模板中要求逐步思考的提示删掉。WorkBuddy 缓存目录想换到其他盘先看设置里有没有存储位置选项找不到就关掉程序后做目录联接Windows 用mklink /JLinux 用ln -s把旧位置指到新硬盘。5.3 局域网共享时的 API Key 前置Ollama 本身没有内置的 API Key 机制如果只在本机用不需要任何鉴权配置。但如果你想把它共享给局域网里其他机器的 WorkBuddy 用等于把端口裸奔在网络上这个风险得自己兜住。一个轻量做法是用 nginx 在前面加一层校验。比如配置一个静态 API Key请求带对了才转发给 Ollamaserver { listen 8080; location / { if ($http_x_api_key ! your-secret-key) { return 403; } proxy_pass http://127.0.0.1:11434; proxy_set_header Host $host; } }这样 WorkBuddy 一侧填的地址就变成http://你的IP:8080/v1API Key 填your-secret-key。但我的建议是单机自用时别开0.0.0.0更别做公网端口映射。本地工具的价值就是本地跑暴露出去只会增加不必要的风险。5.4 快速验证脚本留档最后再分享一个实际排查技巧把前面那段 Python 脚本改名成check_ollama.py存好每次动配置后先跑一遍。很多时候你觉得“WorkBuddy 连不上”其实 Ollama 服务根本没加载模型你觉得“模型太慢”其实是上下文参数开太大。脚本能在一分钟内告诉你答案在服务侧还是客户端侧。结尾踩完这一圈坑我最大的体会是本地模型接入这类问题多数时候不是你不会配置而是不知道坑藏在哪一层。WorkBuddy 界面越是“友好”它就越擅长把真实的错误信息藏起来。所以排查的第一步永远是绕开图形界面直接跟服务对话。再一个小经验就是把最终打通的接口地址、模型名、上下文参数、环境变量全部存成一份配置清单每次升级工具或换机器都照着恢复一次能少绕很多弯。希望这份记录对你也有用。