📚 喵喵的笔记库

AI 原生基础设施：为不确定性而设计的系统

11分钟阅读

AI 原生基础设施：为不确定性而设计的系统

核心论点：AI 原生基础设施的本质，是让模型行为、算力稀缺与不确定性成为可治理的系统边界。不是更快的推理或更便宜的 GPU，而是为不确定性提供可治理、可度量、可进化的系统边界。

一、核心定义

一句话定义：以"模型/智能体作为执行主体、算力作为稀缺资产、不确定性作为常态"为前提，通过算力治理把"意图 → 执行 → 资源消耗 → 经济与风险结果"闭环起来的基础设施体系。

与云原生的关系：不是替代，而是"上位范式 + 下沉改造"——Cloud Native 是底座，AI Native 是其上的语义重写。

| 层级 | 名称 | 职责 | |------|------|------| | Layer 0 | Cloud-Native Substrate（保留） | K8s、容器、CNI/CSI、可观测基础 | | Layer 1 | Resource Model Rewrite（核心断点） | GPU/token/context 成为一等资源 | | Layer 2 | Runtime & Control Plane Shift | Agent 循环、异步多步工作流 | | Layer 3 | Governance & Scheduling First | 调度成为首要控制平面 |

二、三个根本前提

| 前提 | 含义 | 治理含义 | |------|------|----------| | Model-as-Actor | 模型/Agent 成为"执行主体"，有行动能力、产生副作用 | 需要审计、回滚、责任界定 | | Compute-as-Scarcity | GPU/互连/功耗/带宽是核心稀缺资产，扩不动且贵 | 算力治理成为第一性约束 | | Uncertainty-by-Default | 行为与资源消耗高度不确定，尤其 agentic/long-context | 需要预算、上限化、可回退 |

三、架构骨架：三平面 + 一闭环

三平面

┌─────────────────────────────────────────────────┐
│              意图平面 (Intent Plane)              │
│  API / MCP / Agent Workflow / Policy as Intent  │
├─────────────────────────────────────────────────┤
│              执行平面 (Execution Plane)           │
│  训练 / 推理 / Serving / 状态服务 / 全链路观测    │
├─────────────────────────────────────────────────┤
│              治理平面 (Governance Plane)          │
│  预算配额 / 隔离共享 / 拓扑调度 / 风险合规 / FinOps│
└─────────────────────────────────────────────────┘
         ↕ 闭环反馈 (The Loop) ↕
    Admission → Translation → Metering → Enforcement
  • 意图平面：表达"我想要什么"——关键是意图能否被转译为可治理的执行计划
  • 执行平面：落地为真实执行——关键是可度量、可归因、可治理
  • 治理平面：硬核差异化——预算/隔离/拓扑/风险/FinOps 联动

一闭环（四步循环）

| 步骤 | 职责 | 要点 | |------|------|------| | Admission | 入口准入 | 绑定预算/优先级/合规，拒绝理由可解释 | | Translation | 意图→执行计划 | 选择 runtime、路由策略、上限化（最大步数/token/工具调用） | | Metering | 端到端计量归因 | tokens/GPU time/KV footprint/网络/存储 → 租户/项目/模型归因 | | Enforcement | 策略执行 | 预算触发降级/限流/抢占，风险触发隔离/审计 |

闭环不是"监控面板"，而是"治理驱动的实时纠偏机制"。

四、算力治理：从后果出发设计

核心观点：AI 原生基础设施必须从"后果（Consequence）"出发设计，而非从"意图（Intent）"出发堆叠能力。

五层架构与组织责任

| 层 | 能力 | 建议 Owner | 失败代价 | |----|------|-----------|----------| | L5 业务接口 | SLA、产品体验 | Product/Business | 收入受损 | | L4 意图/编排 | MCP/Agent、workflow | App/Platform/AI Eng | 行为失控 | | L3 执行 Runtime | serving、batching、路由 | AI Platform/Infra | 吞吐不足 | | L2 上下文/状态 | KV/cache/context tier | Infra + AI Platform | token 成本飙升 | | L1 算力/治理 | 配额、隔离、拓扑、计量 | Infra/FinOps/SRE | 预算爆炸 |

MCP 属于 Layer 4（意图层），不是 Layer 1。MCP 解决能力暴露，不解决资源后果的计量与约束。

关键洞察

  • 上下文正在上升为新的基础设施层：KV cache 与推理状态复用从"性能优化技巧"变为"平台产能结构"
  • 治理对象是四类组合：Token 经济、加速器时间、互连与存储、组织预算与风险

五、不确定性治理

四类不确定性

| 类型 | 表现 | 影响 | |------|------|------| | 行为不确定性 | Agent 路径爆炸、工具选择动态变化 | 成本、风险 | | 需求不确定性 | 并发 burst、长尾请求、多租户干扰 | 资源池、隔离 | | 状态不确定性 | 上下文跨请求复用、KV cache 迁移 | 性能、成本 | | 基础设施不确定性 | 网络/存储/互连敏感，拥塞放大为尾延迟 | 体验、稳定性 |

