企业官网建设流程全解析

一万张 GPU 的排班问题，远比排队打饭复杂得多

有算法同学问我：我提交的训练任务在集群里等了二十分钟，到底在等什么？为什么明明有 GPU 空闲，我的任务还是卡在 PENDING？

这种问题几乎每天都会出现。训练框架（PyTorch、DeepSpeed 这些）管的是"代码怎么跑"，而调度器管的是"你的代码到底什么时候能跑、在哪些 GPU 上跑"。当一个集群规模走到万卡级别，调度器就是这个训练场里真正发号施令的人，它决定谁先用显卡、谁往后靠、谁的任务要被迫让位。它不产生训练收益，但它决定整个集群的产能上限。

这一篇我把自己的经验梳理成几个核心维度：调度器到底在解决什么、核心机制有哪些、主流方案之间的差异性，以及实际运营上万卡集群时的那些坑。内容偏实践向，适合正在搭集群、或者被集群排队折磨的人读。

1. 调度器解决的问题，不是一个字"排"那么简单

先说一个反直觉的结论：调度器不是在"分配 GPU"，而是在做资源的时间切片和空间排列。一万张 GPU 听起来很多，问题是一万张卡不是一整块，它们分布在几百台机器上，每台机器有 8 张卡，机器之间又有不同的网络带宽。你的任务需要几卡、需要哪些卡在一起、需要多大显存、需要跑多久，调度器都要在毫秒级做出判断。

1.1 一个训练任务提交之后，后台到底发生了什么

拿一个典型的 PyTorch DDP 任务举例。你执行python -m torch.distributed.run --nproc_per_node=8 train.py，训练框架会申请 8 张 GPU。如果是在单机上跑，操作系统帮你搞定一切；但在集群上，你面对的是一堆节点，调度器的第一个动作是找合适的节点。

这个"合适"有三个维度：

• 数量匹配：你要 8 张卡，一台机器正好有 8 张空闲，这是最好的情况。
• 显存匹配：你的模型需要 40GB 显存，机器上有的是 32GB 的卡，给你也没用，必须按需匹配。
• 网络匹配：你要做分布式训练，8 张卡如果横跨两台机器，就需要走高速网络（比如 RoCE 或者 InfiniBand）。如果集群里高速网络端口不够，调度器还要考虑"尽量不跨机"。

我刚接触集群调度时以为调度器就是"看哪个节点空闲就把任务扔过去"，实际远没有这么简单。调度器要把整个集群抽象成一个资源池，每个节点定期上报自己的状态：总显存、已用显存、空闲卡数、网络带宽、GPU 型号。调度器收到任务请求后，在这个资源池里做匹配。

1.2 万卡集群的调度本质是两个人的协作

一个训练集群的正常运转，需要两个"人"配合：

• 任务方（训练框架）负责把训练任务拆碎：DDP 把数据并行到多张卡，每个进程处理一份 batch，然后互相同步梯度。任务方知道自己需要多少资源。
• 资源方（调度器）负责在多个任务之间做取舍：你手头有三个任务，一个要 512 卡跑大模型，一个要 16 卡调参，还有一个要 64 卡做数据并行微调。全部同时跑？资源不够。让跑 16 卡的先上？大模型的 512 卡任务进度立刻被打断，谁更亏？

这两方的"目标函数"还不一样：训练框架永远想尽快拿到更多资源，而调度器要兼顾所有任务的公平性和整个集群的吞吐量。这个矛盾就是我在标题里说的"隐形的老板"——它总在替你做你不想面对的取舍决策。

在这个协作模型里，调度器更像是一个"操作系统进程调度器"的放大版本：进程调度管的是 CPU 时间片，集群调度管的是 GPU 资源分片。但放大到网络层面后，复杂度指数级上升。CPU 的进程切换是微秒级，网络传输和分布式训练的资源调度要做到秒级响应，而且一次判断错误可能导致整个训练任务失败，损失以小时计。

2. 调度器的三个核心能力：队列、优先级和生命周期

很多想自研调度器的人第一个版本只做了"资源匹配"：有空闲就分配，没空闲就排队。跑起来才发现，队列管理、优先级、生命周期管理才是真正打磨的地方。

2.1 排队不是"谁先来谁先跑"，而是动态博弈

当你提交一个训练任务，它进入调度队列。队列不是简单的 FIFO（先来先服务），否则一个跑 72 小时的大任务会把所有人堵死。

