KCD Beijing 2026 分享回顾：从 Device Plugin 到 DRA——GPU 调度范式升级与 HAMi-DRA 实践

KCD Beijing 2026 是近年来规模最大的 Kubernetes 社区大会之一超过 1000 人报名参与刷新了历届 KCD 北京的记录。HAMi 社区不仅受邀进行了技术分享也在现场设立了展台与来自云原生与 AI 基础设施领域的开发者和企业用户进行了深入交流。本次分享由两位 HAMi 社区核心贡献者完成•王纪飞「Dynamia 密瓜智能」HAMi ApproverHAMi-DRA 主要贡献者•James Deng第四范式HAMi Reviewer分享主题为从 Device Plugin 到 DRAGPU 调度范式升级与 HAMi-DRA 实践。本文结合现场分享内容与幻灯片做一次更完整的技术回顾。附幻灯片下载https://github.com/Project-HAMi/community/blob/main/talks/01-kcd-beijing-20260323/KCD-Beijing-2026-GPU-Scheduling-DRA-HAMi-Wang-Jifei-James-Deng.pdf。现场回顾大会主会场观众注册中HAMi 展台前参会者前来交流打卡志愿者在为观众盖章王纪飞正在分享中James Deng 正在分享GPU 调度范式正在发生变化这次分享的核心其实不只是 DRA 本身而是一个更大的转变GPU 正在从设备变成资源对象。这个转变背后是 AI workload 对 GPU 使用方式的根本性改变——GPU 不再适合以整卡独占的方式被简单分配而是需要被共享、切分、调度和治理。Device Plugin 的天花板传统 Device Plugin 模型的问题本质上在于表达能力不足• 只能描述数量nvidia.com/gpu: 1• 无法表达多维资源显存 / 核数 / 切片• 无法表达多卡组合• 无法表达拓扑关系NUMA / NVLink这些限制直接导致• 调度逻辑外溢extender / sidecar• 系统复杂度上升• 并发调度能力受限当 AI workload 进入推理服务、多租户混合场景后这些问题的严重性被迅速放大。DRA资源建模能力的跃迁DRADynamic Resource Allocation是 Kubernetes 社区在资源模型层面的一次重要升级其核心优势包括•多维资源建模能力——不再局限于数量可以表达显存、算力等细粒度维度•完整设备生命周期管理——从资源发现、分配到回收的完整闭环•细粒度资源分配——支持更灵活的资源组合方式关键的结构性变化在于资源申请从 Pod 内嵌字段变成独立的 ResourceClaim 对象。这意味着 GPU 资源获得了与 Pod、PVC 同等的一等公民地位调度器可以像管理存储卷一样管理 GPU 资源。现实问题DRA 太复杂了DRA 的能力毋庸置疑但有一个经常被忽视的现实问题UX 明显退化。Device Plugin 的写法resources: limits: nvidia.com/gpu: 1DRA 的写法spec: devices: requests: - exactly: allocationMode: ExactCount capacity: requests: memory: 4194304k count: 1同时还需要编写 CEL selectordevice.attributes[gpu.hami.io].type hami-gpu对比之下结论非常明确DRA 是能力升级但用户体验明显退化。对于已经在使用 Device Plugin 的企业来说迁移成本不只是改写 YAML 这么简单而是整个团队需要学习一套全新的资源声明范式。HAMi-DRA 的关键突破自动化迁移这是这次分享最有价值的部分之一。HAMi 的做法不是让用户直接用 DRA而是采用了一个更务实的策略让用户继续使用 Device Plugin 的写法由系统自动转换成 DRA。工作机制通过Mutating WebhookHAMi-DRA 在 Pod 创建阶段自动完成转换输入用户侧保持 Device Plugin 语法nvidia.com/gpu: 1 nvidia.com/gpumemory: 4000Webhook 自动转换• 生成 ResourceClaim 对象• 构造 CEL selector• 注入设备约束UUID / GPU 类型输出系统内部• 标准的 DRA 资源对象• 可被调度器识别的资源表达这个设计的核心价值在于将 DRA 从专家接口变成了普通用户接口。用户不需要理解 ResourceClaim、CEL selector 这些新概念只需要像以前一样写nvidia.com/gpu系统会自动处理底层复杂性。DRA Driver不只是注册资源DRA Driver 的实现复杂度远超想象。它不只是把资源注册到调度器而是承担了完整的设备生命周期管理三个核心接口•Publish Resources——向调度器发布可用资源•Prepare Resources——Pod 创建前的资源准备注入 libvgpu.so、配置 ld.so.preload、管理环境变量和临时目录•Unprepare Resources——Pod 删除后的资源回收这意味着GPU 调度已经进入运行时编排层不再只是简单的资源分配。从用户角度看Pod 创建的时间线被拉长了——调度器匹配资源后Driver 还需要完成设备初始化、运行时注入等一系列操作才能让 Pod 正常运行。性能提升不只是更优雅HAMi-DRA 不只是架构更优雅在性能方面也有实质性的提升。Pod 创建时间对比• HAMi传统模式峰值约 42,000• HAMi-DRA显著降低提升约 30%这一提升来自 DRA 的资源预绑定机制在调度阶段就已经确定了资源分配减少了调度冲突和重试次数。对于大规模 AI 集群来说Pod 创建速度直接影响任务启动延迟和集群吞吐量30% 的提升在生产环境中意义重大。可观测性范式的转变一个容易被低估但非常重要的变化是可观测性。传统模型• 资源信息来自 Node• 使用情况来自 Pod• 需要聚合和推断才能获得完整的资源视图DRA 模型• ResourceSlice 描述设备清单• ResourceClaim 描述资源分配•资源视角是一等公民这意味着可观测性从推断变成了直接建模。运维团队可以直接通过 ResourceClaim 了解每张 GPU 被谁占用、分配了多少显存、还有多少余量而不需要从 Node 状态和 Pod 配置中反推。统一建模异构设备的未来方向如果设备属性可以被标准化那么一个与厂商无关的调度模型就成为可能。例如通过标准化的属性字段描述• PCIe root complex• PCI bus ID• GPU 核心属性这指向了一个更大的叙事DRA 是异构算力抽象的起点。当华为昇腾、寒武纪、AMD 等不同厂商的加速器都通过统一的属性模型接入 Kubernetes调度器就能真正实现跨厂商的资源管理而不再需要为每个硬件厂商维护独立的调度逻辑。更大的趋势Kubernetes 正在成为 AI 控制平面将这些变化串联起来可以看到一个清晰的趋势•从调度机器到调度资源对象——Node 不再是最小调度单元•从设备到虚拟资源——GPU 不再是一张物理卡而是可切分、可组合的资源•从命令式到声明式——调度逻辑被资源声明所替代本质上Kubernetes 正在演进为 AI 基础设施的控制平面。HAMi 的定位在这一趋势下HAMi 的定位正在变得越来越清晰面向 Kubernetes 的 GPU 资源层。•向下适配异构 GPUNVIDIA / 华为昇腾 / 寒武纪等•向上支持 AI workload训练 / 推理 / Agent•中间调度 虚拟化 资源抽象而 HAMi-DRA正是将这层资源能力与 Kubernetes 原生模型对齐的关键一步。结语这次 KCD Beijing 2026 分享的真正价值不只是介绍了 DRA而是回答了一个更实际的问题如何把一个正确但难用的模型变成一个今天就能用的系统HAMi-DRA 的答案是•不改变用户习惯——继续使用 Device Plugin 语法•吸收 DRA 能力——底层自动转换为 DRA 资源模型•内部消化复杂性——Webhook、Driver、生命周期管理全部由系统处理这也是 HAMi 社区一直坚持的方式通过社区协作推动 AI 基础设施进步而不是封闭系统。来自不同公司的贡献者在真实生产环境中验证方案通过社区共享经验让更多人受益。如果你对 HAMi-DRA 或 GPU 调度感兴趣欢迎加入 HAMi 社区与我们一起推动 Kubernetes 上的 AI 算力资源管理。关于密瓜智能「上海密瓜智能科技有限公司」专注 GPU 虚拟化与异构算力调度提升 AI 场景下的算力利用率公司发起并主导了 CNCF 开源项目 HAMi这是业界唯一实现灵活、按需、弹性、可靠 GPU 虚拟化的开源项目已支持主流 AI 芯片生态。了解更多信息欢迎访问官网dynamia.ai联系邮箱infodynamia.ai。