Docker化部署Ollama：从模型管理到WebUI编排的完整实践-代码聚汇网

Docker化部署Ollama：从模型管理到WebUI编排的完整实践

超级简历WonderCV·2026-09-07·阅读 23 GEO检测（免费）

DockerOllama模型部署

|难度：普通|阅读约 36 分钟

1. 为什么我最终选择Docker化部署Ollama

先说结论：如果你的主力机器是Windows，又时不时在Linux服务器之间切换，或者总想把模型、配置、Web界面一次性打包带走，那用Docker部署Ollama几乎是唯一省心的方式。

我第一次接触Ollama是直接在Windows上装的原生安装包。当时觉得没什么问题，双击安装，命令行里ollama run qwen2.5就能跑起来，模型文件默认丢到C:\Users\用户名\.ollama\models。但用着用着就开始难受了：C盘空间告急，想给模型换个磁盘目录得去改环境变量，换一台电脑就得重新走一遍安装流程。最要命的是，一旦我想在网页端管理模型或者接入其他工具，就要在一台机器上同时装好几个服务，环境乱成一锅粥。

后来我把Ollama塞进了Docker容器，这些问题基本都消失了。Docker化的核心价值不是“看起来更高级”，而是把Ollama运行时、模型文件、依赖环境全部隔离在容器里，宿主机器上不留任何残余文件。升级Ollama版本只需要重新拉一个镜像标签，回滚也只是一条命令的事。模型文件通过挂载目录放在任意磁盘位置，目录结构一目了然，再也不用满C盘找文件。

最关键的是，Docker版本在Windows、macOS、Linux上的行为完全一致。我在Windows上用Docker Desktop跑通的容器配置，原封不动搬到Ubuntu服务器上直接可用，没有任何“换个系统就报错”的适配成本。这篇文章就按我实际操作的流程，把从零部署到模型管理、Web界面编排的完整过程写清楚，包括所有踩过的坑和解决办法。

适合看这篇的读者主要有三类：一是本地磁盘吃紧、想把模型放到其他盘的人；二是搞不定Ollama下载速度、需要换国内镜像源的人；三是想在Docker里把Ollama和其他服务（比如Open WebUI）一键编排起来的人。下面直接进入部署实操。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 部署前置准备：Docker环境与镜像加速一次配到位

2.1 Docker Desktop安装时的几个关键勾选

Docker版的Ollama本身不挑Docker实现，关键是你的Docker环境是不是能正常用。Windows平台最主流的做法是安装Docker Desktop，但很多人卡在第一步：安装包下载慢、装完启动不了。

Docker Desktop的安装过程本身没有太多门槛，无非是下一步下一步。我提醒三个容易被忽略的点：

安装时勾选“Use WSL 2 instead of Hyper-V”。WSL 2的内存管理更好，启动速度也比Hyper-V快，Ollama这类需要吃内存的应用跑在WSL 2后端更稳。
安装完成后，在Settings -> General里确认“Use the WSL 2 based engine”处于打开状态。有些机器默认用的是Windows容器模式，会导致拉取Linux镜像时报“no matching manifest”。
如果安装包下载很慢，去官网找国内CDN镜像地址或者用离线安装包。这个问题网上讨论很多，不再展开，但离线包确实能省不少时间。

装完后打开一个终端，执行：

bash复制docker version

能同时看到Client和Server版本信息，就说明Docker引擎已经正常启动了。如果只看到Client，说明Docker Desktop的后台服务没起来，去把Docker Desktop重新启动一下。

2.2 国内镜像加速源配置：解决Docker镜像下载慢

Docker部署Ollama绕不开的一个问题是：从Docker Hub拉镜像的网速可能很慢。尤其是ollama/ollama这个镜像，体积虽然不算大（几百MB级别），但默认从Docker Hub拉取时经常出现连接超时或者进度条半天不动。

解决办法是配置镜像加速器。Docker Desktop的用户可以在Settings -> Docker Engine里修改json配置，加入国内镜像源地址。我自己用的配置大致是这个结构：

json复制{
  "registry-mirrors": [
    "https://docker.1ms.run",
    "https://docker.xuanyuan.me"
  ]
}

改完点“Apply & Restart”，Docker引擎会带着新配置重启。之后拉取镜像会走加速源，速度提升非常明显。

注意：镜像加速源只对Docker Hub的镜像生效，不影响Ollama模型文件的下载。模型下载慢的问题在第4部分单独讲。

2.3 给Docker分配足够的内存和CPU资源

