AWS Re:Invent 从AWS CTO演讲的教训看AI云基础设施架构

AWS Re:Invent CTO专场^[1], Werner Vogels博士并没有发布任何新的产品, 而是把他入职亚马逊20年的宝贵的经验和教训分享出来, 当复杂性是不可避免时, 告诉大家拥抱简单性(Simplexity), 这些经验在我们构建新的AI云基础设施时是尤为重要的.

Simplexity, 拥抱简单

Werner博士引用了Tesler's Law

提醒了参会者:“复杂性既不能被创造也不能被摧毁，它只能转移到其他地方。”

举个例子吧, 例如RoCE网络中的PFC/ECN, 你以为自己很简单的解决了复杂性, 其实把问题转移到了其它地方, 如同下面这个矩阵转置的笑话.

复杂性告警通常有如下几个标志: 软件特性迭代降速, 频繁升级, 调试耗时, 代码库增长过多, 模式不一致, 无处不在的依赖等

对于如何把复杂性(Complexity)变为Simplexity(简单性), werner博士剧了一个很形象的例子: 自行车

独轮车虽然组件最少, 看起来最简单, 却在实际操作运维中很困难, 需要很高的技术能力的团队努力才能实现. 而三轮车虽然组件多, 稳定性更好, 但是灵活度上却带来的一定的限制, 例如转弯不方便.

而普通两轮的自行车介于两者之间, 提供了最佳的平衡, 既灵活又易于控制. 其设计到到了功能和体验的最佳平衡, 因此也成了最简单易用的交通工具.

对于简单性(Simplexity)的几个教训:

1. 未雨绸缪(Make evolvability a requirement), 构建可演进性架构对复杂性进行可预期管理
2. 化繁为简(Break complexity into pieces), 把复杂性分解成多个高内聚和良好API定义的构建块
3. 组织和架构对齐(Align organization to architecture), 建立小团队, 挑战现状, 鼓励主人翁意识
4. 单元化(Organize into cells), 在复杂系统中,通过单元化缩小影响范围
5. 设计可预期系统(Design Predicatable System), 降低不确定性的影响.
6. 自动化(Automate Complexity), 对于不需要高判断力的事情全部自动化.

详细内容可以参考《Werner Vogels：20年架构设计，仅道六句箴言！》^[2] 我们接下来主要谈一下可演进架构, 这也是AWS一直在Well-Architected框架中提到6大支柱: 弹性/安全/性能/稳定/成本/可持续性.

未雨绸缪

对于一个系统, 随着时间的推移都会发生变化, 因此在设计之初, 就需要确保架构能够去适应新的需求.可演进性是一个系统的基础, 是对复杂性进行可预期管理的先决条件.

公司应该构建能够随着时间推移以可预期方式发展的基础设施, 而不是急于推出1.0产品, 迫使团队接下来几年里将新功能添加到日益不稳定的技术栈上. 其实很多技术架构上的灾难往往都开始于Time-To-Market的赶工, 弄出一个人和代码总有一个能跑的框架...

对于一个可演进的系统, 通常包含如下几个维度:

它需要以商业概念作为模型, 隐藏内部的细节, 提供细粒度的接口, 构建智能的端点并且去中心化, 同时要求可独立部署, 能够很好的进行自动化,符合云原生设计原则, 满足故障隔离, 提供很好的可观测能力以及支持多种范式.

werner博士以S3为例, 最初是一个简单, 耐用且高性价比的云存储服务. 到后来随着客户数量的增加, S3都会对其技术和架构进行改进, 但从不影响现有服务的稳定性. 好比开着飞机换引擎.  这得益于在系统设计时就考虑到了未来升级的需求, 设计了灵活可扩展的架构.

它的演进也很好的诠释了AWS对于云计算的价值主张: 一直都是: 弹性,安全, 性能, 成本,可靠性和可持续性.

Werner博士也提到了Nitro System , 虽然很遗憾今年没有新的Nitro v6发布, 但我接下来会对Nitro做一些更详细的阐述.

从可演进架构上来看, Nitro支持多种范式的部署. Nitro除了在通用计算节点上使用外. 在存储上也通过Nitro+4块盘构建了可解耦的存储小系统

在网络设备上, 例如Trn2使用的交换机上有Nitro

在Trn2上还两个Trainium2芯片配置了8颗Nitro

即便是在Nvidia的GB200上, 宁愿抛弃800Gbps的CX8, 也要选择采用6块200Gbps的Nitro

