多租户AI训练基础：多租户概念、AI训练任务特点与资源分配挑战
在深入调度策略之前，必须先厘清三个基础问题：什么是多租户？AI训练任务与普通云上应用有何本质区别？为什么资源分配在多租户场景下会变得异常困难？本章将逐一拆解，为后续的调度算法与实操打下概念基础。
2.1 多租户概念：从“共享”到“隔离”的连续谱
多租户（Multi-tenancy）并非简单的“多个人用一台机器”，而是一种资源所有权与使用权的分离架构。在AI训练平台中，租户通常是一个部门、一个项目组或一个外部客户，每个租户拥有独立的命名空间、配额、权限策略和计费维度。
需要特别强调的是，多租户不是非黑即白的“隔离/不隔离”，而是一个连续谱。按隔离强度从低到高，常见形态包括：
| 形态 | 隔离粒度 | 典型场景 | 资源效率 |
|---|---|---|---|
| 软隔离（共享池） | 仅配额限制，无硬性资源边界 | 内部研发环境、低优先级实验 | 高（资源可超卖） |
| 硬隔离（分区池） | 节点/GPU卡级独占 | 生产训练、SLA保障任务 | 中（碎片化明显） |
| 物理隔离（独立集群） | 整集群独占 | 合规要求高的金融/医疗客户 | 低（运维成本高） |
实际生产环境往往是混合形态：核心训练任务跑在硬隔离分区，而数据预处理、超参搜索等短任务跑在软隔离共享池。理解这一点，是设计调度策略的前提——调度器必须能感知不同租户的隔离等级，而不是一刀切地按“公平”或“效率”单一维度分配。
2.2 AI训练任务特点：与微服务截然不同的资源画像
AI训练任务（尤其是深度学习训练）的资源需求模式，与传统的无状态微服务有本质差异。忽略这些差异，直接套用通用调度器（如默认的Kubernetes调度器），必然导致效率低下或任务失败。
2.2.1 长时运行与状态持久性
单个训练任务可能持续数小时到数周，且训练过程中的模型权重（checkpoint）必须持久化保存。这意味着调度器不能像对待Web服务那样随意迁移或重启任务——一次意外驱逐可能导致数小时的计算成果丢失（除非配置了频繁的checkpoint，但那是另一笔I/O开销）。
2.2.2 同步并行与集体通信
分布式训练（如TensorFlow的PS架构或PyTorch的AllReduce架构）要求多个GPU/节点之间进行高频同步通信。以AllReduce为例，每步迭代都需要所有worker完成梯度聚合，最慢的worker决定整体速度（木桶效应）。因此，调度器必须保证分配给同一任务的资源在拓扑上尽量靠近（如同一机架、同一交换机），否则网络延迟会直接转化为训练吞吐的损失。
2.2.3 资源需求的异构性与动态性
一个训练任务内部，不同角色的资源需求不同：
- Parameter Server（PS）：网络I/O密集，CPU和内存需求高，GPU需求低。
- Worker：GPU计算密集，显存需求大。
- Evaluator：周期性运行，资源需求波动大。
更复杂的是，训练过程中的显存占用并非恒定——批量大小（batch size）、模型结构、数据流水线都可能影响实际显存峰值。调度器如果只按“申请值”分配，会造成大量浪费；如果按“峰值”分配，又可能因超卖导致OOM（Out of Memory）崩溃。
2.3 资源分配的核心挑战：多目标冲突下的权衡
多租户AI训练的资源分配，本质上是一个多目标优化问题，且这些目标之间往往互相冲突。以下是生产环境中最常见的四组矛盾：
2.3.1 公平性 vs. 效率
严格按租户配额比例分配（公平）可能导致GPU碎片化——例如租户A需要4卡，但只剩3卡空闲；而租户B的任务只需1卡，却占着2卡配额。反之，为了效率允许租户间抢占，又可能引发“噪声邻居”问题，导致SLA任务性能抖动。
2.3.2 优先级 vs. 饥饿
高优先级任务（如线上紧急模型修复）需要插队，但如果调度策略设计不当，低优先级任务可能长期得不到资源（饥饿）。业界常用抢占式调度（preemption）解决，但被抢占任务的checkpoint频率、重启成本必须纳入考量。
2.3.3 资源亲和性 vs. 碎片消除
为了通信性能，调度器倾向于把任务的所有GPU放在同一节点（亲和性）。但这会加剧碎片化——一个节点有8卡，一个任务要6卡，剩余2卡可能因无法满足其他任务的“整卡”需求而闲置。反之，跨节点分散放置虽然能利用碎片，却牺牲了通信效率。
2.3.4 弹性伸缩 vs. 稳定性
AI训练任务支持弹性扩缩容（如根据loss收敛情况动态调整worker数量），但频繁扩缩容会导致：
- 通信拓扑重建的开销（重新建立AllReduce环）
- 数据加载的重复（新worker需要重新读取数据集）
- 学习率调度（learning rate schedule）需要重新调整
因此，调度器必须设定最小伸缩步长和冷却时间，避免系统震荡。
2.4 典型场景：一个真实的多租户训练平台资源视图
假设某公司有3个租户：算法部（A）、数据科学部（B）、外部客户（C）。集群共有32张A100 GPU，分布在4台节点（每台8卡）。
初始状态：
- 租户A：配额16卡，当前使用12卡（节点1的8卡 + 节点2的4卡）
- 租户B：配额8卡，当前使用4卡（节点2的2卡 + 节点3的2卡）
- 租户C：配额8卡，当前使用0卡
- 空闲：节点3剩余4卡，节点4全部8卡（共12卡空闲）
此时租户C提交一个需要8卡的任务，调度器面临选择：
方案1：将节点4的8卡全部分配给C（满足亲和性，通信最优）
方案2：将节点3的4卡 + 节点4的4卡分配给C（碎片利用，但跨节点通信）
若选择方案1，节点3的4卡将闲置，未来租户B若要扩容到8卡，只能使用节点3的4卡 + 节点4的4卡（跨节点），性能受损。
若选择方案2，租户C的任务通信效率下降约15%-20%（取决于模型大小和网络带宽）。
这个例子说明，没有绝对正确的分配方案，只有基于当前集群状态和未来预测的“较优解”。这也是为什么现代调度器（如Volcano、Kueue）引入了队列（Queue）和弹性配额（Elastic Quota）机制——允许租户间临时借用空闲资源，但保证在对方需要时能够回收。
2.5 常见误区与复盘
配额（Quota）只是上限，不是预留。如果租户A的16卡配额在凌晨闲置，而租户B的任务急需资源，合理的调度器应该允许B临时借用。但很多平台因为配置了静态配额，导致资源白白闲置。正确做法是启用“弹性配额”或“借用/回收”机制，并设置借用时限。
训练任务需要读取数据集。如果调度器把任务分配到与数据存储（如Ceph、HDFS）网络距离较远的节点，每次epoch的数据加载时间可能增加数倍。调度时必须考虑数据缓存位置、存储节点带宽等因素，而不仅仅是GPU资源。
小规模的微调任务（如LoRA）与大规模预训练任务（如千卡级LLM训练）的资源需求模式完全不同。前者启动快、生命周期短，适合用“尽力而为”的调度；后者需要长期稳定占用，必须用“预留+保障”的调度。一个调度器无法同时优化两种极端场景，需要分层设计。