HyperPod:通过新的治理功能降低成本

HyperPod:通过新的治理功能降低成本

关键字: [Amazon Web Services re:Invent 2024, 亚马逊云科技, 生成式AI, Dynamic Allocation, Task Prioritization, Real-Time Monitoring, Cost Optimization, Idle Compute Utilization]

导读

各组织的团队正在训练新模型、使用自己的数据进行微调,并大规模运行推理——所有这些都需要及时获取加速计算资源。鉴于巨大的需求和有限的预算,组织无法在需要时为每个项目、团队和任务分配加速计算资源。在本次会议中,了解Amazon SageMaker HyperPod中的新治理功能如何从根本上简化了计算资源在整个组织的团队和项目间的优先级排序和分配,这有助于团队按时完成最重要的生成式AI开发项目,同时避免因计算资源利用不足而导致的成本超支。

演讲精华

以下是小编为您整理的本次演讲的精华。

在不断演进的人工智能领域,生成式人工智能(GenAI)的出现带来了变革性时代,重塑了公司进行模型训练和数据处理的方式。作为亚马逊云科技产品经理的Kareem在备受期待的亚马逊云科技 re:Invent 2024大会上登台,他推出了一种突破性解决方案,旨在应对GenAI模型和数据集快速增长带来的挑战。

Kareem的开场白生动描绘了过去一年GenAI领域所见证的指数级增长。公司发现自己正在应对以惊人速度增长的基础模型,每年扩大4-6倍,每6个月规模翻倍。与此同时,为这些模型提供燃料的数据集也呈现类似轨迹,每8个月翻一番。这种前所未有的增长不仅影响了上市时间,还给成本带来了沉重压力,迫切需要创新解决方案。

当Kareem深入探讨客户面临的挑战时,他强调了四个关键领域。首先,数据收集成为一个巨大障碍。获取大量多样化的数据集、确保其质量并为模型训练做好准备,这是一项艰巨任务。其次,为数据科学家运行训练模型提供和管理集群也是一大挑战。保持这些集群的可用性和稳定性至关重要,任何中断都可能破坏整个过程。第三,启用分布式训练策略以加速模型训练需要复杂的协调和实施。最后,确保底层基础设施的弹性和稳定性至关重要,任何故障都可能使整个努力付诸东流。

为应对这些紧迫挑战,亚马逊云科技去年推出了SageMaker HyperPod。HyperPod是一组具有自我修复能力的弹性集群,成为游戏规则改变者,可以减轻节点或集群故障的影响。它简化了分布式训练过程,减轻了复杂配置的负担,使数据科学家能够专注于核心任务。此外,HyperPod提供了对任务提交和工作负载管理的增强控制,让用户能够更好地监督资源利用情况。

SageMaker HyperPod的影响深远,使客户能够将训练时间缩短40%。这一卓越成就在亚马逊云科技的客户群中引起强烈反响,著名公司如Hugging Face、Anthropic和Cohere都采用了这一解决方案并从中获益。

然而,亚马逊云科技对创新的承诺并未就此止步。同年9月,该公司推出了Amazon Elastic Kubernetes Service (EKS)对SageMaker HyperPod的支持,进一步扩展了集群和作业的弹性能力。这种集成允许客户在任何EKS上创建HyperPod集群,确保在发生故障时,作业可以无缝从最后一个检查点恢复,而集群可以动态修复,最大限度减少停机时间,提高生产力。

尽管取得了这些进展,客户仍在表达他们的担忧,促使亚马逊云科技深入探讨剩余的挑战。一个主要问题围绕着昂贵GPU和计算资源的静态分配。团队被分配了固定的配额,常常导致资源分配不足或过度分配的情况。这种静态方法阻碍了资源在团队之间的流动,导致空闲的计算资源无法被等待任务的团队有效利用。

此外,无法自动优先处理任务加剧了这一问题。数据科学家被迫手动干预,停止低优先级任务以腾出空间给高优先级任务,从而影响生产力和效率。加之缺乏对资源利用情况的实时可见性,管理员无法洞察潜在的效率低下和优化机会。

