物理隔离 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 之间，必须通过加密介质或单向数据闸门移动。每一次更新都是一次发布；每一次发布都是一次文书工作。那些在路线图中规划了每月模型更新的团队会发现，他们交付的流程根本无法通过安全部门的审批。

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

云端 AI 评估流水线几乎总是带有托管依赖：调用公网 GPT-4 或 Claude 的 LLM 评审模型、运行时从 Hugging Face 获取的基准数据集、以及将指标上传到 SaaS 可观测性工具的结果仪表板。在物理隔离（Air-gap）环境下，这些都无法生存。

在边界内构建评估栈意味着三个具体方面。评审模型必须是你自托管的模型 —— 通常是一个较小的、本地部署的变体，其与云端评审模型的校准度在边界关闭前已在线下完成衡量。RAND 的评审模型可靠性测试框架（Judge Reliability Harness）研究是一个有用的参考，用于压力测试评审模型的评分在提示词扰动下是否保持稳定；当你无法简单地更换一个前沿模型来解决争议时，这一点尤为重要。评估框架 —— 大多数团队会适配 EleutherAI 的 lm-evaluation-harness 或构建类似的工具 —— 必须在出厂时预置基准数据，而不是在运行时拉取。仪表板也必须是自托管的，通常是针对本地时序数据库的 Grafana 技术栈。

最容易被低估的部分是基准真相（Ground Truth）。在云端工作流中，基准真相标签通常来自使用 SaaS 标注工具的人工审核员。在物理隔离的工作流中，标注工具必须位于边界内，这意味着要么在本地部署开源标注工具（如 Argilla、Doccano），要么构建内部工具。这通常是建立受监管评估流水线中耗时最长的任务（Long-pole task），也是大多数团队忘记纳入规划的一项。

集群管理、发布流转与 kubectl apply 的终结

云端 LLM 推理服务已经收敛为一种 Kubernetes 原生模式：在 vLLM 之上运行 KServe 和 llm-d，并使用 GitOps 进行跨环境的发布流转。这种模式可以转移到物理隔离环境，但有一个关键变化：GitOps 控制器无法连接回托管的 Git 服务商。集群必须从内部镜像库拉取，而镜像库必须通过带外同步（Out-of-band sync）进行填充，这种同步本身就是一个发布事件。

集群管理器 —— 无论是 Rancher Fleet、Argo CD、Flux 还是厂商的 Kubernetes Fleet Manager —— 晋级模型的方式与晋级服务相同：清单文件（Manifest）通过摘要（Digest）引用模型产物，控制器调和期望状态，推理集群从内部注册表拉取产物。不同之处在于，注册表现在是信任边界的一部分。未经授权的集群泄露拉取模型产物属于数据定级事故。

发布过程必须通过策略（Policy）而非流程（Procedure）来强制执行。准入控制器验证清单中的模型摘要是否匹配白名单上的签名。网络策略防止推理 Pod 向除本地模型服务器和本地遥测采集器之外的任何地方发起出站调用。Pod 安全标准阻止任何未经明确批准的 Sidecar 注入。集群的角色绑定限制了能够将模型晋级到生产环境的人员范围，这比云端版本的人数更少，因为配置错误的发布后果更加严重。

一个有用的操作规则是：如果系统的云端版本只需要一名审核员批准即可更新模型，那么物理隔离版本可能不行。物理隔离环境下的发布在设计上就是缓慢的，任何假装不慢的团队，在监管机构第一次要求提供变更控制证据时就会发现这一点。

破坏物理隔离声明的隐藏出站依赖

即使显式的云端依赖消失了，仍有三类隐藏的依赖会悄悄重新引入出站流量。

SDK 与框架。 现代 Python 包默认会发送后台遥测、自动更新检查和“匿名使用统计”。禁用所有这些功能是一个针对每个包的重复性工作，且每次依赖升级都必须重新进行。如果包的第一步动作就是“打道回府”（Call home），那么在边界内执行 pip install 就是个误称；本地 PyPI 镜像必须是唯一可解析的索引，如果尝试在其他地方解析，构建必须闭锁失败（Fail closed）。

向量嵌入（Embeddings）。 许多“边界内 RAG”架构会悄悄地为文档库或传入的查询调用托管的向量嵌入 API，因为团队选择的向量数据库其默认嵌入集成是 SaaS 端点。向量嵌入模型必须与生成模型一起自托管，并且架构图应明确展示这一点。如果图中有一个离开边界并标注为“Embeddings”的箭头，那么物理隔离的声明就是虚构的。

遥测与可观测性。 云原生可观测性方案（Datadog、Honeycomb、New Relic）无法在边界内存活。替换它意味着需要一套自托管的 Prometheus + Grafana + Loki + Tempo 技术栈，以及一套符合环境数据定级规则的日志保留策略。保留策略并非易事：定级的推理日志本身可能也是机密的，这意味着可观测性后端必须与推理集群处于相同的数据定级水平。将它们路由到较低级别的分析师仪表板属于跨域传输事件，而不是简单的 Grafana 数据源。

云原生技术栈认为理所当然的事

大多数团队都不愿面对的一个架构现实是：云 AI 技术栈并非只是恰好托管在云端的通用平台。它是一个每一层都将“出站流量”（egress）视为免费原语的平台——无论是为了更新、评估、遥测、密钥管理还是身份验证。一旦拔掉网线，这些层级的每一处都必须长出云端版本从未需要的原语：一个同时也是主权制品库的模型注册表，一个同时也是自包含评判器的评估框架，一个同时也是严密可靠发布流水线的集群管理器，以及一个遵循与数据平面相同数据分类规则的可观测性技术栈。

成功的团队不会将“气隙隔离”（air-gap）视为需要规避的约束，而是将其作为从第一天起就决定架构的设计需求。那些在收到监管机构信函后才急忙补救的团队会发现，“气隙化”并不是一个配置开关。它意味着在最后期限前，由那些发现自己的 Kubernetes 运维手册突然失效的人员，去重构一半的平台。

好消息是：这些原语现在已经存在。自托管模型推理（vLLM、llm-d、KServe）已达到生产级别。开源权重模型（Llama、Mistral、Qwen 以及长尾的微调模型）在大多数企业级任务中已逼近前沿模型的水平。MLBOM 工具链（CycloneDX、AIRS）正在成熟。气隙隔离的 Kubernetes 模式已被充分理解。这套蓝图不再只是理论。现在缺失的是一种严谨性——即将“出站流量”视为一种刻意的架构选择而非默认设置，并愿意为那些被云版本隐藏在托管服务抽象下的运维原语进行规划。现在建立起这种严谨性的团队将拥有未来十年的受监管 AI 技术栈。而那些没能做到的团队将不断通过一个又一个的出站依赖发现，“自托管”从来都只是一个营销术语，而非一种架构。