Ollama跑大模型非常吃内存和CPU，尤其是现在主流的7B、14B模型，量化后也要5-8GB内存。Docker Desktop默认给WSL 2分配的内存可能只有2GB左右，如果不调大，容器启动后模型加载到一半就可能被系统杀掉。

打开Docker Desktop的Settings -> Resources，把内存调到至少8GB，CPU留4核以上。我自己的机器是32GB内存，Docker分配了16GB，跑14B量化模型很从容。

如果你的模型超过20GB，建议把Swap也调大一点，防止内存峰值时容器被强制重启。

这步看着不起眼，但很关键。很多人容器起来了，ollama run命令也能执行，就是模型一加载就报“Killed”，十有八九是内存配额不够。

3. Ollama容器启动：run命令参数逐个拆解

3.1 拉取官方镜像与标签选择

环境准备好之后，直接拉取Ollama官方镜像：

bash复制docker pull ollama/ollama

这个命令会拉取latest标签的最新版本。如果你有版本洁癖，可以去Docker Hub的ollama/ollama页面查看所有标签，比如0.5.7、0.6.2这样的具体版本。生产环境建议锁定版本号，避免某天更新出问题不知道是哪次变更引起的。

比如：

bash复制docker pull ollama/ollama:0.6.2

不过对于个人部署，latest就够用了。镜像本身不大，拉取时间主要取决于网络。

3.2 最简启动命令：先跑通再说

镜像拉下来后，用一条命令就能把容器跑起来。我建议第一次先不要加一堆自定义参数，用最朴素的命令验证能否正常工作：

bash复制docker run -d \
  --name ollama \
  -p 11434:11434 \
  ollama/ollama

参数含义解释一下：

-d：后台运行容器。
--name ollama：给容器起个名字叫ollama，后续操作直接引用名字即可。
-p 11434:11434：端口映射。Ollama的API服务默认监听11434端口，把容器的11434端口映射到宿主机的同名端口，这样从外面的命令行或程序才能访问到容器里的服务。

启动后执行：

bash复制docker ps

能看到名为ollama的容器状态为Up，就说明服务已经起来了。再验证一下API是否响应：

bash复制curl http://localhost:11434

正常会返回一行Ollama is running之类的提示。

3.3 完整启动命令：模型目录挂载到宿主机

但上面这种最简启动方式有个问题：容器一旦删除，里面的模型文件全没了。而且我前面说过，模型文件默认存在用户目录，你不想在系统盘里堆积大量模型文件怎么办？

所以我在实际部署中，最终用的启动命令长这样：

bash复制docker run -d \
  --name ollama \
  -p 11434:11434 \
  -v D:/ollama/models:/root/.ollama/models \
  -v D:/ollama/uploads:/root/.ollama/uploads \
  ollama/ollama

这里的关键是把容器内部的/root/.ollama/models目录挂载到宿主机的D:/ollama/models。容器内的Ollama会把模型文件写到这个目录，实际上就是写在D盘，宿主机上的任何程序也可以直接访问这些文件。

第二个挂载点/root/.ollama/uploads是在较新版本中出现的，用于存放模型上传的临时文件，同样建议挂载到本地。

如果你用的是Linux服务器，挂载路径按Linux习惯写即可。比如：

bash复制-v /data/ollama/models:/root/.ollama/models

3.4 GPU参数：NVIDIA GPU怎么透传给容器

如果要跑较大体量的模型（比如14B以上），纯CPU推理速度会非常难受。NVIDIA用户可以在启动命令中加--gpus=all参数，把宿主机的GPU能力透传给容器：

bash复制docker run -d \
  --name ollama \
  --gpus=all \
  -p 11434:11434 \
  -v D:/ollama/models:/root/.ollama/models \
  ollama/ollama

但前提是：

宿主机必须已经安装了完整的NVIDIA显卡驱动。
Docker环境需要安装NVIDIA Container Toolkit（Windows Docker Desktop通常内置了支持，但Linux需要单独安装）。

确认GPU透传是否成功，可以在容器内执行：

bash复制docker exec -it ollama nvidia-smi

能看到显卡信息，就说明GPU已经生效了。之后模型加载时，Ollama会自动把推理任务放到GPU上执行。这个坑我踩过：在Windows Docker Desktop里，有时候需要先在Settings里打开“Enable GPU”开关，否则--gpus=all参数会报错或者被忽略。

4. 模型管理：拉取模型、本地导入与“装到D盘”的完整解法

4.1 模型下载太慢的解决思路