大多数训练集群采用多级队列的设计：

• 短任务队列：跑实验、跑 eval、数据处理，任务时间预计在 40 分钟以内。调度器会尽量优先安排，因为这些任务通常"人等机器"，等太久实验人员就阻塞了。
• 训练任务队列：正式训练，动辄数天到数周。调度器会保证它有足够的资源连续性。
• 服务队列：推理服务或在线任务，对延迟敏感，一旦调度就不能随意抢占，因为在线服务的 SLA 不允许训练任务干扰。

真实调度器里队列之间还有权重。比如短任务队列权重高，但每个短任务最多只能拿 N 张卡；训练任务优先级低但是独占性好。队列设计的目的很明确：不同任务吃的是不同的资源特征，用一套策略管所有任务，最终就是既让大任务吃不饱，也让小任务饿死。

我之前遇到过一个典型槽点：把离线训练和在线推理放在同一个队列，结果某次训练任务做大规模 checkpoint，磁盘 IO 打满，在线推理的延迟从 10ms 飙到 2 秒。后来强制分离队列，各自限流，问题才解决。队列不只是排队，还是隔离。

2.2 优先级和配额，谁也不能无限抢占

多级队列解决的是任务分类，但同一个队列里"谁先跑"还需要优先级。

优先级系统通常分两层：

1. 用户/项目配额：每个部门、每个项目组在集群里有一个资源配额上限。比如 A 组配额 2000 卡，B 组配额 5000 卡。调度器保证配额的存在，防止某个组把资源全部占光。
2. 任务优先级：同配额内，任务有高、中、低三级。高优先级任务可以挤占低优先级任务。

但这里有个非常微妙的点：为什么不能只用配额把任务隔离开，还要做抢占？

因为配额是静态的，任务却是动态的。A 组的 2000 卡配额 60% 处于空闲状态，B 组的 5000 卡已经排了很长的队。这时候如果严格按配额，A 组空闲卡就浪费了。所以调度器要允许一种"借资源"的机制：B 组可以临时使用 A 组的空闲配额，但一旦 A 组有高优任务提交，B 组的任务需要能被抢占（preempt）释放资源。

抢占机制是调度器里最危险的部分。一个训练任务被抢占，不只是"暂停等一下"，而是直接杀掉进程，中间的显存状态全部丢失，模型权重回到上一个 checkpoint。如果 checkpoint 频率是一个小时，被抢占就意味着浪费一个小时。所以调度器要做的不是单纯抢占，而是根据 checkpoint 的进度来决定"现在可以杀谁"。

这个机制做得好不好，直接决定了用户对集群的信任程度。频繁被抢会导致用户抗拒使用集群，宁可自建小规模的资源孤岛。所以大规模调度器里的抢占，一般都配置了"最小保护时间"——一个任务跑起来之后，至少给两小时稳定运行时间，不让它刚启动就被抢占。

2.3 生命周期管理：从提交到回收的完整链路

调度器从头到尾管着一个任务的完整生命周期：

• 提交：用户提交任务定义，包括镜像、启动命令、资源需求、运行时间上限。
• 排队：等待调度器分配资源。
• 运行中：任务绑定 GPU 之后，调度器持续监控健康状态。
• 结束/失败：正常结束则回收资源，失败则判断是否需要重启，同时保留日志。

这里有个容易忽略的环节是冷启动时间。集群里有几千个任务同时排队，调度器要负责把镜像从镜像仓库拉取到计算节点。如果一个镜像有 10GB，几百个任务同时启动就可能把镜像仓库的带宽打爆。为了优化这个环节，很多集群会做镜像预拉取——节点空闲时就把常用镜像缓存好，任务提交后直接复用，冷启动时间从十几分钟压缩到几十秒。这个功能通常不是调度器核心，但实际使用体验差异巨大。

3. 调度器内部的关键算法：从资源匹配到 Gang 调度

调度器的核心说白了是一套资源规划算法。我按照实战中遇到的复杂度从低到高来说。

3.1 最基本的资源匹配：Binpack 还是 Spread

一个节点上有多张 GPU，调度器分配时会面临两个策略选择：

