📚 课程目录第2章基础知识

基础知识：分布式系统、集群架构、资源调度与负载均衡的基本概念

2.1 分布式系统的本质特征

在深入AI算力集群之前，必须先厘清“分布式系统”这一底层概念。分布式系统并非简单地把多台机器连在一起，而是一组通过网络通信、协同完成同一目标的自治计算机集合。对于外部使用者而言，它应当表现为一个单一的、连贯的系统。理解分布式系统，需要抓住三个核心特征：

并发性：多个节点同时运行，共享或竞争资源，任务之间存在交错执行的可能。
无全局时钟：各节点有自己的本地时钟，事件先后顺序无法依靠物理时间精确判定，必须依赖逻辑时钟或向量时钟。
故障独立性：任何节点都可能随时失效，而其他节点无法提前感知，系统必须将故障视为常态而非例外。

这三个特征直接决定了资源调度与负载均衡的复杂性——调度器无法假设节点永远健康，也无法依赖一个中心化的时间基准来协调所有任务。

  关键认知：分布式系统的核心难点不在于“如何连接”，而在于“如何在不完美条件下达成全局一致”。AI训练任务动辄数百GPU卡协同工作数天，任何一个节点掉队都会拖慢整体进度，这正是分布式调度要解决的首要矛盾。

2.2 集群架构的基本形态

集群（Cluster）是将多台服务器组织起来，对外提供高可用、高扩展服务的技术方案。在AI算力场景中，集群架构通常分为三种典型形态，每种形态对调度器的要求截然不同。

架构类型	典型场景	调度特点	代表系统
共享式集群	多团队共用GPU资源池	需要配额管理、抢占策略、公平性保障	Kubernetes + 自定义调度器
专用式集群	单一大型训练任务独占	需要gang scheduling（成组调度）、拓扑感知	Slurm、PBS Pro
混合式集群	在线推理 + 离线训练混合部署	需要优先级抢占、弹性伸缩、资源隔离	Volcano、YARN

无论哪种架构，集群中每个节点都需要向调度器上报自身的实时资源状态，包括GPU利用率、显存占用、网络带宽、磁盘I/O等。调度器维护一张全局资源视图，并根据这张视图做出分配决策。这张视图的新鲜度直接决定了调度质量——视图越陈旧，调度决策越可能失效。

2.3 资源调度的核心机制

资源调度本质上是一个多目标优化问题：在满足任务资源需求的前提下，最大化资源利用率、最小化任务完成时间、同时保证公平性。AI集群中的资源调度需要经过以下关键步骤：

资源建模：将节点资源抽象为可量化的维度（GPU卡数、显存MB、CPU核数、内存GB），并定义任务的资源请求规格。
任务排队：当资源不足时，任务进入等待队列，调度器按照优先级、FIFO或公平策略决定出队顺序。
节点筛选：从所有节点中过滤出满足任务资源需求的候选节点（Feasible Check）。
节点打分：对候选节点进行多维度评分，如资源碎片最少、数据本地性最优、散热条件最好等。
绑定与启动：选定最优节点后，调度器将任务绑定到该节点并触发启动流程。

# 一个典型的GPU任务资源请求示例（Kubernetes风格）
resources:
  requests:
    nvidia.com/gpu: 8        # 请求8张GPU卡
    cpu: 32                  # 请求32个CPU核心
    memory: 256Gi            # 请求256GB内存
  limits:
    nvidia.com/gpu: 8
    cpu: 32
    memory: 256Gi

调度器 vs 资源管理器：调度器（Scheduler）负责“决定任务跑在哪里”，而资源管理器（Resource Manager）负责“跟踪资源被谁占用”。两者通常协同工作，但在某些系统中（如Slurm）二者合二为一，在另一些系统中（如Kubernetes）则分离部署。

2.4 负载均衡的层次与策略

负载均衡与资源调度是互补但不同的概念。资源调度发生在任务启动前，解决“任务应该放在哪里执行”；负载均衡则贯穿任务运行过程中，解决“流量和负载如何在节点间动态分配”。在AI集群中，负载均衡至少包含三个层次：

网络流量层：将外部请求均匀分发到多个推理服务实例，避免单一实例过载。
计算负载层：监控各节点的GPU利用率、队列长度，将新增任务调度到最空闲的节点。
数据负载层：确保数据分片在各节点间分布均匀，避免部分节点成为数据热点。

常见的负载均衡策略包括：轮询（Round Robin）、加权轮询（Weighted Round Robin）、最少连接数（Least Connections）、一致性哈希（Consistent Hashing）等。在AI场景中，由于任务执行时间差异巨大（从毫秒级推理到数天级训练），静态轮询策略往往效果不佳，需要采用基于实时负载反馈的动态策略。

常见误区：很多人认为“负载均衡 = 所有节点利用率相同”。实际上，由于任务之间存在数据依赖和通信开销，盲目追求利用率均等可能导致任务被分散到不同机架，反而增加网络通信延迟。正确的目标应当是在满足任务性能约束的前提下，最小化整体资源碎片和通信开销。

2.5 案例复盘：一个典型的调度失效场景

某AI团队使用Kubernetes管理一个32卡GPU集群，用于深度学习模型训练。某天，团队提交了一个需要16卡的任务，但调度器始终无法将其调度成功，任务一直处于Pending状态。

排查过程：

查看集群资源总量：32卡，已用16卡，剩余16卡——资源充足。
查看节点级资源：发现剩余16卡分布在4个不同节点上，每个节点仅剩4卡。
查看任务请求：任务要求16卡必须位于同一节点（因为使用了张量并行，需要高速NVLink通信）。
根因定位：调度器默认的“最少资源碎片”策略将任务分散到多个节点，但任务本身要求单节点16卡，导致资源碎片化使得任务无法调度。

解决方案：为任务添加节点亲和性（Node Affinity）约束，并配置自定义调度策略，优先将任务分配到剩余卡数最多的节点。同时，团队引入了拓扑感知调度，让调度器在分配时考虑GPU之间的物理连接拓扑（NVLink域、PCIe交换机等），避免因跨节点通信导致训练性能下降。

  复盘要点：资源调度不仅要看“总量是否满足”，还要看“分布是否满足”。AI训练任务往往对GPU之间的通信带宽有极高要求，调度器必须感知硬件拓扑，否则即使任务成功调度，训练速度也可能因跨节点通信而降低数倍。这也是为什么现代AI调度器（如Volcano、Kueue）都开始支持拓扑感知调度和Gang Scheduling的原因。

通过上述案例可以看到，分布式系统的三个核心特征（并发性、无全局时钟、故障独立性）在真实集群中会以各种形式显现。理解这些基础概念，是后续掌握AI算力集群资源调度算法、负载均衡策略以及故障恢复机制的前提。在实际操作中，调度策略的选择永远需要结合具体业务场景——没有放之四海而皆准的最优配置，只有针对特定负载特征不断调优的持续过程。