本地大模型不只靠命令行：用 OpenWebUI 统一接入 Ollama 与 DeepSeek API

前言

我第一次把 Ollama 跑起来以后，很快发现一个很现实的问题：模型能用，和模型好不好用，是两回事。

命令行当然能完成拉取模型、启动模型和对话，但当本地模型开始变多，或者还想同时接入局域网里的大模型、云端 API，再继续靠命令行切来切去，使用体验很容易变得割裂。真正日常使用时，我更希望有一个统一入口：能看见有哪些模型、直接切换、保留聊天记录，还能继续扩展知识库和工具能力。

OpenWebUI 适合解决的就是这类问题。它把 Ollama、本地或局域网模型、OpenAI 兼容 API 等不同来源放进同一个 Web 界面里，再补上对话历史、Markdown 渲染、模型管理、知识库等能力。原文记录中，这个项目在 GitHub 上已经达到 110,000 Stars。

这次我没有只看功能列表，而是按实际使用顺序走一遍：先把 OpenWebUI 跑起来，再看它能不能自动识别本机已有的 qwen3:32b，然后拉一个 deepseek-r1:1.5b 做快速测试；接着接入局域网中已经部署好的 deepseek-r1:671B，最后再换成阿里云百炼 API，看同一个界面对不同模型来源的兼容性到底怎么样。

本文会围绕几个最实际的能力来验证：

• Web 交互：是否能把原本的命令行模型变成更适合长期使用的聊天界面，并保留 Markdown、LaTeX、代码高亮和历史记录。
• 多模型统一管理：本地 Ollama、局域网 Ollama 与 OpenAI 兼容 API 能不能放在同一个入口里切换。
• 知识与工具扩展：OpenWebUI 提供 RAG、知识库、工具调用等扩展能力，后续可以继续在同一平台里使用。
• 多用户管理：支持用户与角色管理，适合从个人使用继续扩展到多人场景。
• 远程访问：本地 8080 服务跑通后，再通过 cpolar 增加公网入口。

所以这篇文章的主线不是“装一个好看的聊天框”，而是看 OpenWebUI 能不能把几种原本分散的 AI 使用方式，真正收进一个统一工作台里。

1 OpenWebUI介绍及演示

1.1 OpenWebUI界面操作演示

在部署之前，先看一下最后会得到什么。对我来说，OpenWebUI 最直观的变化不是“界面更漂亮”，而是模型终于从一条条命令，变成了一个可以长期使用的工作台。

下面是 Web 界面效果，包含代码预览：

下面这段 GIF 则演示了直接在对话里生成一个 HTML 登录界面。相比单纯看功能介绍，这种交互更容易理解 OpenWebUI 的使用方式：

从这个效果基本可以判断：OpenWebUI 的价值首先体现在“交互入口统一”。接下来再看它是否真的能把不同来源的模型接进来，而不只是把 Ollama 套上一层网页。

1.2 OpenWebUI介绍

OpenWebUI（原名 Ollama WebUI）是一个开源 Web 用户界面与模型管理平台。它最早很容易让人把它理解成“Ollama 的网页皮肤”，但真正用起来以后，更准确的定位其实是多个模型后端的统一入口。

Ollama 是其中一个重要后端，但并不是唯一后端。后文会实际验证：本机 Ollama、局域网 Ollama，以及 OpenAI 兼容 API 都可以在 OpenWebUI 中继续使用。

为什么很多人会把 OpenWebUI 当成长期入口？

原文记录的 GitHub 数据是 110K Stars。抛开热度本身，更值得看的还是它解决了哪些日常问题。

核心能力：

• 把命令行使用变成长期 Web 入口 支持打字机效果、Markdown 渲染（含表格和 LaTeX 数学公式）、代码高亮与复制、多主题和对话历史管理。对于已经会用 Ollama 的人来说，它减少的不是“学习模型”的难度，而是每天重复敲命令、切模型和找历史对话的成本。

