91n 网络环境下最优 TensorFlow 镜像拉取方案
在金融、制造等对安全与稳定性要求极高的企业环境中，AI 模型的部署早已不再是'能不能跑'的问题，而是'能否稳定、快速、可复制地交付'。尤其是在类似'91n'这类受限内网中——外网访问受限、DNS 解析不稳定、带宽紧张——开发者常常面临一个看似简单却极其恼人的场景：执行一条 docker pull tensorflow/tensorflow:2.13.0-gpu-jupyter 命令，结果卡住半小时无响应，最终构建失败。这种体验不仅拖慢了 CI/CD 流程，更让团队陷入'一次能跑，下次报错'的环境怪圈。
这背后的问题核心，并非 TensorFlow 本身有多复杂，而在于容器镜像分发机制与封闭网络之间的根本性冲突。官方镜像动辄数 GB，依赖层层拉取，一旦中间断连或源不可达，整个流程就宣告失败。真正的解决方案，不是反复重试，也不是手动打包压缩，而是从架构层面重构镜像获取路径——通过私有镜像代理实现本地缓存与透明加速。
TensorFlow 镜像本质上是一个预装了 Python 运行时、CUDA 驱动（GPU 版）、cuDNN、TensorFlow 库及常用工具链（如 Jupyter、TensorBoard）的完整容器环境。它的价值在于将复杂的深度学习依赖封装成一个可移植、可版本控制的单元。比如这条标准引用：
tensorflow/tensorflow:2.13.0-gpu-jupyter
标签明确指出了版本（2.13.0）、硬件支持（GPU）和交互方式（Jupyter），使得任何人在任何机器上都能获得一致的开发体验。但这也带来了副作用：首次拉取需要从 Docker Hub 下载数十个镜像层，每层都可能因网络抖动中断。
更麻烦的是，在'91n'这类网络中，你甚至无法保证 hub.docker.com 能被正确解析。即使能通，公网平均下载速度往往只有几 MB/s，一次完整拉取耗时超过 10 分钟是常态。如果多个节点同时构建，还会进一步挤占本就不宽裕的出口带宽。
这时候，很多人会想到'摆渡机'方案：在外网机器先拉下来，再推送到内网仓库。这确实可行，但属于被动应对，难以规模化。理想的做法应该是自动化、透明化、可持续演进的基础设施级支持。
这就引出了我们真正要依赖的技术——私有镜像代理。
想象这样一个场景：当你在内网执行 docker pull tensorflow/tensorflow:2.13.0-gpu-jupyter 时，请求并没有直接冲向公网，而是被自动路由到一台位于 DMZ 区的本地服务（例如 mirror.91n.local）。如果这个服务之前已经有人拉过该镜像，它会立刻返回缓存数据，速度可达百兆甚至千兆内网水平；如果还没有，它会代你去公网拉取，边下边返，并把结果永久保存下来，供后续所有人复用。
这就是私有镜像代理的核心逻辑：按需缓存 + 请求转发。典型实现包括 Harbor、Nexus Repository、阿里云 ACR 企业版等。它们不只是简单的'镜像仓库'，更是企业级镜像治理的中枢节点。
要启用这一机制，只需在所有 Docker 客户端配置 registry-mirrors。编辑 /etc/docker/daemon.json：
{
"registry-mirrors": [ "https://mirror.91n.local" ],
"insecure-registries": [ "registry.91n.local:5000" ],
"log-driver":
