360智算中心:万卡GPU集群落地实践
- AIGC
- 2024-10-14
- 771热度
- 0评论
01
基础设施建设
1.1 服务器选型
-
2片CPU -
2张存储网卡(负责带内管理、访问存储) -
4块PCIe Gen4 Switch 芯片 -
6块NVSwitch 芯片 -
8块GPU芯片 -
4张IB网卡


nvidia-smi topo -m
佐证查看,经过实际验证,开启了GDR后大模型训练速度最高可以提升50%。1.2 网络建设


-
同一个Node内的GPU通过NVLink通信。 -
同一个SU内不同Node的挂在同号网卡下的GPU可以通过Leaf交换机通信,即同轨通信,现在大模型训练的通信基本都为同轨通信,通信路径为HCA -> Leaf -> HCA。 -
同一个SU内不同Node的挂在不同号网卡下的GPU需要跨Spine通信,即跨轨通信,这种通信方式在大模型训练中非常少,通信路径为HCA -> Leaf -> Spine -> Leaf -> HCA。 -
不同SU的GPU需要跨Spine通信,通信路径为HCA -> Leaf -> Spine -> Leaf -> HCA。
02
Kubernetes集群建设
2.1 调度能力

-
Gang调度:满足“All or Nothing"的调度需求,避免Pod的任务调度导致集群资源的死锁与浪费。 -
BinPack调度:最小化资源使用量,优先将碎片任务调度到同一台机器,最大化集群的整体利用率。 -
优先级与抢占:提供了P0~P5一共6种优先级,其中P0~P2为高优先级任务,可以抢占P4、P5的任务,同时P3既不会执行抢占动作,也不会被高优先级抢占。满足了不同任务的重要性区分,确保关键任务能够顺利执行。 -
网络拓扑感知调度:实现了智能化的资源调度和任务分配,感知各个节点间的网络拓扑关系,将通信频繁的任务分配到带宽高、延迟低的区域,提升数据传输效率,减少网络瓶颈。最简单的拓扑感知调度为将任务尽量分配到同一台交换机下的多个节点,我们经过验证后发现,这个调度策略在某些特定场景下可以带来超过20%的收益。 -
延迟调度:大模型训练场景中,占用大块资源的任务结束时由于资源释放的顺序不确定,导致资源需求小的任务总是被优先调度,此时优先级规则是不生效的。基于这种场景我们提出了延迟调度的方法,当低优先级的任务资源满足时,采取延迟调度的方式,解决了资源需求大的训练任务长期饥饿的问题。 异构算力调度:我们实现了在单一智算集群中构建NVIDIA-GPU和多种国产化芯片,兼容昇腾等主流AI芯片,并且全面适配支持了X86、arm架构,通过配套的AI开发平台一键调度海量异构算力资源。
2.2 网络方案

-
mofed:Mellanox网卡驱动,推荐将网卡驱动直接部署到物理机上,不通过network-operator的容器化方式部署,这样可以提高整个系统的稳定性,否则当network-operator出现异常时,会导致宿主机失联,只能通过BMC方式连入主机。 -
rdma-shared-device-plugin:将服务器上的mlx网卡以k8s扩展资源的形式暴漏出来,供业务申请使用。 -
Secondary CNI:在k8s集群中建立第二个网络平面,以支持分布式训练多机多卡的网络通信。 -
Multus-cni:k8s环境中的容器多网络方案,能够attach多个网络接口到pod中,是meta类的cni插件,能够和第三方插件搭配使用并且不会产生冲突。 -
container-networking-plugins:包含多个cni插件,主要利用macvlan插件,为pod中申请的mlx资源创建新的mac地址以便从新地址转发流量。 -
whereabouts:负责在集群范围内对挂载到pod中的mlx网卡分配对应的ip地址
-

-
除了IB网卡外,还需要专门的IB交换机支持,通过UFM来统一管理IB网络。 -
在k8s集群中不需要通过第三方网络组件建立第二网络平面,此时可以不需要再配置Macvlan。
03
训推加速
3.1 QLM训练加速
-
千卡模型训练:支持超过千卡规模的大模型训练,并优化了长文本(超过360K token)的训练性能。针对智脑模型进行了专门的GDR、3D并行加速和定制优化,Dense模型训练速度达到了175TFLOPS,整体性能提升了8倍。 -
兼容HF模型格式:QLM具备与Hugging Face模型格式的无缝转换功能,方便开发者在多平台间灵活使用,提高了模型的可移植性。 -
训练过程可视化:通过可视化界面实时监控训练过程中的关键指标,如损失函数、学习率、训练性能等,帮助研究人员快速发现问题并优化模型。 -
训练过程Profile:QLM提供了全面的性能分析能力,可以对训练过程中的各个阶段进行深度剖析,帮助定位计算和通信瓶颈,进一步优化训练效率。 -
模型评测:QLM集成了多种评测工具,支持对模型的训练效果进行全面评估,确保模型性能达到预期。 -
模型微调:QLM支持灵活的微调功能,用户可以在预训练模型的基础上进行定制化微调,以满足特定业务需求。
3.2 GLLM推理加速
-
多平台硬件支持:GLLM能够无缝运行在不同的硬件平台上,无论是在企业内部应用还是面向客户的AI产品,都能提供高效、稳定的推理服务。 -
Continuous Batching:GLLM通过动态批量处理推理请求,极大提高了GPU利用率,降低了每个请求的平均处理时间,优化了系统性能。 -
PageAttention:通过优化内存访问机制,Page Attention提升了长文本推理的内存利用率和计算效率。 -
PrefixCache:这一缓存机制减少了重复计算,特别是在长上下文推理场景中,显著降低了首字返回的延迟。
04
AI平台建设

