企业官网建设流程全解析

前阵子有朋友问我，本地跑大模型到底该用什么工具，从命令行拉模型到接进代码编辑器、网页聊天界面和业务系统，到底需要几步。说实话，现在市面上大模型工具多到让人眼花缭乱，但真正常用的链路其实非常清晰：Ollama 负责模型下载和推理服务，IDE 插件负责写代码辅助，Open WebUI 负责聊天界面，API 则让程序能直接调用模型能力。这篇文章我会完整走一遍这条链路，从下载安装 Ollama、配置国内下载源，到接入 Continue 插件、部署 Open WebUI，再到用 Python 写出能生产可用的 API 调用代码，整个过程都基于我自己的实操记录，希望对准备做本地大模型部署的朋友有帮助。

1. 方案选型与整体架构：为什么选 Ollama

1.1 从下载到推理，Ollama 解决了什么核心问题

本地大模型部署这件事，在 Ollama 出现之前并不轻松。你得先搞懂 Hugging Face 的模型权重怎么下载，再用 llama.cpp 或 transformers 做推理框架，还要自己处理量化、上下文长度、GPU 显存分配这些底层问题。我自己最早折腾的是 llama.cpp 编译，光是环境依赖就能耗掉一下午。

Ollama 把这些环节全部封装掉了。它的核心模型是把模型下载、量化格式转换、推理引擎、HTTP API 服务打包成一个命令，装完之后只要两条命令就能跑起一个模型：

ollama pull qwen2.5:7b ollama run qwen2.5:7b

对绝大多数人来说，这已经足够简单。但它的价值不只是简单，更重要的是它默认提供了一个本地 HTTP 服务（监听 11434 端口），IDE 插件、Web 界面、你自己的程序都能通过这个端口访问模型能力。等于说 Ollama 不只是"下载器"，它还是一个标准的模型服务中间层，下游工具只要能发送 HTTP 请求，就能接入本地大模型。

我当时的选型对比是在 Ollama 和 llama.cpp 之间纠结的。llama.cpp 的优势是性能调优自由度高，对老显卡、CPU 推理友好，但你需要手动管理模型文件、构建 server、处理跨平台路径问题，门槛不低。Ollama 则是开箱即用，对绝大多数开发者来说，它牺牲的那点自由度换来了巨大的易用性收益。

1.2 模型怎么选：从 7B 到 32B 的实测经验

Ollama 本身不提供模型，它只是一个模型运行环境。模型库非常丰富，主流开源模型都有对应的 Ollama 标签，比如 Qwen、Llama、Mistral、DeepSeek、Phi 等。这里我强烈建议根据显存选择模型规模，而不是一上来就追求大模型，否则跑起来卡顿、显存爆掉会非常打击信心。

• 7B~8B 级别（比如 qwen2.5:7b、llama3.1:8b）：适合 8GB 显存以下的环境，多数情况下还能 CPU 推理，速度可接受。代码补全、简单问答、文档润色都够用。
• 13B~14B 级别（比如 qwen2.5:14b）：建议 16GB 显存，如果只做文本推理，CPU + 部分显存混跑也能启动。这个档位的中文能力和逻辑推理明显比 7B 强一截。
• 32B 级别（比如 qwen2.5:32b、deepseek-r1:32b）：建议 24GB 以上显存。会写代码、能总结长文档，是本地部署的"甜点档"。
• 70B 级别：除非你有 48GB 以上的专业显卡，不然别碰，CPU 推理慢到怀疑人生。

还要注意 Ollama 默认下载的是量化后的模型，标注类似qwen2.5:7b对应的是 Q4_K_M 量化版本，参数量不变但精度有损，显存占用会明显小很多。如果你追求更高精度，可以用qwen2.5:7b-q8_0这个标签，代价是模型文件更大、显存占用更多。

模型大小估算公式（经验值）：显存占用 ≈ 参数量（B）× 量化位数（bits）÷ 8 例：7B 模型 Q4 量化 ≈ 7 × 4 ÷ 8 = 3.5GB 权重 + 约 1~2GB 推理缓存