这些问题的集中体现是数据科学家生产力降低、任务等待时间增加,以及组织为缓解团队面临的瓶颈而寻求获取额外计算资源导致成本攀升。

有趣的是,亚马逊自己的零售和AI团队也遇到了类似的挑战,促使他们开发了一种创新的内部解决方案。来自亚马逊AI团队的Joy登台分享了他们的经验和应对这些障碍所采取的措施。

Joy解释说,与许多客户和合作伙伴一样,亚马逊一直在加大对GenAI的投资,预计2025年及以后将继续增长。然而,这种对加速计算资源(AI开发所需)的需求激增,与有限的供给形成了供需失衡。

正如Kareem之前强调的那样,静态分配方法被证明是无效的,一些团队出现空闲容量,而另一些团队则在等待分配。此外,团队缺乏标准化的方式来监控和跟踪利用率指标,使他们无法了解自己的性能和效率水平。

为了直接应对这些挑战,亚马逊的AI团队构建了一个内部的AI编排和分配服务。该服务整合了所有可用的加速计算资源,并采用了一种专门构建的动态调度算法,以最大限度地提高项目和团队之间的利用率。认识到用户体验的重要性,该服务为科学家和客户提供通知,让他们了解作业状态变化,例如作业何时启动或停止。

此外,该服务提供了集中的利用率指标,包括实例使用小时数、集群利用率、核心和内存利用率以及功耗指标。弹性是一个重点关注领域,包括对节点进行定期健康检查、自动重新提交失败作业,以及能够从最后一个检查点重新启动作业。

通过这个综合系统并利用空闲容量,亚马逊的AI团队在其团队中实现了超过90%的令人印象深刻的利用率。这不仅解决了高需求、低供给和低利用率的挑战,还使团队能够加速开发工作,平滑需求并优化亚马逊内部的效率。

然后,Kareem再次登台,介绍了备受期待的SageMaker HyperPod Task Governance发布。这一突破性解决方案旨在最大限度地提高加速器的利用率,同时降低各种工作负载(包括模型训练、微调和推理)的成本。

这次发布的关键要点是多方面的。首先也是最重要的,它实现了跨团队的计算资源动态分配,同时保持预算约束。其次,它确保在资源争用期间优先处理高优先级任务,从而提高了计算资源的价值。第三,它为管理员提供了实时监控和审计功能,提供集群健康状况、资源分配和治理指标的洞察。这种实时可见性使管理员能够做出明智决策并微调资源分配策略,确保最佳利用率并满足团队需求。

Kareem强调,SageMaker HyperPod Task Governance是一个智能调度器和编排器,可以实现计算资源的动态分配。这种动态分配方法与之前的静态分配模型(团队被分配固定的计算资源)有着显著区别。通过动态分配,团队被授予配额,可以在分配的限额内保证获得计算资源。但是,如果需要额外资源,团队可以按需突破到空闲计算资源,无需手动干预或经历漫长的审批流程。

此外,Task Governance能够利用空闲计算资源,确保没有可用的计算能力被浪费。如果一个团队有分配但未使用的空闲计算资源,其他团队就可以利用这些资源,从而减少等待时间并加快任务执行。

实时任务优先级排序是Task Governance的另一个关键特性。在资源争用期间,当多个任务在队列中等待时,Task Governance将根据预定义的策略自动优先处理高优先级任务。这确保了关键任务在低优先级任务之前获得所需的计算资源,优化了资源分配并最小化了延迟。

为了展示Task Governance的强大功能,Kareem向观众现场演示了SageMaker控制台提供的功能。控制台包含三个选项卡:Dashboard、Tasks和Policies。Dashboard提供了集群利用率和健康状况的实时指标,而Tasks选项卡则显示了集群上运行的任务状态,包括正在运行、等待或被抢占的任务。

Policies选项卡是管理员可以定义资源分配和任务优先级两个关键策略的地方。任务优先级策略允许管理员为不同的任务类别(如推理、训练、微调和数据处理)分配权重。这些权重决定了在资源争用期间,任务被分配资源的优先顺序。

