十多年来，企业的云战略一直遵循着一个明确的方向：整合。

应用程序从分散的本地环境迁移至集中的公有云平台，其目标在于简化运维、实现可扩展性并提升成本效益。混合架构也有被提及，却鲜少被真正采纳。它们被视为过渡状态——迁移过程中不可或缺，但终将被淘汰。如今这种假设正开始动摇。

AI系统引入的限制条件与集中式基础设施模型并不相容。在许多情况下，问题已不再是工作负载能否迁移到单一环境，而是是否应该迁移。

本文将探讨混合云如何从一种折中方案，转变为一种结构性需求。

AI工作负载的行为模式与传统应用程序不同

传统的企业应用程序大多是确定性的，且由请求驱动。用户发起请求，系统进行处理并返回响应。延迟固然重要，但需在既定容差范围内。数据访问模式可预测，治理在明确的边界内得到执行。

AI系统的行为则截然不同。现代AI工作负载，尤其是涉及检索增强生成、代理工作流和持续推理的场景，会同时在多个维度上运行：

• 它们依赖于分布在不同环境中的上下文数据。

• 它们执行多步骤推理管道，而非单次事务。

• 它们持续运行，而非仅按请求处理。

• 它们引入反馈循环，其中输出结果会影响未来的行为。

这些特性从根本上改变了执行的位置和方式。

延迟成为正确性约束

在传统系统中，延迟主要是一个性能问题。而在 AI 系统中，延迟正日益成为一种正确性约束，它直接影响系统输出的有效性，而不仅仅是及时性。

试想一个在生成响应前需检索上下文数据的系统。若检索步骤引入延迟，系统可能基于过时或不完整的上下文进行操作。在实时环境、金融系统、运营决策平台或客户交互层中，这种延迟不仅会改变用户体验，更会改变结果。延迟不再仅仅关乎速度，它已成为决策边界的一部分。

这标志着系统设计中对延迟理解方式的转变：不再将其视为优化变量，而是视为塑造决策本身语义准确性的关键因素。

这催生了新的架构要求。执行必须发生在延迟约束能保障语义正确性(而非仅保障用户体验)的位置。在实践中，这通常意味着将组件分布于不同环境：

• 在用户附近或边缘位置进行推理。

• 在受监管的数据源附近进行数据检索。

• 在集中式控制层之间进行编排。

没有任何一种环境能够同时满足所有延迟约束。这给架构设计带来了结构性影响：执行位置的确定必须基于在延迟约束下如何保证正确性，而非计算资源最易获取的位置。从这个意义上说，分布式架构并非一种优化方案，而是一种必要条件。

延迟作为分布式AI系统中的正确性约束

下图展示了延迟不仅影响系统性能，还影响AI驱动决策的正确性。在集中式架构中，数据检索和推理延迟会导致上下文过时或不完整，从而导致结果质量下降。而在分布式架构中，将数据检索、推理和交互层部署在边缘、云和企业环境中，既能降低延迟，又能保持语义正确性。

治理模式不再集中化

企业治理模式历来认为，集中化能提升管控能力。将数据汇集到一个环境中，应用统一的政策。一致地执行访问控制。AI 颠覆了这一模式。

AI 系统经常与以下内容交互：

• 受监管的数据。

• 企业的专有知识。

• 外部数据源和 API。

这些交互是动态发生的，且往往跨越多个司法管辖区和合规领域，将所有数据移入单一环境并非总是可行或被允许的。相反，治理必然变得分布式。政策必须在数据所在之处、决策制定之处以及行动执行之处得到执行。

这催生了不同的架构模型：

• 治理不再受限于地理位置。

• 治理必须跨地域实施。

混合架构的出现并非源于碎片化，而是源于政策约束——若不违反监管或运营边界，这些约束便无法集中管理。

成本引力改变了部署决策

传统工作负载的云经济模型相对可预测。成本随使用量、计算资源、存储和网络流量而变化，并可通过整合进行优化。

AI 工作负载带来了不同的成本动态：

• 推理成本随上下文长度和模型复杂度而增加。

• 数据迁移成为主要的成本驱动因素。

• 持续评估引入了持续的开销。