这个公式不绝对，但能帮你快速判断"我的显卡能不能带动这个模型"。比如 8GB 显存的显卡，跑 7B Q4 量化模型基本是安全的，跑 14B 就非常勉强，极大概率要依赖内存交换。

1.3 本地部署方案横向对比

这里放一个我自己整理过的对比表，方便你做决策：

选型的核心逻辑是：你的目标是"用模型"还是"研究模型"。前者直接用 Ollama，后者才需要折腾底层框架。我自己目前的生产环境（给团队做内部问答机器人）用的就是 Ollama + 自建 API 网关，吞吐量完全够用。

2. 安装与环境配置：把最坑的下载环节解决掉

2.1 跨平台安装：Windows、macOS、Linux 的实测路径

Ollama 官方提供了三端安装包。Windows 用户直接去官网下载OllamaSetup.exe，双击安装就可以了，安装完成后命令行里输入ollama --version能输出版本号就说明成功。macOS 同理，下载.zip拖入应用程序即可。Linux 上官方安装脚本是一行命令：

curl -fsSL https://ollama.com/install.sh | sh

不过这个安装脚本在部分地区连接不稳定，实测经常卡在下载二进制文件那一步。我的建议是：不管哪个平台，先检查网络。如果下载慢或者失败，优先考虑使用镜像加速方案，不要反复重试官方链接，那不是解决问题的办法。

2.2 下载太慢的解法：配置国内镜像源

很多人在官方渠道下模型动辄几 GB，经常半天下不完，这个问题在社区里讨论很多。解决方案是给 Ollama 配置镜像源。Ollama 支持通过环境变量OLLAMA_BASE_URL或修改配置文件指向镜像站，从而加速模型下载。具体做法是：

• Windows：打开"系统属性 -> 环境变量"，新建一个用户变量，变量名OLLAMA_BASE_URL，变量值填你选择的镜像地址，比如https://ollama.example.com（这里只是占位说明，具体可用镜像可以搜"ollama 镜像源"）。
• Linux/macOS：在~/.bashrc或~/.zshrc中追加export OLLAMA_BASE_URL="https://ollama.example.com"，然后source ~/.bashrc生效。

配置完后重启 Ollama 服务（Windows 托盘图标退出重开，Linux 用systemctl restart ollama），再执行ollama pull qwen2.5:7b就会发现下载速度明显提升。需要注意，镜像源可能有版本同步延迟，如果某些冷门模型拉不下来，可以临时切回官方源。

2.3 模型存储路径与显存策略

Ollama 默认把模型存储在用户目录下，占用空间很大。Windows 在C:\Users\你的用户名\.ollama\models，Linux 在/usr/share/ollama/.ollama/models。如果 C 盘空间紧张，建议把模型目录挪到其他盘。方法同样是设置环境变量OLLAMA_MODELS，指向一个新的目录，然后重启服务。

我踩过的一个坑是：改完环境变量后没有重启 Ollama 服务，结果ollama pull还是下载到旧目录，导致 C 盘一度被塞爆。所以每次修改环境变量后，务必确认服务进程已经完全退出再重新启动。

显存管理方面，Ollama 默认会自动调度显存，但在多模型切换时可能残留显存占用。可以在环境变量里加OLLAMA_MAX_LOADED_MODELS=1，让系统只保留一个模型，避免显存被多个模型瓜分。如果推理时显存溢出，还可以调小上下文长度（这个后面细说）。

2.4 启动服务并验证接口

安装配置完成后，先跑一个最小模型验证环境：

ollama pull qwen2.5:7b ollama run qwen2.5:7b

输入一句"你好"，如果能看到模型流式回复，说明本地推理链路已经通了。此时 Ollama 的 HTTP 服务默认监听http://127.0.0.1:11434，用以下命令验证服务状态：

curl http://127.0.0.1:11434/api/tags

这个接口会返回一个 JSON 数组，里面是你本地已经拉取的所有模型。如果能正常返回，说明 API 服务已经在线，接下来接入 IDE、Web 和自有程序就都具备了基础。

3. 接入 IDE：让本地模型做你的编程助手

3.1 IDE 插件的选型：Continue 为什么是最稳的选择

