去年年底我给自己列了个“本地跑大模型”的计划选来选去最后还是落到了 Ollama 上。试过之后发现与其在 Ubuntu 系统里直接裸装不如用 Docker 来部署 Ollama整个流程干净、可控、换机器也方便。这篇博文我就从 Ubuntu 环境准备讲起到 Docker 镜像加速、Ollama 容器启动、轻量模型拉取与 API 调用最后把我在实际部署中踩过的坑一并列出来。全程拿我自己跑过的命令和参数说话照着操作基本一次就能跑通。1. 为什么建议在 Ubuntu 上用 Docker 部署 Ollama1.1 Ollama 到底解决了什么问题Ollama 是一个本地大模型运行框架把模型的下载、加载、推理 API 这几件事封装得非常简单。你不需要懂 TensorFlow、PyTorch 或者 CUDA 的细节也不需要手动去 Hugging Face 上下载权重文件再写推理脚本只要一条ollama run qwen2.5:0.5b就能把模型跑起来。它的优势在于抽象层做得非常薄。底层虽然也是调用 llama.cpp 或类似引擎但对外暴露的是一个极简 REST API默认监听11434端口。这个设计思路和 Redis、MySQL 这类服务类似做成“常驻服务”之后任何语言都能通过 HTTP 调用模型后续对接前端、接 Python 后端、甚至做企业内部知识库都非常顺手。有人可能会问既然 Ollama 本身安装就不难为什么还要用 Docker因为我实际部署过两三台机器之后发现Ollama 对运行环境是有要求的比如 glibc 版本、CUDA 驱动、Python 依赖等等。一旦脱离官方推荐环境安装失败的概率会明显上升。而 Docker 镜像里把运行时全部打好了拉下来就是一个隔离好的“盒子”对宿主机环境几乎零入侵。1.2 Docker 部署相比裸装的三个优势第一个优势是隔离性。Ollama 会写日志、下载几个 GB 甚至几十 GB 的模型文件、占用大量内存如果用裸装方式一旦出了问题系统里会残留一堆服务和依赖。Docker 部署则把这些问题都关在容器里清掉容器就等于完全卸载。第二个优势是迁移方便。我原来在一台 Ubuntu 服务器里配好了这么多模型后来要换到另一台机器直接做个ollama_data数据卷迁移把模型目录打包拷贝过去就完事了不需要重新下一遍模型。如果你用裸装方式得重新开环境、配依赖、重新 pull 模型费时费力。第三个优势是版本管理。Ollama 官方更新很勤使用 Docker 镜像可以精确控制版本比如固定到ollama/ollama:0.5.7这种具体 tag。升级时只要重新拉标签、按容器就行出问题还能马上回滚。裸装升级一旦覆盖了旧版本出现兼容问题就很难恢复。2. 部署前的环境准备2.1 Ubuntu 系统基础要求我用的系统是 Ubuntu 22.04 LTS这套方案对 Ubuntu 20.04 和 24.04 同样适用。内核要求不算苛刻5.4 以上即可因为 Docker 本身依赖内核特性比较大的版本差异主要体现在存储驱动上overlay2 是默认推荐配置Ubuntu 20.04 以上基本不需要额外配置就能满足。硬件上要注意两点。一个是 CPU 架构x86_64 和 ARM64 都可以跑但如果你用的是 CPU 推理小模型 x86_64 会更友好一些。另一个是内存只是跑 0.5B、1.5B 级别的小模型8GB 内存就够了但如果你准备之后尝试 7B 甚至 13B 模型最好上 32GB 内存或者至少有一块 8GB 显存的 NVIDIA 显卡。在动手前先把系统更新到最新避免依赖冲突sudo apt update sudo apt upgrade -y sudo apt install -y curl git nano这里顺手安装 curl 和 git后面下载和编辑配置都会用到。如果你的系统之前装过旧版 Docker建议先把旧版本卸载干净然后再装新的。2.2 安装 Docker 的正确姿势安装 Docker 有两个主流路径官方一键脚本和 apt 源安装。官方脚本最简单但前提是你的网络能顺畅访问 Docker 官方域名curl -fsSL https://get.docker.com | bash -s docker如果网络条件不太稳定更推荐用 apt 仓库方式安装。先添加 Docker 官方 GPG key 和 apt 源然后正常安装sudo install -m 0755 -d /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 sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin装完之后记得把当前用户加进 docker 组否则每次执行 docker 命令都要加 sudosudo usermod -aG docker $USER newgrp docker然后验证一下 Docker 服务状态sudo systemctl enable --now docker docker version这里有一个容易踩的坑如果提示连接 Docker socket 权限不足多半是用户组没有刷新。重新登录一次或者直接执行newgrp docker让当前会话生效就行。2.3 给 Docker 配一份镜像加速拉取 Docker 官方镜像在国内网络环境里经常很慢这个和服务器带宽、地理位置都有关系。解决办法是配置镜像加速器这些加速器本身是合法的公共镜像缓存服务。我通常配置两个加速器比如阿里云容器镜像服务的加速地址和道客云的公共加速地址。先创建或修改/etc/docker/daemon.jsonsudo mkdir -p /etc/docker sudo nano /etc/docker/daemon.json写入以下内容{ registry-mirrors: [ https://docker.m.daocloud.io ] }这里只写了一个地址是因为阿里云加速地址需要用户登录后获取专属域名。道家云的这个公共地址我自己用了很久速度一直很稳定。改完配置后重启 Dockersudo systemctl daemon-reload sudo systemctl restart docker然后用docker info查看 Registry Mirrors 是否生效。以后拉取镜像时Docker 会优先走加速地址速度往往能快不少。3. 用 Docker 跑起 Ollama 服务3.1 拉取官方镜像前先了解目录结构Ollama 官方镜像名是ollama/ollama我建议拉取的时候指定具体版本不要直接用默认的 latest。因为 Ollama 跨版本升级偶尔会有模型兼容性变化钉版本可以让你在重新部署时保持行为一致。先拉镜像docker pull ollama/ollama:latest拉取的同时我们要搞清楚 Ollama 数据存储的位置。Ollama 把模型文件、日志和配置统一放在容器内的/root/.ollama目录这条路径是整个部署方案里最重要的一条路径。如果你不把它挂载到宿主机容器一旦被删除所有已下载的模型都会丢失。3.2 启动容器的关键命令启动命令我会写成这样docker run -d \ --name ollama \ -v ollama:/root/.ollama \ -p 11434:11434 \ --restartalways \ ollama/ollama:latest逐项解释一下参数含义-d后台运行日志交给 Docker 管理。--name ollama给容器起一个固定名字后面执行 exec 命令时方便引用。-v ollama:/root/.ollama创建一个名为ollama的命名卷并挂载到容器内的模型目录。这样即使容器删了模型数据还在。-p 11434:11434把容器内的 11434 端口映射到宿主机后续调用 API、对接 Web 界面都靠这个端口。--restartalways让容器在开机或崩溃后自动拉起很适合作为服务运行。这里我特意用命名卷而不是直接挂宿主机目录。命名卷由 Docker 管理权限不会出现乱七八糟的问题执行docker volume inspect ollama就能看到实际存储位置备份时用tar打包目录也方便。如果你的机器有 NVIDIA GPU并且已经装好 nvidia-container-toolkit可以在docker run里加上--gpus all参数来启用 GPU 加速这个后面第 6.3 节会细说。3.3 验证服务是否正常启动之后先确认容器状态docker ps | grep ollama如果 STATUS 显示Up再调一次 API 验证版本信息curl http://localhost:11434/api/version看到类似{version:0.5.7}的 JSON 返回说明服务已经正常起来了。如果 curl 连接不上第一件事不是查容器而是看容器日志docker logs ollama --tail 50Ollama 监听的是0.0.0.0:11434所以宿主机上的 curl 一定能通。如果你在局域网的另一台电脑上访问不到先去检查防火墙规则Ubuntu 上通常需要放行 11434 端口sudo ufw allow 11434/tcp4. 拉取并运行轻量模型4.1 轻量模型怎么选“轻量模型”不是一个严格的学术定义我习惯把参数量在 0.5B 到 4B 之间、部署后内存占用可控、CPU 也能跑的模型都归到这个范围。下面这几款是我在 Ollama 模型库里实测下来表现不错的轻量模型模型名称参数量默认量化拉取体积适合场景qwen2.5:0.5b0.5BQ4_K_M约 400MB快速验证、函数名生成、简单文本处理qwen2.5:1.5b1.5BQ4_K_M约 1.1GB中文问答、摘要、代码补全llama3.2:1b1BQ4_K_M约 810MB英文对话、指令跟随deepseek-r1:1.5b1.5BQ4_K_M约 1.1GB推理链测试、可解释性内容gemma3:4b4BQ4_K_M约 3.3GB多语言对话、中等复杂度任务如果是第一次部署我非常推荐从qwen2.5:0.5b开始。体积最小、拉取最快先把整条链路跑通再根据需求切换到更大模型。0.5B 的模型虽然能力有限但用来测试 API、试 web 界面、验证代码调用完全够用。需要注意模型体积不是固定不变的Tensor 量化方式会影响实际文件大小。Ollama 默认拉取的标签通常会附上量化信息比如qwen2.5:0.5b默认就是 Q4_K_M如果想用更大精度的版本可以显式指定qwen2.5:0.5b-q8_0这样体积会更大但精度也更高。4.2 在容器内运行模型拉取模型需要在容器内执行ollama命令docker exec -it ollama ollama run qwen2.5:0.5b第一次执行时Ollama 会先下载模型文件。由于模型文件体积有几百 MB 到几 GB下载速度和你的网络条件强相关。如果下载过程卡住或太慢可以参考第 6.2 节的解决办法。下载完成后会进入交互式命令行界面输入文字就会得到模型回复。输入/bye退出交互模式模型会继续保留在容器里。如果你不想进交互式界面也可以直接用命令拉到模型库但不运行docker exec ollama ollama pull qwen2.5:0.5b这样模型就保存在数据卷里了后续要调用时随时可以加载。我比较推荐这种“先 pull 再 run”的方式因为交互模式容易让人误以为模型没有持久化。4.3 通过 REST API 调用模型Ollama 最常用的接口有两个/api/generate和/api/chat。/api/generate适合“一次性文本补全”直接把 prompt 丢进去拿结果curl http://localhost:11434/api/generate -d { model: qwen2.5:0.5b, prompt: 用一句话解释什么是 Docker, stream: false }返回 JSON 里的response字段就是模型生成的文本。stream: false表示等整段生成完再返回调试时用这个参数最方便生产环境里想实现“打字机流式输出”可以把stream设为true然后用curl -N或者 SSE 客户端来消费。/api/chat适合多轮对话场景需要带上历史消息curl http://localhost:11434/api/chat -d { model: qwen2.5:0.5b, messages: [ {role: user, content: 11等于几} ], stream: false }消息结构完全兼容 OpenAI Chat API 的格式后面接 Python、JavaScript 都毫无障碍。我经常用 Python 里的requests直接调这个接口几分钟就能写出一个本地聊天机器人。5. 让 Ollama 容器更顺手Compose 与界面化5.1 用 docker-compose 管理容器实际部署时我从来不靠一条docker run打天下。因为要同时管理 Ollama 和 Web UI用 Compose 编排更清晰还能把端口、卷和重启策略都写在代码里换机器部署时直接复制文件。创建docker-compose.ymlservices: ollama: image: ollama/ollama:latest container_name: ollama restart: always ports: - 11434:11434 volumes: - ollama_data:/root/.ollama volumes: ollama_data:然后启动docker compose up -d之后查看状态就用docker compose ps升级镜像时用docker compose pull docker compose up -d全省事了。如果后续要加第二个服务改 YAML 文件就行不需要再记住那一长串 docker run 参数。5.2 可选加一个 Open WebUI纯命令行和 REST API 已经能干活但如果想让家里其他人也能用我强烈建议配一个 Open WebUI。它是一个开源对话前端界面类似 ChatGPT还能管理多用户和会话记录。在docker-compose.yml里追加一个open-webui服务并让它加入与 Ollama 同一个自定义网络services: ollama: image: ollama/ollama:latest container_name: ollama restart: always ports: - 11434:11434 volumes: - ollama_data:/root/.ollama open-webui: image: ghcr.io/open-webui/open-webui:main container_name: open-webui restart: always depends_on: - ollama ports: - 3000:8080 environment: OLLAMA_BASE_URL: http://ollama:11434 volumes: - openwebui_data:/app/backend/data volumes: ollama_data: openwebui_data:保存后重新docker compose up -d等镜像拉取完成后打开http://服务器IP:3000就能看到注册界面。首次注册的账号就是管理员账号。这个方案最舒服的地方在于Open WebUI 通过容器内部的ollama:11434访问 Ollama不需要走公网端口安全性和易用性都能兼顾。我在局域网里用手机浏览器连这个端口调用本地模型速度非常理想。6. 常见问题与排查实录6.1 Docker 镜像拉取慢这个问题的核心是 Docker Hub 在国内的访问不稳定。解决办法是配置镜像加速器。我在第 2.3 节已经写了 daemon.json 的写法这里补充一个排查思路配置加速后拉取镜像仍然慢可以执行docker info看Registry Mirrors是否已列出你的加速地址如果列表为空说明 Docker 没有重新加载配置重启一下服务。还有个小技巧不要在深夜高峰期执行大镜像拉取很多公共加速服务在晚上 8 点到 11 点会有明显延迟。如果是企业环境自己搭一套镜像仓库做内网缓存才是长久之计。6.2 模型下载慢怎么处理Ollama 的模型默认从registry.ollama.ai下载模型文件动辄几百 MB 到几 GB网络差的时候经常失败。处理方式不止一种我这里说两种我亲测有效的方法。第一种在宿主机先把模型文件通过其他渠道下载好再放进 Ollama 的模型目录。Ollama 模型本质上是 GGUF 文件可以从 Hugging Face 等渠道找到同名格式然后用 Modelfile 的方式导入。比如下载了qwen2.5-0.5b-instruct-q4_k_m.gguf可以先准备一个 ModelfileFROM ./qwen2.5-0.5b-instruct-q4_k_m.gguf然后执行ollama create qwen2.5-custom -f Modelfile这样模型就会出现在本地模型列表里API 调用时填qwen2.5-custom即可。这种“离线导入”方式很适合在公司内网、无外网环境下部署模型。第二种在容器外面先用临时容器预下载再把数据卷挂载到正式容器。原理和第一种类似核心还是把模型文件落进挂载目录。实际操作时我会先运行一个临时容器拉取模型成功后删除临时容器但保留数据卷最后再启动正式容器。这个方案不需要改 Modelfile适合网络波动不大、只是速度偏慢的场景。6.3 GPU 加速用不上如果在docker run里没加--gpus allOllama 会默认使用 CPU 推理。想启用 GPU需要在宿主机安装 NVIDIA 驱动和 nvidia-container-toolkitsudo apt install -y nvidia-container-toolkit sudo nvidia-ctk runtime configure --runtimedocker sudo systemctl restart docker然后启动容器时加上--gpus all并设置环境变量docker run -d \ --name ollama \ --gpus all \ -v ollama:/root/.ollama \ -p 11434:11434 \ ollama/ollama:latest如果你用的是不带 GPU 的机器也不要气馁。轻量模型本身用 CPU 跑也完全能接受0.5B 模型在纯 CPU 环境下单次推理延迟也就一两秒完全够用。6.4 端口冲突与日志查看11434 端口被占用时容器会启动失败。用docker logs ollama --tail 50一般能看到bind: address already in use之类的提示。排查命令sudo lsof -i :11434如果确实是其他进程占用了要么停掉旧进程要么改映射端口比如把宿主机端口改成11435:11434。平时排查问题我也建议先看日志不要动不动就重启容器。Ollama 的日志里会详细记录模型加载过程、API 请求参数和错误堆栈很多“莫名其妙”的问题一眼就能看出来比如模型加载内存不足、请求路径写错等等。6.5 容器权限与数据卷备份命名卷的权限问题在 Ubuntu 上很少出现但如果你手动挂载了一个宿主机目录比如-v /home/ubuntu/ollama:/root/.ollama有时会遇到容器内无法写入的情况。原因通常是目录属主不是 root或者 SELinux 上下文不对。建议优先使用 Docker 命名卷能避开大部分权限问题。备份模型数据很简单直接打包命名卷docker run --rm -v ollama:/root/.ollama -v /tmp/backup:/backup ubuntu tar czf /backup/ollama_backup.tar.gz /root/.ollama恢复时把目录解压回对应位置即可。这个操作我在迁移服务器时用了好多次非常可靠。7. 实际使用中的几点体会部署完成后最直观的变化就是“本地有一个可以随时调用的推理 API”了。我平时写脚本需要批量改写文本、生成标签或者做一些简单的意图识别都是直接调http://localhost:11434/api/generate既不需要外部服务也不用担心数据隐私。轻量模型的价值并不在于生成多惊艳的文章而在于“低成本解决简单问题”。比如给工具函数写注释、从日志里提取关键字段、做简单的文本分类这些场景用 0.5B 到 1.5B 的模型就足够了。非要拿 70B 模型跑这种任务完全是资源浪费。有一点要提前说清楚轻量模型的幻觉问题依然存在对它输出的数字和事实要人工校验。我一开始让它帮忙整理账单数据结果它一本正经地算出了错误的总和这个教训印象很深。最后再分享一个小技巧。因为 Ollama 的模型是惰性加载第一次调用某个模型时会有几秒的冷启动时间。如果你在做定时任务想避免这个延迟可以提前发一个空请求让模型预热curl http://localhost:11434/api/generate -d {model:qwen2.5:0.5b,prompt:ping,stream:false}第二次再调用同样的模型延迟会明显下降。这个预热技巧在我对接定时任务时帮了大忙省掉了每次任务启动时那几秒钟的空等。我到现在已经在两台 Ubuntu 服务器上跑通这套 Docker Ollama 部署一次是纯 CPU 环境另一次加了 NVIDIA GPU。整个链路下来最深的体会是先选一个小模型把流程跑通再根据实际需求逐步换大模型整个过程最稳妥也最不容易中途放弃。