跨层放大链路

Agent 分支爆炸 → 上下文膨胀 → 资源竞争失真 → 尾部成本失控

工程响应的三个核心问题：

  1. 上限在哪里——预算、步数、调用次数、状态占用
  2. 越界怎么办——降级、回退、隔离、阻断
  3. 结果如何回写——策略迭代与成本纠偏

六、组织与运营模型

API-first 的三个失效假设

| 假设 | 传统成立 | AI 时代失效原因 | |------|----------|-----------------| | 资源不稀缺 | ✅ CPU/内存可弹性 | ❌ GPU/互连扩不动且贵 | | 请求成本可预测 | ✅ 相对稳定 | ❌ agent 任务成本呈长尾/爆发 | | 状态短命可丢弃 | ✅ 无状态扩展 | ❌ 推理状态决定单位成本 |

反模式清单

  • ❌ API-first，治理当后续 → runaway cost，产品路线被限流锁死
  • ❌ MCP/Agent 只当能力加速器 → token 与调用成本指数上升
  • ❌ 只买 GPU 不做共享/隔离 → 利用率低 + 争用失控
  • ❌ 忽视网络拓扑 → JCT/tail latency 被放大，容量规划失效
  • ❌ 上下文不资产化 → 长上下文时代单位成本失控

最小可行治理堆栈

  1. 准入与预算——工作负载分级、policy-as-intent
  2. 计量与归因——request → tokens → GPU → 网络 → 成本的可追溯链路
  3. 隔离与共享——同时存在，而非二选一；变成可执行策略
  4. 拓扑优先——网络特性是 JCT/tail latency 的决定变量
  5. 上下文资产化——KV cache / inference context 的复用决定单位成本

七、迁移路线图

北极星定义

AI-Native Migration = AI Landing Zone + Compute Governance Loop + Context Tier

三块前置地基

| 地基 | 关键行动 | 不做的后果 | |------|----------|-----------| | FinOps/配额控制面 | 预算/告警/showback/配额纳入控制面 | 成本外溢 | | GPU 治理 | 共享/切分/调度升级/编排闭环 | 利用率低 + 争用 | | 网络基线 | AI-ready fabric、lossless 策略、验收口径 | 尾延迟放大 |

三条迁移路径

| 路径 | 适用场景 | 核心做法 | 退出标准 | |------|----------|----------|----------| | 旁路试点 | AI 刚起步，治理未成型 | 最小闭环沙箱 | 成本可归因、能力可下沉 | | 分域隔离平台化 | 多团队多租户 | AI Landing Zone | 可复制的落地方式，预算约束下扩展 | | AI-First 重构 | AI 是核心业务 | 状态资产 + 单位成本驱动 | 用单位成本做工程决策 |

90 天可执行计划

| 阶段 | 目标 | 关键交付 | |------|------|----------| | Day 0-30 | 账本立起来 | 成本看板 + 准入策略 v0 | | Day 31-60 | 资源治理立起来 | GPU 共享隔离 + AI-ready 网络 + 推理/训练模板 | | Day 61-90 | 闭环立起来 | 预算策略执行 + 组织合同 + AI 平台运行手册 v1 |

组织合同

  • 平台团队提供：Landing zone、网络基线、身份策略、预算体系、计量归因、GPU 治理、运行时黄金路径
  • 工作负载团队负责：模型选择、prompt/agent 逻辑、工具接入、SLO 定义、业务价值度量

八、速查表

核心术语速查

| 术语 | 英文 | 一句话 | |------|------|--------| | 算力治理 | Compute Governance | 治理意图的资源后果 | | 意图平面 | Intent Plane | API/Agent/策略表达 | | 执行平面 | Execution Plane | 训练/推理/serving/runtime | | 治理平面 | Governance Plane | 配额/预算/隔离/风险控制 | | 闭环 | The Loop | Admission→Translation→Metering→Enforcement | | MCP | Model Context Protocol | 工具访问标准化的协议 | | FinOps | Financial Operations | 成本治理嵌入架构决策 | | Landing Zone | AI Landing Zone | 承载治理基线的受控环境 |

CEO/CTO 准备度 10 问速查

  1. 能否定义每个 AI 工作负载的单位成本？
  2. 是否有预算/配额机制限制消耗？
  3. 能否在性能-成本-风险间做显式政策选择？
  4. 平台能否处理不确定性（峰值、长尾、路径爆炸）？
  5. Agent/MCP 意图是否映射到可审计的资源后果？
  6. 是否有隔离与共享策略？
  7. 能否做端到端可观测（request→runtime→GPU→成本）？
  8. 基础设施是否支持异构硬件演进？
  9. 是否建立 AI SRE + FinOps 协作机制？
  10. 能否一页纸给出三平面 + 一闭环架构图？

来源：Jimmy Song - AI 原生基础设施 | GitHub: jimmysong/ai-native-infra

关键参考：Cisco AI-Native Infrastructure · HPE AI-native Architecture · NVIDIA Rubin ICMS · FinOps Foundation · NIST AI RMF · Google SRE Workbook

关系图谱