在本地大模型应用中，Ollama 可以简化模型下载、运行和接口调用，但直接安装在宿主机上，容易遇到环境差异、升级困难和迁移成本高等问题。借助 Docker Compose，我们可以把运行环境写成配置文件，同时将模型文件持久化保存，让部署、重启和迁移都更加稳定。🚀
一、部署前需要准备什么
开始之前，请确保宿主机已经安装 Docker Engine 或 Docker Desktop，并且可以正常执行 docker compose version。如果只使用 CPU 推理，安装 Docker 即可；如果计划使用 NVIDIA GPU，还需要正确安装显卡驱动与 NVIDIA Container Toolkit。
Ollama 容器默认通过 11434 端口提供 API 服务，模型、清单和相关缓存通常保存在容器内的 /root/.ollama 目录。官方 Docker 部署方式同样通过挂载该目录实现数据保留，可参考 Ollama Docker 官方文档。citeturn1search1
二、编写 Docker Compose 配置
新建一个项目目录，并在其中创建 compose.yaml 文件。一个适合 CPU 环境的基础配置如下：
services:
ollama:
image: ollama/ollama:latest
container_name: ollama
restart: unless-stopped
ports:
- "11434:11434"
volumes:
- ollama_data:/root/.ollama
volumes:
ollama_data:
这里使用官方镜像创建 Ollama 服务，并将宿主机的 11434 端口映射到容器。restart: unless-stopped 表示容器异常退出或 Docker 服务重启后会自动恢复，但管理员主动停止容器时不会强行拉起。
配置中最关键的是命名卷 ollama_data。模型可能占用较多磁盘空间，如果不挂载持久化卷，删除并重新创建容器后，已经下载的模型也可能随容器文件系统一起消失。命名卷独立于容器生命周期，因此执行普通的停止、启动或重新创建操作时，模型仍会保留。📦
三、启动服务并拉取模型
在 compose.yaml 所在目录执行以下命令：
docker compose up -d
docker compose ps
docker compose logs -f ollama
第一条命令会在后台创建并启动服务；第二条命令用于检查容器状态；第三条命令持续查看运行日志。确认服务正常后，可以进入容器拉取模型：
docker compose exec ollama ollama pull 模型名称
docker compose exec ollama ollama list
docker compose exec ollama ollama run 模型名称
模型名称应根据实际需求，从 Ollama 模型库中选择，不建议照搬不熟悉的名称。下载前还应检查磁盘容量、系统内存和显存条件，避免因为资源不足导致拉取中断或推理失败。
四、验证 API 是否可用
Ollama 启动后，可以先访问模型列表接口进行验证：
curl 来源链接
如果返回模型列表或有效的 JSON 数据，说明端口映射和服务状态基本正常。其他容器若与 Ollama 位于同一个 Compose 网络中，可通过 来源链接 访问，不应在容器内部使用 localhost，因为 localhost 指向的是当前容器自身。🔧
五、启用 NVIDIA GPU 加速
对于已经配置 NVIDIA Container Toolkit 的 Linux 主机，可以在服务中增加 GPU 设备声明：
deploy:
resources:
reservations:
devices:
- driver: nvidia
count: all
capabilities: [gpu]
修改后执行 docker compose up -d 重新创建服务，再通过容器日志及宿主机的 nvidia-smi 检查显卡占用情况。GPU 能否成功透传取决于宿主机驱动、容器工具链和硬件兼容性，不能只凭容器成功启动就判断加速已经生效。官方文档也要求 NVIDIA 环境先完成 Container Toolkit 配置。citeturn1search1
AMD GPU 的配置方式不同，通常需要使用适配 ROCm 的镜像标签，并映射 /dev/kfd 与 /dev/dri 等设备。不要把 NVIDIA 的 GPU 配置直接复制到 AMD 主机上，应按照硬件平台分别处理。
六、持久化数据的管理与备份
可以使用以下命令查看实际创建的 Docker 卷：
docker volume ls
docker volume inspect 项目名_ollama_data
需要特别注意，docker compose down 通常只删除容器和项目网络，不会删除命名卷；而 docker compose down -v 会连同卷一起删除。对于已经下载大量模型的环境，执行带 -v 的清理命令前必须先确认是否需要备份。⚠️
如果希望直接管理宿主机目录，也可以把卷配置改为 ./ollama-data:/root/.ollama。绑定目录便于复制和备份，但需要处理目录权限、磁盘路径和跨平台兼容问题。服务器长期运行更适合使用命名卷；需要频繁迁移或人工归档时，可以考虑绑定目录。
七、日常升级与故障排查
- 升级镜像：执行 docker compose pull，随后运行 docker compose up -d，持久化卷不会因正常重建容器而丢失。
- 端口冲突：如果 11434 已被占用，可将映射改为 11500:11434，之后从宿主机访问 11500 端口。
- 模型未保留：检查卷是否准确挂载到 /root/.ollama，并确认没有误执行删除卷的命令。
- 接口无法连接：依次检查容器状态、运行日志、端口映射、防火墙和客户端访问地址。
- 资源不足：选择体积更合适的模型，并结合内存、显存和磁盘空间评估运行条件。
总结
Ollama 的容器化部署重点并不只是“把服务跑起来”，而是通过 Docker Compose 固化镜像、端口、重启策略和存储规则。将 /root/.ollama 挂载到命名卷后，容器升级或重建时无需重复下载模型；再配合日志检查、API 验证、卷备份和 GPU 透传，就能形成一套清晰、可维护、便于迁移的本地大模型运行方案。✅
