[Bizuayeu]

What this changes

GLM's config parser now reads quantization_config where EXL3 admission does: at the top level, else inside
text_config. cuda_exl3.zig's block(), behind isExl3 and admit (cuda_engine.zig:113), takes either, top
level first, but config.zig's parse read the top level only. A checkpoint that nests it was admitted as EXL3,
parsed with exl3 false, and the loader then asked it for NVFP4 dense weights (cuda_weights.zig:338). parse now
looks in the same two places in the same order. A top-level block parses as before.

• Issue: n/a (found reading glm cuda: EXL3 mcg experts at any whole-bit width, mixed by projection #2094's admission; asked on glm cuda: EXL3 mcg experts at any whole-bit width, mixed by projection #2094, where it was asked for on its own:
  glm cuda: EXL3 mcg experts at any whole-bit width, mixed by projection #2094 (comment)).
• Stacked on: main.
• atc overlap --json: against main 754c3e9a3, 3 clean, 7 conflicting and 40 unknown. Test-merged here, only Metal: a request's stats list its prompt pass widths, on every text family #2293
  conflicts with this branch and not with main: both add a line at the head of the CHANGELOG's Unreleased. The other
  conflicts are with main itself.

Checks on this head

• Head commit: 8ce2cfe4f, this commit on main 34d42fcc8. The tests below ran on be6e7dc01, the same commit on
  main d1e91b518; rebasing moved its CHANGELOG line to the new head of Unreleased, and the line now ends with this
  pull request's number. Nothing else changed.
• Lean checker, python3 tools/zig/lean_check.py, on the base and on this head: 325 on main 754c3e9a3 and 325 on
  this commit on it (3887db711), 0 new; 425 and 425 on d1e91b518 and be6e7dc01.
• Tests run, with the command and pass, fail and skip counts (Zig 0.17.0, Linux x86_64 under WSL):
  • zig build test: 559/559 steps; 7,303 passed, 0 failed, 61 skipped.
  • zig build test-golden (5/5 steps), test-exl3-cuda-host (7/7), compile-cuda-tests (10/10, native and
    -Dtarget=aarch64-linux-gnu) and compile-config-server (7/7): pass.
  • zig fmt --check build.zig zig: clean.
  • With quantBlock's text_config line removed, zig build test fails the new test and only it (7,302 passed,
    1 failed, 61 skipped).
• CI: green on 8ce2cfe4f, 7 of 7 (zig, zig-windows, zig-macos-dev-tools, fmt, release-paths and
  benchmark-clients on Ubuntu and Windows).
• Not run, and why: zig build test-exl3-prompt-host does not build on main d1e91b518 either
  (exl3_prompt_host.zig:59: missing struct field b32), with or without this commit. No CUDA device run (see
  Receipt).

Receipt

n/a: the change is where the config parser looks for quantization_config. No GLM EXL3 checkpoint I know of nests it
inside text_config, so none reaches the loader differently to run; a top-level block parses as before, the parse
test's first case. The parse test covers the nested form and the order (a top-level block naming another method wins
over a nested exl3 one, as block() reads it).

Checklist

• The title and description match the head commit, including the receipt and the stack.
• New tests fail before the change, pass after it, and skip cleanly without their dependency (with
  quantBlock's text_config line removed, zig build test fails the new test and only it; it has no dependency to
  skip on).
• Comments and docstrings are one line. No measurements or history in the source.
• No personal data, machine names, internal hosts or local paths in the diff or its commits. No AI attribution lines.

[ashhart]

Thanks @Bizuayeu, a good catch from reading #2094's admission. This is right:

• quantBlock reads quantization_config in the same two places, in the same order, as cuda_exl3.zig's block(). So admission and the parser can no longer disagree.
• A top-level block is returned first, so every checkpoint we serve today, which all carry it at the top level or not at all, parses exactly as before.
• Only a nested EXL3 block changes, from a failed load to an EXL3 parse.
• The test covers top level, nested, and top level winning over nested, and your planted removal fails it alone.

No device run is needed, since no checkpoint we know of reaches this differently. It goes in the landing queue now and lands once CI on this head is green. The one CHANGELOG conflict, with #2293, is the usual top-of-Unreleased one, and we'll take care of it at landing.

[ashhart]

/atc exchange 79c7a1a61668541f0dbef334bde927b878bcd584c285556938f92db932a0f1ae

[ashhart]

Thank you @Bizuayeu. This is merged into main with your commits under your own name, so you're listed as a TensorFold contributor. It ships in the next release, credited to you in the changelog and the release notes.