• 不同模型来源可以继续收进同一个界面

  • 多模型生命周期管理：支持 Ollama 全系列本地模型，同时可连接 OpenAI 兼容 API（如 DeepSeek R1）、Claude 系列、LocalAI 等多种后端。
  • 检索增强生成（RAG）与知识库：支持上传 PDF、DOCX、TXT 等多种格式的本地文档，构建知识库。
  • 工具调用与 MCP 兼容性：支持模型调用外部工具执行任务，扩展单纯聊天之外的能力。
  • 提示词工作流与协作：提供提示词市场和管理功能，可以创建、保存、共享和重用自定义提示词模板。

  

• 部署位置可以由自己决定 OpenWebUI 可以运行在本地电脑或私有服务器上。是否完全离线、数据是否离开本地环境，仍取决于你最终接入的是本地模型还是云端 API，因此后文会把这两种方案分开测试。

• Ollama 集成是最直接的一条路径 OpenWebUI 可以识别本地 Ollama 服务及已下载模型。后面我会直接用本机已经存在的 qwen3:32b 验证这一点，再继续拉取新的 DeepSeek 小模型。

核心功能概览

把这些功能放在一起看，OpenWebUI 的核心优势就比较明确了：不是替你运行模型，而是把不同模型后端、聊天记录、知识库和管理能力放进同一个入口。

这也是后面部署和测试时需要一直保持的判断标准。

2 本地部署OpenWebUI

界面和功能看完以后，下一步先把 OpenWebUI 本身独立跑起来。这里暂时不急着接 DeepSeek，先确认 8080 Web 服务、管理员账号和基础页面都正常，再继续增加模型后端。

2.1 部署环境准备

在开始部署之前，我们需要确保你的系统环境满足基本要求。OpenWebUI 支持多种部署方式，我们将重点介绍最推荐的 Python pip 部署方案，这种方式简单、快速且无需额外软件。

系统要求：

• Python 版本：Python 3.11（必须，其他版本可能有兼容性问题）
• 操作系统：Windows 10/11、macOS 10.15+、Linux (Ubuntu 18.04+、CentOS 7+)
• 内存：建议 8GB 以上（运行大模型需要更多内存）
• 存储空间：至少 10GB 可用空间（用于存储模型和数据库）
• 网络：需要网络连接以下载依赖包和模型

必需软件：

• Python 3.11：核心运行环境
• Ollama：本地大模型运行环境（可选，也可使用远程 API）

2.2 开始部署OpenWebUI

OpenWebUI 提供了多种部署方式，本文继续采用原文中的 Python pip 部署方案。先把 Python 版本和依赖环境确认好，再进行安装：

首先，确保您的电脑上拥有python 3.11版本的python环境，如果没有可以前往官方进行下载：

Python 3.11 下载地址及命令：

# Windows
https://www.python.org/downloads/release/python-3118/

# macOS
brew install python@3.11

# Linux (Ubuntu/Debian)
sudo apt install python3.11

快速验证版本：

在cmd中输入如下命令进行验证版本：

python –version

然后配置一下国内源镜像（用于加速下载依赖）：

# 配置清华源加速下载
pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple

接下来，依旧在cmd中执行如下命令，进行安装OpenWebUI：

# 安装 OpenWebUI
pip install open-webui

安装完成后，执行如下命令进行启动测试：

# 启动OpenWebUI
open-webui serve

启动命令执行后，先不要直接判断部署完成，继续通过浏览器访问下面地址验证 Web 服务：

http://localhost:8080/

参考图如下：

页面能够正常打开后，说明 OpenWebUI 本体已经运行。接下来点击开始使用，进入创建管理员账号页面：

创建好您的管理员账号后，会自动登录进首页：

管理员账号创建完成以后，OpenWebUI 这个“壳”已经准备好了。但此时真正决定它是否好用的还是后面的模型接入。

下面从最容易验证的本地 Ollama 开始。

3 配置接入DeepSeekR1-671B 大模型

3.1 接入DeepSeekR1- 671B（本地方案）

