云原生AI算力平台实战：从GPU调度到配额与稳定性治理

1. 为什么这个阶段我需要重新审视算力平台

先说结论：云原生AI算力平台不是把GPU塞进Kubernetes就完事了，也不是装个调度器就能宣称“云原生”。我过去大半年一直在和这套东西打交道，从最初只有几个算法工程师手动申请机器，到现在平台承载训练、微调、推理、Agent编排等多类负载，中间踩过的坑、推翻过的设计，比写业务代码多得多。这篇阶段性解读，就是把这段过程里沉淀下来的东西整理出来，给正在搭或者准备搭同类平台的团队一些参考。

先说个背景。最开始我们的AI基础设施其实很原始：几台裸金属GPU服务器，谁要用就在文档表格里填申请，管理员手工分机器。算法同事拿到机器后自己装驱动、配虚拟环境，训练脚本跑完机器就闲置在那儿。模型多了之后问题开始集中暴露：有人要A100跑大模型预训练，有人只要一块3090调模型，还有人跑数据预处理根本不需要GPU；机器利用率长期在20%上下，但每次申请新卡都要走采购流程，周期一长业务就卡住。

当时团队内部吵过一轮：要不要引入Kubernetes？反对意见很直接——搞K8s本身就有学习成本，AI训练任务又不像Web服务那样天然适合容器，GPU的调度、显存隔离、多卡通信都是绕不开的硬骨头。但后来促使我们下决心的，不是技术趋势，而是一个很现实的问题：算力已经变成了组织内的共享资源，必须有明确的分配规则、排队机制和计量手段，否则永远在“谁嗓门大谁先跑”。

IOE架构时代的经验在这里其实没太多直接可迁移的东西，但有一个思路是通用的：当资源从“物理独占”变成“逻辑共享”，系统的设计重心就从“怎么把机器用好”转向“怎么把规则定清楚、把故障隔离好、把成本算明白”。云原生这套东西之所以合适，是因为它天然提供了资源抽象、声明式编排、弹性扩缩容和多租户隔离的底座，AI工作负载在上面只是另一种类型的应用。

这篇解读不会讲太多入门概念。我假设你已经知道Pod、Deployment、StatefulSet这些基础词，也大概听过GPU Operator。我更想聊的是平台真正跑起来之后遇到的事：调度器选型为什么反复推翻、配额系统怎么做才不会把用户逼疯、混合负载挤在一起时怎么保证训练不被推理任务饿死、以及哪些“看起来很重要”的设计其实根本不值得做。这些都是有实际场景支撑的，不是概念推演。

顺便说一句，这篇内容里提到的数据和参数，有的是我们实测的，有的是通用经验值，我在写的时候会标注清楚。如果你拿到的环境和我差异很大，别直接照搬，当成参考坐标用。

2. 从裸金属到Kubernetes：算力纳管的第一个分水岭

2.1 为什么默认的K8s调度器管不了GPU

把GPU接入Kubernetes，第一步通常是用NVIDIA Device Plugin暴露资源。这条路本身没问题，真正的问题是：默认调度器根本不理解“GPU卡”这种资源，它只知道数字。

举个例子。我在节点上声明了nvidia.com/gpu: 8，调度器就知道这台机器有8个单位的GPU资源。但当你申请nvidia.com/gpu: 1的时候，K8s不关心你用的是不是同一张卡，也不关心这张卡的显存、算力、驱动版本。于是出现了一个经典场景：两个Pod都被调度到了同一台8卡机器上，一个只用2GB显存，另一个把剩余显存全占了，结果后者启动直接OOM。

更麻烦的是多卡训练任务。你用Horovod或者PyTorch DDP跑分布式训练，每个Worker需要独占一张卡，而且最好在同一台机器上通过NVLink通信。如果调度器只是机械地分配资源，两个分布式训练任务的Worker可能被分配到不同机器，跨机通信的带宽损耗直接让训练速度打折。

所以，光有Device Plugin是不够的，你需要一个懂“GPU拓扑”的调度层，至少得知道：哪些卡在同一台机器上、它们之间的互联方式是NVLink还是PCIe、显存总量多少、卡的使用率怎么样。