空闲计算资源分配策略使管理员能够指定如何在团队之间分配空闲计算资源。管理员可以选择公平份额方法,根据团队优先级、任务类型和现有利用率分配空闲资源,或者先到先得方法。

Kareem模拟了一个包含三个团队的场景:聊天机器人团队、研究团队和工程团队。每个团队都被分配了一个权重和特定配额的计算资源,如P5或P4实例。有趣的是,聊天机器人团队选择不将其空闲计算资源借给其他团队,而其余团队则愿意共享和借用空闲资源。

Kareem演示了团队如何提交任务,以及Task Governance如何根据定义的策略动态分配资源。如果某个团队需要超出其配额的资源,Task Governance会自动扩展到空闲计算资源,确保高效利用。相反,如果提交了高优先级任务且没有空闲资源可用,Task Governance会抢占低优先级任务,使高优先级任务获得优先权。

在整个演示过程中,Kareem强调了实时监控功能,展示了管理员如何跟踪团队分配、利用率和待处理任务,从而做出明智决策并优化资源。

为进一步说明SageMaker HyperPod Task Governance的现实影响,Kareem邀请了来自Articulate AI的Sean Kumar分享他们的经验和见解。

Sean代表Articulate AI,这是一家开发全栈生成式AI平台的公司,阐述了他们在AI模型开发方面独特的方法。Articulate AI的设计理念是,没有单一模型能够有效解决所有行业的所有任务。相反,他们主张采用一系列模型,包括大型语言模型(LLM)和非LLM,在大规模上协同工作以为企业应用程序提供最佳成果。

为实现这一愿景,Articulate AI开发了一种称为“模型网格”的技术。这个模型网格由一系列预训练模型组成,针对特定任务、行业和领域进行了微调和优化。通过利用航空航天、半导体和金融服务等行业的数据合作伙伴关系,Articulate AI旨在为行业特定应用程序提供一流的性能和成本效益。

尽管是一家相对年轻的公司,Articulate AI已经拥有多元化的客户群,其中一些客户正处于AI应用程序生产部署的不同阶段。他们的平台设计为自包含和预打包,集成了企业级、生产就绪AI应用程序所需的众多技术组件。这种方法加快了实现成果的时间,使客户能够在数周而不是数月内部署解决方案,同时通过在客户自己的亚马逊云科技虚拟私有云(VPC)中托管平台来确保安全性和可扩展性。

随着对生成式AI解决方案的需求激增,Articulate AI意识到了不断演变的格局以及针对解决行业特定用例的领域特定模型的需求。虽然像ChatGPT这样的通用知识模型可以提供广泛的见解,但在深入研究诸如航空航天复合材料设计、空气弹性学或计算流体动力学等高度专业领域时,它们往往会力有未逮。

为解决这一差距,Articulate AI专注于构建能够理解和处理行业特定数据的领域特定模型,如航空航天图像、结构力学方程和计算流体动力学。然而,他们认为,即使是领域特定模型也不足以在长期内与竞争对手区分开来。

根据Articulate AI的观点,实现真正差异化的关键在于让客户能够使用自己的专有数据对这些领域特定模型进行微调。通过在客户自己的环境中托管整个平台,Articulate AI使客户能够利用自己的数据对模型进行微调,确保生成的模型仍然是他们的知识产权,永远不会离开他们的安全环境。

这种方法源于Articulate AI对未来的愿景,届时将需要数以百计、数以千计的模型来满足不同行业和任务的多样化需求。这些模型不一定会更小,但会针对特定领域和任务进行定制,涵盖从广泛应用到特定行业内高度专业化的用例。

正如Sean所解释的那样,在航空航天行业的早期概念设计阶段使用的工具、数据和模型将与复合材料制造所使用的工具、数据和模型有很大不同。跨领域的这种精细调整模型的激增需要一个强大的系统来促进高效的模型微调、评估和部署。

