企业官网建设流程全解析

把 WorkBuddy 接到本地 Ollama 模型，是我最近折腾下来最有成就感也最崩溃的一件事。说崩溃，是因为配置完成、界面一切正常、模型也明明加载成功了，结果在对话窗口里发一句话过去，转圈半天什么都吐不出来——这种“无输出”的状态，碰过的人都懂。说成就感，是因为后面一步步排查、一个参数一个参数地调，把生成速度从最初的二十多 tok/s 一路拉到 70 tok/s 上下，整条链路彻底跑通，那种感觉确实不错。

这篇文章就把我的完整实操记录整理出来，包含 WorkBuddy 与 Ollama 的接入配置、无输出问题的定位思路、性能调优的具体动作，还有一份常见问题速查表。如果你正在研究“本地模型 + AI 工作台”这套玩法，或者正准备把 WorkBuddy 接上 Ollama，可以直接照着我这份流程走，能少踩好几个坑。

1. 接入前的准备：先把 WorkBuddy 和 Ollama 的角色想清楚

1.1 WorkBuddy 到底需要一个什么样的后端

在动手之前，先把两者的关系理顺。WorkBuddy 本身不跑模型推理，它承担的是“前端对话、上下文管理、任务编排、工具调用”这些活，真正出内容的还是后端的大模型。所以接入 Ollama，本质上就是在 WorkBuddy 的“模型后端”配置里，指向一个本地地址，让它把请求发到 Ollama 上跑模型。

这里想清楚一点很重要：WorkBuddy 对后端只有一个最基本的要求——兼容 OpenAI 风格的接口协议。它不关心你是用云端 API、内网部署的推理服务，还是本地跑一个 Ollama，只要接口长那个样子就行。Ollama 从很早的版本就提供了兼容 OpenAI 的/v1/chat/completions接口，所以两边对接非常顺。

我之所以选本地模型，主要是两个原因：一是数据敏感，写代码、整理文档的时候不想把所有内容都丢到云端；二是我经常在无外网、弱网环境下干活，本地模型不需要等网络往返，零延迟起步。如果你也有类似的诉求，WorkBuddy + Ollama 的组合就是一个非常合理的落地方式。

1.2 为什么是 Ollama，而不是 LM Studio、vLLM 或云端 API

我知道你可能会问：本地推理方案那么多，为什么偏偏选 Ollama？这几类我都试过，说下我的直观感受。

LM Studio 的图形界面确实友好，适合新手拖拽式下载模型、点按钮启动服务，它的 API 也兼容 OpenAI。但对我来说，它更适合“临时体验”，无头模式、批量管理、命令行自动化这些能力不如 Ollama 顺手。vLLM 和 sglang 是面向高吞吐在线服务的推理框架，性能上限高，但依赖重、部署步骤多，本地单机用属于杀鸡用牛刀，折腾成本完全划不来。而 Ollama 的优势是轻量、模型管理方便、一条命令拉模型、一条命令起服务，同时原生带 OpenAI 兼容 API，几乎就是为“个人本地模型服务”这个场景设计的。

云端 API 我也长期用，优点是省心、模型强，但每月的 token 消耗账单、数据外发的问题，始终是个坎。接入 Ollama 之后，我至少可以把日常琐碎的、不敏感的请求留在本地，只把真正复杂困难的任务发给云端——Hybrid 混用，既省钱又灵活。

1.3 安装阶段的三个常见坑：下载慢、存储路径、离线导入

先说下载。Ollama 官网的安装包在国内网络环境下经常下到一半就断，进度条形同虚设。我的建议是别傻等，直接去 GitHub Releases 页面手动下载离线安装包——Windows 下是OllamaSetup.exe，Linux 下是.tar.gz或官方安装脚本，下载完成后本地执行即可。这种方式比命令行拉取要可控很多，至少你能看到真实的下载进度，中断了也能断点续传重试。

