Docker Prune 清理无用 PyTorch 镜像释放磁盘
在 GPU 服务器上跑模型的你，是否经历过这样的场景：某天突然发现df -h显示根分区爆了，训练任务被中断，排查后才发现/var/lib/docker占用了超过 200GB？点进一看，几十个<none>:<none>的镜像层层叠叠，全是之前构建 PyTorch-CUDA 环境时留下的“历史遗迹”。
这并非个例。在深度学习开发中，我们频繁地基于不同版本的 PyTorch、CUDA 和依赖库构建定制化镜像。每次docker build都会产生中间层，而一旦打标签覆盖旧镜像或切换分支重构环境，那些未被引用的镜像就会变成悬空状态——它们不再服务于任何容器，却依然占据着数 GB 甚至十几 GB 的空间。
更麻烦的是，这些镜像往往难以手动识别和删除：名称混乱、版本不清、来源不明。一个误删可能导致正在调试的容器无法重建；而不删，磁盘又持续告急。如何在安全与效率之间找到平衡？
答案就在docker prune系列命令中。
Docker 的分层文件系统机制决定了它天生容易积累冗余数据。当你执行一次镜像构建时，Dockerfile 中的每一行指令都会生成一个只读层。如果后续修改并重新构建，新镜像会复用部分已有层，但旧的整体镜像（尤其是已被覆盖标签的）并不会自动消失。
这类失去标签且无容器依赖的镜像被称为悬空镜像（dangling images），典型表现为：
REPOSITORY TAG IMAGE ID CREATED SIZE <none> <none> abc123def456 3 days ago 7.2GB <none> <none> xyz987uvw654 5 hours ago 6.8GB它们就是docker image prune的主要清理目标。
该命令默认行为非常安全：仅扫描并删除悬空镜像，不会触碰任何带有有效标签或正被容器使用的镜像。你可以先预览哪些会被清理：
docker image prune --dry-run确认无误后执行实际清理：
docker image prune如果你希望进一步释放空间，比如在 CI/CD 流水线服务器上定期“瘦身”，可以使用-a参数删除所有未被使用的镜像——即哪怕有标签，只要没有运行中的容器依赖它，也会被清除：
docker image prune -a -f这里的-f表示免交互确认，适合写入自动化脚本。但要注意，这种操作不可逆。建议配合过滤器使用，避免误删近期仍在使用的测试镜像：
# 只删除创建时间超过7天的未使用镜像 docker image prune -a -f --filter "until=168h"这个策略尤其适用于团队共享的开发机或 Jenkins 构建节点：既能保留最近常用的环境，又能防止长期积累导致磁盘耗尽。
比起单一清理镜像，docker system prune提供了更高维度的系统级回收能力。它不仅处理悬空镜像，还会一并清理以下资源：
- 停止的容器（exited containers）
- 未使用的网络（unused networks）
- 构建缓存（build cache）
这意味着，即使你已经停止了某个 PyTorch 调试容器，它的文件系统层仍可能保留在docker container ls -a列表中；同样，构建过程中产生的临时缓存也可能堆积成山。system prune正是为这类“隐形占用”而生。
基础用法如下：
docker system prune它会列出将要删除的内容，并提示你确认。对于无人值守环境，可添加-f强制执行：
docker system prune -f若想彻底清理，包括所有未被使用的镜像（不仅仅是悬空的），加上-a：
docker system prune -a -f注意：此操作会影响所有项目，因此不建议在生产环境中随意使用。
还有一个常被忽略但极其重要的选项是--volumes：
docker system prune -a --volumes -f这会额外删除未被容器挂载的 volume。虽然能大幅释放空间，但也意味着所有本地持久化数据（如数据库文件、缓存目录）都将丢失。务必确保关键数据已备份或挂载到外部存储。
在 PyTorch 开发场景中，镜像体积本身就大得惊人。一个标准的pytorch:2.0-cuda11.8官方镜像轻松突破 7GB，若再加上自定义依赖（如 OpenCV、TensorBoard、Hugging Face 库等），很容易达到 10GB 以上。开发者每做一次小改动就重建镜像，不出一周就能积攒下数十 GB 的垃圾。
更复杂的问题来自多版本共存需求。例如：
- 实验 A 使用 PyTorch 1.13 + CUDA 11.7；
- 实验 B 使用 PyTorch 2.0 + CUDA 11.8；
- 推理服务 C 使用 PyTorch 2.1 + CUDA 12.1；
每个组合都需要独立镜像，且必须与主机驱动兼容。NVIDIA 明确要求：容器内 CUDA 版本不能高于主机驱动支持范围。这就迫使我们在升级驱动前不得不保留老版镜像作为过渡方案。
面对这种局面，单纯依赖prune并不够，还需结合良好的命名与标签管理策略。推荐采用如下格式：
# 格式：[项目]-[框架]-[版本]-[硬件] docker tag my-experiment pytorch:v2.0-cuda11.8然后在构建时添加元信息标签，便于后期筛选：
docker build \ --label "ai-project=vision" \ --label "pytorch-version=2.0" \ --label "cuda-version=11.8" \ -t pytorch-vision:v2.0 .有了这些标签，就可以实现精准清理。例如，只删除属于某个项目的旧镜像：
docker image prune -a -f --filter "label=ai-project=vision"或者清理特定 PyTorch 版本的历史构建：
docker image prune -a -f --filter "label=pytorch-version=1.13"这种方式既保证了灵活性，又避免了“一刀切”带来的风险。
我们来看一个真实运维流程的应用案例。假设在一个多用户 AI 实验平台上，每位研究员都有自己的开发容器，平台每天接收大量构建请求。随着时间推移，磁盘使用率逐渐攀升至 85% 以上。
此时，可以通过定时任务自动触发分级清理策略：
# crontab entry: 每日凌晨2点执行 0 2 * * * /usr/bin/docker system prune -f >> /var/log/docker-prune.log 2>&1这只是第一步。当监控系统检测到磁盘使用率连续两天超过 90%，则触发更激进的操作：
#!/bin/bash # aggressive-cleanup.sh # 删除所有超过5天未使用的镜像 docker image prune -a -f --filter "until=120h" # 清理孤立的 volumes（谨慎！） docker volume prune -f # 输出当前磁盘状态 df -h /var/lib/docker | tail -n1 >> /var/log/cleanup-report.log为了防止误删重要镜像，可以在生产环境使用的镜像上打“保护标签”：
docker image tag pytorch-prod:v2.1 protected/pytorch-prod:v2.1并通过配置.dockerignore或组织内部规范，约定所有带protected/前缀的镜像不得被自动化脚本清理。
此外，日志审计也不可或缺。每次prune操作都应记录时间、删除数量和释放空间，以便事后追溯：
echo "$(date): Starting prune..." >> /var/log/docker-prune.log docker system prune -f --format "table {{.Description}}\t{{.Size}}" >> /var/log/docker-prune.log最终你会发现，真正解决问题的不是某一条命令，而是一套完整的生命周期管理思维。
docker prune本身只是一个工具，但它背后体现的是对资源使用习惯的反思：我们是否在盲目构建？是否有清晰的版本控制？是否建立了合理的清理机制？
在现代 AI 工程实践中，环境管理早已不再是“配好就行”的一次性工作。随着 MLOps 的推进，从代码、数据到环境的全流程可复现性成为标配。而一个整洁、可控的 Docker 环境，正是这一切的基础。
下次当你准备敲下docker build .之前，不妨先问自己一句：这个镜像，将来怎么删？
