企业官网建设流程全解析

最近有个项目要在内网搭一套本地大模型问答环境，要求很直白：代码和文档数据都不能出这台机器，不能走云端API，但又要让VS Code里的代码补全、网页对话界面、后端系统调用都能用同一个模型。折腾一圈之后，我选了Ollama把整条链路跑通。从下载安装、模型选取，到最终同时接入 IDE、Web 和 API，整个过程不像“一条命令装模型”看起来那么轻巧，中间踩了不少坑，这篇就按实操顺序把关键步骤和解决思路写下来。

适合谁看？准备在本地电脑或内网服务器上部署大模型、想接进开发工具做成“AI辅助写代码”、或者要给团队搭一个不依赖公网的对话服务的人。就算之前没用过 Ollama，跟着走也能把链路跑起来。

1. 项目整体设计：先拆需求，再决定怎么部署

1.1 需求拆解：你要接的不是模型，而是三种完全不同的客户端

我一开始也以为“我把模型下载下来、在终端能聊天就算部署完成”，结果发现这只是起点。实际项目里同时存在三种消费场景，它们的协议和接入方式差别很大。

第一种是 IDE 场景。最典型的是 VS Code 里的 Continue、Claude Code 这类插件，它们是需要接一个“后端模型服务”的，但问题是这类插件的请求协议五花八门。Continue 这种还比较好说话，支持 OpenAI 兼容接口；而 Claude Code 走的是 Anthropic 的消息协议，不是标准 OpenAI 格式，不能直接把地址改成本地 Ollama 就完事。

第二种是 Web 场景。你希望给不熟悉命令行的同事一个网页，打开浏览器就能用，不需要他们去跑ollama run。这里需要一个 Web UI 服务，最常见的是 Open WebUI，它自己不带模型能力，本质上还是把请求转发给本地大模型服务。

第三种是 API 场景。团队内部的其他后端系统要调用模型能力，比如解析日志、归纳工单、生成周报。后端服务最稳妥的方式是走 REST API，最好还兼容 OpenAI 的 SDK，这样现有代码不用大改就能切换模型地址。

把需求拆到这层以后，部署方案就清晰了：Ollama 负责模型管理和推理服务，它是整个链路的地基；上层再根据场景分别接 IDE 插件、Web UI 和应用代码。

1.2 工具选型：Ollama 为什么比乱七八糟的方案更省事

市面上本地跑大模型的方案不算少，我比较过 llama.cpp、LM Studio、vLLM 和 Ollama，最终选 Ollama 不是因为它在单点技术上最强，而是因为它把“模型管理、推理服务、接口暴露”三件事绑在一起做了，对个人和小团队非常友好。

这里给个直观对比：

也就是说，Ollama 赢在“开箱即用”。它自身就是一个常驻进程，监听 11434 端口，模型拉下来之后默认就通过本地服务对外提供。我需要做的不是去编译底层推理引擎，而是专心解决“上层客户端怎么连进来”的问题。这个定位在项目里非常关键，因为它大大缩短了从零到可用的时间。

2. 下载与安装：真正耗时间的不是安装包，是模型文件

2.1 安装包下载慢？先做对这几个选择

先说安装。Ollama 提供 Windows、macOS、Linux 三类安装方式，Windows 直接去官网下载安装包，双击安装后右下角托盘会有一个小图标，模型服务默认在后台自动启动。macOS 可以用 Homebrew 安装，命令是brew install ollama。Linux 官方推荐的是在终端执行curl -fsSL https://ollama.com/install.sh | sh，这个脚本会自动检测系统架构并安装到/usr/local/bin，同时注册 systemd 服务。

如果你在下载安装包这一步就卡了半天，先把心态调整一下：安装包本身很小，真正的下载大头是模型文件。一个 7B 的模型 Q4 量化后普遍在 4.7GB 左右，14B 要到 9GB 以上，32B 直接 20GB 起，网络不好确实很让人崩溃。

