从零开始构建强大 AI 对话系统：ollama + deepseek + open-webui 完整部署教程（Docker 版）

---

前言

在现代的人工智能应用中，基于模型的对话系统和开放式网络UI正逐渐成为越来越多企业和开发者的选择。本篇博文将为您详细讲解如何通过 Docker 部署 ollama、deepseek 和 open-webui，并结合使用 Docker Compose 实现更加高效、便捷的管理。

---

一、工具简介

在开始之前，我们先了解一下每个工具的功能和作用：

ollama

• ollama 是一个强大的对话生成模型，它支持多种自然语言处理任务，包括对话生成、问答、文本总结等。通过容器化部署，ollama 可以轻松地集成到开发环境中，提供一个灵活、可扩展的对话服务。

deepseek

• deepseek 是一个基于深度学习的语义理解模型，通常与对话系统一起使用。它能够根据用户的输入快速生成符合语义逻辑的回答，从而增强对话系统的准确性和响应速度。在本教程中，我们通过 ollama 运行 deepseek 模型，提供强大的对话能力。

open-webui

• open-webui 是一个开源的 Web 界面，用于与 AI 模型进行交互。通过它，用户可以通过浏览器与部署的 AI 模型进行实时对话，查看模型的输出结果。open-webui 提供了一个简洁、易用的 UI，方便用户快速集成和管理对话系统。

---

二、前期准备

在开始部署之前，首先确保系统中已安装好 Docker。若尚未安装，可以参考以下教程：
Windows 系统 Docker 安装教程（菜鸟教程）

Docker 是一个基于容器的轻量级虚拟化平台，能够帮助我们更轻松地部署和运行应用。

---

三、部署步骤

1. 安装并配置 ollama

可参考：

• ollama官网
• ollama 官方 docker 镜像

ollama 是一个强大的对话生成模型，支持多个版本的对话能力。在 Docker 中部署 ollama 是十分简单的。我们首先需要从 Docker Hub 上拉取 ollama 的镜像。

docker run -d -v D:/ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

-d：后台运行容器
-v D:/ollama:/root/.ollama：将本地文件夹挂载到容器内
-p 11434:11434：映射端口，方便外部访问
--name ollama：容器名称
ollama/ollama：镜像名

部署完成后，执行以下命令启动 deepseek 模型：

docker exec -it ollama ollama run deepseek-r1:1.5b

此时，系统已启动，进入容器后，你可以看到一个 >>> 的提示符，表示可以开始与模型进行对话了。

2. 部署 open-webui

接下来，我们将部署 open-webui，它是一个用于与 AI 模型交互的 Web 界面。只需要执行以下命令即可启动：

docker run -d -p 3000:8080 -e OLLAMA_BASE_URL=http://192.168.x.x:11434 -v D:/open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main

-p 3000:8080：将容器的 8080 端口映射到宿主机的 3000 端口
-e OLLAMA_BASE_URL=http://192.168.x.x:11434：配置 ollama 服务的基础 URL 地址（此处 192.168.x.x 请替换为本机 IP 地址）
-v D:/open-webui:/app/backend/data：挂载本地目录到容器
--name open-webui：容器名称
--restart always：容器异常退出后自动重启

可使用 ip a （Linux）或 ipconfig （Windows）命令查看本机 ip 地址。

四、调试与验证

完成部署后，可以通过浏览器访问 http://localhost:3000 进入 open-webui。在这个 Web 界面上，你可以与 deepseek 模型进行交互。

登录进去后，左上角选择模型。

五、Docker Compose 简化部署

为了让部署过程更加自动化和易于管理，我们可以将以上命令封装到一个 docker-compose.yml 文件中。通过 Docker Compose，我们可以实现一次性启动整个应用栈。

以下是 docker-compose.yml 文件的示例：

version: '3'services:ollama:image: ollama/ollamacontainer_name: ollamaports:- "11434:11434"volumes:- ./ollama:/root/.ollamacommand: ollama run deepseek-r1:1.5brestart: alwaysopen-webui:image: ghcr.io/open-webui/open-webui:maincontainer_name: open-webuiports:- "3000:8080"environment:- OLLAMA_BASE_URL=http://ollama:11434volumes:- ./open-webui:/app/backend/datarestart: always

在文件夹中创建 docker-compose.yml，然后执行以下命令启动所有服务：

docker-compose up -d

Docker Compose 会根据 docker-compose.yml 文件自动拉取镜像、创建容器并启动服务。你只需要专注于应用的业务逻辑，无需手动管理每个容器。

六、注意事项与常见问题

在实际部署 ollama + deepseek + open-webui 的过程中，我遇到了一些问题和限制，特别是在硬件配置和性能方面。这里是我个人的一些使用经验和建议，供大家参考。

1. ollama run 500 报错

