前三篇我们完成了 DRA 的部署实战、核心概念拆解和工作流程分析。但一直使用的是 NVIDIA 官方的 DRA Driver，如果我们的硬件不是 GPU，或者只是想暴露自定义资源给 Pod 使用，该怎么办？
本文从零实现一个自定义 DRA Driver —— i-dra-driver，沿用之前 Device Plugin 文章 中的 “gopher” 资源隐喻，将节点上的文件作为设备暴露给 Pod。通过对比同一个功能在 DevicePlugin 和 DRA 两种框架下的实现差异，加深对 DRA 机制的理解。
前两篇我们完成了 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 针对这些问题推出的新框架。
