What does this skill do, and when should you use it?
This skill validates the NIXL, UCX, and NCCL interconnect used by disaggregated or multi-node NVIDIA Dynamo deployments. It inspects transport environment variables in a recipe and probes InfiniBand, GPUDirect RDMA, GDRCopy, and NVLink capabilities in a worker pod or GPU node. It also checks whether NIXL test tooling is available and surfaces the next step for a pairwise transfer test. The checks are read-only and do not modify the cluster or print secrets.
Runs scripts/check_interconnect.py with env, node, and nixl modes: reads transport variables from a recipe; uses kubectl exec access to probe InfiniBand devices and Active links, nvidia_peermem, GDRCopy, and NVLink in GPU topology; looks for NIXL test tooling and reports how to run a prefill-to-decode transfer test; returns ok, warn, fail, or skipped for checks and rolls them into a disaggregated-transport readiness verdict.
- A Dynamo disaggregated recipe has just been deployed and an operator needs to verify KV-transport readiness.
- A platform engineer is validating RDMA, GPUDirect RDMA, or NVLink capabilities before a multi-node rollout.
- Aggregated serving works but disaggregated serving is slow, hangs, or produces incorrect output and the fabric is suspected.
- A performance engineer needs to validate the transport before publishing disaggregated throughput or latency numbers.
How do you install this skill?
- Do not treat warn or skipped results as transport validation; the summary may be overly optimistic when all probes are skipped.
- Before running, verify that kubectl RBAC is limited to the target namespace and pods, and ensure manifest environment values do not contain credentials or other sensitive data.
- A paired NIXL transfer test using real scheduled prefill and decode GPU pods is still required to confirm the RDMA/NVLink path.
- Shell / CLI
- Network access
- Local filesystem
Python 3.10+kubectl exec accessrecipe-directory read access
Install the individual skill with the skills CLI:
npx skills add nvidia/skills --skill dynamo-interconnect-check --yes
The full NVIDIA collection can also be installed:
npx skills add nvidia/skills
The supplied material does not document additional manual deployment steps; the CLI prompts for the skill and installation destination.
tmp="$(mktemp -d)"
git clone --depth 1 https://github.com/NVIDIA/skills.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/skills/dynamo-interconnect-check" ~/.claude/skills/
rm -rf "$tmp"Generated from the source repository and skill path; it copies only this skill's folder. If the author's install steps above differ, follow those first. To scope it to one project, replace ~/.claude/skills with that project's .claude/skills.
How do you use this skill?
Check the recipe transport environment first:
python3 scripts/check_interconnect.py env recipes/<model>/<framework>/<mode>
Then probe a worker pod and assess NIXL readiness:
python3 scripts/check_interconnect.py node --namespace "${NAMESPACE}" --pod <worker-pod>
python3 scripts/check_interconnect.py nixl --namespace "${NAMESPACE}" --pod <worker-pod>
The script can also be invoked through the agentskills.io run_script() protocol. A complete cross-pod NIXL transfer test requires two scheduled GPU pods on the fabric.
What are this skill's strengths and limitations?
- Read-only by design: it does not mutate the cluster or print secrets.
- Checks recipe variables, InfiniBand, GPUDirect RDMA, GDRCopy, NVLink, and NIXL test-tool readiness.
- Reports missing diagnostic tools as skipped and provides concrete troubleshooting directions.
- It does not run the complete pairwise NIXL transfer test, so reachability may remain unverified.
- Skipped results for ibstat, nvidia-smi, or lsmod are inconclusive rather than passing results.
- Recipe-text inspection cannot detect variables injected at runtime by initContainers or an operator.
- It does not apply to single-node aggregated deployments, and the supplied material includes no benchmark figures.
How does this skill compare with similar options?
Side by side with related skills; every score comes from the same FSRS standard.
| Skill | FS score | Stars | Last updated | License |
|---|---|---|---|---|
| Dynamo Interconnect Readiness Check this page ✓ NVIDIA · Official | 52 · Use with care | ★ 3.6k | 13d ago | Apache-2.0 |
| Dynamo Recipe Runner ✓ NVIDIA · Official | 50 · Use with care | ★ 3.6k | 13d ago | Apache-2.0 |
| DOCA UROM Service Operations ✓ NVIDIA · Official | 45 · Not recommended | ★ 3.6k | 13d ago | Apache-2.0 |
| DOCA Management Service Operations ✓ NVIDIA · Official | 55 · Use with care | ★ 3.6k | 13d ago | Apache-2.0 |
| TAO NVIDIA GPU Host Setup ✓ NVIDIA · Official | 55 · Use with care | ★ 3.6k | 13d ago | Apache-2.0 |
Its scope differs from dynamo-troubleshoot: use this skill to validate interconnect readiness after deployment, while crashing or unschedulable pods should be handled with dynamo-troubleshoot first.
How did FollowSkills review this skill?
The skill explicitly states that it is read-only and does not mutate the cluster, and its probes are fixed read-only commands. However, it relies on the caller's existing kubectl exec privileges without confirmation or RBAC scoping, and the env check can print plaintext manifest environment-variable values, potentially exposing sensitive data. Points are deducted for least privilege, confirmation, and sensitive-data handling; no malware, covert exfiltration, or destructive default was found.
The script provides structured JSON, timeouts, graceful handling of missing tools, and generally diagnosable failure details. Static inspection also shows that it does not run a complete two-pod NIXL transfer test. Its summary ignores skipped counts, so an all-skipped run may still report no detected transport gaps, creating an overly optimistic result. No execution was performed, so the static ceiling applies.
Purpose, prerequisites, use cases, non-fit cases, positive and negative trigger examples, and the output contract are reasonably clear. The core function depends on a local Kubernetes/GPU environment rather than an overseas online service. Points are deducted for heavy environment requirements, no explicit Chinese-language support, and inability to complete real end-to-end validation with one pod or missing test tools.
The documentation includes purpose, prerequisites, procedures, examples, output contract, limitations, troubleshooting, references, and licensing; the skill card also gives ownership, version clues, and risk notes. Points are deducted for an overly long description, missing explicit dependency-installation guidance and formal changelog/maintenance path, plus benchmark-noted unexpected files and a script-lint finding.
The skill can inspect recipe transport variables, probe node capabilities, and provide a next command when NIXL validation cannot be completed; its structured output is directly consumable. Points are deducted because the essential two-pod transfer validation remains manual and the skill cannot independently prove that KV traffic uses the correct fast path. The static materials contain no independently reviewable representative success output or end-to-end execution evidence.
The source files, script, reference document, evaluation cases, and static benchmark report provide auditable evidence, with evaluation cases covering positive and negative trigger boundaries. Points are deducted because the benchmark explicitly lacks Tier 3 details, no committed key-path test suite is supplied, and no third-party runtime results are shown; this review executed no code.
Open a dimension to read why it scored that way
Evidence confidence：Low — Mostly static review, author material or a limited demo; useful for discovery, not high-risk decisions.
See the full review method →