迁移路线图：从云原生到 AI 原生

迁移不是“重建平台”，而是用治理闭环和组织合同，把不确定性转化为可控的工程能力。

前五章已经明确：AI 原生基础设施是 Uncertainty-by-Default（不确定性为常态）。因此，架构起点必须是 算力治理闭环，而非“接入模型即完成迁移”。否则，系统极易在成本（runaway cost）、风险（越权/副作用）、尾部性能（P95/P99 与队列尾巴）三个维度失控。

这也解释了 FinOps Foundation 强调：在 Kubernetes 上跑 AI/ML，“弹性”极易演化为不可控的成本外溢。FinOps 必须作为共享 operating model 前置进入架构与组织，而非事后对账。

本文将给出一份可执行的迁移路线图，涵盖技术演进路径与组织落地方式。你无需一次性“重建 AI 平台”，但必须在每个阶段跑通治理闭环：预算/准入、计量/归因、共享/隔离、拓扑/网络、上下文资产化。

迁移的北极星：从交付平台到治理闭环

下图展示从旁路试点到 AI-first 重构的迁移路径。

云原生迁移通常以“交付能力”为中心：CI/CD、自助平台、服务治理、弹性伸缩。其默认假设是系统确定、成本随请求线性增长、扩缩容不会显著改变系统边界。

AI 原生迁移则必须以“治理闭环”为中心，聚焦成本、风险、尾部性能、状态资产。其默认假设恰好相反：系统天然不确定，推理/Agent 的“动作与后果”会将成本与风险带入非线性区域。

这里将“Landing Zone”提升到北极星层级，不是追热点，而是因为它天然承担一项组织级任务：划清平台团队与工作负载团队的责任边界。主流云厂普遍用 Landing Zone 承载“共享治理基线”（网络、身份、策略、审计、配额/预算），业务团队则在受控边界内自助迭代应用。对 AI 而言，这种边界是治理闭环的承载体。

迁移前置条件：先补三块地基，再谈应用爆发

你可以并行做 PoC、做应用，但如果这三块地基缺失，任何“应用爆发”都可能转化为平台救火与财务争议。

地基 A：FinOps / Quotas as Control Plane（财务与配额是控制面）

迁移第一步不是“上线第一个 Agent”，而是将预算、告警、showback/chargeback、配额纳入基础设施控制面：

• 预算与告警不仅是财务报表，更是运行时策略的触发器（限流、降级、排队、抢占）。
• showback/chargeback 不只是算账，更是将“成本后果”绑定到组织决策与产品边界。
• 配额不是静态限制，而是可演进的治理手段（按租户/团队/用例的动态预算与优先级）。

地基 B：Resource Governance（GPU 共享/隔离与编排能力）

AI 原生基础设施的“弹性”受制于稀缺算力的治理方式。将 GPU 当普通资源，结果往往是利用率低与争用失控。因此需具备可落地的共享/隔离与编排能力组合：

• 共享/切分：MIG/MPS/vGPU 等路线，让“独占”变为“池化”。
• 调度升级：引入拓扑、队列、公平性、抢占、成本等级的显式建模。
• 编排闭环：将隔离、抢占、优先级策略固化为可执行规则。

关键不在于选哪种切分技术，而在于能否将 GPU 从“机器资产”提升为一等治理资源，并纳入预算与准入体系。

地基 C：Fabric as a First-Class Constraint（网络/互连是一级约束）

训练与高吞吐推理对拥塞、丢包、尾延迟极度敏感。忽视网络与拓扑，易导致“看似偶发、实则结构性”的问题：

• 训练 JCT 被尾部放大，容量规划失效；
• 推理 P99 与排队尾巴被放大，SLO 难以兑现。

因此需构建可复用的 AI-ready 网络基线：容量假设、lossless 策略、隔离域划分、测量与验收口径。网络不是“后面再优化”，而是 Day 31–60 必须落地的基线工程。

迁移路径选择：按组织风险与技术债务分层

迁移不是“选一条路走到黑”，而是将不同风险偏好与债务结构的组织，映射到不同起步方式与退出标准。可并行推进，但需为每条路径定义适用条件与退出标准。

路径一：旁路试点（Bypass Pilot / Skunkworks）

适用于云原生平台稳定运行，但 AI 需求刚起、组织不确定性高、治理机制尚未成型的场景。

做法是在现有平台旁建立“AI 最小闭环沙箱”，目标不是“功能齐全”，而是“闭环跑通”：

• 独立 GPU 池（或至少独立队列）+ 基本准入与预算
• 最小 token/GPU metering 与归因
• 受控推理/agent 入口（max context / max steps / max tool calls）
• “失败可接受”的 SLO 与成本上限（先定义边界，再谈体验）

退出标准：

• 成本曲线可解释（至少能归因到团队/用例）
• GPU 利用率与隔离策略形成可复用模板
• 试点能力可下沉为平台能力（进入路径二）

