DGDR Reference

A DynamoGraphDeploymentRequest (DGDR) is Dynamo’s deploy-by-intent API. You describe what you want to run and your performance targets; the profiler determines the optimal configuration and creates the live deployment.

For a step-by-step walkthrough of deploying your model — including strategy selection, model caching, planner setup, and common pitfalls — see the Model Deployment Guide.

DGDR vs DGD

Dynamo provides two Custom Resources for deploying inference graphs:

When to use DGD instead: Use DGD when you have a hand-crafted configuration for a specific model/hardware combination (e.g., from recipes/). These configs may be more optimal for known setups but require understanding of what parallelism parameters (TP, PP, EP) are appropriate and don’t generalize across different hardware.

For DGD deployment details, see Creating Deployments.

Spec Reference

Minimal Example

1
apiVersion: nvidia.com/v1beta1
2
kind: DynamoGraphDeploymentRequest
3
metadata:
4
  name: my-model
5
spec:
6
  model: Qwen/Qwen3-0.6B
7
  image: "nvcr.io/nvidia/ai-dynamo/dynamo-planner:1.0.0"

Field Reference

For the complete CRD spec, see the API Reference.

SKU Format

When providing hardware configuration manually, use lowercase underscore format:

All supported values: gb200_sxm, b200_sxm, h200_sxm, h100_sxm, h100_pcie, a100_sxm, a100_pcie, l40s, l40, l4, v100_sxm, v100_pcie, t4, mi200, mi300.

Lifecycle

When you create a DGDR, it progresses through these phases:

Conditions

The operator maintains these conditions on the DGDR status:

Monitoring

$
# Watch phase transitions
$
kubectl get dgdr my-model -n $NAMESPACE -w
$
$
# Detailed status, conditions, and events
$
kubectl describe dgdr my-model -n $NAMESPACE
$
$
# Profiling sub-phase
$
kubectl get dgdr my-model -n $NAMESPACE -o jsonpath='{.status.profilingPhase}'
$
$
# Profiling job logs
$
kubectl get pods -n $NAMESPACE -l nvidia.com/dgdr-name=my-model
$
kubectl logs -f <profiling-pod-name> -n $NAMESPACE
$
$
# View generated DGD spec (when autoApply: false)
$
kubectl get dgdr my-model -n $NAMESPACE \
>
  -o jsonpath='{.status.profilingResults.selectedConfig}' | python3 -m json.tool
$
$
# View Pareto-optimal configs from profiling
$
kubectl get dgdr my-model -n $NAMESPACE \
>
  -o jsonpath='{.status.profilingResults.pareto}'

Resource Ownership

• The DGDR does not set an owner reference on the DGD it creates. Deleting a DGDR does not delete the DGD — it persists independently so it can continue serving traffic.
• The relationship is tracked via labels: dgdr.nvidia.com/name and dgdr.nvidia.com/namespace.
• Additional resources (planner ConfigMaps) are created in the same namespace and labeled with dgdr.nvidia.com/name.

Further Reading

• Model Deployment Guide — How to deploy your model, strategy selection, pitfalls, examples
• Profiler Guide — Profiling algorithms, picking modes, gate checks
• Profiler Examples — Ready-to-use YAML for SLA targets, private models, MoE, overrides
• Planner Guide — Scaling modes, PlannerConfig reference
• API Reference — Complete CRD field specifications
• Creating Deployments — DGD spec for full manual control