AI 原生基础设施一页参考架构：三平面 + 一闭环

真正的架构价值，是让复杂系统在 5 分钟内形成组织共识，而不是再造一套新技术栈。

业界主流厂商在表达上各有侧重：Cisco 更强调 AI-native 基础设施与 Cisco Validated Designs 等参考设计与交付体系；HPE 强调面向 AI 全生命周期的 open, full-stack AI-native architecture；NVIDIA 则明确提出为 long-context 与 agentic workloads 的 inference context 复用新增 AI-native infrastructure tier。本章将这些视角收敛为一个可验证的架构骨架：三平面 + 一闭环。

一页架构总览

下方为 AI 原生基础设施三平面与闭环的参考架构详细图，帮助读者快速建立整体认知：

这张图可以理解为：AI 原生基础设施的新控制面（意图）必须被治理平面约束，并在执行平面产生可计量的资源后果。

这一点也是厂商叙事差异背后的共同点：Cisco 用参考设计与交付体系把基础设施能力可规模化复制；HPE 用 open/full-stack 覆盖生命周期交付；NVIDIA 则把“上下文状态资产”的复用上升为独立基础设施层。三者都指向同一个问题：把 AI 的资源后果纳入可治理的系统边界。

三平面核心能力解析

本节将详细解析三平面各自的核心能力，帮助架构评审时明确关注点。

意图平面（Intent Plane）

意图平面负责表达“我想要什么”，包括以下能力：

• 推理/训练 API（入口与契约）
• MCP/工具调用协议与工具目录（把工具访问标准化为“可声明的能力边界”）
• Agent/Workflow（把任务拆解为可执行步骤）
• Policy as Intent：优先级、预算、配额、合规/安全约束（以“意图”的形式前置）

关键点：意图平面不是起点本身；真正的起点是——意图能否被转译为可执行且可治理的计划。否则 Agent/MCP 只会放大不确定性：更多工具、更长链路、更大状态空间、更不可控的资源消耗。

在架构评审时，建议关注以下问题：

• 意图是否可声明（contract）与可拒绝（admission）？
• 意图是否携带预算/优先级/合规约束（policy as intent）？
• 意图到执行的转译是否可追踪（traceable）？

执行平面（Execution Plane）

执行平面负责把意图落地为“真实执行”，主要包括：

• 训练、微调、推理 serving、批处理、agentic runtime
• “状态与上下文”服务：缓存/KV/vector/context memory 等，用于承载推理上下文、检索结果、会话状态
• 全链路观测钩子：token 计量、GPU 时间、显存、网络流量、存储 IO、队列等待等

需要强调一个产业趋势：当 long-context 与 agentic workload 普及，“上下文”本身成为关键状态资产，甚至可能上升为独立基础设施层。NVIDIA 在 Rubin 平台中明确提出 inference context memory storage，建立 AI-native infrastructure tier，为 pod 级提供共享的、低延迟的 inference context 以支持复用（面向 long-context 与 agentic workloads）。

评审要点聚焦三件事：

• 执行是否可度量：是否能在 token/GPU/网络/存储维度做归因？
• 状态是否可治理：上下文与缓存的生命周期、复用边界、隔离策略是什么？
• 观测是否面向闭环：观测不是为了“看见”，而是为了“让治理能纠偏”。

治理平面（Governance Plane）

治理平面是 AI 原生基础设施的“硬核差异化”，负责把资源稀缺与不确定性变成可控系统：

• 预算/配额/计费：按团队、租户、项目、模型、agent 任务维度治理消耗
• 隔离与共享策略：同卡共享、显存隔离、抢占、优先级、公平性
• 拓扑感知调度：把 GPU、互连、网络、存储拓扑纳入 placement（尤其在训练与高吞吐推理中）
• 风险与合规控制：审计、策略执行点、敏感数据与访问控制
• 与 FinOps/SRE/SecOps 的联动：把成本、可靠性与风险纳入同一套运行机制

从厂商叙事看，这一层通常对应“参考架构 + 全栈交付”：
Cisco 强调在 AI 基础设施中通过“fully integrated systems + Cisco Validated Designs”加速与规模化交付；HPE 以“open, full-stack AI-native architecture”强调端到端交付以支撑模型开发与部署。

治理平面评审的底线问题是：你能否在预算/风险约束下做可解释的资源分配与降级决策？

一闭环机制详解

本节介绍闭环机制的核心流程，帮助理解 AI-native 与 AI-ready 的本质区别。

闭环的最小实现包含四步：

1. Admission（准入）：在入口就把意图与政策绑定（预算、优先级、合规）
2. Translation（转译）：把意图转译为可执行计划（选择 runtime、资源规格、拓扑偏好）
3. Metering（计量）：对 token/GPU/网络/存储做端到端计量与归因
4. Enforcement（执行）：预算触发降级/限流/抢占；风险触发隔离/审计；SLO 触发扩缩/路由

换句话说：闭环不是“监控面板”，而是“治理驱动的实时纠偏机制”。
如果缺乏“意图 → 消耗 → 成本/风险结果”的闭环，系统容易在成本、风险、质量等方向失控。

这也是为什么“AI-native”经常伴随 operating model 的变化：当系统的执行速度与资源消耗都被模型/agent 放大，组织必须把治理机制前置并制度化。LF Networking 也明确指出：成为 AI-native 不只是技术迁移，而是 operating model 的重定义。

一页架构的实际用法

在后续章节中，这张“一页架构”可以反复复用为评审模板：

• 讨论 MCP/Agent：把它们定位到意图平面，并用闭环约束（admission/translation）避免“意图泛滥”
• 讨论 runtime 与平台：放到执行平面，重点看可观测、可归因、可治理的状态资产（context/cache/KV/vector）
• 讨论 GPU、调度、成本：落到治理平面，以预算/隔离/拓扑/计量为抓手
• 讨论企业落地：用闭环审视是否“真的 AI-native”（是否能把成本/风险结果回写为可执行策略）

如果你只能记住一句话：
AI-native 的判定不在“用了多少 AI 组件”，而在“是否存在可执行的治理闭环，把意图约束为可控的资源后果与经济/风险结果”。

总结

一页参考架构为 AI 原生基础设施提供了统一的系统语言和评审骨架。通过意图、执行、治理三平面与闭环机制，组织能够在架构设计、资源治理和风险控制等方面实现高效协同。未来，随着 AI-native 能力的不断完善，治理闭环将成为企业落地 AI 的核心竞争力。

参考文献

• NVIDIA AI Enterprise Reference Architecture - nvidia.com
• Google Cloud AI Infrastructure - cloud.google.com
• AWS Well-Architected Framework - aws.amazon.com