我在实操中总结了一些针对“下载慢”的处理顺序：

• 不要遇到速度慢就反复删下载缓存重来，优先确认是不是磁盘空间不足。模型文件下载时要大量写盘，如果磁盘快满了，速度会异常慢。
• Ollama 拉模型走的是分块下载，中断后重新执行ollama pull会续传，停留在 90% 不代表死掉，等我几分钟让剩余块落盘是常态。
• 如果装完 Ollama 后拉模型持续很慢，换一台网络环境较好的机器把模型拉好，再用移动硬盘拷贝整个~/.ollama/models目录到目标机器，这是最省心的离线方案。
• 不要在第三方网站下载来路不明的“Ollama 加速版”或“绿色版”安装包，这属于给自己埋雷，轻则无法更新，重则直接中招。

Linux 上如果你对安装路径有要求，可以先用官方脚本装一次，再把模型目录改到空间更大的分区。Ollama 的模型目录默认在用户主目录下的.ollama/models，实际可以通过环境变量OLLAMA_MODELS指定。比如：

export OLLAMA_MODELS=/data/ollama/models ollama serve

一定要先设置环境变量再启动服务，模型服务启动后会按这个路径读写模型文件。如果你在 Windows 上，可以通过系统环境变量面板添加OLLAMA_MODELS变量，重启 Ollama 后生效。

2.2 选模型前先算算显存，不是所有模型都适合你的机器

模型下载之前先回答一个问题：你的机器能扛多大的模型？这不是玄学，是显存和内存的硬性限制。

Ollama 拉取的模型基本都是 GGUF 量化格式，量化就是把权重从 16 位压缩到 8 位、4 位甚至更低，换来体积减小、显存占用降低，代价是精度略微下降。日常对话和代码辅助场景，Q4_K_M 量化是公认性价比最高的档位。

我给一些常见模型做了一张参考表：

注意，表中列的只是权重大小的占用，实际运行还要加上 KV Cache。上下文窗口开得越大，KV Cache 占用越高。我第一次在 8GB 显存的卡上跑 7B 模型，直接把上下文窗口拉到 32K，结果没跑几步就爆显存。所以模型选择不能只看参数规模，还要看你准备开多大的上下文。

如果你没有独立显卡，完全靠 CPU 跑也不是不行，但要做好“能出结果、速度慢”的心理准备。7B 模型在 CPU 上跑，生成速度大概每秒几个 token 到十几个 token，静态分析、日志总结这种能等的场景还可以凑合，但如果用于 IDE 实时代码补全，体验会很着急。这点对后面接 IDE 的选择影响非常大。

模型拉取命令很简单：

ollama pull qwen2.5-coder:14b

拉完后可以用ollama list查看本地模型，用ollama run qwen2.5-coder:14b命令行对话。这里有个被我忽略过的细节：ollama run并不是简单地启动一个终端聊天，它会先把模型加载进显存再运行，首次执行通常比后续慢好几秒，这是正常的“冷启动”过程。

3. 接入 IDE：先分清插件协议，再动手配置

3.1 关键认知：Ollama 不是只能跑命令行的玩具，它自带 HTTP 接口

为什么能用 IDE 接本地模型？因为 Ollama 本身是一个常驻的 HTTP 服务，不是单纯的命令行工具。它默认监听127.0.0.1:11434，提供原生 REST API，比如/api/tags查看已安装模型、/api/generate做文本生成、/api/chat做多轮对话。

更重要的是，Ollama 从 0.1.28 版本开始提供 OpenAI 兼容端点，访问地址是http://localhost:11434/v1。也就是说，很多为 OpenAI API 写的代码、插件，只要把 base URL 改成这个地址，再把 API Key 随便填一个非空字符串（本地不校验），就能直接调用本地模型。