甚至是在高精度时钟分发上也采用了Nitro

而这背后的本质就是可演进架构的抽象, 就像前面自行车那个例子, 独轮车成本最低但运维难, 而三轮车成本高稳定, 但是不灵活. 最后权衡下的选择就是两轮自行车.

而Nitro vs CX8的定位也是如此, 为什么要坚持使用Nitro接入AWS? 对于云选择何种技术的问题, 还是要回到:弹性/安全/稳定/性能/成本/可持续性

从弹性的角度, Nitro隐藏了基础设施中的大量的复杂性, 让所有的资源都能对等的接入到整个Fabric中, 无论是存储/CPU/GPU等资源, 都可以按照用户的需求进行组织和构建. 这一点非常关键, 在第一天Peter的演讲中也有详细的讲解,根据负载的动态可伸缩的架构.

Nitro把中间的网络/存储的资源动态配置和物理拓扑的复杂性全部隐藏了, 也就是Werner博士讲的, 将这些真正复杂的东西转移到了基础设施这一层, 让用户能够更加专注于业务, 并以业务的需求来使用资源.

从安全的角度, 首先Nitro是整个AWS云的可信根

从制造到组装, 再到物流/安装, 以及初始化过程, 最后到服务器引导启动, 整个流程上Nitro以一种非常干净的方式提供了安全验证, 您可以看到这一块中它完全隐藏了内部细节, 并且以端侧智能(Smart Endpoint)的方式构建, 可以独立部署可以很好的自动化, 满足了故障隔离需求, 也有很好的可观测能力.

从性能和稳定性的角度, Nitro当前才200Gbps是CX8的1/4, 但是从稳定的角度考虑, CX8单卡故障导致流量损失模型训练中断, 即便是采用2x400G的接口也会导致一半的流量中断, 对整个集群的影响太大. 而如果采用4张200Gbps的Nitro, 并且拆分成2x100G的接口, 光模块故障率普遍在0.3%左右, 即便是一个链路故障, 流量损失仅有1/8. 实际上这里有一个取舍.

另一方面, 通常硬件的故障率都有万分之几, 当规模大了以后, 硬件每天都会有损坏, 如何做到用户对这些宕机事故不感知? 云上各种异常检测和自动异常调度是非常有挑战的一件事.

而对于云计算而言, 多个租户共享时带来的网络拥塞, 如何让用户不感知实际的物理拓扑和拥塞, 在虚拟网络中做到不丢包满足用户的SLA也是很有挑战的一件事情, 例如最近发布的针对10p10u架构的SIDR路由以及大量的Host拥塞控制机制.

而这些系统的设计无不诠释着Werner博士讲的可演进架构中的隐藏内部的细节/故障隔离/智能端点(Smart Endpoints)/去中心化的设计架构.

从成本的角度, 您可以看到Nitro的部署从计算到存储再到网络设备, 包括大量的GPU实例, 其单芯片的成本来看是很有可能做到CX8的1/4以下的. 另一个成本的视角是售卖率的考虑. 资源在按照用户需求切散售卖的时候, 通常会产生大量的资源碎片, 如何做到碎片化的资源整理, 资源共池, 针对用户的不同需求,能够实现多种范式的交付能力.

从可持续性的角度, 除了环境/绿色能源问题外, 其实也在谈论架构的可演进性.举个最简单的例子吧, 采用这套基于Nitro的系统, 复杂的网络构建问题都被VPC简化了, 数据完全在VPC中被打通, 例如最近刚发布的Nitro支持GPU-Direct-Storage特性, 这样对于推理业务有着很大的帮助, 后面我们将专门阐述.

可演进的AI云基础设施

AWS针对AI云基础设施的演讲, 也有大量的可演进性的思考. 首先它并没有因为这一波AIGC的热潮而迅速的上线一个1.0的业务, 让过去的一年多大家普遍认为落后了.

相反正是这一年多来业务的快速演进, 工业界在可靠性上遇到了大量的问题, 特别是训练集群逐渐通过Prefill-Decode转为训推一体集群时, 很多原有的训练集群架构也存在一些局限性. 而在推理场景, 也存在早期的一些推理系统架构的缺陷基本上就昙花一现,然后就跟不上业务的节奏匆忙下线了.

首先针对工业界常见的FrontEnd VPC/ ScaleOut RDMA 和 ScaleUP三张独立的网络组网模式,

