将大模型放进容器里用 Ollama 跑起来，已经成为许多团队做本地推理原型的标配做法。Ollama 本身是一个简化了模型权重管理与推理调用的运行时，它屏蔽了诸多底层细节，让开发者能用几条命令拉起 Llama、Qwen 等开源模型。当它与容器技术结合后，部署形态变得更加标准化，无论是笔记本上的开发验证，还是机房里的批量服务，都可以通过同一套镜像完成。
一、Ollama 容器化运行的核心原理
Ollama 的容器镜像本质上打包了模型运行所需的推理引擎（基于 llama.cpp 等后端）、模型仓库客户端以及一组 HTTP 接口服务。当容器启动后，Ollama 会监听固定端口，等待用户通过命令行或者 API 提交模型名称。如果本地持久卷里没有对应的权重文件，它会自动从远程仓库拉取并解压，这也是为什么挂载数据卷十分关键——否则每次重建容器都要重新下载几十 GB 的文件。
在 Linux 容器环境中，Ollama 通过宿主机的 GPU 驱动实现加速。Docker 场景下通常使用 nvidia-container-toolkit 将显卡设备映射进容器，使得内部的推理后端可以调用 CUDA 能力。CPU 模式下虽然也能跑，但生成速度会明显下降。理解这一原理有助于我们后续针对性地做资源限制：模型加载阶段占用的是磁盘与内存，推理阶段则主要消耗显存和算力。
另一个容易被忽视的机制是 Ollama 的并发处理模型。它默认以单进程方式加载模型，并通过内部队列处理多个请求。如果在容器中不限制内存和显存，一旦同时涌入大量长文本生成任务，就可能触发系统的 OOM Killer 把容器杀掉。因此，清楚 Ollama 如何管理模型生命周期，是做好容器化部署的前提。
二、基于 Docker 的标准部署步骤
最基础的部署方式是直接使用官方镜像并映射端口与数据目录。下面这段命令可以启动一个带 GPU 支持的 Ollama 容器，并将模型存储在宿主机的 /opt/ollama 目录中，避免重复下载。
docker run -d --name ollama --gpus all -p 11434:11434 -v /opt/ollama:/root/.ollama ollama/ollama:latest
容器起来之后，我们可以通过 docker exec 进入内部执行模型拉取。例如运行 ollama pull qwen2:7b 就会自动下载对应的量化版本。完成后用 ollama run qwen2:7b 做交互测试。如果一切正常，外部程序就能通过 http://宿主机IP:11434/api/generate 提交 JSON 请求来获取推理结果。
对于需要编写 Docker Compose 的团队，可以把上述参数固化成文件，方便多人协作和环境复制。下面给出一个最小可用的 compose 片段，其中明确了重启策略和日志限制，防止容器异常退出后无人感知。
version: "3"
services:
ollama:
image: ollama/ollama:latest
container_name: ollama
ports:
- "11434:11434"
volumes:
- ./ollama_data:/root/.ollama
deploy:
resources:
reservations:
devices:
- driver: nvidia
count: all
capabilities: [gpu]
restart: unless-stopped
这种标准部署方式优点在于简单直观，适合快速验证。但在生产环境里，我们还需要考虑模型预热、接口鉴权以及容器资源配额，这些会在下一节展开。
三、资源调优与常见故障排查
容器化运行大模型时，最常见的故障是显存不足导致推理崩溃。Ollama 支持通过环境变量调整部分运行时行为，例如设置 OLLAMA_NUM_PARALLEL 控制并行请求数，降低并发可以避免瞬时显存峰值。同时在 docker run 中加上 --memory 和 --shm-size 限制，能防止容器吃掉宿主全部内存。
docker run -d --name ollama --gpus all -p 11434:11434 -v /opt/ollama:/root/.ollama -e OLLAMA_NUM_PARALLEL=2 --memory=16g --shm-size=4g ollama/ollama:latest
另一个典型问题是模型拉取缓慢或中断。由于默认源在国外，国内机器经常会卡在下载阶段。此时可以配置镜像代理或者在宿主机提前用其他工具下好权重，再拷贝进挂载卷对应的目录结构里。Ollama 的本地仓库按 models/blobs 与 models/manifests 组织文件，手动放置后执行 ollama list 能验证是否识别成功。
日志排查方面，建议用 docker logs -f ollama 实时观察启动与推理报错。若出现 CUDA out of memory 字样，说明当前模型量化等级过高，应换用 4bit 或 5bit 版本；若是 permission denied 类错误，多半是卷挂载路径权限不对，需要确认宿主目录对容器用户可读写。把这些排错点做成检查清单，能大幅缩短线上事故恢复时间。
四、与业务系统集成的实践建议
当 Ollama 容器稳定运行后，业务侧通常通过 HTTP 客户端调用其 API。需要注意的是，Ollama 的接口默认没有鉴权，如果在公网暴露会带来安全风险。做法是在容器前端加一层反向代理，例如用 Nginx 配置访问令牌校验，只转发合法请求到 11434 端口。
在代码层面，可以用任意支持 HTTP 的语言封装调用逻辑。下面是一段 Python 示例，展示如何向容器内的 Ollama 提交生成请求并流式读取返回内容，适合嵌入到对话服务中。
import requests
url = "http://127.0.0.1:11434/api/generate"
data = {
"model": "qwen2:7b",
"prompt": "用一句话解释容器化",
"stream": True
}
with requests.post(url, json=data, stream=True) as r:
for line in r.iter_lines():
if line:
print(line.decode("utf-8"))
从架构角度看，把 Ollama 作为独立推理容器剥离出来，有利于横向扩展。当单一容器无法满足吞吐时，可以启动多个实例并用负载均衡分发请求，只要它们共享同一个后端存储或各自缓存模型即可。这种解耦思路让算法迭代和系统运维互不干扰，也更符合当前云原生应用的构建方式。