AI Infra的演进与挑战:从OpenAI生产事故到未来展望

今天整理之前的文稿，发现了这篇去年的关于 AI Infra 的文章，当时忘记发出来了，现在看也不过时，分享出来大家一起看下。

OpenAI生产事故回顾

2024 年 11 月，ChatGPT 突发故障，导致服务中断近半小时，超过 19,000 人受到影响。

没想到仅仅一个月时间后，2024.12.19又发生了全球性服务中断事件。

这次中断与OpenAI使用的Kubernetes (k8s)集群有关。

作为一个拥有约7000个节点的超大规模集群,它在面对突发流量时出现了不稳定。

这暴露出了在构建和管理如此庞大的AI基础设施时所面临的挑战。

OpenAI 在事后报告中写道：

OpenAI 提到，在客户感受到影响的“几分钟”内，公司就检测到了该问题；

但由于必须绕过不堪重负的 Kubernetes 服务器，因此无法快速实施修复。

于是，一个惨痛的生产事故，就这么出现了。

再说一个SRE技术岗位工程师都知道的基本事实。

一个k8s集群的总节点数最大上限建议为5000个

为什么是这个数字？

k8s控制面底层依赖etcd存储元数据，etcd本身底层基于Raft算法来保证分布式数据的一致性。

Kubernetes官方文档指出，单个集群支持的最大节点数为5000，

这是谷歌基于对大规模集群性能的测试和经验得出的。没错，K8S是谷歌开源的，5000这个数字也不是随便给出的。

如果大于5000节点(中小厂会限制在100个左右)，一般会使用多集群方案，而k8s多集群之间的通讯，存储，计算一致性又是一个难题。买了一堆性能强劲的GPU，肯定是把它们算力压榨到极致，这也是AI大厂不想拆分多个k8s集群的原因之一。

当然，也可以突破限制让k8s支撑5000节点以上，这就需要更多的精力花在集群稳定性，监控，数据流传递等方面，这也是OpenAI这次事故发生的必然性。后续一定还有会更多类似的事故发生。

AI Infra包括之前的Cloud Infra在大多数时候都是默默无闻，就像一个低头拉磨的老黄牛，一般不太会有存在感，

但凡出了事就是大事儿，比如前几年的某宝的网络电缆被挖断，某云的OSS权限认证失败导致存储访问被拒绝等等。这些基础设施是基石，它十分考验搭积木的技巧，一块摆的不对，整个大厦瞬间宕机。

在OpenAI事故中,Kubernetes(k8s)作为核心基础设施组件备受关注。

那么,k8s在AI基础设施中究竟扮演着什么角色?它的关键组件有哪些?

Kubernetes是一个开源的容器编排平台,它为大规模分布式系统提供了强大的管理和调度能力。

在AI领域,k8s的作用更加凸显。

它不仅可以管理运行AI模型的容器,还能协调GPU等硬件资源的分配,实现负载均衡和自动扩缩容。

k8s的架构主要分为控制平面(Control Plane)和数据平面(Data Plane)。

控制平面负责整个集群的管理和决策,包括API Server、Scheduler、Controller Manager等组件。

数据平面则由众多Worker节点组成,负责实际运行工作负载。

在控制平面中,API Server是整个系统的入口,负责接收和处理各种请求。

Scheduler负责将新创建的Pod分配到合适的节点上。

Controller Manager则包含多个控制器,负责维护集群的期望状态。

数据平面的核心是kubelet,它运行在每个Worker节点上,负责管理该节点上的容器。

kube-proxy则负责维护网络规则,实现服务的负载均衡。

在AI工作负载中,k8s还需要与GPU管理插件(如NVIDIA的GPU Operator)协同工作,以实现GPU资源的高效调度和利用。

就像OpenAI的事故,当集群规模达到数千个节点时,k8s的管理难度也大大增加。

控制平面的性能、网络通信的效率、存储系统的吞吐量等都将面临巨大挑战。

所以在构建超大规模AI集群时,需要AI Infra 专家对k8s进行深度优化和定制。

构建一个拥有7000个节点的超大规模AI集群,这绝非易事。

它需要在硬件、软件、网络、存储等多个层面做好充分准备,并具备应对各种挑战的能力。

硬件方面需要搭建大量高性能的GPU服务器

考虑到AI模型的计算密集特性,每个节点可能配备多块NVIDIA A100或H100 GPU。同时,高速网络互联(如InfiniBand或100GbE+)也是必不可少的,以支持节点间的高效通信。