这一部分我按“从小到大”的顺序测试本地模型接入：先看 OpenWebUI 能否识别现有 Ollama 模型，再拉一个体积较小的 deepseek-r1:1.5b 验证下载和对话，最后再接入局域网中的 deepseek-r1:671B。

如果要使用本地模型，需要先安装 Ollama服务，如果未进行安装，可以访问如下官方进行下载：

或者可使用如下命令进行安装：

# Windows
winget install Ollama.Ollama
# macOS
brew install ollama
# Linux
curl -fsSL https://ollama.ai/install.sh | sh
# 启动服务
ollama serve

下载安装好后，可以在cmd中测试验证一下是否安装成功,直接输入如下命令：

ollama

接下来，登录到OpenWebUI首页，进来以后，可以看到左上方的选择模型部分：

进入模型列表后，我本机原来已经存在的 qwen3:32b 被 OpenWebUI 自动识别出来了。

这一步验证了前面提到的一个关键点：如果 Ollama 本身已经在运行，OpenWebUI 可以直接把现有模型接到自己的界面里，不需要重新下载一遍。

现有模型识别正常以后，再测试从 OpenWebUI 里直接拉一个新模型。这里继续使用原文的 deepseek-r1:1.5b，大小约 1.1G，先用小模型验证整个流程：

deepseek-r1:1.5b

然后点击从Ollama.com拉取“deepseek-r1:1.5B”的选项，就会进行自动下载该模型，参考如下GIF动图演示：

模型下载完成后，直接进入聊天测试。下面 GIF 是原文记录的未加速效果：

从这次测试可以看到，deepseek-r1:1.5B能够正常对话。小模型的意义主要是验证安装、拉取、选择和聊天这一整条链是否通畅。

接下来再把变量换掉：不在本机继续拉更大的模型，而是接入局域网中已经部署好的 deepseek-r1:671B Ollama 服务。这样更能测试 OpenWebUI 是否真的可以作为“统一入口”，而不只是管理本机模型。

首先，点击左下角头像，然后在弹出来窗口点击设置，在接下来的弹出的窗口点击左下角的管理员设置，打开后台页面：

或者直接访问如下地址，也可以进入后台页面：

http://localhost:8080/admin/settings/general

后台页面：

按照上图操作，依次点击外部连接,点击Ollama API右侧的+号按钮，在新弹出的添加连接窗口配置您的本地ollama服务：

回到首页，查看模型列表：

回到首页后，模型列表已经显示来自局域网 Ollama 服务的 deepseek-r1:671B。

模型能出现在列表里只是第一步，下面继续用实际对话确认它是否可用：

对话能够正常完成，说明局域网中的 DeepSeekR1-671B 已经通过 Ollama API 接入 OpenWebUI。

到这里，本机小模型和局域网大模型已经可以共用同一个聊天界面。两者的模型规模和响应体验不同，但管理入口已经统一。

3.2 接入DeepSeekR1- 671B（Api方案）

前面的 671B 方案有一个前提：局域网里本来就有一台机器能够运行这个模型。如果本地硬件做不到，OpenWebUI 还有另一种用法——把云端 OpenAI 兼容 API 也接进同一个界面。

这样模型推理由云端完成，OpenWebUI 继续负责聊天入口和模型管理。代价是需要使用 API Key，并按服务规则计费。原文这里使用阿里云百炼进行演示，并记录了新用户登录即可享受每个模型100万免费Tokens：

就以满血版的DeepSeekR1-671B大模型为例：

首先，咱们需要领取千问百万tokens，来到阿里云百炼官网，点击右上角新用户登录即享每个模型100万免费tokens:

阿里云百炼官网：

https://bailian.console.aliyun.com/#/home

领取完成后，接下来进入密钥管理，设置设置千问api密钥： 密钥管理地址：

https://bailian.console.aliyun.com/?spm=a2c4g.11186623.0.0.60907980OAftBf&tab=model#/api-key

点击创建api-key，填写完信息：

然后点击复制按钮：

复制下来格式大概如下：

sk-53207f95f7e44ec18d05669767f649b7