这一层兼容性大大扩展了 Ollama 的接入场景。VS Code 里的很多 AI 插件、开源的自动化脚本、企业内部的小工具，都默认支持 OpenAI 自定义地址，这部分改造成本极低。

但有个例外：Claude Code。它走的是 Anthropic 的消息协议，请求体结构和 OpenAI 格式不太一样，而且会携带具体的模型名去请求，不能直接把它的 Base URL 指到.../v1就认为完事。这个问题我放到后面单说。

3.2 VS Code 实操：在 Continue 插件里配置本地模型

在 VS Code 生态里，我推荐用 Continue 插件接入 Ollama。它开源免费，支持对话、代码补全、编辑等常见场景，而且对本地模型的支持比较成熟。

安装 Continue 后，需要打开配置文件（通过插件面板设置入口可以进），在models列表中加入本地模型。我的配置是这样：

models: - name: "Local Qwen Coder" provider: openai model: qwen2.5-coder:14b apiBase: http://localhost:11434/v1 apiKey: ollama roles: - chat - edit

配置完成后，在 Continue 面板里把当前模型切换到这个名称，就可以开始对话了。

实际操作时需要注意几个问题：

• 如果希望 Ollama 模型名是固定的，在 provider 里直接填 openai 并指定 apiBase 即可，很多教程让你选择 provider 为 ollama，这也没问题，但为了以后切换不同服务，我更愿意统一用 openai 兼容格式。
• 用 14B 模型做代码补全，响应延迟通常在几百毫秒到几秒，如果体感太卡，可以单独拉一个 3B 或 7B 小模型专门做补全，14B 只负责对话和代码解释。
• Continue 首次调用时模型可能还没加载，前几次请求会明显慢，不要误以为卡死，多等几秒。

如果你是 JetBrains 系的 IntelliJ IDEA、PyCharm，思路完全一样，找一个兼容 OpenAI 自定义地址的 AI 插件，填同一个 base URL 就行。重要的是先确认插件支持自定义 provider，而不是默认写死云端地址。

3.3 Claude Code 接本地模型：CC Switch 与模型别名两个细节

Claude Code 在开发者社区非常火，它默认是连接 Anthropic 云端 API 的。很多人想在本地环境里让它调用 Ollama，直接在插件设置里换 API 地址，结果报错或者提示模型不存在，原因就是我前面说的协议差异。

解决的常见路线是用 CC Switch 这类工具做一层适配。CC Switch 可以把它收到的 Anthropic 格式请求转换成 OpenAI 兼容请求，再转发给 Ollama。实际上它把“各厂商协议不同”这个脏活揽了过去，Claude Code 侧不需要改协议。

大体操作流程：

1. 安装并启动 CC Switch，添加一个新的 Provider，类型选择 Ollama。
2. 地址填http://127.0.0.1:11434。
3. 选择需要映射的 Claude 模型名称，比如claude-3-5-haiku、claude-3-5-sonnet，把它们指向本地已有的模型，如qwen2.5-coder:14b。
4. 切换到该 Provider，重启 Claude Code 或 reload 窗口。

这里有一个非常容易翻车的地方：Claude Code 请求的模型名可能是带日期后缀的精确版本号，比如claude-3-5-sonnet-20241022，如果指定的模型名与 Ollama 本地标签不一致，Ollama 会直接返回 model not found。

最省事的兜底办法是直接用 Ollama 创建别名模型：

先准备一个 Modelfile：

FROM qwen2.5-coder:14b PARAMETER num_ctx 32768

然后执行：

ollama create claude-3-5-sonnet-20241022 -f ./Modelfile

这样 Ollama 本地就多了一个叫claude-3-5-sonnet-20241022的模型，实际跑的还是千问的权重，但 Claude Code 请求这个名字时就不会再报“模型不存在”了。用FROM引用的基础模型需要提前 pull 好，别名模型本身不会额外占用多少磁盘空间，因为它底层指向同一个权重文件。

