Docker system df查看PyTorch镜像磁盘占用-编程实验室

Docker 磁盘管理实战：精准掌控 PyTorch 镜像空间占用

在 AI 开发日益容器化的今天，一个常见的痛点悄然浮现：明明服务器配置不低，GPU 资源充足，却突然无法拉取新镜像或启动容器——原因竟是磁盘满了。更令人困惑的是，df -h显示根分区还有几十 GB 空间，但 Docker 却报错“no space left on device”。这种“看不见的存储黑洞”，往往就藏在那些被遗忘的 PyTorch 镜像背后。

尤其是当你频繁迭代模型、测试不同版本的pytorch/pytorch:2.x-cuda镜像时，每个动辄 4GB 以上的“重型”镜像层层叠加，共享层看似节省空间，实则一旦累积多个版本，总占用可能远超预期。这时候，docker system df就成了你排查资源消耗的“第一把钥匙”。

为什么标准系统命令查不到 Docker 的真实占用？

很多人习惯用du或df查看磁盘使用情况，但在 Docker 环境中，这些命令会严重失真。因为 Docker 使用的是联合文件系统（如 overlay2），镜像层分散存储在/var/lib/docker/overlay2目录下，普通用户难以直观统计。更重要的是，多个镜像可能共享同一基础层（比如都基于nvidia/cuda:12.1-base），直接对目录求和会导致重复计算。

而docker system df是 Docker 守护进程原生提供的系统级资源统计工具，它能穿透分层机制，准确识别哪些是独占空间、哪些是共享层，并据此给出真实的“可回收空间”建议。这才是我们真正需要的数据。

执行最简单的命令：

docker system df

你会看到类似这样的输出：

TYPE TOTAL ACTIVE SIZE RECLAIMABLE Images 5 3 8.714GB 2.345GB (26%) Containers 7 2 1.201GB 980.4MB (81%) Local Volumes 3 2 450.2MB 120.1MB (26%) Build Cache 12 - 5.2GB 4.8GB

这里的关键词是RECLAIMABLE—— 它告诉你，即使某些镜像或容器已经停止运行，只要没有被显式删除，它们仍占用着物理空间。而这一部分，正是可以通过清理操作拿回来的“闲置资产”。

比如上面的例子中，虽然只有 3 个活跃镜像，但总共 5 个镜像占用了 8.7GB，其中 2.3GB 可以通过docker image prune回收。如果你正卡在“无法拉取新镜像”的窘境，这 2.3GB 很可能就是突破口。

深入分析：谁才是真正的“空间大户”？

光看总量还不够，我们需要知道具体是哪个镜像在“吃”磁盘。这时就要加上-v参数查看详细信息：

docker system df -v

输出节选如下：

Images space usage: REPOSITORY TAG IMAGE ID CREATED SIZE SHARED SIZE UNIQUE SIZE CONTAINERS pytorch/pytorch 2.8-cuda abc123def456 2 weeks ago 4.2GB 0B 4.2GB 2 nvidia/cuda 12.1-base def789ghi012 3 weeks ago 2.8GB 1.5GB 1.3GB 1 ubuntu 20.04 jkl012mno345 1 month ago 72MB 72MB 0B 0

注意这里三个关键字段：
-SIZE：该镜像的总大小；
-SHARED SIZE：被其他镜像共享的部分；
-UNIQUE SIZE：仅由该镜像独占的空间。

你会发现，nvidia/cuda:12.1-base虽然本身有 2.8GB，但它贡献了 1.5GB 的共享层，说明它是多个 PyTorch 镜像的基础依赖。因此，你不能简单地认为“删掉它就能省 2.8GB”——实际上只会释放 1.3GB 的独占部分，且可能导致其他镜像损坏。

反观pytorch/pytorch:2.8-cuda，它的 UNIQUE SIZE 高达 4.2GB，意味着这个镜像是完全独立占用的。如果它不再被任何容器引用（ACTIVE=0），那它就是最佳的清理目标。