2.2 调度器选型：Volcano还是Kueue还是自研

调度器选型这块，我们前后试过三条路线，不是每条都成功，说出来供你参考。

第一版直接用了K8s默认调度器加Device Plugin，结果就是上面说的拓扑混乱和资源碎片问题。训练任务经常被拆得七零八落，8卡机器可能只被用掉3张卡，剩下的要么显存不够跑大模型，要么和别的任务抢带宽。这段经历让我对“默认方案”有了敬畏心：K8s的默认调度器是为微服务设计的，不是为HPC负载设计的。

第二版用Volcano。Volcano的gang scheduling（成组调度）解决了一个关键问题：分布式训练任务的所有Worker必须要么全部调度成功、要么全部等待，不能出现“4个Worker起来了，另外4个没资源”这种半吊子状态。它还支持队列和优先级，可以把不同团队的任务放在不同队列里做配额管理。Volcano在AI场景里确实成熟，很多大厂的训练平台底层都是它。

但Volcano也有自己的问题。它的API设计偏HPC风格，队列、PodGroup这些概念和K8s原生风格有差距;和Kueue这类较新的项目相比，Volcano的弹性配额管理要弱一些。我们后来因为要支持大批短任务（比如数据预处理、超参调优的单个试验），Volcano的队列模型显得有些重。

第三版，也就是现在的方案，是用Kueue加自定义调度插件。Kueue做的是“工作负载级别的队列管理”——它不管你Pod怎么调度，只管一个Job什么时候可以被放行、放行几个。我们把Volcano的队列概念拆掉，用Kueue的LocalQueue和ClusterQueue来做配额和优先级，再用自定义调度插件处理GPU拓扑和显存感知。这个组合灵活很多，但代价是自定义逻辑变多了，调度器出问题的时候要自己排查。

选型这件事我给不了你一个“标准答案”，只能说几条实际经验：

• 如果你的团队主要是分布式训练，上手Volcano最稳，社区资料多，踩坑半径小。
• 如果你的负载很杂（训练、推理、批处理都有），又想保留K8s原生的体验，Kueue值得花时间认真评估。
• 自研调度插件是把双刃剑，最好在标准组件确实卡住你的时候再做。

2.3 异构算力的纳管细节

异构这个词，我们在实际环境里指三层东西：不同厂商的GPU（NVIDIA、国产加速卡）、同一厂商不同型号（A100、A800、4090）、以及完全不需要GPU的纯CPU任务。

NVIDIA系列是最好处理的，GPU Operator一把梭，驱动、Device Plugin、DCGM监控全给你装好。国产加速卡就比较费劲了，有的有Device Plugin，有的只给一个裸驱动，你必须自己写资源上报逻辑；还有的卡对Kubernetes版本的兼容性有问题，升级集群之前要先验证。

我们把异构纳管的核心放在了一套“节点标签规范”上，每个节点都打上三层标签：

• gpu.vendor：厂商，比如nvidia、iluvatar、cambricon
• gpu.model：具体型号，比如A100-SXM4-40GB
• gpu.memory：显存大小，比如40Gi、80Gi

然后在调度插件里写了一个简单的“资源匹配规则”：用户申请的时候可以指定型号或显存，调度器先把候选节点限定在标签匹配的范围内，再按可用的GPU整数卡数筛选。不指定就按默认型号池分配，方便快速试验。

这样做以后,至少解决了两个实际问题：一是用户不用记住每台机器是什么配置，平台按标签自动分；二是国产卡和NVIDIA卡可以共存，各自有资源池，互不干扰。缺点是标签体系要维护，新机型上线时忘了打标签，调度器就会一直找不到可用节点，这种问题通常很隐蔽。

3. 配额与核时体系：把“抢卡”变成“计费”

3.1 配额设计的第一原则：先让用户算得清账

我们被配额问题折磨了很久。最开始用的是最简单的做法：每个团队固定分几张卡，管理员手动改配置。这么做的问题很直观——有的团队卡闲着，有的团队不够用，而且谁也没法说清楚“我的卡到底用在了哪里”。