这就是HyperPod Task Governance的用武之地。Articulate AI的应用科学、数据科学和研究团队由数十人组成,之前一直在为模型微调和评估设置和管理自己的高性能计算集群时面临挑战。这个过程不仅耗时,而且将宝贵的数据科学家资源从核心职责中分散出去。

HyperPod Task Governance为Articulate AI提供了一种解决方案,可以自动化这些过程,确保宝贵的GPU资源(对任何AI公司来说都是关键资产)得到高效利用。通过以自动化方式解决中断问题,如在发生故障时自我修复节点或集群,HyperPod Task Governance减轻了数据科学家的负担,使他们能够专注于核心任务。

在不同的异构计算源、项目和团队之间分配资源是HyperPod Task Governance另一个出色的领域。Articulate AI现在可以根据重要性对任务进行优先级排序,无论是为航空航天、半导体构建领域模型,还是协助客户微调自己的模型。

作为一家将大部分燃烧率用于GPU消耗的初创公司,成本管理和优化也是Articulate AI的重要考虑因素。HyperPod Task Governance提供了必要的工具来衡量、跟踪和优化GPU利用率、实例使用小时数、集群利用率、核心和内存利用率以及功耗指标,所有这些都可以通过单一窗口实现。

HyperPod Task Governance中的细粒度资源分配控制使Articulate AI能够高效管理资源,确保团队对其利用率负责。这允许持续监控、调整策略并根据性能指标优化资源分配。

Articulate AI对HyperPod Task Governance的依赖不仅限于他们的企业和专家产品。为了加快上市时间并为客户提供快速的价值证明,Articulate AI着手开发了一款名为Articulate Essential的新SaaS产品。在仅2-3个月的紧迫时间框架内,该团队利用HyperPod Task Governance高效地微调新模型,从而成功在1月份推出了Articulate Essential。

正如Sean所强调的,如果没有HyperPod Task Governance提供的功能,在如此压缩的时间框架内快速微调和部署新模型是不可能的。这款最初作为免费服务提供的产品允许客户引入他们的文档并体验Articulate AI平台的强大功能,为最终在他们自己的环境中部署铺平了道路。

最后,Kareem重申了SageMaker HyperPod Task Governance的变革性影响,使像Articulate AI这样的客户能够加速开发工作,同时优化资源利用并降低GenAI工作负载相关成本。

在2024年亚马逊云科技 re:Invent大会上的演讲展示了亚马逊云科技对创新的承诺,以及解决客户在快速发展的生成式AI领域面临的不断演变的挑战的决心。通过推出SageMaker HyperPod Task Governance,亚马逊云科技提供了一个综合解决方案,简化了资源管理、实现了动态分配、促进了任务优先级排序,并提供了实时监控和成本优化功能。

通过整合尖端技术和从客户经验中汲取的见解,亚马逊云科技展示了预测和响应行业需求的能力,将自己定位为在释放生成式AI全部潜力的过程中值得信赖的合作伙伴。

下面是一些演讲现场的精彩瞬间:

演讲者强调GenAI模型和数据集的快速增长,导致上一年公司的上市时间和成本增加。

5d368a4255917f412e62fcd81dc457cb.png

强调了静态资源分配和缺乏可见性管理GPU集群的挑战,导致了昂贵的加速计算资源利用率低下。

fea3686ef04f0206ba50a57c6d29838e.png

亚马逊中央效率团队的领导者Joy讨论了为GenAI开发分配加速计算资源所面临的挑战,由于静态分配和缺乏利用率跟踪而导致效率低下。

09bfd32244b2fd75d037549bfcbe89b1.png

亚马逊云科技构建了一个内部人工智能编排和分配服务,以最大限度地利用各个项目和团队的加速计算资源,为客户提供通知、利用率指标和恢复能力。

28c0ec530f9f52d351061e93bd3f56d2.png

亚马逊推出了一种智能调度程序,可实现计算资源的动态分配,允许团队无需人工干预即可无缝扩大或缩小使用量。

62efbaf4b391946849cbc9437e415e61.png

