DGD
A custom resource definition (CRD) in Dynamo that describes the desired topology of an inference graph. The Dynamo Operator reconciles it into the actually running Pods, Services, and endpoint components.
Timeline (last 90 days)
DGDR (DynamoGraph Deployment Request) is an intent-driven deployment path: users only need to describe the model, backend, workload, hardware, and optional SLA targets, and Dynamo analyzes these inputs and generates a DynamoGraph Deployment (DGD).
Teams can start deployment directly from a validated DGD manifest; after applying it with kubectl, the Dynamo Operator reconciles the inference graph into actually running components that serve traffic.
The rule for choosing between DGDR and DGD: choose DGDR if you want a usable endpoint quickly and do not want to hand-write the topology; use DGD directly if you already have a validated recipe and need fine-grained control over the inference graph.
All Facts (3)
DGDR (DynamoGraph Deployment Request) is an intent-driven deployment path: users only need to describe the model, backend, workload, hardware, and optional SLA targets, and Dynamo analyzes these inputs and generates a DynamoGraph Deployment (DGD).
50%UnverifiedTeams can start deployment directly from a validated DGD manifest; after applying it with kubectl, the Dynamo Operator reconciles the inference graph into actually running components that serve traffic.
50%UnverifiedThe rule for choosing between DGDR and DGD: choose DGDR if you want a usable endpoint quickly and do not want to hand-write the topology; use DGD directly if you already have a validated recipe and need fine-grained control over the inference graph.
50%