做选型调研这件事最怕的不是技术选项多而是业务目标没想清楚就一头扎进对比清单里。我自己在做算力调度平台的前期调研时花了两周时间筛方案最后发现真正影响决策的往往不是某个调度器性能强多少而是团队现有技术栈、GPU资源规模和业务对排队时延的容忍度。这篇先聊技术选型阶段的思路和取舍后续再展开架构设计和落地细节。1. 先想清楚算力调度到底在解决什么问题算力调度平台这个名字听起来很宏大但落到实际场景核心就是一句话把多用户、多团队对GPU资源的请求以合理的方式分配到有限的异构算力节点上。这个问题在深度学习训练普及之前并不突出因为单机单卡或者单机多卡基本能覆盖需求但到了大模型时代一个训练任务要吃几十张卡而且可能跨节点情况立刻变复杂了。1.1 算力调度的核心矛盾我见过不少团队一开始就把问题想大了直接对标云厂商的调度系统结果做了一堆用不上的功能。其实算力调度的核心矛盾就三个资源不够分总有团队的训练任务排队但买卡不是无限预算碎片化严重有人申请8卡但集群里只有3张空闲卡和5张空闲卡分散在不同节点优先级难定训练任务、调试任务、推理任务混在一起谁先跑谁后跑需要规则而不是拍脑袋这三个矛盾决定了调度平台的设计取向。如果只是内部小团队用几十张卡优先级明确其实不需要很重的平台写脚本分配足够。但如果是给多个业务线、多个团队共用几百卡以上的集群就必须有一个自动化的调度层。1.2 选型前的三个前置问题在打开任何技术对比文档之前我建议先回答三个问题回答清楚了再选型第一算力规模多大10张卡和1000张卡的技术方案完全不同。小规模用裸K8s加大纲调度就能跑大规模必须考虑队列、抢占、分时复用、拓扑感知这些东西。第二业务形态是什么是纯训练还是训练推理混合训练任务特征是长稳、占用大、不能随意中断推理任务特征是短、波动大、时延敏感。两者的调度策略差异很大。第三团队技术栈是什么如果团队对K8s已经滚瓜烂熟选Volcano或Kueue会顺理成章如果团队原来是玩HPC出身对Slurm更熟那也许应该考虑Slurm或者混合方案。技术栈迁移成本往往比调度器本身的差异更影响落地速度。我把这三个问题的答案写进了一页需求文档所有后续对比都围绕这三个点来收窄范围避免被各种花哨功能带偏。2. 主流调度方案全景对比目前业界做GPU算力调度的主流方案大致可以分四类原生K8s调度增强、专业调度器、云厂商托管调度、HPC调度器跨界。每一类都有自己的适用边界。2.1 原生K8s调度器和它的局限Kubernetes原生调度器本身支持节点亲和、Pod亲和反亲和、资源请求与限额这些能力但直接用原生调度器做GPU训练任务调度很快会撞到三堵墙第一堵墙是GPU拓扑感知缺失。原生调度器不关心多卡训练任务需要NVLink全连接它只知道某个节点有8张卡但不会区分这些卡之间是走NVLink还是走PCIe。模型并行或数据并行任务如果被分到PCIe互联的卡上通信瓶颈会直接拉低训练效率。第二堵墙是批量调度能力弱。训练任务经常是AllReduce架构要求所有worker同时就绪才能开始。原生调度器逐个Pod调度如果某个Pod一直Pending整个任务就一直卡着没有群调度的概念。第三堵墙是队列和优先级体系太简单。原生只有PriorityClass没有复杂的队列策略多团队共享集群时配额和公平性很难管理。所以裸K8s只适合小规模、单团队、任务简单的情况。真要作为多租户算力调度平台底座必须在上面加一层。2.2 专业调度器Volcano与Kueue的对位分析调度器圈子里早期比较热的是Volcano它是CNCF的孵化项目诞生于华为的AI计算场景后来在MindSpore、TensorFlow、PyTorch等框架的训练任务调度中大量落地。Volcano带来的是真正的群调度能力比如Gang调度、队列管理、任务优先级抢占这些都直击训练任务的痛点。后来Kueue出现它是K8s官方社区主导的作业级调度器设计思路更优雅。Kueue本身不做Pod级别调度而是在K8s之上加了一层队列和配额管理把“资源预占”和“队列等待”分开来处理。你可以把它理解成调度策略的前置网关协同默认调度器工作。这两者在实际选型时并不是互斥关系。我在调研中看到不少团队是Volcano和Kueue混用的Kueue负责队列配额和全局公平性Volcano负责批量任务的Pod调度细节。这个组合前期调研下来体验最好后面讲方案选型时会单独说。2.3 HPC调度器与云原生方案的边界还要提一下Slurm这一类传统HPC调度器。Slurm在超算中心、科研机构的统治力极强支持复杂的作业依赖、节点分配、时间策略。有些做AI平台的老牌厂商底层调度器确实是Slurm改的。Slurm玩起来很成熟但它和云原生的技术栈融合得不好。容器化和微服务演进之后K8s生态的扩展性、开发者体验、可观测性都明显占优。新建平台如果没有历史包袱我不太推荐直接上Slurm。除非团队本身就是HPC背景或者有大量MPI作业要管那另说。把这几个方向整理成一张对比表方便团队沟通时快速对齐维度原生K8sVolcanoKueueSlurm调度粒度PodPod/作业作业作业群调度不支持支持支持支持队列管理弱强强强GPU拓扑感知无有无有云原生适配原生优秀优秀一般离线训练支持一般优秀优秀优秀生态活跃度极高高高高这张表并没有绝对的好坏关键看业务目标。如果团队已经有K8s平台Volcano或Kueue是上手成本最低、扩展性最好的选择。3. 确定方案选型为什么组合拳更靠谱经过上面的对比我最终把调研方向锁定在VolcanoKueue的组合方案上。这里要说明这不是一个非此即彼的选择题它们的分工完全不同。3.1 Volcano要解决的问题Volcano存在的核心意义是群调度。什么叫群调度拿直观的例子说一个PyTorch训练任务需要4个worker每个worker是一个Pod。如果集群只剩3个Pod的资源那么第4个Pod申请不到整个任务其实无法启动。原生K8s会把这个任务的前3个Pod调度起来跑着第4个一直等待但实际上前3个跑起来也是白跑浪费资源还占着位置。Volcano的Gang调度策略会在所有Pod资源都满足后才一次性调度不会发生这种“半启动”状态。对训练任务来说这个能力是保命的否则资源浪费和任务卡死会让运维团队焦头烂额。Volcano还自带队列和优先级体系可以配置多个队列每个队列有各自的容量配比和调度权重。这种设计很符合多团队共享集群的场景算法团队一个队列数据团队一个队列谁也不干扰谁。还有一个容易忽略的点是Volcano对异构设备的支持。它原生适配GPU、NPU这类资源并且能把设备型号作为调度维度。比如作业申请中指定A100就不会被调度到V100节点上。这个能力在没有设备插件做二次开发时特别有用。3.2 Kueue解决的优先级不一致问题Kueue的切入点和Volcano不一样它更像一个前置的作业治理层管的是“进不进集群”的问题而不是“进集群后放到哪里”的问题。举个例子两个团队同时提作业甲团队配额是60%乙团队配额是30%Kueue会根据队列配置决定每个作业进入调度器的顺序。它不允许超出配额的任务进入调度逻辑避免资源争抢和互相饿死。Kueue还支持本地队列和集群队列的两级管理。本地队列可以给一个小团队用多个本地队列归属于一个集群队列。这在组织架构上非常灵活平台管理员配置集群队列每个业务团队内部自己管理本地队列谁优先谁排队不用事事找平台管理员。我发现Kueue在和中大型训练任务配合时能有效减轻底层调度器的压力。大量作业拥塞在入口时Kueue先做一轮粗粒度过滤只有获得准入的作业才进入调度器底层的负担小很多。3.3 组合方案的协作逻辑组合使用时顶层是Kueue管队列和配额中间是Volcano管群调度和任务优先级底层是K8s原生调度器管节点选择。这个架构的分层非常清晰每一层只干自己擅长的事。遇到策略类需求比如改一下公平算法或配额计算就改Kueue配置遇到调度类需求比如增加新的GPU调度算法就改Volcano插件平台的稳定性好很多不会动不动就要升级底层K8s。这套组合在实际落地时也有问题要留意。两个调度器同时存在需要确保Kueue的AdmissionCheck和Volcano的调度流程不对冲突。一般是把Kueue作为总入口Volcano作为执行器K8s原生调度器放在最后兜底。配置时要小心不要抢占对方的管理对象否则会出现作业被Kueue接受了但Volcano却不调度的情况。4. 开发配套控制台和API层的重要性选型调研不能只看调度器本身配套的API层和用户界面会直接决定平台是否好推广。调度器技术再强如果用户要用起来很麻烦那业务团队大概率还是自己写脚本直接往集群上丢Pod平台会被绕过。4.1 用户中心的设计思路平台的上层用户不只是算法工程师还有平台管理员和团队负责人。三种角色对平台的需求完全不同算法工程师要的是提交任务、看日志、看监控、看状态、重启任务、拿结果。最好一键提交别让填一堆不懂的参数。团队负责人要的是看本团队的配额使用比例、队列里有几个任务排队、预计什么时候能跑完、哪些人最占资源。平台管理员要的是配置节点组和队列、设置配额、看集群水位、节点健康、全局哪台机器在空转、哪个团队的资源浪费最多。这三层信息分别对应三层界面不能揉在一起。调研阶段我就把控制台原型画出来了用来检验调度器选型是否满足用户心智。比如如果选原生K8s调度器没有队列概念那团队负责人的配额管理界面就做不出来方案直接打回。4.2 API层设计对调度器选型的反向影响调度器决定了下层能提供什么语义API层决定了下游用户怎么触达这些语义。在调研时我重点关注了几组API提交作业API必须屏蔽底层是Volcano还是Kueue用户只需要传框架类型、镜像、卡数、优先级平台内部翻译成对应的CRD状态查询API要能区分排队、创建、运行、失败、重试这些状态同一下层状态可能有多种业务状态API要做语义映射配额查询API要能查询集群配额和本地配额两级信息同时展示已用、预占、空闲三档数据操作类API取消、抢占、重排队这些动作底层不同调度器支持程度不同API层要统一封装API层设计的核心目标是用户不感知调度器差异。我见过有平台把Volcano的PodGroup概念直接透出给用户文档里写一堆Volcano特有的术语算法工程师看了直接迷糊。在调研阶段就要明确所有底层调度器概念都在API层做转换不向外暴露。4.3 可观测性选型中常被低估的一环调度器只是资源分配的大脑而可观测性是看大脑有没有想清楚的镜子。选型时要注意调度器自带指标的能力以及和Prometheus、Grafana的集成难度。Volcano自带Exporter能暴露排队任务数、调度成功/失败次数、队列资源使用率这些关键指标开箱即用。Kueue也提供各个队列的ResourceManager状态指标。这些指标直接关系到控制台的水位监控。如果调度器不带指标意味着全部自己埋点工作量会翻倍。我在调研时专门做了一个可观测性验证启动一个测试集群装上Prometheus看调度器能不能自然吐出一套完整指标。不能的打叉。做到这一步选型调研的大框架基本就结束了。还需要把最后一部分内容补上GPU共享和分时复用的考量以及选型阶段常见的坑这些都是实际调研中最容易被忽略的细节。5. GPU共享与分时复用的取舍算力调度平台绕不开的另一个话题是GPU资源利用率。很多团队总感觉卡不够用但其实真实跑起来的GPU利用率很低教育训练和调试阶段长时间占用又不出活。于是调度平台经常会考虑加入GPU共享和分时复用能力这部分在选型阶段就要有结论。5.1 时间片与显存切分两种技术路径NVIDIA vGPU和MIG技术提供了两条硬件维度的切分路径而软件层方案比如K8s和容器运行时层面的time-slicing实现走的是另一条路线。先说时间片方案。它允许一个物理GPU承载多个容器多个任务轮流使用整卡的计算单元。实现相对简单NVIDIA官方和社区都有插件支持。优点是灵活性高一个任务空闲计算资源时另一个任务可以顶上。缺点同样明显任务之间会争抢算力训练性能可能剧烈波动。如果一个任务跑大模型训练另一个跑推理碰到一起时训练时间可能拉长30%以上这个波动对生产训练是不可接受的。再说显存切分。MIG目前在A100、H100这些卡上支持能把一张物理卡切分成多个实例每个实例有独立的显存和计算单元。隔离性比时间片好很多但限制是MIG实例数量上限固定、切分粒度不够灵活、并且一旦开启MIG整张卡只能用于MIG实例不能再跑完整任务。调研时要做一个简单的决策推理类负载和短时开发环境适合用共享方案追求高吞吐长时生产训练任务是绝对不能开时间片的宁可让它独占。如果团队只有物理卡且部署的框架支持MIG那优先考虑MIG。如果卡型号老不支持MIG那就只能用时间片过渡并且要在平台层明确标注哪些任务共享、哪些独占。5.2 共享能力对调度器选型的影响启用GPU共享后调度器的资源模型要跟着调整。原来一张卡是一个可分配单位现在一张卡可能被分成多个实例调度器需要感知这些实例的拓扑和占用状态。Volcano在这块相对友好它扩展了资源名和调度策略能把设备插件上报的类似nvidia.com/gpu.shared这种资源纳入调度。而Kueue对这种细分资源的感知能力较弱它更擅长管理整卡粒度的配额。调研结论是GPU共享肯定要搞但只限定在某些场景并且要在调度层面对共享资源做独立标记。最简单的方法是创建一个共享资源池把时间片或MIG切出来的资源放到一个单独的节点池中通过标签区分。训练任务默认不调度到这里只有开发任务和推理任务才能使用。这样既可以避免共享导致训练性能抖动又能提升整体利用率也不用把调度器的资源模型搞得过于复杂。6. 调研阶段踩过的坑与提醒最后整理几个选型调研中容易踩的坑都是实际遇到过才明白的经验。6.1 别被官网文档的指标带偏很多调度器的文档会强调性能指标比如调度吞吐量、调度延迟。这些指标在统一基准测试中很漂亮但真实场景往往不适用。因为我们面对的是几十个到几百个任务而不是几万个任务的超大规模所谓调度吞吐量差异根本感知不到。真正影响体验的是队列等待逻辑和资源抢占机制是否合理这些案例只能通过真实场景模拟才能发现。我在调研时做了两个模拟场景一个是一百个任务同时提交打爆资源池另一个是高优先级任务插队。跑完这两轮方案的好坏基本就区分出来了。官网Benchmark只能作为初筛参考模拟场景才是决策依据。6.2 调度策略与业务SLA的匹配有的平台在选型时过于关注调度器本身却忽略了业务SLA的差异性。训练任务和推理任务对调度时延的容忍度完全不同。开发调试任务可以排队但推理服务必须快速启动。调度器处理这种混合负载时需要有优先级抢占机制。如果没有一个高优任务启动时底层缺资源就只能在队列里等着可能严重影响线上推理服务SLA。选型时要明确平台规划的混合负载比例是怎样的调度器是否支持抢占抢占粒度是作业级别还是Pod级别这些都要有明确答案。6.3 控制台和调度器的迭代节奏调研阶段容易忽略调度器和控制台之间的迭代依赖。控制台会潜移默化地影响调度器需要暴露的接口能力。比如控制台要展示每个队列的任务排队时长历史曲线调度器就必须暴露每个任务的排队时间戳且API要保留历史查询能力。如果不提前把控制台需求和调度能力对齐后期接口补全会非常痛苦。我的习惯是边调研边画原型把控制台原型中的每个功能点反推回调度器做一张对照表逐项确认是否支持下层实现。这张对照表在整个平台上线前都会成为开发排期的重要依据。7. 选型调研阶段的最终整合思路等到以上问题都调研完基本可以形成一个完整的选型结论报告了。报告不必太长但要能回答决策委员会或团队的核心疑问。我当时是按这个目录组织的业务背景与目标资源规模方案候选集的筛选逻辑组合架构与各层职责描述控制台及API能力的原型与调度器的对应关系GPU共享策略的适用范围模拟场景的测试结论风险点与备选方案报告的关键是有明确的建议结论而不是把各方案优缺点罗列一遍让上层做阅读理解。决策者需要的是“选什么、为什么、有什么代价、什么情况下这个选择不成立”这几件事而不是一份五十页的对比分析表。选型调研本身不是一个纯技术评估的过程它同时受组织架构、团队技能、业务SLA多方面影响。方案没有绝对优劣只有匹配度高低。把需求边界划清楚把决策依据摆明白调研报告才能真正成为项目启动时的可靠底座。