专门的GPU管理和调度系统

例如,NVIDIA的NCCL(NVIDIA Collective Communications Library)可以大幅提升多GPU、多节点训练的效率。同时,分布式训练框架(如Horovod)的选择和优化也至关重要。

网络架构

在如此大规模的集群中,网络拓扑的选择(如Spine-Leaf架构)直接影响着整体性能。此外,智能的流量管理和负载均衡策略也不可或缺。

存储系统

面对海量的训练数据和模型参数,传统存储方案可能力不从心。这就需要引入高性能分布式存储系统,如Ceph或Lustre,并针对AI工作负载进行优化。国内用的比较多的云原生存储方案是JuiceFS，基本上类似的解决方案勉强可以满足这一段AI形态的业务需要。

AI Infra的运营运维

管理和运维如此庞大的集群也是一项艰巨任务。自动化运维、故障检测与恢复、资源利用优化等都需要先进的工具和经验丰富的团队支持。

能源消耗和散热

大规模GPU集群的功耗巨大,需要先进的电力供应和冷却系统。

一些公司甚至选择将数据中心建在寒冷地区或水源丰富的地方,以降低冷却成本。

比如Azure尝试把数据中心建在海底。

所以呢，买到多少H200,300..不是关键，

关键的是有多少AI Infra专家可以很好的保证基础设施可以支撑算力可以线性扩展，

在Scaling-law失效之前，AI Infra这块的能力就是大模型这个木桶上的一块短板。

说到超大规模AI基础设施,我们不得不提到Elon Musk的雄心勃勃计划——Grok的超级AI中心。

这个项目旨在打造一个前所未有的AI计算设施,其规模和复杂度可能远超OpenAI的集群。

Grok的超级AI中心在AI基础设施方面会面临哪些新的挑战呢?

规模带来的挑战将更加严峻

如果说OpenAI的7000节点集群已经令人望而生畏,那么Grok的超级AI中心可能会将这个数字推向新的高度。这意味着我们需要重新思考集群管理的方式。传统的中心化管理模式可能难以应对,可能需要引入更加分布式和自治的管理架构。

异构计算将成为一大挑战

Grok可能会采用多种类型的计算单元,包括传统GPU、专用AI芯片、甚至量子计算单元。如何在一个统一的平台上管理和调度这些异构资源,将是一个巨大的技术难题。

网络互联也将面临新的挑战

随着规模的增长,传统的网络架构可能难以满足需求。我们可能需要探索新的网络拓扑和协议,甚至考虑光学互联或其他新兴技术,以实现更高的带宽和更低的延迟。

数据管理和存储同样是一个重要问题

面对可能达到EB级的数据规模,如何实现高效的数据存取、移动和处理?分布式存储系统需要进一步优化,可能还需要引入新的数据管理范式,如近数据计算(Near-Data Processing)。

能源效率将是另一个关键挑战

如此庞大的计算设施必然会消耗大量能源。如何提高能源利用效率,降低碳排放,将是Grok项目必须面对的问题。这可能涉及到新的冷却技术、可再生能源的使用,甚至是计算任务的智能调度以优化能耗。

AI系统的安全性和隐私保护

作为一个超大规模的AI系统,Grok将处理海量的敏感数据。如何在保证性能的同时,实现强大的安全防护和隐私保障,这是一个复杂而关键的问题。

在探讨AI基础设施的未来之前,回顾一下计算机领域的几个重要发展规律,以及它们对AI基础设施的影响。

首先是大家熟知的摩尔定律。

尽管近年来有人质疑其是否仍然适用,但不可否认的是,计算能力的持续提升为AI的发展提供了坚实基础。

从早期的CPU到现在的GPU和专用AI芯片,硬件性能的飞跃直接推动了AI模型的规模和复杂度的增长。

云原生容器技术诞生于摩尔定律之后，Scaling-law定律之前，

通过容器化技术,我们可以更加高效地管理和调度计算资源。

而云原生的思想则使得AI系统能够更好地利用云计算的优势,实现弹性伸缩和故障恢复。

随着AI模型规模的不断增长和应用场景的日益复杂,现有的解决方案也面临着诸多挑战。

如何更好地利用GPU资源?

如何优化大规模分布式训练的效率?

如何处理日益增长的数据规模?

最关键的，如何保证AI Infra可以随着Scaling-law定律的曲线从基础设施层面保证AI算力的线性扩展？