需要注意的是，很多适配工具要求的版本号会变，如果后续 Claude Code 升级了模型名，再回到 Ollama 里重新建一个带新版本号的别名即可。

3.4 其他 IDE 的接入思路

热词里还包含了 Trae 这类新 IDE，以及 Arduino IDE 等相对垂直的编辑器。Arduino IDE 本身没有 AI 插件生态，不太建议折腾，代码辅助需求可以放在 VS Code 里完成。

Trae 这类 AI IDE 的情况要具体看版本。不少国内版 IDE 的 AI 功能绑定的是厂商账号，想换成本地 OpenAI 兼容接口就需要看设置里有没有“自定义模型”或“自定义 Provider”入口。如果没有，就别硬改配置文件了，直接走 Open WebUI 这类 Web 页面或者用 Continue 做互补。原则是：优先利用能够支持 OpenAI 兼容地址的工具，而不是去改 IDE 的私有配置。

4. 部署 Web 页面：给不懂命令行的同事一个聊天入口

4.1 用 Open WebUI 10 分钟跑出一个对话站点

命令行聊天怎么都不适合发给普通同事，所以 Web 端我首选 Open WebUI。它是一个功能完整的对话 Web 界面，支持多用户、历史记录、文件上传，后台模型地址可以指向 Ollama。

最标准的部署方式是 Docker。假设 Ollama 跑在宿主机上，Open WebUI 跑在容器里，关键是解决容器内如何访问宿主机服务的问题。先看命令：

docker run -d -p 3000:8080 \ --add-host=host.docker.internal:host-gateway \ -v open-webui:/app/backend/data \ --name open-webui \ --restart always \ ghcr.io/open-webui/open-webui:main

这里面的--add-host=host.docker.internal:host-gateway是给 Linux 用的，让容器内可以通过host.docker.internal这个域名访问宿主机。macOS 和 Windows 的 Docker Desktop 自带该映射，不传也行，但加了不会出错。

启动后打开http://localhost:3000，第一次访问会让你注册管理员账号。进入设置页把 Ollama 的 Base URL 填成http://host.docker.internal:11434，保存后就能在模型列表里看到本地已经拉取的模型。

填地址这里是最容易出问题的一步。有人填http://localhost:11434，在容器内部这个 localhost 是容器自己，不是宿主机，自然连不上。我一开始也在这卡了一会儿，理解“容器内访问宿主机要用 host.docker.internal”之后就顺了。

如果你不想用 Docker，还可以考虑 pip 安装 Open WebUI，但依赖比较多，个人电脑上跑容易遇到 Python 版本兼容问题。实际项目里我推荐 Docker，更新、回滚都简单，不会把 Python 环境搞得一团糟。

4.2 局域网访问和跨域限制处理

Open WebUI 部署只是第一步。团队使用时别人访问的是你这台机器的 IP，不能只在localhost上开放。Ollama 默认只监听本地回环地址，其他电脑访问不到，必须在启动服务前设置环境变量：

export OLLAMA_HOST=0.0.0.0

重启 Ollama 后，它才会监听所有网卡。此时可以尝试在另一台电脑上访问http://服务器IP:11434，能看到 Ollama 的响应说明网络层通了。

但有一个安全提醒：如果只是内网使用，OLLAMA_HOST 设为 0.0.0.0 问题不大，但一旦这台机器有公网 IP，就相当于把模型服务裸奔在公网上，任何人都能调用，这很危险。更稳妥的做法是让 Ollama 继续保持127.0.0.1，只把 Open WebUI 暴露出去，由 Open WebUI 作为内部调用方。Open WebUI 和 Ollama 在同一台机器上，不涉及跨网络问题。

如果你是前端项目直接调 Ollama，比如用 fetch 在浏览器里呼叫本地模型，浏览器会有跨域限制。Ollama 提供了OLLAMA_ORIGINS环境变量来控制允许来源。开发环境下可以这样设：