Articulate加快了实现成果的速度,使客户能够在数周内部署生产级别的人工智能解决方案,安全托管在客户的亚马逊云科技 VPC环境中。

52302944d82b421fbfb6c3bd0df424c1.png

演讲者表示,虽然目前的产品可能不是主要的收入来源,但它是测试平台功能的绝佳起点,最终目标是在客户自己的环境中部署,这要归功于Hyper Pod。

8dc9e63b695dc665a41204fb98cbdba8.png

总结

在一段引人入胜的叙述中,亚马逊云科技的产品经理Kareem揭开了SageMaker Hyperpod Task Governance的革命性推出,这是一种突破性解决方案,使组织能够最大限度地利用加速计算资源,同时降低成本。这一创新产品解决了公司面临的一个紧迫挑战,即GenAI模型和相应数据集规模的指数级增长,这严重影响了上市时间和运营费用。

Kareem生动地阐述了SageMaker Hyperpod Task Governance如何实现跨团队的动态计算资源分配,确保优先处理高优先级任务,并高效利用闲置计算资源。通过实时监控和审计功能,管理员可以前所未有地洞察资源利用情况,从而做出明智决策并优化成本。该解决方案承诺将提高计算利用率高达40%,同时降低相同比例的成本。

来自亚马逊AI团队的Joy分享了她团队的经历,强调了他们面临的加速计算资源需求高、供应低以及静态分配效率低下的挑战。他们基于动态调度算法的创新内部服务实现了令人瞩目的90%利用率,加快了开发进程并平滑了需求。

Articulate AI公司是全栈生成式AI平台的先驱,Sean Kumar强调了SageMaker Hyperpod Task Governance在他们大规模微调特定领域模型的征程中发挥的关键作用。Articulate AI有数百甚至数千种针对不同行业定制的模型愿景,他们利用Hyperpod的能力自动分配资源、优先处理任务和优化成本,使他们能够以前所未有的速度和效率为客户提供尖端的AI解决方案。

这段叙述以一个行动号召结束,邀请与会者探索Articulate AI新推出的SaaS产品Articulate Essential,展示了他们平台的强大功能,以及SageMaker Hyperpod Task Governance在加速上市时间方面的不可或缺的作用。

亚马逊云科技(Amazon Web Services)是全球云计算的开创者和引领者。提供200多类广泛而深入的云服务,服务全球245个国家和地区的数百万客户。做为全球生成式AI前行者,亚马逊云科技正在携手广泛的客户和合作伙伴,缔造可见的商业价值 – 汇集全球40余款大模型,亚马逊云科技为10万家全球企业提供AI及机器学习服务,守护3/4中国企业出海。

