Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/aidas-dev/k8s-agent-skills/nvidia-device-pluginnpx skills add Aidas-dev/k8s-agent-skills --skill nvidia-device-plugingit clone --depth 1 https://github.com/Aidas-dev/k8s-agent-skillsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/aidas-dev/k8s-agent-skills/nvidia-device-plugin)<a href="https://agentmods.dev/skills/aidas-dev/k8s-agent-skills/nvidia-device-plugin"><img src="https://agentmods.dev/badge/skills/aidas-dev/k8s-agent-skills/nvidia-device-plugin.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00050 | $0.01746 |
| Opus 5 | $0.00025 | $0.00873 |
| Sonnet 5 | $0.00010 | $0.00349 |
| Haiku 4.5 | $0.00005 | $0.00175 |
Grade A, and why
nvidia-device-plugin scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 5d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 205 lines — stays where its author put it; the contents beside it link to each section on GitHub.
NVIDIA Device Plugin
Overview
NVIDIA device plugin exposes GPUs to Kubernetes workloads. It runs as a DaemonSet on GPU nodes, discovers NVIDIA GPUs via NVML, and advertises them as allocatable resources (nvidia.com/gpu). Includes GPU Feature Discovery (GFD) for node labelling and optional Node Feature Discovery (NFD) for hardware detection.
No CRDs. ConfigMap-based configuration.
Latest: chart 0.19.2, app v0.19.2.
Architecture
node-feature-discovery (NFD) worker
→ detects PCI devices (class 02/03 = GPU)
→ labels node: nvidia.com/gpu.present=true
gpu-feature-discovery (GFD) daemon
→ queries NVML for GPU details
→ labels node: nvidia.com/gpu.product, nvidia.com/gpu.memory, etc.
→ labels node: nvidia.com/gpu.present=true
k8s-device-plugin daemon
→ watches for pods requesting nvidia.com/gpu
→ mounts GPU devices + drivers into containers
→ generates CDI specs (optional)
Quick Start
Add annotation to any pod that needs GPU:
spec:
runtimeClassName: nvidia
containers:
- resources:
limits:
nvidia.com/gpu: 1
Runtime class nvidia must be configured on the node (Talos: .spec.runtime.runtimes.nvidia in machine config).
Key Features
| Feature | Enabled | Config |
|---|---|---|
| GPU device discovery | Always | NVML |
| GPU Feature Discovery (GFD) | ✅ (gfd.enabled: true) |
Labels nodes with GPU properties |
| Node Feature Discovery (NFD) | ✅ (nfd.enabled: true) |
Detects PCI GPUs, labels nodes |
| CDI support | ✅ | cdi.nvidiaHookPath, cdi.featureFlags |
| Config-manager | ✅ | Dynamic config via node labels |
| MIG (Multi-Instance GPU) | Optional | migStrategy flag |
| Time-slicing | Optional | Config file config.name |
| Health checks | Always | Xid detection, device health |
Helm Values
Core Settings
| Value | Default | Description |
|---|---|---|
image.repository |
nvcr.io/nvidia/k8s-device-plugin |
Image repo |
image.tag |
latest | Image tag |
runtimeClassName |
nvidia |
Runtime class for GPU pods |
priorityClassName |
— | Pod priority |
failOnInitError |
true |
Fail if no GPU found at startup |
deviceListStrategy |
envvar |
How device IDs are passed to container |
deviceIDStrategy |
uuid |
How devices are identified |
nvidiaDriverRoot |
/ |
Host driver root path |
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 5d ago First seen · 205 lines · 50 tokens per session scan A 17e2cc42697d
nvidia-device-plugin is a skill published in the GitHub repository Aidas-dev/k8s-agent-skills (2 stars, last pushed 22d ago), licensed MIT. It adds 50 tokens to every session and 1,746 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
holoscan-install-container
Install Holoscan SDK via the NGC Docker container. Use for container-based installs; not for native apt/pip/Conda installs.
doca-urom-svc
Operate the DOCA UROM Service container on BlueField Arm for remote memory operations (puts, gets, atomics, collectives) enqueued by a paired host using doca-urom: pull the NGC image, choose the UCX component, size queues, configure Comch pairing, and align host and service versions. SECURITY: the service has no…
hsb-setup
Clone the latest NVIDIA Holoscan Sensor Bridge repo, ask which supported devkit is being used, configure the host per platform, build the correct demo container, run it, and verify HSB connectivity by pinging 192.168.0.2. Use for Holoscan Sensor Bridge setup, build, container launch, and first-connectivity bring-up.
holoscan-install-source
Build Holoscan SDK from source via the in-tree ./run script. Use only when published packages don't meet the user's needs.
dakota-image
OCI layer assembly, boot testing, installer boundaries, VM work, and local OTA verification for Dakota images.
xpu-container-run
Launch a Docker container with Intel GPU access on Linux. Encodes the correct combination of --device /dev/dri, render-group access, --ipc=host, ZEAFFINITYMASK pinning, Hugging Face cache mount, and --entrypoint /bin/bash for interactive use. Use when running any Intel-XPU container (vLLM-XPU, sglang-xpu, torch-XPU…