目前主流的 AI 编程助手插件都支持接入本地 Ollama 模型，比如 Continue、Cline、Roo Code、CodeGPT 等。我试过几个之后，长期留下来的是 Continue，原因是它的配置结构非常清晰，能同时配置 OpenAI 兼容接口和 Ollama 原生接口，而且对多模型切换支持得非常好。

Continue 的安装途径很多：VS Code 和 JetBrains 系列 IDE 都有插件市场入口，直接在扩展面板搜索 "Continue" 安装即可。安装完成后，左侧边栏会出现一个 Continue 图标，点开就是它的聊天面板。此时它默认指向云端模型，需要修改配置才能指向本地 Ollama。

3.2 配置本地模型：config.yaml 的完整解析

Continue 的配置文件位于~/.continue/config.yaml，核心是定义模型列表。我用的配置大致如下（根据个人环境调整）：

name: Local Assistant version: 1.0.0 schema: v2 models: - name: Qwen 2.5 7B provider: ollama model: qwen2.5:7b roles: - chat - edit - apply apiBase: http://127.0.0.1:11434

配置里几个关键字段：

• provider: ollama：指定走 Ollama 协议，Continue 会直接用 Ollama 原生 API。
• model: qwen2.5:7b：模型名必须和你在 Ollama 里ollama list看到的名字完全一致。
• apiBase：Ollama 服务地址，默认就是 11434 端口。
• roles：定义了模型能参与哪些操作。chat是聊天，edit是编辑代码，apply是应用 diff。如果只想用聊天，可以不写edit。

修改完配置后，在 Continue 面板里重新加载配置（设置按钮里有个 reload 选项），再在模型下拉框里选中 Qwen 2.5 7B，就可以开始对话了。

3.3 代码补全与代码编辑的实际体验

Continue 的聊天面板更像一个"对话式编程助手"，你可以选中代码段，按Ctrl+I（VS Code）让它解释代码，按Ctrl+Shift+I让它生成注释。它的edit模式会自动 diff 你的代码块，你可以逐行确认修改，而不是一下子全替换掉。

我用 qwen2.5:7b 做日常代码注释和重构时，速度和输出质量都还过得去。但要注意，7B 模型在复杂代码推理上确实不如更大的模型，遇到需要跨文件理解的场景，我会手动把错误信息复制给它，比只贴代码段准确率高很多。

一个值得一提的优化是：在同一台机器上跑 IDE 插件和 Ollama，默认的num_ctx是 4096，也就是模型一次只能处理 4096 个 token 的上下文。代码文件稍微大一点就容易截断。你可以在 Ollama 命令行启动时临时调大：

ollama run qwen2.5:7b --num-ctx 8192

或者更稳定一点，在创建模型时用 Modelfile 固定参数（后面 API 章节会讲）。调大上下文会显著增加显存占用，8GB 显存跑 7B 模型开到 8192 一般没问题，再大就可能开始用内存交换了。

3.4 断网环境下的 IDE 体验：本地模型的独有优势

我之所以坚持用本地模型接入 IDE，一个很现实的原因是：我经常需要处理不能上传到云端的内容，比如公司内部项目代码、未发布的协议文本等。本地模型保证聊天上下文不出机器，这在数据安全上是很大的优势。

实际体验下来，本地模型的响应速度完全可控。在 4060 级别的显卡上，qwen2.5:7b 生成速度大约每秒 40~60 token，在 IDE 里做代码补全和代码解释完全够用。如果你的机器没有独立显卡，纯 CPU 推理也能跑，只是速度会掉到每秒 5~10 token，做简单问答还行，做大规模代码分析就比较煎熬了。

4. 搭建 Web 对话界面：Open WebUI 部署

4.1 为什么需要一个 Web 界面

Ollama 自带的命令行交互终端（ollama run）适合短对话，但要用作团队知识库或者日常聊天工具，体验就差远了。Open WebUI 是目前我个人最推荐的 Ollama 配套界面，它提供类似 ChatGPT 的对话框、多会话管理、模型切换，还内置了联网搜索、文档上传、RAG 知识库等进阶功能。

