| name | gpu-selection |
| description | Use when choosing or reviewing GPU targets for NPA workbench tools, training, rendering, inference, or workflow YAML resources. |
GPU Selection
When To Use
Use this skill when a task asks which GPU family to use, changes workflow
resources, updates image routing, or reviews render/training placement.
Procedure
- Identify whether the workload needs RT cores, tensor throughput, multi-GPU
scaling, or only CPU resources.
- Check the tool-specific skill for hard constraints.
- Encode the choice in CLI flags, SDK config, or workflow YAML env/resources.
- Keep image variants aligned with GPU selection.
Three-Tier Contract
- CLI: commands expose GPU choices through flags such as
--gpu-type,
--gpu-preset, --runtime, or tool-specific image variant options.
- SDK: runtime config and request builders should carry GPU type/count rather
than deriving it from private environment names.
- YAML: workflow resources and env vars must express the GPU target explicitly
enough for reviewers to validate routing.
Current Defaults
- H100: general training, CLIP embedding, detection, MJLab, Cosmos inference,
LeRobot training smoke, and non-render throughput.
- L40S: Isaac Lab and SONIC render validation on VM hosts.
- RTX PRO 6000 Blackwell: Isaac Lab and SONIC render validation on Kubernetes
with mounted NVIDIA GPU Operator drivers.
- CPU: Retargeting and many dataset curation/import steps.
Gotchas
- H100 and H200 lack RT cores; do not route Isaac Lab or SONIC render validation
there.
- L40S capacity can be constrained; if the task only needs non-render training,
H100 may be the pragmatic target.
- B300/Blackwell enablement depends on upstream library support. Treat it as
vendor-paced unless current tests prove the path.
Verify
npa/.venv/bin/python -m pytest npa/tests/guardrails/test_skills_index.py -q
The smoke test invokes help for GPU-sensitive training commands and parses the
workflow YAML resources referenced by the manifest.