路径二：分域隔离的平台化（Domain-Isolated Platform）

适用于 AI 已进入多团队、多租户阶段，需要将“试点资产”沉淀为平台能力，防止成本与风险跨域扩散。

做法是建设 AI Landing Zone，由平台团队集中管理共享治理能力，工作负载团队在受控边界内自助迭代应用。

平台侧必备模块（建议按“治理闭环”组织）：

• Identity/Policy：统一身份、策略下发与审计（policy-as-intent）
• Network/Fabric baseline：AI-ready 网络基线与自动化验收
• Compute governance：配额、预算、抢占、公平性、隔离/共享
• Observability & Chargeback：端到端计量、告警、showback/chargeback
• Runtime catalog：推理/训练 runtime 的“黄金路径”与模板化交付

退出标准：平台提供“可复制的 AI 工作负载落地方式”，并能在预算约束下扩展用例数量，而非靠人工救火维持稳定。

路径三：AI-First 重构（AI Factory / Replatform）

适用于 AI 已是核心业务，需要将基础设施当作“生产线”而非“集群”，并将优化目标从“上线功能”切换为“吞吐/单位成本/能效”。

做法围绕“状态资产 + 单位成本”重构：

• 推理/agent 的 context/state 被显式治理与复用（不再是应用内技巧）
• 引入 Context Tier 架构假设：长上下文与 agentic 推理要求 inference state / KV cache 能跨节点、跨会话复用
• 用“单位 token 成本、尾部延迟、吞吐/能效”驱动平台演进，而非“新增组件数量”

退出标准：能持续用“单位成本与尾部性能”做工程决策，并将上下文复用当作平台能力，而非应用团队的技巧性缓存。

90 天可执行计划：AI Landing Zone + 最小治理闭环

目标是在 90 天内跑通“AI Landing Zone + 最小治理闭环”，形成可复制模板。关键不是覆盖所有场景，而是打通准入—计量—执行—反馈闭环。

Day 0–30：账本立起来（Cost & Usage Ledger）

首先需定义归因维度，建立 budgets/alerts 与基线报表，并落地 quotas / usage controls。

• 归因维度：tenant/team/project/model/use-case/tool
• 建立预算与告警、基线报表（成本 + 业务价值指标）
• 落地配额与用量控制（至少覆盖 GPU 配额与关键服务配额）

交付物：

• 成本与用量看板（周报级、可追溯）
• “准入策略 v0”（max context / max steps / max budget）

Day 31–60：资源治理立起来（GPU Governance + Scheduling）

此阶段需评估 GPU 共享/隔离策略，引入拓扑/网络约束，形成推理与训练两类黄金路径。

• GPU 共享/隔离策略：MIG/MPS/vGPU/DRA 路线评估与 PoC（以可执行策略为验收）
• 引入拓扑/网络约束，形成 AI-ready 网络基线与容量假设（含验收口径）
• 形成推理/训练两类模板化交付路径

交付物：

• 工作负载模板（推理与训练各 1 个）
• 调度与隔离策略（白名单化、可审计）

Day 61–90：闭环立起来（Enforcement + Feedback）

最后阶段需执行预算策略，将试点用例迁移到 landing zone，并固化组织接口。

• 执行预算：限流/排队/抢占/降级策略，并与 SLO 联动
• 迁移试点用例到 landing zone（或将 landing zone 能力服务化）
• 固化“组织接口”：平台团队 vs 工作负载团队责任边界（形成可执行合同）

交付物：

• “AI 平台运行手册 v1”（含 oncall、变更、成本审计）
• 两条可复制的用例落地路径（新增用例 ≤ 30 分钟上线黄金路径）

Operating Model：平台团队与工作负载团队的“合同”

迁移能否成功，取决于是否建立了清晰、可执行的“组织合同”。合同本质是：谁为“能力供给”负责，谁为“行为后果”负责。

平台团队提供（必须稳定）

Landing zone、网络基线、身份与策略、预算/配额体系、计量归因、GPU 治理能力、运行时黄金路径

工作负载团队负责（必须自助）

模型选择、prompt/agent 逻辑、工具接入、SLO 定义、业务价值度量、用例风险分级与回退路径

这也是 FinOps Framework 强调 operating model（personas、capabilities、maturity）而不仅是工具的原因：没有“合同”，预算难以执行；预算无法执行，闭环难以成立。

迁移反模式

以下为常见迁移反模式及其后果：

总结

AI 原生迁移的核心，不是“迁移清单”，而是在不确定性前提下，将成本、风险、尾部性能纳入同一治理闭环，并用 Landing Zone 承载组织合同，用 Context Tier 实现状态复用的基础设施能力。只有这样，才能让平台与业务在规模化演进中保持可控与高效。

参考文献

• McKinsey on AI Strategy - mckinsey.com
• Thoughtworks Technology Radar - thoughtworks.com
• Google Cloud Adoption Framework - cloud.google.com