简介：这是Open WebUI官方GitHub项目的ZIP源码包，用于将Ollama本地模型引擎与Deepseek等模型组合成可视化聊天界面。资源面向希望在本地或私有网络部署AI对话平台的开发者和爱好者，解决网页端调用Ollama时交互体验不足、模型切换不便的问题。压缩包共2000个文件，约54MB，以svg前端图标资源、svelte界面组件、py后端服务代码及json配置文件为主，另含Dockerfile、Windows启动脚本、TypeScript类型定义与多套CSS主题样式，便于直接部署和二次开发。已有670人学习下载。通过该源码包可得到Open WebUI完整实现：多模型集成与一键切换、响应式聊天面板、用户管理及离线运行能力，同时附带了资源描述中对Ollama相关Web UI的选型对比，涵盖Open WebUI、AnythingLLM与Dify三款工具的定位差异，帮助读者按需选择最合适的前端方案。
1. 把 Ollama + Deepseek 装进 Web 界面：Open WebUI 这份 ZIP 包到底解决什么问题
很多人以为本地部署 Deepseek 就是装个 Ollama、拉个模型、在终端里敲几句对话就完事了。真这么干过的人都清楚，终端里滚动输出的对话体验极差，没有历史上下文管理、没有参数面板、别人想用还得跟着敲命令。Open WebUI 就是来解决这个问题的：它把 Ollama 后端的管理、对话、文件上传、多模型切换、参数调节全包进一个类似 ChatGPT 的网页界面里。我手上这份 GitHub ZIP 包，是 Open WebUI 的完整源码包，配合 Ollama 和 Deepseek 系列模型，能在自己电脑上跑出一套完整的私有聊天服务。适合两类人：一类是想在局域网里给团队提供大模型入口的运维，另一类是折腾本地模型但受够了命令行交互的深度玩家。
2. 装 Ollama 并拉取 Deepseek 模型：先让模型跑起来，再谈界面
2.1 为什么选 Ollama 当模型运行时：OpenAI 兼容 API 是最大理由
Ollama 能在本地大模型部署里站稳脚跟，靠的不是它拉模型有多快，而是它把“跑模型”这件事压缩成了两个动作：装服务、拉模型。它内部用 llama.cpp 做推理后端，支持 CPU 和 GPU 混合运行，不需要你手动配 CUDA、cuDNN，也不需要写推理脚本。更关键的是，Ollama 默认监听 11434 端口，暴露出来的接口是/v1/chat/completions和/v1/models，OpenAI 兼容格式意味着 Open WebUI 不用写任何适配层，直接把 Ollama 当成一个本地 OpenAI 服务对接就行。
选 Deepseek 的原因也直接：它是目前开源模型里中文理解和代码能力都比较靠前的系列，Ollama 官方库里有deepseek-r1和deepseek-coder两个分支。R1 是推理模型，回答问题前会生成一段思考链，适合做复杂问题拆解和代码调试；Coder 系列偏代码生成与补全。如果机器显存只有 8G 左右，选deepseek-r1:7b或deepseek-r1:8b比较合适；显存到 24G 可以考虑 14b 甚至 32b（量化版）。7b 的量化模型大概占 4.7G 存储，14b 大概 9G 左右。
这套组合的逻辑是：Open WebUI 负责交互层，Ollama 负责模型层，Deepseek 负责能力层。三者通过 HTTP 接口串联，每一层都能独立替换。以后想换 Qwen、Llama，不用动 WebUI 和 Ollama，只改模型名。
2.2 安装与模型拉取：Windows / Linux 两条路径
先装 Ollama。Windows 直接去官网下载安装包，装完服务会自动注册成系统服务，托盘区能看到图标。Linux 用官方一键脚本：
curl -fsSL https://ollama.com/install.sh | sh装完先确认服务状态和版本：
ollama --version ollama serveollama serve是前台启动命令，正常情况会输出监听127.0.0.1:11434的日志。如果服务已经在后台运行（Windows 安装后默认如此），这条命令会提示端口被占用，不用管。接着拉取 Deepseek 模型：
ollama pull deepseek-r1:7b这里有几个参数要知道：:7b是模型尺寸标签，不写标签默认拉latest，而 R1 系列的 latest 指向 7b；ollama list查看本地已有的模型；ollama run deepseek-r1:7b直接进终端对话。首次拉取要下载几 GB 文件，具体大小看模型标签，网络正常的话 7b 大概一两分钟，慢的时候可能要半小时。
拉取成功后，用一条命令验证模型能正常出结果：
ollama run deepseek-r1:7b "用一句话解释什么是残差网络"提示：
ollama run会先把模型加载进内存，对话结束默认驻留 5 分钟（OLLAMA_KEEP_ALIVE控制）。第一次输出会慢，因为要加载权重，后续在同一进程里对话会快很多。
2.3 下载慢与存储路径：两个必须提前改的变量
Ollama 让人翻车最多的不是推理慢，而是模型下载慢和磁盘爆掉。模型文件默认存到用户目录下，Windows 是C:\Users\你的用户名\.ollama\models，Linux 是/usr/share/ollama/.ollama/models。C 盘空间紧张的话，这个默认路径非常坑。
常见的做法是先设环境变量再装服务。Windows 在“系统属性 → 环境变量”里新建：
OLLAMA_MODELS=D:\ollama_models OLLAMA_HOST=0.0.0.0 OLLAMA_KEEP_ALIVE=24hLinux 用 systemd 管理的话，要改服务配置文件：
sudo mkdir -p /data/ollama sudo systemctl edit ollama.service然后写入：
[Service] Environment="OLLAMA_MODELS=/data/ollama" Environment="OLLAMA_HOST=0.0.0.0" Environment="OLLAMA_KEEP_ALIVE=24h"改完重启服务：
sudo systemctl daemon-reload sudo systemctl restart ollama说下这三个变量的含义。OLLAMA_MODELS是模型存储路径，必须在拉模型之前设好，已经拉过的模型不会自动迁移，得手动拷贝过去。OLLAMA_HOST=0.0.0.0是让 Ollama 监听所有网卡，默认只监听127.0.0.1，如果 Open WebUI 和 Ollama 在不同机器上，这个必须改。OLLAMA_KEEP_ALIVE=24h是模型加载后驻留内存的时间，频繁切换模型的人建议设短一点，长期只用 Deepseek 一个模型的话设长更省事。
注意：改环境变量之后，Ollama 服务要完全重启才生效。Windows 上改系统环境变量后，最好注销一次或重启系统，否则服务可能仍然读旧值。
3. 从 ZIP 包到运行中的 Open WebUI：源码部署的完整步骤
3.1 ZIP 包里有什么：先认清源码目录结构再动手
从 GitHub Releases 下载的 Open WebUI 源码包，解压后第一眼看到的不是可执行文件，而是一套 FastAPI 后端 + Svelte 前端的混合仓库。根目录下有几个关键文件夹和文件：backend/是 Python 后端的核心代码，frontend/是 Svelte 前端工程，pyproject.toml声明后端依赖，package.json声明前端依赖。
很多人拿到 ZIP 包直接双击想跑，发现根本没有启动程序，这是没搞清楚项目结构。Open WebUI 的官方推荐部署方式是 Docker，但 Docker 对网络和内存都有要求；源码直接跑的话，需要 Python（建议 3.11+）和 Node.js（建议 20.x）双环境。在动手启动之前，先把依赖装齐，这是整个部署过程中最容易出问题的一步。
ZIP 包解压后，建议先确认前端和后端的依赖文件都在，再按下面的顺序安装和启动。这套流程我在干净系统上跑过多次，顺序错了会出现前端页面 404 或者后端 API 连不上的情况。
3.2 后端启动：Python 虚拟环境与 uvicorn
后端是 FastAPI 应用，入口在backend/open_webui/main.py。直接往系统 Python 里装依赖容易把环境搞乱，血泪经验是先建虚拟环境：
cd OpenWebUI python -m venv venv source venv/bin/activate # Windows 下用 venv\Scripts\activate pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple这里要求 requirements.txt 存在，实际上 Open WebUI 用 pyproject.toml 管理依赖，官方源码里可能没有 requirement s.txt，需要改用 pip install -e . 安装。安装完成后启动后端：
python -m open_webui默认端口是 8080，启动成功的日志会显示Uvicorn running on http://0.0.0.0:8080。这里有两个关键参数：--port改端口，--host改监听地址。跨机器访问时一定要--host 0.0.0.0：
python -m open_webui --host 0.0.0.0 --port 8080后端启动后先别急着开浏览器，用 curl 探一下健康检查接口：
curl http://localhost:8080/health返回{"status":true}说明后端活着。这个健康检查接口在排错时非常有用，它能区分“后端挂了你不知道”和“前端页面起了但连不上后端”这两种情况。后端进程不要关，开一个新的终端窗口继续前端部分。
3.3 前端构建：Node.js 版本与 npm install 的坑
Open WebUI 的前端是 Svelte 项目，开发模式下可以走 Vite 热更新，但更稳的方式是构建静态文件、让后端直接伺服。前端构建前先确认 Node 版本，低版本会在npm install阶段报各种语法错误——常见坑是 Node 18 以下跑不动 Svelte 5 的构建链。
node -v # 需要 >= 18，建议 20+ npm install --registry=https://registry.npmmirror.com npm run buildnpm install会生成node_modules目录，体积很大，正常现象。国内网络建议带上 npmmirror 源，否则个别依赖包下载会比较慢。npm run build执行的是构建脚本，产物输出到frontend/dist或build目录，具体看 package.json 里的配置。
构建完成之后，重启一次后端——因为后端只在启动时检查前端构建产物是否存在，如果构建在启动之后才完成，后端不会自动去读新产物。重启命令还是那条python -m open_webui。这时候浏览器访问http://localhost:8080，就能看到 Open WebUI 的注册页面。
提示：如果构建了前端但仍然显示默认欢迎页或者样式错乱，八成是构建产物路径和后端静态目录路径对不上，检查
backend/open_webui/static.py里的路径声明。
3.4 环境变量与首次登录：OLLAMA_BASE_URL 是关键
Open WebUI 启动后第一件正事是把 Ollama 连上。源码部署的话，环境变量在启动前设置，不能用页面来配。在虚拟环境里启动前，先设置：
export OLLAMA_BASE_URL=http://localhost:11434 export WEBUI_AUTH=false python -m open_webuiOLLAMA_BASE_URL告诉 Open WebUI 去哪里找 Ollama 服务。如果 Ollama 在别的机器上，这里填那台机器的 IP，比如http://192.168.1.100:11434。WEBUI_AUTH=false表示首次访问跳过注册登录流程，直接进聊天页面——单机自用可以这么干，多人使用必须开启认证，否则任何人都能访问你的模型服务。
支持的外部连接环境变量还有这几个，统一用OPENAI_API_*前缀：
export OPENAI_API_BASE_URLS="https://api.deepseek.com/v1" export OPENAI_API_KEYS="sk-你的key"这个后面接 Deepseek 云端 API 时会用到。填入后，Open WebUI 的模型选择器里会多出一个外部模型组，来源显示 Deepseek。
首次进页面的路径建议这样走：注册管理员账号（如果开了认证）→ 左下角设置 → 外部连接 → 确认 Ollama 连接器的 URL 是http://localhost:11434→ 模型列表里应该能看到deepseek-r1:7b。如果模型列表为空，先回终端检查后端日志，多半是地址写错或 Ollama 没监听对应网卡。
4. 把 Deepseek 接进 Open WebUI：模型参数、外部 API 与反向代理
4.1 Deepseek-R1 的思考链：在界面上打开和关闭
Deepseek-R1 是推理模型，回答前会生成一段内部思考过程。在 Open WebUI 里，这段思考会单独呈现在回复上方，有时还会搭配一个可折叠的“思维链”区域。对调试问题很有用，但对日常问答，冗长的思考链会拖慢输出体验。
在 Open WebUI 里控制它的位置在“模型设置”里，针对某个模型单独配置。拉取模型后，点击模型名称旁的设置图标，进入高级参数面板。这里有几个参数会影响 R1 的表现：Temperature默认 0.7，调低到 0.3 左右，回答会稳定很多但创造力下降；Top P默认 0.9，配合低 Temperature 使用；Max Tokens对 R1 尤其重要，因为它的思考过程也要占用 token 配额，默认 4096 可能让长回答被截断，建议拉到 8192。
关闭或展开思考链，Open WebUI 提供的是显示层面的控制，不是模型 API 的参数。如果页面上没有看到折叠按钮，检查是否开启了“流式输出”，关闭流式输出会导致思考过程一次性渲染，没法折叠。
注意：Ollama 侧的
OLLAMA_NUM_PARALLEL参数控制同一时刻能并行处理的请求数量，默认 4。Deepseek 模型并发过高时显存会爆，OOM 错误在日志里表现为out of memory，此时不是调低并行数，而是要降低每请求的上下文窗口。
4.2 用 OpenAI 兼容格式接入外部 Deepseek API
本地模型的显存跑不动 70b 时，可以注册 Deepseek 官方 API，把云端大模型也接进 Open WebUI。这一步用的就是前面提到的OPENAI_API_BASE_URLS和OPENAI_API_KEYS。Deepseek 的 API 端点也是 OpenAI 兼容的，填两个环境变量即可。
export OPENAI_API_BASE_URLS="https://api.deepseek.com/v1" export OPENAI_API_KEYS="sk-填写你的真实key" python -m open_webui重启后，页面模型选择器里会出现deepseek-chat和deepseek-reasoner这两个模型，前者对应 Deepseek-V3，后者对应 R1 系列。这个配置下，Open WebUI 相当于一个聚合网关：本地跑 Ollama 的模型，云端跑 Deepseek 的模型，统一在同一个聊天界面里切换。
外部 API 接入最容易出的问题是 base URL 写不对。Deepseek 的文档里明确写的完整路径是https://api.deepseek.com/v1，不要在末尾加/chat/completions。Open WebUI 拼接请求时，会在这个 base URL 后面自动追加路径，加多了就会 404。另一个陷阱是 key 本身，Deepseek 控制台创建的 key 以sk-开头，复制时注意别带空格和换行。
4.3 Nginx 反向代理 Ollama：让 WebUI 和模型不在同一台机器
有些场景下 Open WebUI 和 Ollama 不能装在一台机器。比如模型服务器是带 GPU 的 Ubuntu，而 Open WebUI 跑在另一台商业服务器上；或者 Ollama 不希望直接暴露 11434 端口给局域网。这时用 Nginx 做反向代理是常见做法，既能把端口藏起来，也能在代理层加访问控制。下面是一个实际可用的 Nginx 配置：
server { listen 11434; server_name _; location / { proxy_pass http://127.0.0.1:11434; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; # Ollama API 的流式输出需要关闭缓冲，否则对话体验会变成一个字一个字卡着出 proxy_buffering off; proxy_read_timeout 600s; } }比较重要的一项：proxy_buffering off;必须开。Ollama 的/api/chat接口默认走 SSE 流式返回，Nginx 默认会缓冲响应，导致用户在页面上看到整个回复一次性刷出来，流式体验完全丧失。proxy_read_timeout 600s是因为 7b 模型在纯 CPU 机器上生成一段回答可能需要一两分钟，默认 60s 超时会被频繁打断。
如果代理层还需要 API key 保护，可以在 Nginx 上用auth_request指向一个校验服务，或者在 Ollama 侧设置OLLAMA_API_KEY（新版本支持）。设了 key 之后，Open WebUI 的 Ollama 连接器地址和密钥都要对应填上，否则页面会报 401。这个 401 看起来像是在说模型不存在，实际是身份校验没过，排查时先看后端日志的 HTTP 状态码。
5. 部署 Open WebUI 的常见问题排查：从 ZIP 错误到 401
5.1 ZIP 解压失败“could not find eocd”
现象：用系统自带的解压工具打开下载的 ZIP 包，直接报invalid zip archive: could not find eocd，或者解压到一半提示文件损坏。
原因：GitHub Releases 的文件走 CDN，浏览器下载大文件容易被中断，中断后文件尾部缺失。ZIP 格式的关键索引区（EOCD，End of Central Directory）就在文件末尾，尾部缺字节，索引就找不到。
解决：用终端下载代替浏览器。Windows PowerShell 里执行：
curl.exe -L -o OpenWebUI.zip https://github.com/你的地址/releases/download/tag/OpenWebUI.zip下载完先看文件大小和 GitHub 页面标注的 size 对不对，再用压缩软件测试完整性。我一般会再用 PowerShell 算一下哈希值，和页面提供的 SHA256 比对，一致才解压。这个习惯帮我避开过好几次下到半截文件还硬着头皮解压的翻车。
5.2 模型全下到了 C 盘
现象：Ollama 正常拉取模型，但 C 盘空间飞速下降，ollama list显示的模型大小没问题，但磁盘容量告急。
原因：没有提前改OLLAMA_MODELS，模型默认落到用户目录下。特别是在 Windows 上，C:\Users\xxx\.ollama\models里全是几个 GB 的 blob 文件。
解决：改环境变量之后需要迁移已有模型。把整个.ollama目录从 C 盘剪切到新盘，然后在系统环境变量里设OLLAMA_MODELS=D:\ollama_models（指向新位置）。再重启 Ollama 服务。不要只复制 models 子目录，因为.ollama下还有 id 索引和其他配置，缺了会导致ollama list显示空。
5.3 WebUI 能看到 Ollama 但看不到模型
现象：Open WebUI 的“外部连接”里 Ollama 连接器状态正常，但模型选择器里没有任何模型。
原因：OLLAMA_HOST没有放开监听。默认 Ollama 只监听127.0.0.1:11434，如果 Open WebUI 容器或进程在别的网络命名空间里访问，就连不上。另一个常见原因是 Open WebUI 是在 Ollama 拉模型之前启动的，它启动时会拉一次模型列表，之后没有自动刷新。
解决：先确认服务端连通性，在 Open WebUI 所在机器上执行：
curl http://你的OllamaIP:11434/api/tags能返回 JSON 列表说明网络通，那就在 Open WebUI 页面上点一次刷新按钮；如果返回 connection refused，去 Ollama 机器检查OLLAMA_HOST是否设置成了0.0.0.0，并确认防火墙没有拦截 11434 端口。
5.4 Nginx 反代后连接被拒绝
现象：Open WebUI 填了 Nginx 代理地址后报 502，直接访问代理地址也显示错误页。
原因：Nginx 配置里proxy_pass http://127.0.0.1:11434指向的地址，在 Nginx 所在机器上没有 Ollama 服务。很多人在模型服务器上配置 Nginx 时忘了把 11434 监听在0.0.0.0，Nginx 通过回环地址访问时被拒绝。
解决：在 Nginx 所在机器上执行curl http://127.0.0.1:11434/api/tags，失败说明 Ollama 只监听了外部网卡或者根本没起服务。检查 Ollama 日志，确认启动参数里OLLAMA_HOST是0.0.0.0还是具体 IP。如果 Ollama 在另一台机器，Nginx 的proxy_pass应该写那台机器的 IP 而不是 127.0.0.1。
5.5 环境变量改了但不生效
现象：在/etc/environment或 Windows 系统变量里设置了OLLAMA_KEEP_ALIVE，但ollama ps看到的模型驻留时间还是默认 5 分钟。
原因：Ollama 作为 systemd 服务运行时，/etc/environment的变量不能传递到服务进程。Windows 上也一样，服务启动时读取的是服务启动瞬间的环境快照，改完环境变量后服务没重启。
解决：Linux 上必须显式在 service 配置里写 Environment：
sudo systemctl edit ollama.service写入：
[Service] Environment="OLLAMA_KEEP_ALIVE=24h"然后确认生效：
sudo systemctl daemon-reload sudo systemctl restart ollamaWindows 上改完环境变量，在“服务”管理器里重启 Ollama 服务，或者直接重启系统最稳妥。验证方式是在 Open WebUI 的模型参数里改 Keep Alive，或者在终端直接查ollama ps看模型的驻留时间列。
6. 用 curl 验证整条链路：从模型层到界面层的一次健康检查
部署完成不等于万事大吉，我习惯按“模型层 → 接口层 → 界面层”三层做一次完整验证。模型层验证的是 Ollama 本身能正常出结果：
curl http://localhost:11434/api/chat -d '{"model":"deepseek-r1:7b","messages":[{"role":"user","content":"你好"}],"stream":false}'重点看响应里是否包含"done":true和完整的message.content。stream:false表示不流式返回，方便在终端看到完整 JSON；日常对话走的是流式，但这个验证用非流式更直观。接口层验证的是 Open WebUI 后端到 Ollama 的连接是否正常：
curl http://localhost:8080/api/models -H "Authorization: Bearer 你的token" | grep deepseek能 grep 到deepseek-r1:7b，说明 Open WebUI 已经成功列出了模型。这一步能区分问题出在 WebUI 的配置还是出在底层连接。界面层就不用多说了，浏览器里开一个新对话，选deepseek-r1:7b，让它写一段带条件的代码——比如“写一个 Python 函数，输入是日期字符串列表，输出是去重后的最大日期”。R1 的思考链会先展开，然后给出代码。思考链的展开与折叠、代码高亮、复制按钮，这些功能正常就说明整条链路通了。
最后说一个调试技巧：Open WebUI 的后端日志里能看到每一次请求的耗时和状态码。如果感觉对话响应慢，先看日志里POST /api/chat的耗时，超过 30 秒就要检查模型加载时间和 KV cache 大小。我在第一次部署时忽略了模型冷启动时间，总以为是网络问题，翻了好几天日志才发现是模型权重加载到内存要十几秒。从那以后，我每次改完配置都强制走一遍上面三条 curl 命令，确认每一层都响应正常才关终端窗口。希望帮到你。
本文还有配套的精品资源，点击获取