• Binpack（装箱）：尽量把任务集中到少量节点上，让其他节点空出来。好处是省电（空节点可以关机），而且大任务来了更容易找到整块的空闲区域。
• Spread（分散）：把任务尽量分散开。好处是单个节点的故障影响面小，坏处是节点碎片化，比如 8 台机器每台只剩下 1 张卡，但一个任务要 2 张卡，就因为不连续而无法调度。

真实场景里两种策略都要用：小任务用 Binpack 把它们堆到一起，大任务用 Spread 避免互相争抢网络带宽。调度器需要动态评估两种策略的利弊，这就是"编排"的核心含义。

3.2 拓扑感知：不是所有 GPU 都是平等的

这是新手做调度器最容易忽略的维度。一个 8 卡节点内部，GPU 之间的连接方式是 NVLink 和 PCIe 的混合拓扑；两个节点之间走的是网卡和交换机。对训练任务来说，通信开销直接决定扩展效率：

• 同一个节点内 8 卡使用 NVLink 通信，带宽可以达到 600GB/s。
• 跨节点通信走 RoCE（比如 200Gbps 网络），实际有效带宽远低于 NVLink。

所以调度器分卡时要考虑"通信拓扑亲和性"。同样是分配 8 张卡，从同一台机器上分 8 张，和从两台机器上各分 4 张，性能差异可能超过 30%。一个合格的调度系统需要维护整个集群的拓扑图：哪个 GPU 在哪个节点，节点之间有几跳网络，哪些节点共享同一个 leaf 交换机。调度的时候不仅算资源够不够，还要算通信成本。

具体到实现，调度器会维护一张分层视图：集群 → 机架 → 节点 → GPU。分配任务时优先在最小层级内完成。NCCL 的NCCL_P2P_LEVEL和NCCL_TOPO_DUMP_FILE就是用来查看和调整通信路径的，但真正好用的方式是调度器直接把任务安排在拓扑内聚的节点上，从源头减少跨机通信。

3.3 Gang 调度：要么全部给我，要么我全都不要

这是训练集群调度区别于普通服务的核心特性。普通微服务扩缩容是"有多少资源就启动多少实例"，训练任务不行——一个数据并行任务需要 N 个进程同时跑，任何进程缺失都导致训练卡住。

这种"要么全有要么全无"的分配方式叫Gang Scheduling。一个 128 卡的任务，必须等 128 张卡全部就绪才能启动。如果只凑到 127 张，任务就一直在等待，那 127 张卡也处于"被预订但未使用"的状态，造成资源浪费。

这个问题在大型训练任务上尤其突出。我记得有一次集群资源碎片化严重（每台机器剩下 3-4 张卡），而排在队首的是一个需要 128 卡的大任务。小任务进不来，因为大任务把资源都预订了；大任务凑不齐，因为资源太碎。这就是经典的"头阻塞"问题。

业界主流的解法有两个：

1. Backfill 机制：大任务等待时，允许小任务临时使用它预订的资源，但要保证在大任务资源凑齐前小任务能结束（或者可以被抢占）。
2. 时间片切分：调度器规定一个"等待周期"，大任务在周期内无法凑齐资源则让位给小任务，避免无限期占位。

Volcano 调度器里对这两个都有支持，job.minAvailable配合job.queue来标记 Gang 调度。但真正的难点是"backfill 进来小任务是否会影响大任务启动时间"这个判断逻辑，需要调度器对任务运行时长做精确预估。

3.4 抢占机制的实现细节：优雅终止比强杀重要

当一个高优先级任务进入队列，调度器要"抢"资源时，什么时候触发、选谁下手、怎么下发指令，每个环节都有技术讲究：

• 触发条件：高优任务排队超过阈值（比如 5 分钟），调度器才会触发抢占。
• 选择被抢占对象：优先选择 checkpoint 频率最高的任务（损失最小），然后再看优先级最低的那个。
• 下发方式：调度器不是直接 kill 进程，而是发送 SIGTERM 信号，让训练框架有机会做"优雅退出"——保存当前状态、释放显存、上传日志。如果超过宽限期（通常 60 秒）还没退出，再发 SIGKILL。

这里我最想强调的是：一定要留好优雅退出的逃生门。很多用户训练脚本没有注册 SIGTERM 信号处理器，被抢占就等于直接丢进度，这个体验非常糟糕。调度器至少要保证被杀的任务有足够时间把日志和 checkpoint 保住。

4. 主流技术选型：Slurm、Ray、Volcano 和自研平台的取舍

