用Docker部署Ollama：从零搭建大模型服务环境指南

最近团队里又有同事在群里问Ollama到底怎么装说他照着网上各种教程手动配了两遍都没跑起来不是Python依赖打架就是下载的模型文件不知道去哪了。这事我太熟了我自己刚开始玩Ollama也是一样后来干脆全部改用Docker部署整个流程一下就清爽了。这篇内容就是我把这两年用Docker跑Ollama模型的经验完整梳理一遍从最基础的安装命令到GPU直通、API对接再到生产环境里会踩的坑一次说清楚。如果你正在做模型评测、本地私有化部署、或者想给团队搭一个统一的大模型服务环境这篇基本可以拿来直接当操作手册。用Docker部署Ollama本质上就是把Ollama运行时、模型文件和环境依赖全部塞进一个标准化的容器里宿主机只需要一个Docker引擎。这样做最直接的好处是不管你在Ubuntu、Debian还是CentOS上也不管是个人笔记本还是服务器同一个镜像跑起来的结果完全一样再也不用花时间清理环境。1. 为什么我坚持用Docker跑Ollama——容器化部署的实际收益1.1 裸机安装的三个老大难问题先说我在裸机环境装Ollama踩过的坑。早期Ollama版本对Linux的依赖其实挺挑的需要系统里有合适的glibc版本、显卡驱动、CUDA运行库。每次在新机器上装几乎都会碰到一类问题Ollama安装好了但跑模型的时候提示CUDA版本不对或者libcuda.so找不到又不敢乱动系统里正在跑的CUDA环境因为可能有其他业务依赖旧版本。再有一个是Python环境的问题。虽然Ollama本身不是Python项目但它周边工具链比如各种自动调用脚本、WebUI工具往往依赖特定Python版本和一堆库自己环境一旦很乱很容易出现装A依赖就把B的版本改了的情况。在多人共用的机器上这种问题尤其烦人。最后一个问题是卸载和回滚。裸机装的东西想要换版本或者彻底清掉需要手动删一堆文件、还要检查环境变量、清理缓存。操作不熟练的话很容易把系统搞出毛病。1.2 Docker把这些问题简化成了什么用Docker部署之后上面这些痛点基本消失依赖隔离Ollama运行时连同它需要的系统库都封装在镜像里宿主机只需要有Docker引擎。版本可控想换Ollama版本换一个镜像标签就可以回滚也简单再启动旧容器就是旧版本。一致性同一个镜像在任何机器上行为一致不用再写在我机器上是好的这种话。可迁移模型文件存到数据卷里备份、迁移都很方便。我自己的经验是容器化部署看起来多学一个Docker概念但实际上把后期运维成本降得非常明显。尤其是在服务器上一台机器可能同时跑多个AI服务用Docker天然隔离端口、内存、日志互不干扰这在裸机环境下要手动做很多配置才能达到。1.3 也有不需要Docker的场景当然不是所有人一上来就必须Docker。如果你只是在个人电脑上装来尝鲜平时跑跑小模型、不涉及给别人提供服务那直接按Ollama官网的脚本装也挺好省事。但如果你想把这个模型服务稳定地跑起来、供多个应用调用、或者部署到团队共用的服务器上那我建议直接用Docker一步到位。后面我说的所有操作也都是基于Docker环境。2. 部署前置工作硬件清点、Docker环境与镜像版本选择2.1 硬件需求心里要有数部署前先搞清楚自己要跑什么规模的模型。Ollama支持很多开源模型包括Qwen、Llama、Mistral等系列。模型参数大小和量化方式直接决定内存占用。我列一个常用参考表模型参数规模量化方式内存/显存预估适用场景0.5B~1.5BQ4_K_M2~4GB轻量任务、快速测试7B~8BQ4_K_M6~8GB日常对话、文档总结14BQ4_K_M10~16GB中等复杂度推理32BQ4_K_M20~32GB高质量生成70BQ4_K_M40~50GB深度推理、代码生成注意这里的内存数值是一个大概范围实际占用会包括KV cache和上下文长度。跑32B以上模型16GB内存的机器就会很吃力了建议至少32GB内存起步。有NVIDIA显卡的话显存尽量满足上述容量需求否则模型会被放到内存里用CPU算速度会慢很多。没有独立显卡也能跑比如7B Q4模型在现在主流的8核CPU上单次生成大概每秒几个token到十几个token体验一般但调试API、做简单自动化是完全够用的。如果有RTX 3060 12GB这种级别的显卡跑7B模型就非常流畅。我建议新手刚开始别贪大先跑7B级别模型打通流程之后再根据效果调整。2.2 Docker环境的安装与验证Linux服务器上安装Docker最标准的做法是用官方脚本。Debian/Ubuntu系curl -fsSL https://get.docker.com | sh systemctl enable --now docker装好以后验证一下docker version输出里有client和server两段信息就说明Docker引擎正常。然后还要确认一下当前用户有权限操作Docker避免每次都要sudosudo usermod -aG docker $USER newgrp docker如果你是CentOS/RHEL系官方脚本同样适用。不建议再额外装docker-compose的方式安装compose插件现在Docker自带docker compose命令方便一点。2.3 镜像版本怎么选Ollama官方在Docker Hub上有ollama/ollama镜像。打开镜像仓库的tags页面能看到两类标签纯版本号标签比如0.5.4、0.6.1latest标签我的建议是生产环境不要用latest因为它指向最新发布版万一官方某次升级引入了不兼容变化你重启容器就中招了。正确做法是固定一个知道自己验证过的版本比如ollama/ollama:0.5.4。等官方出稳定新版本、你验证过再手动升级。如果你需要读模型文件做二次开发还有带-rocm后缀的标签用于AMD GPU-cu后缀用于NVIDIA GPU。不过多数情况下基础标签已经自动带CUDA支持了我后面会专门讲GPU直通。当前的镜像体积也不小一般几百MB拉取时有耐心。拉取完可以确认一下docker image inspect ollama/ollama:0.5.4 | head -30能看到镜像架构和配置信息确认拉取成功。3. 一条命令跑起Ollama容器启动参数逐个拆解3.1 最小可用容器最简部署只需要下面这一条命令docker run -d \ --name ollama \ -p 11434:11434 \ -v ollama:/root/.ollama \ ollama/ollama:0.5.4这里每个参数背后都有讲究我逐个说-d后台运行容器不会阻塞终端。--name ollama给容器起名叫ollama后面操作、查看日志、停止都方便。不指定就会随机生成一个名字找起来很麻烦。-p 11434:11434把容器内部的11434端口Ollama API默认端口映射到宿主机的11434端口。这样宿主机上其他程序、局域网内其他机器就能直接访问这个端口调用模型服务。-v ollama:/root/.ollama这是关键。把容器里的/root/.ollama目录挂载到Docker数据卷ollama里。Ollama下载的所有模型文件都存在这个目录下不挂载的话容器一删模型全没了。数据卷的好处是路径由Docker统一管理不用关心具体位置。跑起来之后可以用docker ps确认容器状态是Up。3.2 为什么建议用命名卷而不是bind mount有人习惯用-v /data/ollama:/root/.ollama这种方式做路径映射bind mount。好处是模型文件直接落在宿主机某个具体目录里自己好找。但坏处是权限问题很常见容器内通常以root运行挂载的目录如果属主不是root或者SELinux没配置好就会报permission denied。命名卷没有这个麻烦数据卷目录归Docker管理权限自动协调好。我自己现在的做法是容器部署用命名卷备份的时候再用docker run --rm -v ollama:/data -v /backup:/backup临时把数据卷内容拷出来。这样兼顾了稳定性和可管理性。3.3 GPU直通让推理速度真正起飞如果你的服务器上有NVIDIA显卡不把显卡传给容器就亏大了。要让容器用上GPU需要做的步骤如下。先安装NVIDIA Container Toolkit。以Ubuntu为例官方给的方式一般是添加APT源之后安装curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \ sed s#deb https://#deb [signed-by/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g | \ sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list sudo apt-get update sudo apt-get install -y nvidia-container-toolkit装完后配置Docker运行时sudo nvidia-ctk runtime configure --runtimedocker sudo systemctl restart docker然后启动容器的时候加上--gpus all参数docker run -d \ --name ollama \ --gpus all \ -p 11434:11434 \ -v ollama:/root/.ollama \ ollama/ollama:0.5.4验证GPU是否真的被容器用到了进入容器执行docker exec -it ollama nvidia-smi能看到显卡信息就说明直通成功。如果看不到多半是toolkit没装好或者Docker运行时没有切换后面踩坑部分我会再展开。3.4 下载模型并完成首次对话容器跑起来之后下载模型的命令要放到容器里执行docker exec -it ollama ollama pull qwen2.5:7b这里qwen2.5:7b是一个例子你可以换成其他你想用的模型。下载过程会有进度条模型会存到刚才挂载的/root/.ollama目录里。下完以后直接对话测试docker exec -it ollama ollama run qwen2.5:7b当终端出现 Send a message提示输入一句话回车模型就会返回结果。这一步通了整套部署就算成功了一半。4. 模型下载管理与API对接让容器里的模型真正被用起来4.1 容器内的ollama命令用法因为Ollama跑在容器里所有命令都要通过docker exec进入容器执行。我常用的几条命令# 查看本机已下载的模型 docker exec ollama ollama list # 查看某个模型详情 docker exec ollama ollama show qwen2.5:7b # 删除已下载的模型 docker exec ollama ollama rm qwen2.5:7b # 从本地文件导入模型 docker exec -it ollama ollama create mymodel -f /root/Modelfile特别是最后一条Ollama支持把Hugging Face上其他格式的模型转换后导入但操作上要先把模型文件拷到容器或者挂载目录里再执行create命令。日常用得不多但偶尔会有奇效。4.2 用Modelfile定制模型Ollama的强大之处在于可以通过Modelfile自定义模型参数。比如我嫌默认温度太高导致输出发散就写一个简单的ModelfileFROM qwen2.5:7b PARAMETER temperature 0.3 PARAMETER top_p 0.8 SYSTEM 你是一个严谨的技术文档撰写助手。然后执行docker cp ./Modelfile ollama:/root/Modelfile docker exec ollama ollama create tech-writer -f /root/Modelfile之后用tech-writer这个模型名调用就会自动带上这些参数和系统提示词。注意docker cp的路径别搞错我经常因为路径不对导致create命令报找不到文件。4.3 REST API调用方式容器跑起来后宿主机端口11434就是Ollama的API入口。最常用的接口有两个生成接口/api/generate一般用于一问一答式补全curl http://localhost:11434/api/generate -d { model: qwen2.5:7b, prompt: 用一句话解释Docker是什么, stream: false }不设置stream: true的话返回的是完整JSON设置成true会按SSE格式逐段返回token适合做流式打字机效果。对话接口/api/chat适合模拟多轮对话curl http://localhost:11434/api/chat -d { model: qwen2.5:7b, messages: [ {role: user, content: Docker和虚拟机有什么区别} ], stream: false }如果你的应用在另一个容器里不想通过宿主机端口访问更优雅的方式是让两个容器共享一个Docker网络然后用容器名访问比如http://ollama:11434。4.4 快速配一个Web对话界面命令行里玩模型终归不够直观我一般会顺手部署一个Open WebUI让团队里不懂命令行的同事也能用浏览器对话。docker run -d \ --name open-webui \ -p 3000:8080 \ --add-hosthost.docker.internal:host-gateway \ -v open-webui:/app/backend/data \ ghcr.io/open-webui/open-webui:main打开http://服务器IP:3000注册账号后在模型选择里就能看到Ollama已经下载的模型。如果WebUI和Ollama不在同一个Docker网络首次需要手动配置Ollama的Base URL填http://宿主机IP:11434即可。5. 生产级配置GPU直通、持久化与并发调优5.1 环境变量这些参数得知道Ollama容器支持通过环境变量控制行为。我常用这几个环境变量作用建议值OLLAMA_HOST监听地址默认0.0.0.0除非有安全需求不用改0.0.0.0OLLAMA_NUM_PARALLEL同时处理的请求数1~4OLLAMA_MAX_LOADED_MODELS最多同时加载的模型数量1~2OLLAMA_KEEP_ALIVE模型在内存中保持加载的时间单位秒5m或者-1维持OLLAMA_MODELS模型存储路径容器内默认在/root/.ollama/models一般不用改在启动容器时通过-e传进去即可docker run -d \ --name ollama \ --gpus all \ -e OLLAMA_NUM_PARALLEL2 \ -e OLLAMA_MAX_LOADED_MODELS1 \ -e OLLAMA_KEEP_ALIVE5m \ -p 11434:11434 \ -v ollama:/root/.ollama \ ollama/ollama:0.5.45.2 并发和内存怎么权衡内存和显存有限并发开太高容易OOM。我建议先用默认值跑一天观察内存和显存占用再逐步调高OLLAMA_NUM_PARALLEL。比如8GB显存的卡跑7B Q4模型同时处理2个请求通常没问题开4个就可能爆显存。模型在内存里驻留有好处也有坏处常驻可以省去加载时间首次加载可能需要几秒到几十秒但会一直占着显存。OLLAMA_KEEP_ALIVE5m是一个比较平衡的设置。5.3 自动重启和日志管理服务跑在容器里最怕机器重启后容器没起来。给docker run加上--restart always参数或改成unless-stopped也行docker run -d \ --name ollama \ --gpus all \ --restart unless-stopped \ ...unless-stopped比always好的地方在于如果你明确执行了docker stop ollamaDocker不会在重启机器后强行把它拉起来。日志查看也是日常运维的必要操作docker logs -f ollama拉出来的日志会显示每次启动加载的GPU信息、模型加载时间以及API请求的错误原因。之前我遇到过一次容器能起来但模型加载异常就是靠日志里unable to load model报错定位到是磁盘空间不足。5.4 用docker-compose固化整套配置命令行参数一长串不便于团队共享。我还是建议把配置固化到docker-compose.yml里。下面是我目前在用的版本可以直接抄services: ollama: image: ollama/ollama:0.5.4 container_name: ollama restart: unless-stopped ports: - 11434:11434 volumes: - ollama_data:/root/.ollama environment: - OLLAMA_NUM_PARALLEL2 - OLLAMA_MAX_LOADED_MODELS1 - OLLAMA_KEEP_ALIVE5m deploy: resources: limits: memory: 32g # 如果有NVIDIA GPU取消下一行的注释 # gpus: # - driver: nvidia # count: all # capabilities: [gpu] open-webui: image: ghcr.io/open-webui/open-webui:main container_name: open-webui restart: unless-stopped ports: - 3000:8080 volumes: - open_webui_data:/app/backend/data environment: - OLLAMA_BASE_URLhttp://ollama:11434 volumes: ollama_data: open_webui_data:在这个配置文件所在目录执行docker compose up -d会自动创建自定义网络两个服务可以通过ollama这个服务名互相访问。该限制内存32g也写在deploy配置里防止模型加载时把机器其他服务挤垮。6. 我在部署和日常使用中踩过的四个坑6.1 模型下载中断和处理方法第一次在服务器上下载7B模型进度跑到一半卡住不动了等十几分钟直接失败。后来发现Ollama的模型下载是多分片并发拉取网络稍有抖动就会有一个分片超时重试是整个文件从来非常折磨。我的对策下载前先检查磁盘空间和网络连通性。不要让Ollama容器内存占用过高下载阶段CPU占用也明显尽量选空闲时段。如果经常失败可以在宿主机配置HTTP代理环境变量让Ollama走代理下载。注意这里说的是合法合规的代理具体地址根据你的网络环境配置。不配置也可以耐心多试几次。另一个办法是从别人那直接拷贝模型文件放到数据卷的models目录下Ollama会识别。迁移时我通常用带命名卷的临时容器做打包拷贝。6.2 端口11434被占用这是多服务共存的服务器上很常见的问题。启动容器时提示Error response from daemon: driver failed programming external connectivity on endpoint ollama: Bind for 0.0.0.0:11434 failed: port is already allocated解决方案很简单把宿主机的端口映射改成其他端口比如-p 11435:11434但要注意改成11435之后所有API调用地址、WebUI里配置的Ollama Base URL都要同步改。我一开始图省事就直接换端口结果Open WebUI一直连不上排查半天才发现是这里没更新。6.3 显卡明明有容器里就是看不到我在一块新卡服务器上部署时--gpus all也加了但容器内执行nvidia-smi报错找不到设备。排查链路是这样的首先确认宿主机带不带卡直接执行nvidia-smi正常。然后确认docker run里有没有--gpus all确认有。再确认NVIDIA Container Toolkit是否安装执行docker info | grep -i runtime发现runtimes里只有runc没有nvidia。问题定位在toolkit没用上重新执行sudo nvidia-ctk runtime configure --runtimedocker然后重启Docker。再启动容器时就能看到显卡了。这类问题本质上就是运行时没注册不是Ollama的问题排查方向要明确。6.4 容器内模型加载慢、输出越来越慢有段时间我用7B模型做批量测试跑了几百条之后发现单条响应时间明显变长。一看内存模型常驻占了快20GB系统开始用swap。原因是我一开始为了响应快设了OLLAMA_KEEP_ALIVE-1模型一直驻留内存再加上同时跑着WebUI和其他任务内存就吃不消了。从那次之后我把OLLAMA_KEEP_ALIVE改回5m并限制了容器内存上限问题没有再出现。在资源有限的机器上让模型空闲一段时间后自动卸载是更划算的选择那几秒加载延迟换来的是整体稳定。6.5 一个容易忽视的权限坑如果你一定要用bind mount挂载模型目录比如-v /data/ollama:/root/.ollama注意宿主机目录权限。Ollama容器默认用户是root但目录如果挂在NFS或者有子目录权限限制模型加载时会有permission denied。我建议除非清楚自己在做什么否则统一用命名卷。硬要用bind mount记得先mkdir -p /data/ollama chmod 755 /data/ollama再启动容器。最后分享一点我自己的使用心得用Docker把这套东西管起来之后我最大的感受是不用再为环境问题焦虑了。一台新服务器要部署同样的模型服务不需要再翻各种安装教程只要把docker-compose文件拷过去docker compose up -d等镜像和模型下载完就能用。团队里几个人一起开发的时候也不会出现A的版本是0.4B的版本是0.6这种对不上的情况。另外容器化也让我养成了一件事每次换Ollama版本之前先停掉容器、备份数据卷、再拉新镜像。这一步花不了几分钟但能避免很多不必要的返工。如果后续你想把多个不同规模、不同用途的模型组合起来做一个私有化推理平台这套Docker底子完全够用甚至可以在这个基础上继续叠服务比如自动化评测、数据标注、流式对话网关都是顺着已有架构延伸的活。