Repository navigation
Add the GLM-5.3 Flash TrellisMX checkpoint and serve it on b12x's in-tree P8 runtime - #163
Open
brandonmmusic-max wants to merge 1 commit into
Open
brandonmmusic-max wants to merge 1 commit into
brandonmmusic-max wants to merge 1 commit into
Conversation
Problem brandonmusic/glm-5.3-flash-tr3-fp8 is a TrellisMX (procedural NPK) release of GLM-5.3 Flash, quantized directly from zai-org/GLM-5.3-Flash-BF16. It overlays per-layer, per-rank routed-expert sidecars (layers 3 to 45, one per TP4 rank) on a carrier/ directory that holds every other tensor as stored (BF16 projections and head, FP32 scalars), with a manifest and the encoder transform. The GLM recipe reads only the NVFP4 checkpoint, so Flare could not resolve, plan, verify or prepare this release. Serving it is a maintainer request. Resulting behavior - A glm-5.3-flash-trellismx checkpoint pins the release at 80cbe535, whose carrier chat template is byte-identical to the NVFP4 checkpoint's, so the recipe's insertion patch annotates it and preparation checks both the source and the result digest. Checkpoint gains tensor_parallel (sizes its storage fixes; this release plans and lists TP4 only) and overlay (the manifest schema it is published with). Local release directories resolve to it. cached and post-download verification require the canonical inventory: one sidecar per allocated layer and rank at its declared size, plus the encoder transform. - Detection checks the manifest (schema, checkpoint, allocation, MTP layer, carrier pin), the carrier index and config, geometry and the SwiGLU clamp of 10, the quantization config compared whole, and every sidecar header through a strict safetensors parse against the coupled contract and the transform digest. It reads the manifest once and hashes those bytes. Before loading, all ranks compare manifest and transform digests. - Loading reads each sidecar once, checks its size and SHA-256 against the manifest, and builds the tensors from those same bytes. Carrier tensors load as stored, MTP layer 45 takes the same path, and the draft keeps the target's BF16 head. - b12x's TrellisMX source format prepares each layer's experts; the plan must be SiLU with the clamp before SiLU at 10. On CUDA each layer and rank runs b12x's in-tree P8 runtime, built with b12x's declared GLM-5.3 Flash serving configuration (GLM53_SERVING_OPTIONS), which the recipe consumes rather than restates. Attach requires that the runtime resolved that configuration and uses in_tree_p8_backend(). The launch geometry is not a recipe setting: each capacity's plan races b12x's P8 launch configurations and fixes the winner before capture, and the plan declares the arena every P8 call carves its buffers from, which preparation sizes in the shared scratch arena. No runtime call runs at attach: the runtime declares every program a call of 1 to its capacity in rows reaches, and b12x preparation compiles those programs and installs them in the runtime before it freezes kernel resolution, so no capture compiles or allocates. No environment variable selects P8 behavior, and the mHC prefill route is left to b12x's autotuner. Compile workers receive attached bundles as b12x's inert descriptor, and only the preparing process runs the runtime. - The routed-expert record names the TrellisMX release that supplied its experts, and the recipe's TrellisMX geometry checks read that typed origin directly. - Each rank records the backend identity, b12x's serving configuration, and the attachment identities and resolved settings of its runtimes. Building that record fails if any TrellisMX layer lacks a live runtime. - The checkpoint declares the resident bytes preparation keeps: 10,046,638,288 bytes of expansion and 4,457,303,696 draft bytes. - scripts/qualify_glm53_trellismx.py runs the release's two test modules with the GPU and release cases enabled and fails unless every collected test ran and passed. - No Protocol Buffer schema or Helios code changes, so packages exported before this change load as before. Validation performed (NVIDIA main 6fa01a4, 2026-10-31) - CPU, CUDA_VISIBLE_DEVICES="", with the companion FlashInfer changes (c37d2d9ee and 9be301a77) installed: the full tests/ directory gives 64 failed, 4,326 passed and 2,515 skipped on this branch against 64 failed, 4,180 passed and 2,466 skipped on unmodified 6fa01a4 in the same environment, with identical failing ids. - GPU, one RTX PRO 6000 Blackwell Max-Q: scripts/qualify_glm53_trellismx.py against the release at 80cbe535 collected 192 tests and passed all 192, none skipped, in 26 minutes; its release cases detect, load and verify the published sidecars. - TP4 end to end on four RTX PRO 6000 Blackwell GPUs (two Max-Q, two Workstation Edition), with this change on NVIDIA main a161b17 before it was carried onto 6fa01a4, FlashInfer f5f5341d7 plus the companion changes (TrellisMX c37d2d9ee, mHC precision 9be301a77) and no mHC route pin. Apart from the mHC fix, that run's FlashInfer runtime differed from c37d2d9ee in comments, one validation error message and a trailing-padding clear span this geometry does not have, its FlashInfer tests predate the final tail test, and its Flare tree carried this change before a test-only adjustment. The build also carried changes this commit does not contain: the mixed Max-Q/Workstation tuning agreement (NVIDIA#150), retained warmup mapping reuse with its follow-up fixes (NVIDIA#154), the reasoning close-token output fix, and two local-only changes for this host (an override of torch's compile-package GPU-name comparison in ignition/preparation/aot.py for the two card names, and acceptance of this host's DeepSeek checkpoint's 2-D slab scale planes in ignition/components/weights.py and ignition/preparation/csf_checkpoint.py). - Export from an empty kernel cache passed in 41 minutes, with all 1,287 prepared requests and 122 serving graphs; every rank verified its sources and the package was signed. - Boot healthy in 104 s. Smoke NLL 1.5618 over 12 of 16 scored positions, equal to the previous export of this release. The smoke's greedy chat check spent its 512-token budget inside reasoning and returned no content. - Decode tok/s (llm-inference-bench v0.4.29) at context 0 and 8K: C1 189.2 / 218.4, C2 281.0 / 283.5, C4 377.2 / 383.7, C8 471.9 / 462.8, C16 594.5 / 590.3, C32 751.9 / 697.8, no errors; speculative acceptance over the bench was 0.68 (112,117 of 163,792 drafts, from the server's counters). Sieve coding peak median 229.7 tok/s (5 of 5). - Reliability at the model card's sampling: 12 bursts of 32 or 28 requests that restore one published prompt and 13 prompts of 99,208 tokens sent one at a time, 373 requests. 351 correct, 8 with an adjacent record number, 4 with a wrong record, and 10 the fixture grades corrupt (6 that spent the 1,024-token budget in reasoning, 3 that ended with the answer inside reasoning and no content, and 1 whose content repeats the right answer twice); 11 of the 13 long prompts were correct. None of the 373 replies carried a think tag in its content. Three bursts of 32 distinct prompts: 92 of 96 correct. There were no request or device errors. These figures measure the whole local system, not this change alone. Material limitations - Preparing and serving the release requires FlashInfer with the TrellisMX source format and the in-tree P8 runtime; the figures above also used the mHC TF32 projection precision fix, which keeps the mixing coefficients at FP32 accuracy on b12x's TF32 route. pyproject.toml and uv.lock keep upstream's LIL FlashInfer pin to main (f5f5341d7), this change adds no pin, and the release cannot be prepared until the TrellisMX change is on main. - GLM-5.3 Flash can generate its close token after reasoning has ended; without the separate change "Drop reasoning close delimiter tokens from visible content", that token appears in message.content. - Validated on SM120 (RTX PRO 6000 Blackwell) only; SM103, SM121 and Windows were not run. - The manifest lists no carrier digests, so carrier files get header checks only, as every other checkpoint does. Design-Signed-Off-By: Claude Opus 5.5 (Claude Code); design-review=1c01 Signed-off-by: Brandon M. Music <266531604+brandonmmusic-max@users.noreply.github.com>
7 of 11 tasks
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
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.
brandonmusic/glm-5.3-flash-tr3-fp8is a TrellisMX release of GLM-5.3 Flash, quantized directly fromzai-org/GLM-5.3-Flash-BF16with the procedural NPK codec. Flare could not resolve, plan, verify orprepare it: the GLM recipe reads only the NVFP4 checkpoint. This change serves it at the maintainer's
request. The release is a second checkpoint of the GLM-5.3 Flash recipe,
glm-5.3-flash-trellismx;ignition export glm-5.3-flash-trellismxprepares it andflare runserves it on four GPUs. Therelease, the codec and the P8 kernels are Brandon M. Music's; the b12x W4A8 trellis path they build
on is Luke Alonso's.
Change
carrier/holds every other tensoras stored (BF16 projections and head, FP32 scalars), and one sidecar per layer and TP4 rank holds the routed
experts, so only TP4 can load it.
Checkpointgainstensor_parallelandoverlay; local release directoriesresolve to the TrellisMX checkpoint, and cached and post-download verification require the canonical inventory
(one sidecar per allocated layer and rank at its declared size, plus the encoder transform). The recipe pins
release revision
80cbe535, whose carrier chat template is byte-identical to the NVFP4 checkpoint's, so therecipe's insertion patch annotates it and preparation checks both the source and the result digest.
and every sidecar header against the coupled contract. Loading reads each sidecar once, checks its size and
SHA-256 against the manifest, and builds the tensors from those same bytes. Every rank compares manifest and
transform digests before any of them loads.
prepared-program runtime for these experts) executes them. Preparation builds the runtime with b12x's declared
GLM-5.3 Flash serving configuration (
GLM53_SERVING_OPTIONS, which the recipe reads from b12x rather thanrestating), reads nothing from the environment, and attaches it under b12x's in-tree backend declaration once
the runtime has resolved that configuration. The launch geometry is not a recipe setting: each capacity's plan
races b12x's P8 launch configurations and fixes the winner before capture, and the plan declares the arena
every P8 call carves its buffers from, which preparation sizes in the shared scratch arena. Attaching runs no
runtime call: the runtime declares every program that a call of 1 to its capacity in rows reaches, and b12x
preparation compiles those programs and installs them in the runtime before it freezes kernel resolution, so
no capture compiles or allocates. Compile workers receive b12x's inert descriptor; only the preparing process
runs the runtime. The routed-expert record names the release that supplied its experts, and the TrellisMX
geometry checks read that typed origin. Each rank records the backend identity, b12x's serving configuration
and the attachment identities with their resolved settings, and refuses to report if a TrellisMX layer has no
live runtime. The mHC prefill route is left to b12x's autotuner, like every other recipe's.
which a release test checks against the prepared bundle, and 4,457,303,696 draft bytes.
scripts/qualify_glm53_trellismx.pyruns the release's two test modules with the GPU andrelease cases enabled and fails unless every collected test ran and passed.
Dependencies
runtime": required to prepare and serve the release.
pyproject.tomlanduv.lockare unchanged and keep Flare'sFlashInfer
@mainpin, so the release cannot be prepared until that change is on main.coefficients at FP32 accuracy when b12x's autotuner picks the TF32 mHC route; all figures in Validation used it.
</think>token after reasoning has ended, and without that change the token appears in
message.content.Validation
CUDA_VISIBLE_DEVICES="", companion FlashInfer changesc37d2d9eeand9be301a77installed): no test failsonly with this change.
scripts/qualify_glm53_trellismx.pycollected 192 tests and passed all 192,none skipped, in 26 minutes.
this change applied to NVIDIA main
a161b17f: the export from an empty kernel cache passed in 41 minutes and thepackage was signed; 443 of 469 reliability requests at the model card's sampling answered correctly, and none of
the 373 whose content was recorded in full carried a think tag; decode ran at 189.2 tok/s for one stream and
751.9 tok/s for 32 streams at context 0, Sieve coding peak median 229.7 tok/s.
Evidence
CPU: the full
tests/directory gives 64 failed, 4,326 passed and 2,515 skipped on this branch against 64 failed,4,180 passed and 2,466 skipped on unmodified
6fa01a49in the same environment, with identical failing ids; thefailures are this environment's (template fixtures and native-recipe contract generation are not set up here).
GPU: the qualification runs against the release at
80cbe535; its release cases detect, load and verify thepublished sidecars.
TP4 end to end: FlashInfer
f5f5341d7plus the companion changes (TrellisMXc37d2d9ee, mHC precision9be301a77); apart from the mHC fix, that run's FlashInfer runtime differed fromc37d2d9eein comments, onevalidation error message and a trailing-padding clear span this geometry does not have, its FlashInfer tests predate
the tail test in
c37d2d9ee, and its Flare tree held this change with a test-only difference. The build also carriedchanges this PR does not contain: the mixed Max-Q/Workstation tuning agreement (Treat Max-Q and Workstation Edition device names as one GPU when tuning #150), retained warmup mapping reuse with
its follow-up fixes (Reuse retained warmup mappings across compiled warmup #154), the reasoning close-token output fix, and two local-only changes for this host (an
override of torch's compile-package GPU-name comparison in
ignition/preparation/aot.pyfor the two card names,and acceptance of this host's DeepSeek checkpoint's 2-D slab scale planes in
ignition/components/weights.pyandignition/preparation/csf_checkpoint.py).made before this change. The smoke's greedy chat check spent its 512-token budget inside reasoning and returned
no content.
383.7, C8 471.9 / 462.8, C16 594.5 / 590.3, C32 751.9 / 697.8, no errors; speculative acceptance over the bench was
0.68 (112,117 of 163,792 drafts, from the server's counters). Sieve coding peak median 229.7 tok/s (5 of 5).
sent one at a time, 373 requests: 351 correct, 8 with an adjacent record number, 4 with a wrong record, and 10 the
fixture grades corrupt (6 that spent the 1,024-token budget in reasoning, 3 that ended with the answer inside
reasoning and no content, and 1 whose content repeats the right answer twice); 11 of the 13 long prompts were
correct, and none of the 373 replies carried a think tag in its content. Three bursts of 32 distinct prompts: 92
of 96 correct. No request or device errors.
parsed.
These figures measure the whole local system, not this change alone.
Limitations
Related pull requests