Docker 部署 Ollama 全流程指南:支持 CPU/GPU、生产环境可用的工程化实践

Docker 部署 Ollama 全流程指南:支持 CPU/GPU、生产环境可用的工程化实践

在上一篇文章中,我们通过本地安装的方式快速跑通了 Ollama,还成功将 DeepSeek 模型运行起来,体验到了大模型本地部署的便捷性。但当你真正把 Ollama 放到团队协作环境、服务器长期运行场景,或是纳入正式项目开发流程时,会立刻发现一个核心问题:本机安装虽简单,却缺乏工程化属性

本地安装的典型痛点集中在这几点:

  • 环境易污染,容易出现 CUDA 版本、依赖包的冲突问题
  • 机器迁移成本高,换服务器需要重新配置全套环境
  • 服务状态不可控,缺乏标准化的启停、监控方式
  • 无法无缝接入企业现有运维体系,与容器化、自动化部署流程脱节

也正因如此,在真实的项目落地场景中,Docker 方式部署 Ollama 才是更合理、更可持续的选择

本文不只是教你把 Docker 版 Ollama “跑起来”,更核心的是带你理解:如何用 Docker 部署 Ollama,让它真正具备工程可用性,适配团队协作与生产级的使用需求

📌 系列文章

👉 大模型本地部署实践(总览):为什么要做本地部署及方案选型
👉 如何在本地部署 DeepSeek?Ollama 一步跑通全流程实战
👉 vLLM 本地部署 DeepSeek 全流程实战(Linux + NVIDIA GPU + OpenAI API 兼容)
👉 Docker 部署 vLLM 实战指南(NVIDIA CUDA / AMD ROCm 全流程)

一、什么时候必须使用 Docker?

很多开发者会有疑问:「我本地直接安装 Ollama 用着挺好,为什么非要用 Docker?」

答案很明确:本地安装可以用,但仅适合个人实验、功能验证阶段

当你的使用场景出现以下任意一种情况时,建议直接采用 Docker 部署方案,这会从根源上规避后续的诸多问题:

  • 需要在服务器上长期运行 Ollama 服务
  • 需对外暴露大模型 API 接口,供业务系统调用
  • 希望利用 GPU 加速推理,提升模型响应速度
  • 计划将服务迁移到云服务器或混合云环境
  • 未来可能接入 Kubernetes(k8s)进行集群化管理
  • 需要和企业现有 CI/CD 自动化部署体系融合

Docker 部署的核心价值,从来不是"操作更方便",而是为大模型本地部署赋予环境可复制、服务可管理、数据可持久化的工程化特性,这也是从个人使用到团队协作的关键跨越。

二、基础环境准备

Docker 部署的前提是搭建好基础的 Docker 环境,这一步是所有操作的基础,建议在生产服务器上使用官方源安装,保证环境稳定性。

检查 Docker 安装状态

首先在终端执行以下命令,确认服务器是否已安装 Docker:

docker version 

如果能正常输出 Docker 的客户端和服务端版本号,说明环境已就绪;若未安装,需参考 Docker 官方文档,根据自己的操作系统(Ubuntu/CentOS/Windows Server 等)安装最新稳定版本。

三、三种运行方式:CPU / Nvidia GPU / AMD GPU

这是 Docker 部署 Ollama 最容易踩坑的环节——不同的硬件配置(CPU/英伟达GPU/AMD GPU),对应的容器启动参数完全不同,选不对参数会导致硬件资源无法利用,甚至容器启动失败。

1️⃣ CPU 方式运行

如果只是做功能测试,或是服务器没有独立显卡,可直接采用纯 CPU 方式运行,无需额外配置硬件驱动,命令如下:

docker run -d \ -v ollama:/root/.ollama \ -p 11434:11434 \ --name ollama \ ollama/ollama 
核心参数说明
  • /root/.ollama:Ollama 的模型存储和配置目录,所有拉取的模型都会存放在这里
  • -v ollama:/root/.ollama:通过 Docker 命名卷实现数据持久化,即使容器被删除,模型文件也不会丢失。其中 ollama 是卷的名称,可通过 docker volume ls 查看
  • -p 11434:11434:映射容器端口到宿主机,11434 是 Ollama 的默认 API 通信端口
  • --name ollama:为容器命名,方便后续的启停、查看等操作

该方式下,模型的推理计算全部由 CPU 承担,响应速度较慢,仅适合小模型、低并发的测试场景。

2️⃣ Nvidia GPU 方式运行(推荐)

如果服务器配备了 NVIDIA 显卡,建议优先采用 GPU 方式运行,能大幅提升模型推理速度。但需要额外安装 NVIDIA Container Toolkit,让 Docker 容器能够调用 NVIDIA 显卡的算力。

① 安装 NVIDIA Container Toolkit

依次执行以下命令,全程使用 root 权限或 sudo 执行:

# 导入NVIDIA GPG密钥 curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey \ | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg # 添加NVIDIA Container Toolkit软件源 curl -fsSL 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运行时,让Docker识别NVIDIA GPU sudo nvidia-ctk runtime configure --runtime=docker # 重启Docker服务,使配置生效 sudo systemctl restart docker 

⚠️ 关键提醒:很多开发者会漏掉 nvidia-ctk runtime configure 这一步,导致Docker无法识别GPU,即使后续启动容器加了GPU参数,也无法正常使用。

② 启动 GPU 版 Ollama 容器

安装完成后,执行以下命令启动容器,核心是添加 --gpus=all 参数:

docker run -d \ --gpus=all \ -v ollama:/root/.ollama \ -p 11434:11434 \ --name ollama \ ollama/ollama 
核心参数说明
  • --gpus=all:让容器调用宿主机的所有 NVIDIA 显卡,也可指定单张显卡,如 --gpus=device=0
  • 其余参数与 CPU 方式一致,实现数据持久化和端口映射

3️⃣ AMD GPU 方式运行

如果服务器配备的是 AMD 显卡,需要使用 Ollama 专门的 ROCm 版本镜像,启动命令如下:

docker run -d \ --device /dev/kfd \ --device /dev/dri \ -v ollama:/root/.ollama \ -p 11434:11434 \ --name ollama \ ollama/ollama:rocm 
核心参数说明
  • --device /dev/kfd--device /dev/dri:将 AMD 显卡的设备文件映射到容器,让容器能够调用 AMD 显卡算力
  • ollama/ollama:rocm:AMD 显卡专属的镜像版本,不可使用默认镜像

⚠️ 注意:ROCm 对显卡型号有明确的支持范围,RX 6000/7000 系列支持较好;老旧型号可能需要额外设置环境变量 HSA_OVERRIDE_GFX_VERSION 才能正常工作,建议提前在 ROCm 官方支持列表中确认你的显卡是否在支持范围内。

四、如何判断是否真的使用了 GPU?

很多开发者添加了 GPU 相关参数后,就默认 GPU 已生效,但实际可能存在驱动不兼容、配置未生效等问题,必须验证模型推理时 GPU 是否真正被调用,才算确认启用成功

NVIDIA GPU 验证

执行以下命令进入 Ollama 容器,查看 GPU 是否可被识别:

# 进入容器交互终端 docker exec -it ollama bash # 查看NVIDIA GPU信息(仅Nvidia GPU方式可用) nvidia-smi 

nvidia-smi 能正常输出 GPU 信息,说明 NVIDIA Container Toolkit 配置正确、容器可以访问显卡。但这只是前提条件——要确认模型推理真正在使用 GPU,还需要在另一个终端窗口运行模型的同时,观察 nvidia-smi 输出中 GPU 利用率(GPU-Util)是否有明显上升,或查看 Ollama 日志中是否包含 GPU 相关提示:

docker logs ollama | grep -i gpu 

若提示命令不存在或无硬件信息,需检查 NVIDIA Container Toolkit 安装步骤,或确认显卡驱动是否正常。

AMD GPU 验证

对于 AMD GPU,可在容器内通过 rocminfo 命令验证显卡是否被识别,同样建议在运行模型时同步观察 GPU 利用率变化。

五、拉取并运行模型

Docker 容器启动后,就可以像本地安装方式一样,拉取并运行大模型了,核心是通过 docker exec 命令在容器内执行 Ollama 相关操作。

直接运行模型

以 DeepSeek-R1 1.5B 模型为例,执行以下命令,若模型未拉取,会自动下载并启动交互模式:

docker exec -it ollama ollama run deepseek-r1:1.5b 

单独拉取模型

如果只想先下载模型,不立即运行,可执行拉取命令:

docker exec -it ollama ollama pull deepseek-r1:1.5b 

模型下载完成后,会存储在之前映射的卷目录中,即使重启容器,模型也无需重新下载。

六、验证服务是否可用

容器和模型都准备好后,需要验证 Ollama 服务是否正常运行,确保能对外提供 API 调用能力,主要通过检查容器状态访问本地接口两步验证。

步骤1:检查容器运行状态

执行以下命令,查看容器是否处于 Up 状态:

docker ps 

如果输出结果中,ollama 容器的状态为 Up(无 Exited),说明容器启动正常。

步骤2:访问本地 API 接口

在服务器本地或通过浏览器访问以下地址:

http://localhost:11434 

如果页面返回 Ollama is running,说明 Ollama 服务已正常启动,可对外提供 API 调用服务;若服务器部署在云环境,需开放 11434 端口,才能通过公网访问。

七、工程化优化建议(强烈建议做)

如果只是做短期测试,以上步骤就足够了,但如果打算将 Ollama 服务作为长期运行的业务组件,建议做以下工程化优化,让服务更稳定、更易管理,这也是生产环境部署的必备操作。

1️⃣ 替换命名 Volume,使用本地目录映射

前面使用的 -v ollama:/root/.ollama 是 Docker 命名卷,虽然能实现数据持久化,但模型文件的实际存储路径由 Docker 管理,不方便直接备份、迁移。建议将卷映射改为宿主机本地目录,路径完全透明可控,命令示例:

-v /data/ollama:/root/.ollama 

其中 /data/ollama 是宿主机的本地目录,可根据自己的服务器目录规划调整,建议选择磁盘空间充足的分区。

2️⃣ 添加自动重启参数,保证服务高可用

服务器重启、Docker 服务重启后,若未指定重启策略,Ollama 容器不会自动启动,会导致业务服务中断。添加 --restart unless-stopped 参数,让容器在异常退出或服务器重启后自动恢复运行,命令示例:

--restart unless-stopped 

该策略的含义是:除非手动执行 docker stop 停止容器,否则容器将在退出后始终自动重启。

3️⃣ 设置资源限制,防止拖垮宿主机

大模型推理会占用大量的内存、CPU 资源,如果不做限制,可能会导致宿主机资源耗尽,影响其他服务运行。可通过以下参数限制容器的资源使用:

# 限制最大系统内存使用为16G --memory=16g # 限制CPU核心使用,如使用0-1号核心 --cpuset-cpus="0,1" 

需要注意的是,--memory 限制的是系统内存(RAM),而大模型推理的核心瓶颈通常在显存(VRAM)。显存容量决定了能加载多大参数量的模型,需根据所用显卡的显存规格合理选择模型版本,这两者是独立维度,不可混为一谈。

八、推荐使用 Docker Compose 管理服务

当你开始把 Ollama 作为正式的"服务"纳入项目管理时,不建议再使用原生 Docker 命令启动,推荐使用 Docker Compose——通过配置文件管理容器参数,让配置可版本化、可复用、可迁移。