后来我们想明白一件事：配额的意义不是限制，而是让算力变成可计量的资源，让每个使用者对自己的消耗有感知。 如果用户连自己用了多少算力都查不清楚，任何配额制度都会显得像在针对人。

这一阶段的核心理念，是引入“核时”作为统一计量单位。为什么不用“卡时”？因为不同型号的GPU算力差异太大，一张A100跑一小时和一张4090跑一小时，价值完全不一样。我们按基准算力折算：

• 1核时 = 1 vCPU + 1GB内存，持续运行1小时
• 一张4090卡时 = 折合 12 核时
• 一张A100-40GB卡时 = 折合 30 核时
• 一张A800-80GB卡时 = 折合 54 核时

换算比例不是拍脑袋定的，我们参照了各种卡在典型训练任务（ResNet、BERT、LLaMA系列）上的实际吞吐差异，按“完成一个标准化任务所需时间”来算。这样用户在对比不同方案时，可以直接说“跑这个实验大概要消耗多少核时”，而不是纠结“我有几张卡”。

3.2 配额预冻结机制：为什么会出现“冻结时间5.00 min，折合1.33核时”

说到配额，就不得不提“预冻结”这个我们踩了不少坑才做对的设计。字面意思理解，就是任务在排队等待时，先把预计消耗的资源配额冻结住，避免用户同时提交多个任务导致超额占用。

有个真实场景可以说明问题。一位算法同事提交了一个GPU训练任务，但当时资源池里没有空闲卡。系统提示：“GPU配额已不够预冻结，冻结时间5.00 min，折合1.33核时。”他一开始很懵：明明任务是“排队中”，为什么配额被冻结了？冻结时间不是排队时间吗？

这里有个关键逻辑：配额冻结和任务排队是两回事。 队列中的任务已经提交给平台了，平台要为它预留资源配额——也就是说，在你之后提交任务的人，就算有空闲卡，也可能因为你的任务优先占用了配额而排在你后面。这个“预冻结”动作，本质上是在做资源承诺。

具体计算方式是这样的：

code复制预计冻结配额 = 预估运行时长 × 每小时配额消耗

比如一个任务预估跑2小时，使用1张4090卡（折合12核时/小时），那么预冻结配额就是24核时。系统在队列中等待了5分钟，这5分钟也会被折算成消耗（1.33核时），因为任务在等待期间已经占用了调度系统的处理能力——虽然GPU没跑，但调度器、监控、存储连接都在工作。

这个设计后来被我们改进成了**“冻结上限”机制**：为了防止长队任务把所有配额都冻结住，导致后到的短任务永远无法插队，我们给每个队列的冻结配额设置了上限，比如不超过总配额的30%。短任务可以走“快速通道”占用剩余配额，避免了配额被长任务“压死”的情况。

3.3 多级配额与组织架构的映射

我们把配额体系设置成了三级结构：

• 集群级配额：整个平台总共有多少核时，通常是物理资源上限的保守估算。
• 组织级配额：按部门或项目组划分，比如算法A组、算法B组、数据组各占多少比例。
• 用户级配额：个人用户的消耗上限，防止单个人把团队资源耗尽。

三者关系是逐级嵌套的：用户消耗记入组织，组织消耗记入集群。做这个映射时最大的坑，是“部门”这个边界在组织架构变动时非常不稳定。我们后来改成按项目标签（project=xxx）而不是按部门来划分配额，因为项目是相对固定的，部门经常调整。

4. 训练、推理、Agent负载的混合调度实践

4.1 三类负载各自的“性格”

算力平台上线半年后，我们面对的负载已经变成三类：分布式训练、在线推理、AI Agent及批处理任务。它们对调度系统的要求完全不同，我把它们的特征整理成一个表格，方便对照：

你会发现，训练任务和推理任务在调度上是天然冲突的：训练要“独占”，推理要“随时可用”。Agent任务则是“缝缝补补”——它什么资源都能用，但量特别大、特别碎。如果平台只管训练不管推理，GPU利用率会很高但不稳定；如果只服务在线推理，很多训练任务又会因为排队被饿死。

4.2 把资源池切出三层

为了兼容这三类负载，我们最终放弃了“全局一个大池子”的设计，改成三层资源池：