通俗点说，Ollama 就像是一个发动机，Open WebUI 是给它装上的驾驶舱。发动机本身能转，但没有驾驶舱你是不能舒服地开着上路的。

4.2 安装方式：Docker 一步到位

Open WebUI 官方推荐用 Docker 部署，这也是我实测下来最省心的方式。前提是你的机器已经装了 Docker。如果你没装 Docker，也可以直接用 Python 安装 Open WebUI，但对新手来说依赖冲突的坑会多一些。

Docker 部署命令如下：

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

这行命令拆开解释：

• -p 3000:8080：把容器内的 8080 端口映射到宿主机的 3000 端口。打开浏览器访问http://localhost:3000就能看到界面。
• --add-host=host.docker.internal:host-gateway：这一步至关重要。Open WebUI 默认连接的是http://host.docker.internal:11434，如果不加这个映射，容器内无法访问宿主机的 Ollama 服务。
• -v open-webui:/app/backend/data：持久化数据卷，保存会话记录和配置，容器删除后数据不丢。
• --restart always：Docker 重启或系统重启后自动拉起容器。

启动后需要先注册一个管理员账号，这是 Open WebUI 的第一道门。注册完成后进入主界面，在"设置 -> 外部连接 -> Ollama API 地址"里确认一下配置，一般默认填的就是http://host.docker.internal:11434，无需修改就能连通。

4.3 模型管理与对话参数调优

Open WebUI 连接上 Ollama 之后，左侧模型下拉框里会自动列出本机已有的全部模型。管理模型也很方便，可以直接在界面里拉取新模型：进入"设置 -> 模型"，输入模型名（如qwen2.5:14b），点击下载即可，相当于把ollama pull搬进了浏览器。

对话参数方面，Open WebUI 设置里可以对每个模型独立调整：

• Temperature（温度）：控制生成随机性。写代码设低一点（0.2~0.4），创意写作设高一点（0.7~0.9）。
• 上下文长度：对应模型的num_ctx，默认 4096，可以根据显卡显存调大。
• Top P：核采样，配合温度一起控制生成多样性，一般保持默认 0.9 或调低到 0.8。

这些参数最终会映射到 Ollama 的请求参数里，在 Open WebUI 里点开右上角"高级设置"就能看到实际发送的 JSON，对理解 Ollama API 非常有帮助。

4.4 进阶玩法：让 Web 界面真正服务团队

Open WebUI 能做的远不止聊天。它内置了文档问答功能，你可以把 PDF、Word、TXT 直接拖进对话框，它会做文本切块和向量化检索。它还支持创建多用户账号，配合--restart always的部署方式，完全可以当一个小型团队知识库系统来用。

我自己把公司部分文档放进去，构建了一个内部问答机器人。同事访问同一台机器上的 3000 端口，用自己的账号登录，就能查询文档内容，整个过程不需要任何代码开发。如果你想用 API 把数据写进它的知识库，Open WebUI 同样提供了接口文档，这点后面 API 章节再展开。

注意：Open WebUI 的验证码登录在局域网内很顺滑，但如果通过公网暴露，强烈建议在前面加一层反向代理做 HTTPS 和访问控制，否则任何人都能访问你的对话记录。

5. API 调用：程序里接上本地大模型

5.1 原生 API 和 OpenAI 兼容接口怎么选

Ollama 提供了两套 HTTP API：原生 API（/api/chat、/api/generate）和 OpenAI 兼容接口（/v1/chat/completions）。原生 API 功能更全，能直接构造消息、获取非流式响应、管理模型；OpenAI 兼容接口的好处是，你现有的调用 OpenAI 的代码几乎不用改，只要把 base_url 换成http://127.0.0.1:11434/v1就能切到本地模型。

我的建议是：新项目直接用 OpenAI 兼容接口，方便未来在云端模型和本地模型之间切换；需要用到 Ollama 特有功能（比如模型管理、生成进度）时再走原生 API。

5.2 先用 curl 测通，再写代码

正式写代码前，先用 curl 确认服务状态和响应格式。最简单的聊天请求：

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

返回的 JSON 里choices[0].message.content就是模型回复内容。能看到这个，说明 API 链路通了，后面写程序只是格式化请求的问题。