调度系统领域没有万能的银弹。不同技术栈有各自的适用边界，我在实际项目中踩了不少坑，这里把几套主流的方案拉一起复盘。

4.1 Slurm：老牌 HPC 调度器，可靠但设计偏批处理

Slurm 是学术圈和高性能计算领域使用最广的调度器。它把任务当作"批处理作业"来管理，稳定性极高，一套 Slurm 集群跑几年不出大事是常见的。

优势：

• 成熟稳定，大规模部署案例多，生态文档齐全。
• 原生的 Gang 调度（scontrol show job里能看到 job 的节点分配状态）。
• 对网络拓扑敏感度不高，HPC 领域本来就是强关联的专用网络。

局限：

• 对 GPU 任务的资源抽象相对粗糙，主要靠--gpus参数和 GRES 插件来管理，显存维度管理能力弱。
• 对弹性伸缩支持差，训练任务运行过程中不能动态加减卡。
• 对长时间运行的分布式训练任务支持一般，尤其是涉及动态组网的任务（比如 PyTorch elastic 模式）。

如果团队主要做传统 HPC 或者简单的小型训练，Slurm 可以快速上线。但大型 AI 训练集群用它，调度策略上会有不少挑战。

4.2 Ray：训练/推理一体化的弹性调度器

Ray 从开发之初就是为分布式 Python（尤其是机器学习负载）设计的，不是一个通用的集群资源管理器，但它天然适合训练和推理混合的场景。Ray 的调度强调"对象存储 + 任务图"的运行模型，每个任务把数据输入输出定义为分布式对象。

优势：

• 对 Python 生态非常友好，和 PyTorch 深度集成，跑 DDP 任务的时候 Ray 可以直接拉起每个 rank 的进程。
• 弹性扩缩容能力极强，ray autoscaler可以按需申请和释放云上节点。
• 任务优先级队列内置于ray.remote的num_cpus/num_gpus调度器中，开发者不需要额外学习一套作业描述语言。

局限：

• 调度策略相对简单（内置于 GCS，统一调度），超大规模（上万节点）的调度性能可能成为瓶颈。
• 高可用方案部署复杂，Ray 自带 GCS（Global Control Store）如果挂了，整个集群调度就停了，需要额外做容灾。

Ray 更适合做"AI 应用开发的统一运行时"，但如果你要把一个庞大的内部集群管好，通常还是要套一层自己的资源管控组件。

4.3 Volcano + Kubernetes：云原生时代的主流组合

Kubernetes 原生调度器不擅长批处理和 Gang 调度，于是出现了 Volcano 这类扩展调度器。Volcano 是 CNCF 项目，专门为 AI/大数据工作负载服务，在调度框架层面实现了 Queue、PriorityClass、Gang scheduling。

优势：

• 和 Kubernetes 生态无缝集成，镜像管理、存储编排、网络策略全部复用 K8s 能力。
• 调度策略可做插件化定制（比如自定义插件实现 binpack/拓扑感知）。
• 资源可视化管理比 Slurm 好，K8s Dashboard 和 Metrics Server 直接展示资源使用情况。

局限：

• K8s 本身是面向长跑服务的系统，批处理任务在 K8s 里的生命周期管理逻辑（如 job 失败重试、超时清理）不如 Slurm 直观。
• 大规模集群里 K8s 的 API Server 和 etcd 会成为短板，K8s 万节点集群需要非常多调优。
• 调度性能和抢占策略的复杂度，在极大规模下同样是个坑。

我推荐的中型团队方案是 K8s + Volcano：业务能拿到云原生的整体收益，同时 Volcano 的调度语义对 AI 场景的适配度足够高。但如果已经有一套 Slurm 在跑，就没有必要强行迁移。

4.4 自研调度平台的常见误区

见过不少中大型公司走上自研调度器的路，结果价值没做出来，反而陷入维护泥潭。总结下来，常见的误区有三个：

1. 过度强调抢占和优先级，忽视了链路稳定性。一个调度器最重要的能力是"无论如何都不把集群搞死"。
2. 调度器变成数据库。系统里存了太多的任务元数据、用户自定义字段和审计日志，性能被拖垮，真正调度决策时反而变得迟钝。
3. 缺少故障演练。调度器挂了怎么恢复？有没有备份调度器？很多系统只有一台调度节点，挂了全都趴窝。

