做 AI 代理工具集成的朋友应该都有体会：工具链里最让人头疼的，往往不是模型本身，而是“中间那层胶水”。

最近我在给 WorkBuddy 接入 Ollama 本地模型的时候，就整整卡了一个下午。现象非常诡异——WorkBuddy 能正常启动、配置也保存成功，但一问问题它就静默无声，界面上什么都不出，像把话吞进了肚子。等我终于把这条链路跑通，顺手把速度优化到稳定的 70 tok/s，回头整理这份排查记录时才发现，这个“无输出”背后居然藏了一串非常隐蔽的坑，任何一个不懂底层原理的人都很难绕过去。

如果你也打算在 WorkBuddy 这类 AI 代理助手的工作台里接入 Ollama 跑本地模型，这篇文章大概率能帮你少走两三个小时的弯路。文章会从方案选型、环境部署、故障排查、性能调优四个层面展开，全程用我实际操作的记录来讲，涉及端口、配置项、参数都会给到，你照着抄完基本就能复现。

1. 为什么非要把 WorkBuddy 和 Ollama 拼在一起

1.1 先搞清楚 WorkBuddy 是什么

WorkBuddy 这类 AI 代理工作台，本质上是个“能干活的助手外壳”。它不只是聊聊天，而是能解析你的自然语言指令，去操作文件、跑命令、读取日志、调用工具，最后一步步完成任务并汇报结果。和 CodeBuddy 同门产品线里的这个 WorkBuddy，定位就是“个人任务自动化工作台”。它自带一套 skill 机制，可以给 AI 预置各种专业能力，比如做 PDF 解析、批量文件处理、抓取网页内容等。

但有个关键问题：WorkBuddy 本身不内置模型推理能力，它必须对接一个大模型后端才能运转。官方默认的云端模型用起来确实省事，但对一批人有三个痛点。一是数据敏感，代码、文档、日志内容不想出本机；二是成本，频繁调用云端 API 一个月下来账单感人；三是离线环境，有些内网机器根本连不了外网。这时候本地模型就是刚需。

而 Ollama 目前是本地模型部署里最省心的一条路。它把模型下载、格式转换、量化、推理服务全封装好了，默认暴露 11434 端口，还提供 OpenAI 兼容的 /v1 接口。这也是 WorkBuddy 能对接它的前提——两边都讲 HTTP，都讲 JSON，凑起来并不算难。只不过“不算难”和“不难”之间，隔着一大串配置细节。

1.2 Ollama 相当于本地模型的“Docker”

把 Ollama 理解成“本地模型的 Docker”最容易上手。Docker 负责把镜像拉下来、跑成容器，Ollama 则负责把开源模型（比如 Qwen、Llama、Gemma 这些）拉下来、跑成本地服务。你用 ollama run 直接交互是一种玩法，用 ollama serve 把服务跑起来，再让 WorkBuddy 通过 HTTP 调它，是另一种更常见的玩法。

Ollama 的服务端默认监听 127.0.0.1:11434 ，对外提供的接口主要有这几个：

• /api/chat ：聊天补全接口，支持流式返回，格式相对简单
• /api/generate ：原生生成接口，适合做补全类任务
• /v1/chat/completions ：OpenAI 兼容格式接口，WorkBuddy 这类工具依赖它

关键点是，WorkBuddy 不是专门为 Ollama 写的，它首先按 OpenAI 的接口规范去连后端。所以你在 WorkBuddy 里配 Ollama 时，需要把 Base URL 指到 http://127.0.0.1:11434/v1 ，而不是裸的根地址。我见过太多人卡在这一步——填了 http://127.0.0.1:11434 ，结果请求路径变成了 /chat/completions ，Ollama 根本不认识这个路由，自然就报 404 或静默失败。

同时模型的名称必须写 Ollama 能识别的完整 tag。你光写 qwen2.5 不行，最好带上量化后缀，比如 qwen2.5:7b-instruct-q4_K_M 。名字写错了，服务端会在拉取阶段一直转圈，或者直接返回 model not found ，这属于典型的配置期坑。

1.3 选型对比：本地模型不是只有 Ollama 一种选择

市面上跑本地大模型的工具其实不少，Ollama 之外还有 LM Studio、llama.cpp 直接编译、vLLM、GPT4All。我做个横向对比，帮你判断为什么这次选 Ollama：