4.1 平台基础能力

-
交互式建模:交互式建模是AI平台支持用户进行实验性数据分析、特征工程、模型设计与验证的重要能力。它强调实时性和灵活性,允许数据科学家和算法专家在轻量化的环境中快速迭代模型,调整参数并观察即时反馈。平台集成了Jupyter Notebook与VSCode,提供开箱即用的可扩展云端IDE环境,并支持多租户实时协作。 -
分布式训练:分布式训练是AI平台的一项核心能力,尤其在大模型训练中尤为重要。通过秒级调用海量计算资源,用户可以轻松启动千卡训练任务,支持3D并行、极致通信、训练过程可视化及故障自愈等功能,广泛应用于大规模多模态训练和自然语言处理,显著提高训练效率,缩短开发周期。 -
在线部署:在线部署是AI平台将训练好的模型以API或微服务形式部署到线上供业务调用的重要能力。平台能够根据业务需求自动伸缩部署实例,满足高并发需求。同时,实时监控模型服务的运行状态,包括响应时间、并发请求数和资源消耗,确保服务的稳定性和高可用性。 -
资源池管理:AI平台提供对计算、存储和网络资源的统一管理与分配能力,确保多租户环境下资源分配的公平性与有效性。通过动态调度、负载均衡、资源隔离、弹性伸缩和故障恢复等机制,确保在多用户、多任务环境下高效、稳定地利用计算资源。 -
其他优化手段:提升整体资源利用率是AI平台的核心能力之一,特别是在多个用户共享有限计算资源时,平台需要合理安排任务的执行优先级。平台提供低效任务优化、最大排队时长限制、抢占等功能,能够自动识别并终止低效任务,避免资源浪费,在某些特定项目下,AI平台帮助其整体资源利用率提升了25%以上。
4.2 可视化能力

-
集群资源可视化:集群资源可视化提供整个计算环境的资源使用情况,帮助用户和管理员了解系统运行状态,主要包括节点状态监控、网络流量监控、磁盘和IO监控、资源调度监控等。 -
模型训练资源监控:模型训练资源监控侧重于对计算资源的实时追踪和分析,主要包括GPU/CPU利用率监控、显存和内存使用监控、温度和功耗监控、SM利用率等常规监控,通过这些监控可以判断是否达到硬件瓶颈。 -
任务维度指标统计:任务维度的指标统计功能帮助用户深入了解每个任务的执行性能,主要包括:任务运行时长分析、任务执行成功率、TFLOPS统计、Token处理速度等业务相关指标,并支持根据这些指标进行任务成本评估和优化。 -
训练过程可视化:训练过程可视化是模型开发者调试和优化模型的重要工具,它涵盖的视图包括但不仅限于损失函数和评估指标曲线、超参数调节和对比、实时训练日志、多模型对比可视化、梯度和权重监控等,帮助用户选择最优的模型架构和训练策略,快速定位问题。
4.3 故障容错
-
运行时环境检测:运行时环境的异常主要表现为导致训练任务异常退出、训练任务性能下降、甚至内存泄漏等问题。如 nvidia-fabricmanager
服务未正常启动会导致训练任务失败,但是这个服务对于用户来说是屏蔽且无感的,用户无法通过应用程序的日志定位到这一问题。基于当前场景,QihooSMI实现了智算中心的运行时环境监测,检测的内容包括系统内核模块缺失与版本异常、驱动异常、关键软件服务状态异常及版本缺失、集群关键组件的检测与异常修复等。这些故障可以在秒级定位到运行时环境故障源,并可以立即修复同时不影响运行时任务。 -
硬件故障检测:硬件故障通常表现为服务器宕机、GPU硬件故障、硬盘损坏等。这些故障往往会导致计算节点不可用或性能大幅下降,尤其在大规模模型训练场景中,硬件故障可能会严重影响整个训练任务。QihooSMI实现了GPU ECC故障检测、掉卡、网卡异常等常见GPU故障检测,同时采取了故障隔离、节点排干等一系列自愈策略,及时止损。硬件故障往往需要运维人员下线维修,因此当硬件故障发生时,QihooSMI便能秒级定位到故障且及时告警运维人员,在节点下线维修前这一过程完全做到自动化处理,提高运维效率。 -
网络异常:网络故障在分布式系统中尤为常见,表现为节点间的通信延迟增加、网络中断、数据丢包等。网络故障会严重影响大模型训练任务的效率,因为分布式训练依赖于节点间的高速通信。IB网络的故障检测与恢复依赖于UFM,可以实现故障的隔离、网络拓扑自愈等能力,如当Spine交换机异常时,UFM可以自动调整路由,将数据流量引导到正常的链路上。RoCE网络异常主要通过Prometheus、Grafana等工具监控节点间的网络带宽、延迟、丢包率等指标,并通过告警及时监控感知。 -
慢节点:慢节点是分布式训练中的常见问题,指的是某些节点的性能明显低于集群中的其他节点,导致整体训练任务的速度降低。慢节点的定位对于智算中心的挑战是该节点已经通过了QihooSMI的扫描与检测,但是将其加入到大规模训练中却会引起集群训练任务下降,因此如何从大规模机器中(如128台A800)定位到这台慢节点是一件非常耗时的工作。传统的方式是通过提交训练任务的方式以二分法定位,这种方式往往需要几个小时才能定位到慢节点。QihooSMI基于NCCL-Tests实现了轻量级检测程序,5分钟内即可定位到集群中慢节点,极大提高了检测效率。

05
总结与展望