Ollama拉取模型的标准命令是：

bash复制docker exec -it ollama ollama pull qwen2.5

但“下载太慢”几乎是所有国内用户都会遇到的问题。模型文件动辄几GB，如果直接从官方源下载，速度可能只有几十KB/s，甚至经常失败。

这里分享几种亲测有效的方案，按推荐程度排序：

使用镜像站替换下载地址。Ollama模型下载走的是ollama.com/library的地址，但实际文件在registry.ollama.ai。很多国内镜像源想办法把这些模型文件做了缓存。你可以通过设置环境变量来改变模型下载源。比较常见的做法是配合一些开源代理项目，例如把默认的模型源指向一个国内可访问的镜像仓库。
手动下载模型文件再导入。如果你能找到GGUF格式的模型文件（比如在Hugging Face上），直接下载到本地，然后按4.3节的方法导入Ollama，绕开Ollama自带的下载机制。这个方法最稳，也是我目前主要用的方式。
用文件夹先下载再挂载。有些镜像站提供模型文件的直链，你用任意下载工具（比如IDM、迅雷）先把模型下载好，放到挂载目录下的models/manifests和models/blobs对应位置，然后重启容器。

实际经验是，方案2最可控。模型文件那么大，与其靠Ollama那套不一定稳定的下载机制，不如自己把文件拿稳了再交给Ollama管理。

4.2 Windows下把模型装到D盘的完整配置

因为容器已经把/root/.ollama/models挂载到了D:/ollama/models，你在容器里执行ollama pull下载的模型，实际上是直接写到了你的D盘目录。打开D:/ollama/models，你会看到类似这样的目录结构：

code复制models/
  blobs/
  manifests/
  models/

blobs目录存放的是模型文件的实际数据，默认是一堆没有扩展名的哈希文件名。
manifests目录记录模型的元数据，包括哪个模型对应哪些blob文件。
models目录通常是你在ollama create命令中指定的自定义模型存放位置（比如从Modelfile导入的模型）。

这个结构不需要手动改动，但了解之后，你就能清楚地知道模型装在哪里、占了多少空间。如果你想迁移模型到另一台机器，直接把这个目录整个拷贝过去，再在另一台机器上启动容器的同时挂载这个目录，模型就能无缝复用。

如果你之前已经使用过Windows原生版Ollama，模型放在C:\Users\用户名\.ollama\models，想迁移到D盘，可以直接把这个目录的内容剪切到D:/ollama/models，然后启动Docker容器时挂载新目录即可。注意Ollama版本之间的模型目录结构可能略有差异，最好保持同一版本的Ollama做迁移。

4.3 加载本地手工下载的模型

这个需求很常见：网上下载了一个GGUF格式的模型文件，比如qwen2.5-7b-instruct-q4_k_m.gguf，不想重新去Ollama仓库拉一遍。

加载逻辑不复杂，具体步骤如下。

把GGUF文件放到挂载目录下，比如D:/ollama/models/gguf（这个位置随意，但建议单独建个文件夹方便管理）。
把宿主机里的GGUF文件拷到容器内，或者直接利用挂载目录让容器能访问到。如果你挂载了D:/ollama/models:/root/.ollama/models，那GGUF文件放D:/ollama/models/gguf后，容器内的路径就是/root/.ollama/models/gguf。
执行ollama create命令创建模型条目：

bash复制docker exec -it ollama ollama create my-local-model -f /root/.ollama/models/gguf/Modelfile

其中Modelfile是一个文本文件，里面写了模型来源。最简单的Modelfile内容就一行：

dockerfile复制FROM /root/.ollama/models/gguf/qwen2.5-7b-instruct-q4_k_m.gguf

你也可以写更多参数，比如上下文长度、温度设置等。保存为Modelfile后，执行上面的create命令。命令执行成功后，ollama run my-local-model就能直接运行这个自定义模型。

提示：如果你的GGUF文件名或者路径里有空格，Modelfile的FROM行需要加上引号，不然会解析失败。

4.4 模型检查器：验证模型文件是否完整可用

模型下载完或者导入完，一定不要急着直接用，先做个检查。最基础的检查方式就是列出模型列表：

bash复制docker exec -it ollama ollama list

能看到模型名称、标签、大小等信息。接着可以查看模型详细信息：

bash复制docker exec -it ollama ollama show my-local-model

这个命令会显示模型的架构、参数量、量化类型、上下文长度等元数据。如果你之前从Hugging Face下载模型后自己写Modelfile导入，建议重点检查这里的输出是否符合预期。

