物理隔离 LLM 蓝图：无出站流量部署的真正需求

云端 AI 的策略通常建立在一个没有人明确写下来的前提之上：出站 HTTPS (outbound HTTPS)。厂商 API、托管评测器、遥测流水线、模型注册表、向量存储、仪表板 SaaS、密钥管理器——其中的每一个都静默地解析到公网上的一个域名。一旦拔掉这根电缆，整个技术栈并不会优雅降级，而是会直接崩溃。

大多数团队直到那一刻才会发现，他们的架构中存在从未考虑过的出站依赖。一个“微小”的提示词更新可能需要调用托管分类器；评估套件需要通过网络访问 LLM 评测器；可观测性代理会向后端发送数据；模型注册表从 CDN 拉取权重。这些都不是恶意的，也并不罕见。当你忽视了那根电缆时，云原生技术栈本就是这个样子的。

国防、医疗和金融服务的部署越来越无法容忍这根电缆。原因是不容置疑的：数据分级、驻留规则、合同排他性、横向移动风险、监管定义的托管链。洛斯阿拉莫斯国家实验室 (Los Alamos National Laboratory) 在 2025 年初将其 LLM 技术栈迁往本地，以处理受控非密信息 (CUI)、ITAR 标记数据以及非密受控核信息 (UCNI)。处理受保护健康信息 (PHI) 的医院诊断 Copilot 不能将提示词路由到厂商的推理端点。受 FINRA Rule 3110 和 SEC Regulation S-P 监管的经纪交易商，在面对客户投资组合数据跨越第三方 API 时，给不出满意的答复。

“只需自建托管权重开放模型”这句话将运维范畴低估了一个数量级。模型是最简单的部分，接下来的内容才是其他所有部分的蓝图。

出站审计优先，而非推理服务器

在 GPU 上架之前，团队必须回答一个大多数团队无法回答的问题：列出你的 AI 技术栈目前发出的每一次出站网络调用。不仅仅是推理 API。还有托管评测器、Hugging Face 下载、提示词监控 SaaS、向量数据库的遥测、将追踪发送到托管后端的 OpenTelemetry 收集器、评估流水线在发生回归时提醒的 Slack Webhook、SDK 中的 npm postinstall 脚本。

一个有用的练习：在默认拒绝出站规则的网络命名空间中运行现有技术栈，观察哪些部分会断开。这些故障点几乎与物理隔离版本必须具备的新组件一一对应。大多数团队会发现 5 到 15 个他们之前未察觉的独立出站依赖。

人们往往倾向于逐个处理这些问题——这里做一个本地镜像，那里加一个配置标志。真正可扩展的准则是将出站限制视为一等架构关注点，包括：一份明确的允许访问目的地列表（通常是空集，或受严格控制的内部镜像）、一个在引入新依赖时导致构建失败的 CI 检查，以及一个在生产环境中执行相同规则的网络策略。如果没有这一关口，物理隔离的承诺会随着每一个悄悄增加的依赖而逐渐瓦解。

模型产物溯源是最难的问题

在隔离边界内，模型文件不再是你通过 pip install 就能得到的东西。它是一个受监管的产物，团队必须在审计中为其溯源提供辩护。这里有三个复合问题。

供应链默认就是被污染的。 权重开放模型库是新的攻击目标。研究人员已经证明，Hugging Face 的 Safetensors 转换服务可能被利用来劫持提交的模型，且 OWASP 的 LLM Top 10 将供应链风险 (LLM03:2025) 列为主要攻击类别。SafeTensors 格式缓解了最糟糕的 Pickle 式代码执行问题，但它没有解决溯源问题。目前仍缺乏广泛采用的机制来对权重进行加密签名，并在加载时验证该签名。团队必须自己建立这个关口：对每个模型进行哈希锁定 (hash-pin)，在引入时使用内部密钥对产物进行签名，并拒绝加载任何签名验证失败的内容。

依赖树比软件更广泛。 传统的 SBOM 追踪库。AI/ML 物料清单 (MLBOM，越来越多地以 CycloneDX 格式发布) 则必须追踪模型、分词器、安全分类器、LoRA 适配器、合并的检查点、生成部署权重的量化工具、发布前的评估套件，以及该链条中每个环节附带的许可证。一个微调的微调的微调可能会引入一个来自基础模型的许可证条款，而该条款可能从未被团队认可。MLBOM 是唯一能使该链条可审计的产物。

更新不是幂等的。 在云端版本中，模型升级只是一个配置更改。在物理隔离版本中，模型升级是一个产物传输过程，必须通过签名包发布流程、安全性复审和托管链日志。模型权重本身可能在 10–400 GB 之间，必须通过加密介质或单向数据闸门移动。每一次更新都是一次发布；每一次发布都是一次文书工作。那些在路线图中规划了每月模型更新的团队会发现，他们交付的流程根本无法通过安全部门的审批。

评估栈必须存在于边界之内

加载中…