我们大胆设想一下理想的AI基础设施方案。

首先,打破当前GPU、CUDA和Kubernetes GPU调度的限制。

虽然NVIDIA的GPU和CUDA生态系统极大地推动了AI的发展,但也在某种程度上限制了创新。

我们需要探索更开放、更灵活的GPU计算方案。例如,开放的GPU指令集架构可能会带来更多的创新机会。同时,我们也需要改进GPU的调度机制,使其能更好地适应AI工作负载的特点。

其次,为大模型提供更适合的网络方案。

当前的网络架构在面对大规模分布式训练时,往往会成为性能瓶颈。未来的AI网络可能需要更高的带宽、更低的延迟,甚至可能需要专门为AI工作负载优化的网络协议和拓扑结构。

在存储方面,更高效的解决方案来支持大模型的预训练和推理。

eRDMA(Enhanced Remote Direct Memory Access)技术在这方面显示出了巨大潜力。

它可以大幅降低数据移动的开销,提高内存访问效率。结合Kubernetes的CSI(Container Storage Interface)机制,我们可以实现更灵活、更高效的存储管理。

此外,考虑如何更好地支持异构计算。

随着专用AI芯片、FPGA等新型计算单元的出现,未来的AI基础设施需要能够无缝集成和管理这些异构资源。

这可能需要新的资源抽象和调度算法。

安全性和可解释性

随着AI系统变得越来越复杂和强大,如何确保其行为可控、结果可解释,将成为一个关键问题。这可能需要在基础设施层面引入新的机制和工具，超越目前k8s Metrics纯资源视角的监控标准

K8s是AI Infra目前一个绕不开的问题:

是否可以突破Kubernetes的局限性?

毕竟,Kubernetes最初并非为AI工作负载设计。

然而,短期内完全抛弃Kubernetes似乎并不现实。

预计至少在未来5年内,Kubernetes很可能仍将是AI基础设施的核心组件。

这是因为Kubernetes已经在云原生生态系统中占据了主导地位,拥有庞大的用户群和丰富的工具链。

完全重新设计一个新的系统不仅成本高昂,而且风险巨大。

相反,我们可能会看到Kubernetes的持续演进和优化,以更好地适应AI工作负载的需求。

例如,我们可能会看到针对大规模GPU集群的专门调度器,更高效的网络插件,以及为AI工作负载优化的存储解决方案。同时,Kubernetes的插件机制也为引入新功能提供了灵活性。

尽管如此,我们仍然需要保持开放的心态,积极探索新的架构和范式。

随着AI模型和应用的不断发展,我们可能会遇到Kubernetes难以解决的问题。

在这种情况下,我们需要勇于创新,甚至重新思考分布式系统的设计原则。

可以预见,未来几年内,类似OpenAI事故的情况可能会越来越多。

这并不意味着Kubernetes或其他现有技术是失败的,而是表明我们正在不断挑战技术的极限。每一次事故都是一次学习的机会,推动我们改进和优化AI基础设施。

事实上,AI基础设施的优化过程在某种程度上类似于云计算的发展历程。

早期的云计算同样面临着诸多挑战,如可靠性、性能、安全性等。

但通过持续的创新和改进,云计算最终成为了一个成熟而强大的技术生态系统。AI基础设施很可能会经历类似的发展轨迹。

在AI基础设施快速发展的背景下,顶尖的AI基础设施专家正扮演着越来越重要的角色。

目前,这些专家主要集中在AWS、Google、阿里云等传统云计算巨头中。

这并不奇怪,因为这些公司拥有丰富的大规模分布式系统经验,以及强大的技术积累。

这意味着专门的AI公司在短期内可能会在AI基础设施能力上受到限制。

尽管他们在AI算法和应用方面可能领先,但在处理大规模基础设施的经验上可能不及传统云厂商。

这种情况可能会导致一些有趣的合作和竞争动态。

我们可能会看到更多的AI公司与云厂商建立深度合作关系,以弥补自身在基础设施方面的不足。

同时,一些大型AI公司可能会加大对基础设施人才的投资和培养,试图建立自己的核心竞争力。

对于那些有志于成为AI基础设施专家的人来说,这无疑是一个充满机遇的时代。

他们需要具备跨学科的知识和技能,包括分布式系统、高性能计算、网络架构、存储技术,

以及对AI算法和工作负载特性的深入理解。

同时,他们还需要具备系统思维和创新精神,能够在复杂的技术生态中找到平衡点,并不断推动技术的边界。