第一层是“训练池”，物理上独占大部分高性能卡（A100/A800），采用预占用策略，任务提交就冻结资源直到训练结束。这一层的核心指标是“训练性价比”，宁可利用率低一点也要保证训练任务稳定性，因为断一次大模型训练的代价可能需要按小时算钱。

第二层是“推理池”，卡相对低配但数量多，采用预留加弹性的策略。在线推理服务常驻占有一部分卡，为的是应对突发流量；另外留了一部分卡专门给“突发扩容”用。推理池的设计重点是自动伸缩——根据请求量指标，在30秒内快速拉起或回收Pod。

第三层是“弹性池”，使用训练池空闲的卡和CPU节点，专门跑Agent任务、数据预处理、超参搜索这类短任务。弹性池的优先级最低，一旦训练任务需要资源，弹性池里的Pod会被抢占。

这个三层结构不是一开始就设计好的，是踩了几次“推理任务把训练任务饿死”的坑之后才改的。之前我们把所有任务混在一个池子里，结果在线推理服务为了保持响应速度，占住了大量GPU卡，训练任务排队长达几小时。后来加了优先级和抢占，但K8s默认的抢占是“杀掉低优先级Pod让位给高优先级”，对训练任务来说这种操作代价太大——训练中断后要重新加载数据、重新初始化通信域，损耗巨大。所以最稳妥的方案还是物理隔离资源池，从源头上避免冲突。

4.3 Agent负载给调度系统出的难题

AI Agent相关的负载，我们在做平台的初期完全没有考虑到。Agent任务的典型特点是：大量短生命周期任务，由Agent框架自动发起，频繁调用推理API或执行工具调用，单个任务的资源占用很小，但任务数量可能是传统负载的几十倍。

这个特点给调度器带来了元数据风暴问题。Pod创建和销毁的频率太高，Kube-scheduler的API Server压力陡增，etcd的写入量也在涨。我们曾经遇到过几百个Agent任务同时创建Pod，直接把API Server的CPU打满，影响了其他所有任务。

为了应对这个问题，我们做了一些针对性调整：

• 把支持Agent短任务的节点单独划到弹性池，配置更短的Pod终止宽限期，快速回收资源；
• 对Agent任务的Pod做批量提交，减少API Server的调用次数；
• 在Agent框架层限制并发Pod数量，默认一个Agent的任务并发不超过10个，防止失控。

这里最反直觉的一点是：Agent任务的调度策略，反而要把“效率”放在“质量”前面。 一个Agent任务跑失败了，Agent框架会自己重试或者让大模型换个策略，你不需要调度器做太多重试保障;但如果你为了保障短任务而配置了过于复杂的调度规则，反而可能拖慢整个系统的吞吐。

5. 稳定性治理：算力平台真正开始“像产品”的一步

5.1 三个典型的稳定性事故

算力平台在上线初期，稳定性问题比功能问题更闹心。我有三段比较典型的“事后复盘”，分享出来，你看能不能帮你避坑。

第一个是GPU显存泄漏导致的整节点雪崩。当时有个团队在推理池上部署了一个新模型，服务发布后第一天的表现正常，但第二天节点的可用显存逐步下降，先是可用GPU从8张变成7张，然后半小时内8张卡全部变成不可调度。排查后发现是推理框架在每次请求时没有正确释放CUDA context，导致显存越积越多。这个问题的教训是：平台的监控必须包含“每张卡的显存使用趋势”，而不只是“节点是否可用”。 我们后来加了显存使用率的24小时趋势图，并配置了阈值告警，卡在显存使用率超过95%且持续10分钟时自动将节点标记为“不参与新调度”。

第二个是抢占机制误杀在线服务。前面提到弹性池可以抢占优先级低的Pod，但有一次系统误判了Pod的优先级，把运行中的推理服务实例当成弹性任务给杀了，导致线上请求大量超时。后来我们把优先级改成“写在Pod模板里，且不能通过运行时参数覆盖”，并且把推理服务的PriorityClass单独设置为最高级别，和弹性任务完全隔开。这里想说的是：K8s的优先级机制非常灵活，但也非常危险，任何抢占规则在真正上线前，一定要做一次“把所有PriorityClass放在一起跑一遍”的演练。