5.3 Python 调用示例：从单轮到流式输出

我自己生产环境用的调用方式是requests库，简单直接，不引入额外依赖。先写一个基础的非流式调用：

import requests OLLAMA_URL = "http://127.0.0.1:11434/v1/chat/completions" def chat_once(model: str, user_input: str) -> str: payload = { "model": model, "messages": [{"role": "user", "content": user_input}], "stream": False, "temperature": 0.7, } resp = requests.post(OLLAMA_URL, json=payload, timeout=60) resp.raise_for_status() return resp.json()["choices"][0]["message"]["content"] print(chat_once("qwen2.5:7b", "给我解释一下什么是布隆过滤器"))

这个函数的核心点是设置"stream": False，让 Ollama 一次性返回完整结果。对大多数内部工具来说，非流式就够用了。但如果你要做一个聊天机器人，自然希望像 ChatGPT 那样逐字输出，那就开启流式模式：

import json import requests def chat_stream(model: str, messages: list): payload = { "model": model, "messages": messages, "stream": True, } with requests.post(OLLAMA_URL, json=payload, stream=True, timeout=120) as r: r.raise_for_status() for line in r.iter_lines(): if not line: continue # 按 SSE 格式解析，每行是 data: {json} line = line.decode("utf-8") if line.startswith("data: "): line = line[len("data: "):] if line == "[DONE]": break chunk = json.loads(line) delta = chunk["choices"][0]["delta"].get("content", "") if delta: print(delta, end="", flush=True) messages = [{"role": "user", "content": "用一首诗描述程序员的生活"}] chat_stream("qwen2.5:7b", messages)

流式解析要注意[DONE]终止标志，以及每行开头的data:前缀。这是我第一次写流式调用时踩过的坑，没去掉data:前缀直接json.loads会报错。

5.4 关键请求参数：上下文、温度、最大 Token

对接 API 时，有几个参数直接决定生成质量，值得认真对待：

很多人会问，max_tokens和num_ctx有什么区别。区别在于：num_ctx是模型"能看到的输入长度"（所有历史问题和回答加在一起），max_tokens是"本次回答的最长长度"。如果输入很长但num_ctx很小，前面的内容会被截断；如果回答很长但max_tokens很小，话说到一半会被生硬打断。

5.5 用 OpenAI SDK 调用本地模型

如果你以前用过 OpenAI 的 SDK，切到本地模型非常轻松：

pip install openai