如果你要自研，我强烈建议在第一版就考虑好：调度器本身无状态化、任务状态的持久化放外部存储、调度决策逻辑必须可以随时重建。也就是调度器本身可以挂，但集群状态不会因为调度器挂掉而丢失。

5. 运营经验分享：调度器上线之后的真实挑战

前面讲的是原理和选型，最后这一部分我想讲讲调度器上线之后真正考验人的地方。调度器的开发工作可能只占 30%，剩下 70% 都是日常运营中的问题定位、策略调优和用户沟通。

5.1 从"调度成功"到"训练不慢"之间，还有很长的路

很多团队误以为"调度成功=任务开始跑=万事大吉"。实际上，调度器的指标不能只看"分配成功率"，最关键的指标是训练实际吞吐量。

我之前排查过一个案例：任务成功调度到 64 张 GPU 上，但训练速度只有预期的 40%。排除了代码、存储、网络问题之后，最后发现是调度时把任务的 8 个 rank 分散到了 4 个不同机架上，训练通信的跨机流量远超预期。虽然调度器保证了"资源够"，但完全忽视了"通信路径最短"这个要求。

所以调度器设置完策略以后，要持续收集训练任务的性能指标：每次迭代耗时、通信耗时占比、吞吐量。一旦指标异常，就要把调度方案和训练性能关联起来分析。这套可观测性体系的建设，和调度器本身同样重要。

5.2 碎片化问题的真实处理过程

碎片化是每个训练集群的头号问题。我处理过一次相当严重的碎片危机：集群合计空闲约 1000 张 GPU，但每天排队超过 4 小时的用户很多，因为他们要的都是 64 卡、128 卡的整块资源。

排查发现碎片主要来源于三类：

1. 小任务长时间占卡：一些 4 卡的调参任务一跑就是 3 天，期间机器剩余 4 卡被占死，128 卡的训练任务永远凑不齐。
2. 节点故障未完全隔离：节点上报只有 6 卡可用，另外 2 张卡因为异常被屏蔽，但这些"残网"没有自动归并，导致整个节点的剩余容量利用率极低。
3. 模型新版本显存需求变大：旧任务要求 40GB 显存，新任务要求 60GB 显存，集群里 40GB 和 80GB 的卡混布，资源碎片直接翻倍。

针对这些问题，我做了两组策略调整：一是对卡时长短的小任务启用"抢占后可迁移"策略，被抢占之后自动把状态迁移到另外的空闲节点续跑；二是对节点做"容量归一化"——通过池化技术把同型号 GPU 划到一个逻辑池，调度的时候尽量让任务在池内完成。效果是单集群的 GPU 利用率从 46% 提升到 68%。这个提升在万卡规模下，等于是凭空多出来两千多张卡。

5.3 调度器挂了怎么办：故障演练的必要性

调度器自身的容灾设计，在开发初期很少有人认真对待。我第一次做集群故障演练的时候，直接手动 kill 掉了调度器主进程，结果整个集群长达 15 分钟无法提交任何任务，排队中的任务全部超时。新提交的任务因为没有调度器响应，直接卡在 PENDING。

这个问题解决起来并不难，关键是提前做好设计：

• 调度器要能快速重启，并从持久化存储恢复队列状态。
• 已经运行中的任务不受调度器重启影响（避免任务被误杀）。
• 调度器重启期间，新任务可以先落到持久化队列，等调度器恢复后继续调度。
• 多副本部署或者主备切换，真正具备自动 failover 能力。

这套设计做完再演练，故障恢复时间可以压到 1 分钟以内，用户几乎没有感知。不过这里想提醒一下：一定不要只在测试环境演练，生产环境的负载特征、任务分布和测试环境差距很大，建议最初几次演练选在线业务间歇期做。

5.4 训练框架和调度器的配合细节

好的调度器不是"分配完资源就消失"，而是要能和训练框架产生化学反应。目前实测下来，PyTorch 生态和调度器的配合要注意几个细节：

• DDP 的初始化机制：DDP 用torch.distributed.init_process_group通过环境变量MASTER_ADDR和MASTER_PORT做通信初始化，调度器要保证每个 rank 都能正确拿到这些信息。
• torch.cuda.set_device：调度器给任务分了物理 GPU 序号，但 PyTorch 默认从 0 号开始用。如果任务跑在 GPU 4-7 上，而脚本没有os.environ['CUDA_VISIBLE_DEVICES']做映射，就会出现显存不够的报错。调度器要为每个任务注入正确的CUDA_VISIBLE_DEVICES环境变量。
• checkpoint 与抢占的配合：更好的做法是在框架侧每隔固定步数把当前模型权重、优化器状态写到共享存储。调度器触发抢占时，优先选中距离上次 checkpoint 时间较短的任务，把它的损失控制到最小。

