把大模型留在自己机房，是很多团队上 AI 的第一道门槛。Ollama 负责把模型跑起来，Open WebUI 负责给同事一个像 ChatGPT 那样好用的界面——两者组合，半天就能搭出一个数据不出网的团队 AI 助手。
一、为什么要自建 AI 助手
直接买 SaaS 版聊天机器人最省事，但三类团队迟早要自己搭：第一类处理客户合同、财务报表等敏感数据，不敢明文传第三方；第二类调用量大，按 token 计费月底账单吓人；第三类要在模型外挂私有知识、定制人设与审批流，通用产品满足不了。再往深了说，SaaS 的模型版本你控制不了——今天还是这个版本，明天厂商一升级，回答风格和准确率都可能漂移，对需要稳定输出的业务是隐患。自建的核心收益就三个词：数据不出网、成本可控、行为可审计。而 Ollama + Open WebUI 是当下门槛最低、文档最全的一条路，单机就能跑，不需要 Kubernetes，运维心智负担小。
二、整体架构：各管一摊
这套组合只分两层，理解清楚就不会迷路：
- Ollama：模型运行时。它负责下载、加载、推理大模型，对外暴露一个本地 HTTP 接口（默认 11434 端口）。你可以把它当成”模型服务器”。
- Open WebUI：交互层。它提供网页界面、用户体系、对话历史、RAG 检索，背后通过 OLLAMA_BASE_URL 把请求转发给 Ollama。你可以把它当成”自带权限的 ChatGPT 前端”。
两者解耦的好处是：模型想换就换（qwen2.5、llama3、deepseek 随意切），前端想加功能就加功能，互不绑架。
三、第一步：用 Ollama 跑起本地大模型
在 Linux 服务器上装好 Ollama 后（官方一键脚本），先拉一个对中文友好的模型。团队场景建议从 7B 量化版起步，显存占用小、响应快：
# 拉取并运行一个中文友好的模型
ollama pull qwen2.5:7b
ollama run qwen2.5:7b
# 查看本机已下载的模型
ollama list
# 启动常驻服务（默认监听 11434）
ollama serve如果希望固化”公司助手”的人设、统一上下文长度，用 Modelfile 封装一个专属模型，避免每个人每次都重新写提示词：
FROM qwen2.5:7b
# 设定系统提示词，固化团队助手的人设
SYSTEM """你是公司内部 AI 助手，只基于公开资料回答，不泄露任何内部未公开信息。"""
# 调高上下文窗口，适配长文档问答
PARAMETER num_ctx 8192保存为 Modelfile 后执行 ollama create team-assistant -f Modelfile 即可生成一个新模型名。关于显存与量化参数的取舍，可参考本地大模型量化部署：GGUF 与 llama.cpp 调优，里面把 4-bit/5-bit 量化的显存账算得很清楚。
3.1 模型选型：团队用多大够用
不是模型越大越好，团队助手 90% 的诉求是”问答、总结、改写、写 SQL”，7B~14B 量化版已经能打。只有在需要复杂推理或长程代码生成时才上 32B/70B。显存大概的对应关系：
| 模型规模 | 量化后显存 | 适用场景 |
|---|---|---|
| 7B | 约 4~6 GB | 日常问答、摘要、改写，单机首选 |
| 14B | 约 8~10 GB | 中等推理、带格式的代码生成 |
| 32B | 约 18~22 GB | 强推理、复杂 Agent 编排 |
| 70B+ | 40 GB 以上 | 接近旗舰体验，需多卡或云推理 |
建议先用 7B 把链路跑通、让同事用起来，再根据真实反馈决定要不要上更大的模型。盲目上 70B 往往只是把显存压满，体验提升却有限。
四、第二步：一条命令部署 Open WebUI
Open WebUI 官方提供镜像，用 Docker 起最稳。关键是把数据目录挂成 volume，否则容器一删用户全没：
docker run -d \
--name open-webui \
-p 8080:8080 \
-e OLLAMA_BASE_URL=http://host.docker.internal:11434 \
-v open-webui-data:/app/backend/data \
ghcr.io/open-webui/open-webui:main几个要点：OLLAMA_BASE_URL 指向宿主机的 Ollama 地址；macOS/Windows 上用 host.docker.internal，Linux 上换成宿主机真实内网 IP（如 http://192.168.1.10:11434）。启动后访问 http://服务器IP:8080，第一位注册的用户自动成为管理员。
4.1 用 compose 管起来更省心
生产环境建议写成 docker-compose，把端口、数据卷、重启策略固定下来，升级时 docker compose pull && docker compose up -d 一行搞定，不会丢配置。
五、第三步：把知识接进来（可选 RAG）
光有模型还不够，团队助手真正有用是因为”懂公司”。Open WebUI 内置文档上传与向量检索，上传 PDF/Word 即可在对话里引用。若你需要更完整的”私有知识库 + 工作流”方案，可以看2026 年搭建私有 AI 知识库：Dify + Ollama 本地部署完整教程，它把知识入库、切分、召回的全链路讲透了；Open WebUI 胜在轻量和界面友好，Dify 胜在流程编排，按团队成熟度二选一或搭配用都行。
六、第四步：团队权限与多用户管理
面向团队，必须解决”谁能注册、谁能用什么模型”。Open WebUI 管理员面板里可以：关闭开放注册（仅邀请）、建用户组、给组分配可见模型。一个稳妥的落地节奏是：先开开放注册让核心 3~5 人内测、跑通工作流，再关掉公开注册、改成邀请制，避免外部人员蹭算力。常用环境变量：
# 关闭公开注册，只允许管理员邀请
-e WEBUI_AUTH=false # 仅内网可信环境可关；公网务必保持 true
# 限制单用户并发与令牌，防止某人把 GPU 占满
-e OLLAMA_MAX_LOADED_MODELS=2
# 通过反向代理（如 Nginx）统一加 HTTPS 与登录保护公网暴露时，务必在前面套一层 Nginx 反代做 HTTPS 与访问控制，做法可对照Nginx 反向代理实战。多模型统一路由（比如把贵的大模型走云 API、便宜的走本地）则可用LiteLLM 多模型网关收口，Open WebUI 直接填网关地址即可。
七、生产环境避坑清单
自建最怕”本地能跑、上线就崩”。把这几条提前堵上：
| 坑点 | 现象 | 对策 |
|---|---|---|
| 模型太大内存爆 | Ollama 进程被 OOM 杀掉 | 选 7B/14B 量化版；用 num_gpu 限制显存占用 |
| Open WebUI 连不上 Ollama | 界面模型列表为空 | OLLAMA_BASE_URL 用宿主机真实 IP，放行 11434 端口 |
| 数据卷没挂 | 升级后用户与对话清零 | 务必挂载 volume 持久化 /app/backend/data |
| 首字延迟高 | 打字机卡顿、体验差 | 开 GPU 推理、合理设 num_ctx、首次请求前预热模型 |
| 公网裸奔 | 被扫到后滥用算力 | Nginx 反代 + HTTPS + 关闭开放注册 |
八、总结
Ollama 解决”模型怎么跑”，Open WebUI 解决”同事怎么用”，两者一Docker一配，半天交付一个数据不出网、成本可算、权限可控的团队 AI 助手。下一步想上规模，把模型推理换成vLLM 高吞吐部署，前面再接 LiteLLM 网关统一调度，就能从”能用了”平滑演进到”扛得住”。
