摘要：NVIDIA开源GPU动态资源分配驱动：Kubernetes里的GPU用法变了NVIDIA把自家GPU动态资源分配驱动开源了，直接集成进Kubernetes生态。这不是加个插件的事——它改写了GPU在K8s里被调度、隔离和复用的基本逻辑。三大老问题，这次真动刀了GPU在K8s里一直卡在“整卡分配”模式，导致三个现实问题：一卡一任务，空转成常态 比如一个轻量级推理服务（只需2GB显存、30%...

NVIDIA开源GPU动态资源分配驱动：Kubernetes里的GPU用法变了

NVIDIA把自家GPU动态资源分配驱动开源了，直接集成进Kubernetes生态。这不是加个插件的事——它改写了GPU在K8s里被调度、隔离和复用的基本逻辑。

三大老问题，这次真动刀了

GPU在K8s里一直卡在“整卡分配”模式，导致三个现实问题：

一卡一任务，空转成常态

比如一个轻量级推理服务（只需2GB显存、30%算力）仍得独占一块A100，剩下90%资源锁死闲置。显存和算力绑死，没法拆开用

传统device plugin只暴露/gpu: 1，不区分显存用量、SM占用率、NVLink带宽。多租户场景下，一个训练任务跑满显存，另一个推理任务直接OOM，但算力其实还有富余。调度过程像黑盒

kubectl describe pod 看不到GPU实际分配了哪些SM、多少显存；nvidia-smi 在容器里看到的是整卡视图，无法确认是否真被隔离。故障排查靠猜，性能调优靠试。驱动干了什么？三件事落地1. 显存与算力真正可分

驱动在内核层暴露两个新资源类型：

示例：为一个LLM推理Pod申请资源

resources:
  limits:
    nvidia.com/gpu-memory: 4Gi
    nvidia.com/gpu-utilization: 50%

驱动会：

注：非MIG卡的算力隔离依赖NVIDIA驱动470+版本的nvidia-smi -c（Compute Mode）和内核调度器补丁，实测A10/A100/V100上有效。2. 资源能伸能缩，不是静态切片

典型场景：一个训练Pod（占8Gi显存+70%算力）和三个推理Pod（各占2Gi+20%）共存于单卡A10

3. 多租户安全不是口号对AI基础设施的实际影响OpenClaw生态怎么接？现在就能做的三件事开发者：拉取nvidia/k8s-device-plugin:devel镜像，启用--enable-dra=true启动参数，在测试集群跑通gpu-memory资源请求运维：检查现有GPU节点驱动版本（≥470.82.01）、内核版本（≥5.10）、是否启用IOMMU，用nvidia-smi -q -d MEMORY,UTILIZATION验证指标可读性框架团队：在containerd配置中添加nvidia-container-runtime作为默认runtime，测试CUDA context初始化是否受gpu-utilization限制影响（实测PyTorch 2.1+、TensorFlow 2.13+无兼容问题）

驱动代码已托管在NVIDIA/k8s-dra-driver，MIT许可证，无闭源组件。