export OLLAMA_ORIGINS="*"

生产环境建议只填你自己的 Web 域名，不要一刀切全放开。能规避跨域就规避，用后端转发比让浏览器直连模型安全得多。

5. 开放 API：让后端系统也能调用本地模型

5.1 OpenAI 兼容接口：最快上手的调用方式

后端系统接入我建议直接走 OpenAI 兼容端点，因为现代后端项目多数已经安装了 OpenAI SDK，改一个 base_url 就能切到本地。

用 Python 的 openai 库调用本地 Ollama，代码很简洁：

from openai import OpenAI client = OpenAI( base_url="http://localhost:11434/v1", api_key="ollama" ) resp = client.chat.completions.create( model="qwen2.5:14b", messages=[ {"role": "system", "content": "你是项目助理，答案要简洁。"}, {"role": "user", "content": "帮我总结下面这段日志的核心问题"} ], temperature=0.3, max_tokens=1024 ) print(resp.choices[0].message.content)

这里有几个容易踩的坑。第一，api_key虽然本地不校验，但是 openai 库要求非空，所以随便填一个字符串，不能完全不填。第二，model的名称必须和ollama list里的名称完全一致，包括 tag。第三，max_tokens只是输出上限，真正的上下文窗口大小受模型加载参数影响。

curl 验证更快：

curl http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2.5:14b", "messages": [{"role": "user", "content": "你好"}], "stream": false }'

收到类似 OpenAI 格式的 JSON 响应，就说明接口层已经通了。

5.2 原生流式接口：别用同步等待去做长时间生成

有些场景用 SDK 的同步调用等一个完整回复，体验很差。比如让模型生成一篇长文或分析一大段代码，如果模型生成速度慢，HTTP 请求可能要等几十秒才能返回，后端连接很容易超时。此时应该使用流式接口。

OpenAI 兼容接口的流式用法是在请求参数里加"stream": true，openai SDK 侧会自动把响应变成迭代器。原生 Ollama 的/api/chat接口同样支持流式输出，响应格式是 SSE。一个简单的 Python 例子：

from openai import OpenAI client = OpenAI( base_url="http://localhost:11434/v1", api_key="ollama" ) stream = client.chat.completions.create( model="qwen2.5:14b", messages=[{"role": "user", "content": "写一个快速排序"}], stream=True ) for chunk in stream: delta = chunk.choices[0].delta if delta and delta.content: print(delta.content, end="", flush=True)

实际项目里，流式输出不仅是为了用户体验好，还有个额外好处：客户端可以在生成过程中判断是否已经满足需求，提前终止请求释放显存，而不是干等模型把整段话说完。

5.3 API 报错高发区：模型找不到与上下文超限

API 接入代码本身不复杂，绝大多数问题集中在模型参数和运行环境上。

后端调用返回类似model "xxx" not found, try pulling it first，原因很直接：Ollama 服务端根本没有这个名字的模型。先用ollama list看一遍实际模型名，再把代码里的 model 字段改一致。这个错误在 IDE 插件接入时也很常见，因为很多插件默认发送的模型名是gpt-4或claude-3，本地 Ollama 肯定不会认识，需要在插件配置里把模型名改成本地实际模型，或建一个同名的 Ollama 别名。

另一个更隐蔽的高频报错是上下文相关。如果你从某云 API 切到本地，请求里带了很大一段历史消息，可能会收到上下文超长的 400 错误。云端接口通常有自己的最大上下文限制（比如 1M tokens），一旦超过会返回明确提示。本地 Ollama 场景则相反，很多人在 IDE 里感觉“模型记不住前面的代码”，不是模型蠢，而是 Ollama 默认上下文窗口太小。

默认情况下 Ollama 只开 2048 个 token 的上下文，如果发送的消息总量超过这个范围，模型就只能看到消息末尾部分。解决办法是把num_ctx调大。三种常用方式：

在启动模型时临时指定：