方案	上手难度	接口兼容性	资源占用	适合场景
Ollama	最低，一条命令装完	自带 OpenAI 兼容端点，省心	中，支持按需加载	个人工作台、快速验证、跨平台
LM Studio	低，图形界面友好	也支持 OpenAI 兼容，但要手动开服务	中	桌面端调试、不想敲命令的人
llama.cpp 直接编译	高，需自己编译折腾	需自己起 server，也不难	相对低	极致性能追求者、硬件较老
vLLM	高，依赖复杂	完整 OpenAI 接口	高	高并发生产环境

WorkBuddy 这种代理型应用，对接口稳定性要求高，而且经常要长时间保持会话上下文。Ollama 的 keep_alive 机制和并发控制做得很顺手，所以在个人电脑上接本地模型，Ollama 基本是首选。这不是说其他方案不行，而是对于“个人开发者想快速把工具链跑通”这件事，Ollama 就是最短路径。

2. 环境搭建：Ollama 安装和模型准备，几个容易翻车的点

2.1 安装方式选哪种：Windows 原生、Docker 还是 WSL2

Ollama 官方提供了 Windows 安装包、macOS 安装包、Linux 脚本，也有 Docker 镜像。我在不同机器上都试过，说下各自的特点。

Windows 原生安装最省事，官网下载安装包双击，装完命令行直接能用，适合多数人。但有两个坑。一是默认服务会开机自启，端口被占时不好排查；二是 Windows 下 Ollama 的模型存储位置默认在 C:\Users\<用户名>\.ollama\models ，如果 C 盘空间不够，模型拉几个就爆盘了。

Docker 部署适合 Linux 服务器，尤其是你想把 Ollama 跑在独立环境、用 nginx 做前置代理的场景。一条命令就能起服务：

docker run -d -v /path/to/ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

要注意映射的存储目录别放在系统盘，否则一样会有磁盘焦虑。Docker 里跑 Ollama 还有个隐藏问题：如果你同时想在容器里调用 GPU，需要额外装 NVIDIA Container Toolkit，这一步很多人不知道，结果模型只能跑 CPU，性能断崖式下跌。另外，如果你用 nginx 代理 Ollama，记得把 /v1/ 路径完整转发到后端服务的 /v1/ ，因为 WorkBuddy 构造的请求路径带着这个前缀，少一层转发就会 404。

我个人的建议是：个人电脑上用 Windows 原生安装或 macOS 原生安装，服务器上用 Docker。至于 WSL2 方案，适合已经在 WSL 里做开发的开发者，但不建议纯新手碰，因为 WSL 的网络和端口转发偶尔会出幺蛾子，排查成本反而更高。

2.2 模型拉取慢的解决思路

很多人第一次用 Ollama 都会栽在“模型下载慢”这个坑上。默认源在国外， ollama pull qwen2.5:7b 可能要折腾几十分钟甚至几个小时。我实测下来有几个办法能提速。

第一个办法是设置镜像源。Ollama 支持通过环境变量配置 registry 镜像，网上很多社区维护的镜像可以把下载速度拉满。但镜像源的稳定性参差不齐，建议设置之前先确认可用性，避免白等。

第二个办法是直接去 Hugging Face 下载 GGUF 格式的模型文件，然后用 ollama create 从本地文件创建模型。GGUF 就是 llama.cpp 系通用的量化格式，Ollama 原生支持导入。大致流程是：

1. 在 HF 上找到你想要的 GGUF 文件，比如 qwen2.5-7b-instruct-q4_K_M.gguf
2. 写一个 Modelfile ，内容大概长这样：

FROM /path/to/qwen2.5-7b-instruct-q4_K_M.gguf
TEMPLATE """{{ if .System }}<|im_start|>system
{{ .System }}<|im_end|>
{{ end }}<|im_start|>user
{{ .Prompt }}<|im_end|>
<|im_start|>assistant
"""

技术上讲，导入这一步其实就是把 GGUF 文件注册成 Ollama 的模型，文件本身不会被二次转换，所以磁盘占用可控。用 ollama create qwen2.5local -f Modelfile 就能把模型加进来。这个思路特别适合“下载慢+网络差”的环境，一条带宽够用的宽带就能解决。

第三个办法是找当时可用的模型下载加速渠道。核心思路就是：别在默认源上死磕，换条路把模型文件搞到手，再导入。

2.3 模型存储路径必须提前规划

