如果你和我一样手头有一块 12GB 显存的显卡又恰好受不了每次问 AI 一个问题都要把对话记录发给云端那大概率动过本地模型的念头。上周我把 WorkBuddy 接上 Ollama前后折腾了两天半中间一度以为这组合根本跑不通——界面上发消息永远没回复日志干干净净没有报错也没有超时提示。最后排查完速度从 0 tok/s 一路拉到稳定的 70 tok/s。这篇记录写给所有正在跟 WorkBuddy、Ollama、本地模型这些关键词搏斗的人完整的排错思路、每个坑背后的原因以及可以直接照抄的配置。先说结论WorkBuddy 接入 Ollama 本身一点都不复杂复杂的是看起来全对但就是不工作的中间层——协议、路径、代理、环境变量、甚至一个标点符号都可能是元凶。我会把整个排查链拆开讲尽量让零基础的人也能跟着走一遍。1. 先交代清楚为什么 WorkBuddy 值得配一个本地模型1.1 我的使用场景WorkBuddy 这个工具定位是AI 工作台把多模型、技能Skill、工作流都组织在一个桌面客户端里。你可以把它理解为带 Agent 编排能力的 AI 助手可以在里面搭对话流、写技能、跑批量任务底层可以自由切换云端模型或者本地模型。比起 Cursor、CodeBuddy 这类偏 IDE 集成的工具WorkBuddy 更侧重内容处理和任务编排写文案、整理材料、跑科研辅助流程都好用。问题在于我日常处理的材料里有一部分不适合发到云端——不是见不得人而是量大、重复、涉密边界模糊尤其科研和项目文档来回上传下载太被动。所以从一开始我就计划全部用本地模型兜底云端模型只做对照测试。1.2 我的硬件和模型选型先看环境后面所有排查都建立在它上面系统Windows 11 原生不是 WSL216 核 CPU32GB 内存显卡NVIDIA RTX 3060 12GB驱动版本 566.36Ollama 版本0.5.4主力模型qwen2.5:7b-instruct-q4_K_M约 4.9GB验证用模型llama3.1:8b、nomic-embed-text向量模型为什么选 Qwen2.5 7B 而不是更大的模型12GB 显存能跑 14B 量化版但速度和内存都不宽裕7B 的 Q4_K_M 加载后只占 4.9GB 显存能留出空间给上下文窗口和工作台本身的开销。如果跑 14B上下文稍微拉长就会爆显存然后回退到 CPU 推理速度直接从 70 掉到 10 出头根本不划算。2. Ollama 装好之前这几个坑已经在排队了Ollama 部署本身不算难但如果你关注过ollama下载太慢ollama离线安装包ollama安装到其他盘这些高频问题就知道光是装好它就已经能劝退一波人了。我按顺序踩了一遍逐个说。2.1 安装包下载慢离线包方案最省心官网下载页在大陆网络下经常让人怀疑人生几十 MB 的安装包能下出 30KB/s。解决办法其实很老套换可用的镜像源地址或者让人帮忙拉一份离线安装包。Ollama 官方在 GitHub Releases 会同步发布 Windows 安装包.exe和 macOS 的压缩包Linux 则是安装脚本。如果你在一台能正常访问外网的机器上或者有同事可以帮忙直接下载 Windows 安装包后用 U 盘或者内网传过去比任何加速手段都稳。下载完成后它是个图形安装程序默认装到C:\Users\用户名\AppData\Local\Programs\Ollama。对大多数用户来说装完不需要手动加 PATH安装程序自己会处理。2.2 模型存储路径用环境变量搬家默认情况下Ollama 模型会存到C:\Users\用户名\.ollama\models。你的 C 盘本来就不宽裕的话这就是个隐患——一个 7B 模型 Q4 量化后 4.9GB多拉两个模型再加一个 bge-m3 向量模型约 1.2GB十几个 GB 就没了。正确做法是装完 Ollama 之后、拉任何模型之前先把模型目录搬走。我先手动把C:\Users\用户名\.ollama整个目录复制到D:\ollama然后在系统环境变量里添加OLLAMA_MODELSD:\ollama\models提示设置完环境变量必须完全退出 Ollama 再重启包括右下角托盘图标也要右键退出。我一开始只关了命令行窗口托盘里 Ollama 还活着新路径根本没生效白复制了一次目录。验证方法很简单重启后运行命令ollama list如果模型列表里能看到旧模型说明路径切换成功如果为空再检查一遍环境变量拼写。注意是OLLAMA_MODELS不是OLLAMA_MODEL少个 S 它不报错只是悄悄当没看见。2.3 ollama serve 段错误先查版本再查驱动ollama serve 段错误这个热搜词看着吓人遇到过的人才知道多凭空。我在一台 4060 笔记本上部署时只要一运行ollama serve终端直接打印 core dump 信息进程秒退。排查思路从这几个方向走升级 Ollama 版本。0.4.x 早期版本在不同显卡驱动组合下有已知崩溃问题升级到 0.5.x 后大部分直接解决。更新 NVIDIA 驱动。Ollama 依赖 CUDA 运行时驱动太老会导致加载 CUDA 库失败表现形式往往不是友好报错而是段错误。检查显存占用。如果同时开着其他占用显存的应用Ollama 初始化失败也可能直接崩。我解决的方式是先备份~/.ollama目录卸载旧版装最新版重启系统再ollama serve。如果是 Linux 环境下崩还可以试试OLLAMA_DEBUG1 ollama serve开详细日志错误原因通常会直接印出来。2.4 拉模型的网络问题重试加到怀疑人生模型拉取失败是另一个高频问题。ollama pull qwen2.5:7b走到一半断掉再继续时进度条归零重试几次都这样。这不是脚本 bug是下载连接不稳定。解决办法是老实的等一个相对空闲的时段再拉或者多次重试每次它都会从断点续传最终能拉完。也可以设置一个较长的超时时间必要的话分批次中断再续总比反复清零强。注意ollama pull支持断点续传只要你不清掉.ollama里的临时分片文件中断后重新跑它不会从头开始。看到进度条从 0 走但文件在涨也别慌耐心等就行。3. WorkBuddy 配置项拆解明明每一项都能对上为什么还是无输出Ollama 跑起来、模型拉好了接下来是把 WorkBuddy 和它接上头。这一步理论上最简单实际上却是无输出问题的高发区。WorkBuddy 的模型设置通常会让你填这些字段模型服务类型OpenAI 兼容接口Base URLhttp://127.0.0.1:11434/v1API Key随便填比如ollama模型名称qwen2.5:7b看着没毛病对吧我填完发消息界面转了几秒然后就没有然后了。没有报错、没有文字回复、没有残留日志。这就是我这次折腾的核心战场。3.1 Base URL 的尾斜杠是个老陷阱很多客户端会把 Base URL 原样拼到请求路径后面。如果你填的是http://127.0.0.1:11434/v1/它可能拼出http://127.0.0.1:11434/v1/chat/completions这就是对的但如果填http://127.0.0.1:11434/v1且客户端自己又拼了一个/chat/completions一般也能正确处理。问题反而出在客户端拼路径时直接用了/api/chat而不是/v1/chat/completions。WorkBuddy 这类工具支持 Ollama 原生接口也可能只走 OpenAI 兼容接口当你把模型类型选成OpenAI它默认打/v1/chat/completions。Ollama 自己实现了这个端点路径是兼容的所以理论上没问题。但如果你在配置里看到模型后端类型有 Ollama 原生 和 OpenAI 兼容 两个选项优先选 Ollama 原生它会走/api/chat参数兼容性更好。3.2 模型名必须一字不差WorkBuddy 发请求时会把模型名原样传给 OllamaOllama 对模型名匹配是精确匹配。我一开始偷懒在 WorkBuddy 里填qwen2.5心想一样的模型拉什么 tag 都行。结果 Ollama 返回model qwen2.5 not foundWorkBuddy 抓到这种错误有时显示得很隐晦甚至直接吞掉不显示表现就是无输出。记住一条铁律WorkBuddy 里填的模型名必须和ollama list输出的第一列完全一致带:tag就带:tag一个字符都不能省。ollama list NAME ID SIZE MODIFIED qwen2.5:7b-instruct-q4_K_M 1234abcd5678 4.9 GB 2 hours ago nomic-embed-text:latest 5678efgh9012 274 MB 1 hour ago3.3 超时时间本地模型生成慢时的隐形杀手这个坑特别隐蔽。云端模型响应快客户端默认超时往往是 60 秒。但本地模型第一次生成前要加载权重、分配显存7B 模型冷启动在我这台上要 8-15 秒之后生成几百字可能要 10-30 秒。看起来时间够但如果 WorkBuddy 内部还有一个不明显的首包超时、空闲超时或者你的请求带上了流式输出而它等的是完整响应就会出现一种诡异的现象等十几秒后 UI 恢复但没有文字仿佛模型什么都没说。如果你能在 WorkBuddy 设置里找到超时时间或者网络请求高级选项直接调到 300 秒别客气。如果找不到后面章节会讲怎么绕过这个问题。3.4 上下文长度和 system prompt 被悄悄截断另一个常见误配是上下文长度。WorkBuddy 默认可能只给 4096 token你填的 system prompt 加上多轮对话超过这个长度请求直接失败或者被静默截断。Ollama 侧也有自己的上下文设置默认num_ctx是 2048如果 WorkBuddy 传了 8192 但 Ollama 还是按 2048 处理长文本生成会胡言乱语甚至返回空。所以配置阶段最好就统一WorkBuddy 上下文长度设 8192Ollama 模型参数num_ctx也设 8192。后面的提速章节我会展开讲为什么这个参数要小心。4. 无输出问题排查全过程从界面到协议栈一层一层挖如果你和我一样配置看着全对模型名也对超时也调了还是没有输出那就要按下面的顺序排查。这条路我走了整整一个晚上省下来的是你接下来的两小时。4.1 第一层Ollama 服务本体是否健康最基础但最容易被忽略。先确认 Ollama 进程真的在跑curl http://127.0.0.1:11434/api/tags如果返回一个 JSON里面有models数组说明服务正常。如果连接被拒绝说明 Ollama 没起来如果返回空对象或报错检查端口是否被占用。顺便看一眼环境变量OLLAMA_HOST默认应该是127.0.0.1:11434。有些人为了让局域网内其他设备也能访问把它设成了0.0.0.0:11434这没问题但如果你把 WorkBuddy 的 Base URL 还填localhost而 WorkBuddy 对localhost的解析顺序有问题也可能连不上。4.2 第二层绕过 WorkBuddy直接用 curl 验证协议这一步是判断是 WorkBuddy 的问题还是模型/服务的问题的分水岭。模拟 WorkBuddy 的请求直接拿 curl 打 Ollamacurl http://127.0.0.1:11434/v1/chat/completions -H Content-Type: application/json -d {\model\: \qwen2.5:7b\, \messages\: [{\role\: \user\, \content\: \你好\}]}注意 Windows 的 PowerShell 里反斜杠转义很烦建议复制到记事本改成一行再执行。如果 curl 能在几秒内返回完整 JSON里面有content字段说明 Ollama 和模型没有任何问题问题一定出在 WorkBuddy 到 Ollama 这一段的某个环节。如果 curl 也没反应或者报错就用ollama run qwen2.5:7b直接命令行对话一次能聊通就说明模型文件没损坏。命令行也卡住的话回到模型文件级别——重新拉一次。4.3 第三层本地回环被代理悄悄劫持我这台机器上装了多个代理工具连 curl 都能正常访问 OllamaWorkBuddy 却始终无输出。后来我打开系统代理设置仔细看发现代理工具把127.0.0.1和localhost也纳入了转发范围。WorkBuddy 发出的请求到了本地端口被代理工具截走又不知道往哪转发于是一直挂着直到超时UI 上就是无输出。解决方法是把本机回环地址加入代理工具的绕过列表不同工具的设置位置不一样一般叫直连地址绕过规则或No Proxy。至少要把这几条加进去127.0.0.1 localhost ::1 *.local如果你是通过环境变量设的代理还要注意 Windows 对NO_PROXY的支持有限最省事的办法是用工具自身的图形界面设置。提示检查这个问题的命令是netstat -ano | findstr 11434看本地连接数。正常的请求只有一两条如果出现大量来自随机端口的ESTABLISHED连接且明显有条链路连到代理的监听端口上基本就是被劫持了。4.4 第四层请求参数和 WorkBuddy 兼容性把返回错误打印出来如果以上都没问题那大概率是 WorkBuddy 发出的请求参数 Ollama 不认。最常见的是 WorkBuddy 发了stream: true而 Ollama 的 OpenAI 兼容端点对某些字段处理不够宽松或者 WorkBuddy 请求里带max_tokensOllama 的 OpenAI 端点把它解释为max_tokens时因为上下文限制被静默拒绝。这时候最有效的办法是看日志。Ollama 在 Windows 上会保留服务日志路径大概在C:\Users\用户名\AppData\Local\Ollama\server.log。打开它搜索请求对应的行通常会看到类似[WARN] 400 Bad Request: invalid parameter: max_tokens看到这个你就能反过来在 WorkBuddy 里把生成参数调小或取消。我当时看到的是403后面跟着一串模型列表——WorkBuddy 每次发消息前都会先拉模型列表而此时 Ollama 返回 403 是因为请求头带了 API Key但 Ollama 的OLLAMA_API_KEY没有设置。诡异的是 Ollama 对/api/tags忽略错误 Key但对/v1/chat/completions会拒掉。处理方案要么设置OLLAMA_API_KEY环境变量并让 WorkBuddy 填同一个值要么在 WorkBuddy 里把 API Key 留空如果它允许。4.5 根因复盘最终让我从无输出到能正常说话的不是某一个惊天动地的原因而是三个小问题叠在一起系统代理劫持了 localhost 流量代理工具把请求转发后Ollama 收到的是来自非本机的连接而当时OLLAMA_HOST恰好被前任同事改成过0.0.0.0混合作用下权限校验逻辑走了弯路WorkBuddy 请求头带的 API Key 触发了 Ollama 的 Key 校验三个问题任何一个单独存在都可能被容忍但叠在一起就是无输出。这也解释了为什么我更新配置、重启服务都没有效果——因为每次只修了一个。5. 从能出声到 70 tok/s性能调优的完整清单能对话之后新的焦虑来了速度太慢。初期只有 20 多 tok/s体感像在跟树懒聊天。调到 70 tok/s 的过程里我做了下面几件事。5.1 量化等级7B 模型别直接跑 FP16先明确一个概念Ollama 拉取模型时的标签决定了模型的量化精度。qwen2.5:7b默认可能是 Q4_K_M但也有7b-fp16或7b-f32这种全精度版本。全精度 7B 需要约 16GB 内存12GB 显存根本塞不下只能部分跑 CPU速度直接腰斩。我对比过同型号 Q4_K_M 和 Q8_0 的差距量化等级文件大小实测速度显存占用生成质量Q4_K_M4.9GB70 tok/s约 6GB够用Q8_08.2GB52 tok/s约 9GB略好FP1615GB12 tok/s超限理论上最好对日常对话和工作流来说Q4_K_M 的降质几乎不可感知速度却快一大截。如果你不是特别较真生成质量就锁死 Q4_K_M。5.2 num_ctx、并行度和 keep_alive三个参数控制显存活力Ollama 的上下文窗口num_ctx直接影响显存占用。num_ctx8192比2048多占不少显存因为 KV cache 是按上下文长度预分配的。WorkBuddy 如果每次请求都带上更大的上下文参数Ollama 会按请求里的值重新计算 KV cache 大小显存不够就部分回退 CPU。我在 Ollama 服务级做了两个环境变量设置OLLAMA_NUM_PARALLEL4 OLLAMA_MAX_LOADED_MODELS1OLLAMA_NUM_PARALLEL控制同一模型最多并行处理几个请求。并行度越高KV cache 预留越多显存占用越大。WorkBuddy 这类客户端大部分是做交互对话不是高并发4在我这里体验最好如果显存吃紧就调回2。OLLAMA_MAX_LOADED_MODELS1强制 Ollama 只保留一个模型常驻显存。如果你插了向量模型和多模型工作流这个参数能避免显存被多个模型切来切去导致抖动。还要记得在模型参数里为 WorkBuddy 固定keep_alive-1让模型保持常驻避免每次会话都重新加载重新加载一次 7B 模型要 5-10 秒。Ollama 的全局默认值是 5 分钟自动卸载对交互工具太短了。5.3 GPU 层数让权重尽可能留在显存里Ollama 默认会尽可能把层放到 GPU但如果显存不够它会自动把一部分层放到 CPU。你可以通过 API 参数num_gpu强制控制。一般不需要手动改除非你发现显存占用很高但速度还是很慢那说明它把部分层放到了 CPU。在 WorkBuddy 里如果能看到模型参数把num_gpu设成-1代表全部层都放 GPU。如果卡在显存不足减少上下文长度到 4096比强行抠层数更有效——上下文占的显存不释放GPU 层数设置就是空话。5.4 第一次请求慢是正常的warm-up 有必要你可能会发现重启 Ollama 后第一次发消息等了 10 秒第二次开始就飞快。这不是配置问题是模型冷启动加载。如果你想让界面体验一直顺滑可以在 WorkBuddy 之外开一个命令窗口提前ollama run qwen2.5:7b聊一句再退出让模型留在显存里。如果设置了keep_alive-1模型会一直驻留后面任何客户端请求都会秒回。5.5 实测速度数据怎么判断是否正常我用一个简单的计时命令测性能curl http://127.0.0.1:11434/api/generate -d {\model\: \qwen2.5:7b\, \prompt\: \写一篇300字短文\, \stream\: false} -o response.json从返回 JSON 里看eval_count和eval_durationeval_count * 1000 / eval_duration就是 tok/s。我这套环境下Qwen2.5 7B Q4_K_M 的稳定值在 68-75 tok/s 之间取整算 70。如果低于这个数字检查顺序是进程列表里有没有别的吃显存程序、系统电量/电源模式是否开启了省电、Ollama 是不是跑在 WSL2 里WSL2 的显存访问和原生 Windows 有差距速度下降 10%-20%。6. 让这套组合更顺手向量模型、OCR 和运维细节速度起来之后我开始琢磨怎么让 WorkBuddy 这个组合不只停留在聊天层面。接下来这几块是我觉得最值回票价的扩展。6.1 接 nomic-embed-textWorkBuddy 的本地记忆和 RAGWorkBuddy 如果支持技能Skill和知识库功能就需要本地向量模型做语义检索。Ollama 里拉一个 nomic-embed-text 或 bge-m3ollama pull nomic-embed-text:latest这类模型很小几百 MB速度很快。然后在 WorkBuddy 里新增一个 Embedding 模型后端Base URL 填同一个http://127.0.0.1:11434模型名填nomic-embed-text。这样你给自己建的知识库文档就能在本地完成向量化不需要把文档内容传到任何云端服务。向量模型的选择上中文场景我更喜欢 bge-m3 的效果但 nomic-embed-text 胜在速度快、显存占用小。如果你跑在 3060 上还挂着 7B 模型毫不犹豫选 nomic除非你要做大量复杂语义统一才能体现 bge 的优势。6.2 EasyOCR 本地识别图片里的字也能进对话框WorkBuddy 对接文本没问题但如果你给它发一张带文字的截图它能看懂图里内容吗如果它本身不带视觉能力你可以在本机挂一个 EasyOCR 服务把图片先转文字再塞进 WorkBuddy 的上下文。EasyOCR 支持中文识别模型文件本地加载不需要联网。我自己写的简化流程是这样的用 Python 起一个 Flask 接口接收图片路径调用 EasyOCR 识别返回文字内容在 WorkBuddy 技能里加一个预处理步骤把图片先转成文字再进入模型对话这个组合解决了一个很实际的痛点很多本地文档是扫描件或者截图OCR 转一遍之后WorkBuddy Ollama 才能继续处理和总结。如果你想做成更完整的流水线还可以把 OCR 输出和向量库结合起来识别完直接入库。EasyOCR 使用本地模型的关键是第一次运行时会自动下载识别模型如果网络不好就手动下载模型压缩包放到~/.EasyOCR/model目录。这个目录你同样可以用符号链接迁移到其他盘避免 C 盘膨胀。6.3 用 nginx 给 Ollama 做统一网关如果你不只是自己用还想让同一台机器上的多个客户端WorkBuddy、Cherry Studio、IDEA 插件等都走同样的配置或者想给模型访问加一层控制用 nginx 反代 Ollama 是很稳的方案。我的 nginx 配置精简版server { listen 11435; location /v1/ { proxy_pass http://127.0.0.1:11434/v1/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_read_timeout 300s; proxy_connect_timeout 30s; } location /api/ { proxy_pass http://127.0.0.1:11434/api/; proxy_set_header Host $host; proxy_read_timeout 300s; } }这样所有客户端统一连http://127.0.0.1:11435将来想换模型服务、加统一超时、做模型名称别名都只需要改网关这一层不用每台机器每个工具都改一遍。如果你有局域网内共享需求把server的监听地址改成内网 IP其他机器就能通过内网访问本地模型服务。注意暴露到局域网前建议在网关层加上访问控制而不是直接依赖 Ollama 自己的校验。毕竟本地模型服务的本意是给自己和团队用不是给公网随便蹭。6.4 日常维护缓存目录、模型清理、升级策略最后说点运维层面的经验。WorkBuddy 本身的缓存目录在 Windows 上默认走系统用户目录如果长期使用会话缓存、技能数据也会慢慢涨。WorkBuddy 的配置里一般有缓存位置相关设置如果你用的版本没有提供界面选项最省事的迁移方案是把原缓存目录用mklink /J做目录联接指向 D 盘。命令是mklink /J C:\Users\用户名\AppData\WorkBuddy\Cache D:\WorkBuddyCache注意先退出 WorkBuddy把原目录真正移动到 D 盘再建联接否则会报错。模型管理上ollama list能看所有本地模型ollama rm 模型名删除不用的。我一般保持两个 7B 模型 一个向量模型 一个 OCR 模型总共不到 10GB换模型比云端 API 切换还快。升级策略上Ollama 的升级频率不低升级前先看server.log里有没有历史报错再决定是否备份.ollama目录。模型文件通常不需要重拉但如果你从极老的版本跳上来建议重新拉一次目标模型因为量化格式和 KV cache 布局可能变了。最后这套组合现在是我主力配置把 Ollama 和 WorkBuddy 接通的这两天半收获比预想大。70 tok/s 的速度在本地 7B 模型里算是顺手级别再叠上向量检索和 OCR 预处理WorkBuddy 对我来说已经从一个需要折腾的实验品变成了日常工具。整个过程真正卡住我的永远是那些小但叠加致命的细节而不是模型本身有多大技术含量。如果你现在还在无输出的状态里挣扎我建议按这个顺序做自查先确认 Ollama 服务健康并curl通 API再检查本地回环有没有被代理劫持然后核对模型名称字符完全一致最后才去看 WorkBuddy 的请求参数。大概率是其中一环的叠加效应。最后再分享一个小技巧把 Ollama 的OLLAMA_DEBUG1打开跑一天日志会告诉你很多隐藏的行为。比如某个请求到底传了什么参数、超时发生在哪一层、Ollama 为什么拒了你的请求。你一旦看过一次 Oscillating 在日志里留下的线索就再也不会对着一个无输出的界面干瞪眼了。