然后回到OpenWebUI首页.点击左下角头像，然后在弹出来窗口点击设置，在接下来的弹出的窗口点击左下角的管理员设置，打开后台页面：

或者直接访问如下地址，也可以进入后台页面：

http://localhost:8080/admin/settings/general

后台页面：

按照上图操作，依次点击外部连接,点击OpenAI API右侧的+号按钮，在新弹出的添加连接窗口配置您的阿里云百炼的服务：

# 阿里云百炼API地址
https://dashscope.aliyuncs.com/compatible-mode/v1/

配置参考图如下：

回到首页，点击查看标签为通义千问下的模型：

可以看到，成功的显示了接入来自阿里云百炼服务的deepseek-r1大模型！

让我们演示一下阿里云百炼服务的deepseek-r1大模型（GIF动图参考）：

回到模型列表后，阿里云百炼提供的 deepseek-r1 已经能在 OpenWebUI 中选择并对话。

到这里，三种来源已经放进了同一个入口：

• 本机 Ollama 模型；
• 局域网中的 Ollama 大模型；
• 云端 OpenAI 兼容 API。

这也是我认为 OpenWebUI 最实用的一点：真正变化的不是模型本身，而是你不再需要因为模型部署位置不同，就换一套完全不同的使用方式。

4 穿透OpenWebUI支持外网访问

前面所有测试都在本地或局域网环境完成。如果 OpenWebUI 只在当前电脑上使用，到这里其实已经够了。

但当它已经把本机模型、局域网模型和云 API 都收进同一个工作台以后，一个新的需求会自然出现：人在另一台电脑、公司或外地时，能不能继续打开这个统一入口？

这时才需要处理公网访问。下面使用 cpolar 将 OpenWebUI 的 8080 Web 服务增加公网入口。模型实际运行在哪里并不会因此改变：本机 Ollama 仍在本机，局域网 671B 仍在局域网服务器，云 API 仍由云端推理。

4.1 什么是cpolar?

在本文中，cpolar 只解决“OpenWebUI 页面从哪里能访问”的问题，并不参与模型推理或模型管理。这样分开以后，后续排查也更清楚：页面打不开看隧道，模型不可用则继续检查 OpenWebUI 与对应后端的连接。

• cpolar 是一款内网穿透工具，可以将你在局域网内运行的服务（如本地 Web 服务器、SSH、远程桌面等）通过一条安全加密的中间隧道映射至公网，让外部设备无需配置路由器即可访问。
• 广泛支持 Windows、macOS、Linux、树莓派、群晖 NAS 等平台，并提供一键安装脚本方便部署。

4.2 下载cpolar

打开cpolar官网的下载页面： 点击立即下载 64-bit按钮,下载cpoalr的安装包:

下来下来是一个压缩包,解压后执行目录种的应用程序,一路默认安装即可,安装完成后,打开cmd窗口输入如下命令确认安装:

cpolar version

能够正常返回版本信息，说明 cpolar 客户端已经安装完成。

4.3 注册及登录cpolar web ui管理界面

4.3.1 注册cpolar

访问cpolar官网，点击免费注册按钮，进行账号注册

进入到如下的注册页面进行账号注册：

4.3.2 访问web ui管理界面

注册完成后,在浏览器中输入如下地址访问 web ui管理界面:

http://127.0.0.1:9200

输入刚才注册好的cpolar账号登录即可进入后台页面:

4.4 穿透OpenWebUI项目的WebUI界面

4.4.1 随机域名方式(免费方案)

这里先使用随机域名验证连通性。它更适合测试“公网能不能访问 8080”，而不是直接作为长期入口。

使用此方式时，系统会每隔 24 小时 左右自动更换一次域名地址。对于长期访问的不太友好，但是该方案是免费的，如果您有一定的预算，可以查看大纲4.4.2 的固定域名方式，且访问更稳定。

点击左侧菜单栏的隧道管理，展开进入隧道列表页面，页面下默认会有 2 个隧道：

