OpenWebU部署实战:Python 3.11、Ollama、DeepSeek R1与固定地址访问

OpenWebUI部署实战：Python 3.11、Ollama、DeepSeek R1与固定地址访问

前言

Ollama把本地模型跑起来以后，很多人很快会遇到第二个问题：命令行能用，但不适合长期聊天、切模型、看历史记录，更别说同时接本地模型和在线API。模型本身已经能回答问题，真正影响使用体验的，反而变成了“怎么管理和调用”。

这次我直接用Python 3.11部署OpenWebUI，把它作为统一的Web入口。先完成8080本地访问和管理员初始化，再接入本机Ollama中的deepseek-r1:1.5b，继续测试局域网里另一台Ollama服务器上的DeepSeek R1 671B。

本地模型跑通以后，再接阿里云百炼的OpenAI兼容API，让OpenWebUI同时具备本地Ollama和云端模型两条调用路径。

最后再给8080增加外部访问入口，从随机公网地址切换到固定二级子域名。整篇重点不是把OpenWebUI写成“终极AI平台”，而是把OpenWebUI → 本地Ollama → 局域网Ollama → 云端API → 远程访问这条链真正跑通。

这类AI工作台真正好用的地方，也不只是“界面像ChatGPT”，而是模型后端可以拆开管理：轻量模型放本机，大模型放局域网服务器，需要时再接云端API。这样一来，界面、算力和模型来源不必绑死在一台机器上，后续扩展会更清楚。

也更方便后面继续接知识库、工具调用或更多模型服务。

1 OpenWebUI真正解决什么问题

OpenWebUI更适合被理解成：

一个把不同模型入口集中到浏览器里的Web界面和管理层。

如果直接使用Ollama命令行，常见操作通常围绕：

• 启动模型；
• 切换模型；
• 查看模型；
• 输入Prompt。

而OpenWebUI把这些交互搬到浏览器以后，真正改善的是：

• 聊天界面；
• 对话历史；
• Markdown和代码展示；
• 模型切换；
• 外部模型连接；
• 管理员配置；
• 多用户入口；
• 后续知识库和工具扩展。

效果：

2 先看本次实际验证到什么程度

界面示例：

代码生成效果：

这篇真正实测的重点包括：

• OpenWebUI本地部署；
• 管理员账号初始化；
• 本机Ollama识别；
• 拉取deepseek-r1:1.5b；
• 本地模型聊天；
• 局域网Ollama连接；
• DeepSeek R1 671B模型显示与调用；
• 阿里云百炼API接入；
• DeepSeek R1云端模型调用；
• OpenWebUI远程访问。

至于RAG、MCP、团队协作等功能，属于OpenWebUI后续可扩展方向，不作为这篇已经完整验证的主线。

3 OpenWebUI更像“统一入口”，不是模型本身

项目界面：

它真正负责的是：

把不同AI后端接进一个统一Web界面。

例如：

• 本机Ollama；
• 局域网Ollama；
• OpenAI兼容API；
• 其他支持的模型服务。

所以整条链应该拆开理解：

OpenWebUI负责界面和连接

Ollama负责本地模型运行

阿里云百炼负责云端API模型

三者不是同一个角色。

4 Web界面比命令行更适合长期使用

页面：

当模型使用频率上来以后，真正省事的不是“少敲一条命令”，而是：

• 不同会话能留下历史；
• 模型可以直接切换；
• 代码和Markdown更容易阅读；
• 管理配置有固定入口。

继续看功能界面：

本次不把所有功能都写成已经逐项验证，而是把它作为OpenWebUI的扩展能力背景。

5 自托管不等于“百分百离线和绝对隐私”

页面：

如果OpenWebUI只连接本地Ollama，并且使用本地模型，那么模型推理链确实可以主要留在本地环境。

但这篇后面还实际接入了：

阿里云百炼API。

这时Prompt和请求就会经过对应云端接口。

所以更准确的说法是：

OpenWebUI支持自托管，数据路径取决于你实际连接的模型后端。

本地模型和云端API要分开理解。

6 开始部署OpenWebUI

这次使用：

Python 3.11 + pip

先准备Python环境。

安装方式保持如下：

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

# macOS
brew install [email protected]

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

页面：

7 验证Python版本

执行：

python --version

结果：

本次按Python 3.11环境部署。

8 配置pip镜像源

执行：

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

结果：

这里使用清华PyPI镜像，目的是减少依赖下载时的等待。

9 安装OpenWebUI

执行：

# 安装 OpenWebUI
pip install open-webui

安装过程：

10 启动OpenWebUI

执行：

# 启动OpenWebUI
open-webui serve

结果：

启动以后，默认本地入口是8080。

11 浏览器访问8080

访问：

http://localhost:8080/

页面：

做到这里可以确认：

浏览器 → OpenWebUI:8080

已经跑通。

12 创建管理员账号

点击开始使用：

创建第一个管理员账号以后进入首页：

这一步很重要。

因为后面：

• 外部模型连接；
• API配置；
• Ollama连接；
• 用户管理；

都会从管理员设置里继续操作。

