[docs] Tell Qwen3.8-27B DFLASH2 users to build from main (#35753)

This commit is contained in:
Jimmy Shong
2026-08-20 23:34:44 +00:00
committed by GitHub
parent 779e593bd1
commit 1a138e13b9
6 changed files with 122 additions and 25 deletions
@@ -34,7 +34,7 @@ the full contract):
| `quantizations` | `{id, label}[]` | 3rd-dim option list. |
| `strategies` | `{id, label}[]` | 4th-dim option list. Canonical ids: `low-latency` / `balanced` / `high-throughput` (never model-specific ids like `mtp`). **The count follows the page's operating points**: one recipe → a single `balanced`; two → `low-latency` + `high-throughput`; three → the full trio (the ideal). Tiers apply per (hw × variant × quant) combination — a single-recipe combination parks under its semantically honest tier (clear slant → that tier, e.g. DSv4's RTX 6000 → `low-latency`; no slant → `balanced`, e.g. Qwen3.5's Xeon); the page's list is the union and the engine greys unused chips per selection. Never invent a recipe just to fill chips. When two recipes differ by MTP / speculative decoding, the assignment is deterministic: spec ON → `low-latency`, spec OFF → `high-throughput` (at saturation the draft+verify overhead outweighs the speedup — same reason DSv4's high-throughput recipes disable MTP). The recurring markers in the other direction: dp-attention ON (MLA-attention models) and EP / DP+EP ON (MoE models) → `high-throughput`. |
| `nodesOptions` | `{id, label}[]` | 5th-dim option list. The `id` MUST be `single` or `multi-N` — the engine parses N from the id for `--nnodes`. |
| `cells` | `{match, verified?, nnodes?, env, flags}[]` | One per supported (hw × match-dim) combination. See §2.2. `nnodes` supplies the node count when the config declares no `nodes` dim (default 1). |
| `cells` | `{match, verified?, verificationStatus?, nnodes?, env, flags}[]` | One per supported (hw × match-dim) combination. See §2.2. `nnodes` supplies the node count when the config declares no `nodes` dim (default 1). |
| `modelNames` | `{[key]: string}` | HF slug lookup. Keys are either `hw\|variant\|quant` (most specific) or `variant\|quant` (fallback). |
| `placeholders` | `{[key]: {target, label, default?}}` | `{{KEY}}` interpolation map for command + curl. `target` is `'command'` or `'curl'`. Editable through the Env modal. |
| `curl` | string | cURL template. Uses `{{MODEL_NAME}}` + placeholder keys. |
@@ -114,6 +114,17 @@ Each cell describes one verified (or auto-estimated) launch recipe.
- `match` MUST contain exactly the 5 keys: `hw`, `variant`, `quant`,
`strategy`, `nodes`. The engine looks up cells by tuple equality.
- `verified` is the badge baseline (`true` → green **Verified**, absent →
yellow **Not Verified**). `verificationStatus` overrides it with a third
state — `"verified" | "in-progress" | "unverified"` — for a recipe whose
verification round is OPEN rather than absent. It may also be a FUNCTION of
the selection, which is how a cell reports a per-pick state: e.g.
`verificationStatus: (sel) => sel.spec === "dflash" ? "in-progress" :
"verified"` marks one speculative option as still being validated while the
cell's other picks stay Verified. An unrecognized string falls back to
`unverified`, so a typo can never render as a green badge — and
`check_cookbook_configs.mjs` probes the function over every reachable
selection, so a typo or a crash fails the check instead of reaching the page.
- `env` and `flags` are FLAT literals. The engine does NOT expand
fragments, aliases, or templates — it consumes them verbatim
(only `{{PLACEHOLDER}}` substitutions happen at render time).
@@ -335,6 +335,9 @@ sgl-eval run gsm8k \\
// ==== NVIDIA Blackwell + FP4 (single node) ====
{
match: { hw: "b200", variant: "default", quant: "fp4", strategy: "low-latency", nodes: "single" },
// For a cell whose verification round is open, use `verificationStatus`
// instead ("verified" | "in-progress" | "unverified", or a function of
// the selection for a per-pick state) — authoring-reference §2.2.
verified: true, // EXAMPLE — set false / replace with your verified recipe
env: [],
flags: [