给近半年做的云原生AI算力平台做一个回顾, 思考和实践参考了云溪大会上的分享:为大模型工程提效,基于阿里云 ACK 的云原生 AI 工程化实践[1],全文很长,我这边做一个牵引和解读。
云计算是一种通过互联网的方式按需提供计算资源(如服务器、存储、数据库、网络、软件等)的服务模式, 用户可以像使用水电气一样,按需购买、灵活付费,无需购买和维护物理设备。
特征是① 按需自助服务 ② 广泛的网络访问 ③ 资源池化 ④ 快速弹性伸缩 ⑤ 使用量计费
为什么叫“云计算”? 在冯诺依曼体系中,计算资源是CPU,但我们还是以“计算机”来指代包含计算、存储、网络、软件形成的完整服务器; 在云计算领域,“计算”一次被沿用,将传统计算机核心组件拆开虚拟化、池化,并提供了“用于信息处理所有软硬件要素的总和抽象”。
今天的云计算已经承载了web应用、数据库、大数据、机器学习和高性能计算等计算负载。
面对LLM和GAI这类对算力和数据都有极高需求的新负载,云计算也迎来了“智算”时代, 一方面以服务化资源池的概念提供万卡算力、PB级存储、和单机TB级高速网络互联,另一方面以云原生标准化交付算力给大模型的生产者和使用者。
AI有工程化的要求,同时也对基础设施提出挑战。


最近在做的“AI大模型基础设施”, 宏观目标也是帮助AI工程从小作坊向端到端云原生解决方案演进。

对idc内各种异构计算(GPU、CPU、NPU等)、存储(OSS、NAS、CPFS、HDFS)、网络(TCP、RDMA)资源进行抽象,统一管理和运维和分配,通过软硬协同优化,提供资源利用率。

我们的云原生AI算力平台, 有参考上面的实践,针对企业业务的现状和侧重, 技术调研上做了调整和裁剪。

没有使用kubeflow全家桶,基于现有资源使用了arena、 kubeflow trainer。
kubeflow[2]是一个包含多个开源项目的AI生态组合, kubeflow以Kubernetes为底座,目标是成为部署、扩展和管理AI平台的系统。
在平台侧,我们统一纳管多集群资源,实现了统一调度能力和模型生命周期管理,关联了公司自有的数据存储(涉及数据集预热、模型存储), 这里有一个技术点:Go动态感知资源变更的技术实践,你指定用过!

用户行为的触发点是arena, 我们使用arena提交了训练任务。
ref: Golang 文本模板,你指定没用过!
在调度侧,使用tranning operator和kserve组件,tranning operator 提供统一的训练工作流, kserve提供了将模型以云原生方式部署、扩缩容的能力。
arena产生训练任务/部署动作---> 内部helm形成对应的CRD(pytorchjob、InferenceService)--->控制器监听CRD的变更---> 生成底层资源(deploy/service/network)

各算法团队天然对应租户概念,也就是k8s命名空间, 我们给租户下面每一个用户颁发了一个serviceAccount[3]作为登录和操作凭据。
为实现自动任务调度,我们引入了kueue这样的任务队列组件,在任务被k8s调度器调度之前做准入,kueue成为了异构资源池化、多租户配额、任务排队的技术支撑。
有关kueue的使用,请参考:🎉在k8s调度的花园里面挖呀挖

为适配AI工程化的调度要求,我们使用Koordinator调度器支持了binpack装箱调度。
什么叫binpack, 为什么AI训练需要binpack, 请参考:

最后平台需要管控多渠道的任务,我们使用 informer机制监听了多渠道任务并回显到页面, 这里有个技术点,值得参考。

参考资料
[1]
为大模型工程提效,基于阿里云 ACK 的云原生 AI 工程化实践: https://developer.aliyun.com/article/1414573
[2]
kubeflow: https://www.kubeflow.org/docs/started/architecture/
[3]
serviceAccount: https://blog.miniasp.com/post/2022/08/24/Understanding-Service-Account-in-Kubernetes-through-MicroK8s
🤖 🚀 👑 🛠️ 💡 🌟 🤖 ☕ 🔗 💼 🗣️ 🐳🚜👍🔎😄🌐