在本地部署大模型时，单独执行一条 Docker 命令并不困难，真正棘手的是模型文件如何长期保存、多个模型如何统一加载，以及上层应用如何稳定连接推理服务。Docker Compose 可以把 Ollama、模型初始化任务和业务应用组织成一个可重复部署的服务栈，让环境迁移、故障恢复和配置维护更加清晰。本文给出一套适合开发与小型内部环境的实践方案。🚀
一、为什么选择 Ollama 与 Docker Compose
Ollama 提供统一的模型下载、运行和 API 调用方式，应用通常通过 11434 端口访问服务。容器化后，无须在宿主机直接安装 Ollama 运行环境；Docker Compose 则负责声明镜像、端口、存储卷、网络、健康检查和启动依赖。相比零散的 docker run 命令，Compose 文件更容易纳入版本管理，也更适合多人协作。
需要注意，“多模型编排”并不等同于同时启动多个 Ollama 容器。更常见的方式是由一个 Ollama 服务管理多个模型，上层应用在请求中指定模型名称。这样可以共享模型存储目录，减少重复文件，同时保留按任务选择对话、代码、嵌入或视觉模型的能力。
二、设计服务与持久化结构
建议将服务拆分为三个角色：
- ollama：提供模型管理与推理 API。
- model-init：首次启动时拉取所需模型，完成后退出。
- app：可选的 Web UI、知识库或业务接口，通过容器网络访问 Ollama。
模型数据应挂载到容器内的 /root/.ollama。Ollama 官方 Docker 示例也采用该目录保存模型文件，可参考 Ollama Docker 文档。使用 Docker 命名卷后，即使删除并重新创建 Ollama 容器，模型数据仍会保留；只有显式删除卷时，相关数据才会消失。Docker 对卷生命周期和适用场景的说明可查看 Volumes 官方文档。
三、编写 Compose 配置
下面是一份基础配置示意。实际模型名称应根据设备资源和业务需求调整，不要一次拉取大量暂时不会使用的模型。
services:
ollama:
image: ollama/ollama:latest
container_name: ollama
restart: unless-stopped
ports:
- "11434:11434"
volumes:
- ollama-data:/root/.ollama
healthcheck:
test: ["CMD", "ollama", "list"]
interval: 10s
timeout: 5s
retries: 12
model-init:
image: ollama/ollama:latest
depends_on:
ollama:
condition: service_healthy
environment:
OLLAMA_HOST: 来源链接
volumes:
- ollama-data:/root/.ollama
entrypoint: ["/bin/sh", "-c"]
command: ["ollama pull llama3.2 && ollama pull nomic-embed-text"]
restart: "no"
volumes:
ollama-data:
这里使用服务名 ollama 作为容器网络中的主机名。model-init 不应请求 localhost，因为容器内的 localhost 指向该容器自身。通过设置 OLLAMA_HOST，它可以连接真正的推理服务。健康检查通过后再执行模型拉取，可以避免 Ollama 进程尚未就绪时初始化任务直接失败。Compose 对 depends_on 与 service_healthy 的行为说明见 启动顺序官方文档。
四、启动并验证多模型环境
将配置保存为 compose.yaml 后，可按顺序执行以下操作：
- 运行 docker compose up -d ollama，先启动推理服务。
- 运行 docker compose run --rm model-init，拉取预设模型。
- 运行 docker compose ps，检查容器状态与健康结果。
- 运行 docker compose exec ollama ollama list，确认模型已经写入持久化目录。
- 请求 GET /api/tags，验证应用能否读取当前模型列表，接口格式可参考 Ollama API 文档。
调用生成接口时，只需在请求体中更换 model 字段即可切换模型。例如，普通对话请求指向生成模型，知识库向量化请求则指向嵌入模型。模型是否能够同时驻留内存，由可用内存、显存、模型规模和运行参数共同决定，因此“已经下载多个模型”并不意味着这些模型会永久同时占用计算资源。💡
五、GPU 配置与资源控制
纯 CPU 环境可以直接使用基础镜像，但响应速度与模型规模会受到处理器和内存限制。NVIDIA GPU 环境需要先正确安装 NVIDIA 驱动及 NVIDIA Container Toolkit，再在 Compose 中声明 GPU 设备；AMD GPU 的镜像标签与设备映射方式不同，应以 官方 Docker 部署说明为准。
实际部署前，应先用较小模型验证链路，再逐步增加模型规模。如果宿主机资源有限，可以避免并发加载多个大模型，并根据业务限制请求并发数。还可以使用 docker compose exec ollama ollama ps 查看当前加载的模型及处理器使用情况，便于判断模型是否运行在 CPU、GPU或混合资源上。⚙️
六、备份、升级与安全注意事项
持久化不等于备份。命名卷虽然独立于容器生命周期，但磁盘损坏、误删卷或宿主机迁移仍可能造成数据丢失。建议定期停止写入任务，将 ollama-data 卷归档到受控备份位置，并记录模型名称、版本标识与自定义 Modelfile。恢复时先创建卷、还原数据，再启动服务并执行模型列表检查。
升级镜像时，可先执行 docker compose pull，随后使用 docker compose up -d 重建容器。不要在生产环境无评估地长期依赖 latest 标签，较稳妥的做法是固定经过验证的镜像版本，并在测试环境确认 API、模型加载和 GPU 兼容性。
如果仅供本机或内部应用使用，不建议直接把 11434 端口暴露到公网。可以将端口绑定到本地地址，或通过反向代理增加身份认证、HTTPS、访问日志和请求限流。对于包含敏感数据的请求，还应明确日志保存范围，避免提示词或模型输出被无意记录。🔐
总结
使用 Docker Compose 接入 Ollama，核心并不是简单地启动一个容器，而是建立可维护的模型服务体系：用命名卷保存模型，用初始化服务声明模型清单，用健康检查控制启动顺序，再由业务应用通过内部网络按名称选择模型。在此基础上补充 GPU 配置、资源限制、卷备份、版本固定和访问控制，就能形成一套可重复部署、便于迁移且适合持续迭代的多模型运行方案。