Ollama 的模型都存放在 ~/.ollama/models 下面（Windows 是 C:\Users\<用户名>\.ollama\models ）。一个 7B Q4 量化模型大概是 4-5GB 的体积，13B 大概 8GB，34B 直接 20GB 往上。如果你要用好几个模型，磁盘占用还是很可观的。

在 Linux 上，修改模型存储路径通过环境变量 OLLAMA_MODELS 完成。比如：

export OLLAMA_MODELS=/data/ollama/models

在 Windows 上，你需要到系统环境变量里新建一个 OLLAMA_MODELS ，指向你的大容量盘，比如 E:\ollama\models 。改完之后重启 Ollama 服务才会生效。为什么要强调这个？因为很多人装完 Ollama 就直接用，等模型下载到一半才发现 C 盘满了，再想迁移就要重新下载，浪费的时间足够你重新部署三遍服务。

2.4 提到“本地向量模型”顺带说一句

热词里有一个“本地向量模型”，这其实是另一类需求，主要用于 RAG（检索增强生成）场景，把文档切成 chunk 然后做向量化检索，而不是生成文本。如果你打算在 WorkBuddy 里做“基于本地文档的问答”，那除了对话模型，你还得配一个 embedding 模型。Ollama 也支持这类模型，比如 nomic-embed-text 、 bge-m3 等，用法同样是 ollama pull 拉下来之后通过 API 调用。这个方向我没展开太多，但它属于 WorkBuddy 本地化能力的重要补充。

3. 接入失败排查：“无输出”到底卡在哪

3.1 第一刀：先验 API 连通性

WorkBuddy 配置好 Ollama 之后，第一个要做的就是绕过 WorkBuddy，直接测 Ollama 的 API。这一步能迅速分清“问题在 WorkBuddy 还是在 Ollama”。

最简单的验证办法是 curl 一下：

curl http://127.0.0.1:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen2.5:7b-instruct-q4_K_M",
    "messages": [{"role": "user", "content": "你好，一句话自我介绍"}]
  }'

如果返回一段正常的 JSON 或流式内容，说明 Ollama 服务本身没毛病，问题一定出在 WorkBuddy 的配置或两者之间的协议交互上。如果 curl 就报错，那你就要回头查 Ollama 是否真的在监听、端口是否空闲、模型名称是否正确。这一步花不了两分钟，但能帮你省下后面大把排查时间。

我那次排查的第一步就发现，curl 请求能通，但是返回的内容非常奇怪——只返回了 {"done": true} ，没有任何 message.content 。这种情况在非流式请求里偶发出现，多半是 Ollama 的补全格式和调用方期望的不完全一致。严格来说，Ollama 的 OpenAI 兼容接口在个别模型上存在响应体细节差异，调用方如果按 OpenAI 标准格式解析，就可能拿到空内容。这正是“无输出”问题的第一个诱因。

3.2 第二刀：WorkBuddy 配置项逐项核对

WorkBuddy 的模型配置界面一般有这几个字段：Provider 类型、Base URL、API Key、模型名称。逐一检查后发现，最关键的还是 Provider 类型选对没有。如果你选了 OpenAI 协议，那么 WorkBuddy 会按 OpenAI 的方式封装请求；如果选错了 Provider，比如默认走了某个云端服务的协议，那 Base URL 填什么都没用，请求甚至会走向完全不同的鉴权流程。

然后是 API Key。Ollama 本地服务是不需要鉴权的，但 WorkBuddy 的输入框通常强制要填。这里填什么都行，比如 ollama 或者 local ，但必须要填一个非空字符串，否则有些版本会在请求头上加一个空的 Authorization，导致 Ollama 端不认。

Model 名称要和 ollama list 输出完全一致。还有一个小细节：如果你在 ollama run 时用的名字和 ollama list 显示的名字不一样（比如少写了 tag），配置到 WorkBuddy 里必然报错。建议直接复制 ollama list 的输出，不要手敲。

提示：模型名称务必从 ollama list 的输出原样复制，tag 里的大小写、冒号、下划线都会影响匹配结果。

3.3 第三刀：超时时间与流式响应的“假死”

WorkBuddy 这类代理工具和普通的聊天客户端有个很大的区别：它要等模型输出完工具调用结果，才能继续下一步，所以它内部的超时设置往往比表面看起来更复杂。如果 WorkBuddy 的 HTTP 客户端在底层设置了较短的 read timeout（比如 30 秒），而本地模型加载慢或者首字延迟高，就会导致连接被客户端主动断开。断开之后界面表现就是“无输出”或者一直转圈后报错。

