DRA P3:DRA 工作流程与源码分析

前两篇我们完成了 DRA 的部署实战和核心概念拆解,知道了 ResourceSlice、DeviceClass、ResourceClaim 各自的职责和协作方式。
但还有一个问题没回答:从 Pod 提交到 GPU 可用,中间到底发生了什么?每个组件具体做了哪些事?
本篇逐阶段拆解 DRA 的端到端工作流,每个阶段结合 NVIDIA DRA Driver 源码分析,然后深入调度器分配算法。

前两篇我们完成了 DRA 的部署实战和核心概念拆解,知道了 ResourceSlice、DeviceClass、ResourceClaim 各自的职责和协作方式。
但还有一个问题没回答:从 Pod 提交到 GPU 可用,中间到底发生了什么?每个组件具体做了哪些事?
本篇逐阶段拆解 DRA 的端到端工作流,每个阶段结合 NVIDIA DRA Driver 源码分析,然后深入调度器分配算法。

RTK (Rust Token Killer) 是一个 CLI 代理工具,它的核心思路是在命令输出到达 AI 之前把噪音过滤压缩掉,从而实现平均省 60-90% 的 token 的效果。

HAMi 是目前 Kubernetes 上最活跃的开源 vGPU 方案,能够将一块物理 GPU 按显存和算力细粒度地切分为多个虚拟 GPU,供不同 Pod 共享。
本文聚焦 HAMi DRA 模式的部署与使用:安装 HAMi DRA 驱动后,分别用原生模式和兼容模式提交 Pod,验证 GPU 切分是否生效。

在上一篇 DRA P1:DRA 能解决什么问题?从部署到使用的完整体验 中,我们部署了 DRA 并成功运行了第一个 GPU Pod。DRA 相比 DevicePlugin 最大的区别在于:资源展示更详细,资源申请也更灵活。靠三个 API 对象来实现:ResourceSlice、DeviceClass、ResourceClaim。
那么这三个对象各自干什么,它们之间怎么配合?本篇就来回答这个问题。

在 Kubernetes 里用 GPU 这类设备,大家习惯走 DevicePlugin。但 AI workload 越来越复杂,DevicePlugin 的短板越来越明显——没法描述设备属性,调度器不参与分配,Pod 经常调度到节点后才发现资源不够。
DRA(Dynamic Resource Allocation,动态资源分配)就是 Kubernetes 针对这些问题推出的新框架。

Kimi-K2.6 是 Moonshot AI 在 4 月 20 日正式发布并开源的旗舰大语言模型,具备强大的长上下文推理、多模态理解和工具调用能力。本文将详细介绍如何使用 vLLM 部署 Kimi-K2.6 模型,并附上性能基准测试。