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. ## Present For Confirmation Return to `user-interviewer`, for relay to the user: - the complete draft manifest; - a per-decision evidence table: each major choice (TP, replicas, memory settings, backend, image, topology) with the guide citation or arithmetic that produced it; - the nearest recipes considered and why each was rejected as a base; and - the explicit statement that this draft is unvalidated on hardware and iteration 0 will characterize it. Do not proceed on silence, enthusiasm, or a partial answer: confirmation is the user's explicit acceptance of THIS manifest (or of it as amended by the user). The confirmed manifest goes to `synthesize-user-workload` for canonical capture with `deployment.origin: agent-authored` and `deployment.origin_source: inputs/baseline-evidence.md` (the interviewer writes the evidence table and confirmation there at capture time, per `run-artifacts.md`). ## Do Not - Deploy, benchmark, or apply anything. - Record an unconfirmed draft anywhere a downstream role could mistake it for the baseline. - Author when a user DGD exists (that engagement has a baseline) or when rung 1 or 2 produced a viable base. - Invent model, hardware, or SLO facts; missing facts return to the interview. - Embed secret values or Kubernetes `Secret` resources.