1. 为什么非要折腾 WorkBuddy 接 Ollama 本地模型先说清楚我为什么要在 WorkBuddy 里接入本地模型而不是直接用云端 API。我用 WorkBuddy 搭个人工作台主要是想让它帮我跑一些日常的文档处理、代码片段生成、文献信息整理这类活儿。一开始接的是云端模型用起来确实省事但越用越觉得不对劲——费用一累积就是实打实的账单而且有些内部资料和实验数据我不想让它们离开本地机器。于是我决定把 Ollama 拉起来在本地跑模型让 WorkBuddy 走本地推理链路。这个想法听起来很顺理成章实际操作却是我上半年踩得最狠的一段坑。WorkBuddy 本身不是为本地模型设计的默认期望连接高性能云端 API接上本地模型之后我先是遇到服务完全无响应接着是看似连上了但输出空白最后还有反复出现的 500 错误。整个过程从完全跑不通到最终稳定在 70 tok/s 左右我花了不少时间排查也试了不少组合方案。这篇记录适合两类人看一类是想把 WorkBuddy 或者类似工作台工具接到 Ollama 上、但还没跑通的人另一类是本地模型已经能跑但速度慢得怀疑人生想优化吞吐的人。我尽量把每个为什么这么做和踩到的是什么坑都写清楚而不是只丢给你一套配置。我用的环境是 Windows 11 加一张中端 NVIDIA 显卡Ollama 装在非系统盘WorkBuddy 通过 OpenAI 兼容接口连到本机 11434 端口。如果你用的是 Linux 或 macOS大部分排查思路同样适用只是环境变量和系统服务配置的地方不太一样。2. 安装与模型准备90% 的无输出问题其实出在这一步很多人一遇到 WorkBuddy 没输出第一反应是去改 WorkBuddy 的配置或者去调模型参数。我自己也是这么干的折腾了半天发现根子全在环境准备阶段。所以我把这部分单独拎出来顺序对了后面能省很多事。2.1 Ollama 安装、模型下载慢与存储位置迁移Ollama 安装本身不难官网下载安装包、双击下一步就行。但有两个问题非常普遍一是安装包和模型下载速度不稳定二是默认模型存储路径在 C 盘稍大一点的模型就能把系统盘塞满。下载慢的问题我试过几个思路最终可用的是两条找国内镜像源来拉模型文件或者直接在 Ollama 官网的发布页面找对应版本的安装包再用支持断点续传的下载工具去拉。模型文件的下载一般走ollama pull但默认源在国内环境不稳定我后来在环境变量里配置了镜像源地址速度才稳定下来。如果你不愿意改全局配置也可以手动把模型文件下载好放到对应的目录下再用ollama pull触发校验这种方式对离线内网环境尤其好使。定期备份模型文件这个习惯也值得养成我重装过一次系统没有备份的话几个模型就全没了。存储路径迁移是另一个必做的操作。方法很简单把OLLAMA_MODELS环境变量指向新目录然后重启 Ollama 服务。比如我希望模型放在 D 盘的D:\ollama\models就在系统环境变量里新增OLLAMA_MODELSD:\ollama\models改完之后务必把原来的模型文件整体拷贝到新目录否则已经拉取过的模型全部要重新下载。启动 Ollama 后可以用ollama list确认模型是否被正确识别。我对这个操作的体会是早改早省心别等 C 盘飘红再动手。2.2 模型选型参数规模、量化等级和任务场景的匹配Ollama 不是装完就完事选什么模型直接决定了 WorkBuddy 里的体验。这里有一个普遍误解以为模型越大效果越好。实际上本地部署要同时考虑显存、推理速度和任务匹配度。我最初顺手拉了个 70B 级别的模型结果是加载都费劲WorkBuddy 请求一次要等几十秒才返回首字体验极差后来才换成了 7B 到 14B 这个区间。在 Ollama 里模型标签的格式通常是模型名:版本-量化等级。量化等级就是压缩权重的方式常见的包括 Q4_K_M、Q6_K、Q8_0 等。简单理解量化等级越低模型体积越小、显存占用越少、速度越快但精度会有轻微损失量化等级越高越接近原始精度但资源消耗也越大。对 WorkBuddy 这种以代码生成、文本整理、信息抽取为主的场景我实测 Q4_K_M 和 Q5 级别完全够用没有明显质量下降。如果你跑的是需要严谨推理或专业问答的任务可以试试 Q8_0代价就是慢一些。模型选型上我还得到一个经验别迷信最新版本号。我在一个讨论帖里看到有人报qwen3.5:2b遇到 500 错误其实那个名字本身就是问题——版本号和实际可用模型不匹配时Ollama 会尝试拉取一个不存在的模型或者报错。选模型前先去 Ollama 的模型库页面确认准确的名字和标签不要凭记忆输入。对于 WorkBuddy 这类偏干活的工具我目前用 Qwen 系列和 Codestral 替代方案比较多2B 模型跑起来确实飞快但复杂指令的遵循能力弱一些适合简单任务7B~14B 的模型速度与效果比较均衡是我的主力选择。2.3 先跑通命令行再连接 WorkBuddy这是我最想强调的一条经验无论如何先脱离 WorkBuddy直接在命令行把模型跑通。原因很简单只有先把问题限定在模型这一层后面排查 WorkBuddy 的配置时才不会两头猜。命令行测试分两步。第一步是确认服务在跑ollama list如果能看到你拉取的模型列表说明服务和模型都正常。第二步是发一个真实的对话请求curl http://localhost:11434/api/chat -d { model: qwen3:7b, messages: [{role: user, content: 用一句话介绍你自己}], stream: false }这里把模型名换成你实际拉取的名字。如果 curl 能正常返回 JSON 内容就说明 Ollama 的推理接口是通的。如果这一步就失败那问题大概率在 Ollama 本身和 WorkBuddy 没有关系。我见过不少人在 WorkBuddy 里反复调试最后发现是 Ollama 服务根本就没启动或者 11434 端口被占用这种低级错误最浪费时间。还有一个容易被忽略的点WorkBuddy 连接 Ollama 时它会发起的请求格式和命令行不太一样特别是参数名和请求体结构。但只要你把服务层先验证通了后面剩下的问题就都能定位到 WorkBuddy 侧。3. WorkBuddy 接入配置与无输出问题的完整排查链路这一章是整篇文章的核心我把从WorkBuddy 连上 Ollama 但完全无输出到跑通的完整排查链路写下来。这部分不是简单的配置罗列而是我当时一步一步排查的真实过程。3.1 接入配置第一步WorkBuddy 里应该填什么WorkBuddy 的模型接入界面一般需要你填三样东西接口地址、模型名称、API Key。API Key 这一栏在本地环境下可以随便填比如ollama或者local因为 Ollama 默认不校验 Key但要保证这个字段不为空否则一些客户端会把请求直接拦截掉。接口地址要填的是 Ollama 的兼容端点不是 Ollama 原生 API 地址。WorkBuddy 用的是 OpenAI 兼容协议而 Ollama 在 11434 端口上同时暴露了两种接口风格其中/v1/路径是兼容 OpenAI 格式的。很多人在这一步填了http://localhost:11434结果怎么连都不对就是因为少了/v1。正确写法是http://localhost:11434/v1模型名称必须和ollama list里显示的完全一致包括冒号后面的版本和量化后缀。比如你在命令行看到的是qwen3:7b那在 WorkBuddy 里填qwen3就可能出问题因为有些实现会尝试精确匹配。我的建议是直接填完整标签。如果你是在远程服务器上跑的 OllamaWorkBuddy 在另一台机器上那接口地址就不能填 localhost 了要填服务器的局域网 IP 或域名同时在 Ollama 侧需要把监听地址从默认的 127.0.0.1 改成 0.0.0.0。3.2 现象一能连上但第一次回答永远空白我最初接好配置之后WorkBuddy 里能看到模型列表发送消息也没有报错但助手回复区域一直是空的等多久都没有内容。这种静默失败比报错更难搞因为你不知道请求到底有没有到 Ollama更不知道模型到底有没有在生成。排查第一步确认请求是否到达了 Ollama。方法是观察 Ollama 的日志。Windows 下我一般这么看右键任务栏 Ollama 图标退出然后在命令行手动启动日志会直接打印在当前窗口ollama serve保持这个窗口开着再回 WorkBuddy 里发一条消息观察窗口里有没有新的日志输出。如果有请求进来但响应体为空或直接结束那就说明 WorkBuddy 发出的请求格式 Ollama 能接收但生成环节出问题了。接下来要排查的是模型加载问题。本地模型不像云端那样常驻Ollama 会在收到请求时加载模型如果模型过大、显存不足加载会失败。但失败时通常会有日志而空白响应往往是因为模型加载成功后生成速度太慢或者模型本身一直在推理WorkBuddy 默认的超时时间又很短导致前端等不到结果就放弃了。这里有一个很实用的验证方法在 WorkBuddy 发送消息的同时打开一个终端用nvidia-smi观察显存占用。如果显存占用飙升然后又回落到低位说明模型加载后被快速卸载了多半是keep_alive时间设置太短。Ollama 默认模型加载后会保持一段时间如果你在 WorkBuddy 里频繁切换模型或者显存压力过大会出现反复加载卸载的情况。可以在请求参数里显式指定keep_alive或者直接加大这个值。最后一个可能原因是 WorkBuddy 对响应内容的过滤。有的工作台工具会对模型输出做后处理比如期待特定格式的 JSON而本地小模型返回的内容不符合预期就被悄悄丢弃了。我当时是在 WorkBuddy 的日志目录里找到了被丢弃的响应看到模型其实生成了内容只是被判断为无效格式。解决办法是换用指令遵循能力更强的模型或者在 WorkBuddy 里关闭严格输出校验。3.3 现象二直接报 500 Internal Server Error 与 llama-server process比空白响应更明确的是报错500 internal server error: llama-server process。这个报错我在实践里见过几次也帮别人排查过。它直接指向 Ollama 内部的 llama-server 进程出问题了通常是三个原因之一。第一种是模型文件损坏或版本不完整。这种情况一般出现在下载中断、磁盘空间不足或者模型文件被手动移动之后。解决起来最干脆删掉这个模型重新拉取。虽然要重新下载但总比反复排查半天好。ollama rm 模型名 ollama pull 模型名第二种是显存不足。Ollama 默认会将尽可能多的层放到 GPU 上加载如果你的显卡显存不够llama-server 进程启动就会失败或者跑起来之后被系统杀掉。有个非常关键的技巧把部分层留在 CPU 上跑通过参数控制 GPU 层数。如果图形界面里不知道参数名可以用环境变量或者在请求体里传参让 Ollama 只把部分层加载到 GPU剩下的用 CPU 推理。这样虽然速度慢一些但至少不会一加载就崩。第三种是模型与当前 Ollama 版本的兼容性问题。我遇到过新版 Ollama 对某些旧模型格式支持不完善的情况升级 Ollama 之后问题自动消失。你也可以反过来用旧版 Ollama 跑特定模型。这类兼容性问题的特征很典型同一模型有时能加载有时报错而且报错信息里没有明确的资源不足提示。3.4 现象三模型一直不加载请求频繁超时还有一类问题WorkBuddy 发请求过去Ollama 没有日志或者日志显示等待模型加载然后 WorkBuddy 那边就已经超时了。核心原因往往是 WorkBuddy 的连接超时设置太短而本地模型的冷启动时间又太长。模型越大、机器越差冷启动越明显。WorkBuddy 默认连接超时可能只有几十秒如果你用的是一个 14B 的量化模型冷启动加上首 token 生成时间很可能就超时了。解决方式有两种一种是在 Ollama 层面让模型保持常驻把keep_alive设为-1或者很大的值这样模型加载一次后不卸载后续请求延迟会大幅降低。另一种是调整 WorkBuddy 的超时参数把连接超时和读取超时都调大。我当时在 WorkBuddy 的配置文件里把 timeout 从默认的几十秒调到 300 秒这之后再也没出现过模型正在加载然后请求就断了的情况。保证模型常驻的好处是WorkBuddy 里的交互体验会流畅很多感觉像是在用云端模型。4. 从十几 tok/s 到 70 tok/s我是怎么把性能一分一分榨出来的连接问题解决之后新的问题来了速度。最初我的本地模型在 WorkBuddy 里跑起来速度惨不忍睹尤其第一次生成内容几乎是一个字一个字往外蹦完整生成一段话要等半天。后来我做了几轮优化把稳定吞吐提升到了 70 tok/s 左右这一章把优化的过程和原理说清楚。4.1 先搞清楚什么在影响 tok/stok/s 是 tokens per second也就是每秒生成的 token 数量。这是衡量本地模型生成速度最直观的指标。影响它的因素很多但最核心的是三个模型大小、显存带宽和上下文长度。模型大小方面同样是 7B 模型不同量化等级的体积差异很大加载到显存后占用的带宽也不同。显存带宽是关键中的关键——本地模型推理的速度很大程度取决于显存带宽而不是单纯看 GPU 的算力。我实测同一台机器跑 Q4 量化的 7B 模型速度明显高于跑 Q8 量化的 7B 模型因为后者读取权重的数据量更大。上下文长度经常被忽略。num_ctx参数决定模型能看到的上下文窗口大小它直接影响 KV cache 的占用和计算量。默认值往往只有 2048 或 4096如果你给 WorkBuddy 传了一大段资料进去实际上下文可能已经超出这个范围模型处理起来就会非常吃力。但需要注意盲目调大num_ctx并不会让速度变快反而会因为显存占用增加而降低速度。你需要找到适合自己任务的平衡点。4.2 我的优化清单按优先级排序我把实际起作用的优化点按优先级列出来你可以照着设置第一件事检查显存是否真的用满了。用nvidia-smi看 GPU 利用率。如果在推理期间 GPU 利用率只有百分之几十说明模型没有完全加载到显存有一部分在 CPU 上跑这会是速度的瓶颈。解决办法是让 Ollama 加载更多层到 GPU。显存够的情况下可以用环境变量OLLAMA_GPU_LAYERS把层数调高甚至可以全部加载到 GPU。这是我从十几 tok/s 提升到几十 tok/s 最关键的一步。第二件事尽量使用低量化等级。在不影响输出质量的前提下Q4_K_M 通常是最佳性价比选择。Q8 虽然质量更好但速度差距在 7B 模型上能差出一倍。如果你的任务对精度要求没那么高别犹豫换 Q4。第三件事控制并发和常驻模型数量。Ollama 支持并发请求但 WorkBuddy 同时发多个请求时你的显卡可能会被多个模型实例瓜分反而导致单个请求变慢。设置环境变量OLLAMA_NUM_PARALLEL1强制同一时间只处理一个请求同时让同一个模型常驻减少反复加载的开销稳定性和速度都会改善。4.3 具体操作步骤与实测数据对比下面是我实际操作的一整套配置直接给出来供参考。在 Ollama 的服务环境变量里我设置了OLLAMA_HOST127.0.0.1 OLLAMA_KEEP_ALIVE1h OLLAMA_NUM_PARALLEL1 OLLAMA_MAX_LOADED_MODELS1然后把模型以 Q4_K_M 量化重新拉取用ollama run进入对话后用/set parameter num_ctx 8192设置了上下文长度再用/set parameter num_gpu 999让模型尽量全部落在 GPU 上。配置完成后我在同一段长文本生成任务下做了前后对比配置状态首次响应耗时稳定吞吐初始默认配置 Q8 量化约 8 秒约 12 tok/s调整 GPU 层数 Q4 量化约 3 秒约 35 tok/s完整优化 常驻模型约 1 秒约 70 tok/s这个对比是在我自己的显卡上跑出来的你的机器如果显存更大或者带宽更高数字可能完全不同但趋势是一致的优先把模型完整放进显存选对量化等级减少模型调度开销这三个动作对速度的提升立竿见影。还有一个冷门但有效的小技巧禁用不使用的服务比如图形界面显示进程或后台自动更新检查把它们对 CPU 和内存的占用让给推理。我关闭了一些动画效果和后台程序后虽然显存不变但 CPU 调度更清爽模型的 prompt 处理阶段速度也提升了一些。5. OLLAMA_HOST 与远程调用的安全配置WorkBuddy 和 Ollama 如果不在同一台机器上你会遇到另一层问题跨机访问。这一章讲远程调用时的配置和注意事项同时也说说我自己踩过的权限相关的坑。5.1 修改监听地址和防火墙策略Ollama 默认只监听127.0.0.1也就是说只有本机程序能访问它。如果你在服务器上部署 Ollama然后在自己的电脑上用 WorkBuddy 连接就必须把监听地址改成0.0.0.0。设置环境变量OLLAMA_HOST0.0.0.0:11434改完之后重启 Ollama。但这里有一个很多人忽略的问题即使监听地址改好了防火墙可能仍然在拦截外部连接。Windows 上第一次启动 Ollama 时会弹防火墙授权窗口你要是点了取消后面连接就会一直失败。检查防火墙入站规则里有没有允许 11434 端口的规则没有的话手动加一条。我当时遇到的问题是局域网内另一台机器 telnet 11434 端口是通的但 WorkBuddy 就是连不上最后发现是 WorkBuddy 那边默认走了某种不兼容的协议需要把 API 类型明确改成兼容 OpenAI 的类型而不是自动识别。5.2 统一入口方式用网关把多个模型服务收拢到一个地址如果你不想让 WorkBuddy 直接暴露给 Ollama或者你同时跑了多个本地模型服务推荐用一个统一入口把这些服务收拢起来WorkBuddy 只需要配置一个固定地址。在我的实践里我用的是一个轻量级的 API 网关技术方案把 Ollama 的/v1接口挂到统一入口下同时配上简单的密钥校验这样 WorkBuddy 侧即使换了底层模型服务配置也不用动。另外需要提醒的是链路安全问题。局域网内虽然相对封闭但对 Ollama 这种一启动就开放 API 的服务不建议直接暴露到公网。如果确实需要从外网访问请务必加上校验机制。Ollama 本身对安全校验的支持比较有限我在实际部署中是让网关来承担这层身份验证的这样既能统一管理也能避免直接把没有防护的服务敞在公网上。虽然我没有做更深层的内网穿透配置但如果你有这类需求思路是一样的Ollama 只监听内网由网关对外提供服务。5.3 一个容易被忽视的点跨机访问时的模型加载与并发冲突远程模式下服务器上可能同时有多个客户端在请求 Ollama。如果不设限并发请求会触发多个模型实例显存瞬间被瓜分。我实践中最稳妥的方案是在服务器上把并发数限制为 1同时让模型常驻这样虽然每个请求都要排队但至少每个请求都能稳定跑完。对 WorkBuddy 这种单人使用的工具来说并发需求其实很弱稳定比同时处理多任务重要得多。6. 跑通之后WorkBuddy 与本地模型实际搭配的体感与扩展连接稳定、速度达标之后我花了一段时间真实使用这里聊聊个人体感和后续扩展的方向。6.1 本地模型在 WorkBuddy 里到底能做什么WorkBuddy 的核心优势是能把多个工具串成工作流比如读取本地文件、整理代码、生成报告。接上本地模型后这些能力依然能用但模型的能力上限决定了体验上限。我用 7B 级别的本地模型日常处理文本摘要、代码片段生成、格式转换这类任务完全没问题输出速度快响应也稳定。但如果涉及复杂多轮推理、需要强逻辑理解的任务本地模型和云端模型的差距还是很明显的。另外我强烈建议为 WorkBuddy 配置专门的 skill 或提示词模板。本地模型对长指令的遵循能力弱于云端模型如果你把任务拆得更细、描述得更具体输出质量会明显提升。我在实践里把一个大任务拆成几个小步骤每个步骤单独配置提示词效果比一次性丢给模型好得多。6.2 扩展方向本地向量模型、OCR 工具与 Dify 类平台的组合等基础链路稳定后你可以考虑进一步扩展。比如接入本地向量模型为知识库检索提供语义能力让 WorkBuddy 能看懂你本地文档之间的关系。再比如配合 OCR 工具处理扫描版 PDF把图片中的文字提取出来再交给模型处理。这些都是本地化工作流里非常实用的补充。另一个值得尝试的组合是把 Ollama 接入 Dify 这类平台。我最近在尝试用 Dify 编排更复杂的应用然后把 Ollama 作为模型源。两者打通之后你能在可视化界面里配置提示词、知识库和工具调用比直接在 WorkBuddy 里改配置灵活得多。打通方式不复杂Ollama 提供兼容接口而 Dify 也支持自定义模型接入两者通过 HTTP 请求对接即可。不过接入后建议先用简单的对话测试验证连通性再逐步增加节点。6.3 一个关于本地模型 工作台的真实体会说实话本地模型的工作流并不是为了取代云端模型而是给你多一个选择。当你处理敏感信息、离线环境、高频小任务时本地模型的价值非常明显——没有费用焦虑没有网络依赖隐私数据不离开你的机器。代价就是你需要花时间调优并且接受一定程度的模型能力上限。如果让我给一个最实用的建议先把 Ollama 单机跑通用 curl 验证推理再连接 WorkBuddy然后逐步优化速度和并发。每改一个配置记录一次前后效果。这个习惯帮我省掉了大量重复排查的时间也是我今天能稳定跑在 70 tok/s 的根本原因。