过去两年，随着 Llama 3.1 和 Qwen 2.5 等开源模型的爆发，本地部署大模型已经从极客玩具变成了企业刚需。我们在实际运维中发现，绝大多数工程师在拿到一台带 GPU 的 Linux 服务器后，第一反应就是 `pip install ollama` 然后在终端里敲字。这虽然快，但当你要给非技术人员演示、或者要把公司内部知识库喂给模型时，原生的 Ollama CLI 就显得捉襟见肘。
这就是 Open WebUI 诞生的土壤。它的前身是著名的 Ollama WebUI，后来由于社区分裂并进行了全面重构。现在的 Open WebUI 不仅仅是一个聊天界面，它实际上是一套完整的 LLM 应用框架。它能帮你解决两个核心痛点：一是知识隔离，你可以针对不同的对话窗口挂载不同的知识库（Knowledge Base），实现真正的上下文隔离；二是协作体验，它支持多用户注册、角色权限分配（Admin/User/Guest），这对于需要向团队内部提供 AI 服务的初创公司来说，是原生 CLI 绝对无法提供的。
很多人会拿 vLLM 或 Text Generation WebUI 来做对比。vLLM 胜在吞吐量，但界面简陋；TGW 功能强大但部署极其繁琐。Open WebUI 选择了中间路线：它通过标准化的 OpenAI API 接口接入底层推理引擎，这意味着无论你后端换的是 Ollama、vLLM 还是 LM Studio，前端都不用动。这种解耦设计让它成为了当前本地大模型生态中事实上的“标准外壳”。
理解 Open WebUI 的部署，首先要看懂它的架构数据流。它主要由三个部分组成：前端（React 构建的用户界面）、后端（FastAPI 提供逻辑控制）以及数据存储层（PostgreSQL 存业务数据，SQLite 存向量索引，Ollama 存模型权重）。
当我们发起一次对话时，请求会先进入 FastAPI 后端。后端会解析用户的 Prompt，并根据当前会话绑定的 Knowledge ID，去向量数据库中检索相关的文档片段。这些片段会被打包进 System Prompt 里，一起发送给后端的 Ollama 推理节点。这种 RAG（检索增强生成）的流程被封装在了 Open WebUI 的代码库里，用户只需要在 UI 上点击“上传文件”，剩下的切片、Embedding、存储都由系统自动完成。
在架构设计上，我们推荐采用 Docker Compose 的方式部署。这样做的好处是环境完全隔离，且可以通过修改环境变量一键切换底层模型。例如，你可以让同一套 Open WebUI 同时对接本地的一张 RTX 4090（跑 70B 的量化模型）和远程的一台云端 A100 集群（跑 405B 的原型模型），前端用户通过简单的下拉菜单就能无缝切换算力资源。
我们不建议直接在宿主机上 `git clone` 源码运行，因为依赖冲突的概率极高。最稳妥的方式是使用官方推荐的 Compose 模板。以下是我们在生产环境中验证过的配置：
version: '3.8'
services:
open-webui:
image: ghcr.io/open-webui/open-webui:main
container_name: open-webui
volumes:
- open-webui:/app/backend/data
- /var/run/docker.sock:/var/run/docker.sock
ports:
- "3000:8080"
environment:
- OLLAMA_BASE_URL=http://host.docker.internal:11434
- WEBUI_SECRET_KEY=changeme_to_a_secure_random_string
- ENABLE_RAG_WEB_LOADER=true
depends_on:
- ollama
restart: unless-stopped
ollama:
image: ollama/ollama
container_name: ollama
volumes:
- ollama-models:/root/.ollama
ports:
- "11434:11434"
deploy:
resources:
reservations:
devices:
- driver: nvidia
count: all
capabilities: [gpu]
volumes:
open-webui:
ollama-models:
这段配置的核心在于 `OLLAMA_BASE_URL` 的设置。对于使用 Docker Desktop 的 Mac/Windows 用户，`host.docker.internal` 能正确解析到宿主机 IP。但在 Linux 服务器上，你可能需要使用 `--network host` 模式，或者指定服务器的局域网 IP。此外，挂载 `docker.sock` 是为了让 WebUI 能够动态控制底层的 Ollama 容器（比如自动拉取新模型）。
部署完成后，性能瓶颈通常不在 WebUI 本身，而在后端的 Ollama 和向量检索。我们在测试一台配备 2 张 RTX 4090 的服务器上，使用 Qwen2.5-72B-Instruct-Q4_K_M 模型进行压测。结果显示，在 batch_size=4 的情况下，首字延迟（TTFT）约为 1.2 秒，后续生成速度约为 25 tokens/s。如果开启 WebUI 的 RAG 模式，由于增加了 Embedding 检索的时间，首字延迟会增加约 300-500 毫秒，但这换来的是回答准确度的显著提升。
| 方案 | 优势 | 代价 | 适用场景 |
|---|---|---|---|
| 原生 Ollama CLI | 部署极简，几乎无资源消耗 | 无任何界面，不支持 RAG，无法分享 | 个人开发者调试 Prompt |
| Open WebUI | 开箱即用，支持多模型、知识库、多用户 | 依赖 Docker，显存占用略高（前端渲染） | 团队协作、企业内部知识库搭建 |
| vLLM + Custom Frontend | 极致吞吐量，支持 Continuous Batching | 开发成本高，需要自行处理鉴权与知识库逻辑 | 高并发 C 端商业产品 |
在实践中，我们遇到过最多的投诉是“上传了 PDF，但 AI 根本不看”。排查后发现，问题通常出在向量切片的粒度上。Open WebUI 默认的切片大小（Chunk Size）是 512 tokens。如果你的 PDF 是一份复杂的财务报表，单个单元格的数字可能就被切断了，导致语义不完整。
现象： 提问具体的财务数据时，模型回答“未在文档中找到相关信息”。
定位： 检查 WebUI 的 Logs，发现 Embedding 后的向量维度虽然正常，但检索召回率极低。
最终方案： 在环境变量中调整 `RAG_CHUNK_SIZE=256` 并重启容器。更小的切片虽然增加了向量库的大小，但对于结构化文档的精确匹配更有效。此外，务必在设置中将 Embedding 模型从默认的 `nomic-embed-text` 切换为 `BGE-M3`，后者在处理中文混合英文的专业文档时，召回率提升了近 40%。
Open WebUI 是目前本地部署大模型性价比最高的选择。它用一套 UI 解决了模型管理、知识库挂载和多用户协作的难题。对于大多数中小型团队，我们给出的建议是：直接使用 Docker Compose 一键部署，并在第一时间将数据库从 SQLite 迁移至 PostgreSQL，同时在设置中将 Embedding 模型升级为 BGE-M3。这套组合拳打下来，你的本地 AI 助手就能达到商用级的稳定性。
如果你只有单机显存资源（如 24GB），请优先部署 7B-14B 参数量的模型配合 RAG 使用，效果往往优于强行上 70B 模型却连知识库都跑不动的情况。记住，算力是底座，但数据质量才是 AI 的上限。
完全可以。通过环境变量 OLLAMA_BASE_URL=http://<远程IP>:11434 即可指向任意远程 Ollama 实例。这在边缘端部署 Ollama、中心端部署 WebUI 的多租户架构中非常常见。
只要是兼容 OpenAI API 格式的模型均可。在 Ollama 生态下，支持 Llama 3, Qwen 2, Mistral 以及各类微调版本（如 Qwen2.5-Coder）。
进入设置中的 'Knowledge' 选项，上传 PDF/Markdown/TXT 文件。WebUI 会自动调用内置的 Embedding 模型（默认 BGE-M3）将文档切片分词，并存入 SQLite 向量索引中。
SQLite 适合个人开发者或小团队（3人以下）。超过 3 人并发编辑知识库时，极易出现数据库锁定（Database is locked）错误，此时应切换配置 PostgreSQL。