真正跑起来做验证的方式是执行一次简单的生成请求。比如你想和它打个招呼：

bash复制docker exec -it ollama ollama run my-local-model "你好，请用一句话介绍自己"

反应慢的话，在命令后面加--verbose可以看到详细的推理耗时和内存占用。如果响应正常，说明这个模型文件本身没有损坏，Ollama加载也没有问题。

还有一个典型的检查场景：你从别处拷贝了一个模型目录到D盘挂载目录，但启动容器后ollama list看不到任何模型。这种问题大概率是因为manifest文件里的路径和blob文件的实际位置对不上。处理方法见第6部分，我会把这类问题单独拉出来讲。

5. 用Docker Compose把Ollama和Web界面编排在一起

5.1 为什么建议用Docker Compose管理

单跑一个Ollama容器，用上面的docker run命令足够。但实际使用中，大家几乎都会想再加一个Web管理界面，比如Open WebUI，这样可以在浏览器里选择模型、切换模型、管理会话，比在终端里敲命令舒服太多。

于是你的环境中就有两个容器：Ollama + Open WebUI。如果不做额外配置，这两个容器需要自己发现对方、在同一网络里通信，端口管理也会变得繁琐。Docker Compose就是为解决这种多容器编排问题设计的：写一份YAML文件，声明所有容器、网络、端口、挂载关系，然后一条命令全部启动。

5.2 一份可直接复制的Docker Compose配置

下面这份配置是我目前在用的，结构清晰，适合直接用：

yaml复制version: "3.8"

services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    ports:
      - "11434:11434"
    volumes:
      - D:/ollama/models:/root/.ollama/models
      - D:/ollama/uploads:/root/.ollama/uploads
    environment:
      OLLAMA_KEEP_ALIVE: "24h"
    restart: unless-stopped

  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    ports:
      - "3000:8080"
    volumes:
      - D:/ollama/open-webui:/app/backend/data
    environment:
      OLLAMA_BASE_URL: http://ollama:11434
    depends_on:
      - ollama
    restart: unless-stopped

把这份内容保存为docker-compose.yml文件，然后在文件所在目录执行：

bash复制docker compose up -d

等两个容器都启动后，浏览器访问http://localhost:3000就能打开Open WebUI界面，注册账号后，进入设置关联本地Ollama服务。由于Compose会自动创建内部网络，容器之间通过服务名ollama就能互相访问，不需要额外配置IP。

几个值得注意的细节：

OLLAMA_BASE_URL这里写的是http://ollama:11434，不是http://localhost:11434。因为在Docker内部网络中，服务名就是容器名，用localhost访问不到其他容器。
Open WebUI的数据也挂载到了本地D盘，这样你保存的历史会话不会随容器删除而丢失。
OLLAMA_KEEP_ALIVE设为24h，意思是模型在24小时内不会被从内存中卸载，频繁切换模型时响应更快。如果你内存紧张，可以去掉这个配置，让Ollama按默认策略管理模型生命周期。

5.3 多模型管理与“模型融合”说点实在的

有了Web界面，多个模型的管理就直观多了。你可以在界面上看到每个模型的参数量、占用空间、最近使用时间，切换模型只靠点击。

说到热搜词里的“模型融合”，在Ollama的语境下并不是把两个模型真正揉成一个，而是通过Modelfile把不同模型组合起来使用。最常见的做法是：

先用ollama pull拉一个基础模型。
再拉一个Embedding模型或者工具调用模型。
通过Modelfile和ollama create创建一条新记录，把基础模型与特定参数、系统提示词绑定到一个新名字上。

比如我可以创建一个“代码助手”专属模型：

bash复制docker exec -it ollama ollama create my-coder -f /root/.ollama/models/Modelfile_coder

Modelfile_coder内容：

dockerfile复制FROM qwen2.5-coder:7b
SYSTEM "你是一名资深软件工程师，回答编程问题时先给出方案再写代码。"
PARAMETER temperature 0.3
PARAMETER top_p 0.9

执行后，ollama list里会多一个叫my-coder的模型，它复用了基础模型的权重文件，没有额外占用太大磁盘空间，但行为和基础模型有明显区别。这种“模型融合”在Ollama生态里其实叫模型组装更准确，理解成“定制一个专属模型”也行。

6. 高频踩坑排查：从“启动失败”到“模型消失”的应对方案

6.1 拉取镜像时报“no matching manifest”