<think>嗯,用户这次聚焦在GPU故障处理的具体场景上,看来是位技术实操型的运维人员。从ta引用的资料来看,特别关注了SageMaker HyperPod的免运维特性和K8s的弹性调度机制,说明用户所在环境可能是大规模GPU集群,且对训练中断问题非常敏感。 用户引用的文献[1]提到"忘记做Checkpoint导致回溯"的问题,这其实指向GPU故障中最棘手的训练中断场景。文献[3]提到的DLRover十分钟故障检测机制也值得注意,用户可能希望了解具体实现方式。这些引用暗示用户需要的是生产环境中的实战解决方案,而非理论概述。 关于GPU故障排查,需要从硬件、驱动、计算框架三个层面展开。硬件层最常见的是显存错误和散热问题,比如NVIDIA的Row Remapping机制触发就需立即处理。驱动层要特别注意CUDA版本与框架的兼容性,PyTorch官网的兼容矩阵是必备参考。计算框架层最头疼的是NCCL通信问题,像"unhandled system error"这种报错往往需要结合IB网络查证。 用户没提但可能关心的隐藏点:如何区分单卡故障和集群通信故障。前者通常有GPU-Zoom等工具检测,后者需要nccl-test等分布式测试。另外文献[4]提到的云平台API其实能简化故障诊断,比如AWS的GPU-memory-utilization监控项就比手动解析nvidia-smi高效得多。 最后要注意文献[5]暗示的AI质检场景——如果用户涉及工业质检系统,还要考虑视频流处理导致的显存碎片化问题,这和常规训练任务故障特征不同。</think>以下是AI算力中心运维工程师在处理GPU故障时的典型问题及系统性排查方法,结合行业实践和引用文献分析整理: --- ### **一、GPU硬件层故障** 1. **显存错误(ECC Errors)** - **现象**:训练作业崩溃,NVIDIA SMI显示`Uncorrectable ECC Errors` - **排查**: ```bash nvidia-smi --query-gpu=ecc.errors.uncorrected --format=csv # 查询ECC错误计数 ``` - 若计数持续增加 ⇒ 物理显存损坏 ⇒ **更换GPU卡**[^1] 2. **散热故障(Thermal Throttling)** - **现象**:GPU频率降低,`GPU Utilization`突降,`Temperature`超阈值(通常>90℃) - **排查**: ```bash nvidia-smi -q -d TEMPERATURE,POWER # 监控温度与功耗 ``` - 检查散热系统:风扇转速、机柜风道、冷却液流量(液冷场景) - 清理灰尘或调整作业调度策略(如分散高负载任务)[^3] --- ### **二、驱动与软件栈故障** 1. **CUDA初始化失败** - **现象**:`CUDA driver version is insufficient for CUDA runtime version` - **排查**: - 检查驱动兼容性:`nvidia-smi`输出驱动版本 vs CUDA Toolkit需求版本 - 升级驱动或降级CUDA版本(需同步验证框架兼容性) 2. **GPU通信故障(NCCL Errors)** - **现象**:分布式训练报错`NCCL unhandled system error` - **排查**: - **网络层**:通过`ibstat`检查InfiniBand链路状态,验证RDMA通信[^4] - **硬件层**:替换故障GPU或NIC网卡 - **框架层**:设置`NCCL_DEBUG=INFO`输出详细日志定位问题节点 --- ### **三、资源管理类故障** 1. **显存泄漏(OOM)** - **现象**:`CUDA out of memory`,但监控显示显存未满载 - **排查**: - 使用`nvtop`或`gpustat`实时监控显存占用 - 检查框架配置:如PyTorch的`max_split_size_mb`参数 - 启用**自动Checkpoint**机制防止训练中断(参考SageMaker HyperPod设计[^1]) 2. **GPU挂起(Stuck Kernel)** - **现象**:GPU利用率卡在100%但无计算输出 - **排查**: ```bash nvidia-smi --query-compute-apps=pid --format=csv # 定位占用进程 kill -9 <pid> # 强制终止异常进程 ``` - 配置**K8s GPU资源隔离**(如七牛云实践[^2]),限制单任务资源占用 --- ### **四、集群级故障处理** | 故障场景 | 解决方案 | |-------------------------|--------------------------------------------------------------------------| | **单节点GPU失效** | 启用DLRover等工具自动迁移任务至健康节点[^3] | | **多节点通信瓶颈** | 优化IB网络拓扑,使用`osu_bw`测试带宽,调整NCCL的`RING`或`TREE`算法 | | **版本冲突** | 通过容器化(Docker/K8s)隔离环境,保证CUDA驱动与框架版本一致性[^2][^4] | --- ### **关键运维工具链** ```mermaid graph LR A[故障检测] --> B[nvidia-smi/dmon] A --> C[DCGM Exporter] B --> D[Prometheus/Grafana] C --> D D --> E[自动告警] E --> F[日志分析] F --> G{决策} G -->|硬件故障| H[触发K8s驱逐流程] G -->|软件故障| I[重启容器/回滚版本] ``` > **最佳实践**:大型算力中心需建立**分层故障响应机制**: > - L1:自动化工具处理常见故障(覆盖70%场景) > - L2:运维工程师深度排查(如NCCL通信优化) > - L3:联合厂商解决硬件缺陷(如GPU批量召回)[^5] ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值