13 接下来先走本地Ollama路线

如果要使用本地模型，先准备Ollama。

安装和启动命令保持如下：

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

页面：

14 验证Ollama已经安装

执行：

ollama

结果：

确认Ollama正常以后，再回OpenWebUI。

15 OpenWebUI可以看到本机Ollama模型

模型选择页面：

这里已经能看到本机已有的：

qwen3:32b

说明OpenWebUI和当前Ollama链路已经连上。

16 再拉一个DeepSeek R1 1.5B测试

搜索模型：

deepseek-r1:1.5b

选择从Ollama拉取：

这一步相当于：

OpenWebUI界面 → Ollama → 下载模型。

17 测试DeepSeek R1 1.5B对话

实际聊天：

这一步可以确认：

OpenWebUI → 本机Ollama → deepseek-r1:1.5b

已经能正常交互。

模型小、响应快只是本次体验表现。

不能直接推导出所有硬件、所有Prompt下都一样快。

18 再接局域网里的另一台Ollama服务器

如果大模型跑在其他机器上，可以把OpenWebUI作为统一入口。

管理员设置地址：

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

页面：

进入外部连接以后，新增Ollama API连接：

这里填写实际局域网里的Ollama服务地址。

19 连接成功以后查看模型列表

回首页：

现在已经能看到来自局域网Ollama服务器的：

deepseek-r1:671B

这一步证明的是：

OpenWebUI可以连接另一台Ollama服务，并识别它提供的模型。

20 实际调用671B模型

演示：

这一步进一步验证：

OpenWebUI → 局域网Ollama → DeepSeek R1 671B

链路已经可用。

至于671B是否适合自己的硬件，要看真正运行Ollama的那台主机资源。

OpenWebUI本身不会替你解决大模型算力需求。

21 没有本地大算力时，再走云端API路线

这篇还保留第二种方式：

OpenAI兼容API。

页面：

这种方案和本地Ollama最大的区别是：

模型推理发生在云端服务。

所以不需要本机承担671B模型的推理资源，但会涉及：

• API Key；
• 调用额度；
• 云端请求；
• 平台计费或免费额度。

22 进入阿里云百炼

地址：

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

页面：

本次材料中展示了新用户模型额度。

具体额度和活动以账号当时页面显示为准，不把它写成长期固定承诺。

23 创建API Key

进入密钥管理：

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

创建：

复制：

本次材料里还保留了一个API Key格式示例：

sk-53207f95f7e44ec18d05669767f649b7

这个值不应该被理解成可直接使用的公共密钥。

实际使用时必须填写自己的API Key，并避免把真实密钥放进公开文章、截图或仓库。

24 回到OpenWebUI管理员设置

访问：

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

页面：

进入：

外部连接 → OpenAI API

新增连接。

25 填写阿里云百炼兼容接口

接口地址保持如下：

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

配置页面：

这里还需要填写自己的API Key。

26 回首页查看云端模型

页面：

现在可以看到通过阿里云百炼接入的：

deepseek-r1

这说明OpenWebUI已经同时具备两类模型来源：

本地 / 局域网 Ollama

和：

云端 OpenAI兼容API

27 实际测试云端DeepSeek R1

演示：

到这里可以确认：

OpenWebUI → 阿里云百炼兼容接口 → DeepSeek R1

也已经正常。

28 三条模型链路应该怎么选

这篇实际跑了三种形态。

本机Ollama

优点：

• 模型在当前机器运行；
• 调用链短；
• 不依赖云端推理API。

限制：

• 受本机CPU / GPU / 内存影响。

局域网Ollama

优点：

• OpenWebUI和推理主机可以分开；
• 可以把大模型放在更强的服务器上。

限制：

• 两台机器需要网络互通；
• 推理性能仍然取决于Ollama服务器。

云端API

优点：

• 本地不需要承担大模型推理资源；
• 接入相对直接。

限制：

• 请求经过第三方模型服务；
• 需要API Key；
• 可能涉及额度和费用。

所以“哪一种最好”没有固定答案。

取决于算力、隐私要求和使用成本。

29 本地链路到这里已经跑通

现在已经完成：

OpenWebUI:8080

↓

本机Ollama

↓

局域网Ollama

↓

云端OpenAI兼容API

如果只在家里或办公室局域网使用，到这里已经够了。

后面的步骤解决：

人在外面怎么进入OpenWebUI。

30 OpenWebUI开放公网前要先看权限

OpenWebUI不是普通静态页面。

它里面可能包含：

• 聊天记录；
• 管理员账号；
• Ollama连接地址；
• 云端API Key；
• 模型列表；
• 上传文件；
• 知识库内容。

所以公网访问时至少应该关注：

• 管理员密码；
• 普通用户权限；
• API Key保护；
• 固定公网地址传播范围；
• 是否真的需要长期对外开放。

cpolar负责网络入口。

OpenWebUI自身仍然负责账号和应用权限。

31 安装Windows版cpolar

页面：

下载安装：

完成以后执行：

cpolar version

结果：

32 注册cpolar账号

注册入口：

页面：

完成以后进入本地Web管理页面。

