先规划传输，再规划架构：隔离部署没人提醒你的教训

有位叫 Uzair Afridi 的开发者，在 X（原 Twitter）平台上分享了一条隔离部署的教训。他说，这些事没人提前提醒你。

air-gapped 这个词，简单说就是物理断网。目标环境不连互联网，甚至不连任何外部网络。涉密内网、核心生产系统、部分工业控制区域，都有这种要求。在开发机上敲一行 pip install 就能解决的事，在隔离环境里要拆成十几步手工操作。

他列了三件事，以前理所当然，现在全部失效：

不能 pip install 任何东西。依赖树在开发环境里跑得好好的，到目标机器上缺这个缺那个。wheel 文件要一个个准备，按依赖顺序装，漏掉一个就卡住。
不能从 HuggingFace 拉模型。HuggingFace 是 AI 圈常用的模型托管平台，上面的预训练权重动辄几个 GB，只能在有网的地方提前下载，再想办法送进去。文件不齐、版本不对、分词器忘带了，都会在部署现场变成事故。
不能搜索报错。以前遇到报错，复制粘贴进搜索引擎，答案就出来了。隔离环境里，你只能盯着终端里那段错误信息，靠上下文去猜。

所以那台机器上需要的每一个 wheel、每一个权重、每一个容器镜像，都得先搬进去。U 盘、移动硬盘、光盘，甚至专用的数据摆渡设备，都可能是运输工具。文件多大、有没有损坏、版本匹不匹配，都是要提前解决的问题。

Uzair 给的建议是：plan the transfer before you plan the architecture。先规划传输，再规划架构。

这句话值得细想。通常一个项目先从架构开始：几个服务、多少资源、怎么部署。但隔离部署的顺序是反过来的。传输方式决定了你能带进去什么，能带进去什么决定了架构的边界。模型大小限制硬件选型，硬件选型限制机柜空间，机柜空间限制运输方案。架构画得再漂亮，东西进不去，等于零。

这类部署还有一些容易忽视的环节：依赖版本不锁定，离线安装时才发现解析冲突；文件拷进去才发现校验和不匹配，来回折腾；容器镜像导入时因为平台差异报错，又得重新导出。

对做 AI 应用的人来说，隔离部署不是最常见的情况，但遇上一次就够受的。开发环境里提前模拟一遍离线安装，锁定依赖版本，把所有模型文件、镜像都打包验一遍，成本比在目标现场补救低得多。

先把传输方案写清楚，再谈架构设计，这算是最便宜的保险。