第三个是镜像拉取风暴。模型训练任务经常要用一个包含数据和代码的镜像，这个镜像有20GB。当50个训练任务同时启动时，50个节点同时从镜像仓库拉取同一个大镜像，直接把仓库带宽打满，所有任务的启动时间从5分钟拖到了40分钟。解决方案是引入P2P分发组件（类似Dragonfly的思路），让已经有镜像的节点充当临时源，其他节点从邻居拉取。镜像仓库的带宽压力瞬间消失，任务启动时间恢复正常。

5.2 成本治理：从“资源利用率”到“每单位有效计算成本”

算力平台做到后期，问题的焦点已经不是“资源够不够”，而是“资源用得好不好”。我们用了一个聚合指标来评估成本效益：每核时产出的有效实验结果数量。

这个指标很朴素：平台消耗了多少核时，这些核时里有多少真正跑完了有价值的训练/推理过程。我们统计后发现，早期的浪费主要集中在三处：

• 试验性任务空跑：很多人提交了一个训练任务，结果结构和参数写错了，跑到一半才发现，浪费了配额。我们加了“任务启动自检”机制，在正式训练前用一小批数据跑一个微型冒烟测试，5分钟就能发现大部分参数错误。
• 推理服务过度预留：为了怕突发流量，很多推理服务常驻了远超实际需求的卡数。我们通过一段时间的流量分析，发现推理池的平均利用率不到30%，于是把常驻卡数调低，靠突发扩容保障峰值。
• 排队任务占着资源等数据：有任务申请到了GPU，但要等数据加载完成（可能几分钟）才开始训练，GPU在等待期间是纯浪费。我们优化了数据预取逻辑，让数据在任务排队期间就提前下载到节点本地缓存。

5.3 值得做与不值得做的“好想法”

最后总结一点踩坑心得。在做平台的过程中，有很多“看起来很有价值”的设计，实际做下来却是低效甚至有害的：

不值得做的：

• 全套自定义UI界面。前三个月我们花大力气做了好看的前端控制台，后来发现用户更愿意直接在终端跑命令，控制台只用来查账单和看监控。
• 过度复杂的调度策略。凡是你需要用一整篇文章向用户解释的调度规则，大概率用户根本不理解，反而觉得系统“有毛病”。
• 自行开发显存虚拟化。GPU显存共享是很多团队的梦想，但搞了三个月后我们发现，大部分任务并不需要，需要的任务自己会用MPS或者vCUDA方案。

值得做的：

• 完善的可观测性。算力平台最核心的产品能力其实是“让用户知道自己跑的任务到底发生了什么”。日志、监控、事件、计费数据，四类数据打通，会大幅降低用户的沟通成本。
• 合理的默认策略。给80%的场景设计默认方案，不要试图让用户自己去摸索。比如默认超时时间、默认资源申请模板、默认镜像仓库地址。
• 一套灵活的配额即时调整工具。配额管理不是设置完了就不动的，你要让管理员能快速响应“临时要加几百核时跑一个紧急任务”的需求。我们做了一个命令行工具，管理员一句话就可以调整某个队列的配额上限，整个调整在30秒内生效。

最后，说一点个人体会

算力平台这种东西，做的时间越长，越觉得核心技术难点不在某个单独组件上，而在“如何让不同需求的用户共享一套基础设施，同时每个人都不觉得自己被亏待了”。这本质上是个资源治理问题，而不是一个性能优化问题。Kubernetes、Volcano、Kueue这些工具只是载体，真正的平台能力体现在你对用户行为的理解、对成本模型的构建、对故障响应的机制上。

如果在所有这些经验里只能保留一条，我会留下这个：一开始就把“计量”机制想清楚——核时、配额、成本分摊必须从第一天做起，哪怕粗糙一点。 因为资源只要变成了共享的，人和人之间就会开始比较消耗，而比较的前提就是有统一的账。很多团队在搭建平台时优先做调度、做GPU纳管，计量体系往后拖，等拖到用户开始问“为什么他的额度比我多”的时候，再回头补账本，成本就高得多了。