33 打开cpolar Web UI

访问：

http://127.0.0.1:9200

页面：

登录：

34 给OpenWebUI的8080创建随机公网入口

本次页面里有默认隧道：

编辑website隧道：

把本地地址改成OpenWebUI使用的：

8080

35 查看随机公网地址

在线隧道列表：

从外部网络使用HTTPS地址访问：

能够正常进入OpenWebUI以后，可以确认：

外部浏览器 → 公网地址 → OpenWebUI:8080

已经跑通。

36 随机地址更适合先验证

本次材料里把随机域名按约24小时变化描述。

这种方式更适合：

先验证远程访问链路。

如果准备长期收藏和使用，再继续配置固定二级子域名。

37 保留固定二级子域名

预留页面：

本次示例：

• 地区：China Top
• 二级域名：chatai

实际能保留的名称以自己账号为准。

38 编辑OpenWebUI隧道

回到隧道列表：

把域名类型改成：

二级子域名

填入已经保留的名称：

39 查看固定地址

在线隧道列表：

现在随机地址已经切换成固定二级子域名形式。

40 最后从外部设备再访问一次

使用固定HTTPS地址：

能够正常进入以后，长期远程入口完成。

整条链现在变成：

外部浏览器 → 固定公网地址 → OpenWebUI:8080 → 本地Ollama / 局域网Ollama / 云端API

41 固定地址解决的是“入口稳定”

固定二级子域名主要解决：

• 手机长期收藏；
• 笔记本长期使用；
• 不需要频繁更新随机地址；
• 多设备使用同一个入口。

它解决的是：

OpenWebUI入口不频繁变化。

并不代表：

• OpenWebUI自动变成生产级部署；
• API Key自动安全；
• 所有模型都在本地运行；
• 云端API不再有成本；
• 管理员页面可以随意公开。

42 “本地AI”也要分清数据到底走哪条路

如果选择本机Ollama：

Prompt → OpenWebUI → 本机Ollama

如果选择局域网Ollama：

Prompt → OpenWebUI → 局域网Ollama服务器

如果选择阿里云百炼：

Prompt → OpenWebUI → 阿里云百炼API

所以真正判断隐私边界时，不能只看OpenWebUI是不是部署在本地。

还要看：

当前选择的模型后端在哪里。

43 这套方案更适合什么人

比较适合：

• 已经在用Ollama；
• 不想长期只用命令行；
• 想在一个页面切不同模型；
• 有局域网GPU服务器；
• 同时需要本地模型和云端API；
• 想多设备共用一个AI入口。

如果只是偶尔运行一次模型，直接Ollama命令行已经足够。

OpenWebUI真正体现价值，通常是在：

模型来源变多、聊天频率变高、设备数量增加以后。

44 最后把完整技术链重新看一遍

Web界面：

Python 3.11 → OpenWebUI → 8080

本地模型：

OpenWebUI → 本机Ollama → deepseek-r1:1.5b

局域网模型：

OpenWebUI → 局域网Ollama → DeepSeek R1 671B

云端模型：

OpenWebUI → OpenAI兼容API → 阿里云百炼 → DeepSeek R1

随机远程：

公网随机地址 → 8080

固定远程：

固定二级子域名 → 8080

实际完成：

• Python 3.11；
• pip镜像源；
• OpenWebUI安装；
• open-webui serve；
• 8080本地访问；
• 管理员账号；
• Ollama安装；
• 本机模型识别；
• DeepSeek R1 1.5B拉取；
• 本地模型聊天；
• 外部Ollama连接；
• 671B模型接入；
• 阿里云百炼API Key；
• OpenAI兼容接口；
• 云端DeepSeek R1；
• cpolar安装；
• 随机公网访问；
• 固定二级子域名；
• 外部设备访问。

这样OpenWebUI才真正从“给Ollama换一个聊天界面”，变成一个能同时管理本地模型、局域网模型和云端API的统一AI入口。

总结

这次真正跑通的是一条完整的OpenWebUI使用链：先用Python 3.11完成安装，通过8080进入Web页面并创建管理员账号，再让OpenWebUI分别连接本机Ollama、局域网Ollama和阿里云百炼OpenAI兼容API。

模型验证也没有停在“列表里能看到”。本机的deepseek-r1:1.5b实际完成了聊天，局域网里的DeepSeek R1 671B也完成调用，云端DeepSeek R1同样通过百炼接口跑通。这样才能真正区分三种模型来源的资源、网络和隐私边界。

远程部分是在本地AI入口正常以后再增加的能力。随机公网地址先验证8080链路，固定二级子域名再解决长期入口变化的问题；但OpenWebUI里可能保存管理员账号、聊天记录和API Key，公网可达不等于权限已经处理完成。

OpenWebUI真正带来的价值，是把不同模型来源集中到一个长期可用的Web入口。至于数据是否留在本地、是否需要云端费用、模型能跑多大，仍然取决于最终选择的是本机Ollama、局域网Ollama还是第三方API。

转载自 CSDN-专业IT技术社区

原文链接：https://blog.csdn.net/2301_76341691/article/details/168435165