在 ollama run 在下载模型时出现 500 错误的情况。根据我的观察，这可能是因为 ollama 的官方网站或服务在某些时段遭遇了攻击或过载，导致无法正常处理请求。
虽然出现了 500 错误，但等待一段时间后问题会自动恢复。

2. 硬件配置对性能的影响

在使用 deepseek 时，我遇到了性能问题，特别是在硬件配置不达标的情况下，模型的表现会非常差。具体来说：

• 我尝试在一台 32 核 CPU、128GB 内存、机械硬盘的超融合集群的 虚拟机 上部署 8B 模型。结果，模型的表现极差，甚至出现了非常离谱的回答——比如问 7B 和 8B 模型的区别是什么，得到的答案居然是“这两台机器的区别”，完全是乱回答。

• 然后，在一台小米笔记本上部署测试，笔记本配置为 i5-7200U（4核），8GB 内存，SSD 硬盘。虽然这台笔记本的硬件配置远不如前述虚拟机，但 7B 模型 在这台机器上能正经回答关于 7B 和 8B 模型区别 这个问题，相比下效果好很多。

从中我得出结论，官方建议的硬件配置真的不容忽视，特别是对于 deepseek 这类计算量较大的模型。官方推荐的硬件配置和部署方案如果达不到，精度和准确度都会大打折扣。特别是硬盘方面，SSD 的作用显著，性能差距非常明显。

AI 模型分享、讨论、下载，开放社区 Hugging Face 里面可以找到很多建议

3. ollama 启动与 open-webui 调用速度差异

在测试过程中，我发现 直接使用 ollama 启动并与模型对话 的速度比通过 open-webui 调用 API 的速度要快得多。速度差距非常明显，直接启动 ollama 的响应时间更短，几乎可以立刻得到回复，而通过 open-webui 调用 API 时，响应时间则明显较慢。

至于为什么会有这种差异，我猜测是由于 open-webui 在前端和后端之间有额外的通信开销和数据处理，而直接启动 ollama 可以避免这些额外的延迟，直接与模型进行交互。但具体的原因可能还需要更深入的分析，涉及到 API 调用、网络请求等多个因素。

4. 内存不足导致的性能问题

由于笔记本的内存限制，1.5B 模型 + open-webui 的组合在使用过程中非常慢，尤其是在内存不足时，体验非常差。我曾在笔记本上运行 1.5B 模型，问一个简单的问题竟然等了 5 分钟，连续提问之后，甚至出现了 500 错误，导致 open-webui 服务挂掉（ollama 没挂）。

因为 open-webui 作为前端容器，它不仅需要处理用户的请求，还需要通过 API 与后端模型容器交互。这会导致以下几个因素：

• API 调用的额外开销：每次用户请求都需要通过网络与后端容器进行通信。如果系统内存不足，网络请求的延迟和处理时间会增加，容易出现超时、错误等问题，特别是在大量并发请求时，可能导致服务挂掉（如 500 错误）。
• 请求队列的积压：在内存不足的情况下，open-webui 可能会积压请求，导致响应变慢，最终无法及时处理所有请求，进而导致服务崩溃。

然而，ollama（和其中的 deepseek）容器在内存不够的情况下依旧能够稳定运行，不会像 open-webui 一样挂掉，并且单独提问也比在 open-webui 回答的速度快。这个现象可能与 open-webui 容器在处理大量 API 请求时的资源消耗有关，而 ollama 可能是通过更高效的资源管理，减少了对内存和 CPU 的依赖。

相比之下，ollama 容器直接运行模型，不依赖于外部的 API 调用，且可能具有以下优势：

• 内部资源管理更高效：ollama 在处理请求时，不需要通过复杂的前端请求-后端响应流程。它将整个流程封装在一个容器内，可能在内存和 CPU 使用上进行了更精简的优化。这使得即使在内存不足的情况下，它依旧能够较为稳定地运行。
• 直接与模型交互：当你直接与 ollama 容器进行交互时，数据传输的路径更短，计算更加集中，减少了外部请求和资源竞争的问题。
• 容错性较强：ollama 可能有更好的内存管理策略，比如缓存、分页加载或其他优化策略，能够在内存资源有限的情况下保持运行稳定。

5. 家用部署方案的困难

我原本的计划是把 deepseek 部署在家用环境中，以达到省电并保持高效的目标。然而，实际测试结果显示，这种方案在当前的硬件配置下似乎不可行。特别是在内存和硬盘的压力下，系统的响应速度和稳定性并没有达到预期效果。

所以，如果你计划在家用机器上运行类似的 AI 模型，尤其是 deepseek，建议你提前检查硬件配置，特别是 SSD 硬盘和充足的内存。

六、总结

通过以上步骤，我们已经成功地在 Docker 中部署了 ollama、deepseek 和 open-webui，并通过 Docker Compose 优化了整个部署过程。这一组合为开发者和 AI 研究人员提供了一个快速、高效的对话系统解决方案，可以方便地进行自定义开发与实验。

如果有任何问题，欢迎留言讨论！