/sglang-model-day0-support

name: sglang-model-day0-support
description: Build or audit an evidence-driven SGLang Day-0 support program for a new LLM, VLM, MoE, hybrid-attention, or speculative-decoding model. Use when Codex needs to map a model architecture into SGLang runtime work, design a public support PR DAG, create validation and release gates, sanitize private development evidence, distinguish Day-0 requirements from later fixes or optimizations, or review whether an existing model-support PR is release-ready.

SGLang Model Day-0 Support

Turn a model release into a reviewable SGLang support program. Produce evidence, implementation boundaries, validation gates, and public release artifacts—not only a launch command.

Use the maintained [source contracts](../../../docs/upstream-source-contracts.md) when applying historical evidence to a current branch. The review/history corpora retain their own capture dates; they do not certify today's dispatch or numerical defaults. For kernel replacements, verify that the real model executes the candidate before treating end-to-end tests as coverage.

Start Here

1. Read [day0-contract.md](references/day0-contract.md) completely. 2. Copy `assets/day0-bundle/` into the active model-support workspace. 3. Lock immutable model, weight, tokenizer/processor, SGLang, dependency, and image revisions before describing support. 4. Read [evidence-audit.md](references/evidence-audit.md) before citing PRs. 5. If any input is non-public, read [sanitization.md](references/sanitization.md) before writing public output. 6. Read only the relevant case study:

• [deepseek-v41-case-study.md](references/deepseek-v41-case-study.md) for

image-first release locks, linear extraction stacks and equivalence proofs.

• [kimi-k3-case-study.md](references/kimi-k3-case-study.md) for hybrid

KDA/MLA, VLM, DSpark, ReplaySSM, DCP, or dense internal-to-public delivery.

• [deepseek-v4-case-study.md](references/deepseek-v4-case-study.md) for

compressed/sparse attention, SWA, mHC, MTP, large rebases, or staged cookbook/image/mainline delivery.

Do not implement model code until the scope contract, architecture gap map, PR DAG, and minimum validation matrix agree.

Workflow

1. Lock the release cut

Fill `scope-contract.md` and `release-lock.md`.

• Record full immutable revisions. Reject floating branches, mutable tags, and

unpinned object-store paths as release evidence.

• Name required hardware, precision, modality, serving topology, protocol, and

performance lanes.

• Separate Day-0 commitments from explicitly deferred work.
• Record dependency ownership: upstream package, SGLang patch, bundled wheel,

image layer, or documented external prerequisite.

• Treat unavailable weights or hardware as an explicit blocked lane, not an

implicit pass.

2. Build the architecture gap map

Compare the public model configuration/reference implementation with the locked SGLang source. Inspect each capability family in the Day-0 contract.

For each gap, record:

• checkpoint/config field and expected tensor or protocol contract;
• closest SGLang implementation and why reuse is safe or unsafe;
• files/classes/functions expected to change;
• required fallback before any specialized kernel;
• evidence class and validation owner;
• interaction risks with state, graph capture, parallel layout, or protocol.

Use public model-family PR history when available. Do not infer support from a shared architecture name alone.

3. Classify the work

Assign exactly one class:

• `day0-required`: needed to load, serve, produce correct public API output, or

satisfy an announced release lane.

• `post-day0-fix`: discovered after the release cut and required to restore a

previously claimed behavior.

• `performance-only`: improves a supported path without defining correctness.
• `experiment-or-revert`: unmerged, reverted, unreachable, or retained only as

a negative result.

If one patch mixes classes, split it or explain why atomic review is impossible. Never promote an experiment merely because it exists on a development branch.

4. Design the PR DAG

Fill `pr-dag.md`. Prefer reviewable PRs with explicit dependencies:

1. shared public infrastructure; 2. model config, loader, and eager correctness spine; 3. state/cache and required parallel composition; 4. protocol, speculative, and multimodal surfaces; 5. platform-specific kernels or backends; 6. images, cookbook, tests, and release wiring; 7. one umbrella integration PR only when the release branch requires it.

Require each node to name its merge gate, fallback, tests, and public evidence. Avoid copying an entire development branch when a smaller auditable diff is possible.

5. Build the validation matrix

Fill `validation-matrix.md`. Do not construct the full Cartesian product.

Always include:

• one eager load and deterministic short generation;
• weight mapping and quantization post-processing;
• chat, reasoning, tool, structured-output, streaming-split, and stop-marker

behavior required by the model;

• state allocation, prefix reuse, eviction, graph padding, and dtype/layout;
• required TP/DP/EP/CP/DCP/PP/PD/EPD roles;
• accuracy, memory capacity, and representative performance;
• one fallback-path test for each specialized backend.

Add risk pairs where two features rewrite the same state, tokens, graph, collective, or transfer layout. Typical examples are speculative decoding × recurrent state, DCP × cache ownership, VLM × PD/EPD, DP attention × MoE collectives, and CUDA Graphs × alternative streams.

6. Execute the seven gates

Execute the gates from the Day-0 contract in order:

1. source; 2. load; 3. protocol; 4. state; 5. topology; 6. quality/performance; 7. release.

For every pass, retain the command, revision, hardware, result, and limitation. For every failure, record whether it blocks Day-0, narrows the claim, or moves to the follow-up ledger.

Do not use server startup as evidence for out