最近在折腾 WorkBuddy 接入本地 Ollama 模型从最开始调用接口干脆没反应到最终跑出 70 tok/s 的稳定速度中间踩的坑攒起来估计能写一篇长文。这篇就当是个人排查记录的整理给正准备把 WorkBuddy 和 Ollama 连起来用的朋友做个参考。我会把整个流程、排查思路、最终能跑通的关键决策全部拆开讲每一步都标注了为什么这么做毕竟这类问题如果不理解原理换个配置可能又得重新踩一遍。先说结论问题基本都出在“模型名不匹配”“上下文参数没调”和“API 兼容性没验证”这三类上性能瓶颈则集中在量化等级、上下文长度和并发数的取舍。下面按我实际操作的顺序来写。1. 整体接入思路为什么选 Ollama 而不是云 API先说 WorkBuddy 这边。它本质上是一个 AI 代理工作台可以挂各种 skill也能调用不同后端的模型接口。默认配置走的是云 API但对我来说有两个痛点一是数据隐私我把不少文档和代码片段丢给工作台处理不希望内容经过第三方服务器二是稳定性云服务有时会抽风而且响应速度随网络波动。所以接本地模型是刚需。选 Ollama 而不是 LM Studio 或其他方案主要看三点Ollama 对 OpenAI 兼容 API 的支持比较成熟WorkBuddy 这类工具基本可以直接配 Base URL 和 API Key 就能用不用额外写适配层。模型管理简单一条命令就能拉模型、跑服务不需要手写复杂的加载脚本。社区活跃遇到问题基本都能搜到现成方案这一点在踩坑时非常重要。当然 LM Studio 也可以但如果 WorkBuddy 的 skill 机制需要频繁切换模型Ollama 的 CLI 比 LM Studio 的图形界面更顺手。另外 Ollama 原生跑 GGUF 量化模型内存占用控制得不错对一台没有顶级显卡的机器更友好。我的目标很明确先用 Ollama 把本地模型服务跑起来再用 WorkBuddy 配置一个本地模型作为默认后端最后在保证可用的前提下把速度拉到能舒服用起来的水平。整个流程就三步但每一步都有不少细节。2. 环境准备与安装避坑存储路径、下载速度、离线迁移2.1 安装 Ollama 前先想清楚装在哪Ollama 模型文件体积不小一个 7B 模型的 q4 量化版本也要 4GB 左右8B 模型更是接近 5GB。如果系统盘比较小默认装 C 盘很容易爆。我的做法是提前规划路径。Windows 上很简单安装包装好后模型默认存储在C:\Users\用户名\.ollama\models。如果想把模型放别的盘不是改安装目录而是要设置环境变量OLLAMA_MODELS。这个变量需要手动新建指向你想放模型的目录改完重启 Ollama 才生效。Linux 和 macOS 同理只是路径不一样。Linux 下默认是/usr/share/ollama/.ollama/modelsroot 用户或~/.ollama/models同样通过export OLLAMA_MODELS/your/path修改。我这次是在一台 32GB 内存的机器上跑的显存只有 8GB所以策略很明确模型放 SSD小模型让 GPU 参与计算大模型干脆纯走 CPU 内存。实测下来 7B q4 模型在纯 CPU 模式下也能有 40-50 tok/s完全够用关键是内存带宽不能太差。注意修改 OLLAMA_MODELS 之后之前拉取的模型不会自动迁移需要手动复制或重新拉取或者直接在新目录里重新ollama pull。2.2 下载速度慢的真正解法官方源下载模型经常卡住尤其是几十 GB 的大模型。我碰到的情况是下载到一半就断重试还是断非常折磨。这里有一个很实用的组合办法设置代理环境变量如果有条件HTTPS_PROXY指到本地代理端口Ollama 会走这个通道下载。如果不想依赖代理可以用 HuggingFace 上的 GGUF 版本手动下载后用ollama create导入本地文件。# 示例手动导入 GGUF 模型 ollama create my-model -f ModelfileModelfile 内容很简单指向你本地下载好的 GGUF 文件即可。这个方式的好处是下载过程可控支持断点续传工具而且能顺便把模型文件整理到统一目录。2.3 离线安装包的迁移动线如果目标机器完全没网或者下载死活拉不动先在一台网络通畅的机器上把 Ollama 安装包和模型文件都下好然后拷贝过去。Windows 下直接把.ollama目录整个拷贝到目标机器的用户目录设置好OLLAMA_MODELS环境变量启动 Ollamaollama list就能看到模型已经就位。这块有一个容易踩的细节模型文件里包含了索引信息和 blob 文件拷贝的时候要保证整个.ollama目录完整不能只拷贝一部分。我见过有人只把 models 子目录考过去结果ollama list能看到名字但一调用就报 manifest 错误。3. WorkBuddy 接入配置与“无输出”问题全排查3.1 WorkBuddy 的模型配置长什么样WorkBuddy 的模型配置入口通常是在设置页面或者配置文件里指定 Base URL 和模型名。以 OpenAI 兼容接口为例Base URL:http://127.0.0.1:11434/v1API Key: 随便填一个占位符比如ollama模型名: 必须和ollama list里的名字完全一致很多人“无输出”的第一个原因就是模型名没匹配。比如ollama list显示的是qwen2.5:7b但 WorkBuddy 里填了qwen2.5-7b这俩就差一个冒号的问题API 直接给你 404 或者空响应。最好的习惯是先去终端跑一遍ollama list把模型名原样复制过去。API Key 这个点也有讲究。Ollama 默认不校验 key但 WorkBuddy 可能要求非空所以填什么都能过。如果后面配了 Nginx 反代加上自定义鉴权那 key 就要和反代层对应起来这部分到第五节再说。3.2 无输出的第一层排查先验证底层 APIWorkBuddy 界面上看不到输出先把 WorkBuddy 丢一边直接用 curl 测试 Ollama 接口是否正常。这一步非常重要能把问题切成两半Ollama 的问题还是 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: 说一句话}] }如果 curl 返回正常 JSON里面有content字段说明 Ollama 这边没问题问题出在 WorkBuddy 的配置。如果 curl 直接报错那就要看 Ollama 服务日志。这个验证动作看起来简单但真的能省大量时间。我排查无输出问题时前两次都以为是 WorkBuddy 配置问题后来一 curl 才发现 Ollama 服务根本没起来只是因为 Windows 服务里显示正在运行实际进程已经僵死。3.3 无输出的第二层排查Ollama 服务日志如果 curl 都挂了看日志是唯一高效路径。Windows 下 Ollama 日志在%LOCALAPPDATA%\Ollama\server.logLinux 下看 systemd 日志journalctl -u ollama -f或者直接前台跑ollama serve前台模式的好处是日志直接打到终端排查起来最直观。常见日志错误大概有这几类显存不够模型加载失败进程直接退出模型文件损坏或 manifest 缺失加载时报错端口被占用Ollama 起不来我这次碰到的问题就是Ollama 服务起来了但模型加载到一半显卡显存爆了服务直接退出WorkBuddy 那边显示的就是“无输出”。因为 WorkBuddy 对连接断开没有特别明确的报错就把我误导到了配置方向上。3.4 无输出的第三层排查WorkBuddy 侧的工具调用问题如果 curl 正常但 WorkBuddy 仍然没输出问题就坑了。我发现 WorkBuddy 这类代理工具在调用模型时并不是简单发一个 user 消息它可能会带上 tool call 相关的结构化要求比如让模型输出特定 JSON 格式或者声明支持 function calling。Ollama 对不同模型的 tool calling 支持程度不一致。有些模型虽然能对话但 tool call 能力很弱API 返回的 content 是空的只返回tool_calls字段而 WorkBuddy 又没能正确解析这个字段结果界面上一片空白看起来就是“没反应”。这种问题怎么快速判断还是回到 curl但这次要模拟 WorkBuddy 的请求加上tools参数curl http://127.0.0.1:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5:7b, messages: [{role: user, content: 调用工具做某件事}], tools: [{type: function, function: {name: search, description: 搜索, parameters: {type: object, properties: {}}}}] }看返回结果是正常回复还是空 content。如果空 content基本可以断定是 tool call 兼容问题。我的解法是不干掉 tool call而是换一个 tool call 能力强的模型实测 qwen2.5 系列对 tool calling 支持得不错部分 8B 以下的旧模型确实拉胯。提示Ollama 的 tool calling 兼容性取决于模型本身是否训练过 function calling 数据。不要指望所有模型都能在 WorkBuddy 里完美工作。4. 性能调优记录从几十秒回一个词到 70 tok/s4.1 影响输出速度的关键因素先明确一个概念tok/s 是每秒生成的 token 数。70 tok/s 意味着一个 500 字的回答大概 7 秒能生成完这个速度在对话场景已经可以让人比较自然地阅读。影响这个数字的因素从大到小排列模型参数量与量化等级7B 和 32B 的速度差距接近 4 到 5 倍。上下文长度上下文越长KV Cache 占用越大计算量也越大。并发请求数多个请求同时进来单请求速度会被稀释。硬件平台GPU 显存带宽、内存带宽、是否支持 bfloat16 等。我最终的配置是qwen2.5:7b 量化版上下文 4096并发 4走OLLAMA_FLASH_ATTENTION1和 GPU 加速。这个组合在 8GB 显存下刚好放得下模型加 KV CacheGPU 推理的速度就上来了。4.2 关闭思考过程模型一个容易忽略的香饽饽如果用的是带思考过程的模型比如 gemma4 这类默认情况下每回答一个问题模型会先输出一大段内部思考内容再输出正式回答。对 WorkBuddy 来说这段思考过程会占掉大量 token而且速度看着很慢——因为你把思考时间也算进等待里了。关闭思考过程的方法因模型而异。在 Ollama 里有些模型通过 prompt 里加特殊标记控制有些支持 API 参数。实测更靠谱的方式是用 Modelfile 定制一个关闭思考的版本。# Modelfile 示例 FROM gemma4:latest PARAMETER temperature 0.7 SYSTEM You are a helpful assistant. Do NOT show your internal reasoning. Provide final answer directly.然后执行ollama create gemma4-direct -f Modelfile在 WorkBuddy 里用这个新模型名。这一招直接把速度翻了一倍不止因为思考过程通常占整段输出的一半以上。4.3 调优后终见 70 tok/s经过上面一轮修改我的ollama list里有两个 gemma 系模型一个是原始的一个是关闭思考的。WorkBuddy 里挂的是关闭思考的版本。最终实测输出速度稳定在 68-72 tok/s 之间和网上类似配置的评测数据基本一致。这个数值说明本地模型在消费级硬件上已经完全能胜任对话和轻量写作任务。如果你也需要做代码补全或者多步推理建议选 7B-14B 区间的 qwen2.5 或 llama3.1 系列性价比最高。再往上没大显存直接就崩了。5. 高频问题速查与最终配置参考5.1 常见问题速查表现象可能原因解决方案Ollama 500 Internal Server Errorllama-server 进程启动失败看日志通常是显存或内存不足换更小模型或降低上下文WorkBuddy 无输出模型名错误、tool call 不兼容用 curl 验证 API确认模型名完全一致下载慢/下载中断网络问题使用代理、离线导入 GGUF、HuggingFace 手动下载模型路径错误OLLAMA_MODELS 未设置新建环境变量指向目标目录重启服务速度慢没关思考过程、上下文过长定制 Modelfile 关闭思考、调低 num_ctx模型加载失败Ollama 服务未启动前台跑ollama serve看日志这个表是我个人排障的顺序。先看服务再看 API最后才怀疑应用配置这个顺序可以帮你快速定位 80% 的问题。5.2 Nginx 反向代理加 API Key 鉴权如果 WorkBuddy 和 Ollama 不在同一台机器或者你想要一层访问控制可以用 Nginx 反代。热词里有“nginx 代理 ollama 设置 apikey cherrystudio”这个思路和 cherrystudio 类似本质都是让 Ollama 暴露一个带鉴权的地址。location /v1/ { proxy_pass http://127.0.0.1:11434/v1/; proxy_set_header Host $host; if ($http_authorization ! Bearer your-secret-key) { return 401; } }这个配置要注意一点Ollama 的 API 本身不校验 key所以必须靠 Nginx 这层来挡。WorkBuddy 那边填的 API Key 就填your-secret-keyBase URL 填 Nginx 的地址。实测下来很稳但这层会引入一点点网络开销局域网内基本感知不到。5.3 WorkBuddy 系统缓存目录修改WorkBuddy 的 skill 和会话记录会占不少空间默认放系统盘的话也会有容量焦虑。热词里提到“workbuddy怎么更改系统缓存目录”我实测的设置方式是在配置文件里指定缓存路径。操作方法类似大部分桌面工具找到设置里的存储/缓存选项手动指向新目录改完重启应用。如果找不到图形入口直接在新路径下建目录然后看配置文件里的绝对路径字段有没有有就改。这个操作对大多数人来说够用了。5.4 WorkBuddy 与 CodeBuddy 的关系网上不少人会问这两个是不是同一个东西。简单说CodeBuddy 定位是编码助手WorkBuddy 更像一个通用 AI 工作台偏向文档处理、流程编排这类的 agent 场景。两者可以配合使用但不要混为一谈。如果你想在自己的工作流里都用本地模型两个工具接 Ollama 的思路是一样的就是配 Base URL 和模型名所以这篇里的排查思路完全通用。6. 最后一公里的经验总结跑通一次完整流程后我个人的体会是接入本地模型的难点不在配置本身而在“沉默的失败”太多了。云 API 挂了会明确报 4xx、5xx本地 Ollama 进程崩了你可能就只看到一个空白对话。所以好用的习惯是任何改动之后先去终端里用 curl 打一发确认底层 OK 再回应用层看。另外一个小技巧如果 Ollama 服务频繁崩先不要怀疑 WorkBuddy把num_ctx从默认的 2048 提到目标长度之前先在 config 里把上下文调低试跑稳定了再往上加。这个顺序能帮你把“模型加载失败”和“性能不足”两类问题分清楚。最后再分享一个从这次折腾中受益的决策WorkBuddy 的 skill 配置里把普通对话和代码生成分成两个模型入口。对话用关闭思考过程的高速度小模型代码生成用能力更强的大一点模型。虽然切换有成本但整体体验比一个模型打天下舒服得多。
最近在折腾 WorkBuddy 接入本地 Ollama 模型从最开始调用接口干脆没反应到最终跑出 70 tok/s 的稳定速度中间踩的坑攒起来估计能写一篇长文。这篇就当是个人排查记录的整理给正准备把 WorkBuddy 和 Ollama 连起来用的朋友做个参考。我会把整个流程、排查思路、最终能跑通的关键决策全部拆开讲每一步都标注了为什么这么做毕竟这类问题如果不理解原理换个配置可能又得重新踩一遍。先说结论问题基本都出在“模型名不匹配”“上下文参数没调”和“API 兼容性没验证”这三类上性能瓶颈则集中在量化等级、上下文长度和并发数的取舍。下面按我实际操作的顺序来写。1. 整体接入思路为什么选 Ollama 而不是云 API先说 WorkBuddy 这边。它本质上是一个 AI 代理工作台可以挂各种 skill也能调用不同后端的模型接口。默认配置走的是云 API但对我来说有两个痛点一是数据隐私我把不少文档和代码片段丢给工作台处理不希望内容经过第三方服务器二是稳定性云服务有时会抽风而且响应速度随网络波动。所以接本地模型是刚需。选 Ollama 而不是 LM Studio 或其他方案主要看三点Ollama 对 OpenAI 兼容 API 的支持比较成熟WorkBuddy 这类工具基本可以直接配 Base URL 和 API Key 就能用不用额外写适配层。模型管理简单一条命令就能拉模型、跑服务不需要手写复杂的加载脚本。社区活跃遇到问题基本都能搜到现成方案这一点在踩坑时非常重要。当然 LM Studio 也可以但如果 WorkBuddy 的 skill 机制需要频繁切换模型Ollama 的 CLI 比 LM Studio 的图形界面更顺手。另外 Ollama 原生跑 GGUF 量化模型内存占用控制得不错对一台没有顶级显卡的机器更友好。我的目标很明确先用 Ollama 把本地模型服务跑起来再用 WorkBuddy 配置一个本地模型作为默认后端最后在保证可用的前提下把速度拉到能舒服用起来的水平。整个流程就三步但每一步都有不少细节。2. 环境准备与安装避坑存储路径、下载速度、离线迁移2.1 安装 Ollama 前先想清楚装在哪Ollama 模型文件体积不小一个 7B 模型的 q4 量化版本也要 4GB 左右8B 模型更是接近 5GB。如果系统盘比较小默认装 C 盘很容易爆。我的做法是提前规划路径。Windows 上很简单安装包装好后模型默认存储在C:\Users\用户名\.ollama\models。如果想把模型放别的盘不是改安装目录而是要设置环境变量OLLAMA_MODELS。这个变量需要手动新建指向你想放模型的目录改完重启 Ollama 才生效。Linux 和 macOS 同理只是路径不一样。Linux 下默认是/usr/share/ollama/.ollama/modelsroot 用户或~/.ollama/models同样通过export OLLAMA_MODELS/your/path修改。我这次是在一台 32GB 内存的机器上跑的显存只有 8GB所以策略很明确模型放 SSD小模型让 GPU 参与计算大模型干脆纯走 CPU 内存。实测下来 7B q4 模型在纯 CPU 模式下也能有 40-50 tok/s完全够用关键是内存带宽不能太差。注意修改 OLLAMA_MODELS 之后之前拉取的模型不会自动迁移需要手动复制或重新拉取或者直接在新目录里重新ollama pull。2.2 下载速度慢的真正解法官方源下载模型经常卡住尤其是几十 GB 的大模型。我碰到的情况是下载到一半就断重试还是断非常折磨。这里有一个很实用的组合办法设置代理环境变量如果有条件HTTPS_PROXY指到本地代理端口Ollama 会走这个通道下载。如果不想依赖代理可以用 HuggingFace 上的 GGUF 版本手动下载后用ollama create导入本地文件。# 示例手动导入 GGUF 模型 ollama create my-model -f ModelfileModelfile 内容很简单指向你本地下载好的 GGUF 文件即可。这个方式的好处是下载过程可控支持断点续传工具而且能顺便把模型文件整理到统一目录。2.3 离线安装包的迁移动线如果目标机器完全没网或者下载死活拉不动先在一台网络通畅的机器上把 Ollama 安装包和模型文件都下好然后拷贝过去。Windows 下直接把.ollama目录整个拷贝到目标机器的用户目录设置好OLLAMA_MODELS环境变量启动 Ollamaollama list就能看到模型已经就位。这块有一个容易踩的细节模型文件里包含了索引信息和 blob 文件拷贝的时候要保证整个.ollama目录完整不能只拷贝一部分。我见过有人只把 models 子目录考过去结果ollama list能看到名字但一调用就报 manifest 错误。3. WorkBuddy 接入配置与“无输出”问题全排查3.1 WorkBuddy 的模型配置长什么样WorkBuddy 的模型配置入口通常是在设置页面或者配置文件里指定 Base URL 和模型名。以 OpenAI 兼容接口为例Base URL:http://127.0.0.1:11434/v1API Key: 随便填一个占位符比如ollama模型名: 必须和ollama list里的名字完全一致很多人“无输出”的第一个原因就是模型名没匹配。比如ollama list显示的是qwen2.5:7b但 WorkBuddy 里填了qwen2.5-7b这俩就差一个冒号的问题API 直接给你 404 或者空响应。最好的习惯是先去终端跑一遍ollama list把模型名原样复制过去。API Key 这个点也有讲究。Ollama 默认不校验 key但 WorkBuddy 可能要求非空所以填什么都能过。如果后面配了 Nginx 反代加上自定义鉴权那 key 就要和反代层对应起来这部分到第五节再说。3.2 无输出的第一层排查先验证底层 APIWorkBuddy 界面上看不到输出先把 WorkBuddy 丢一边直接用 curl 测试 Ollama 接口是否正常。这一步非常重要能把问题切成两半Ollama 的问题还是 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: 说一句话}] }如果 curl 返回正常 JSON里面有content字段说明 Ollama 这边没问题问题出在 WorkBuddy 的配置。如果 curl 直接报错那就要看 Ollama 服务日志。这个验证动作看起来简单但真的能省大量时间。我排查无输出问题时前两次都以为是 WorkBuddy 配置问题后来一 curl 才发现 Ollama 服务根本没起来只是因为 Windows 服务里显示正在运行实际进程已经僵死。3.3 无输出的第二层排查Ollama 服务日志如果 curl 都挂了看日志是唯一高效路径。Windows 下 Ollama 日志在%LOCALAPPDATA%\Ollama\server.logLinux 下看 systemd 日志journalctl -u ollama -f或者直接前台跑ollama serve前台模式的好处是日志直接打到终端排查起来最直观。常见日志错误大概有这几类显存不够模型加载失败进程直接退出模型文件损坏或 manifest 缺失加载时报错端口被占用Ollama 起不来我这次碰到的问题就是Ollama 服务起来了但模型加载到一半显卡显存爆了服务直接退出WorkBuddy 那边显示的就是“无输出”。因为 WorkBuddy 对连接断开没有特别明确的报错就把我误导到了配置方向上。3.4 无输出的第三层排查WorkBuddy 侧的工具调用问题如果 curl 正常但 WorkBuddy 仍然没输出问题就坑了。我发现 WorkBuddy 这类代理工具在调用模型时并不是简单发一个 user 消息它可能会带上 tool call 相关的结构化要求比如让模型输出特定 JSON 格式或者声明支持 function calling。Ollama 对不同模型的 tool calling 支持程度不一致。有些模型虽然能对话但 tool call 能力很弱API 返回的 content 是空的只返回tool_calls字段而 WorkBuddy 又没能正确解析这个字段结果界面上一片空白看起来就是“没反应”。这种问题怎么快速判断还是回到 curl但这次要模拟 WorkBuddy 的请求加上tools参数curl http://127.0.0.1:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5:7b, messages: [{role: user, content: 调用工具做某件事}], tools: [{type: function, function: {name: search, description: 搜索, parameters: {type: object, properties: {}}}}] }看返回结果是正常回复还是空 content。如果空 content基本可以断定是 tool call 兼容问题。我的解法是不干掉 tool call而是换一个 tool call 能力强的模型实测 qwen2.5 系列对 tool calling 支持得不错部分 8B 以下的旧模型确实拉胯。提示Ollama 的 tool calling 兼容性取决于模型本身是否训练过 function calling 数据。不要指望所有模型都能在 WorkBuddy 里完美工作。4. 性能调优记录从几十秒回一个词到 70 tok/s4.1 影响输出速度的关键因素先明确一个概念tok/s 是每秒生成的 token 数。70 tok/s 意味着一个 500 字的回答大概 7 秒能生成完这个速度在对话场景已经可以让人比较自然地阅读。影响这个数字的因素从大到小排列模型参数量与量化等级7B 和 32B 的速度差距接近 4 到 5 倍。上下文长度上下文越长KV Cache 占用越大计算量也越大。并发请求数多个请求同时进来单请求速度会被稀释。硬件平台GPU 显存带宽、内存带宽、是否支持 bfloat16 等。我最终的配置是qwen2.5:7b 量化版上下文 4096并发 4走OLLAMA_FLASH_ATTENTION1和 GPU 加速。这个组合在 8GB 显存下刚好放得下模型加 KV CacheGPU 推理的速度就上来了。4.2 关闭思考过程模型一个容易忽略的香饽饽如果用的是带思考过程的模型比如 gemma4 这类默认情况下每回答一个问题模型会先输出一大段内部思考内容再输出正式回答。对 WorkBuddy 来说这段思考过程会占掉大量 token而且速度看着很慢——因为你把思考时间也算进等待里了。关闭思考过程的方法因模型而异。在 Ollama 里有些模型通过 prompt 里加特殊标记控制有些支持 API 参数。实测更靠谱的方式是用 Modelfile 定制一个关闭思考的版本。# Modelfile 示例 FROM gemma4:latest PARAMETER temperature 0.7 SYSTEM You are a helpful assistant. Do NOT show your internal reasoning. Provide final answer directly.然后执行ollama create gemma4-direct -f Modelfile在 WorkBuddy 里用这个新模型名。这一招直接把速度翻了一倍不止因为思考过程通常占整段输出的一半以上。4.3 调优后终见 70 tok/s经过上面一轮修改我的ollama list里有两个 gemma 系模型一个是原始的一个是关闭思考的。WorkBuddy 里挂的是关闭思考的版本。最终实测输出速度稳定在 68-72 tok/s 之间和网上类似配置的评测数据基本一致。这个数值说明本地模型在消费级硬件上已经完全能胜任对话和轻量写作任务。如果你也需要做代码补全或者多步推理建议选 7B-14B 区间的 qwen2.5 或 llama3.1 系列性价比最高。再往上没大显存直接就崩了。5. 高频问题速查与最终配置参考5.1 常见问题速查表现象可能原因解决方案Ollama 500 Internal Server Errorllama-server 进程启动失败看日志通常是显存或内存不足换更小模型或降低上下文WorkBuddy 无输出模型名错误、tool call 不兼容用 curl 验证 API确认模型名完全一致下载慢/下载中断网络问题使用代理、离线导入 GGUF、HuggingFace 手动下载模型路径错误OLLAMA_MODELS 未设置新建环境变量指向目标目录重启服务速度慢没关思考过程、上下文过长定制 Modelfile 关闭思考、调低 num_ctx模型加载失败Ollama 服务未启动前台跑ollama serve看日志这个表是我个人排障的顺序。先看服务再看 API最后才怀疑应用配置这个顺序可以帮你快速定位 80% 的问题。5.2 Nginx 反向代理加 API Key 鉴权如果 WorkBuddy 和 Ollama 不在同一台机器或者你想要一层访问控制可以用 Nginx 反代。热词里有“nginx 代理 ollama 设置 apikey cherrystudio”这个思路和 cherrystudio 类似本质都是让 Ollama 暴露一个带鉴权的地址。location /v1/ { proxy_pass http://127.0.0.1:11434/v1/; proxy_set_header Host $host; if ($http_authorization ! Bearer your-secret-key) { return 401; } }这个配置要注意一点Ollama 的 API 本身不校验 key所以必须靠 Nginx 这层来挡。WorkBuddy 那边填的 API Key 就填your-secret-keyBase URL 填 Nginx 的地址。实测下来很稳但这层会引入一点点网络开销局域网内基本感知不到。5.3 WorkBuddy 系统缓存目录修改WorkBuddy 的 skill 和会话记录会占不少空间默认放系统盘的话也会有容量焦虑。热词里提到“workbuddy怎么更改系统缓存目录”我实测的设置方式是在配置文件里指定缓存路径。操作方法类似大部分桌面工具找到设置里的存储/缓存选项手动指向新目录改完重启应用。如果找不到图形入口直接在新路径下建目录然后看配置文件里的绝对路径字段有没有有就改。这个操作对大多数人来说够用了。5.4 WorkBuddy 与 CodeBuddy 的关系网上不少人会问这两个是不是同一个东西。简单说CodeBuddy 定位是编码助手WorkBuddy 更像一个通用 AI 工作台偏向文档处理、流程编排这类的 agent 场景。两者可以配合使用但不要混为一谈。如果你想在自己的工作流里都用本地模型两个工具接 Ollama 的思路是一样的就是配 Base URL 和模型名所以这篇里的排查思路完全通用。6. 最后一公里的经验总结跑通一次完整流程后我个人的体会是接入本地模型的难点不在配置本身而在“沉默的失败”太多了。云 API 挂了会明确报 4xx、5xx本地 Ollama 进程崩了你可能就只看到一个空白对话。所以好用的习惯是任何改动之后先去终端里用 curl 打一发确认底层 OK 再回应用层看。另外一个小技巧如果 Ollama 服务频繁崩先不要怀疑 WorkBuddy把num_ctx从默认的 2048 提到目标长度之前先在 config 里把上下文调低试跑稳定了再往上加。这个顺序能帮你把“模型加载失败”和“性能不足”两类问题分清楚。最后再分享一个从这次折腾中受益的决策WorkBuddy 的 skill 配置里把普通对话和代码生成分成两个模型入口。对话用关闭思考过程的高速度小模型代码生成用能力更强的大一点模型。虽然切换有成本但整体体验比一个模型打天下舒服得多。