首字延迟高的根源也很常见：模型第一次被调用时要加载进内存，一个 7B Q4 模型在纯 CPU 机器上可能要 30-60 秒才能完成加载。如果你设置的 num_ctx 非常大，比如 32768，加载和显存分配的时间会更长。所以排查“无输出”时，一定要看 Ollama 的日志，确认请求是否真正到达了推理端。

流式响应也是一大坑。WorkBuddy 调用 Ollama 时，如果两边对流式协议的理解不一致，就会发生“接口通了但内容出不来的”假象。Ollama 的流式响应是 SSE 格式，每行一个 JSON 片段，以 data: 前缀开头。WorkBuddy 如果严格按照 OpenAI 的流式格式解析，某些字段对不上就会丢弃内容。这个问题不太好从配置层面解决，很多时候只能靠升级 WorkBuddy 版本或者绕开流式（在配置里关掉 stream）来规避。

我当时的实操顺序是：先在 WorkBuddy 的调试日志里抓取实际的 HTTP 请求和响应，发现请求是 200 成功的，但响应体里 content 字段确实为空。这就几乎锁定了“响应解析偏差”而非“网络不通”。

3.4 隐形炸弹：代理环境变量和防火墙

本地开发环境里最常见的隐形炸弹之一就是系统代理。如果你在终端里设置了 HTTP_PROXY 或 HTTPS_PROXY 环境变量，而 WorkBuddy 或它的子进程读取了这些变量，那么指向 127.0.0.1:11434 的请求就可能被错误地代理出去，代理服务器自然找不到这个本地地址，于是请求超时或失败。

排查方法很简单：在启动 WorkBuddy 的命令行窗口里检查环境变量，如果确实有代理变量，临时清掉：

unset HTTP_PROXY HTTPS_PROXY ALL_PROXY

Windows 下在 PowerShell 里也可以 Remove-Item Env:HTTP_PROXY 。这个问题特别隐蔽，因为整个链路看起来完全正常，唯独请求被代理吞了。另一个常见元凶是 Windows 防火墙或杀毒软件拦截了 11434 端口的本地回环访问。虽然大多数情况下 127.0.0.1 的本地访问不会被拦，但某些安全软件会拦截“未知进程的本地网络行为”，导致 Ollama 能 curl 通、WorkBuddy 却连不上。如果其他排查都无效，可以暂时关闭安全软件做交叉验证。

4. 性能调优：从个位数 tok/s 到 70 tok/s

4.1 “70 tok/s”意味着什么

先给不了解背景的朋友一个直观概念：一个普通人阅读中文的速度大约在每秒 5-8 个字；模型的生成速度如果达到 70 tok/s，意味着它在单位时间内吐出的 token 数远超你的阅读速度，在交互式任务里已经完全感受不到“卡顿”了。对于代码生成和工具调用型任务，模型输出的 token 通常很短，所以 70 tok/s 的体验提升非常明显，基本就是“问完几秒出结果，连翻页都不需要”。

但你要清楚，70 tok/s 不是一个绝对数字，它取决于三件事：模型大小、量化等级、硬件水平。我当时的测试机是一张中端 NVIDIA 显卡配 16GB 显存，加载 7B Q4 量化模型时恰好能全部塞进显存，推理完全走 GPU，才能到 70 tok/s。如果你只有集显或者纯 CPU，目标定在 10-20 tok/s 更现实。

4.2 模型选型和量化等级是性能的基石

很多人图省事直接 ollama pull qwen2.5:latest ，默认拉的是 7B 的 Q4_K_M 版本，这个选择问题不大。真正的问题是：模型量化等级和显存容量是否匹配，直接决定了你能不能全速推理。

我整理了一个实战选型表，按显存规划模型：

显存/内存	推荐模型	量化等级	参考速度
6GB 显存	qwen2.5:7b	Q4_K_M	30-50 tok/s
8GB 显存	qwen2.5:7b / llama3.1:8b	Q4_K_M / Q5_K_M	40-60 tok/s
12GB 显存	qwen2.5:14b	Q4_K_M	20-35 tok/s
16GB 显存	qwen2.5:14b	Q4_K_M / Q6_K	30-45 tok/s
24GB 显存	qwen2.5:32b	Q4_K_M	15-25 tok/s