AWS为了保证架构的可演进性以及不出现业务孤岛, 在全系列的GPU实例上采用了基于Nitro构建的SRD EFA架构, 使得前端网络中的计算实例和高性能存储实例都可以通过VPC并采用EFA进行GPU-Direct-RDMA(GDR)和GPU-Direct-Storage(GDS). 也就是说AWS的ScaleOut网络基于VPC可以和FrontEdn以及Storage BackeEnd进行完全的互通.

同时在网络拓扑结构中, AWS并没有采用多轨道的方式(Multi-Rail), 完全采用了对等的FatTree架构.

而对于多轨道部署的Nvidia官方方案, 最近也在开始弱化其多轨道能力, 例如在GB200实例上只能支持4轨道 ,这是由于PXN多轨道优化有一些控制面的消息需要共享内存通信, 在NV的架构上早期的H100 8卡共享一个CPU和内存, 在同一个OS内容易实施. 当到了GB200上时, 架构就无法演进了, 因为单个OS只有4个GPU, 所以轨道数反而降低到了4. 这就是架构不具备可演进性带来的负面影响.

基于对等的组网是非常有价值的, 它对整个云运行效率和最大限度的提高资源利用率是有很大的帮助的, 因为很多亲和性的调度, 例如要在同一个交换机之下这样的约束会使得云上的资源碎片特别大, 这些都是很多IDC运维很难理解的.

另一方面对于实例的弹性除了Elastic能够满足业务的按需供应外, 还有另外一个视角, 即Resilence. 虽然中文都翻译成弹性. 这一点Google TPU的论文《Resiliency at Scale: Managing Google’s TPUv4 Machine Learning Supercomputer》写的很清楚, 详细内容可以参考以前的一篇文章

《大规模弹性部署：Google如何管理TPUv4集群》

同样AWS在设计Trainium 2集群时, 也有很多独到的见解. 首先它是一个训推一体的集群. 即便是在推理阶段也通过Prefill-Decode混合部署调度来提升利用率和降低推理延迟. 然后针对ScaleUP的需求, 首先也是谈到ScaleOut有Global Batch Size的约束从而被迫要ScaleUP的论点, 都是以业务驱动的可演进架构. 在ScaleUP的设计过程中, 也充分考虑的实例要拆散了卖的需求, 即便是一个Trn2-ultra server有64卡, 依旧可以拆成4个trn2.48xlarge 16卡机器或者单卡的实例售卖, 充分满足业务需求.

但是对于Torus的组网, Google采用了OCS光交换机根据售卖实例和线上故障来构建TPU拓扑. AWS我们仔细看了一下, 发现部分的NueronLink接到了一个PCIe交换机上

如图中红色框所以, 我们可以发现每个Trn2 Compute Tray有六根NueronLink Cable

橙色和黄绿色的线缆主要连接3D-Torus的Z轴, 它们都被接到了一个PCIe交换机上, 同时X86的机头也和ComputeTray通过一个PCIe交换机连接. 这样就可以根据售卖的需求, 对数据进行更好的隔离, 并根据拓扑构建相应的p2p连接. 其作用和Google的OCS类似.

对于训练场景而言, 主要是训练数据加载和模型的checkpoint. 和传统的大数据相比, 训练数据出现了更多的非结构化的特征, 并且伴随着数据shuffle输入, 对于数据对象的随机读写需求较高. 另一方面伴随着集群规模扩大, 稳定性逐渐变差, 对于集群的checkpoint频度要求更高.

传统的架构通常采用本地的CPU内存或者本地SSD进行checkpoint, 然后再从FrontEnd VPC进行异步的存储. 而当ScaleOut网络能够接入到存储后, 通过GDS可以将整个存储的性能提升12x. 这也是AWS一直坚持要在ScaleOut上使用和FrontEnd相同的技术栈的原因.

而对于推理场景, 由于Transformer类模型Attention得计算机制, 使得我们可以通过Cache KV矩阵来降低矩阵运算的规模

然后再来看推荐系统有大量的Embedding Table在CPU实例中, NV虽然在后期逐渐在推广一些GraceHopper和Grace Blackwell实例, 但是对于一个业务可演进的架构来看, 将GPU的ScaleOut网络和FrontEnd中的CPU通用计算实例以及Strorage打通后, 整个存储的层次化框架就出来了.

AWS整个AI Infra的设计如同S3的迭代那样, 对整体的架构可以演进性进行了充分的考虑后才推出. 另一方面最近刚发布的DSQL也是一个非常值得学习的分布式架构, 性能超过Spanner 4x. 后面有机会再单独写一篇.