
Dynamo Recipe Runner
OfficialFreeDeploy NVIDIA Dynamo recipes with ease.
Free · Opens the source repo
What Dynamo Recipe Runner does
The Dynamo Recipe Runner is designed to streamline the process of deploying existing NVIDIA Dynamo Kubernetes recipes. It simplifies the transition from user intent to a functioning recipe endpoint, minimizing the need for back-and-forth communication. This skill operates on the existing recipes/ tree, allowing users to patch only the necessary manifests and deploy them when they have access to the cluster. It also includes a smoke test to verify successful deployment, ensuring that the endpoint is operational after deployment.
To use the Dynamo Recipe Runner, users must have a working environment that includes Python 3.10+, a configured kubectl, and access to the necessary Kubernetes resources. The skill requires specific inputs such as the recipe target, deployment mode, and GPU specifications. It performs preflight checks to validate the environment before proceeding with recipe selection and deployment. Users can select recipes based on their requirements and validate them before applying any changes, ensuring that all dependencies are met and potential blockers are resolved.
The skill is particularly useful for developers and data scientists who need to deploy machine learning models efficiently using NVIDIA's infrastructure. It is tailored for users familiar with Kubernetes and NVIDIA's recipe structure, allowing them to quickly adapt existing recipes for their specific needs without the overhead of creating new manifests. The focus on minimal changes and validation helps maintain the integrity of the deployment process, making it a valuable tool for anyone working with NVIDIA Dynamo recipes.
When to use it
Use this skill when you need to deploy existing NVIDIA Dynamo recipes in a Kubernetes environment without creating new manifests.
When not to use it
This skill is not suitable for users who need to create new recipes or those without access to a configured Kubernetes cluster.
What you can build with it
Deploying a Model
Use the skill to deploy a specific model recipe by selecting it from the existing `recipes/` tree and validating it before application.
Validating Recipes
Before applying any changes, run the validation step to ensure all necessary dependencies and configurations are in place.
Running Smoke Tests
After deployment, use the smoke test feature to confirm that the endpoint is functioning correctly.
How to install Dynamo Recipe Runner
View source1. Install with the skills CLI
npx skills add nvidia/skills/dynamo-recipe-runner --agent claude-code2. Or install it manually
Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.
Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs
Inside SKILL.md
Written by nvidiaDynamo Recipe Runner
<!-- SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. SPDX-License-Identifier: CC-BY-4.0 -->Purpose
Get from user intent to a working Dynamo recipe endpoint with minimal back and
forth. Do not create new guide content. Operate on the existing recipes/
tree, patch the smallest necessary set of manifests, deploy when the user has
cluster access, and prove success with an OpenAI-compatible smoke request.
Prerequisites
- Python 3.10+ on the operator machine.
kubectlconfigured with a working cluster context.- Cluster has a default storage class for model-cache PVCs.
- Hugging Face token stored in a Kubernetes secret named
hf-token-secret(or equivalent) in the target namespace. - Read access to the
recipes/tree in the ai-dynamo/dynamo repository.
Required Inputs
Collect or infer these before changing manifests:
- recipe target: model, framework (
vllm,sglang,trtllm,tokenspeed), deployment mode, and GPU type/count - Kubernetes context and namespace
- Hugging Face secret name, usually
hf-token-secret - storage class for model cache PVCs
- runtime image tag if the recipe uses a placeholder or stale test image
- whether to run commands or only produce exact commands
If a required value is missing and cannot be inferred from the selected recipe, ask for only that value.
Instructions
1. Preflight
Run read-only checks first:
git status --short
python3 scripts/recipe_tool.py list --format table
kubectl config current-context
kubectl get storageclass
kubectl get nodes -o wide
kubectl get namespace "${NAMESPACE}"
kubectl get secret hf-token-secret -n "${NAMESPACE}"
If kubectl is unavailable or the cluster is unreachable, continue by
selecting and validating the recipe, then return exact commands instead of
pretending the deployment ran.
2. Select The Recipe
Use the recipe matrix from recipes/README.md and the scanner:
python3 scripts/recipe_tool.py list \
--query qwen --framework vllm --mode disagg --format table
Prefer an exact existing recipe. Do not invent new manifests unless the user explicitly asks to author a new recipe.
3. Inspect And Validate
Read the selected recipe README, model-cache manifests, deploy.yaml, and
perf.yaml if present. Then run:
python3 scripts/recipe_tool.py validate \
recipes/<model>/<framework>/<mode>
Resolve reported blockers before applying manifests: storage class, model cache PVC, image tag, HF token secret, GPU count, frontend service name, and router mode.
4. Patch Minimal Values
Patch only recipe-specific values needed for this run. Do not reformat whole YAML files. Common patches:
storageClassName- image repository/tag
- model path or model cache mount path
- GPU resource requests/limits
- frontend
DYN_ROUTER_MODE - namespace only when a manifest hardcodes it
Never write Hugging Face tokens into files or logs. Use Kubernetes secrets.
5. Deploy
Follow the selected recipe README when it differs from the default sequence. The default sequence is:
kubectl apply -f recipes/<model>/model-cache/ -n "${NAMESPACE}"
kubectl wait --for=condition=Complete job/model-download -n "${NAMESPACE}" --timeout=6000s
kubectl apply -f recipes/<model>/<framework>/<mode>/deploy.yaml -n "${NAMESPACE}"
kubectl get dynamographdeployment -n "${NAMESPACE}"
kubectl get pods -n "${NAMESPACE}" -o wide
Wait for the frontend and workers to be ready before testing.
6. Smoke Test
Port-forward the frontend service, then verify /v1/models and one chat
completion:
kubectl port-forward svc/<deployment-name>-frontend 8000:8000 -n "${NAMESPACE}"
curl http://127.0.0.1:8000/v1/models
If dynamo-router-starter is also installed, prefer its scripts/check_router_health.py
for the full OpenAI-compatible smoke test. If this fails, switch to
dynamo-troubleshoot.
Available Scripts
| Script | Purpose | Arguments |
|---|---|---|
scripts/recipe_tool.py list | Enumerate available recipes, optionally filtered | --query, --framework, --mode, --format |
scripts/recipe_tool.py validate | Validate a recipe directory before apply | positional recipe path |
Invoke via the agentskills.io run_script() protocol:
run_script("scripts/recipe_tool.py", args=["list", "--framework", "sglang", "--format", "table"])
run_script("scripts/recipe_tool.py", args=["validate", "recipes/nemotron-3-super-fp8/sglang/agg"])
Examples
List sglang recipes that fit a single 8xB200 node:
python3 scripts/recipe_tool.py list --framework sglang --format table
Validate a specific recipe and resolve blockers before applying:
python3 scripts/recipe_tool.py validate recipes/nemotron-3-super-fp8/sglang/agg
Equivalent through the agent protocol:
run_script("scripts/recipe_tool.py", args=["validate", "recipes/nemotron-3-super-fp8/sglang/agg"])
Output Contract
Return:
- selected recipe path and why it was selected
- exact values patched
- commands run or commands to run
- endpoint and smoke-test result
- unresolved blockers, if any
- next troubleshooting step when deployment does not become healthy
Limitations
- Operates on the existing
recipes/tree only. Does not author new manifests. - Cluster-mutating apply steps require
kubectlpermission to the target namespace. - Smoke-test depth is intentionally minimal; for full router/endpoint coverage use
dynamo-router-starter. - Multi-node disagg transport correctness is out of scope; use
dynamo-interconnect-checkafter deploy.
Troubleshooting
| Symptom | Likely cause | Next step |
|---|---|---|
kubectl cluster unreachable | Context not set or VPN down | Return exact commands instead of running them; resume when cluster is reachable |
validate reports missing storage class | Cluster has no default StorageClass | Patch storageClassName on the model-cache manifest before applying |
Model-cache job stuck Pending | PVC unbound or HF secret missing | Inspect PVC events; create or rename the HF secret to match the recipe |
Worker pods ImagePullBackOff | Stale image tag or missing pull secret | Patch the image tag; verify image pull secret in the namespace |
/v1/models 4xx/5xx after deploy | Frontend not ready or wrong service port | Wait for pods Ready; re-run port-forward; switch to dynamo-troubleshoot if it persists |
Benchmark
See BENCHMARK.md for the NVCARPS-EVAL performance report (auto-generated by the NVSkills CI pipeline). To refresh, re-run /nvskills-ci on an upstream PR touching this skill.
References
- Read
references/k8s-recipe-workflow.mdfor command templates and readiness checks. - Use
scripts/recipe_tool.pyfor recipe discovery and lightweight validation.
Frequently asked questions about Dynamo Recipe Runner
Similar skills
Turborepo
Optimized build system for JavaScript/TypeScript monorepos.
Azure Pipelines Validation
Streamline your Azure DevOps pipeline changes locally.
Azure Developer CLI
Streamline your Azure project workflows with best practices.
Azure Container Registry CLI
Manage Azure Container Registry resources with ease.
Aspire
Build and orchestrate polyglot distributed applications seamlessly.
Vercel CLI
Manage and deploy Vercel projects from the command line.