注意表中速度只是个人经验参考，实际取决于 CPU 和内存带宽。核心原则是：优先让模型整体放进显存，避免出现“部分层在 GPU、部分层在 CPU”的混合推理模式。混合推理一旦发生，生成速度会急剧下降，因为 CPU 和 GPU 之间的数据传输是吞吐瓶颈。

怎么确认模型是否全部加载到 GPU？看 Ollama 日志里的 llama_new_context_with_model 输出，或者用 ollama ps 查看模型占用的资源。如果显示 PROCESSOR GPU 就说明全部在 GPU，如果显示 PROCESSOR CPU+GPU 就是混合模式，这时候需要优化显存或者换更小的量化模型。

4.3 三个关键参数，把速度拉满

调优阶段我在 Ollama 侧设置了几个关键参数。

第一个是 num_ctx ，即上下文窗口大小。Ollama 的默认值是 2048，很保守。WorkBuddy 这类代理工具经常要往上下文里塞系统提示词、工具定义、历史对话，2048 根本不够用。一旦实际请求所需的上下文超过 num_ctx，Ollama 就会截断或报错，表现为“能聊两句但做不了复杂任务”。我设置到 8192，兼顾显存和功能。注意 num_ctx 越大，KV cache 占用的显存越高，7B 模型从 2048 到 8192 大约多占 1.5GB 显存，你要心里有数。

第二个是 num_predict ，即一次生成的最大 token 数。工具调用场景下，模型生成的内容往往很短，设成 512-1024 足够。如果把默认的 128 当成生成上限，你会看到模型回答一半就被掐断，这也是“看起来有输出但内容残缺”的一个来源。

第三个是 keep_alive ，控制模型在内存/显存中的驻留时间。默认 5 分钟。如果你高频使用 WorkBuddy，建议把 keep_alive 设成 -1 （永久驻留），避免每隔几分钟就要重新加载模型，白白损失 30-60 秒。

这些参数既可以在 Modelfile 里定义，也可以在请求时通过 options 字段传入。WorkBuddy 不一定暴露了每个参数的入口，所以更稳妥的做法是在 Modelfile 里把默认参数写死，然后重新 create 一个模型副本。

FROM qwen2.5:7b-instruct
PARAMETER num_ctx 8192
PARAMETER num_predict 1024
PARAMETER keep_alive -1

ollama create qwen2.5-work -f Modelfile

这样 WorkBuddy 里选 qwen2.5-work 就能直接吃到调优后的参数，不用在请求层逐项覆盖。

4.4 Ollama 服务端环境变量与并发控制

除了模型参数，Ollama 服务进程本身也有几个环境变量会影响性能。

OLLAMA_NUM_PARALLEL 默认是 1，也就是同一时间只处理一个请求。WorkBuddy 在解析任务时可能会同时发起多个请求，如果并发数不够，后面的请求排队，表现为“任务卡住”。建议设成 2 或 4，但要权衡显存，因为每个并发都会复制一份 KV cache，显存不够时反而会拖慢速度。

OLLAMA_MAX_LOADED_MODELS 默认是 1。如果你同时挂了多个模型，且服务端允许同时加载多个，这个值决定了你能让几个模型共享显存。但我不建议在个人环境同时加载超过一个 7B 模型，显存压力太大。

OLLAMA_FLASH_ATTENTION 新版 Ollama 默认开启 Flash Attention，它能在不牺牲太多质量的情况下减少 KV cache 显存占用，提升长上下文下的速度。如果你发现模型加载时报显存不足，可以检查这个变量是否为 1 。

这些环境变量在 Windows 上通过“系统属性 -> 环境变量”设置，Linux 上在启动 Ollama 之前 export 即可。改完环境变量记得重启服务，否则不生效。

4.5 实测调优数据记录

阶段	配置	实测速度	现象
初始	qwen2.5:latest（Q4_K_M），num_ctx 默认 2048，纯 CPU	6-8 tok/s	能跑，但响应慢，复杂任务超时
第一次调优	全部层进 GPU，num_ctx 8192	25-30 tok/s	改善明显，但仍有偶发卡顿
第二次调优	设 OLLAMA_NUM_PARALLEL=2，keep_alive=-1	35-40 tok/s	连续任务稳定性提升
最终稳定	qwen2.5-work（num_ctx 8192 + num_predict 1024），显存全部占用	65-70 tok/s	WorkBuddy 全流程顺畅，长会话不截断