from openai import OpenAI client = OpenAI( base_url="http://127.0.0.1:11434/v1", api_key="ollama", # 本地服务不校验，任意值即可 ) resp = client.chat.completions.create( model="qwen2.5:7b", messages=[{"role": "user", "content": "听说你是本地模型，证明一下"}], stream=False, ) print(resp.choices[0].message.content)

只需要改base_url，原有的业务逻辑全部保留。这也是我推荐走 OpenAI 兼容接口最重要的原因：你在云端和本地之间的切换成本几乎为零。

5.6 生产环境部署的几个建议

如果你不是自己调试，而是要给团队提供 API 服务，有几个点必须提前规划：

• 端口管理：11434 是 Ollama 默认端口，如果你在同一台服务器上跑多个服务，注意不要冲突，可以通过OLLAMA_HOST=0.0.0.0:11435修改监听地址和端口。
• 并发控制：Ollama 默认允许的并发请求数有限，如果你的一台机器上同时有好几个人调用，可以通过环境变量OLLAMA_NUM_PARALLEL=4调高并行度，但也要注意显存总量。
• 权限隔离：生产环境别直接把 11434 端口暴露到公网，建议用 Nginx 做反向代理，加上 API Key 校验或 IP 白名单。
• 监控告警：Ollama 自带/api/ps接口可以查看当前加载的模型和显存占用，配合一个定时脚本就能做基础监控。

6. 常见问题与排查实录

6.1 高频问题速查表

6.2 显存不足和并发问题

显存不足是本地大模型玩家最常碰到的硬性问题。判断方法很简单：对话进行到一半突然报错，或者生成速度骤降，大概率是显存不够，开始使用内存交换了。解决方案有几种，按成本排序：

• 下调上下文长度：把num_ctx从 8192 降到 4096，显存占用立刻减少。
• 换更低量化的模型：比如把qwen2.5:7b-q8_0换成默认的 Q4 量化版本，显存缩小约一半。
• 加载更小的模型：7B 跑不动就换 4B、3B 甚至 1.5B 模型，日常问答完全够用。
• 限制并发：把OLLAMA_NUM_PARALLEL设低，避免多个任务同时抢占显存。

并发的问题和显存问题经常是一起的。如果你发现一个请求还没结束，另一个请求就开始排队，但显存还没满，可以适当调高OLLAMA_NUM_PARALLEL；如果显存满了但仍有请求进来，系统会直接报错。合理搭配这两个参数，才能让单机吞吐最大化。

6.3 上下文长度超限的经典报错

很多人在调用大模型时遇到过这个报错：400 this model's maximum context length is 1048576 tokens. however...。这里报的是模型本身支持的最大上下文，但实际可用长度受显存和num_ctx限制。解决思路是明确你的卡片能支撑多大的上下文，而不是盲目把num_ctx拉满。

我自己的实测参考值：8GB 显存跑 7B 模型，num_ctx设为 8192 基本就是极限了；16GB 显存跑 14B 模型，num_ctx可以到 16384。超过这个范围，推理速度会断崖式下降，因为内存和显存之间的数据搬运成了瓶颈。

6.4 一个典型排障过程实录

有一次团队反馈 API 调用偶发超时，我排查了整整两小时。现象是：本地 curl 调用正常，但通过 Nginx 转发后经常 504。开始以为是 Nginx 配置问题，把超时时间调大了还是偶发。

后来仔细看 Ollama 日志，发现问题是并发：同一时刻进来多个请求时，单模型排队时间过长，Nginx 默认的 proxy_read_timeout 只有 60 秒，排队加上慢速生成就超时了。最终方案是给 Nginx 加长超时到 300 秒，同时把OLLAMA_NUM_PARALLEL从默认值调大到 2，让多请求可以并行处理。这两个改动之后，超时问题彻底消失。

这类问题提醒我一个道理：本地大模型 API 的"慢"和普通 Web API 的"慢"不一样，生成式推理动辄几十秒，所有代理层、超时设置都要按这个实际体验来调整，不能套用常规 Web 服务的参数。

6.5 模型文件损坏与下载中断

下载了几 GB 的模型文件突然中断，然后再执行ollama pull总是报错或者反复从头下载，这种情况我碰到过一次。原因是 Ollama 下载中断后，本地残留了不完整的 blob 文件。解决办法是手动删除模型目录下对应模型的残留文件，然后重新拉取。

具体操作是：先ollama stop停掉所有运行中的模型，再找到OLLAMA_MODELS指向的目录，进入blobs子目录，删除最近修改时间异常的大文件，最后重新ollama pull。删除前建议备份，不过如果模型本来就能重新下载，直接删也无妨。

7. 一些实用的收尾配置

安装配置到这一步，整条链路已经通了。最后分享两个我日常高频使用的小配置，能让本地大模型的体验再上一个台阶。

第一个是使用 Modelfile 固化参数。如果你想固定某个模型每次加载时的上下文长度、温度等参数，可以写一个 Modelfile 然后创建模型：

FROM qwen2.5:7b PARAMETER num_ctx 8192 PARAMETER temperature 0.6

然后用ollama create my-qwen -f Modelfile创建新模型my-qwen。之后无论是命令行、IDE 还是 API 调用，只要指定my-qwen，它会自动使用这些参数，不用每次请求都手动传。

第二个是安装 Ollama 的定时清理脚本。模型长时间不推理时不会自动卸载，显存一直被占着。可以用ollama ps判断当前加载情况，配合一个简单的定时任务，把闲置模型卸载掉，给其他程序腾出显存空间。

这两件事看起来不起眼，但长期用下来能省掉很多烦恼。本地大模型部署最大的门槛其实不是技术，而是把环境调教到顺手。等你把模型、界面、API、参数都调顺了，就会觉得这比自己折腾各种云端服务踏实得多。