📚 课程目录第2章 AI任务类型与调度需求

2. AI任务类型与调度需求

在 Kubernetes 上调度 AI 任务，第一步不是写 YAML，而是把任务“翻译”成调度器能理解的资源画像。同样是申请 1 张 GPU，训练任务和推理任务对调度器的诉求可能完全相反：训练希望独占、长时间稳定运行，推理希望快速拉起、能被弹性伸缩，批处理希望尽快吃完队列，超参搜索则希望大量小任务高并发地抢占空闲资源。如果只用“需要 GPU”这一条约束去调度，集群很快会出现 GPU 利用率低、长任务被反复驱逐、推理 P99 延迟飙升等问题。

四类任务的调度特征

训练任务通常以 Job 或自定义 CRD（如 PyTorchJob、TFJob）提交，具有“长时、独占、强同步”的特征。数据并行训练中，多个 Worker 通过 AllReduce 周期性同步梯度，任何一个 Worker 卡顿都会拖慢整个作业，因此调度器需要保证所有 Worker 同时获得资源（Gang Scheduling），否则会出现部分 Pod 已占 GPU、其余 Pod 排队等待的死锁。训练还常需要多机多卡，跨节点通信量大，对网络带宽和拓扑敏感。

推理任务以 Deployment 或 InferenceService 形式长期在线，特征是“常驻、低延迟、可弹性”。它关注的是首 token 延迟、吞吐和显存占用，而不是训练时长。推理实例通常需要固定显存以加载模型权重，调度时要避免与训练任务争抢同一张 GPU 导致显存溢出。推理还常配合 HPA 按 QPS 或 GPU 利用率扩缩容。

批处理任务（如离线特征计算、日志清洗、视频转码）对完成时间不敏感，但对吞吐敏感，适合用低优先级、可抢占的方式填充集群空闲资源。它们往往不需要 GPU，或只需要少量 GPU 做加速，调度重点是队列管理和公平共享。

超参搜索由大量短时、独立的小任务组成，每个 trial 可能只跑几分钟。它们的资源需求小但数量多，调度器需要支持高并发创建、快速回收，并配合早停策略及时终止表现差的 trial，避免浪费 GPU。

资源需求分析：从“要 GPU”到“要什么样的 GPU”

GPU 是最稀缺的资源，但调度时不能只写 nvidia.com/gpu: 1。更完整的画像至少包含四层信息：卡数（单卡、多卡）、型号（A100、H100、L40S 等，不同型号算力和显存差异大）、显存（决定能否装下模型和 batch）、拓扑（同一节点内 NVLink 互联，还是跨节点走 InfiniBand）。例如一个 70B 模型推理，若用 FP16 加载，权重约 140GB，单张 80GB 卡放不下，必须做张量并行跨多卡，此时调度器要保证这些卡在同一高速互联域内。

内存需求分两类：主机内存和显存。数据加载、预处理、模型权重从存储读入主机内存，再拷贝到显存。若主机内存不足，会出现 OOMKilled；若显存不足，则 CUDA OOM。训练时还要注意共享内存 /dev/shm，PyTorch DataLoader 多进程会占用它，默认 64MB 往往不够，需要挂载 emptyDir 并设置 medium: Memory 和足够 sizeLimit。

网络需求在分布式训练中尤为关键。AllReduce 的通信量与参数量、Worker 数成正比，若跨节点走普通以太网，GPU 利用率可能从 90% 掉到 30%。因此调度器应尽量把同一作业的 Pod 放在同一 leaf switch 下，或使用 RDMA 网络。推理任务则更关注南北向流量和网关延迟。

存储需求取决于数据访问模式。训练要顺序读大文件，追求高吞吐，适合并行文件系统或对象存储加缓存；推理要低延迟加载模型，适合本地 NVMe 或镜像内嵌；批处理可能读大量小文件，对 IOPS 敏感。调度时可通过 PVC、CSI 和节点本地缓存策略配合。

一个可参考的任务画像示例

下面给出一个训练任务的资源画像片段，用于说明如何把上述维度落到配置里。参数为教学示例，实际需按模型和集群调整。

resources:
  limits:
    nvidia.com/gpu: 8          # 8 卡，需同节点或同互联域
    memory: 512Gi
    cpu: 64
  requests:
    nvidia.com/gpu: 8
    memory: 512Gi
    cpu: 64
env:
  - name: NCCL_IB_DISABLE
    value: "0"                 # 启用 InfiniBand
  - name: NCCL_SOCKET_IFNAME
    value: "ib0"
volumeMounts:
  - name: shm
    mountPath: /dev/shm
volumes:
  - name: shm
    emptyDir:
      medium: Memory
      sizeLimit: 32Gi
nodeSelector:
  gpu-type: a100-80g           # 绑定 GPU 型号

提交后，判断调度是否合理可以观察几个信号：Pod 是否全部 Pending 后同时 Running（Gang 生效）；nvidia-smi 中 GPU 利用率是否稳定在高位；NCCL 日志里 bus bandwidth 是否接近硬件上限；训练 step time 是否随 Worker 数增加而明显恶化。若出现部分 Pod 长期 Pending，通常是配额不足或拓扑约束过紧；若 GPU 利用率低但 step time 长，多半是网络或数据加载瓶颈。

调度 AI 任务时，先问三个问题：任务能否被抢占？需要几张什么型号的 GPU？通信是否跨节点？这三个答案基本决定了应该用 Gang、优先级、亲和还是拓扑感知策略。

把任务类型、资源画像和调度策略对应起来，才能在同一个 Kubernetes 集群里让训练、推理、批处理和超参搜索稳定共存，而不是互相踩踏。