跑AI大模型的K8s与普通K8s有什么不同

得益于AI开始火的时候，云原生体系已经普及，所以当前绝大多数的AI底层都是基于Kubernetes集群进行的资源管理（不像大数据，早期大量使用Yarn进行资源管理，在云原生普及后，还得面临Spark on K8s这种云原生改造）。

都知道云原生已经是Kubernetes的天下了，各大领域（大数据、互联网，基因、制药、时空、遥感、金融、游戏等）早已纷纷采纳。那在面对大模型AI火热的当下，咱们从程序员三大件“计算、存储、网络”出发，一起看看这种跑大模型AI的K8s与普通的K8s有什么区别？有哪些底层就可以构筑AI竞争的地方。

计算

Kubernetes是一个在大量节点上管理容器的系统，其主要功能总结起来，就是在想要启动容器的时候，负责“找一个「空闲」节点，启动容器”。但是它默认考虑的启动因素（资源类）主要就是“CPU+内存”。就是容器指定“我要多少CPU+多少内存”，然后K8s找到符合这个要求的节点。

但是，当容器运行需要特殊“资源”的时候，K8s就熄火了。因为它不是认识“GPU”这种异构资源，不知道节点上面有多少“异构资源”（只统计剩余CPU+内存资源）。

K8s自己知道，异构资源千千万，每种使用方法也不一样，自己开发肯定搞不完。比如有RoCE网卡，GPU卡，NPU卡，FPGA，加密狗等等各种硬件。仅单纯的GPU管理，就可以有“每个容器挂1个GPU”，或者“几个容器共用1个GPU”，甚至“1个GPU切分成多个vGPU分别给不同容器用”多种用法。

所以，为了成为一个通用的资源调度系统，它（K8s）搞了个插件框架，来辅助自己判断节点有没有“特殊资源”，叫做 Device-plugin插件。用户需要自己完成这个Device-plugin的开发对接，来实时通知K8s节点上面GPU的使用情况，辅助K8s按需分配GPU算力。

总结就是咱们的AI集群里面，总会有一个GPU的Device-plugin用来辅助GPU调度。例如昇腾、含光等各家自研NPU，就算是最简单的整卡调度，也得带这个DP（Device-plugin）。

如果还需要MIG这样利用vGPU功能来提升GPU的利用率的话，那么Device-plugin插件的实现也会复杂很多。因为A100之前没有提供GPU虚拟化的标准实现，这个就看各家神通了。

其实目的都是大同小异的：就是增强Device-plugin插件逻辑，实现GPU资源的复用（显存+算力隔离），来提升底层GPU整体的利用率。虽然K8s新版本1.27之后，可以使用DRA（Dynamic Resource Allocation）框架实现动态切分，但是当前绝大多数的集群，依然是使用DP完成这个逻辑。

而且，K8s设置的“异构资源”调度框架中，认为资源分配必须是“整数”的，即容器可以要1个GPU卡，但是不能要 0.5个GPU卡。所以想要实现多个容器，共用1个GPU卡的话（自己控制分时用，比如白天容器1用，晚上容器2用，这种性能比vGPU切分后用更好），还得增强DP逻辑（以及调度逻辑，后面会讲）。

最后，异构硬件故障的检测，任务的快速恢复，都需要这个DP的深入参与。

存储

其实Kubernetes集群本身也不管存储，主要管理的是容器“如何接入”存储。通过引入PV和PVC概念，标准的K8s都可以做到将存储挂载至容器中，使得容器里面的程序，像使用本地文件一样的访问远端存储。

在大规模AI训练场景下，样本数据的大小还是很可观的，基本都几百T的级别。所以AI-Infrastructure对存储的要求也会比较高。

更大的区别在于：训练是多轮迭代来逼近目标范围的，因为训练数据量太大，数据无法全部放入内存，在每轮迭代结束后，需要重新从文件系统里读取数据进行下一轮迭代的训。即得重新访问样本进行一轮计算。那么如果每次都重新访问“远程”存储，性能必将大受影响（100T数据，每个epoch重新读一遍OBS桶，你想想那得多慢）。

所以如何将大量的样本数据，就近缓存，就是AI+K8s系统需要重点考虑的问题。分布式缓存加速系统，就是其中一条路线。

常见的有Juicefs，Alluxio等产品，以及各云厂商提供的自研产品。它们的特点是：利用服务器本身就带的高速存储（比如nvme高速本地盘），来缓存样本数据。并提供分布式文件系统，达到就近全量存储的目的。这样在多轮的epoch训练中，可以大幅的提升样本访问速度，加快整体训练进度。

