Author Baseline Dgd

Author Baseline DGD

<!--
SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
SPDX-License-Identifier: Apache-2.0
-->

Draft ONE candidate baseline DGD for a greenfield engagement and present it for the user's explicit confirmation. Do not deploy, benchmark, apply, or record anything as the baseline: an unconfirmed draft is a proposal, and only the user's confirmation makes it a user-provided baseline.

Inputs

Require:

• the interview fact table from synthesize-user-workload (model source and revision, hardware type and count, backend and precision preferences, workload shape, SLOs, Kubernetes context and namespace);
• the recipe catalog scan that established rung 3 (no exact or close recipe), including the nearest recipes considered and why each was rejected as a base; and
• any user-stated constraints (resources.pinned candidates, budgets) already collected.

If model identity or hardware type and count is missing, return the question to user-interviewer instead of guessing. Backend is different: when the user explicitly has no preference, CHOOSE it here with evidence - prefer the backend whose nearest catalog recipe scaffolds this model family and hardware, per the knob guides' coverage - and record the choice and its evidence in the decision table the user confirms. A confirmed draft's backend is a confirmed decision, not an invented default; the contract's preferences.framework still records only what the user themselves stated.

Read The Applicable Knowledge

Always read:

• all three files under agent-docs/guides/model-sizing/ (memory fit, min_tp, classification);
• agent-docs/guides/knob-tuning/tuning-hierarchy.md;
• the chosen backend's guide (agent-docs/guides/knob-tuning/vllm.md, sglang.md, or tensorrt-llm.md) - when choosing the backend here, read the candidates' guides as needed to make the choice;
• agent-docs/guides/knob-tuning/dynamo.md; and
• the nearest catalog recipes' manifests, as structural scaffolding only.

Read agent-docs/guides/rate-matching/matching.md only when the draft is disaggregated (rare for a baseline; prefer aggregated unless the user's SLOs demand otherwise).

Author The Draft

1. Size the model: compute weight bytes, min_tp, and headroom_ratio per memory.md, showing the arithmetic. Choose the serving TP per parallelism.md (prefer lower TP and more replicas for throughput workloads; raise TP above min_tp only when headroom demands it, recording the replica cost).
2. Choose topology conservatively: an aggregated single-node layout unless the user's hardware or SLOs force otherwise. The baseline's job is to run and measure, not to win; the optimization loop owns improvement.
3. Scaffold from the nearest recipe: copy its structure (components, probes, service wiring) and replace model, parallelism, resources, and any hardware-bound fields, naming every replacement. Image versions are NOT copied blindly: when a recipe dossier snapshot exists (<EXP_ROOT>/analysis/recipe-dossier/), read the scaffold candidate's recorded verdict and failed conditions, and never carry forward an image the dossier marked mutable, unresolved, stale, or quarantined (Tier 4); choose an image that resolves to an immutable release tag or digest for the chosen backend and record the resolution in the evidence table. A draft whose image fails that gate is not ready for confirmation. Never carry a hardware-bound topology, transport, or checkpoint choice across without evidence it fits the target. A manifest expresses REQUIREMENTS (GPU type, count, memory), never observed cluster state: do not pin node names or encode which nodes happen to be free, and preserve the recipe's scheduling MECHANISMS (tolerations, product-label node selectors) while retargeting their VALUES to the contract's hardware (a selector naming the recipe's GPU product is itself a hardware-bound field to replace). Before copying service wiring, check the recipe's INFRASTRUCTURE PREREQUISITES against the stated target the same way rung-2 adaptation does (gateway/service-mesh routing, referenced secrets, CRDs, storage classes): strip or replace machinery the target cannot satisfy, name each removal, and keep a supported direct client route to the workers; a prerequisite only the user can provide goes back to user-interviewer as a blocking question. Offline YAML parsing and dry-runs cannot verify these, so this check is part of authoring, not validation.
4. Set knobs to the backend guide's defaults, deviating only where the sizing arithmetic requires it (e.g. gpu_memory_utilization, max_model_len capped to the workload). Leave optimization headroom alone.
5. Validate the draft: parse as YAML, exactly one DynamoGraphDeployment document, no secret values, and confirm it would pass kubectl apply --dry-run=server semantics (correct API version, resource names, required fields) to the extent checkable offline.