第二个坑是模型存储路径。Ollama 默认会把模型放在~/.ollama/models，如果你跟我一样系统盘空间紧张，装两个 7B 模型基本就报警了。Linux 下我是这么处理的：先建一个独立的模型目录，再通过环境变量OLLAMA_MODELS指过去，修改后重启 Ollama 服务。Windows 上同理，在系统环境变量里新建OLLAMA_MODELS，指向你有空间的盘符。

还有一个容易被忽略的场景：离线环境导入自己的 GGUF 模型。方法是写一个 Modelfile，里面写一行FROM /path/to/your-model.gguf，然后执行ollama create your-model -f Modelfile。Ollama 会自动把 GGUF 变成可管理的本地模型，整个过程不需要联网。这个技巧在有内网机器、没办法直接ollama pull的时候非常实用。

2. 接入配置全流程：让 WorkBuddy 真正“看见”本地模型

2.1 拉起 Ollama 服务并预加载模型

Ollama 安装好之后，先确认服务在跑。Linux 下如果用的是 systemd 管理，服务通常已经常驻；如果手动启动，就在终端跑ollama serve，看到类似Listening on 127.0.0.1:11434的日志就是正常了。这里有个隐藏点：默认情况下 Ollama 只监听127.0.0.1，也就是只能本机访问。如果你打算从局域网内其他机器连这台机器的 Ollama，或者 WorkBuddy 跑在另一台设备上，需要设置OLLAMA_HOST=0.0.0.0:11434再重启服务。

接着拉模型。我建议第一次先用一个小模型打通流程，比如qwen2.5:3b，验证没问题之后再换主力模型。拉取命令很简单：

ollama pull qwen2.5:3b

拉完之后顺手跑两个命令确认状态：ollama list看模型列表，ollama ps看当前加载到内存的模型。这里有个经验之谈：先手动ollama run qwen2.5:3b预热一次，让模型真正加载进去，再回 WorkBuddy 里测试。因为模型首次加载会有明显的冷启动延迟，如果不预热，WorkBuddy 那边第一次请求等了十几秒没反应，很容易误判成“无输出”。

2.2 WorkBuddy 连接参数到底怎么填

WorkBuddy 里接入模型后端的配置项基本是固定的几个字段。Base URL 填http://127.0.0.1:11434/v1，注意一定带/v1后缀。模型名要填ollama list里显示出来的完整名字，比如qwen2.5:3b，注意 tag 不能漏，qwen2.5和qwen2.5:3b在 Ollama 里是两个东西。API Key 这一栏就比较有意思了——Ollama 默认不校验鉴权，理论上填什么都能过。

不过在真实使用中，API Key 我建议还是填一个固定值。原因有两个：一是有些工具在 Key 为空的时候会直接拒绝保存配置；二是如果你后续在 Ollama 前面加了一层 Nginx 反向代理做鉴权，这个 Key 就会真正用上。提前把习惯养好，后面迁移不折腾。

还有一个细节要注意：很多工具默认会拼https://，如果你 Base URL 填的是http://127.0.0.1:11434/v1但工具强制走 HTTPS，就会连不上。遇到这种情况，先把工具里的协议设置改成 HTTP，确认能通之后再考虑要不要用 HTTPS 代理。

2.3 用 curl 验证链路，别傻等界面反馈

这步是我这次最大的经验教训：不要在配置完 WorkBuddy 之后直接去界面里点发送，然后盯着转圈发呆。正确的做法是先用 curl 把接口打一遍，确认后端没问题，再去界面上做集成测试。

我建议按顺序执行下面三条命令：

# 查看 Ollama 本地模型列表 curl http://127.0.0.1:11434/v1/models # 直接调用聊天接口，不走流式 curl http://127.0.0.1:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model":"qwen2.5:3b","messages":[{"role":"user","content":"你好"}],"stream":false}' # 走流式接口，观察输出分片 curl http://127.0.0.1:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model":"qwen2.5:3b","messages":[{"role":"user","content":"你好"}],"stream":true}'