这里可以沿着Pytorch 安装教程 GPU、DDP 分布式训练这些方向进一步展开，核心思想就是：调度器的资源抽象能力要能平滑对接到框架的资源消费方式，否则调度器分配得再漂亮，训练代码跑不起来也是白搭。

5.5 资源的"超额分配"还是"实时测度"

最后再补充一个新思路：资源调度里一直存在"静态分配"和"动态利用率"的拉扯。

很多训练任务申请了全部显存，但实际运行中 GPU 计算利用率只有 30%（比如数据加载跟不上）。此时调度器如果严格按"已申请显存"来判断节点是否饱和，就会造成大量资源整体闲置。后来我引入了 GPU 利用率的实时监控指标，对于利用率低的节点，允许调度器超额分配一部分任务，等 GPU 真正吃紧时再触发抢占换出。

这套"基于实际使用率而非申请量"的调度策略，在混合负载（训练+推理+数据处理）场景下收益非常明显，但风险也成倍增加——一旦某个任务突然"吃饱"，其他任务可能因为抢不到 GPU 而停滞。所以针对超额分配任务，我会额外设置一个兜底策略：所有超额任务都可以被无条件抢占，且被抢占时自动把进度保存好，重新排队续跑。

6. 调度器给不同角色的参考建议

聊了这么多机制和坑，落到实际应用层面，不同角色面对的调度器问题是不同的。我最后按角色给一些偏实操的建议。

6.1 如果你是算法工程师

别再把调度器当成一个"黑盒"来抱怨。你至少要把这几个概念搞清楚：你的任务被分配到了哪台机器、是哪个队列在服务你、你的任务有没有设置合理的运行时长上限、你是否注册了优雅退出信号。这些了解清楚之后，你的任务排队时间和被抢占概率都会有明显下降。

特别建议：在训练脚本里加上 SIGTERM 的捕获处理逻辑，哪怕只是保存一个简单的训练状态标记，也比裸奔强得多。你永远不知道集群运维哪天调了抢占策略。

6.2 如果你是平台/运维工程师

建设调度器之前，最先要建设的是监控和可观测性。具体来说，至少要覆盖这些维度：

有了这套指标，你要做任何策略调整才有依据，而不是"我觉得小任务优先级该提高"这种拍脑袋决策。

6.3 如果你在考虑训练和推理的混合调度

目前很多平台把训练集群和推理集群完全分开，这是非常简单粗暴的做法。推理集群在凌晨到上午通常会有大量空闲 GPU，而训练任务恰恰在那个时间段往往有排队需求。

混合调度的前提是：推理平台有完善的弹性伸缩组件、训练任务能容忍"被抢占后重排"。如果这两个前提满足，混合调度带来的利用率提升相当可观。我的建议是初期采用"隔离优先、少量混部"的策略，让一小批对延迟不敏感的推理任务和训练任务混跑，跑通之后再逐步扩大。

6.4 关于"调度器是隐形老板"这个说法的个人体会

回到开头那个比喻。我在这个领域做了几年之后，越来越觉得调度器在集群里的角色确实像一个"隐形老板"：你不用直接向它汇报工作，但你的任务什么时候能开始、能跑多久、能拿到多少资源，都是它说了算。和老板相处的正确方式不是抱怨它不公平，而是理解它的决策逻辑，优化自己的行为来获得更好的资源配置。

对调度器开发者来说，要明白自己做的不是一个资源分配组件，而是一个"在冲突中做取舍"的系统。一万张 GPU 的排班问题，终极目标不是让每个任务都立刻运行——这在数学上就不可能。调度器的目标是让整个集群的产出最大化，同时尽量保证公平性。理解了这个目标，很多设计决策都会有明确的方向。

下次你的任务又在队列里等了二十分钟，不妨想想：那个"隐形老板"正在权衡的，可能是好几个团队、几十个训练任务、几千张卡之间的复杂博弈。你要是能顺着它的逻辑优化自己的任务提交方式，也许就能成为拿到最多资源的那个人。