这也引出了一个重要原则：优先清理高 UNIQUE SIZE 且非活跃的镜像，而非盲目删除基础镜像。

实战场景：旧版本 PyTorch 镜像堆积导致空间告急

设想这样一个典型场景：你在过去几个月里依次使用了pytorch:2.6-cuda、2.7-cuda和最新的2.8-cuda。每次升级都只是拉取新镜像，从未清理旧版。现在想尝试一个实验分支，却发现：

$ docker pull pytorch/pytorch:2.8-cuda-devel-jupyter Error response from daemon: failed to copy: write /var/lib/docker/overlay2/...: no space left on device

此时运行docker system df：

TYPE TOTAL ACTIVE SIZE RECLAIMABLE Images 6 1 10.5GB 8.2GB (78%)

惊人的 78% 可回收率！说明大部分镜像其实早已废弃。再结合docker images | grep pytorch查看：

REPOSITORY TAG IMAGE ID SIZE pytorch/pytorch 2.6-cuda a1b2c3d4e5f6 4.1GB pytorch/pytorch 2.7-cuda b2c3d4e5f6a7 4.15GB pytorch/pytorch 2.8-cuda c3d4e5f6a7b8 4.2GB

三个版本累计超过 12GB 存储。而当前项目只用2.8，前两个完全可以安全移除。

执行清理：

# 删除指定旧版本镜像 docker rmi pytorch/pytorch:2.6-cuda pytorch/pytorch:2.7-cuda # 或批量清理所有悬空镜像（<none>标签） docker image prune -a

瞬间腾出近 8GB 空间，问题迎刃而解。

关于 PyTorch-CUDA 镜像的设计逻辑与使用建议

官方pytorch/pytorch镜像之所以体积庞大，是因为它集成了太多“开箱即用”的组件：CUDA 工具包、cuDNN、Python 科学栈（NumPy/Pandas）、Jupyter Notebook、SSH 服务等。这种设计极大降低了入门门槛，但也带来了资源冗余的风险。

例如，pytorch:2.8-cuda-devel-jupyter包含 Jupyter，适合交互式开发；而如果你只是跑训练脚本，完全可以用更轻量的pytorch:2.8-cuda-devel，节省约 300MB 空间。

启动命令也值得优化：

docker run -it --gpus all \ -p 8888:8888 \ -p 2222:22 \ -v $(pwd):/workspace \ --name pt-dev \ pytorch/pytorch:2.8-cuda-devel-jupyter

这里几个参数的意义不容小觑：
---gpus all：启用 NVIDIA Container Toolkit，让容器内torch.cuda.is_available()返回True；
--v $(pwd):/workspace：实现代码热更新，避免每次修改都要重建镜像；
---name pt-dev：命名容器，便于后续管理（如docker stop pt-dev）。

值得注意的是，即使你停止了容器（docker stop pt-dev），它仍然占用磁盘空间——这部分属于“可写层”（container writable layer），记录了你在容器内的所有文件改动。除非你明确删除（docker rm pt-dev），否则这部分不会被自动释放。

这也是为什么docker system df中 Containers 的 RECLAIMABLE 常常很高：大量“已停止但未删除”的容器成了隐形空间吞噬者。

如何建立可持续的资源管理习惯？

很多开发者只在“出事”时才想起查磁盘，结果往往是临时救火。更好的做法是将资源监控纳入日常流程：

定期巡检：每周执行一次docker system df，记录趋势变化；
命名规范化：自建镜像时使用清晰标签，如my-project-pytorch:v2.8-gpu，避免出现一堆<none>镜像；
CI/CD 自动清理：在 CI 流水线末尾加入docker system prune -f，防止测试镜像堆积；
选择合适变体：根据用途选用镜像后缀：
--devel：包含编译工具，适合开发；
--runtime：最小运行环境，适合部署；
--jupyter：带 Jupyter，适合教学或原型验证；
监控集成：结合 Prometheus + cAdvisor 实现可视化监控，设置磁盘使用率告警阈值（如 >80%）。