第一条返回模型列表，说明服务活着；第二条返回完整的 JSON 响应，里面有choices字段和生成的内容，说明普通调用正常；第三条会看到一段一段的流式输出，这模拟了 WorkBuddy 实际使用时的场景。三条都通过，你再去 WorkBuddy 界面里测，问题范围就已经被锁死在客户端配置了。

2.4 顺手解决“模型爱思考”的问题

现在不少模型默认会输出推理过程，也就是在正式回答之前先来一段“思考”内容，像reasoning或者thinking标签里那串文字。在 WorkBuddy 这种工具场景里，思考过程偶尔看看还行，每次都带着就很影响使用体验，输出也显得啰嗦。

关闭思路有三种。第一种最简单：在 WorkBuddy 的系统提示词里明确要求“直接给出最终答案，不要输出任何思考过程或分析步骤”，大部分模型都会遵守。第二种是给模型做一个定制 Modelfile，把模板里的思考标签去掉，重新创建模型。第三种适用于个别支持开关的模型，比如 Qwen3 系列的 API 参数里可以传"think": false关闭思考模式。

具体用哪种取决于你的模型。如果你只是拿 WorkBuddy 做日常问答和代码辅助，我推荐先试第一种，零成本，效果立竿见影；如果发现某些模型不听话，再考虑用 Modelfile 做定制。

3. “无输出”问题深度复盘：沉默背后的几种真凶

3.1 先分清：请求根本没出去，还是响应流断了

“无输出”看起来是一个现象，实际可以拆成好几类，不分类就开始瞎排查是最浪费时间的。我自己遇到过三种情况。

第一种是点发送之后秒报错，提示连接失败、超时之类——这是典型的请求没出去，问题在网络层或服务端。第二种是界面看起来在正常转圈，转了很久然后提示超时——这说明请求可能已经发出去了，但服务端没在预期时间内返回，问题可能在模型加载、上下文过大或代理拦截。第三种最迷惑人：界面显示有响应了，也有内容结构，但正文是空的——这是链路通了，但响应格式解析出了问题。

我的建议是从前往后查：先用 curl 确认后端正常，再看 WorkBuddy 侧的请求有没有真的发出，最后排查网络代理和返回格式。把这个顺序定下来，排查效率能高一大截。

3.2 网络层排查：端口、监听地址、系统代理这三座大山

网络层是最容易出问题的地方。先看端口，确认 11434 真的在监听。Linux 下用ss -tlnp | grep 11434，Windows 下用netstat -ano | findstr 11434。端口被占用的情况在 Windows 上尤其多，我之前装过某些开发工具会抢 11434 端口，导致 Ollama 服务压根起不来，但界面还傻傻以为它在跑。

再看监听地址。如果你用 Docker 跑 Ollama，或者把 OLLAMA_HOST 设成了0.0.0.0，那么从本机访问127.0.0.1:11434和从局域网访问机器IP:11434行为是不一样的。WorkBuddy 里填的 Base URL 必须和 Ollama 实际监听的地址对得上。

第三个坑是系统代理。这个很隐蔽：WorkBuddy 有时候会读取系统的 HTTP 代理设置，把本该发给 localhost 的请求也交给代理服务器去转发，代理服务器处理不了本地地址，结果就是要么超时要么返回一堆看不懂的错误。遇到这种情况，在系统代理设置里把localhost、127.0.0.1加入绕过列表，或者直接在无代理模式下测试一次，基本就能定位。

3.3 跨域与鉴权：本地服务也有拦路虎

如果你的 WorkBuddy 是桌面客户端，一般没有跨域问题；但如果用的是 Web 版本，浏览器同源策略就是一道硬关卡——前端页面从某个域名发起请求到127.0.0.1:11434，跨域了，请求会被浏览器拦截。