1️⃣ 编写 docker-compose.yml 配置文件

在服务器上创建 docker-compose.yml 文件,写入以下配置(以 NVIDIA GPU 方式为例,CPU/AMD 方式可按需修改):

services: ollama: # 镜像版本,AMD GPU请改为ollama/ollama:rocm image: ollama/ollama # 容器名称 container_name: ollama # 指定nvidia运行时,让容器可调用NVIDIA GPU runtime: nvidia # 端口映射 ports: - "11434:11434" # 本地目录映射 volumes: - /data/ollama:/root/.ollama # 自动重启策略 restart: unless-stopped # GPU配置 deploy: resources: reservations: devices: - driver: nvidia count: all capabilities: [gpu] # 环境变量:声明可用GPU environment: - NVIDIA_VISIBLE_DEVICES=all 
说明: GPU 配置采用 driver: nvidia + count: all 的完整写法,runtime: nvidia 与之配合确保单机模式下 GPU 也能正常生效。如需使用 CPU 方式,删除 runtimedeployenvironment 三个节点即可。

2️⃣ 启动/停止服务

在配置文件所在目录,执行以下命令启动服务:

# 后台启动服务 docker compose up -d # 停止服务 docker compose down # 查看服务日志 docker compose logs -f 

Docker Compose 核心优势

  • 配置可版本化:将 docker-compose.yml 纳入 Git 管理,实现配置的追溯和团队同步
  • 易于迁移:将配置文件复制到新服务器,执行一条命令即可启动服务,无需重新输入复杂参数
  • 易于扩展:后续可在配置文件中添加监控、日志收集等组件,实现服务的一体化管理
  • 适配运维体系:可无缝接入企业的容器化部署流程,与现有工具链融合

九、总结

Docker 部署 Ollama 的核心价值,从来不是"让模型能跑"——本地安装也能做到这一点,而是让大模型的本地运行具备完整的工程属性,实现从"个人实验"到"团队协作/生产使用"的跨越。

从个人使用到生产环境,大模型部署的本质差异,就在于服务是否具备可迁移、可管理、可复用、可维护的特性,而 Docker 正是实现这些特性的最低成本、最高效的方式。

如果你的后续规划包含以下任意一种场景,那么 Docker 方式部署 Ollama 几乎是必须选项

  • 搭建本地 RAG(检索增强生成)系统,实现私域数据的智能问答
  • 开发企业内部知识库,基于大模型实现文档智能检索与解读
  • 对外提供私有大模型 API 服务,供业务系统、前端应用调用
  • 将大模型能力接入 Spring/Java/Python 后端,开发智能业务功能

后续我们将继续展开大模型本地部署的工程化实践:基于 vLLM 搭建高性能推理服务,以及如何在实际业务项目中接入 Ollama 提供的大模型 API 能力,让大模型真正落地到业务场景中。

Read more

【OpenClaw从入门到精通】第10篇:OpenClaw生产环境部署全攻略:性能优化+安全加固+监控运维(2026实测版)

【OpenClaw从入门到精通】第10篇:OpenClaw生产环境部署全攻略:性能优化+安全加固+监控运维(2026实测版)

摘要:本文聚焦OpenClaw从测试环境走向生产环境的核心痛点,围绕“性能优化、安全加固、监控运维”三大维度展开实操讲解。先明确生产环境硬件/系统选型标准,再通过硬件层资源管控、模型调度策略、缓存优化等手段提升响应速度(实测响应效率提升50%+);接着从网络、权限、数据三层构建安全防护体系,集成火山引擎安全方案拦截高危操作;最后落地TenacitOS可视化监控与Prometheus告警体系,配套完整故障排查清单和虚拟实战案例。全文所有配置、代码均经实测验证,兼顾新手入门实操性和进阶读者的生产级部署需求,帮助开发者真正实现OpenClaw从“能用”到“放心用”的跨越。 优质专栏欢迎订阅! 【DeepSeek深度应用】【Python高阶开发:AI自动化与数据工程实战】【YOLOv11工业级实战】 【机器视觉:C# + HALCON】【大模型微调实战:平民级微调技术全解】 【人工智能之深度学习】【AI 赋能:Python 人工智能应用实战】【数字孪生与仿真技术实战指南】 【AI工程化落地与YOLOv8/v9实战】【C#工业上位机高级应用:高并发通信+性能优化】 【Java生产级避坑指南:

By Ne0inhk
ARM Linux 驱动开发篇--- Linux 并发与竞争实验(互斥体实现 LED 设备互斥访问)--- Ubuntu20.04互斥体实验

ARM Linux 驱动开发篇--- Linux 并发与竞争实验(互斥体实现 LED 设备互斥访问)--- Ubuntu20.04互斥体实验

🎬 渡水无言:个人主页渡水无言 ❄专栏传送门: 《linux专栏》《嵌入式linux驱动开发》《linux系统移植专栏》 ❄专栏传送门: 《freertos专栏》《STM32 HAL库专栏》 ⭐️流水不争先,争的是滔滔不绝  📚博主简介:第二十届中国研究生电子设计竞赛全国二等奖 |国家奖学金 | 省级三好学生 | 省级优秀毕业生获得者 | ZEEKLOG新星杯TOP18 | 半导纵横专栏博主 | 211在读研究生 在这里主要分享自己学习的linux嵌入式领域知识;有分享错误或者不足的地方欢迎大佬指导,也欢迎各位大佬互相三连 目录 前言  一、实验基础说明 1.1、互斥体简介 1.2 本次实验设计思路 二、硬件原理分析(看过之前博客的可以忽略) 三、实验程序编写 3.1 互斥体 LED 驱动代码(mutex.c) 3.2.1、设备结构体定义(28-39

By Ne0inhk
Flutter for OpenHarmony:swagger_dart_code_generator 接口代码自动化生成的救星(OpenAPI/Swagger) 深度解析与鸿蒙适配指南

Flutter for OpenHarmony:swagger_dart_code_generator 接口代码自动化生成的救星(OpenAPI/Swagger) 深度解析与鸿蒙适配指南

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net 前言 后端工程师扔给你一个 Swagger (OpenAPI) 文档地址,你会怎么做? 1. 对着文档,手写 Dart Model 类(容易写错字段类型)。 2. 手写 Retrofit/Dio 的 API 接口定义(容易拼错 URL)。 3. 当后端修改了字段名,你对着报错修半天。 这是重复劳动的地狱。 swagger_dart_code_generator 可以将 Swagger (JSON/YAML) 文件直接转换为高质量的 Dart 代码,包括: * Model 类:支持 json_serializable,带 fromJson/

By Ne0inhk
Linux 开发别再卡壳!makefile/git/gdb 全流程实操 + 作业解析,新手看完直接用----《Hello Linux!》(5)

Linux 开发别再卡壳!makefile/git/gdb 全流程实操 + 作业解析,新手看完直接用----《Hello Linux!》(5)

文章目录 * 前言 * make/makefile * 文件的三个时间 * Linux第一个小程序-进度条 * 回车和换行 * 缓冲区 * 程序的代码展示 * git指令 * 关于gitee * Linux调试器-gdb使用 * 作业部分 前言 做 Linux 开发时,你是不是也遇到过这些 “卡脖子” 时刻?写 makefile 时,明明语法没错却报错,最后发现是依赖方法行没加 Tab;想提交代码到 gitee,记不清 git add/commit/push 的 “三板斧”,还得反复搜教程;用 gdb 调试程序,输了命令没反应,才想起编译时没加-g生成 debug 版本;甚至连写个进度条,都搞不懂\r和\n的区别,导致进度条乱跳…… 其实这些问题,

By Ne0inhk