• remoteDesktop隧道，指向3389端口，tcp协议
• website隧道，指向8080端口，http协议（http协议默认会生成2个公网地址，一个是http，另一个https，免去配置ssl证书的繁琐步骤）

点击编辑website的隧道，修改成我们open-webui需要的信息：

接着来到在线隧道列表，可以看到名称为open-webui-8080隧道的两条记录信息，一条协议为http,另一条协议为https:

以https为例，访问测试(加载稍慢，需耐心等待一下)：

公网地址能够正常打开 open-webui 页面，说明 8080 的远程访问链路已经打通。

这里验证的是 Web 入口，而不是重新部署模型。打开同一个 OpenWebUI 后，仍然继续使用前面已经配置好的本地 Ollama、局域网 Ollama 或云 API。

需要注意，免费方案每24小时左右会更新域名地址。如果只是临时测试影响不大，长期使用则更适合继续配置固定二级子域名。

4.4.2 固定域名方式（升级任意套餐皆可）

随机地址已经证明公网访问可用，下一步解决的是长期入口问题。OpenWebUI 如果准备长期作为统一 AI 工作台，固定地址更适合保存书签，也更方便在不同设备之间保持一致。

原文这里继续使用固定二级子域名方案。

接下来开始保留二级子域名：

首先，进入官网的预留页面:

选择预留菜单，即可看到保留二级子域名项，填写其中的地区、名称、描述（可不填）项，然后点击保留按钮，操作步骤图如下：

列表中显示了一条已保留的二级子域名记录：

• 地区：显示为China Top。
• 二级域名：显示为chatai。

注：二级域名是唯一的，每个账号都不相同，请以自己设置的二级域名保留的为主

接着，进入侧边菜单栏的隧道管理下的隧道列表，可以看到名为open-webui-8080的隧道，点击编辑按钮进入编辑页面：

修改域名类型为二级子域名，然后填写前面配置好的子域名，点击更新按钮：

来到状态菜单下的在线隧道列表可以看到隧道名称为open-webui-8080的公网地址已经变更为二级子域名+固定域名主体及后缀的形式了：

这里以https协议做访问测试（加载稍慢，需耐心等待一下）:

固定地址能够正常打开 OpenWebUI 后，说明二级子域名已经绑定到当前 open-webui-8080 隧道。后续可以继续使用这个固定入口，而不必依赖前面的随机地址。

到这里，OpenWebUI 负责模型与对话入口，cpolar 负责外部访问，两层职责仍然保持分开。

总结

这次实际折腾下来，我对 OpenWebUI 的理解和一开始不太一样。

如果只是把 Ollama 从命令行换成网页聊天，它当然已经有价值；但真正让我觉得它适合长期留下来的，是后面几次模型接入测试。

本机已有的 qwen3:32b 可以被自动识别；deepseek-r1:1.5b 可以直接从界面拉取并对话；局域网另一台 Ollama 服务器上的 deepseek-r1:671B 能继续接进来；本地硬件不够时，又可以通过 OpenAI 兼容接口把阿里云百炼的 deepseek-r1 放进同一个模型列表。

这几步连起来以后，OpenWebUI 的定位就很清楚了：它不是替代 Ollama，也不替代云 API，而是统一这些模型来源的使用入口。

如果只在当前电脑和局域网里使用，到这里已经完整。存在异地访问需求时，再通过 cpolar 给 8080 Web 服务增加公网入口；随机域名先用于验证连通性，长期使用再切换到固定二级子域名。

最终这套结构可以拆成几层：

• Ollama / 云 API：负责真正的模型推理；
• OpenWebUI：负责模型选择、聊天、历史记录、知识库与管理入口；
• cpolar：只负责让本地 OpenWebUI 页面可以从外部网络访问。

对我来说，最大的变化不是“终于有了一个像 ChatGPT 的界面”，而是以后换模型、换部署位置、甚至在本地与云端之间切换时，不需要跟着换整套使用习惯。

当一个 AI 工作台真正把这些后端差异藏到统一入口后面，它才开始从“部署项目”变成可以每天使用的工具。