MODEL-NEMOTRON-H W1 land-prep: the MIXED_PRECISION resolver re-merged, plus three LOWs and two unwritten dispositions (#517) - #561
Merged
Conversation
…#517) W1 of `.agents/specs/nemotron-h-model.md`. `nvidia/NVIDIA-Nemotron-3.5- Lightning-30B-A3B-NVFP4` is the first `MIXED_PRECISION` checkpoint we have had to read, and the repo name lies about it: 5935 of its 5981 `quantized_layers` entries are NVFP4 W4A16 group-16, 46 are FP8 W8A8 static (the Mamba2 `in_proj`/`out_proj` only), and a 72-entry `ignore` list leaves embeddings, conv1d, the MoE gates and the whole attention tower in bf16. We have never resolved a quant algorithm per module — `quantization_config` is read ad-hoc in exactly two weight files today. Reading this checkpoint as uniformly NVFP4 is the failure a token gate CANNOT see: dequantizing an FP8 projection is still numerically correct, so the tokens match, the goldens pass, and we move the wrong bytes forever. Adds `modelopt_mixed_precision.h`: parse either config shape, then resolve a module prefix to a TYPED result (algorithm, which strategy answered, group size) rather than a raw string handed to callers. Mirrors `modelopt.py:2279-2505` @ 555967922 in full. The spec's §2 claimed the lookup was "direct name first, then shard prefix"; that understated upstream and is corrected in this commit. `_resolve_quant_algo` has FIVE strategies: direct lookup over the prefix candidates; packed/fused unfusing via `packed_modules_mapping`, which RAISES when one fused layer's shards disagree; a prefix scan for parent modules; the `.experts` special case, where a `FusedMoE` prefix is `...moe.experts` while ModelOpt lists `...moe.up_proj`; and a `fused_projection_shards` fallback that raises on disagreement too. Exclusion is separate and checked FIRST (`get_quant_method`), via `is_layer_skipped` + the legacy substring rule + `fnmatch` — which is how the real `ignore` entry `mtp*` covers the entire MTP head. ONE DELIBERATE DIVERGENCE, argued here because it is policy, not a port: an algorithm this consumer does not implement is REFUSED BY NAME. Upstream falls through to `UnquantizedLinearMethod()` for anything outside {FP8, NVFP4, W4A16_NVFP4, MXFP8}, including `FP8_PB_WO` and `FP8_PER_CHANNEL_PER_TOKEN` from its own `QUANT_ALGOS`. That silent dequantization is exactly what a token gate cannot see, so we throw and name the algorithm and the module. A prefix merely ABSENT from `quantized_layers` is not this case and stays unquantized, as upstream: "not listed" is the checkpoint saying bf16. The header lands under `src/` rather than beside its two `include/vllm/...` siblings. `check-doc-checkpoint` classifies the whole `include/vllm/` prefix as user-facing and requires `docs/USAGE.md` to move with it, and nothing here is user-facing yet — not on the `include/vllm.h` ABI, no loader calls it, no command or config key changes — so that edit would have documented nothing. W3 promotes it to `include/` when it becomes part of the consumed surface and pays the obligation that genuinely applies then. The checker is not weakened and `docs/` is untouched. Two gate arms, deliberately two binaries so the opt-in one cannot mask the always-on one: test_modelopt_mixed_precision 22 cases, 137 assertions, always on test_modelopt_mixed_precision_checkpoint 2 cases, 12145 assertions, opt-in The curated fixture copies its real entries verbatim from the checkpoint and annotates every synthetic entry with the strategy it exists to reach — the real config resolves ALL 5981 entries by strategy 1 alone, so strategies 2-5, both disagreement raises and the unknown-algo refusal are unreachable from it. The exhaustive arm reads the real 1.3 MB config.json and asserts all 5981 + 72 entries with the histogram exactly {W4A16_NVFP4: 5935, FP8: 46}; it exits 77 with a loud banner when the checkpoint is not staged, so CTest reports it Skipped rather than a green run that asserted nothing. RED first: build failed on the absent header, then a compiling stub failed 20/20 cases and 74/117 assertions with Status: FAILURE. 17 mutations were then applied one at a time — each disagreement raise turned into a return, the unknown algo routed to a supported path and to unquantized, exclusion moved after resolution, each of the five strategies deleted, both prefix-candidate rules dropped, the group size widened to FP8 and pinned to 16, the partial fused-exclusion raise removed, fnmatch reduced to equality, the legacy substring rule deleted, the empty-map refusal removed, and the `.upper()` dropped. All 17 went red; the tree restored byte-for-byte (sha256 matched) and green was re-proven. Three of those mutations were UNCAUGHT on the first pass and are the reason the fixture has the entries it does: the `language_model` prefix swap needed one map entry PER DIRECTION, and the legacy substring exclusion rule had no case at all. Nothing consumes the resolver yet — no loader, no kernel selection, no forward path. W3 wires it. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [Claude Code]
No file overlap with W1; re-gated after the merge. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [Claude Code]
Brings the branch up to date before repairing the fresh-review findings on row/MODEL-NEMOTRON-H-W1 (#517). No file overlap with W1: the merge touches .agents/benchmark-record.md, .agents/specs/dspark-spec-decode.md, docs/BENCHMARKS.md and docs/STATUS.md only. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [Claude Code]
…nfig.json (#517) Repairs the FAIL from the fresh review of row/MODEL-NEMOTRON-H-W1 at f5c901c. The review confirmed all five resolution strategies against a verbatim upstream transcription -- 63,787 + 6,493 prefixes, 0 diffs -- and found one real defect plus four guarantees the suite did not hold. THE DEFECT. `Parse` gated on `ExtractQuantAlgo`, which mirrors `_extract_modelopt_quant_algo` (modelopt.py:245-263) and requires a top-level `quant_method` starting with "modelopt". That precondition belongs to the SELECTION hook: `override_quantization_method` uses it to tell a ModelOpt `quantization_config` apart from a compressed-tensors one sitting in the same field of the same config.json. Upstream's PARSER, `from_config` (:282-367), never inspects `quant_method` -- it dispatches on the SHAPE and reads `quant_algo` out of whichever shape that was. The driver checkpoint's own hf_quant_config.json -- the file `get_config_filenames()` (:265-267) actually names -- has top-level keys exactly {producer, quantization} and no `quant_method` anywhere. So the header threw std::invalid_argument: not a MIXED_PRECISION config (quant_algo="", quant_method="") on it, while upstream parsed it and resolved all 5981 entries. Detection and parsing are now separate: `ShapeQuantAlgo` for `Parse`, `ExtractQuantAlgo` for `IsMixedPrecision`. The old nested-shape test hid this by manufacturing `nested["quant_method"]` before asserting the nested path. That key is gone, so the case now tests the real shape, and a new exhaustive-arm case feeds the actual staged hf_quant_config.json. FOUR GUARANTEES THAT DID NOT HOLD. Each survived the reviewer's mutation with the suite green; each now has a case, proven by re-applying that exact mutation (all six shown red, then restored byte-for-byte): * scans run in INSERTION order (header divergence 3): loading the fixture with plain nlohmann::json flips synthetic.layers.2.self_attn from FP8 to W4A16_NVFP4, because sorted, k_proj comes first. * strategies 3 and 4 return the FIRST matching child: every prior parent had children that agree or whose first and last agree, so "return the last match" survived. New synthetic.layers.8.moe.{a,b}_proj disagree. * strategy 2's algo set spans ALL base candidates, unlike strategy 5: every prior fused entry had ONE prefix candidate, where the two shapes are indistinguishable. New language_model.model...q_proj (FP8) / model.language_model...k_proj (W4A16_NVFP4) splits the shards across the two spellings, so the union raises while a per-candidate rebuild would return FP8 and never see the second. * is_layer_skipped's `experts` branch (quant_utils.py:559-565): both inverting `e.find(prefix)` and deleting the branch survived. An `ignore` naming one expert CHILD must exclude the whole container -- that is the direction the rule actually has, and it is the true->false observable. FnMatch vs CPython, measured rather than assumed. Two differential sweeps against fnmatch.fnmatchcase: 3,183,165 pairs (names <=3, patterns <=5), 0 mismatches; 6,291,453 pairs (names <=2, patterns <=6), 108 across 20 patterns. All one class, all CPython-True/ours-False: a bracket whose contents reduce to a bare `!` after translate drops a REVERSED range, e.g. `[?-.!]` -> `(?s:.)\Z`. Recorded in the header and deliberately NOT fixed -- matching it means reproducing translate's rewriting, and ModelOpt emits no bracket expressions at all, so no reachable input touches it. Why a plain ctest skips the exhaustive arm: CHECKPOINT_ROOT is a `.env` key and nothing exports `.env`. The repo's documented loader IS `set -a; . ./.env; set +a` (.env.example, .agents/environment.md); there is no CTest-side .env reader, and tests/parity/hf_snapshot.h resolves a Hugging Face cache under $HOME rather than a NAS directory, so it does not apply. The skip banner now names the exact export instead of leaving it to be discovered. Gate: curated 26 cases / 167 assertions (was 22 / 137), exhaustive 3 cases / 12181 assertions (was 2 / 12145) with the checkpoint staged, clean Release -Werror rebuild, Debug ASan and Debug UBSan arms clean, full ctest 396/396. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [Claude Code]
…nding, re-gated) 21 commits landed on main while the W1 findings were being repaired (KERNEL-SSM-MAMBA W1, MODEL-V4-PRO-VARIANT, BENCH-ORACLE-PIN-RECONCILE). No file overlap with this branch: the repair touches only modelopt_mixed_precision.h, its two test TUs, its fixture, and the W1 note in .agents/specs/nemotron-h-model.md, none of which main moved. Clean Release rebuild and full ctest re-run after the merge. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [Claude Code]
…erge of the spec) (#517) `origin/main` moved to `fafa16f0f` while `row/MODEL-NEMOTRON-H-W1-FIX` was in round-2 review. The only overlap is the keyed record `.agents/specs/nemotron-h-model.md`, which main grew a `W7` worklist row, a `## 5a` gateability section and a `## 5b` owed-quantized-arms section in. AGENTS.md forbids accepting an automatic three-way merge of a keyed record, so this took main's file WHOLESALE (`git checkout origin/main -- <spec>`, blob `4b13b56d4`) and re-applied only the two scoped W1 regions, each anchored on a uniqueness assertion. A section-by-section verifier then proved the result: main sections : 12 merged sections : 12 PASS: exactly the 2 scoped sections differ; all 10 other sections byte-identical `## 5. Gates`, `## 5a`, `## 5b`, `## 6`, `## 7`, `## 8`, `## 0`, `## 1`, `## 3` and the preamble all hash-match main byte-for-byte. The merged tree differs from main in exactly the six files this row owns, with the same 1840/3 line counts the branch had against the merge base -- nothing of main's was dropped and nothing extra was added. REFUTED, on the way in: the hand-off claimed main had also moved `tests/CMakeLists.txt`. It has not. Between the merge base `4064558d0` and `origin/main`, `git log 4064558..origin/main -- tests/CMakeLists.txt` is EMPTY and both revisions point at the same blob `77d4fda9ab5577f9`, so there was no second conflicting record to reconcile. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [Claude Code]
…hat cannot exist, a CAPTURE that prints 1, and two env vars gating one checkpoint (#517) WIP land-prep for row/MODEL-NEMOTRON-H-W1. Committed early and deliberately: the previous attempt at this task completed every item and lost all of it to an out-of-session worktree sweep. LOW-1 -- the fnmatch divergence spans 27 patterns, not 20. modelopt_mixed_precision.h:253 and the same sentence in the spec both said the 6,291,453-pair sweep found 108 mismatches "spanning 20 distinct patterns". 20 is impossible on the sentence's own numbers: every divergent pattern translates to `(?s:.)\Z`, which matches a length-1 name and nothing else, so a pattern can contribute at most the 4 one-character names in the sweep alphabet and 20 caps out at 80. Re-measured independently on this branch against CPython 3.12 `fnmatch.fnmatchcase`, compiling the REAL header: SWEEP 1 names<=3 over {a,b,.,0} x patterns<=5 over {a,.,?,*,[,],!,-} cxx: names=85 patterns=37449 pairs=3183165 s1: 3,183,165 pairs, 0 mismatches, 0 distinct patterns SWEEP 2 names<=2 over {a,b,.,0} x patterns<=6 over {a,.,?,*,[,],!,-} cxx: names=21 patterns=299593 pairs=6291453 s2: 6,291,453 pairs, 108 mismatches, 27 distinct patterns direction (cpython, ours): {(True, False): 108} distinct translations: {'(?s:.)\\Z': 108} mismatching name lengths: {1: 108} 27 x 4 = 108, and all 27 have the shape `[X-Y!]` with X > Y. Both pair counts reproduce the recorded sweep exactly, so only the pattern tally was wrong. `FnMatch`'s BEHAVIOR is untouched; the divergence stays recorded and unfixed for the reason already given. LOW-2 -- `CAPTURE` on a `const char*` variable prints `1`. doctest 2.5.2 has no stringifier for a `const char*` lvalue. Two loops in test_modelopt_mixed_precision_checkpoint.cpp compared FIVE prefixes each through one, so a failure named none of them. RED, with the CHECKs inverted in a scratch copy: :172: ERROR: CHECK( c.Resolve(p).how != Resolution::kExcluded ) is NOT correct! logged: p := 1 :248: ERROR: CHECK( a.algo != b.algo ) is NOT correct! logged: p := 1 GREEN, the identical inversions after switching both loops to `const std::string` (matching :149 and :161, which already did): 1 logged: p := backbone.embeddings 1 logged: p := backbone.layers.0.mixer.conv1d 1 logged: p := backbone.layers.0.mixer.in_proj 1 logged: p := backbone.layers.1.mixer.experts 1 logged: p := backbone.layers.1.mixer.gate 1 logged: p := backbone.layers.42.mixer.o_proj 2 logged: p := backbone.layers.5.mixer.q_proj 1 logged: p := lm_head 1 logged: p := mtp.layers.0.eh_proj LOW-3(a) -- a documentation claim that was half true. The test said `.env.example` AND `.agents/environment.md` document the loader as `set -a; . ./.env; set +a`. `.env.example:8` does, verbatim. `.agents/environment.md` does not contain the string at all (`grep -n 'set -a'` exits 1); it points at `.env.example` at :16. The comment now cites `.env.example:8` and says so. LOW-3(b) -- two env vars reached one checkpoint and NEITHER carried the pin. `CHECKPOINT_ROOT` (this test, joining the staging directory by hand) and `VT_NEMOTRON35_SNAPSHOT` (`parity::Nemotron35LightningSnapshot()`) resolved the same NAS `local_dir`. The cache spelling in the accessor is unreachable for a `local_dir` tree -- there is no `snapshots/<rev>/` whose NAME carries the revision -- and an env override is deliberately never revision-checked, so `kNemotron35LightningNvfP4Revision` named the goldens' revision and could refuse nothing. That is the failure `kQwen27NvfP4Revision` exists because of. `hf download --local-dir` does record the revision, just not in the path: it writes a per-revision file manifest at `<dir>/.cache/huggingface/trees/<revision>.json`, verified present on the NAS tree. `Nemotron35LightningSnapshot()` is now the single resolver for both spellings and gates the `CHECKPOINT_ROOT` path on that manifest. Proven by construction, the manifest being the ONLY thing that changes between A and B: A) staged dir carries ONLY deadbeef....json EXIT=77 (loud skip) B) add 29f2d174....json, nothing else EXIT=0, 3/12181 C) VT_NEMOTRON35_SNAPSHOT at the real NAS dir EXIT=0, 3/12181 D) neither env var set EXIT=77, banner names the export AND the required manifest E) VT_ set to a nonexistent dir, CHECKPOINT_ROOT ok EXIT=77 (refuses, never falls back) `VT_NEMOTRON35_SNAPSHOT` keeps `HfSnapshot`'s documented escape semantics unchanged and is checked first: naming ONE directory outright is a deliberate different-checkpoint run, naming a ROOT is not, which is why only the root path is revision-gated. `tests/scripts/test_check_snapshot_pins.py` stays green -- `kNemotron35LightningNvfP4Revision` is still passed to `HfSnapshot` exactly once (19 passed, 80 subtests). `tests/parity/hf_snapshot.h` was RED on main as recently as #556 for an accessor declared before its dependency, and preflight does not build the parity TUs, so the checkpoint TU that now includes it was compiled with `-Wall -Wextra -Werror` as part of this change. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [Claude Code]
…owhere, and the three round-2 LOWs (#517) Round 1 of the W1 review returned findings 1-8. Findings 7 and 8 were answered in conversation and never written down, so the tree carried no record of why the resolver header sits under `src/` or why the exhaustive arm is opt-in. Both are now in the spec's W1 section, where they outlive the session: * Finding 7 -- header under `src/`, not `include/`. ACCEPTED by operator decision: `check-doc-checkpoint` classifies the whole `include/vllm/` prefix as user-facing and demands `docs/USAGE.md` move with it, nothing consumes the resolver yet, and it is not on the `include/vllm.h` ABI, so that edit would have documented nothing. Checker behavior tracked as #515. W3 MUST promote the header when it becomes consumed surface and pay the public-document obligation that genuinely applies then. * Finding 8 -- the exhaustive arm is opt-in because `CHECKPOINT_ROOT` is not exported. ANSWERED: the repo convention is `set -a; . ./.env; set +a` (`.env.example:8`), no new mechanism was invented, and the banner names the exact export. LOW-3(b) supersedes the part of it that claimed `tests/parity/hf_snapshot.h` did not apply -- it does, and it is now the resolver. The same section records the three round-2 LOWs with their evidence: the 27-not-20 arithmetic and re-measurement, the `logged: p := 1` RED and its named- prefix GREEN, and the A-E table proving the revision manifest is what decides whether the checkpoint arm runs. Also corrected in place: the "Why a plain ctest skips the exhaustive arm" paragraph credited `.agents/environment.md` with the `set -a; . ./.env; set +a` line and asserted `hf_snapshot.h` "does not apply". Neither was true. REPORTED, NOT FIXED -- outside this row's authority. `.agents/environment.md` :29-30 says `CHECKPOINT_ROOT` "states an INTENT and nothing more: no code in the tree reads `CHECKPOINT_ROOT`". The exhaustive arm reads it, and did before this branch. That file belongs to whoever owns it; the falsification is recorded in the spec rather than silently repaired here. The keyed-record merge is unaffected: the section verifier still reports `PASS: exactly the 2 scoped sections differ; all 10 other sections byte-identical`. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [Claude Code]
… opposite order to the code (#517) Comment only, no behavior change. The list numbered `CHECKPOINT_ROOT` first and then said `VT_NEMOTRON35_SNAPSHOT` "is checked first", which is exactly the kind of comment a reader has to re-derive from the code to trust. It now lists the three branches in the order the function tests them and states separately, once, that only the `CHECKPOINT_ROOT` branch is revision-gated and why. Release and sanitizer arms rebuilt and re-run for the four targets that include this header: test_modelopt_mixed_precision, test_modelopt_mixed_precision_checkpoint, test_hf_snapshot_pinning, test_qwen36_weights -- 4/4 Passed in each. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [Claude Code]
…e-run on the re-merged tree (#517) The re-merge moved `.agents/specs/nemotron-h-model.md` and nothing else this row owns, so the whole point of re-running is that the baselines do not move. curated 26 cases | 26 passed | 0 failed 167 assertions Status: SUCCESS! checkpoint 3 cases | 3 passed | 0 failed 12181 assertions Status: SUCCESS! Clean Release, CUDA off, `-Werror`: 1209/1209 built, ZERO warnings. Full ctest 402 tests / 401 passed -- `test_engine_core_proc` failed under `-j` and passed on a serial re-run, which is the documented starvation set, and `test_modelopt_mixed_precision_checkpoint` + `test_voxtral_e2e` correctly report Skipped with no `CHECKPOINT_ROOT`. Debug + `VLLM_CPP_SANITIZE=address,undefined`: the four targets this change touches are 4/4 Passed, including under CI's own `ASAN_OPTIONS=detect_leaks=1:strict_string_checks=1`, `UBSAN_OPTIONS=print_stacktrace=1`, `VT_POOL_BYPASS=1`. `scripts/agent-preflight.sh --staged`, `check-doc-checkpoint.py` and `check-commit-trailers.py --range origin/main..HEAD` all green. The whole-tree sanitizer run reports 39 LeakSanitizer failures in unrelated model/serving binaries. Recorded rather than hidden, and NOT attributed to environment on a hunch: `.github/workflows/ci.yml:775-793` marks `sanitize-cpu` `continue-on-error: true` explicitly so "a pre-existing finding cannot block unrelated work", and cites a live run whose conclusion is `success` with both sanitizer lanes `failure`. This change also cannot reach them -- the only `src/` file it touches is `modelopt_mixed_precision.h`, which `grep -rln` finds included by exactly two files, both of them its own tests, so every object in `libvllm.a` is byte-identical to one built from `origin/main`. All six claimed mutations RED against the re-merged tree, each applied to a fresh copy of the tree with its anchor asserted count==1 first: M1 Parse back on ExtractQuantAlgo FAILURE! 25 passed | 1 failed M2 plain nlohmann::json fixture load FAILURE! 163 passed | 4 failed M3 strategies 3+4 return the LAST match FAILURE! 163 passed | 4 failed M4 strategy 2 rebuilds the set per cand. FAILURE! 164 passed | 3 failed M5 e.find(prefix) -> prefix.find(e) FAILURE! 163 passed | 4 failed M6 experts branch deleted FAILURE! 163 passed | 4 failed M1 also REDs the exhaustive arm, and does it in the shape this repo has been bitten by: `assertions: 12152 | 12152 passed | 0 failed` -- a green-looking counter, because the case THREW and its remaining 29 assertions never ran. Only `Status: FAILURE!` and the exit code see it. The mutation table in the spec says so next to the row. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [Claude Code]
localai-bot
pushed a commit
that referenced
this pull request
Aug 13, 2026
…pec re-merged by hand (#517) Second re-merge of this land-prep: `origin/main` moved from `fafa16f0f` to `72e661ae4` while the W2 gates were running, and one of the two new commits is `1bc5ef82c` (#561), the W1 land-prep for THIS SAME ROW. It edits the same keyed record, exactly as the task anticipated. `.agents/specs/nemotron-h-model.md` was therefore merged BY HAND, per AGENTS.md ("take the target branch version wholesale and reapply your scoped edit; verify unrelated keys byte-for-byte. Never accept an automatic three-way merge of a keyed record"). Git's automatic resolution was DISCARDED -- `git checkout origin/main -- <spec>` first, then the three W2 regions re-applied with uniqueness-asserted anchors. Verified section by section (md5 per `##` block), 13 blocks: BYTE-IDENTICAL to main : preamble, 0, 1, 3, 4, 5, 5a, 5b, 6, 8 differ (W2's own) : 2 (one table row), 6a (new), 7 (Now) §4 now carries main's "W1 progress -- the resolver has LANDED" subsection and the W7 row; §5a (oracle gateability) and §5b (owed GGUF arm) are main's, unchanged. §6a is byte-identical to this branch's own W2 note. §7 is the one place both rows speak, and it is reconciled rather than overwritten: W1 has LANDED at `1bc5ef82c`, W2 is this branch in re-review. The only W2 edit to §2 is the routed-scale anchor the repair pass re-verified against the pin: `apply_routed_scale_to_output=True` at `nemotron_h.py:234`, factor `:233` (main still carried the pre-repair `:246`). Everything else auto-merged with no conflict, and the resulting delta vs `origin/main` is exactly this branch's eight W2 files. `tests/CMakeLists.txt` carries BOTH registrations (`test_modelopt_mixed_precision*` from W1 at :67-80, `test_ops_moe_nongated_relu2` at :1165), and `tests/parity/hf_snapshot.h` is byte-identical to main. No file in `src/vt/cuda/cuda_moe.cu`'s include closure moved -- it includes only `vt/ops.h` plus CUDA/std headers, and `vt/ops.h` is untouched by this merge -- so the CUDA arm the fresh reviewer compiled and GPU-verified on GB10 is unchanged. FOLLOWING_AGENTS_PROTOCOL Refs #517. Refs #561. Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [Claude Code]
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Land-prep for the ModelOpt
MIXED_PRECISIONper-module quant resolver (W1 of.agents/specs/nemotron-h-model.md), which a round-2 fresh review returned PASS on ate734fe9e. This branch carries that work re-merged onto currentmainplus the three LOW findings and the two round-1 dispositions that had no written record.Issue: #517. Spec:
.agents/specs/nemotron-h-model.md. Roadmap row:MODEL-TEXT-nemotron-h-nemotron-hfor-causal-lm.What is in here
origin/mainas a KEYED-RECORD mergefnmatchdivergence spans 27 patterns, not 20CAPTUREon aconst char*prints1The merge
mainhad moved tofafa16f0f. The only overlap is the keyed record.agents/specs/nemotron-h-model.md, whichmaingrew aW7worklist row, a## 5agateability section and a## 5bowed-quantized-arms section in. AGENTS.md forbids accepting an automatic three-way merge of a keyed record, somain's file was taken wholesale and only the two scoped W1 regions re-applied, each on a uniqueness-asserted anchor. A section verifier then proved it:The merged tree differs from
mainin exactly the files this row owns.REFUTED on the way in: the hand-off said
mainhad also movedtests/CMakeLists.txt. It had not —git log <base>..origin/main -- tests/CMakeLists.txtis empty and both revisions point at the same blob77d4fda9ab5577f9.LOW-1
20was impossible on its own numbers: every divergent pattern translates to(?s:.)\Z, which matches a length-1 name and nothing else, so a pattern contributes at most the 4 one-character names in the sweep alphabet and 20 caps out at 80 — below the 108 the same sentence reports. Re-measured independently against CPython 3.12fnmatch.fnmatchcase, compiling the real header:Both pair counts reproduce the recorded sweep exactly, so only the tally was wrong.
FnMatch's behavior is untouched.LOW-2
RED, with the CHECKs inverted in a scratch copy —
logged: p := 1, ten times. GREEN under the identical inversions after switching both loops toconst std::string, matching the two loops above them that already did:logged: p := backbone.embeddings,p := lm_head, and so on for all nine distinct prefixes.LOW-3
(a) The test credited
.agents/environment.mdwith documentingset -a; . ./.env; set +a..env.example:8does, verbatim;.agents/environment.mddoes not contain the string at all and instead points at.env.exampleat:16.(b)
CHECKPOINT_ROOTandVT_NEMOTRON35_SNAPSHOTreached the same NASlocal_dirand neither enforced the revision.hf download --local-dirrecords it at<dir>/.cache/huggingface/trees/<revision>.json, soparity::Nemotron35LightningSnapshot()is now the single resolver for both spellings and gates theCHECKPOINT_ROOTpath on that manifest:deadbeef….jsonEXIT=77, loud skip29f2d174….json, nothing else changedEXIT=0, 3 / 12181VT_NEMOTRON35_SNAPSHOTat the real NAS dirEXIT=0, 3 / 12181EXIT=77, banner names the export AND the manifestVT_set to a nonexistent dir,CHECKPOINT_ROOTvalidEXIT=77— refuses, never falls backtests/parity/hf_snapshot.hwas RED onmainas recently as #556 for a declaration-order break andagent-preflight.shdoes not build the parity TUs, so the TU that now includes it was compiled-Wall -Wextra -Werrorin both lanes.Gate
test_modelopt_mixed_precisionStatus: SUCCESS!test_modelopt_mixed_precision_checkpointStatus: SUCCESS!-Werrorctest(Release)test_engine_core_procstarved under-jand passed seriallyVLLM_CPP_SANITIZE=address,undefined, the four touched targetsASAN_OPTIONS/UBSAN_OPTIONS/VT_POOL_BYPASSscripts/agent-preflight.sh --stagedThe whole-tree sanitizer run reports 39 pre-existing LeakSanitizer failures in unrelated model/serving binaries — the state
.github/workflows/ci.yml:775-793markssanitize-cpucontinue-on-error: truefor. This change cannot reach them: the onlysrc/file it touches is included by exactly two files, both its own tests, so every object inlibvllm.ais byte-identical to one built fromorigin/main.Reported, not fixed — outside this row's authority
.agents/environment.md:29-30saysCHECKPOINT_ROOT"states an INTENT and nothing more: no code in the tree readsCHECKPOINT_ROOT". The exhaustive arm reads it, and did before this branch. Recorded in the spec; the file belongs to whoever owns it.🤖 Generated with Claude Code