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

云端 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 技术栈。而那些没能做到的团队将不断通过一个又一个的出站依赖发现，“自托管”从来都只是一个营销术语，而非一种架构。