把 WorkBuddy 接到本地 Ollama 模型是我最近折腾下来最有成就感也最崩溃的一件事。说崩溃是因为配置完成、界面一切正常、模型也明明加载成功了结果在对话窗口里发一句话过去转圈半天什么都吐不出来——这种“无输出”的状态碰过的人都懂。说成就感是因为后面一步步排查、一个参数一个参数地调把生成速度从最初的二十多 tok/s 一路拉到 70 tok/s 上下整条链路彻底跑通那种感觉确实不错。这篇文章就把我的完整实操记录整理出来包含 WorkBuddy 与 Ollama 的接入配置、无输出问题的定位思路、性能调优的具体动作还有一份常见问题速查表。如果你正在研究“本地模型 AI 工作台”这套玩法或者正准备把 WorkBuddy 接上 Ollama可以直接照着我这份流程走能少踩好几个坑。1. 接入前的准备先把 WorkBuddy 和 Ollama 的角色想清楚1.1 WorkBuddy 到底需要一个什么样的后端在动手之前先把两者的关系理顺。WorkBuddy 本身不跑模型推理它承担的是“前端对话、上下文管理、任务编排、工具调用”这些活真正出内容的还是后端的大模型。所以接入 Ollama本质上就是在 WorkBuddy 的“模型后端”配置里指向一个本地地址让它把请求发到 Ollama 上跑模型。这里想清楚一点很重要WorkBuddy 对后端只有一个最基本的要求——兼容 OpenAI 风格的接口协议。它不关心你是用云端 API、内网部署的推理服务还是本地跑一个 Ollama只要接口长那个样子就行。Ollama 从很早的版本就提供了兼容 OpenAI 的/v1/chat/completions接口所以两边对接非常顺。我之所以选本地模型主要是两个原因一是数据敏感写代码、整理文档的时候不想把所有内容都丢到云端二是我经常在无外网、弱网环境下干活本地模型不需要等网络往返零延迟起步。如果你也有类似的诉求WorkBuddy Ollama 的组合就是一个非常合理的落地方式。1.2 为什么是 Ollama而不是 LM Studio、vLLM 或云端 API我知道你可能会问本地推理方案那么多为什么偏偏选 Ollama这几类我都试过说下我的直观感受。LM Studio 的图形界面确实友好适合新手拖拽式下载模型、点按钮启动服务它的 API 也兼容 OpenAI。但对我来说它更适合“临时体验”无头模式、批量管理、命令行自动化这些能力不如 Ollama 顺手。vLLM 和 sglang 是面向高吞吐在线服务的推理框架性能上限高但依赖重、部署步骤多本地单机用属于杀鸡用牛刀折腾成本完全划不来。而 Ollama 的优势是轻量、模型管理方便、一条命令拉模型、一条命令起服务同时原生带 OpenAI 兼容 API几乎就是为“个人本地模型服务”这个场景设计的。云端 API 我也长期用优点是省心、模型强但每月的 token 消耗账单、数据外发的问题始终是个坎。接入 Ollama 之后我至少可以把日常琐碎的、不敏感的请求留在本地只把真正复杂困难的任务发给云端——Hybrid 混用既省钱又灵活。1.3 安装阶段的三个常见坑下载慢、存储路径、离线导入先说下载。Ollama 官网的安装包在国内网络环境下经常下到一半就断进度条形同虚设。我的建议是别傻等直接去 GitHub Releases 页面手动下载离线安装包——Windows 下是OllamaSetup.exeLinux 下是.tar.gz或官方安装脚本下载完成后本地执行即可。这种方式比命令行拉取要可控很多至少你能看到真实的下载进度中断了也能断点续传重试。第二个坑是模型存储路径。Ollama 默认会把模型放在~/.ollama/models如果你跟我一样系统盘空间紧张装两个 7B 模型基本就报警了。Linux 下我是这么处理的先建一个独立的模型目录再通过环境变量OLLAMA_MODELS指过去修改后重启 Ollama 服务。Windows 上同理在系统环境变量里新建OLLAMA_MODELS指向你有空间的盘符。还有一个容易被忽略的场景离线环境导入自己的 GGUF 模型。方法是写一个 Modelfile里面写一行FROM /path/to/your-model.gguf然后执行ollama create your-model -f Modelfile。Ollama 会自动把 GGUF 变成可管理的本地模型整个过程不需要联网。这个技巧在有内网机器、没办法直接ollama pull的时候非常实用。2. 接入配置全流程让 WorkBuddy 真正“看见”本地模型2.1 拉起 Ollama 服务并预加载模型Ollama 安装好之后先确认服务在跑。Linux 下如果用的是 systemd 管理服务通常已经常驻如果手动启动就在终端跑ollama serve看到类似Listening on 127.0.0.1:11434的日志就是正常了。这里有个隐藏点默认情况下 Ollama 只监听127.0.0.1也就是只能本机访问。如果你打算从局域网内其他机器连这台机器的 Ollama或者 WorkBuddy 跑在另一台设备上需要设置OLLAMA_HOST0.0.0.0:11434再重启服务。接着拉模型。我建议第一次先用一个小模型打通流程比如qwen2.5:3b验证没问题之后再换主力模型。拉取命令很简单ollama pull qwen2.5:3b拉完之后顺手跑两个命令确认状态ollama list看模型列表ollama ps看当前加载到内存的模型。这里有个经验之谈先手动ollama run qwen2.5:3b预热一次让模型真正加载进去再回 WorkBuddy 里测试。因为模型首次加载会有明显的冷启动延迟如果不预热WorkBuddy 那边第一次请求等了十几秒没反应很容易误判成“无输出”。2.2 WorkBuddy 连接参数到底怎么填WorkBuddy 里接入模型后端的配置项基本是固定的几个字段。Base URL 填http://127.0.0.1:11434/v1注意一定带/v1后缀。模型名要填ollama list里显示出来的完整名字比如qwen2.5:3b注意 tag 不能漏qwen2.5和qwen2.5:3b在 Ollama 里是两个东西。API Key 这一栏就比较有意思了——Ollama 默认不校验鉴权理论上填什么都能过。不过在真实使用中API Key 我建议还是填一个固定值。原因有两个一是有些工具在 Key 为空的时候会直接拒绝保存配置二是如果你后续在 Ollama 前面加了一层 Nginx 反向代理做鉴权这个 Key 就会真正用上。提前把习惯养好后面迁移不折腾。还有一个细节要注意很多工具默认会拼https://如果你 Base URL 填的是http://127.0.0.1:11434/v1但工具强制走 HTTPS就会连不上。遇到这种情况先把工具里的协议设置改成 HTTP确认能通之后再考虑要不要用 HTTPS 代理。2.3 用 curl 验证链路别傻等界面反馈这步是我这次最大的经验教训不要在配置完 WorkBuddy 之后直接去界面里点发送然后盯着转圈发呆。正确的做法是先用 curl 把接口打一遍确认后端没问题再去界面上做集成测试。我建议按顺序执行下面三条命令# 查看 Ollama 本地模型列表 curl http://127.0.0.1:11434/v1/models # 直接调用聊天接口不走流式 curl http://127.0.0.1:11434/v1/chat/completions \ -H Content-Type: application/json \ -d {model:qwen2.5:3b,messages:[{role:user,content:你好}],stream:false} # 走流式接口观察输出分片 curl http://127.0.0.1:11434/v1/chat/completions \ -H Content-Type: application/json \ -d {model:qwen2.5:3b,messages:[{role:user,content:你好}],stream:true}第一条返回模型列表说明服务活着第二条返回完整的 JSON 响应里面有choices字段和生成的内容说明普通调用正常第三条会看到一段一段的流式输出这模拟了 WorkBuddy 实际使用时的场景。三条都通过你再去 WorkBuddy 界面里测问题范围就已经被锁死在客户端配置了。2.4 顺手解决“模型爱思考”的问题现在不少模型默认会输出推理过程也就是在正式回答之前先来一段“思考”内容像reasoning或者thinking标签里那串文字。在 WorkBuddy 这种工具场景里思考过程偶尔看看还行每次都带着就很影响使用体验输出也显得啰嗦。关闭思路有三种。第一种最简单在 WorkBuddy 的系统提示词里明确要求“直接给出最终答案不要输出任何思考过程或分析步骤”大部分模型都会遵守。第二种是给模型做一个定制 Modelfile把模板里的思考标签去掉重新创建模型。第三种适用于个别支持开关的模型比如 Qwen3 系列的 API 参数里可以传think: false关闭思考模式。具体用哪种取决于你的模型。如果你只是拿 WorkBuddy 做日常问答和代码辅助我推荐先试第一种零成本效果立竿见影如果发现某些模型不听话再考虑用 Modelfile 做定制。3. “无输出”问题深度复盘沉默背后的几种真凶3.1 先分清请求根本没出去还是响应流断了“无输出”看起来是一个现象实际可以拆成好几类不分类就开始瞎排查是最浪费时间的。我自己遇到过三种情况。第一种是点发送之后秒报错提示连接失败、超时之类——这是典型的请求没出去问题在网络层或服务端。第二种是界面看起来在正常转圈转了很久然后提示超时——这说明请求可能已经发出去了但服务端没在预期时间内返回问题可能在模型加载、上下文过大或代理拦截。第三种最迷惑人界面显示有响应了也有内容结构但正文是空的——这是链路通了但响应格式解析出了问题。我的建议是从前往后查先用 curl 确认后端正常再看 WorkBuddy 侧的请求有没有真的发出最后排查网络代理和返回格式。把这个顺序定下来排查效率能高一大截。3.2 网络层排查端口、监听地址、系统代理这三座大山网络层是最容易出问题的地方。先看端口确认 11434 真的在监听。Linux 下用ss -tlnp | grep 11434Windows 下用netstat -ano | findstr 11434。端口被占用的情况在 Windows 上尤其多我之前装过某些开发工具会抢 11434 端口导致 Ollama 服务压根起不来但界面还傻傻以为它在跑。再看监听地址。如果你用 Docker 跑 Ollama或者把 OLLAMA_HOST 设成了0.0.0.0那么从本机访问127.0.0.1:11434和从局域网访问机器IP:11434行为是不一样的。WorkBuddy 里填的 Base URL 必须和 Ollama 实际监听的地址对得上。第三个坑是系统代理。这个很隐蔽WorkBuddy 有时候会读取系统的 HTTP 代理设置把本该发给 localhost 的请求也交给代理服务器去转发代理服务器处理不了本地地址结果就是要么超时要么返回一堆看不懂的错误。遇到这种情况在系统代理设置里把localhost、127.0.0.1加入绕过列表或者直接在无代理模式下测试一次基本就能定位。3.3 跨域与鉴权本地服务也有拦路虎如果你的 WorkBuddy 是桌面客户端一般没有跨域问题但如果用的是 Web 版本浏览器同源策略就是一道硬关卡——前端页面从某个域名发起请求到127.0.0.1:11434跨域了请求会被浏览器拦截。Ollama 专门提供了OLLAMA_ORIGINS环境变量来放行跨域来源。我当时的处理方式是设置一个范围合理的来源列表而不是直接设成*。因为设成*会让所有网页都有权限调用你本机的 Ollama 服务虽然有本地模型不跑敏感数据但如果别人在浏览器里打开恶意页面就可能借你的算力跑东西不值得。鉴权是另一件事。Ollama 默认不鉴权意味着局域网内任何能访问到你 IP 的设备都能调用它。如果 Ollama 只在本机用还好一旦暴露到局域网强烈建议在前面加一层 Nginx 反向代理把鉴权和访问控制做掉。3.4 看日志找真相服务端不会骗你界面上的报错往往含糊不清但日志是诚实的。如果你用的是 systemd 管理的 Ollama查看日志的命令是journalctl -u ollama -f如果是手动ollama serve启动的日志就直接打在终端里。有一次我排查了两个小时无输出问题最后在日志里看到一行关键输出——模型加载到了 80% 的时候显存不足被系统自动终止了但 WorkBuddy 那边只显示“连接中断”完全没暴露根本原因。所以记住无输出的时候第一步不是改 WorkBuddy 配置而是去看 Ollama 的日志确认请求到底到没到、模型到底加载成功了没。日志里如果频繁出现和“segment fault”相关的错误那就是 Ollama 进程本身崩了。这种情况多半是版本和系统环境不匹配或者驱动有冲突。我的处理方式是直接把 Ollama 升级到最新版再不行就彻底卸载重装用官方离线安装包重来一遍。这类稳定性问题靠改配置是解决不了的。4. 从 20 多 tok/s 到 70 tok/s性能调优的完整记录4.1 影响生成速度的硬指标拆解接入通了之后下一个问题就是速度。我一开始测速7B 模型稳定在二十多 tok/s这速度用来写代码对话勉强能忍但多轮对话一长等待感非常明显。后面一步步调到了 70 tok/s 上下整个体验完全不一样。先拆一下影响本地推理速度的几个硬指标。模型量化级别是最直观的Q4_K_M这类 4bit 量化版本体积小、速度快Q8_08bit 量化精度更高但速度明显下降。参数量不用多说3B、7B、14B 的推理耗时差着量级。然后是 GPU 参与度模型有多少层被 offload 到显卡上跑决定了大头开销落在 GPU 还是 CPU。还有上下文长度也就是 KV cache 占用的显存上下文越长每一轮生成的开销越大。最后是并发和预热状态同一条模型第一次请求和跑热之后的第二次请求速度能差出一倍以上。4.2 调优动作与实测数据对比下面是我实际做过的调整按投入产出比排序。第一步是确认 GPU offload 生效。Ollama 默认会尝试把模型加载到 GPU但如果你驱动没装好或者显存不够它会在无提示的情况下退回 CPU 模式。确认的方法很直接跑一段长对话的同时观察显卡占用。如果 GPU 利用率一直在高位说明生效了如果 GPU 闲着一动不动那就是没 offload 上。第二步是设置模型常驻。默认情况下 Ollama 在模型空闲一段时间后会自动卸载下次请求又得冷加载。我设置了OLLAMA_KEEP_ALIVE24h让常用模型一直留在显存和内存里。这一步对连续会话体验的提升非常明显。第三步是收敛并行加载。WorkBuddy 这种工具通常是单请求串行的不需要为它开高并发。我主动把OLLAMA_NUM_PARALLEL设为 1、OLLAMA_MAX_LOADED_MODELS设为 1避免 Ollama 因为同时管理多个模型的 KV cache 而增加额外开销。实测数据大概是这样的配置状态生成速度备注初始默认配置未确认 GPU模型冷启动20~30 tok/s第一次请求尤其慢GPU offload 确认生效模型预热完成45~55 tok/s最直观的提升固定上下文长度 单模型常驻 关闭并行65~70 tok/s连续会话下稳定需要说明的是我测试用的是 7B 量级的量化模型加单张主流显卡硬件不同数据会有浮动但调优的方向和顺序是通用的。4.3 上下文长度、并发与内存的取舍上下文长度是性能调优里容易被忽略的一环。WorkBuddy 这类工具有个特征每次请求都会把会话历史打包发给模型对话轮数一多上下文很快就逼近上限。默认的 2048 上下文在简单测试时没问题但多轮对话之后就开始丢信息或者变慢。我当时把num_ctx上调到了 4096效果立竿见影。但这里有个反面教训上下文不是越大越好。我把参数一度拉到 8192显存直接爆了Ollama 开始被迫把一部分 KV cache 换到内存速度反而比之前更慢。后来我把上下文锁定在 4096观察显存占用稳定在安全线以内之后就没再动过。设置方式是在 Modelfile 里写PARAMETER num_ctx 4096重建模型后生效。如果你是临时测试也可以在 API 请求参数里直接传num_ctx。我的建议是先 4096 起步根据你的实际对话长度和显存余量再决定要不要往上调。4.4 本地向量模型与后续扩展速度和稳定性都搞定之后我开始琢磨 WorkBuddy 里那些依赖向量检索的功能。很多 AI 工作台都会用到 Embedding 来做知识库、语义搜索、本地记忆这类需求同样可以用 Ollama 承接。Ollama 上有很多开箱即用的向量模型比如nomic-embed-text、bge-m3。拉取命令和普通模型一样ollama pull bge-m3向量模型的特点是占用量小、推理快把它常驻在 Ollama 里基本上不占多少显存但能给 WorkBuddy 的知识库检索提供全套本地化能力。这样一来对话模型、向量模型、推理服务就全部落在本地了整条链路完全不依赖外网。我后来还做了一层扩展用 FastAPI 写了个很薄的转发服务把 WorkBuddy 的请求先经过我这一层再做模型路由和 token 统计。这样做的核心好处是以后想从 Ollama 切到别的后端或者做多模型混合调度都不用改 WorkBuddy 的配置只改我这层转发就行了。你可以理解为在 WorkBuddy 和 Ollama 之间加了一个“插座”以后换什么电器都只拔插头。5. 常见问题速查表与保留级建议5.1 高频问题速查表这一趟走下来我把最常遇到的问题和对应解法整理成了一张表方便你直接对照排查。症状可能原因处理方式请求后秒报连接失败Ollama 未启动或端口不是 11434确认服务在跑检查ollama ps转圈很久后超时系统代理拦截了 localhost 请求代理设置里绕过 127.0.0.1或临时关代理测试有响应结构但内容为空返回格式解析异常或流式接口不兼容先用 curl 非流式接口验证返回 JSON模型加载到一半崩了显存不足或上下文设置过大换更小的量化版本降低num_ctx第一次请求特别慢模型冷启动磁盘 IO 慢用ollama run先预热设置OLLAMA_KEEP_ALIVE生成速度始终很慢GPU offload 未生效查看显卡占用更新驱动确认 OLLAMA 版本局域网内其他设备访问不了OLLAMA_HOST 默认绑定了 127.0.0.1设置OLLAMA_HOST0.0.0.0:11434并重启ollama serve 段错误崩溃版本或系统环境不兼容升级到最新版或彻底重装提示 401 鉴权失败前面加了 Nginx 校验Key 不匹配检查代理层要求的 Key和 WorkBuddy 填写一致5.2 实操心得与几个“早该早知道”的事最后分享几个踩过坑之后沉淀下来的心得。第一任何 AI 工具对接后端第一动作永远是 curl 打一遍接口拿到正常的 JSON 再去界面上做下一步。这个习惯帮我省掉了大量“界面报错但不知道错在哪”的排查时间。WorkBuddy 的配置界面再怎么友好也不可能替你把后端的问题说出来。第二模型名必须精确。qwen2.5:7b和qwen2.5:7b-instruct是两个模型占用的内存不一样行为也不一样填错一个字母结果可能完全离谱。一切以ollama list的输出为准。第三改配置之后要重启。环境变量、Modelfile 参数这些东西改了之后不重启 Ollama 服务根本不生效。我自己就有一次改了OLLAMA_KEEP_ALIVE没重启盯着测速数据看了半天还以为是调优方法不对。第四先小模型验证链路再上大模型调优。用qwen2.5:3b或者更小的模型先把 WorkBuddy、Ollama、网络层全部打通确认没有问题再切到 7B、14B 去做性能优化。不然链路问题和大模型性能问题搅在一起你根本分不清是哪个环节在拖后腿。最后说一点个人体会。WorkBuddy 这类工具接本地模型真正的门槛从来不是界面上那几个输入框而是整条链路里那些“你以为通了其实没通”的节点。我后来养成的那个 curl 自测习惯本质上就是在帮自己排除掉“我以为”的部分一步步逼近事实。这套排查思路不只是对 Ollama 有用接任何本地模型、任何自建服务逻辑都是相通的。