随着 GB200 NVL72 等机架级统一计算域产品的不断上线，我们面对的不再是简单的使用数个GPU的时代，而是进入了编排SuperPod的新纪元；但随之而来的核心问题变成了：面对如此庞大复杂的硬件拓扑，我们究竟该如何把这些算力巨兽真正用得好？。
最近，我关注到 Crusoe Cloud 发布的一篇关于在 GB200 NVL72 上微调 Llama 3.1 的基准测试报告。除了硬件本身带来的 2-3 倍吞吐量提升和完美线性扩展外，最让我眼前一亮的，是其背后采用的 “基于 Kubernetes DRA 的拓扑感知调度” 方案。
今天，我想借这个案例，和大家聊聊 Kubernetes 动态资源分配（Dynamic Resource Allocation，简称 DRA）——这个正在重塑云原生 AI 硬件资源管理范式的下一代方案。
一、 从 GB200 NVL72 案例看调度的作用
在 Crusoe Cloud 的案例中，GB200 NVL72 将 72 个 GPU 组合成一个统一机架，提供 130 TB/s 的聚合带宽和统一内存池。硬件指标极其华丽，但在实际微调 Llama 3.1 70B 这种大参数模型时，如果调度不当，不仅无法发挥 MNNVL（Multi-Node NVLink）1.8 TB/s 的跨节点通信优势，甚至会退化成比 H100 更慢的“网络瓶颈”状态。
他们是如何解决的呢？核心在于软硬协同的拓扑感知调度。在这个方案中，我们清晰地看到了 Kubernetes 与 NVIDIA 软件的能力边界与完美分工：
-
Kubernetes：K8s 提供了 DRA 基础框架、Pod 调度与节点放置、以及 ResourceClaim（资源声明）的生命周期管理。它负责在集群层面寻找合适的节点，决定训练 Pod 的落位。 -
NVIDIA 基础软件：NVIDIA DRA Driver 引入了 ComputeDomain这个 CRD（自定义资源），将复杂的物理 GPU 互联拓扑抽象为逻辑计算域。当 K8s 分配好节点后，NVIDIA 驱动自动在底层配置 NVLink 和 IMEX 守护进程，打通物理链路，并向 K8s 暴露底层的拓扑信息（Topology Information），从而支撑 K8s 做出拓扑感知的调度决策。
IMEX 的全称是 Internal Memory Extension（内部内存扩展）守护进程，由 NVIDIA 驱动自动配置和运行。它可以打通跨节点内存映射（Memory Mapping），使得 AI 框架（如 PyTorch、CUDA）来说，感知不到物理机器的界限，就像在读写本地显存一样
通过这种分工，用户只需声明“我需要一个 32 卡的 ComputeDomain”，底层复杂的 NVLink 走线和 IMEX 配置被完全屏蔽。这正是 DRA 框架的魅力所在。
二、 为什么我们需要 DRA？
要理解 DRA 的颠覆性，我们必须回顾一下传统的 Device Plugin 框架（自 K8s v1.8 引入）。在过去几年里，Device Plugin 立下了汗马功劳，但它在如今的 AI 时代暴露出根本性局限：
-
缺乏表达能力：只能申请特定数量个 GPU，无法指定型号、显存、计算能力，更无法指定拓扑连接。 -
忽略拓扑关系：调度器无法感知 NVLink 连接或 PCIe 亲和性，容易把需要高频通信的 Pod 调度到跨交换机的节点上。 -
单节点局限：资源分配决策严格限制在单节点视野内，无法实现像 GB200 NVL72 这种跨节点的集群级调度。
为了解决这些痛点，Kubernetes 社区借鉴了存储领域 PVC（Persistent Volume Claim）动态供应的思路，在 v1.26 引入了 DRA，并在 v1.34 版本中将其作为默认启用的稳定特性。DRA 将硬件资源纳入了 K8s 的声明式 API 体系。
三、 DRA 的核心优势与最新演进
相比传统方案，DRA 带来了几个质的飞跃：
-
集群级资源视图与拓扑感知：资源信息在全集群可见，调度器原生支持基于硬件拓扑（如 GB200 的 MNNVL）的决策，这是大模型分布式训练的刚需。 -
结构化参数与细粒度筛选：用户可通过 CEL 表达式按任意设备属性进行筛选，不再局限于简单的整数。 -
设备共享与声明式管理：支持多容器共享同一设备，Pod 只需引用 Claim，由系统完成匹配绑定。
CEL（Common Expression Language）是谷歌开发的一种简单的表达式语言。借助CEL，可以直接在 YAML 中写筛选条件。例如：直接筛选“显存大于 40GB”且“型号是 A100”的特定硬件，类似这样：device.driver == "nvidia" && device.attributes.memory >= 40G && device.models.contains("A100")
在最新的 Kubernetes v1.36 中，DRA 正在加速演进：
-
Prioritized List（已稳定）：支持异构 GPU 的 fallback 能力。以前你申请 H100 显卡，如果集群里的 H100 被别人占满了，你的任务就会直接卡在 Pending 状态。现在你可以在YAML表示：“我最想要 H100 显卡（首选），如果实在没有，给我 A100 也能凑合（备选）。” 这样系统就会自动帮你做“降级（Fallback）”处理，任务不会卡死。这在目前全球算力紧缺、混合部署的环境下特别有用。 -
Extended Resource Support：让传统 extended resource 的 Pod 写法可以平滑桥接到 DRA 机制上，降低了迁移成本。以前的旧业务可能用传统的老写法。如果升级到 DRA 必须要大家去重写几万行 YAML 文件，推行阻力会极大。K8s 现在提供了一个“自动翻译官”，Kubernetes 会在后台自动把它翻译成 DRA 懂的新语法，让你零成本平滑迁移，既享受了 DRA 的新底层，又不用改动老代码。 -
拥抱 PodGroup：DRA 正与 Workload/PodGroup 方向深度融合， ResourceClaimTemplate可为整个 PodGroup 生成一份 claim。这对于需要严格 gang-scheduling（帮派调度）的大规模 AI/ML 分布式训练来说，简直是量身定制。
四、 结语
正如 NVIDIA 杰出工程师 Kevin Klues 所言，DRA 的这些基础功能将塑造未来十年 Kubernetes 上 AI 工作负载的运行方式。
从 Crusoe Cloud 的 GB200 NVL72 案例中，我们看到了 DRA 如何将极其复杂的机架级硬件拓扑，转化为开发者触手可及的声明式 API。
Kubernetes DRA 不仅仅是一次 API 的升级，它标志着云原生 AI 基础设施从“粗放式的资源堆叠”正式迈入了“精细化的拓扑编排”时代。未来，随着更多像 GB200 这样的超级硬件接入集群，DRA 必将成为连接 AI 框架与底层硅片的坚实桥梁。