★ FEATURED ARTICLE 大概半年前我决定把 WorkBuddy 从云端 API 迁到本地大模型上。原因很简单不想每写一段代码都提心吊胆盯着额度也想试试完全离线跑 AI 编程助手是什么体验。结果第一天差点把我劝退——模型明明加载成功了WorkBuddy 聊天窗口转圈二十多秒一个字都没输出。后来我翻日志、换模型、调参、改环境变量前前后后折腾了快一周最终把速度稳定在 70 tok/s 左右。这篇文章就是那次完整踩坑记录从“没有任何输出”到“流畅对话”的全过程适合所有想用 WorkBuddy、Claude Code 这类工具接入 Ollama 本地模型的朋友参考。1. 把地基打牢Ollama 安装和模型存储的几个前置决定很多人接入本地模型失败不是连接配置有问题而是最开始装 Ollama 的姿势就不对。这个阶段踩的坑虽然看起来和“无输出”没关系但后面排查起来会浪费大量时间。这里先说两个最典型的前置问题。1.1 Ollama 下载慢用离线包和镜像源解决Ollama 的安装包默认从 GitHub Release 下载在国内网络环境下经常只有几十 KB/s下载一个几百 MB 的安装包能等到怀疑人生。我当时试过三种方案最省心的还是找国内加速渠道。第一种思路是直接找 GitHub 文件加速镜像。像ghproxy这类服务可以把 GitHub Release 的下载地址转成加速链接下载速度能拉到几 MB/s。具体操作很简单到 Ollama 的 GitHub Release 页面复制最新版本的下载地址然后在前面拼接加速域名就行和 Windows 安装包、Linux 的 tar.gz 包都兼容。第二种思路更省事——找离线安装包。很多做本地模型分享的社区或个人博主会把 Ollama 安装包传到网盘搜索“Ollama 离线安装包”基本都能找到。下载好后双击安装或者解压即用完全绕开网络问题。Windows 用户建议装完后顺手跑一下ollama --version确认安装目录在 PATH 里如果提示找不到命令把 Ollama 的安装目录手动加到系统环境变量 Path 里就行。第三种方案适合已经有 Docker 环境的场景。直接docker pull ollama/ollama拉镜像虽然镜像是从 Docker Hub 下载但一般比 GitHub Release 快得多。用 Docker 部署还有个好处后面如果要接 Dify 这类平台做工作流服务和模型都在容器里管理起来更干净。1.2 模型别放系统盘OLLAMA_MODELS 路径迁移Ollama 默认把模型文件放在用户目录下Windows 是C:\Users\用户名\.ollama\modelsLinux 是/usr/share/ollama/.ollama/models。一个 7B 模型 Q4 量化后大约 4.7 GB装三四个模型就是 20 GB 起步。C 盘吃得消倒也算了问题是后面换模型、删缓存都会频繁读写放在系统盘里既拖慢速度又占空间。改存储路径靠环境变量OLLAMA_MODELS。Windows 上给当前用户新建环境变量值填你想存放的目录例如D:\ollama\modelsLinux 可以在/etc/systemd/system/ollama.service的[Service]段加EnvironmentOLLAMA_MODELS/data/ollama/models改完systemctl daemon-reload再重启服务。改完之后务必跑ollama list确认能读到已有模型如果之前已经下过模型把旧目录里的文件拷到新目录再启动。这里提醒一件事改完路径后Ollama 服务必须重启而且 WorkBuddy 那边最好也把连接断开重连一次。我当时改完路径后没重启 Ollama结果 WorkBuddy 请求直接 500白白排查了半天。提示老系统比如 Windows 7装最新版 Ollama 会比较吃力官方对旧系统的支持也在逐渐收紧。如果非要在低版本系统上跑建议选老版本 Ollama 配合小模型7B 以上模型体验会非常难受。2. 打通 WorkBuddy 与 Ollama 的配置链路从“看不见模型”到“连得上服务”环境装好后下一步是让 WorkBuddy 能调用 Ollama。大多数 AI 编程助手都支持 OpenAI 兼容接口WorkBuddy 也不例外。这个阶段的错误配置是“无输出”的第二大来源。2.1 Base URL 别填错OpenAI 兼容端点的正确姿势Ollama 从 0.7.x 版本开始内置了 OpenAI 兼容端点路径是/v1。所以在 WorkBuddy 的自定义模型配置里Base URL 填http://127.0.0.1:11434/v1API Key 填任意非空字符串比如ollama本地服务不校验 key但不能留空Model 填qwen2.5:7b这类已经拉到本地的模型名这里有一个很隐蔽的坑localhost在某些系统上会解析到 IPv6 的::1而 Ollama 默认只监听 IPv4 的127.0.0.1。如果 WorkBuddy 报连接失败但你的浏览器访问http://localhost:11434又能通那大概率就是 IPv6 解析问题。直接统一用127.0.0.1能避免大量莫名其妙的问题。还有一个我见过不少新手会踩的点把 Base URL 填成http://127.0.0.1:11434/api/generate或者http://127.0.0.1:11434/api/chat。这两个是 Ollama 的原生接口路径不是 OpenAI 兼容的/v1路径。WorkBuddy 这类工具按 OpenAI 协议去请求URL 拼接会变成/v1/api/chat直接 404。识别方法很简单如果 Ollama 日志里能看见请求进来但 WorkBuddy 提示“model not found”或 404先检查路径。2.2 模型名必须和 ollama list 完全一致模型名这个东西看着简单实际操作中踩坑概率极高。ollama list输出的完整名称长这样qwen2.5:7b llama3.2:3b gemma3:4b deepseek-r1:8b注意llama3.2:3b和llama3.2是两个条目前者是带 tag 的完整名称后者指向默认 tag。你配置时必须完整写对差一个冒号都会报 model not found。更恶心的是有些热词里流传的模型名是错的比如我之前见过有人写qwen3.5:2b但模型仓库里根本没有这个 tag拉取时直接 500。遇到这种 500 错误先ollama pull一次让 Ollama 自己告诉你正确的模型名。稳妥的做法是配置 WorkBuddy 之前先在命令行跑一次ollama list把输出截图或者抄下来配置时逐字对照。不要凭记忆输特别是自己拼过的模型名十有八九是错的。2.3 让 Ollama 允许本地跨域与局域网访问默认情况下Ollama 只允许来自127.0.0.1的请求并且设置了 CORS 限制。如果你只是在同一台机器上跑 WorkBuddy问题不大但如果后面想把 Ollama 提供给局域网内其他设备或者用 Nginx 代理加密码保护这两个变量就得提前设置环境变量作用推荐值OLLAMA_HOST监听地址仅本机用127.0.0.1局域网用0.0.0.0OLLAMA_ORIGINSCORS 允许来源本地用*配合代理可按域名收紧OLLAMA_KEEP_ALIVE模型常驻内存时间5m或30m避免反复加载OLLAMA_NUM_PARALLEL并行处理请求数根据显存设1或4Windows 上改完环境变量后一定要重新启动 Ollama不是关掉窗口再开那种重启而是彻底退出进程后重新跑ollama serve。Linux 上用 systemd 管理的执行systemctl restart ollama。修改OLLAMA_HOST为0.0.0.0后局域网内其他设备就可以通过http://主机IP:11434访问了。如果你不希望局域网裸奔后面可以用 Nginx 做一层Basic Auth或自定义 Header 校验这个在第五章展开讲。3. “无输出”问题完整排查链路从 500 错误到上下文窗口前面这些配置做完正常应该能跑了。但如果你是第一次接入很可能遇到和我一样的情况WorkBuddy 显示模型已连接发送消息后转圈然后——什么都没有。这是整篇文章最核心的部分我按照当时排查的顺序把完整的链路拆给大家。3.1 现象复现已连接但就是不出字描述一下当时的现场WorkBuddy 模型列表里能看到qwen2.5:7b发一句“你好”状态变成“请求中”大约 20 秒后恢复空闲但聊天窗口里一个字都没有。有时候还会直接报超时错误。最诡异的是Ollama 的日志里明明能看见请求进来了模型也没有崩。这种“服务正常但没有输出”的情况排查入口不在 WorkBuddy而在 Ollama 本身。先别急着怀疑客户端把 WorkBuddy 晾在一边直接在终端用 Curl 打 Ollama 的原生接口。3.2 第一刀用 Curl 绕过 WorkBuddy直接验证模型推理执行下面这段命令看 Ollama 能不能正常返回完整响应curl http://127.0.0.1:11434/api/chat -d { model: qwen2.5:7b, messages: [{role: user, content: 你好请只说一句话}], stream: false }用stream: false是为了拿到完整 JSON 响应方便看清有没有报错字段。如果这里直接返回 500那就和 WorkBuddy 一点关系都没有问题出在 Ollama 或模型本身。如果这里输出正常说明 Ollama 侧没问题继续往 WorkBuddy 的方向查。我那次 Curl 测出来的结果就是经典的HTTP/1.1 500 Internal Server Error {error:llama-server process terminated}这个错误很典型值得单独拿出来说。3.3 500 internal server error: llama-server process 的根因llama-server process terminated意味着 Ollama 后端加载模型的原生进程崩溃了。常见原因有四类显存不够模型太大了GPU 装不下进程启动时直接被杀。7B 模型 Q4 量化最小需要 6 GB 左右显存Q8 量化需要 8 GB 以上。如果你的显卡只有 4 GB基本告别 7B 模型。解决办法是换更小模型3B、1.5B或者降低量化等级。num_ctx 参数超限上下文窗口设得太大KV Cache 占满显存也撑不住崩掉。有些客户端允许设置上下文长度你填了 32768 甚至更大模型就会直接在加载阶段崩溃。量化格式与当前版本不兼容某些社区魔改的 GGUF 文件在特定 Ollama 版本下会加载失败。解决办法是自己从 Hugging Face 拉官方 GGUF 写 Modelfile 重新创建模型或者换一个量化版本。驱动/后端问题Windows 上如果显卡驱动过老、OpenCL 或 CUDA 版本不对也会在加载时崩溃。排查这类错误第一件事是看 Ollama 的详细日志。Windows 的日志通常在%LOCALAPPDATA%\Ollama\server.logLinux 在~/.ollama/logs/server.log。用下面命令打开实时日志# Linux / macOS tail -f ~/.ollama/logs/server.log # Windows PowerShell Get-Content $env:LOCALAPPDATA\Ollama\server.log -Wait -Tail 50可以看到进程崩溃前最后的输出多半是CUDA error: out of memory或failed to allocate buffer之类的明确提示。解决方向就是减模型、减上下文、加显存预算。顺带提一个判断技巧如果崩溃前日志里出现较多call to cuInit或ggml_cuda字样大概率是 CUDA 环境有问题。可以在 Ollama 服务启动时加上OLLAMA_DEBUG1环境变量打印更细的日志定位会更精准。3.4 Curl 正常但 WorkBuddy 还是无输出检查请求参数和系统代理把 Curl 调通后回到 WorkBuddy 再次测试。如果此时依然是“转圈不出字”继续往下排查这几个点max_tokens 被设成 0 或极小值有些工具会把“最大输出长度”的默认值设得很小比如 1。模型刚生成一个 token 就被截断表现就是输出框空白。在 WorkBuddy 的模型参数里把最大输出调到 512 以上试试。系统提示词触发模型空回复本地小模型的指令跟随能力不如云端大模型如果你的 system prompt 设置了“只输出 JSON”“不要解释”之类的强约束小模型可能直接输出空字符串或内容被过滤。把 system prompt 删掉再试一次就能定位。上下文长度超限WorkBuddy 可能默认携带很长的系统消息或历史对话总 token 数一旦超过模型的 context windowOllama 在拼 prompt 时就会报错表现形式就是“请求成功但无输出”。设置里把上下文长度调小或者清空历史会话症状通常会消失。系统全局代理拦截了本地请求这是个非常隐蔽的坑。如果你系统里开着全局代理部分客户端会把127.0.0.1的请求也扔给代理转发代理自然无法连到你本地端口的服务请求静默失败或超时。排查方法在 WorkBuddy 里为本地地址配置直连或干脆全局代理里加一条127.0.0.1不走代理的规则。我那次“无输出”的最终原因就是第三条WorkBuddy 默认上下文开到了 8192而 qwen2.5:7b 官方推荐上下文是 4096实际能跑 8192 但显存吃紧推理速度降到几乎停滞看起来就是卡死无输出。把上下文降到 2048 后问题瞬间消失速度也上来了。这件事给我的启发是本地小模型不是“配置越大越好”要顺着它的能力边界去配。3.5 没有输出的潜在元凶模型在 CPU 上慢慢爬还有一种“看似无输出”的情况是模型根本没崩只是生成极慢。7B 模型纯 CPU 推理的速度大约在 1-3 tok/s一句 20 个字的话要 10 秒才蹦出来如果 WorkBuddy 的流式输出又没开成功你就只能干瞪眼看着它转圈。判断方法很粗暴打开任务管理器或nvidia-smi看 CPU 是不是满负载、GPU 显存有没有占用。CPU 拉满但显存为 0说明模型压根没进 GPU推理全在 CPU 上进行。如果是这种情况优先检查配置里有没有num_gpu或GPU Layers参数。Ollama 在 macOS 上自动用 Metal在 Windows/Linux 上通过 CUDA 调用 N 卡但有时自动检测会失效。手动指定# 临时测试强制全部层进 GPU OLLAMA_GPU_LAYERS999 ollama serve或者写进 ModelfileFROM qwen2.5:7b PARAMETER num_gpu 999配置完之后再用nvidia-smi确认显存有占用速度会立刻起飞。4. 从 8 tok/s 到 70 tok/s性能调优的每一次尝试模型能出字之后下一个让人抓狂的问题就是速度。最开始我只有 8 tok/s打字都有延迟根本没法愉快地当编程助手用。这一个章节就是我把速度拉到 70 tok/s 的完整过程每一步都有对应的参数和数据。4.1 选对模型的“甜点位”量化等级决定了下限本地模型领域有一句话叫“量化和损失挂钩但和体验成正比”。同一个模型Q8 量化效果最好但速度最慢、显存占用最高Q2 极致压缩但生成质量稀碎。对 WorkBuddy 这种日常辅助工具Q4_K_M是绝大多数人的最佳选择质量和速度的平衡点最好。我用同一个 7B 模型在同样的硬件上做了个简单对比量化等级模型体积显存占用推理速度 (tok/s)体感质量Q2_K2.6 GB3.1 GB约 28明显变笨逻辑混乱Q4_K_M4.7 GB5.8 GB约 70正常可接受Q8_07.6 GB8.9 GB约 52略好但感知不明显FP1615 GB16 GB约 20不推荐显存爆炸注意一个反直觉现象Q8 比 Q4 慢很多因为显存占用上涨后KV Cache 和计算缓冲都更紧张内存带宽才是瓶颈。如果你的显卡显存在 8 GB 以下7B 模型老老实实用 Q4_K_M不要迷信高精度。选择合适的模型后用以下命令拉取ollama pull qwen2.5:7b-q4_K_M ollama list如果你是 N 卡ollama list后跑一个ollama run qwen2.5:7b-q4_K_M实测一下原始速度如果原始速度就低得离谱说明硬件层还有问题先解决硬件再继续调。4.2 把 num_ctx 调到够用就行KV Cache 才是隐形吞速兽本地模型的速度瓶颈很大程度是 KV Cache 在拖后腿。num_ctx越大预分配的 KV Cache 越大每个 token 的注意力计算越慢曲线不是线性增长是超线性。默认 2048 增加到 8192相同模型速度可能直接掉一半多。对 WorkBuddy 的编程辅助场景单次交互的上下文其实不需要超长。代码片段加对话历史1024 到 2048 完全够用。我用 Modelfile 固定参数FROM qwen2.5:7b-q4_K_M PARAMETER num_ctx 1024 PARAMETER temperature 0.6 PARAMETER top_p 0.9然后创建自定义模型ollama create wb-qwen -f Modelfile之后在 WorkBuddy 模型名里填wb-qwen而不是原来的qwen2.5:7b。这个改动对速度的影响是立竿见影的num_ctx 从默认 4096 降为 1024 后我的速度大概提升了 25% 以上。4.3 keep_alive 与并发让模型常驻不要反复热启动Ollama 默认会在模型空闲 5 分钟后释放显存。如果你每次问一句话都要隔一段时间模型被释放后再次请求就会触发重新加载加载一个 5 GB 模型在 NVMe 上要花 15-30 秒这段时间 WorkBuddy 的表现依然是“无输出”。这也是很多新手误以为“又卡死了”的原因。解决思路是让模型常驻内存。两种方式一种是环境变量全局生效OLLAMA_KEEP_ALIVE30m另一种是请求时动态指定{ model: wb-qwen, keep_alive: 30m }我把 keep_alive 设为 30m 后半小时内连续对话都是秒响应。与此同时还可以把OLLAMA_NUM_PARALLEL调成 4让 WorkBuddy 可以同时处理几个并发请求比如一边在终端问问题一边在编辑器里做代码补全。显存如果够用并发带来的体感提升非常明显。注意一个平衡点显存只有 8 GB 的时候并发数设为 4 意味着 KV Cache 要分成 4 份每一份都会变小单个请求的推理反而会变慢。我的建议是显存 12 GB 以下用默认 112 GB 以上再去尝试并发。4.4 关闭思考过程Gemma、Qwen3 这类“爱啰嗦”模型的提速开关现在很多新模型默认带“思考过程”比如 Gemma3、Qwen3 的 thinking 模式会在回答前先输出一大段“推理内容”。这对复杂问题有帮助但对日常代码补全和常规问答来说纯属浪费时间直接把 tok/s 的一半花在了用户看不到的地方。关闭思考过程有两种办法。第一种是提示词层面在 WorkBuddy 的 system prompt 里加一句“不要输出思考过程直接给出最终答案”很多模型会听从。第二种更彻底选择非思考版本的分支模型比如qwen3:4b有默认思维链版本而某些知识库里的精简版默认关闭思考。如果你用的是支持reasoning_effort参数的模型可以在请求参数里手动把它设成none或minimal。这个动作对体感速度的影响往往是“翻倍”级别的我的实测从 35 tok/s 直接跳到 70 tok/s。4.5 硬件层面的最后几步内存带宽、NVMe、指令集软件调到极致后速度上限就交给硬件了。以下是我实测下来的硬件优化优先级确保模型真正跑在 GPU 上看nvidia-smi显存占用不为 0 且推理时显卡利用率有波动才说明是在 GPU 上算。如果只跑 CPU几百 TFLOPS 的算力就浪费了。显存不足时手动多层到 GPU比如OLLAMA_GPU_LAYERS35把 35 层放进显存剩下的层在 CPU 算。混合推理总比纯 CPU 快不少。内存双通道和频率CPU 推理吃内存带宽双通道 DDR4 3200 和单通道 DDR4 2666 的差距可能达到 40%。如果你无法上 GPU这点很关键。NVMe 固态硬盘模型加载快慢看硬盘推理快慢主要看显存和内存带宽。NVMe 能让 5 GB 模型的加载从 60 秒降到 20 秒体验差距巨大。我最终的稳定配置是这样的qwen2.5:7b-q4_K_Mnum_ctx 1024OLLAMA_KEEP_ALIVE30mnum_gpu 999 关闭思考过程在 RTX 3060 12G 上实测 68-72 tok/s。如果再把并发开成 4交互流畅度完全能当日常主力助手使用我甚至开始用它处理一部分代码 review。5. 接入之后要扩展的几件事skill 配置、多终端共用与知识库Ollama 本地模型接入 WorkBuddy 后真正的价值释放要从“能对话”升级到“能干活”。这个阶段我建议从三个方向切入。5.1 把常用流程固化成 skillWorkBuddy 的 skill 机制允许你把固定的提示词、操作步骤打包成一个可复用的功能块。比如我有一个“文献综述” skill把“请阅读以下论文列表按主题归纳每个主题给出 3 条关键观点”这类 prompt 固化下来输入论文列表就能直接触发。本地模型接入后让 skill 跑通的意义在于你可以把模型擅长的任务标准化不用每次都重新描述一遍需求。我的经验是本地小模型在“总结归纳”“代码解释”“模板生成”这类局部任务上表现稳定可以放心做成 skill但在“长文档逐章分析”这种需要大上下文的任务上小模型容易丢细节skill 里要预设“分段提取再合并”的流程效果才有保障。5.2 多客户端共用同一个 OllamaNginx 代理加 API KeyOllama 本身不带鉴权如果你让它监听0.0.0.0局域网里任何设备都能直接调用你的模型服务这在真实环境中是个不小的隐患。我现在的做法是在 Linux 服务器上用 Nginx 做反向代理加一层最基础的 Basic Authserver { listen 11435 ssl; server_name ollama.example.com; location / { proxy_pass http://127.0.0.1:11434; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; auth_basic ollama; auth_basic_user_file /etc/nginx/.htpasswd; } }这样 WorkBuddy、Cherry Studio、Dify 这些客户端都统一连http://ollama.example.com:11435/v1API Key 填 Basic Auth 的用户名密码组合对应的 token。表面上是多了一层配置但换来的安全性是值得的。如果你还想加 OpenAI 风格的 Bearer API Key可以用 Nginx 的auth_request模块写一个小接口做校验思路完全一致。Docker 部署方案里也推荐用这个架构Ollama 容器只暴露内网端口Nginx 容器对公网提供代理。docker compose一把梭迁移和回滚都方便。5.3 补一个本地向量模型做真正离线的知识库Hotword 里出现“本地向量模型”不是巧合。接入 Ollama 聊天模型只是第一步想让它回答你私有文档里的内容需要 embedding 模型 RAG。Ollama 上可以直接拉取nomic-embed-text或bge-m3这类向量模型ollama pull nomic-embed-text然后在知识库工具里把 embedding 模型的 base URL 指向 Ollama就能把 PDF、文献、代码库全部切成向量存在本地。整个过程不依赖任何外部服务完全离线。对做科研、写文献综述的场景这招比硬塞上下文靠谱得多——向量检索能把相关段落先捞出来喂给生成模型输出质量会高很多。提示本地向量模型和本地 LLM 的搭配是 RAG 的基础组合但 embedding 模型的参数如 chunk size、重叠大小对最终质量影响极大。建议阅读器里把 chunk 控制在 500-1000 token重叠 100-200 token检索效果最稳定。收尾的一点个人体会把 WorkBuddy 接到 Ollama 之后我连续用了一个多月最大的感受是本地模型的瓶颈从来不在“能不能用”而在“会不会调”。num_ctx、量化等级、keep_alive、思考过程开关这四个参数决定了你是“卡到怀疑人生”还是“60 tok/s 飞起”。如果你也卡在某个环节别急着怀疑工具按我上面的链路一步步看日志、用 Curl 拆开验证大概率能在半小时内定位。最后再分享一个小技巧每次改完 Ollama 参数后都先自己用 Curl 打一次确认正常再回 WorkBuddy 测试。永远不要把客户端当第一诊断工具它把太多底层错误吞成“无输出”了。
阅读完成 · 觉得有帮助？