• 训练和微调会产生突发性、高强度的计算需求。

这些因素共同形成了所谓的“成本引力”，即工作负载倾向于留在数据和计算资源最具经济效益的区域附近。例如：

• 为进行推理而在不同环境间迁移大型数据集所产生的成本，可能超过计算成本的节省。

• 集中式推理可能同时增加延迟和出站流量成本。

• 在高成本区域，持续评估管道会因成本过高而难以实施。

其结果并非一个简单的优化问题，而是一系列相互竞争的力量，将系统的不同部分拉向不同的环境。

混合云不是一种策略，而是一种结果

企业讨论通常将混合云视为一种战略选择：我们是否应该采用混合云?本地部署与公有云的比例应如何分配?

AI 改变了这一问题的本质。混合云并非组织在抽象层面主动选择的结果，而是相互冲突的约束条件、延迟要求、治理边界和成本动态在单一环境中无法解决时产生的自然结果。这些力量之间并不协调，它们将系统的不同部分向不同方向拉扯，从而迫使系统进行分布式部署。许多情况下，看似架构复杂的情况，实则是系统在解决那些无法在单一环境中满足的相互冲突的约束条件。

这将混合云的定位从一种实施选择，重新定义为一种受约束驱动的结果，它源于延迟、治理和成本这三股力量的相互作用，这些力量同时作用于系统的不同部分。

现代AI工作流横跨边缘、云和企业环境，延迟、治理和成本限制因素共同决定了部署位置。AI系统不再形成线性管道，而是将执行任务分布于不同环境，以满足相互冲突的限制条件。混合架构已不再是设计偏好，而是成为一种结构性要求。

从位置中心思维到约束中心架构

过去，基础设施决策主要围绕位置展开：应用程序应在何处运行?应选用哪家云服务提供商?

AI系统需要不同的框架。更关键的问题变成了：该系统必须满足哪些约束条件，以及这些约束条件在何处能够得到满足?

这导致了以约束为中心的架构方法。执行被部署在延迟能保障正确性(而不仅仅是性能)的地方。数据保留在治理要求的位置，而不是为了方便而集中存储。计算资源部署在成本效益最优的地方，而不是在容量最易配置的地方。

这种从位置中心化向约束中心化设计的转变，改变了架构决策的单位。系统不再基于基础设施偏好进行部署，而是根据各项约束条件能否得到满足，进行分解和分布式部署。

其结果并非碎片化，而是协同一致。系统之所以分布式部署，并非因为设计拙劣，而是因为它们针对所处的约束环境进行了正确的设计。随着系统分布式部署，协调成为核心挑战。此时控制平面变得至关重要——它不再是可选的治理层，而是使分布式系统能够协同运作的统一机制。控制平面提供了一种在不同环境中执行策略、一致监控行为、管理生命周期过渡以及维持分布式执行可见性的方式。它们并未消除混合环境的复杂性，而是使其可操作。

为何这会改变企业架构决策

许多首席信息官(CIO)仍将混合云视为一种临时状态，认为这是随着时间推移需要简化或消除的事物。AI挑战了这一假设，混合云并非整合失败的结果，而是系统在受限条件下运行的产物——若要实现集中化，必然会引入权衡取舍。

那些继续将混合云视为过渡状态的组织，往往会导致工作负载过度集中，引入延迟瓶颈，增加数据迁移成本，并削弱治理执行力。问题不在于执行层面，而在于“整合始终是终极目标”这一先入为主的假设。

将混合云视为结构性结果，将改变系统设计的方式。架构必须将分布式作为基准状态，将数据本地性视为约束而非偏好，将延迟纳入正确性范畴，并将治理作为分布式能力加以落实。这要求设计出默认跨环境运行的系统——而非仅在例外情况下才如此。

在此背景下，混合云并非转型不完整的产物，而是AI系统在现实世界约束下运行的自然状态。这种从“混合作为过渡状态”到“混合作为结构性结果”的转变，不仅影响系统运行的位置，更影响其设计方式。成功的组织并非那些消除混合复杂性的企业，而是那些针对混合特性进行设计的企业。

作者Varun Raj是一位拥有近二十年大规模云计算和AI平台设计经验的云与AI工程高管。