1. 项目整体思路与“无输出”问题的根源分析先交代下背景。我手里有一套基于 WorkBuddy 搭的智能工作台日常要让它做文档归纳、知识库问答、邮件草拟这些活。起初图省事直接接了云端模型接口用了一段时间发现两个问题一是数据全部要过公网一些内部材料放上去心里不踏实二是接口调用量一大账单蹭蹭涨。所以决定把模型层整个搬到本地选型就是 Ollama。Ollama 是目前本地部署 AI 模型最省事的方案之一。它把模型下载、推理服务、API 暴露都打包好了一条ollama run就能拉起一个模型。WorkBuddy 这类工作台本身不自带模型推理能力它是通过标准 OpenAI 兼容接口去调用后端模型。也就是说架构非常简单WorkBuddy前端工作台 → 本地 Ollama 服务127.0.0.1:11434 → 本地模型推理这条链路看起来短真正跑通时坑却不少。我遇到的最大一个现象就是 WorkBuddy 里发起对话后输入框一直转圈界面没有任何结果输出后台日志也没有明显报错。很多人第一反应是“模型没加载好”于是反复重启 Ollama、重下模型结果问题照旧。实际排查下来“无输出”的反面不是“模型挂了”而是“请求根本没送到模型手里”或者“返回格式不认”。Ollama 本身作为服务器启动后默认监听 11434 端口提供/api/generate和/api/chat两个原生接口同时也暴露一个 OpenAI 兼容接口/v1/chat/completions。WorkBuddy 默认按 OpenAI 协议去对接所以如果配置里把地址指向了 Ollama 原生的/api/generate两边握手就会失败。我那次“无输出”的具体原因是配置的模型名带了多余的空格而且大小写不一致。WorkBuddy 发请求时拿这个名字去 Ollama 找模型找不到Ollama 直接返回 404。但由于 WorkBuddy 对错误响应处理不友好界面不提示红色报错只表现为“转圈 → 无输出”。这种软失败极具迷惑性。所以整个排查思路要反过来先验证 Ollama 本身是否正常再验证 API 接口是否可用最后检查 WorkBuddy 的配置映射是否正确。哪一层断了问题就出在哪一层。下面我按完整流程记录。1.1 WorkBuddy 到底是做什么的适合谁WorkBuddy 本质上是一个 AI 工作台/助手框架核心是把“对话、工具调用、知识库检索、工作流编排”整合到一个界面里。它和 Cursor、CodeBuddy 这类编程助手不同WorkBuddy 更侧重通用任务处理比如接入各种本地模型、挂技能Skill、管理缓存和项目文件适合需要把 AI 能力嵌入日常办公或研究流程的人。如果你只想玩一个开箱即用的聊天机器人那 Ollama 自带的对话界面就够了用不着 WorkBuddy。但如果你想做“多个模型切换 自定义提示词技能 本地知识库 项目级管理”的组合WorkBuddy 的架构会省很多事。换句话说Ollama 是发动机WorkBuddy 是驾驶舱两者是协作关系。1.2 为什么要用本地模型不只是省钱本地部署最大的价值不是省那点 API 费用而是三个隐性收益数据隔离文档、问答记录全部留在本机不经过第三方服务器适合处理合同、论文初稿、内部资料这类敏感内容。离线可用断网环境下依然能工作。我有一次在外地出差酒店网络很不稳定云端接口频繁超时本地模型完全不受影响。定制自由本地模型可以按需换量化版本、改推理参数甚至微调。用云端接口时这些能力大多被锁死只能传参无法动底层。当然代价也很直接显存要够、CPU 要能打、硬盘要腾出几十 GB。所以选型和配置一环扣一环接下来的实操部分会逐个拆开讲。2. 环境准备Ollama 安装、模型下载与存储路径改造先说一个很多人没意识到的点Ollama 安装本身不难但它默认把模型文件放到 C 盘用户目录下而且下载源在国外国内网络环境下经常出现“进度条一动不动”或者“下到一半断掉”。我第一台机器装完 Ollama.ollama目录直接吃掉了 40 多 GBC 盘瞬间告急。所以在正式接入 WorkBuddy 之前有三个动作必须做改存储路径、解决下载慢/离线安装、验证安装完整性。2.1 安装 Ollama 的正确姿势Windows 下直接去官网下安装包双击安装即可没有特殊技巧。但需要注意安装目录和模型目录是两回事。安装程序默认会把可执行文件放到%LOCALAPPDATA%\Programs\Ollama模型默认在C:\Users\你的用户名\.ollama\models。建议在安装完成后先设置环境变量再拉模型OLLAMA_MODELS D:\ollama_models OLLAMA_HOST 0.0.0.0这里的OLLAMA_MODELS就是把模型存储挪出 C 盘OLLAMA_HOST设置成0.0.0.0是允许局域网内其他机器访问。如果是单机使用127.0.0.1就够了没必要开局域网。我见过有人图方便把 OLLAMA_HOST 设成0.0.0.0结果公司内网里同事都能往他的 Ollama 里灌请求还有可能被扫描工具盯上打满带宽。注意修改环境变量后必须完全退出 Ollama 再重新启动光靠重启托盘图标不一定生效。在 Windows 上可以通过任务管理器把 Ollama 相关进程全部结束再重新运行。Linux 下安装更简单curl -fsSL https://ollama.com/install.sh | sh但同样的默认路径是~/.ollama通过export OLLAMA_MODELS/data/ollama改到数据盘。持久化要写进/etc/systemd/system/ollama.service里的Environment字段或者写到~/.config/systemd/user下否则重启失效。2.2 模型下载慢与离线安装的解决方案模型下载慢是频发的坑。Ollama 默认从ollama.com的 CDN 拉文件国内直连有时候只有几十 KB/s。我一次性拉过一个大模型挂了一整夜还没下完后来总结了三种应对方式换镜像源比如配置OLLAMA_HOST之外还可以通过设置HTTPS_PROXY环境变量把下载流量代理出去。但如果代理本身不稳定反而更糟。用下载工具手动拉先通过 Ollama 的 registry API 查到模型对应的磁盘文件名这类信息在社区里都有记录然后用支持断点续传的下载工具下到本地最后把文件放回models/blobs目录再执行ollama pull让它做校验。操作门槛略高但对大模型很管用。直接导入本地文件如果手头有 GGUF 格式的模型文件可以绕过下载直接写一个Modelfile内容就一行FROM ./model.gguf然后执行ollama create mymodel -f Modelfile这样彻底不需要联网。我后来很多测试用的模型都是用 GGUF 文件本地创建的省去了一等再等的下载时间。实操心得如果 Ollama 下载中途报“segment fault”之类的错误多半不是 Ollama 坏了而是下载不完整导致文件校验失败。把models目录里对应模型缓存清掉重新拉一次即可。检查模型目录用ollama list确认模型状态用ollama show。2.3 验证 Ollama 服务是否正常装好后先跑一遍自检流程ollama serve在另一个终端窗口执行ollama list能看到模型列表说明服务起来。再测一次真实推理curl http://127.0.0.1:11434/api/generate -d {model:qwen2.5:7b,prompt:你好,stream:false}如果返回 JSON 且里面有response字段说明推理链路正常。这个自检极其重要它能帮你把“Ollama 问题”和“WorkBuddy 问题”切割开。3. 接入 WorkBuddy 的配置细节与第一轮排查为什么“无输出”Ollama 这层跑通后剩下的核心工作就是让 WorkBuddy 正确连上它。这里的配置项不多但每个都踩过坑。3.1 WorkBuddy 里模型配置的四个关键参数以 WorkBuddy 当前的界面逻辑为例新增一个本地模型需要填写四个东西参数含义我最终填写的内容模型供应商决定走什么 API 协议OpenAI 兼容OllamaBase URL模型服务的地址http://127.0.0.1:11434/v1API Key认证密钥Ollama 默认不校验ollama或任意非空字符串模型名称必须和ollama list显示名字完全一致qwen2.5:7b第一个坑就在 Base URL。很多人直接填http://127.0.0.1:11434理论上 Ollama 也能处理但 WorkBuddy 发的是/chat/completions路径如果不带/v1请求会被顶层路由拦下来轻则返回 404重则被解析成错误响应表现就是转圈无输出。第二个坑在模型名称。ollama list里显示的短 ID 有时候不带版本标签比如qwen2.5但如果你的本地实际拉取的模型是qwen2.5:7bWorkBuddy 配置里必须写qwen2.5:7b不能只写qwen2.5。这个冒号版本号极其容易漏。第三个坑是 API Key。Ollama 默认不开启鉴权只要请求能到达 11434 端口谁能调都行。有一些代理层比如 Nginx 反向代理会在上游配置强制校验 API KeyWorkBuddy 里那栏如果填了空字符串个别代理配置会直接掐断请求。因此我都是填一个固定字符串以防中间环节校验。3.2 第一轮“无输出”的排查方法如果你的 WorkBuddy 已经出现了“无输出”别急着重装按下面顺序查查 WebUI 里是否能看到日志面板。WorkBuddy 的请求日志一般会显示“发送中”还是“失败”。如果看到401或404说明请求已经发出去了问题在模型名或路径。在终端手动发一条与 WorkBuddy 相同的请求curl http://127.0.0.1:11434/v1/chat/completions -H Content-Type: application/json -d {\model\:\qwen2.5:7b\,\messages\:[{\role\:\user\,\content\:\你好\}]}如果这条返回正常说明 Ollama 接口没问题问题在 WorkBuddy 的配置映射。如果这条也报错就围绕报错信息定位。检查防火墙。Windows 系统偶尔会拦截 Ollama 对外的 localhost 回环虽然少见但我也遇过一次。命令行里 curl 能通WorkBuddy 里超时最后在 Windows 防火墙里给 Ollama 可执行文件加了入站允许规则才解决。排查思路很简单换一个客户端比如直接用 Python 请求库测一遍如果只有 WorkBuddy 不通就怀疑是 UI 层拦截或本地代理设置。查看 Ollama 的日志。Windows 上 Ollama 日志在%TEMP%\ollama.logLinux 上用journalctl -u ollama。如果日志里根本没有来自 WorkBuddy 的请求记录说明流量没到 Ollama如果有请求但报model not found那模型名铁定错了。我在第一轮排查中最后的结论就是模型名写错。但这里要提醒一点WorkBuddy 有些版本在界面里会默认给模型名加后缀或者自动补/导致明明下拉框选对了请求发出去时模型名被改动。这种极端情况下建议直接在调试接口里抓请求内容看看实际发出的 model 字段长什么样。3.3 解决“无输出”后不要急着庆祝先测流式响应WorkBuddy 默认会开启流式输出stream也就是打字机效果。如果 Ollama 版本和 WorkBuddy 对 SSEServer-Sent Events数据流的解析不兼容也会表现为“有返回但界面一直不渲染”本质上还是“无输出”。验证方法很简单curl http://127.0.0.1:11434/v1/chat/completions -H Content-Type: application/json -d {\model\:\qwen2.5:7b\,\messages\:[{\role\:\user\,\content\:\你好\}],\stream\:true}看看返回是不是一系列data:开头的数据块。如果正常再在 WorkBuddy 配置里确认是否允许流式响应。有些版本在“高级设置”里把流式响应关了反而能出结果但体验差一点。我习惯保持流式开启同时保证 Ollama 版本不要落后太多。4. 性能优化从“龟速”到 70 tok/s 的调试记录模型能出字了接下来就是速度问题。我第一次接好时跑 7B 模型只有 15 tok/s 出头对话时输出明显“一顿一顿”的。经过一系列调整最终稳定在 70 tok/s 左右。要说明的是这个数字和显卡、模型大小直接相关但里面的优化思路是通用的。4.1 影响 tok/s 的核心因素先列公式感。推理速度取决于模型量化等级q4_0比q8_0快得多但精度略降。Ollama 默认拉取的一般是q4_K_M这是速度和质量的平衡点。显存带宽模型权重要从显存搬到计算单元搬运速度就是瓶颈。同品牌显卡带宽高一点速度就能涨一截。上下文长度num_ctx越大KV Cache 占用越高计算量越大。有些人拉满 32K 上下文结果速度掉到个位数。Ollama 并发处理如果同时跑多个请求Ollama 会把资源切分成多份单个请求变慢。CPU 与 GPU 的分配默认 Ollama 优先 GPU但如果显存不够部分层会落到 CPU速度断崖式下跌。4.2 调参过程记录我第一次无脑默认参数跑 7B q4 模型速度 15 tok/s这个成绩说明 GPU 基本没吃满或 CPU 介入推理了。用ollama ps查看模型进程时发现模型被加载到了 CPU原因是显存不满足模型完整加载需求。这台机器是 RTX 40608GB 显存按理说 7B q4 模型 4.7GB 左右问题不大。但当时我没有关闭其他吃显存的应用加上 Ollama 默认预留给系统的显存额度比较多导致模型放不下一部分落回 CPU。解决办法是显式设置OLLAMA_GPU_OVERHEAD比如OLLAMA_GPU_OVERHEAD 1073741824也就是预留 1GB 显存给系统和其他应用其余全部给 Ollama 吃。调整后模型完整进入 GPU速度立刻跳到 40 tok/s 以上。然后是我的第二个动作检查温度、top_p 这些参数。WorkBuddy 里如果启用了“创意模式”会把temperature调高top_p调低这些参数虽然不影响推理计算量但会影响生成长度和采样路径极端时输出很慢。我统一把 WorkBuddy 的推理参数改成temperature 0.7top_p 0.9然后在 Ollama 层不设置额外参数让模型使用默认采样。第三个动作是降低上下文。WorkBuddy 默认给模型发送的上下文窗口不一定合理。我在 Ollama 侧限制ollama run qwen2.5:7b --num-ctx 40964096 对于大多数办公问答足够用速度比 8192 甚至 16384 快很多。因为每次请求处理时KV Cache 大小和初始化和上下文长度呈正相关上下文越大预热越慢。第四个动作是关闭无关的后台服务。笔记本上挂着浏览器几十个标签页、视频会议、开发工具这些都在抢显存和 CPU。关掉非必要应用后速度又明显提升了一截。最终在 RTX 4060 上跑qwen2.5:7b-q4_K_M单请求测速稳定在 70 tok/s 左右。这个速度已经接近该显卡的推理上限。下面是各阶段的对比调整阶段上下文长度显存占用推理速度初始默认8192部分落 CPU15 tok/s显存预留调整8192完整 GPU42 tok/s上下文缩至 40964096完整 GPU58 tok/s清理后台固定参数4096完整 GPU70 tok/s注意如果显卡是集成显卡或没有 NVIDIA 显卡速度会差一个数量级此时建议选择 3B/4B 小型量化模型而不是死磕 7B。并不是越大越好能流畅用起来的模型才是好模型。4.3 关于“关闭思考过程”的一个技巧热词里有“如何关闭 ollama 里 gemma 的思考过程”这里顺带讲一下。部分模型比如 gemma、deepseek-r1会把内部推理/思考过程作为输出的一部分展示出来。对于工作台场景思考过程会占用大量输出 token导致界面出现一堆“推理内容”后才给出正式答案体感上就是拖慢出字速度。关闭方式分两种如果模型本身支持系统提示控制可以在 WorkBuddy 的“系统提示词”里写上“不要展示思考过程直接给出最终答案”。如果模型是专门带的“思考版”需要在加载时设置关闭开关。Ollama 的Modelfile里可以用PARAMETER stop或者直接换一个非思考版模型。实测下来换非思考版模型最省心比如用gemma2:2b而不是gemma3时输出里就没有一大段推理过程。思考过程不是没用但工作台追求的是响应速度和结果整洁关闭它收益很大。需要深度分析时再临时开回思考模型都是可以在 WorkBuddy 里按对话切换的。5. 日常运营的坑路径、缓存、代理部署与扩展玩法把 WorkBuddy Ollama 跑稳定之后我陆陆续续又踩了几个周边坑这里一并整理。5.1 缓存目录怎么改改了有什么影响WorkBuddy 自己也有一个缓存目录默认在用户目录下。如果长期使用它会积攒向量索引、会话记录、临时文件。热词里有人问“workbuddy 缓存目录怎么更改”我在实践中的做法是修改 WorkBuddy 的配置文件把缓存路径指向数据盘。不同版本配置位置不同但通常在安装目录下有一个config.json或settings.json搜索cache字段改成绝对路径即可。改之前先退出程序否则配置会被覆盖回写。缓存清理很必要尤其是向量数据库索引。如果换了模型或者改了知识库旧的向量索引会导致检索结果混乱表现就是 WorkBuddy 答非所问。清缓存后重建索引即可。实操心得我一般定期清理 WorkBuddy 缓存目录里的vector_store子目录但保留会话记录子目录。这样既能清理掉无效索引又不丢失对话历史。5.2 Nginx 代理 Ollama局域网共享与 API Key 管理团队里如果有多个 WorkBuddy 实例要连一个 Ollama 主机直接暴露 11434 端口不太安全。我用 Nginx 做反向代理统一加了 API Key 校验既解决了密钥管理也方便做访问日志。配置核心server { listen 8080; server_name ollama.local; location / { if ($http_authorization ! Bearer your-secret-key) { return 401; } proxy_pass http://127.0.0.1:11434; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }这样客户端只需要把 WorkBuddy 的 Base URL 改成http://你的主机IP:8080/v1API Key 填your-secret-key就能走代理访问 Ollama。代理层还能做限流和 TLS 终止有条件的可以考虑。坑在 Nginx 对 SSE 流式响应的处理。默认 Nginx 会缓冲响应导致 WorkBuddy 迟迟看不到第一个 token。解决办法是关闭代理缓冲proxy_buffering off; proxy_cache off;这一步不做哪怕 Ollama 本身流式输出正常隔一层代理后又会变成“无输出”。5.3 用 FastAPI 包一层自定义业务逻辑如果不想让 WorkBuddy 的请求直接打到 Ollama也可以用 FastAPI 包一层这样可以在请求前后加自己的处理逻辑比如把用户问题先经过检索增强再发给模型或者记录所有对话到数据库。核心是转发逻辑from fastapi import FastAPI, Request import httpx app FastAPI() OLLAMA_URL http://127.0.0.1:11434/v1/chat/completions app.post(/v1/chat/completions) async def chat(request: Request): payload await request.json() # 在这里可以对 payload 做任何处理比如注入系统提示词 async with httpx.AsyncClient(timeout300) as client: resp await client.post(OLLAMA_URL, jsonpayload) return resp.json()然后 WorkBuddy 的 Base URL 指向http://127.0.0.1:8000/v1。这里的重点是如果之后要支持流式FastAPI 这层需要用StreamingResponse否则会丢掉 SSE 流。5.4 知识库功能中本地向量模型的接入WorkBuddy 的知识库问答依赖向量化。很多人以为向量化也必须用云端接口其实 Ollama 可以拉专门的 embedding 模型比如nomic-embed-text或bge-m3。在 WorkBuddy 配置里多建一个模型类型选“Embedding”Base URL 同样指向本地 Ollama模型名填 embedding 模型名知识库索引就会落到本地完成。我实测nomic-embed-text的大小只有几百 MB速度快效果对中文略一般bge-m3对中文更好但体积稍大。建议中文知识库直接上bge-m3或bge-large-zh。这种方式跑起来后整个知识库的文本处理全部离线完成不再依赖任何云服务隐私性拉满。6. 常见问题速查一句话对症下药为了方便后来者我把踩过的坑浓缩成一张速查表。遇到问题先对号入座能省不少时间。现象可能原因解决动作WorkBuddy 转圈无输出模型名不一致核对ollama list的准确名称重填无输出且日志有 404Base URL 缺/v1改成http://127.0.0.1:11434/v1无输出且日志有 401API Key 未通过代理校验填写非空字符串代理处更新密钥请求到达 Ollama 但模型加载慢上下文设置过大调小num_ctx到 4096 或 2048推理速度极慢显存不足层被丢到 CPU关闭占用显存应用设置OLLAMA_GPU_OVERHEAD下载模型一直失败网络原因换镜像、用 GGUF 本地导入C 盘空间暴涨模型默认路径设OLLAMA_MODELS到数据盘代理后无流式输出Nginx 缓冲加proxy_buffering off;WorkBuddy 检索质量差向量索引旧清理缓存目录vector_store重建索引ollama serve直接段错误下载损坏删除对应模型缓存文件重新拉取对话会先输出大段思考过程模型本身带思考模式换非思考版模型或系统提示词抑制这张表里的每一条都是我实际碰到过的。大多数问题不是同时爆发的而是随着使用场景变化出现的。第一次接 Ollama 的读者建议保存下来按表格逐项排除已经是效率最高的路径。7. 我个人最后的几条经验这套 WorkBuddy Ollama 方案跑通之后我的日常使用习惯也变了不少。这里说几点体会希望对你们有用。第一本地模型不是越新越好。我同时装过 7B 和 14B 两个版本的模型14B 在生成质量上确实更强但速度只有 30 tok/s 出头实际用起来反而没有 70 tok/s 的 7B 顺手。工作台场景下输出速度直接影响大脑思路的连贯性。慢模型容易把人等烦最后还是会切回小模型。第二配置变更后一定重启 Ollama 和 WorkBuddy 两端。环境变量、模型路径、API Key 这些配置有的只在启动时读取。我遇到过一次改了OLLAMA_MODELS但没重启结果新拉的模型跑到了旧目录C 盘又开始暴涨找了半天才发现原因。第三善用ollama ps观察模型是否驻留显存。很多时候 WorkBuddy 提示“模型未加载”其实是 Ollama 的自动卸载机制把不活跃的模型从显存里清掉了。需要时可以设置OLLAMA_KEEP_ALIVE比如OLLAMA_KEEP_ALIVE 1h让模型在显存中驻留一小时避免每次对话都要重新加载。这个参数对交互体验影响很大尤其是频繁切换模型的人建议设置成30m或1h试试。第四备份 WorkBuddy 的配置文件。WorkBuddy 的模型配置、技能、项目设置都存在本地配置里。我经历过一次版本升级后配置被重置所有模型连接信息都没了重新配一遍花了半小时。后来我每次调好配置就复制一份配置文件存到网盘升级前先备份。这比任何教程都实用。这套东西完全跑在本地数据不出门速度拉到 70 tok/s对日常办公辅助来说已经足够流畅。如果你也在折腾 WorkBuddy 接本地模型卡在“无输出”或者速度上不去按这条链路走一遍大概率能解决问题。最后再提醒一句遇到问题先分層别被表面的转圈迷惑先验 Ollama再验 WorkBuddy永远是最稳的排查节奏。