npx skills add ...
npx skills add nvidia/tensorrt-llm --skill exec-env-check
Check the local execution environment for GPU availability, Docker support, and Slurm access. Returns the execution scenario (`satisfied, local, docker`, `satisfied, local, direct`, `satisfied, slurm, local`, or `not_satisfied`), the number of available GPUs, and the GPU type. On Slurm login nodes without local GPUs, the cluster is identified by delegating the hostname to internal-env-info (hostname-based mode), which owns the hostname → cluster_name patterns; GPU type and gpus_per_node then come from that skill's reference files. If internal-env-info is not installed, the scenario falls back to `not_satisfied` without probing compute nodes via srun.
npx skills add nvidia/tensorrt-llm --skill exec-env-check
Detect whether the current machine can run a GPU workload locally (Docker) or via Slurm, and report hardware details.
| Field | Description | Required |
|---|---|---|
required_devices | Minimum number of GPUs needed | Yes |
account | Slurm account (unused for GPU probing, kept for compatibility) | No |
If this succeeds:
available_gpusdevice_type (e.g., NVIDIA B200, NVIDIA H100 80GB HBM3)device_type: strip NVIDIA prefix and trailing memory info to get the short name (e.g., B200, H100, A100, L40S, RTX 6000)If nvidia-smi fails or returns no GPUs → available_gpus = 0, device_type = null.
If available_gpus >= required_devices, continue to step 2a to determine whether Docker is available on this host.
satisfied, local, dockersatisfied, local, directInclude available_gpus in the result. Do NOT include device_type — local execution does not need it.
If local GPUs are insufficient (or as additional detection), check for Slurm:
If Slurm is NOT available → go to step 5.
Optional dependency. Before doing anything else in this step, check whether skills/internal-env-info/ exists in the toolkit. If it does not, skip this step entirely and return scenario: not_satisfied with available_gpus = 0, device_type = null, gpus_per_node = null, cluster_name = null, default_models_repo = null, and default_user_root_dir = null. Do not report this as an error — the skill is an internal-only dependency.
When Slurm is available but local nvidia-smi returned no GPUs or device_type is null (login nodes typically have no GPUs), capture the hostname and delegate cluster identification to internal-env-info:
internal-env-info in hostname-based mode. That skill owns the NVIDIA-internal login-host patterns and the hostname → <cluster> mapping; do not parse the hostname or hard-code any cluster identifier here.cluster_name, device_type, gpus_per_node, default_models_repo, default_user_root_dir) plus supplementary field (mfa_style).available_gpus = gpus_per_node (if resolved).cluster_name = the value returned (a placeholder <cluster> token in this skill). The orchestrator uses this to fetch per-cluster info (mfa_style, default_models_repo, default_user_root_dir, gpus_per_node) from internal-env-info; connection fields (mounts, ssh_host, partition, etc.) come from caller-supplied inputs in job_spec.json (with internal-env-info default values / ask-the-user fallbacks).default_user_root_dir = the user root directory returned (with <user_name> substituted with the actual SLURM username). Set to null if not found.internal-env-info returns null for cluster_name (no pattern matched), set device_type = null, cluster_name = null, default_user_root_dir = null and fall through to Step 5 (not_satisfied).Result: satisfied, slurm, local with device_type, gpus_per_node, cluster_name, and default_user_root_dir.
If neither local GPUs nor Slurm is available:
not_satisfiedReturn a single structured result:
Examples:
nvidia-smi hangs, use a 5-second timeout: timeout 5 nvidia-smi ...internal-env-info skill when it is installed — no srun allocation needed. If that skill is absent, the scenario falls back to not_satisfied (see Step 4); do not error.