--- title: "NVIDIA GPU Operator or Device Plugin: Compare the Managed GPU Stack" description: "Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20." canonical: "https://www.leviathansystems.co/articles/nvidia-gpu-operator-versus-device-plugin-scope" last-updated: "2026-10-20" --- # NVIDIA GPU Operator or Device Plugin: Compare the Managed GPU Stack Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20. For a Kubernetes deployment using device plugins, the NVIDIA device plugin connects GPU resources to Kubernetes; the NVIDIA GPU Operator can manage a broader software stack that includes that plugin. The purchasing choice concerns which components need management and which existing arrangements should remain. Neither product name establishes a workload scheduling service, a complete application environment or an ongoing support commitment. ## What the device plugin supplies to Kubernetes Kubernetes documents a device-plugin framework through which vendor software advertises specialized hardware to the kubelet, the Kubernetes agent on each node. The plugin registers a resource name and reports its devices; the kubelet advertises the resources in node status. The plugin also participates in making allocated devices accessible to containers. This is more than an inventory label, but narrower than managing the node's complete GPU software environment. The Kubernetes GPU guide describes vendor drivers and the corresponding device plugin as separate requirements for this path. Once configured, the cluster exposes a custom schedulable resource such as nvidia.com/gpu that a container can request. A proposal identifying only the plugin still needs to explain where the required driver and container integration come from. The quantity and meaning of the advertised resource should be stated with its configuration. A node count does not supply a GPU count, and a resource name alone does not define the physical allocation behind it. This article follows device-plugin-based exposure; the separate DRA route is addressed briefly below. References: [K1](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/), [K2](https://kubernetes.io/docs/tasks/manage-gpus/scheduling-gpus/) ## Follow the functions across the software stack NVIDIA's Operator overview identifies drivers, the Kubernetes GPU device plugin, NVIDIA Container Toolkit, automatic GPU node labeling and DCGM-based monitoring among its components. The Operator automates management across these functions. It can therefore include the plugin being compared with it. The GPU driver supplies the device-level software needed for GPU use. Container integration addresses how a container receives access to that GPU environment. NVIDIA's Container Toolkit architecture describes components that integrate GPU support with container runtimes, with different arrangements depending on the runtime. Listing a device plugin does not identify that runtime arrangement. Discovery and labeling supply another kind of information. Kubernetes describes using node labels to select suitable GPU nodes; NVIDIA identifies GPU Feature Discovery for automatic GPU labeling. A label can help express a placement requirement. It neither allocates the device by itself nor proves that the required application software is present. Monitoring is another output. NVIDIA's DCGM Exporter converts selected GPU telemetry into Prometheus format; Prometheus collects, stores and queries the time series. If an offer includes the exporter, ask whether it also includes connection to the buyer's monitoring system and an assigned response to observations. Software that exposes metrics and people who investigate an alert are different things to purchase. References: [N1](https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/overview.html), [N2](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/arch-overview.html), [K2](https://kubernetes.io/docs/tasks/manage-gpus/scheduling-gpus/), [N5](https://docs.nvidia.com/datacenter/dcgm/latest/installation/install-dcgm-exporter.html) ## An Operator offer can retain an existing driver stack NVIDIA's installation guide explicitly describes deployments with preinstalled GPU drivers, and deployments with both the driver and NVIDIA Container Toolkit already installed. These scenarios allow those components to remain outside the Operator's installation work. The guide also accounts for Node Feature Discovery already running in the cluster. The broader management product does not require every supporting component to be installed again. That makes the existing environment part of the buying decision. A customer may already have an appointed team supplying approved node images, drivers and container integration. Ask the proposed supplier which of those arrangements it will retain, which additional components it will manage and where any responsibility changes. Distinguish three descriptions: the software exists, the Operator is configured to manage it, and a named organization is engaged to maintain it. A quote can establish the first without the second, or deploy the Operator without buying a continuing operating service. Have the supplier explain its actual component selection and management boundary rather than treating the default component list as the delivered scope. The appointed platform team should assess the supported arrangement before any change is selected. Retaining an existing driver can be appropriate; transferring its management can also be appropriate. The useful comparison is the work each option adds, duplicates or leaves with the customer. References: [N3](https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/getting-started.html) ## Attach support claims to a release and platform NVIDIA publishes both a GPU Operator component matrix and supported platform configurations. The component matrix relates Operator releases to component versions; the platform coverage distinguishes operating systems, Kubernetes platforms and hardware. A statement that the Operator supports GPUs is too broad to establish support for the buyer's particular combination. Ask for the proposed Operator release, device-plugin release, GPU and server, operating system and relevant kernel, Kubernetes distribution and release, container runtime and GPU driver basis. Include retained components in that assessment. For a standalone-plugin proposal, the appointed team still needs to establish its applicable prerequisites and supported environment. Keep the evidence dated. The latest documentation consulted on October 20, 2026 is a reference for this explanation, while an actual offer needs the documentation applicable to its selected releases. This article recommends no numeric version pairing. A supported component combination also leaves the buyer's selected application and required workload evidence to be assessed. References: [N4](https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/platform-support.html) ## Compare two fictional offers for the same four GPU nodes Suppose a customer is comparing offers A and B for the same four GPU worker nodes. Both proposals stipulate the same resource names, quantities and allocation configuration on each corresponding node. Four is the number of nodes; the example specifies no GPU count. These are invented proposal terms, not observed cluster results. Offer A supplies an identified standalone NVIDIA device plugin and its agreed initial integration. The customer's existing platform team retains the node image, GPU driver and container-runtime integration. Its existing monitoring team retains the exporter, telemetry collection and response. A identifies the interfaces its plugin needs from those teams and ends at the agreed initial output. Offer B supplies the GPU Operator and expressly includes management of the agreed driver, Container Toolkit, device plugin, GPU labeling and exporter components. Its supplier also proposes continuing maintenance of that set over a stated service period. The buyer's existing monitoring system remains the destination, and application software remains with the application team. B's additional purchase is therefore defined software management and supplier work. Equal proposed GPU resources give no basis for assigning B more GPU capacity or faster applications. Equally, A's narrower supplier scope is not necessarily a gap: the customer's existing teams may already provide exactly the remaining work it wants to retain. Now consider a future node reprovisioning requirement. Under A, ask whether the existing image process will restore the required driver and runtime integration, and who will reconnect the plugin to that restored environment. Under B, ask which parts the supplier will return to the agreed managed state and which prerequisites still come from the customer. These questions reveal lifecycle differences that an initial resource-count comparison misses. Compare the additional supplier price with the customer work that actually changes. If the customer must keep its image and driver management arrangement, request a B option that retains those components and prices the remaining management. If no customer team will maintain the required stack, ask A's supplier to price that missing work or identify the separately appointed provider. Neither product name supplies the answer. ## Buy the lifecycle result without confusing it with scheduling For the initial delivery, ask the platform team to connect the identified component configuration to the proposed GPU resources and intended container access. For continuing operation, use a changed-node or changed-platform scenario to establish what the provider will assess and maintain. This turns a software list into a comparison of useful work without assuming that every future change is covered. Monitoring needs its own endpoint: exported telemetry, collection into the selected system and an assigned operating response are separate outputs. Likewise, an Operator installation can automate component management without promising that a supplier will choose releases, coordinate changes or investigate incidents indefinitely. State which of those services the offer includes. Kubernetes assigns Pod placement to a scheduler. Its scheduler documentation describes matching Pods to nodes while considering resource requirements and other constraints. Device exposure supplies information used in that process; the device plugin is not a rival job scheduler, and the GPU Operator's stack management does not by itself supply a queue-admission or workload-policy package. Keep application evidence distinct as well. The advertised GPU resources cannot establish that the chosen application image has its required libraries, data access or accepted behavior. Ask the application owner for the separately agreed validation. There is no need to buy the same configuration or verification twice if an existing team already supplies it. References: [K3](https://kubernetes.io/docs/concepts/scheduling-eviction/kube-scheduler/), [N5](https://docs.nvidia.com/datacenter/dcgm/latest/installation/install-dcgm-exporter.html) ## Identify DRA when the offer uses a different allocation route Dynamic Resource Allocation, or DRA, is a separate Kubernetes device-allocation mechanism. NVIDIA's current Operator documentation describes managing its DRA driver and contrasts allocation through ResourceClaim objects with device-plugin resource limits. The Operator name alone therefore does not identify the allocation route. If an offer uses DRA, request its actual driver release, supported platform and enabled capabilities. The current NVIDIA documentation distinguishes feature maturity, so a generic DRA label cannot establish every capability. This article's device-plugin explanation is not a comprehensive DRA comparison or a reason to declare the plugin obsolete. References: [N6](https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/dra-intro-install.html) ## Connect the selected platform to physical delivery When customer equipment also needs installation, the chosen platform team should identify the servers, physical connections and equipment records it needs to receive. Leviathan's Complete Physical Infrastructure Deployment service is relevant to receiving, rack integration, agreed hardware QA, onsite installation, IT cabling and physical handoff records. Kubernetes administration and GPU software-stack management remain with the separately appointed platform provider. Use the service and project-inquiry links below when there is a physical package to scope. Share a nonconfidential equipment and site outline, the requested physical work and the team receiving the installation. ## Primary sources - [N1 — NVIDIA GPU Operator: About the Operator](https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/overview.html). Checked 2026-10-20. Defines the Operator's broader component-management role, including drivers, device plugin, Container Toolkit, GPU labeling and DCGM-based monitoring. - [K1 — Kubernetes: Device Plugins](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/). Checked 2026-10-20. Device-plugin registration, kubelet resource advertisement and the container-allocation interface for the device-plugin path. - [K2 — Kubernetes: Schedule GPUs](https://kubernetes.io/docs/tasks/manage-gpus/scheduling-gpus/). Checked 2026-10-20. Vendor driver/plugin relationship, custom schedulable GPU resources and node-feature selection. These device-plugin semantics do not describe every DRA allocation. - [N2 — NVIDIA Container Toolkit: Architecture Overview](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/arch-overview.html). Checked 2026-10-20. Explains GPU integration with container runtimes and runtime-dependent component roles. - [N3 — NVIDIA GPU Operator: Installing the Operator](https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/getting-started.html). Checked 2026-10-20. Documents preinstalled-driver, preinstalled-driver-and-Toolkit and existing Node Feature Discovery scenarios, establishing that component management can be selective. - [N4 — NVIDIA GPU Operator: Platform Support](https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/platform-support.html). Checked 2026-10-20. Separates release-specific component versions from hardware, operating-system and Kubernetes-platform coverage; an actual offer needs its applicable combination. - [N5 — NVIDIA DCGM: Install DCGM Exporter](https://docs.nvidia.com/datacenter/dcgm/latest/installation/install-dcgm-exporter.html). Checked 2026-10-20. Guide updated September 10, 2026. Distinguishes exporter telemetry, Operator-managed exporter lifecycle and Prometheus collection. - [K3 — Kubernetes: Kubernetes Scheduler](https://kubernetes.io/docs/concepts/scheduling-eviction/kube-scheduler/). Checked 2026-10-20. Defines Pod-to-node placement and scheduling constraints, distinct from GPU software-stack management. - [N6 — NVIDIA GPU Operator: DRA Driver for NVIDIA GPUs](https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/dra-intro-install.html). Checked 2026-10-20. The consulted page describes NVIDIA DRA driver v0.5.1, claim-based allocation, Operator management and separately qualified feature maturity. Used only to identify the distinct route. ## Related Leviathan resources - [Distinguish preinstalled software from customer-specific configuration](/articles/gpu-server-preinstalled-software-vs-site-commissioning) - [Plan the later GPU cluster management handoff](/articles/gpu-cluster-management-handoff) - [Compare cloud and colocation operating responsibilities](/articles/gpu-cloud-vs-colocation-ownership) - [Discuss complete physical infrastructure deployment](/services/turnkey-gpu-deployment) - [Send a nonconfidential physical project outline](/contact?service=turnkey-gpu-deployment&from=%2Farticles%2Fnvidia-gpu-operator-versus-device-plugin-scope) ## Scope the physical handoff to your platform team Share the equipment, requested physical installation, connection requirements and records your appointed platform team needs. We can discuss the physical work and availability. [Discuss the scope](/contact?service=turnkey-gpu-deployment&from=/articles/nvidia-gpu-operator-versus-device-plugin-scope)