/ set parameter num_ctx 32768

但这只对当前会话有效。更稳妥的是通过 Modelfile 固化：

FROM qwen2.5:14b PARAMETER num_ctx 32768 PARAMETER temperature 0.7

再用ollama create创建成一个新模型。或者在 API 请求里带上：

resp = client.chat.completions.create( model="qwen2.5:14b", messages=[...], extra_body={"options": {"num_ctx": 32768}} )

最后这种适合只想对某个请求临时扩大上下文的需求。

这里要特别提醒：把 num_ctx 调大不是白嫖，上下文窗口扩大后 KV Cache 显存占用会明显上涨。比如 7B 模型开 2048 上下文可能只占几百 MB，开 32768 可能额外多吃几 GB 显存。显存不够就别一味调大，优先裁减消息数量，比如只保留最近几轮对话，而不是把完整历史全塞进去。

6. 高频问题与排查思路

6.1 问题速查表：按症状直接找对策

我在这次部署中把各种报错大致归了几类，为了让你排查时不走弯路，直接用表格列出来：

整个排查逻辑其实就一句话：先确认 Ollama 服务本身正常，再确认模型名一致，最后确认协议和参数符合客户端要求。很多人栽在第 2 步“模型名不一致”上，和网络其实没关系。首次接入 IDE 不熟悉插件机制时，可以先在终端curl一把本地模型，看看服务是否响应，这样能快速把问题边界划分清楚：是服务层挂，还是插件配置错。

6.2 我这轮折腾下来的一些经验

真正把这套链路稳定跑起来之后，我总结出几条很值得分享的习惯，都是实测下来好用的。

第一，模型服务要当成常驻服务来管理，不要每次用的时候现开。Windows 上装完 Ollama 托盘默认运行；Linux 服务器用 systemd 管理并设置好OLLAMA_HOST和OLLAMA_MODELS。否则重启一次机器环境变量丢了你都不知道，模型又跑回到默认目录，几 GB 的模型文件又要重新下载，这种事我干过一次就不会再干了。

第二，如果有多个人共用一台模型服务器，建议设置 keep_alive 控制在显存里的驻留时间。Ollama 默认模型加载后 5 分钟没有请求就会释放，方便是方便，但频繁被调用时每次都要重新加载模型，体验很差。可以设置keep_alive为更长的时间，比如30m，或者直接-1表示一直驻留。反过来，如果显存特别紧张，需要跑多个模型轮流处理，建议把 keep_alive 设小一点，避免模型一直占着显存不放。

第三，尽量把 Web UI、IDE、API 的调用全部收敛到同一个模型服务。不要 IDE 接一个 Ollama，Web UI 又单独装一套模型引擎，那样显存会被重复占用。Open WebUI 和 Continue 都指向同一个localhost:11434，用 Open WebUI 时把请求负载稍微控制下，不需要为每个系统开一套独立环境。

第四，所有客户端在配置时都应先验证一次连通性。Open WebUI 设置里有连接测试按钮，Continue 配置完可以直接发起一次对话，API 用 curl 测试。我见过很多同事配置完啥反应没有就去翻日志，其实问题只是模型名随手写了个不存在的名称，这种基础错误提前验证能省很多时间。

关于容器部署时的 Docker 镜像拉取如果一直很慢，配置可信的镜像加速是正规做法，也比反复重试更靠谱。至于 Ollama 大模型文件，还是那句话：不要随便找第三方“一键脚本”下载模型再复制进来，模型文件通常是公开的，但使用前注意看项目许可证，商用场景更要留意模型授权和隐私边界。

这套链路搭完之后，后续还可以继续扩展：在 Ollama 同机装上嵌入模型，配合 Open WebUI 的知识库功能做简单的本地 RAG；或者把模型服务接到企业内部 API 网关，做统一的流量审计。底层的模型调度逻辑已经稳了，上面这些扩展就是水到渠成的事。