企业官网建设流程全解析

大概半年前，我决定把 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\models，Linux 是/usr/share/ollama/.ollama/models。一个 7B 模型 Q4 量化后大约 4.7 GB，装三四个模型就是 20 GB 起步。C 盘吃得消倒也算了，问题是后面换模型、删缓存都会频繁读写，放在系统盘里既拖慢速度又占空间。

改存储路径靠环境变量OLLAMA_MODELS。Windows 上给当前用户新建环境变量，值填你想存放的目录，例如D:\ollama\models；Linux 可以在/etc/systemd/system/ollama.service的[Service]段加Environment="OLLAMA_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/v1
• API 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 代理加密码保护，这两个变量就得提前设置：

Windows 上改完环境变量后一定要重新启动 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 后端加载模型的原生进程崩溃了。常见原因有四类：

1. 显存不够：模型太大了，GPU 装不下，进程启动时直接被杀。7B 模型 Q4 量化最小需要 6 GB 左右显存，Q8 量化需要 8 GB 以上。如果你的显卡只有 4 GB，基本告别 7B 模型。解决办法是换更小模型（3B、1.5B）或者降低量化等级。
2. num_ctx 参数超限：上下文窗口设得太大，KV Cache 占满显存也撑不住崩掉。有些客户端允许设置上下文长度，你填了 32768 甚至更大，模型就会直接在加载阶段崩溃。
3. 量化格式与当前版本不兼容：某些社区魔改的 GGUF 文件在特定 Ollama 版本下会加载失败。解决办法是自己从 Hugging Face 拉官方 GGUF 写 Modelfile 重新创建模型，或者换一个量化版本。
4. 驱动/后端问题：Windows 上如果显卡驱动过老、OpenCL 或 CUDA 版本不对，也会在加载时崩溃。

排查这类错误，第一件事是看 Ollama 的详细日志。Windows 的日志通常在%LOCALAPPDATA%\Ollama\server.log，Linux 在~/.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_DEBUG=1环境变量打印更细的日志，定位会更精准。

3.4 Curl 正常但 WorkBuddy 还是无输出：检查请求参数和系统代理

把 Curl 调通后，回到 WorkBuddy 再次测试。如果此时依然是“转圈不出字”，继续往下排查这几个点：

• max_tokens 被设成 0 或极小值：有些工具会把“最大输出长度”的默认值设得很小，比如 1。模型刚生成一个 token 就被截断，表现就是输出框空白。在 WorkBuddy 的模型参数里把最大输出调到 512 以上试试。
• 系统提示词触发模型空回复：本地小模型的指令跟随能力不如云端大模型，如果你的 system prompt 设置了“只输出 JSON”“不要解释”之类的强约束，小模型可能直接输出空字符串或内容被过滤。把 system prompt 删掉再试一次就能定位。
• 上下文长度超限：WorkBuddy 可能默认携带很长的系统消息或历史对话，总 token 数一旦超过模型的 context window，Ollama 在拼 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_LAYERS=999 ollama serve

或者写进 Modelfile：

FROM 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 模型在同样的硬件上做了个简单对比：

注意一个反直觉现象：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_ALIVE=30m

另一种是请求时动态指定：

{ "model": "wb-qwen", "keep_alive": "30m" }

我把 keep_alive 设为 30m 后，半小时内连续对话都是秒响应。与此同时，还可以把OLLAMA_NUM_PARALLEL调成 4，让 WorkBuddy 可以同时处理几个并发请求，比如一边在终端问问题，一边在编辑器里做代码补全。显存如果够用，并发带来的体感提升非常明显。

注意一个平衡点：显存只有 8 GB 的时候，并发数设为 4 意味着 KV Cache 要分成 4 份，每一份都会变小，单个请求的推理反而会变慢。我的建议是：显存 12 GB 以下用默认 1，12 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_LAYERS=35，把 35 层放进显存，剩下的层在 CPU 算。混合推理总比纯 CPU 快不少。
• 内存双通道和频率：CPU 推理吃内存带宽，双通道 DDR4 3200 和单通道 DDR4 2666 的差距可能达到 40%。如果你无法上 GPU，这点很关键。
• NVMe 固态硬盘：模型加载快慢看硬盘，推理快慢主要看显存和内存带宽。NVMe 能让 5 GB 模型的加载从 60 秒降到 20 秒，体验差距巨大。

我最终的稳定配置是这样的：qwen2.5:7b-q4_K_M+num_ctx 1024+OLLAMA_KEEP_ALIVE=30m+num_gpu 999+ 关闭思考过程，在 RTX 3060 12G 上实测 68-72 tok/s。如果再把并发开成 4，交互流畅度完全能当日常主力助手使用，我甚至开始用它处理一部分代码 review。

5. 接入之后要扩展的几件事：skill 配置、多终端共用与知识库

Ollama 本地模型接入 WorkBuddy 后，真正的价值释放要从“能对话”升级到“能干活”。这个阶段我建议从三个方向切入。

5.1 把常用流程固化成 skill

WorkBuddy 的 skill 机制允许你把固定的提示词、操作步骤打包成一个可复用的功能块。比如我有一个“文献综述” skill，把“请阅读以下论文列表，按主题归纳，每个主题给出 3 条关键观点”这类 prompt 固化下来，输入论文列表就能直接触发。本地模型接入后，让 skill 跑通的意义在于：你可以把模型擅长的任务标准化，不用每次都重新描述一遍需求。

我的经验是：本地小模型在“总结归纳”“代码解释”“模板生成”这类局部任务上表现稳定，可以放心做成 skill；但在“长文档逐章分析”这种需要大上下文的任务上，小模型容易丢细节，skill 里要预设“分段提取再合并”的流程，效果才有保障。

5.2 多客户端共用同一个 Ollama：Nginx 代理加 API Key

Ollama 本身不带鉴权，如果你让它监听0.0.0.0，局域网里任何设备都能直接调用你的模型服务，这在真实环境中是个不小的隐患。我现在的做法是在 Linux 服务器上用 Nginx 做反向代理，加一层最基础的 Basic Auth：

server { 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/v1，API 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 测试。永远不要把客户端当第一诊断工具，它把太多底层错误吞成“无输出”了。