很多工程师第一次上 Ollama 容器，卡的不是拉镜像，而是拉完发现模型下载慢、容器重启模型就没了、外面连不上 11434。这篇按「拉取—运行—挂载—验证」四步走一遍，把端口绑定、模型存储目录、GPU 透传和常见报错按顺序列出来。具体镜像标签和体积不写死，去站内页面核对当时的数字。
很多工程师第一次上 Ollama 容器，卡的不是拉镜像这一步，而是拉完之后发现模型下载慢、容器一重启模型就没了、外面机器连不上服务端口。这三个问题基本能覆盖八成求助场景，而且都能在起容器之前就规避掉，不需要事后再挪数据、改网络。
这篇按「拉取—运行—挂载—验证」四步走，把端口绑定、模型存储目录、GPU 透传和常见报错按顺序列清楚。具体镜像标签、镜像体积和内部行为这类会变的数字，一律不写死，去站内资料库核对当时的数字。下面进入正题。
第一步：把镜像拉下来，别急着 run
拉镜像本身只有一条命令，但拉之前有两件事没确认，后面全是坑。一是运行用户有没有权限操作 Docker，非 root 账号不在 docker 组里会直接报权限错误，这时候先别怀疑网络，先看报错原文。二是镜像标签对应的是不同硬件后端，NVIDIA、AMD、CPU 各有各的版本，标签拉错的现象很典型：容器能起来、服务也能跑，但进去看不到显卡。
- 确认身份与权限用 whoami 和 id 看当前用户在不在 docker 组；不在就切到有权限的账号，或按运维规范加组后重新登录，别用临时 sudo 硬顶，后面挂载权限还会踩一次。
- 选对硬件标签先明确目标机器是 NVIDIA 卡、AMD 卡还是纯 CPU，再决定拉哪个标签。拿不准就先用 CPU 版把流程跑通，再换 GPU 版，避免一上来同时排查镜像和显卡两个变量。
- 处理拉取速度国内拉取慢属于常见情况，加速方式的思路先定好。具体可用的镜像源和配置写法会变，到 /tools/speed-test/tools/speed-test 这类工具页确认当时的推荐配置，别照抄一年前的教程。
第二步：起容器，端口和存储先定死
起容器这条命令里有三个决定长期稳定性的参数：端口映射、模型存储位置、容器名与重启策略。它们都不是启动时才会暴露问题，而是过几天、过几周才慢慢显现，所以别用最长的那条命令，用最短但把这三件事写全的那条。
| 配置项 | 判断标准 | 不设会怎样 |
|---|---|---|
| 端口映射 | 是否需要外部机器访问，还是只给本机用 | 只绑回环时外面连不上，绑全网段时默认暴露 |
| 模型存储 | 用 volume 或 bind mount 挂到宿主机 | 容器删掉模型全丢，重新拉一遍 |
| 重启策略 | 宿主机重启后服务是否要自动回来 | 服务悄悄没了，没人发现直到业务报错 |
| 容器名 | 是否要固定名字方便进容器排查 | 容器 ID 每次变，脚本和文档全得改 |
- 端口先想清楚访问范围：只给本机用就绑回环，要给其他机器用再绑全部网卡，别默认开全网
- 模型目录不要留在容器可写层，用命名 volume 或宿主机目录挂进去，两种方式按团队备份习惯选
- 容器名固定下来，配上重启策略，避免宿主机重启后没人知道服务停了
- 这三项建议直接写成启动脚本或 compose 文件，别每次手敲一遍，手敲迟早漏一项
第三步：GPU 透传与模型目录挂载
GPU 这条线的核心不是命令长什么样，而是容器运行时有没有配对、显存可不可见。宿主机驱动正常，不代表容器里就能看到卡。起完容器第一件事是进去跑一次设备查询，确认能看到显卡和显存，看不到就说明透传没生效，后面的模型跑多慢都别急着归因到模型本身。
模型存储目录默认落在容器内部某个位置，宿主机目录映射到哪、该目录属主和权限够不够，直接决定模型拉取会不会中途失败。这个目录通常可以用环境变量改，但改完必须同步改挂载路径，两边不一致就会出现「明明拉完了却找不到模型」的怪现象。
- 容器运行时
- 让容器能访问宿主机 GPU 的那层配置，没配好容器里看不到卡
- 显存可见性
- 进容器跑设备查询能列出显卡和显存，才算透传成功
- 模型目录环境变量
- 指定模型存放位置的开关，改了它就必须同步改挂载路径
- 目录属主
- 挂载目录的所属用户和权限，不对齐会让拉取写入失败
挂载一致性自查顺序
- 先在容器里确认模型目录环境变量指向哪个路径
- 再看这个路径是不是挂载进来的宿主机目录
- 然后核对宿主机该目录的属主和可写权限
- 最后拉一个小模型验证能否落地并再次调用到
第四步：验证服务与排查顺序
验证要分层做，不要一上来就从外部机器捅。顺序是：容器内确认服务在监听，宿主机 curl 一次，外部机器再 curl 一次。三层逐级查，能立刻分清是绑定地址问题、宿主机网络问题还是外部网络问题。这一条比记住任何报错都管用。
- 容器内自检进容器看服务进程在不在、监听在哪个地址和端口。监听地址是回环还是全部网卡，直接决定外部能不能连。
- 宿主机验证在宿主机上请求一次服务地址，通则说明容器和宿主机之间没问题，不通就回头查端口映射。
- 外部验证从另一台机器请求，不通再查防火墙、安全组和绑定地址，别一上来就改容器配置。
- 性能异常排查响应慢先看是不是退回了 CPU 跑，再确认模型是否常驻显存、拉取是否还在后台进行，最后才怀疑硬件。
- 连不上：先查绑定地址是否只绑了回环，再查防火墙和安全组
- 拉不到模型：先查存储目录权限和挂载路径是否与环境变量一致
- 跑得慢：先确认 GPU 是否可见，再看模型有没有常驻显存
- 重启丢模型：先确认模型目录是不是挂载进来的持久化路径
判断标准就一条：能在容器删掉重建之后，不重新拉模型、外部照常调用，就算部署稳了。做不到这一点，说明第二步和第三步里至少有一项没做对。如果团队里还要比不同部署方式的成本，到 /price-watch/price-watch 看当时的追踪数据，别凭印象拍。
下一步把端口、存储、GPU 这三项的判断标准对照一遍，再去站内核对当时的镜像标签与配置写法，避免照着过期教程返工。→常见问题
容器里的 Ollama 和直接装在宿主机上有什么区别？
功能一致，差别在隔离和运维方式。容器把依赖打包好了，换机器迁移更省事，代价是模型存储、GPU 透传、端口绑定都要显式配置。如果你的机器就一台、也不打算做环境隔离，直接装宿主机反而少一层排查。团队多环境部署、要统一版本时，容器更省心。
为什么容器起来了，模型却拉不动或者拉一半断？
三个方向按顺序查：一是容器到外网的连通性，代理或 DNS 没配好，pull 会直接卡住；二是挂载目录的写权限，宿主机目录属主不对，下载到一半写不进去；三是磁盘空间不够，模型文件通常比镜像大得多。先把这三项排掉，再考虑镜像源问题，具体路径配置到站内页面核对。
能不能直接把容器里的模型拷出来复用？
可以，思路是把模型存储目录整目录挂到宿主机，换容器时把同一个目录再挂进去，服务就会认到已有模型。注意目录结构和权限保持一致，跨机器迁移还要确认两边架构和硬件后端一致，否则模型能识别但跑不动。离线环境批量迁移的做法建议另开一条流程单独验证。
