企业官网建设流程全解析

汕头企业网站建设,如何创建微信小程序下单,开网站流程,用oracle做网站数据库在Kubernetes中为NVIDIA GB200 NVL72及后续平台启用多节点NVLink NVIDIA GB200 NVL72将AI基础设施推向新的极限#xff0c;使得训练大语言模型和运行可扩展、低延迟的推理工作负载成为可能。无论是在本地还是在云端#xff0c;Kubernetes在高效部署和扩展这些工作负载方面扮演…在Kubernetes中为NVIDIA GB200 NVL72及后续平台启用多节点NVLinkNVIDIA GB200 NVL72将AI基础设施推向新的极限使得训练大语言模型和运行可扩展、低延迟的推理工作负载成为可能。无论是在本地还是在云端Kubernetes在高效部署和扩展这些工作负载方面扮演着越来越核心的角色。然而快速演进的AI工作负载、基础设施需求以及新的硬件架构给Kubernetes编排和资源管理带来了新的挑战。本文介绍了一种名为ComputeDomains的新Kubernetes抽象旨在隐藏确保多节点工作负载的每个工作节点能够通过多节点NVLink结构跨节点边界执行安全的GPU到GPU内存操作所涉及的复杂性。作为某中心GPU的DRA驱动程序的一部分提供ComputeDomains将底层的GPU结构NVIDIA NVLink和NVIDIA IMEX与现代Kubernetes原生调度概念动态资源分配简称DRA连接起来为在现代GPU硬件上运行分布式、多节点工作负载提供了所需的基础支持。如果没有ComputeDomains多节点NVLink设置将不得不手动定义并固定这会限制Kubernetes旨在提供的灵活性并以牺牲安全隔离、故障隔离和成本效益为代价。虽然这项工作已在NVIDIA DGX GB200某中心为GB200 NVL72系统制定的蓝图上得到验证但ComputeDomains的设计目标是推广到任何支持多节点NVLink的当前或未来架构包括未来的NVL576系统。本文主要关注基础知识ComputeDomains是什么它们为何重要以及如何使用它们在Kubernetes上运行自己的分布式多节点工作负载。从单节点到多节点GPU计算要理解ComputeDomains的重要性简要回顾一下GPU系统设计随时间的演变会很有帮助。早期的NVIDIA DGX系统通过尽可能多地将GPU打包到一台通过高带宽NVLink连接的服务器中来最大化性能。这种设计提供了强大的节点内扩展能力但仅限于能容纳在单个系统中的工作负载。随着NVIDIA多节点NVLink的引入这个限制消失了。不同服务器中的GPU现在可以通过NVIDIA NVLink交换机以全NVLink带宽进行通信将整个机架转变为单一、统一的GPU结构。这实现了跨节点的无缝性能扩展并构成了超快速分布式训练和推理的基础。GPU通信库如NVIDIA NCCL和NVIDIA NVSHMEM已得到扩展以利用此结构而像PyTorch这样的框架则在此基础上构建以实现快速的跨节点、跨GPU通信。这些库会自动检测并使用最快的可用结构例如NVLink、RDMA、InfiniBand或以太网因此无论拓扑如何分布式应用程序无需更改代码即可实现最佳性能。借助ComputeDomains我们提供了在Kubernetes上支持多节点NVLink的推荐方式。因此它已经作为通用层在其之上构建了整体某中心Kubernetes堆栈中的几个更高级组件包括KAI调度器、某中心Dynamo和某中心DGX Cloud Lepton。下图描绘了DGX GB200系统使用的NVIDIA GB200 NVL72机架拓扑。这只是ComputeDomains在Kubernetes上启用的系统类型的一个例子。图1.一个DGX GB200系统顶部有10个计算托盘底部有8个计算托盘通过中间的九个NVLink交换机连接创建了一个通过多节点NVLink芯片到芯片1.8 TB/s累计带宽超过130 TB/s完全连接的72个GPU网状结构。在Kubernetes上支持多节点NVLink那么在Kubernetes上支持多节点NVLink需要什么ComputeDomains如何帮助实现这一点关键部分是NVIDIA节点间内存交换服务这是GPU驱动程序级别的软件允许GPU跨节点通信。通过IMEX每个单独的GPU内存导出/导入操作都受到细粒度的访问控制。IMEX在一组被称为IMEX域的节点上运行。请参考下图以更好地理解多节点NVLink环境中NVLink域、IMEX域以及其他可能的GPU分区层次之间的关系。图2.多节点NVLink环境中可用的分区层级。可以将ComputeDomains视为IMEX域的泛化。虽然IMEX域存在于驱动层并定义哪些节点可以通过NVLink通信但ComputeDomains将这一概念泛化并扩展到Kubernetes中。它们代表了多节点工作负载的分布式工作节点之间的连接性或可达性的高级概念。IMEX在底层被用来启用这种连接性这是一个实现细节。本质上ComputeDomains会随着多节点工作负载被调度到节点上并运行至完成动态地创建、管理和拆除IMEX域。ComputeDomains不需要静态、预配置的IMEX设置而是实时响应调度事件围绕分布式作业所落地的一组节点自动形成IMEX域。IMES本质上提供了可重新配置的隔离边界而ComputeDomains以一种流畅、透明的方式管理这些边界。借助ComputeDomains每个工作负载都获得其自己的隔离IMEX域和共享IMEX通道确保作业所有工作节点之间的GPU到GPU通信同时安全地与其他作业隔离。ComputeDomain跟随工作负载并随着工作负载的增长或收缩动态调整其拓扑。当工作负载完成时其对应的IMEX域和通道会自动清理释放资源供未来的作业使用。在不影响利用率的前提下实现隔离如上所述IMEX原语旨在作为隐藏在ComputeDomain抽象之下的实现细节。尽管如此我们认为围绕工作负载动态形成IMEX域需要一个健壮的、经过实战检验的解决方案这主要基于以下三个原因安全隔离在零信任环境中即使物理上通过NVLink连接也需要对相邻的GPU作业进行安全隔离。故障隔离相邻的作业即使受信任也不能相互干扰。成本效益即使在1和2的前提下也必须保持高资源利用率这在多租户环境中尤其重要。安全隔离或许可以通过静态NVLink分区来实现但这将严重抑制资源利用率。在受信任的环境中安全隔离可能并不总是最受关注的问题。然而作业可靠性始终是——因此故障隔离也是。IMEX域是一个有状态的分布式系统自然会受到可能导致状态降级或不一致的故障场景和瞬态条件的影响。特别是在大规模情况下这种情况会以可感知的速率发生。在这些情况下爆炸半径应仅限于单个作业。从概念上讲最大化故障隔离的最安全方法是在时间和空间上将单个IMEX域仅与一个特定的工作负载绑定——这正是ComputeDomain实现在底层所确保的。如果没有ComputeDomains人们将不得不静态设置长期存在的IMEX域从而在1和2上都做出妥协。任何用于动态编排IMEX域的自制解决方案最终都会演变成类似于ComputeDomains的东西并且构建起来会很困难。通过提供一个通用解决方案我们可以使用户免于自己进行这些努力并集中汲取经验教训。在Kubernetes中使用ComputeDomainsComputeDomains由某中心GPU的DRA驱动程序提供。近期DRA驱动程序将与某中心GPU Operator一同发布。目前它需要通过Helm chart手动安装。详细的安装说明和先决条件可以在此处找到。通常需要Kubernetes 1.32或更高版本并启用DRA API和CDI。请务必在安装DRA驱动程序时启用ComputeDomain支持这是默认设置并在已设置跨多节点的NVLink分区的环境中运行它例如在GB200 NVL72机架中或跨机架。该驱动程序正在大力开发中。我们建议关注我们的GitHub项目以保持最新状态您可以在此处了解最新版本的信息。部署工作负载让我们通过一个示例来了解如何创建和使用ComputeDomain。以下Kubernetes规范声明了一个名为compute-domain-0的ComputeDomainapiVersion:resource.nvidia.com/v1beta1kind:ComputeDomainmetadata:name:compute-domain-0spec:numNodes:0# -- 此字段已弃用应始终设置为0channel:resourceClaimTemplate:name:compute-domain-0-rct目前还没有工作负载引用这个ComputeDomain。此时它只是一个API对象。ComputeDomain跟随工作负载它只会在工作负载Pod实际调度到节点上时及时围绕它们形成。接下来让我们指定一个工作负载并通过在引用中使用compute-domain-0来将其投入使用。假设我们想要在18个节点上运行一个分布式作业。目标是每个节点使用四个GPU并在所涉及的所有72个GPU之间建立NVLink可达性。为此在本例中我们将在每个节点上运行一个Kubernetes Pod。每个Pod请求四个GPU。与此工作负载的所有其他Pod位于同一个NVLink分区中以实现物理可达性。加入先前指定的ComputeDomain实现逻辑可达性。以下Kubernetes部署规范示例实现了所有这些目标关键概念在内联中解释apiVersion:apps/v1kind:Deploymentmetadata:name:example-mnnvl-workloadspec:# 要求此部署由18个Pod组成。replicas:18selector:matchLabels:job:ex1template:metadata:labels:job:ex1spec:# 将此部署中的所有Pod与先前创建的特定ComputeDomain关联。# 为此请引用与该域关联的所谓资源声明模板。# 本例中该模板的名称在ComputeDomain API对象中定义为 compute-domain-0-rct。# 这里我们还定义了一个新名称 cd-0供下面的容器规范使用。resourceClaims:-name:cd-0resourceClaimTemplateName:compute-domain-0-rct# 定义一个 podAffinity 规则以确保所有Pod都调度到同一个NVLink分区中的节点上。# 具体来说要求所有Pod调度到 nvidia.com/gpu.clique 节点标签具有*相同*值的节点上。# 此标签由某中心GPU Operator设置基于静态NVLink配置状态。affinity:podAffinity:requiredDuringSchedulingIgnoredDuringExecution:-labelSelector:matchExpressions:-key:joboperator:Invalues:-ex1topologyKey:nvidia.com/gpu.cliquecontainers:-name:ctrimage:ubuntu:22.04command:[mnnvl-workload]resources:claims:-name:cd-0# 参见上面的 resourceClaims。limits:nvidia.com/gpu:4# 请求四个GPU。为清晰起见上面的示例通过声明resourceClaimTemplateName: compute-domain-0-rct来建立与先前指定的ComputeDomain的连接。现在资源声明模板的概念可能更清晰了在底层此部署中的每个Pod都会生成一个唯一的资源声明。上面的示例还展示了一种确保一组Pod被放置到都属于同一NVLink分区的节点上的典型方法通过对齐nvidia.com/gpu.clique节点标签值。当ComputeDomain需要扩展到单个NVLink分区之外时需要移除或更改此约束。完整和全面的示例可以在DRA驱动程序文档中找到。已知限制和未来工作某中心GPU DRA驱动程序版本包含了对ComputeDomains的重大改进。除此之外更多旨在提高调度灵活性和易用性的增强功能已在路线图上。以下是当前已知的两个限制以及计划用于缓解它们的工作目前任何给定ComputeDomain每个节点只能有一个Pod。用户必须了解一个节点中有多少GPU可用然后通常从单个工作负载Pod中获取所有这些GPU。该Pod中的应用程序然后需要在这些GPU之间细分其工作。我们计划取消此限制以减少单个节点的相关性。届时应用程序可以由许多单GPU Pod组成这些Pod可能位于同一节点上也可能不位于同一节点上。在这种模式下关注单元是单个GPU而不是单个节点——节点边界几乎变得透明。目前每个节点最多支持一个ComputeDomain。此约束基于为每个工作负载提供其专用IMEX域的选择以及每个节点最多只能运行一个IMEX守护进程这一事实。如果一个ComputeDomain仅占据节点GPU集合的一部分则该节点中剩余的GPU不能成为任何其他ComputeDomain的一部分。例如GB200机架中的六GPU ComputeDomain总是会使一定数量的GPU对其他ComputeDomain不可用最好情况下两个最坏情况下18个。取消此约束一方面可以提高资源利用率但另一方面可能会削弱工作负载之间的故障隔离。没有通用的补救措施我们将允许用户在成本效益和隔离强度之间的权衡频谱上选择他们的最佳点。这项工作已计划并在此处跟踪。其他计划正在进行中例如进一步增强大规模下的鲁棒性并改进整体可调试性。请关注GitHub上的问题跟踪器并浏览里程碑视图以获取路线图的最新动态。我们也鼓励您通过问题跟踪器提交问题、错误报告和增强请求。总结随着像NVIDIA GB200 NVL72这样的先进多节点GPU架构开始推动高性能AI基础设施的极限Kubernetes需要能够理解和管理这些现代GPU系统拓扑的抽象。ComputeDomains通过将NVLink和IMEX域等底层结构与Kubernetes原生调度和DRA连接起来应对了这一挑战。ComputeDomains随着工作负载在集群中移动动态地形成、管理和拆除IMEX域从而实现安全、高带宽的GPU到GPU连接而无需手动设置。最新版本的某中心GPU DRA驱动程序通过弹性和容错能力扩展了此模型允许ComputeDomains随着工作负载扩展或收缩从节点丢失中自动恢复并加速分布式作业的启动时间。对于基础设施团队而言这些变化意味着在GB200 NVL72或DGX GB200系统上进行多节点训练和推理只需最少的设置。对于开发人员而言这意味着跨复杂、NVLink连接的GPU结构运行分布式训练或推理现在感觉就像部署标准的Kubernetes工作负载一样简单。这些创新共同使ComputeDomains成为在NVIDIA GB200 NVL72及未来平台上进行可扩展、拓扑感知AI编排的基石。请参见某中心GPU DRA驱动程序及其最新版本以开始使用。并查看以下其他资源Kubernetes设备管理工作组7月在某会议上关于ComputeDomains演讲的幻灯片7月在某会议上关于ComputeDomains演讲的视频ComputeDomains设计文档关于某中心GPU DRA驱动程序的公共文档显示某中心GPU DRA驱动程序即将推出路线图的项目板更多精彩内容 请关注我的个人公众号 公众号办公AI智能小助手或者 我的个人博客 https://blog.qife122.com/对网络安全、黑客技术感兴趣的朋友可以关注我的安全公众号网络安全技术点滴分享