Ollama 专门提供了OLLAMA_ORIGINS环境变量来放行跨域来源。我当时的处理方式是设置一个范围合理的来源列表，而不是直接设成*。因为设成*会让所有网页都有权限调用你本机的 Ollama 服务，虽然有本地模型不跑敏感数据，但如果别人在浏览器里打开恶意页面，就可能借你的算力跑东西，不值得。

鉴权是另一件事。Ollama 默认不鉴权，意味着局域网内任何能访问到你 IP 的设备都能调用它。如果 Ollama 只在本机用还好，一旦暴露到局域网，强烈建议在前面加一层 Nginx 反向代理，把鉴权和访问控制做掉。

3.4 看日志找真相：服务端不会骗你

界面上的报错往往含糊不清，但日志是诚实的。如果你用的是 systemd 管理的 Ollama，查看日志的命令是journalctl -u ollama -f；如果是手动ollama serve启动的，日志就直接打在终端里。

有一次我排查了两个小时无输出问题，最后在日志里看到一行关键输出——模型加载到了 80% 的时候显存不足，被系统自动终止了，但 WorkBuddy 那边只显示“连接中断”，完全没暴露根本原因。所以记住：无输出的时候，第一步不是改 WorkBuddy 配置，而是去看 Ollama 的日志，确认请求到底到没到、模型到底加载成功了没。

日志里如果频繁出现和“segment fault”相关的错误，那就是 Ollama 进程本身崩了。这种情况多半是版本和系统环境不匹配，或者驱动有冲突。我的处理方式是直接把 Ollama 升级到最新版，再不行就彻底卸载重装，用官方离线安装包重来一遍。这类稳定性问题靠改配置是解决不了的。

4. 从 20 多 tok/s 到 70 tok/s：性能调优的完整记录

4.1 影响生成速度的硬指标拆解

接入通了之后，下一个问题就是速度。我一开始测速，7B 模型稳定在二十多 tok/s，这速度用来写代码对话勉强能忍，但多轮对话一长，等待感非常明显。后面一步步调到了 70 tok/s 上下，整个体验完全不一样。

先拆一下影响本地推理速度的几个硬指标。模型量化级别是最直观的：Q4_K_M这类 4bit 量化版本体积小、速度快，Q8_08bit 量化精度更高但速度明显下降。参数量不用多说，3B、7B、14B 的推理耗时差着量级。然后是 GPU 参与度，模型有多少层被 offload 到显卡上跑，决定了大头开销落在 GPU 还是 CPU。还有上下文长度，也就是 KV cache 占用的显存，上下文越长，每一轮生成的开销越大。最后是并发和预热状态，同一条模型第一次请求和跑热之后的第二次请求，速度能差出一倍以上。

4.2 调优动作与实测数据对比

下面是我实际做过的调整，按投入产出比排序。

第一步是确认 GPU offload 生效。Ollama 默认会尝试把模型加载到 GPU，但如果你驱动没装好或者显存不够，它会在无提示的情况下退回 CPU 模式。确认的方法很直接：跑一段长对话的同时观察显卡占用。如果 GPU 利用率一直在高位，说明生效了；如果 GPU 闲着一动不动，那就是没 offload 上。

第二步是设置模型常驻。默认情况下 Ollama 在模型空闲一段时间后会自动卸载，下次请求又得冷加载。我设置了OLLAMA_KEEP_ALIVE=24h，让常用模型一直留在显存和内存里。这一步对连续会话体验的提升非常明显。

第三步是收敛并行加载。WorkBuddy 这种工具通常是单请求串行的，不需要为它开高并发。我主动把OLLAMA_NUM_PARALLEL设为 1、OLLAMA_MAX_LOADED_MODELS设为 1，避免 Ollama 因为同时管理多个模型的 KV cache 而增加额外开销。

实测数据大概是这样的：

需要说明的是，我测试用的是 7B 量级的量化模型加单张主流显卡，硬件不同数据会有浮动，但调优的方向和顺序是通用的。

4.3 上下文长度、并发与内存的取舍