这个报错几乎都是Docker引擎跑在Windows容器模式下导致的。解决方法是打开Docker Desktop Settings -> General，勾选“Use the WSL 2 based engine”，重启后再试。

还有一种情况是镜像标签写错了，去Docker Hub确认一下标签名是否存在。ollama/ollama这个镜像的官方标签很常规，不存在什么特殊写法，所以重点还是检查引擎模式。

6.2 容器启动了但`curl localhost:11434`没响应

这个问题的排查链路要拉长。先看容器是否真的在运行：

bash复制docker ps | grep ollama

如果容器显示Up，但curl不通，重点检查端口映射是否正确。假如你启动时把宿主机端口写成了11435，那访问11434自然没用。可以用下面的命令看端口映射情况：

bash复制docker port ollama

如果容器根本没起来，用docker logs ollama看启动日志。Ollama容器启动时如果出错，日志里会写明原因，比如内存不足、挂载目录权限不对等。

我遇到过一次比较隐蔽的问题：挂载目录是Windows的D盘，但Docker Desktop在WSL 2后端下对D盘挂载偶尔会权限错乱，容器启动后日志里显示“permission denied”，把挂载目录换成Docker配置里已经共享过的目录路径就恢复了。

6.3 模型加载到一半报“Killed”或者OOM

这个问题在前面玩命强调过：Docker分配的内存不足。WSL 2后端下，Docker默认内存上限可能只有2GB，跑7B模型一定会OOM。解决方案如下：

打开Docker Desktop Settings -> Resources，把Memory调大，同时把Swap也调大。修改后容器需要重启，建议在修改之前先把Ollama容器停止，改完再启动：

bash复制docker stop ollama
# 修改Docker Desktop配置...
docker start ollama

如果你的模型确实太大（比如70B量化），就算宿主机内存充足，也建议分块或者用低量化版本。Docker Desktop毕竟不是裸机，还有一层虚拟化开销，内存分配要留出余量。

6.4 `ollama list`看不到从别处拷来的模型文件

这个坑最隐蔽。你辛辛苦苦从别的机器拷贝了整个D:/ollama/models目录，挂载到新容器后执行ollama list，结果一片空白。

原因通常不是文件目录不对，而是里的manifest文件记录的路径还指向原来机器上的路径。你手动检查manifest文件会发现，里面写的是JSON格式的配置，有一个path字段指向blob目录的具体位置。如果原来的机器把这个路径写成绝对路径，换了一台机器后路径不对，Ollama就无法识别模型列表。

解决办法有两个方向：

整体迁移时尽量保持目录结构完全不变。把整个models目录打包，解压到新机器的同一挂载路径下，然后保持挂载路径和manifest里的路径一致。这样最省事。
删除缺失的manifest，重新导入模型。找到models/manifests/registry.ollama.ai/library/模型名/标签这种结构的文件，删掉后执行ollama pull重新拉一遍，或者用4.3节的方法从GGUF文件重新create。

肯定是第一种方案省时得多，所以如果你要迁移模型，建议先压成一个tar包再移动，尽量避免路径变化。

7. 部署完成后的日常维护与使用心得

docker化部署真正跑起来之后，日常维护非常轻量，只有几个经常用到的命令。

更新Ollama版本时，不需要先卸载，直接：

bash复制docker pull ollama/ollama:latest
docker stop ollama
docker rm ollama
docker compose up -d

因为模型文件都挂载在宿主机上，容器删了重建不影响任何模型数据。这是我用Docker部署最舒服的一点——升级就像换了个空箱子，东西本身都留在原地。

查看当前有哪些模型在运行、每个模型的资源占用：

bash复制docker exec -it ollama ollama ps

清理不再使用的镜像和容器：

bash复制docker image prune
docker container prune

热词里还提到了“模型检查器”，除了前面说的ollama show和ollama list，你也可以通过API接口获取模型列表：

bash复制curl http://localhost:11434/api/tags

返回的JSON里包含所有已安装模型的信息，脚本化处理时会常遇到。

最后再分享一个我在实际使用中的体会：Docker部署Ollama最大的门槛不在技术，而在心态。很多人一看到命令行和YAML文件就觉得复杂，但真正按步骤操作一遍，会发现其实没有比双击安装包多多少步骤。好处却是长期的——模型文件位置可控、升级回滚方便、多服务编排标准化。如果你还在被模型下载慢、磁盘空间乱、环境冲突这些问题折磨，照着这篇从头走一遍，应该能把时间从“折腾环境”里省出来，花在真正想做的模型应用上。