所以建设or使用分布式缓存系统，也是AI平台建设中的重要一环。

网络

在Kubernetes的标准框架里，容器是只有1个网络平面的。即容器里面，只有1个eth0网卡。所以无论是利用overlay实现容器隧道网络，还是underlay实现容器网络直通，其目的都是解决容器网络“通与不通”的问题。

而大规模AI集群中，百亿、千亿级别参数量的大模型通常需要做分布式训练，这时参数梯度等信息要在节点间交换，就需要使用RDMA网络来传递。否则以普通以太网进行传输，其仅仅解决“通与不通”这种入门要求，参数信息传的实在太慢了。

RDMA可以绕过TCP/IP协议栈，并且不需要CPU干预，直接从网卡硬件上开始网络数据传递，网络传输性能可以大幅的提升，大大加快训练参数的交换。

所以咱们的AI集群中，必须要将RDMA网络管理起来，使得所有AI容器可以通过这条路，完成各种集合通信算法（AllReduce等）。

如上图，除了「底部」那条咱们平时看到的容器网络那条线外，顶部还有一个「参数面」网络。一般成本考虑咱们都是走RoCE方案，即用IB网卡+以太网交换机（而不是IB专用交换机）实现。而且由于RDMA协议要求网络是无损的（否则性能会受到极大的影响），而咱们要在以太网上实现无损网络，就需要引入PFC（Priority-Based Flow Control）流控逻辑。

这个就需要同时在交换机和服务器RoCE网卡上，两侧同时配置PFC策略进行流控，以实现无损网络。

可见，「参数面」网络的管理，会比普通主机网络，多一份PFC调优的复杂度。而且，由于NCCL性能直接影响训练速度，所以定位NCCL性能掉速or调优NCCL性能，也是系统必须提供的运维能力之一。

并且RoCE网卡的管理，也属于“异构资源”，也需要开发Device-plugin来告知K8s如何分配这种RoCE网卡。而且GPU和RoCE网卡是需要进行联合分配的，因为硬件连接关系，必须是靠近在一起的配对一起用，如下：

因此，除了「参数面」网络设备的管理分配以外，还得关联调度逻辑来感知这个RoCE网卡的硬件拓扑。

调度

标准K8s集群的容器调度，都是单个容器独立考虑的：即取一个容器，找到其适合的节点，然后取下个容器调度。但是分布式AI训练容器不一样，它们是一组容器。这一组容器，必须同时运行，才可以进行集合通信，即所谓的All_or_Nothing。通常也会叫「Gang Scheduling」，这个是分布式AI场景的强诉求。否则会因为多个分布式作业在资源调度层面出现争抢，导致出现资源维度的死锁，结果是谁都没法正常训练。

因此K8s自带的Scheduler调度器对这种分布式AI训练中的「pod-group」型资源调度就无能为力了。这时K8s提供的「调度插件」框架，又再次发挥作用。用户可以自己开发调度器，集成到K8s集群中，实现自己的容器调度逻辑。

于是，各家又开始整活了。什么Coscheduling，Yunikorn，Volcano，Koordinator，Katalyst等纷纷上线。目的都差不多，先补Gang Scheduling基本功能，再补些MPI等辅助功能。

这里我们以Volcano为例，它除了完成分布式AI训练中「Pod-group」这种容器组的调度，还实现了容器组之间「SSH免密登录」，MPI任务组的「Hostfile文件」这些辅助实现。

小结

Kubernetes云原生管理平台，已经成为AI数据中心的标准底座。由于AI-Infrastructure设备价格昂贵（参数面一根200Gb的网线要7000元，一台8卡的GPU服务器，超150万元），所以提升资源利用率是一个收益极大的途径。

在提升资源利用率方法上，常见有（1）调度算法的增强和（2）业务加速 2种方式。

其中（1）调度增强上，又分Volcano这种pod-group组调度，来提升分布式训练的资源利用率。以及通过Device-plugin来获得vGPU算力切分或者多容器共用GPU卡的方式。

（2）业务加速路径中，也有通过分布式缓存加速数据访问的。以及通过参数面RDMA网络来加速模型参数同步的。

以上这些就是唐老师小结的，与平常使用CPU类业务的K8s集群不太不一样的地方。可见除了Kubernetes本身的复杂性外，要做好AI平台底层的各项竞争力，还是需要投入不少人力的。