上下文长度是性能调优里容易被忽略的一环。WorkBuddy 这类工具有个特征：每次请求都会把会话历史打包发给模型，对话轮数一多，上下文很快就逼近上限。默认的 2048 上下文在简单测试时没问题，但多轮对话之后就开始丢信息，或者变慢。我当时把num_ctx上调到了 4096，效果立竿见影。

但这里有个反面教训：上下文不是越大越好。我把参数一度拉到 8192，显存直接爆了，Ollama 开始被迫把一部分 KV cache 换到内存，速度反而比之前更慢。后来我把上下文锁定在 4096，观察显存占用稳定在安全线以内之后就没再动过。

设置方式是在 Modelfile 里写PARAMETER num_ctx 4096，重建模型后生效。如果你是临时测试，也可以在 API 请求参数里直接传num_ctx。我的建议是：先 4096 起步，根据你的实际对话长度和显存余量再决定要不要往上调。

4.4 本地向量模型与后续扩展

速度和稳定性都搞定之后，我开始琢磨 WorkBuddy 里那些依赖向量检索的功能。很多 AI 工作台都会用到 Embedding 来做知识库、语义搜索、本地记忆，这类需求同样可以用 Ollama 承接。

Ollama 上有很多开箱即用的向量模型，比如nomic-embed-text、bge-m3。拉取命令和普通模型一样：

ollama pull bge-m3

向量模型的特点是占用量小、推理快，把它常驻在 Ollama 里基本上不占多少显存，但能给 WorkBuddy 的知识库检索提供全套本地化能力。这样一来，对话模型、向量模型、推理服务就全部落在本地了，整条链路完全不依赖外网。

我后来还做了一层扩展：用 FastAPI 写了个很薄的转发服务，把 WorkBuddy 的请求先经过我这一层，再做模型路由和 token 统计。这样做的核心好处是，以后想从 Ollama 切到别的后端，或者做多模型混合调度，都不用改 WorkBuddy 的配置，只改我这层转发就行了。你可以理解为在 WorkBuddy 和 Ollama 之间加了一个“插座”，以后换什么电器都只拔插头。

5. 常见问题速查表与保留级建议

5.1 高频问题速查表

这一趟走下来，我把最常遇到的问题和对应解法整理成了一张表，方便你直接对照排查。

5.2 实操心得与几个“早该早知道”的事

最后分享几个踩过坑之后沉淀下来的心得。

第一，任何 AI 工具对接后端，第一动作永远是 curl 打一遍接口，拿到正常的 JSON 再去界面上做下一步。这个习惯帮我省掉了大量“界面报错但不知道错在哪”的排查时间。WorkBuddy 的配置界面再怎么友好，也不可能替你把后端的问题说出来。

第二，模型名必须精确。qwen2.5:7b和qwen2.5:7b-instruct是两个模型，占用的内存不一样，行为也不一样，填错一个字母，结果可能完全离谱。一切以ollama list的输出为准。

第三，改配置之后要重启。环境变量、Modelfile 参数，这些东西改了之后不重启 Ollama 服务根本不生效。我自己就有一次改了OLLAMA_KEEP_ALIVE没重启，盯着测速数据看了半天，还以为是调优方法不对。

第四，先小模型验证链路，再上大模型调优。用qwen2.5:3b或者更小的模型先把 WorkBuddy、Ollama、网络层全部打通，确认没有问题，再切到 7B、14B 去做性能优化。不然链路问题和大模型性能问题搅在一起，你根本分不清是哪个环节在拖后腿。

最后说一点个人体会。WorkBuddy 这类工具接本地模型，真正的门槛从来不是界面上那几个输入框，而是整条链路里那些“你以为通了其实没通”的节点。我后来养成的那个 curl 自测习惯，本质上就是在帮自己排除掉“我以为”的部分，一步步逼近事实。这套排查思路不只是对 Ollama 有用，接任何本地模型、任何自建服务，逻辑都是相通的。