1. 为什么需要 Docker 化部署 Ollama？
在本地安装 Ollama 确实简单快捷，但当我们真正要将大模型部署到生产环境时，就会遇到一系列棘手问题。我曾经在一个企业知识库项目中，因为直接使用本地安装方式，导致 CUDA 版本冲突让整个项目停滞了两天。这种教训让我深刻认识到 Docker 化部署的必要性。
1.1 本地安装的四大痛点
环境隔离问题是最常见的坑。上个月我帮一个团队排查问题，发现他们测试环境的 CUDA 11.8 与生产环境的 12.1 不兼容，导致模型推理结果不一致。这种环境污染问题在 Docker 部署中根本不会出现，因为每个容器都有独立的环境。
迁移成本同样不容忽视。记得有一次客户需要将服务从阿里云迁移到腾讯云，使用本地安装方式时，我们花了整整一天重新配置环境。而 Docker 部署只需要把镜像和 volume 拷贝过去，十分钟就完成了迁移。
服务管理的缺失也很致命。本地运行的 Ollama 进程如果崩溃，往往需要人工干预。我曾见过一个午夜报警，因为 Ollama 进程意外退出导致业务中断，运维人员不得不半夜爬起来手动重启。
运维体系整合的难度经常被低估。当企业已经有成熟的 Kubernetes 集群和监控系统时，本地安装的 Ollama 就像个"孤儿"，无法纳入统一的运维体系。上周有个客户就因为这个原因，不得不将运行了半个月的本地部署推倒重来。
1.2 Docker 部署的三大核心优势
环境一致性保障是最直接的价值。通过容器镜像，我们可以确保开发、测试、生产环境完全一致。上周我为一个金融客户部署时，使用相同的 Docker 镜像在三个环境一次性通过测试，客户都惊讶于这种丝滑体验。
资源隔离让系统更稳定。通过 cgroups 可以精确控制 CPU、内存用量。我在压力测试中发现，没有资源限制的 Ollama 容器在并发请求下会吃掉所有系统内存，导致宿主机崩溃。而合理的资源限制可以避免这种雪崩效应。
标准化运维是长期收益。Docker 天然支持健康检查、日志收集、指标监控等运维功能。上个月我们通过 Prometheus+Grafana 监控 Ollama 容器的 GPU 利用率，及时发现并解决了一个内存泄漏问题，这些在本地部署中实现起来要困难得多。
2. 基础环境准备与验证
2.1 Docker 环境配置
在 Ubuntu 22.04 上安装 Docker 时，我强烈建议使用官方源而非系统自带版本。上周我在一台新服务器上测试时，发现 Ubuntu 自带的 20.10 版本存在与 NVIDIA 容器工具集的兼容性问题。以下是经过验证的安装步骤：
bash复制# 卸载旧版本（如果有）
sudo apt-get remove docker docker-engine docker.io containerd runc
# 安装依赖
sudo apt-get update
sudo apt-get install \
ca-certificates \
curl \
gnupg \
lsb-release
# 添加Docker官方GPG密钥
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
# 设置稳定版仓库
echo \
"deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
# 安装Docker引擎
sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-compose-plugin
安装完成后，务必执行 docker run hello-world 验证基础功能。我遇到过因为 AppArmor 配置错误导致 Docker 无法正常运行的情况，这个简单的测试可以提前发现问题。
2.2 GPU 环境特殊配置
对于 NVIDIA GPU 用户，除了常规的驱动安装外，还需要特别注意两点：
驱动版本匹配：CUDA Toolkit 对驱动版本有严格要求。上个月我遇到一个典型问题：服务器安装了 535 版驱动，但 Ollama 需要 CUDA 12.2 对应的 525 驱动。通过以下命令可以检查兼容性：
bash复制nvidia-smi # 查看驱动版本
docker run --rm nvidia/cuda:12.2.0-base-ubuntu22.04 nvidia-smi # 验证容器内驱动
用户组权限：默认情况下只有 root 用户能访问 GPU 设备。建议将当前用户加入 docker 和 video 组：
bash复制sudo usermod -aG docker $USER
sudo usermod -aG video $USER
newgrp docker # 立即生效
对于 AMD GPU 用户，ROCm 的安装更为复杂。上周我在一台配备 RX 7900 XT 的机器上测试时，发现官方仓库的 ROCm 5.7 存在内核模块编译问题，降级到 5.6 才解决。建议使用以下命令验证 ROCm 安装：
bash复制/opt/rocm/bin/rocminfo # 查看GPU信息
/opt/rocm/opencl/bin/clinfo # 检查OpenCL支持
3. 容器化部署实战
3.1 CPU 基础部署方案
对于测试环境或没有 GPU 的机器，CPU 部署是最简单的入门方式。但即使是这种简单场景，也有几个关键点需要注意：
数据持久化：我强烈建议使用命名卷而非绑定挂载，除非你有特殊需求。上周一个客户因为直接挂载/home 下的目录，导致权限问题容器无法启动。安全做法是：
bash复制docker volume create ollama-data
docker run -d \
-v ollama-data:/root/.ollama \
-p 11434:11434 \
--name ollama \
ollama/ollama
端口冲突：11434 是 Ollama 的默认端口，如果冲突可以映射到其他端口。但要注意修改后所有 API 调用都需要相应调整：
bash复制-p 11435:11434 # 将容器端口映射到宿主机的11435
资源限制：即使是 CPU 模式，也应该设置内存限制。我在压力测试中发现，7B 参数的模型在无限制情况下可能占用超过 16GB 内存：
bash复制--memory=16g --memory-swap=16g # 禁止使用交换空间
3.2 NVIDIA GPU 加速方案
GPU 加速能显著提升推理速度，但配置不当会导致性能还不如 CPU。以下是经过实战验证的配置流程：
NVIDIA 容器工具集安装：除了官方步骤外，还需要验证运行时配置。执行以下命令检查：
bash复制sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker
docker run --rm --gpus=all nvidia/cuda:12.2.0-base-ubuntu22.04 nvidia-smi
容器启动参数：--gpus=all 并不是唯一选择。对于多卡机器，可以指定具体卡号：
bash复制--gpus='"device=0,1"' # 只使用前两张卡
性能调优：通过环境变量可以优化 GPU 利用率。我在测试中发现这些设置能提升 15% 左右的吞吐量：
bash复制-e NVIDIA_DRIVER_CAPABILITIES=compute,utility \
-e CUDA_CACHE_PATH=/root/.nv/ComputeCache
3.3 AMD GPU 特殊配置
AMD 的 ROCm 方案配置更为复杂，需要特别注意：
设备权限：除了常规设备文件外，还需要挂载 render 节点：
bash复制--device /dev/kfd \
--device /dev/dri/renderD128 # 根据实际设备号调整
环境变量：某些 AMD 显卡需要特定环境变量才能正常工作：
bash复制-e HSA_OVERRIDE_GFX_VERSION=10.3.0 # 针对RX 5700系列
镜像选择：必须使用带有 rocm 标签的专用镜像：
bash复制ollama/ollama:rocm
4. 生产环境优化策略
4.1 存储方案优化
原始方案使用的 Docker 卷虽然简单，但在生产环境中存在几个问题：
备份困难：Docker 卷的实际存储路径不透明。我建议改用绑定挂载到固定路径：
bash复制-v /mnt/ssd/ollama:/root/.ollama # SSD能显著提升模型加载速度
分层存储：对于大模型，可以将基础模型存储在 HDD，而把频繁访问的适配器放在 SSD：
bash复制-v /mnt/hdd/models:/root/.ollama/models \
-v /mnt/ssd/adapters:/root/.ollama/adapters
4.2 高可用配置
重启策略：unless-stopped 是基础，但对于关键服务应该结合监控：
bash复制--restart unless-stopped \
--health-cmd "curl -f http://localhost:11434 || exit 1" \
--health-interval 30s
资源隔离：除了内存限制，CPU 亲和性也很重要。将 Ollama 绑定到特定核心可以避免上下文切换开销：
bash复制--cpuset-cpus="0-3" # 使用前4个核心
4.3 安全加固
非特权运行：避免以 root 身份运行容器：
bash复制--user 1000:1000 \
--cap-drop=ALL \
--security-opt=no-new-privileges
网络隔离：如果只需要本地访问，可以限制网络：
bash复制--network host \ # 或者使用自定义bridge网络
-p 127.0.0.1:11434:11434
5. Docker Compose 工程化实践
5.1 完整配置示例
以下是我在一个实际生产环境中使用的 docker-compose.yml，支持 GPU 和健康检查：
yaml复制version: '3.8'
services:
ollama:
image: ollama/ollama
container_name: ollama
runtime: nvidia # 仅NVIDIA需要
deploy:
resources:
reservations:
devices:
- driver: nvidia
count: 1
capabilities: [gpu]
ports:
- "11434:11434"
volumes:
- /mnt/nvme/ollama:/root/.ollama
environment:
- NVIDIA_VISIBLE_DEVICES=all
- OLLAMA_KEEP_ALIVE=5m
restart: unless-stopped
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:11434"]
interval: 30s
timeout: 10s
retries: 3
5.2 多模型负载均衡
对于需要同时运行多个模型的场景，可以通过编排多个服务实现：
yaml复制services:
ollama-llama:
image: ollama/ollama
ports:
- "11435:11434"
volumes:
- /mnt/models/llama:/root/.ollama
command: ["ollama", "serve", "--model", "llama2"]
ollama-mistral:
image: ollama/ollama
ports:
- "11436:11434"
volumes:
- /mnt/models/mistral:/root/.ollama
command: ["ollama", "serve", "--model", "mistral"]
5.3 版本升级策略
模型和 Ollama 本身的升级需要谨慎处理：
bash复制# 拉取最新镜像
docker-compose pull
# 重建服务（保持数据卷）
docker-compose up -d --force-recreate
# 回滚到特定版本
docker-compose run ollama ollama pull llama2:<特定版本>
6. 性能监控与调优
6.1 GPU 监控方案
对于 NVIDIA GPU，推荐使用 dcgm-exporter + Prometheus：
yaml复制# docker-compose.yml 追加
monitor:
image: nvidia/dcgm-exporter
ports:
- "9400:9400"
environment:
- DCGM_EXPORTER_LISTEN=:9400
然后配置 Prometheus 抓取指标，可以监控显存使用率、GPU 利用率等关键指标。
6.2 请求日志分析
启用详细日志有助于性能分析：
bash复制docker run -e OLLAMA_DEBUG=1 ...
典型的性能瓶颈包括：
- 显存不足导致的频繁换入换出
- 内存带宽限制
- CPU 成为瓶颈（GPU 利用率低）
6.3 量化模型选择
对于生产环境，模型量化版本能显著减少资源占用：
bash复制docker exec ollama ollama pull llama2:7b-chat-q4_0 # 4-bit量化版本
在我的测试中，7B 模型的 4-bit 量化版本仅需 6GB 显存，而原始版本需要 14GB。