做选型调研这件事，最怕的不是技术选项多，而是业务目标没想清楚就一头扎进对比清单里。我自己在做算力调度平台的前期调研时，花了两周时间筛方案，最后发现真正影响决策的往往不是某个调度器性能强多少，而是团队现有技术栈、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作业要管，那另说。
把这几个方向整理成一张对比表，方便团队沟通时快速对齐：
| 维度 | 原生K8s | Volcano | Kueue | Slurm |
|---|---|---|---|---|
| 调度粒度 | Pod | Pod/作业 | 作业 | 作业 |
| 群调度 | 不支持 | 支持 | 支持 | 支持 |
| 队列管理 | 弱 | 强 | 强 | 强 |
| GPU拓扑感知 | 无 | 有 | 无 | 有 |
| 云原生适配 | 原生 | 优秀 | 优秀 | 一般 |
| 离线训练支持 | 一般 | 优秀 | 优秀 | 优秀 |
| 生态活跃度 | 极高 | 高 | 高 | 高 |
这张表并没有绝对的好坏，关键看业务目标。如果团队已经有K8s平台，Volcano或Kueue是上手成本最低、扩展性最好的选择。
3. 确定方案选型：为什么组合拳更靠谱
经过上面的对比，我最终把调研方向锁定在Volcano+Kueue的组合方案上。这里要说明，这不是一个非此即彼的选择题，它们的分工完全不同。
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多方面影响。方案没有绝对优劣，只有匹配度高低。把需求边界划清楚，把决策依据摆明白，调研报告才能真正成为项目启动时的可靠底座。