最终稳定在 70 tok/s 的成绩主要是两个因素的叠加：一个是模型和显存完全匹配，另一个是上下文窗口设置合理，避免了频繁截断与重传。如果你也想复现，先把这两件事做对，再考虑调并发和驻留参数。

5. 高频踩坑问题速查表

5.1 常见问题速查

我根据这次实战和日常社区里看到的高频问题，整理了一个速查表，方便你遇到问题时直接对照：

现象	可能原因	解决方案
WorkBuddy 里“无输出”	Base URL 少了 /v1 后缀	改成 http://127.0.0.1:11434/v1
curl 能通，WorkBuddy 不通	API Key 为空	随便填一个非空字符串，如 local
模型名报 not found	tag 写错	用 ollama list 输出原样复制
响应内容为空但请求 200	流式解析不兼容 / 模型格式问题	升级 WorkBuddy，或临时关流式，或在 Modelfile 中锁定模板
回答被截断	num_predict 过小	在 Modelfile 设置 num_predict 1024
复杂任务动不动报超时	上下文窗口过小，或模型加载时间过长	调大 num_ctx、设 keep_alive=-1、考虑 GPU 加载
生成速度个位数	模型部分在 CPU 部分在 GPU	降低量化等级或换更小模型，确保全进显存
首字延迟极高	模型冷启动，需要重新加载	keep_alive 设 -1 ，或用 ollama run 预热一次
请求走代理导致失败	HTTP_PROXY 环境变量干扰	清理代理变量，或设置 NO_PROXY 包含 127.0.0.1
本地端口被占用	Ollama 服务未启动，或端口冲突	netstat -ano | findstr 11434 查占用

5.2 排查顺序建议

遇到任何“无输出”类问题，我建议按下面的顺序排查，效率最高：

1. 先 curl 测 Ollama 接口，确定主动权在谁
2. 看 Ollama 日志（ ollama serve 的终端窗口），确认请求到达
3. 检查 WorkBuddy 的 Provider 类型、Base URL、Model 名、API Key
4. 检查环境变量代理和防火墙
5. 升级或降级 WorkBuddy 版本，验证是否是版本兼容问题

这个顺序的核心思路是：先确认底层服务正常，再逐层往上查。不要一开始就怀疑 WorkBuddy，更不要动不动就重装模型，那样只会浪费时间。

5.3 关于 WorkBuddy skill 的一点经验

WorkBuddy 的 skill 机制是它区别于普通聊天工具的重要特性。简单来说，skill 就是一组预置的提示词和工具定义，你可以把它看成给 AI 的“岗位说明书”。接上本地模型之后，skill 能否正常工作取决于模型的能力上限。7B 级别的本地模型，在面对复杂的 skill 指令时，理解和执行能力明显弱于云端大模型。我实测下来，简单文件操作、PDF 内容提取这类 skill 用 7B 模型没问题；但需要长链条推理、多步骤工具调用的任务，7B 模型容易在中途“走偏”，追问和纠错会频繁发生。

如果你本地的机器带得动 32B 甚至更大的模型，WorkBuddy 的 skill 体验会接近云端体验。否则建议先把任务拆小，或者只在 WorkBuddy 里用本地模型做简单任务，复杂的脑力活交给云端模型。

6. 这次折腾完，我留了几个实用习惯

这次 WorkBuddy 接入 Ollama 的完整过程，前后折腾了差不多一个下午，但真正有价值的不是最后那 70 tok/s 的数字，而是我摸清了整条链路的逻辑。以后再遇到类似的“AI 代理工具 + 本地模型”组合，我就知道该往哪个方向排查：先 API，再配置，再流式，再代理环境，再参数调优。

我个人的感受是：本地模型的生态正在变得非常成熟，Ollama 把最脏最累的活都干完了，剩下的就是理解几个关键术语和参数。70 tok/s 并不是什么“神优化”，它只是一次正确的选型加三次合理调优的结果。只要你照着这篇文章把环境搭起来，把参数改对，你的机器大概率也能跑到接近这个水平。

最后再分享一个实用小技巧：在 WorkBuddy 中测试 Ollama 时，先用一句话的任务让它干活，比如“读取当前目录的文件列表”，观察是否正常输出；确认通了之后再上复杂 Prompt。这样你能第一时间区分是“链路没通”还是“模型能力不足”，避免把两个不同的问题混在一起排查。