1. KubeCon 简介
2024 年 8 月 21 日至 23 日，云原生计算基金会的旗舰会议联合开源峰会和 AI_dev 在香港汇聚来自领先开源和云原生社区的应用者和技术专家。 KubeCon 每年会在欧洲、美洲、亚洲 3 个地方举办，从 2018 年开始进入中国，这是我第 3 次参加 KubeCon，前两次是以演讲者的身份参加的。
2. 议题分享
本次会议我个人会更加关注和我工作相关的 AI、GPU、调度相关的议题。在这里列举几个我重点关注并且和演讲者有深入交流的议题。
您的GPU在数据中心真的高效工作吗？提高GPU使用率的N种方法 - Xiao Zhang, DaoCloud & Wu Ying Jun, China Mobile
这个分享的主题围绕在 K8s 集群中运行 AI 应用时遇到的 GPU 利用率、性能、效率等问题，探讨如何在集群中运行 AI 应用时，提高 GPU 的 MFU、通信性能以及训练效率。 具体的优化措施有以下几点：
- 通信性能：
- 对并行策略进行优化：在多并行策略训练场景的中，其通信数据量 TP（张量并行）>DP（数据并行）>PP（流水线并行），因此在划分并行策略组时尽量将 TP 组分在同节点、DP 组分在同 leaf 交换机（一层）、PP 组分在同 spine 交换机（二层）中，实现性能最佳。
- 交换机拓扑感知调度：调度时感知交换机拓扑，提升通信性能。
- 训练效率：
- checkpoint优化：快速写入 sharedmemory，减少 checkpoint 中断训练的时间，从分钟级的 checkpoint 优化到了秒级。
- 故障节点屏蔽自动重调度恢复
- 利用率：
- GPU虚拟化混部，采用了 CNCF 的 sandbox 开源项目——HAMi。
- 高低优先级实现相互的算力抢占，更好地 GPU 混部支持。
- 弹性 quota，两个租户间空闲算力临时租借
- 显存超卖超分，将空闲显存置换到内存中。
总体的优化思路上比较全面，从调度、通信、虚拟化混部等多个方向进行了优化，随着各家厂商的 GPU 训练规模的不断扩大，相信这是未来 GPU 大规模训练优化的一个大方向。
坐和放宽，了解大规模 AI 负载场景下的故障感知和健壮的快速故障恢复 - Fanshi Zhang & Kebe Liu, DaoCloud
这个议题讨论的是如何通过开源项目 kcover 快速定位 k8s 集群中 GPU 硬件、RDMA 网络、GPU 训练/推理框架的故障，并对故障节点进行自动屏蔽、恢复，提高 AI 应用的稳定性和弹性。
该项目实现上的思路：
- 收集节点和容器产生的 GPU、PCIe、NCCL、pytorch 错误日志，进行关键字匹配，识别并分析定位故障类型，感知故障节点
- 对故障节点的容器进行驱逐、重调度，使任务自动恢复
大规模的 GPU 训练发生各种故障是在所难免的，近期 Meta 发布的 Llama3 训练论文也提到了他们在训练过程中因为各种故障中断了几百次，非常影响训练效率。 但从 kcover 项目本身以及和该项目的 maintainer 交谈中，也发现该项目存在一定的局限性：
- 基于日志关键字识别异常的方式能识别到的错误类型非常有限，往往无法定位到根因。
- 无法定位任务 hang 住的原因、某个节点通信或计算慢导致拖慢了整体的训练速度的问题，因为这些问题并不会有明确的故障提示。
总而言之，kcover 给了我们很好的启发，构建一个云原生的统一 GPU 任务故障智能诊断、自愈平台（统一的日志采集、分析、屏蔽、恢复）是未来解决大规模 GPU 训练故障问题的一大趋势。
利用拓扑建模和拓扑感知调度加速LLM训练 - William Wang, Huawei
link 这个分享介绍了在 K8s 集群中如何通过实现 GPU 节点机间、机内拓扑感知调度，从而提升多机训练任务的 RDMA 网络通信性能。
其主要的功能：
- 实现 GPU 任务的 RDMA 网络拓扑感知调度和重调度（机间和机内通信）
- 机间通信拓扑优化：spine/leaf 组网，调度时避免跨 spine
- 机内通信拓扑优化：NVLink、NUMA 亲和调度
- 对集群资源建模、workload 建模
- 资源建模（HyperNode）：按网络性能划分节点组（相同性能节点分在一组）
- workload建模（HyperJob）：按性能需求分组，匹配对应性能的节点组
整个方案是在华为云的 volcano 内部版本实现的，后续会逐步开源到社区版的 volcano 中，该方案是否具有普适性还有待观察。
解锁异构AI基础设施K8s集群：发挥HAMi的力量 - Xiao Zhang, DaoCloud & Mengxuan Li, The 4th Paradigm
link 该分享介绍了 GPU 虚拟化项目——HAMi 的细节，该项目主要是通过共享 GPU 将一张 GPU 卡虚拟化成多张虚拟卡，实现更细粒度算力和显存的划分，减少用户使用 GPU 的成本。
简单介绍一下该项目的 GPU 虚拟化方案的实现原理：
- 使用用户态的 CUDA API 拦截技术，对 GPU kernel 下发、显存分配等核心 API 接口进行拦截，实现对算力和显存的拦截。（和腾讯在 2018 年开源的 vCuda 方案类似）
- 除了对 NVIDIA 卡的虚拟化支持，HAMi 在框架层面还统一支持华为、寒武纪等异构卡的虚拟化（这里指的是 scheduler 和 device-plugin 生态的支持，核心的虚拟化拦截库还是由硬件厂商提供）
最后，我和该项目 maintainer 深入交流了很久，发现该项目还是有不少值得优化改进的地方：
- 当前的算力切割方案的隔离性较弱且具有滞后性（参考上一个时间的 GPU 利用率进行算力压制）
- 多卡任务如果存在周期性通信同步的场景，每张卡 GPU 算力被压制的时机不同步，会拖慢整个训练进度。
- 显存超卖的实现过于简单，通过 UMI （统一内存）进行显存分配，完全由 NVIDIA 驱动决定哪些显存需要置换成内存，只适用于潮汐混部的场景（其中一个混部任务空闲），无法应对一些特殊场景下的显存需求。（例如：显存碎片问题、两个任务同时需要分配较多的显存导致性能下降）
利用云原生人工智能技术在生产环境中赋能大型语言模型(LLMs) - Lize Cai, SAP & Yang Che, Alibaba Cloud Intelligence
link 这个分享主要是针对社区非常流行的云原生 AI 推理项目——KServe，介绍该项目如何管理 LLM 推理的生命周期。
该分享更多的是对 Kserve 功能的介绍，这里简单提一下，就不过多赘述了，感兴趣的话可以直接看 KServe 的官方文档。 KServe 本质上是对 GPU 推理涉及到的各个阶段进行 K8s CRD 层面的抽象（例如：模型、网络、服务实例）：
- InferenceService：面向用户，定义推理服务的模型格式、模型名、模型位置、所需资源
- ClusterServingRuntime：面向管理员，定义集群所支持的模型格式、协议、所需资源
- TrainedModel：定义模型属性、大小、保存地址
- InferenceGraph：定义推理工作流程图
经过一系列的抽象，可以让模型推理服务的部署更贴近用户的使用场景、模型服务的管理更加高效。在 K8s 中使用 KServe 进行模型推理服务的部署也是 AI 和 K8s 结合非常典型的例子，相信未来会有更多的开源项目支持更丰富的 K8s for AI 的场景。
3. 其他活动
Ambassador 早餐
和各位 CNCF Ambassador（大家熟知的 Fog 和 Whitney 小姐姐、前同事化冰大佬、晓辉、韩国小哥 Hoon Jo）一起共进早餐，聊了很多国内外的工作、生活等文化差异。 大家平常在线上的开源社区里非常活跃地交流，这次非常开心能和大家在线下见面。
和 CNCF 工作人员的 Ambassador & Maintainer 晚餐
晚上，CNCF 工作人员（Jeff 和 Jorge）热情邀请了我们社区 maintainer 和 ambassador 一起共进了晚餐。 大家聊了一个晚上，话题从"如何筹备一场 KubeCon"、“怎么审核筛选 KubeCon 议题”、“在 CNCF 工作是什么样的体验"聊到"大家在社区里熟知的人的各种八卦”，欢声笑语不断。 Jeff 和 Jorge 简直是气氛组担当，甚至还聊起了我最感兴趣的 F1 话题（大家一起吐槽丑潘今年又要夺冠了）。
遇到了 Linus Torvalds
这是本次 KubeCon 最意外也是最有意思的经历了。当时 KubeCon 结束后我正准备回酒店，突然发现一个熟悉的身影出现在会场楼下，走进一看，果然是 Linus。 此时大家还没意识到 Linus 的出现，我赶紧上前去搭讪聊了几句，并且留下了珍贵的自拍合影。 感觉 Linus 本人和在网上完全判若两人，全程友好地微笑，跟大家的合影、交谈也是来者不拒，我们聊了他未来几天的行程以及他对这次 Keynote 分享的看法（哈哈，他表示参加这次分享有点被迫营业的意思，但他很久没有出来旅游了，偶尔出趟远门看看也挺不错的）。 没想到 Linus 这么多年仍然在为 Linux Foundation 打工一直没有退休。 没过多久，大家都发现了 Linus，一窝蜂围了上来，我赶紧和 Linus 匆忙告别撤退了。
没想到这辈子能和传奇大佬 Linus 说上话、合影，感觉跟做梦一样。
在最后，非常感谢 Linux 基金会和 CNCF 带给我这么多精彩难忘的经历，我们明年见！