Onboard RadixArk/GLM-5.3-NVFP4 and derive its GB10 deployment projection

[gunbai-bot]

What this lands (option C cut, per the source hold and the parent's ruling)

The artifact authorities, the census, the runtime observation rows and the topology vocabulary land; no fit claim does. The projection module is an ideal even-split artifact screen with runtime placement explicitly unread, and the fit is a later PR's, backed by a per-tensor placement projection or a real load/memory-profile receipt.

Upstream authorities

• extdeps.zhipu.glm_5_3 — the base model Z.ai published (not Flash): GlmMoeDsaForCausalLM, the MoE shape read key-for-key from config.json at aca966e4…, the native FP8 manifest (141 shards, 755,632,050,320 bytes).
• extdeps.radixark.glm_5_3_nvfp4 — RadixArk's quantized redistribution in its own home, citing the base. DESIGN §3's external-decomposition rule keys on who can change the artifact; RadixArk can re-quantize and push tomorrow, so filing it under extdeps.zhipu would put facts Z.ai never published in a Z.ai-owned module. Manifest at 6e389189… (47 shards, 464,823,042,096 bytes), the modelopt NVFP4 config (4-bit weights and 4-bit input activations on BitWidth, group 16, fp8 KV), the 240-pattern ignore list modelled as eight module classes with "quantized" derived (answers [RoutedExperts]), one representative routed expert's twelve safetensors header entries, and the all-shard byte partition carried at its honest standing — TranscribedUncited with the executing header-census producer named as the read obligation.
• HubCheckpointManifest moves to extdeps.huggingface.hub (a Hub fact, not a GLM one); Flash, GLM-5.3 and RadixArk each own only their row.

Re-read from the source at the pinned revision (HF API ?blobs=true, config.json, hf_quant_config.json, every shard header by HTTP range). One correction to the brief: the ignore list also contains model.layers.78* — the nextn/MTP layer, whose 256 experts are bf16 (19.3 GB). Shape-derived bytes of one expert equal the header sum at byte grain; the derived routed-expert total equals the reported all-shard total (407,686,809,600; 87.7%).

Runtime observations (from the GLM performance lane's readings on the Group B head)

The exact-match join in the projection caught that Group B serves an image the corpus did not model: the tag resolves to sha256:c7d63d15… (repository gunbc-vllm-glm53-gb10, built 09-17), while the only modelled GLM runtime pinned the NoPE image sha256:41366caf…. This PR lands: glm53_derived_registry_reading (the full 378-name dump inside that config id; re-hashing reproduces the digest the lane quoted), GunbcGlm53DerivedGb10 + glm53_derived_row pinned through it, with source typed as PackageVersionClaimsRevision (the base's labels say VLLM_BUILD_COMMIT=unknown; RuntimeArtifactIdentity.source_revision became a RuntimeSourceStanding so a self-report is not spelled as an established lineage), ModeloptQuantizationModulePresent (module-file presence only) and an ungrounded FP4 probe row (torch.ops._C.cutlass_scaled_mm_supports_fp4 is absent from the build's op namespace — a blind instrument, never a negative), and architecture_asked_answer with a conflict arm.

Declared frontier, not repaired here: the launch planner, serving_compatibility's NoPE standing and the selection still name GunbcGlm53NopeDerivedGb10. The cutover is the arm owner's change (#11565 re-derives the pin through glm53_derived_tag); until it lands the old ExecutionCompatible receipt is true only of its old subject.

The screen (gunbc.spark.serving_fit_projection)

gunbc run --source-root dag --source-root src/v2 --entry dag/gunbc/spark/serving_fit_projection.dag --function radixark_nvfp4_gb10_readout

The screen carries two even splits — the full artifact (headers and the optional nextn/MTP population included) and a supplied payload (for RadixArk, the routed experts derived from the modelled expert layout) — and every outcome is advisory: the payload is an unbound caller figure (not a subject-bound receipt) and the capacity is a rounded free -g reading under another arm's utilisation policy, so neither can back a byte-exact wall. The only structural refusal left is a topology with no ranks.

• tp4: CALIBRATION REQUIRED — the full-artifact split (116,205,760,524 bytes/rank) exceeds the rounded budget (109,135,118,991 usable at 8400 bp of 121 GiB) by 7.07 GB, reported as an advisory; the routed-expert payload's split (101,921,702,400) is inside it. Which optional populations the serving mode loads decides it.
• tp8: CALIBRATION REQUIRED — both splits within budget (full-artifact 58,102,880,262/rank, pre-runtime artifact residual 51,032,238,729), placement unread; architecture registered and modelopt module file present are Established; the dense CUTLASS fp4 helper is NotEstablished (ungrounded discriminator) and is informational only — it neither establishes nor refutes the routed-expert path; the NVFP4 MoE kernel path is its own question, NotEstablished by construction, naming the ModelOpt MoE selector for this shape on SM 121 or a bounded expert-layer load. There is no admitting arm while placement is unread; missing corpus rows are FeasibilityModelingRequired, not refusals.
• Host-memory expert offload has no distinct tier on GB10 (UnifiedShared, from the catalog row); other strategies are unqualified, not refused; the uncached all-miss bound is 600 visits × 21,233,688 B = 12,740,212,800 B/token.

Where this disagrees with the brief: it mints neither "TP4 refuses" nor "TP8 fits" nor "51 GB of KV headroom" nor "more KV than the Flash arm" — those numbers were seeded by the brief; TP4's overrun is on a figure that includes populations the loader may not load, and the only producer that can mint KV is the engine's memory profile, which has no reading for any candidate.

Evidence

22 witnesses in test.claim.spark.serving_fit_projection_witness_test + 22 in the capability-probe module, green locally. REDs: zero ranks has no screen; the NoPE pin has no modelopt row and defers naming it while the serving pin establishes; full-artifact one byte over and payload one byte over are distinct advisories; a payload overrun is calibration-required, never structural; tp4 is calibration-required with the overrun reported and tp8 calibration-required naming the MoE path and placement; a checkpoint without a row is modeling-required; module-file presence never answers the kernel question; shape-derived expert bytes ≠ header bytes if group size, scalar count or projection count is wrong.

Not deployed, not downloaded, Group B untouched.

🤖 Generated with Claude Code

[briansrls]

SOURCE HOLD — #11570 @ 6d59ff8e5bb5a1eeabf0f36e10b4630b83f753b4

The artifact census is valuable and materially better than the parent brief: the child independently found the MTP/nextn layer, the bf16 expert population, the exact routed-expert bytes, and the actual serving-image mismatch. The deployment projection, however, promotes several lower bounds/transcriptions into an exact TP fit and asks the wrong kernel-capability question.

1. P0 — total artifact bytes divided by TP degree is not a per-rank load plan

project_weight_fit computes:

weights_per_rank = ceil(manifest.safetensors_bytes / ranks)

That assumes every safetensors byte:

• is loaded by this serving mode;
• remains resident in its on-disk representation;
• is partitioned evenly by tensor parallelism;
• has no replicated tensors;
• incurs no padding/swizzle/transformed-copy overhead;
• follows no expert-parallel placement law.

None of those are established. This checkpoint alone contains a ~19.9 GB nextn/MTP layer whose loading depends on runtime/model mode; norms, routers, scales, embeddings, and other tensors have topology-specific replication/sharding; NVFP4 kernels preprocess/pad weights. The artifact byte census is not the runtime residency census.

Therefore this fold cannot mint either TP4 refuses or TP8 fits. At most it gives an average-on-disk lower/upper screening bound, depending on which unused/runtime-added populations are considered. Build a per-tensor placement projection from the exact model loader/topology, or run a dry/model-load memory producer. Until then both topology fit verdicts are unestablished.

2. P0 — the residual is not “KV headroom”

usable_per_rank - artifact_bytes/rank is named kv_headroom_per_rank. Before KV, vLLM must fund runtime/non-torch memory, activations, CUDA graphs, communication workspaces, allocator rounding, transformed weight copies, and platform/host pressure. The current live arm itself demonstrates the gap between simple weight residual and actual “Available KV cache memory.”

Rename this to a pre-runtime residual bound. Only the vLLM memory-profile/layout producer may mint available KV bytes/tokens.

The input also claims byte-exactness while gb10_unified_pool_gib = 121 came from rounded free -g. Use an exact byte producer and bind it to the candidate host class/incarnation before describing byte-grain admission.

3. P0 — the FP4 probe is not the capability the actual runtime needs

The probe asks only:

torch.ops._C.cutlass_scaled_mm_supports_fp4

Its absence proves that this one CUTLASS op is not registered in the image. It does not answer whether this checkpoint can execute.

At vLLM 8d09804, NVFP4 linear dispatch includes multiple backends, including FlashInfer paths and an SM120+ B12x kernel. NVFP4 MoE has a separate selector with FLASHINFER_TRTLLM/CUTEDSL/CUTLASS/B12X, vLLM CUTLASS, Marlin, Humming, and emulation candidates. This checkpoint's own partition says only routed experts are NVFP4, so the load-bearing question is the exact ModelOpt NVFP4 MoE selector for this shape/topology/activation format—not a generic dense CUTLASS op.

Probe the actual runtime selection (select_nvfp4_moe_backend / exact kernel classes) or, preferably, a bounded real config/layer/model load using the checkpoint metadata. An absent CUTLASS symbol must not become the sole blocker when another installed backend may be valid.

4. P0 — ProjectionRefused conflates known impossibility with missing evidence

StaticCompatibilityAnswer correctly distinguishes MeasuredNegative from NotEstablished; project_deployment then collapses both into ProjectionRefused.

Fail-closed admission is correct, but the product standing must remain:

ProjectionImpossible
ProjectionCalibrationRequired / ProjectionIndeterminate
ProjectionAdmitsStatically

The current TP8 result is not “refused by the platform”; it is at best unqualified pending the right runtime selector/load observation.

5. P1 — the new runtime row launders an unknown build genealogy into a bare source revision

The row candidly says the base labels report VLLM_BUILD_COMMIT=unknown and that 8d09804 comes from vllm.__version__. It then places 8d09804 into RuntimeArtifactIdentity.source_revision, whose contract is the runtime's modeled lineage.

A package-reported version is useful evidence, but it is not the same fact as an established build-source revision. Split this into a standing (BuildSourceEstablished, PackageVersionClaimsRevision, BuildSourceUnknown) rather than filling a mandatory positive field. Likewise preserve the Docker history and probe outputs as raw/content-addressed receipts or mark them historical transcriptions.

architecture_asked_answer also folds multiple applicable observations with last-writer-wins semantics. Conflicting asked rows/dumps must produce a conflict standing, not whichever row appears later.

6. P1 — adding the row does not repair the live authority

This PR proves that the arm moved from the NoPE image to sha256:c7d63d15…, but it does not update the launch planner, compatibility standing, or selection consumer. The old ExecutionCompatible receipt is still available to current consumers, and the new row is used only by this projection.

A historical execution receipt may remain true for its exact old subject. What must change is the current desired/live authority and every consumer that claims to describe Group B now. Either include that cutover or name a source-level frontier and stop saying the corpus mismatch is repaired here.

7. P1 — GlmCheckpointManifest is single-homed in the wrong layer

Full GLM and the independently governed RadixArk artifact import their generic checkpoint-manifest shape/mint from extdeps.zhipu.glm_5_3_flash. That makes the base model and third-party redistribution depend on a sibling Flash product to describe ordinary Hub/safetensors facts.

“One authority” does not justify a product-specific home. Extract the generic shape to a neutral Hub/checkpoint module; let Flash, full GLM, and RadixArk each own only their concrete rows.

8. P1 — the expert-offload refusal is broader than its mechanism

UnifiedShared establishes that GB10 has no larger, separate local host DRAM tier. It does not prove every expert-offload strategy is impossible: remote expert placement, distributed expert parallelism, a bounded hot-expert cache, or NVMe-backed strategies are different mechanisms.

The 12.74 GB/token figure is a worst-case uncached read volume assuming every one of 600 expert visits misses and transfers a full expert. Carry it as that bound. Rename the verdict to LocalHostMemoryOffloadHasNoDistinctTier; do not call all expert offload refused.

9. P1 — the child re-derived the artifact, but copied the parent's deployment arithmetic

Independent and good:

• exact repository/shard totals;
• per-expert header spans;
• all-header routed-expert total;
• ignore classes;
• nextn/MTP population;
• 87.7% routed-expert share.

Still adopted from the parent rather than established:

• total bytes / rank as resident bytes;
• 121 rounded GiB as an exact byte pool;
• the current Flash arm's 0.84 policy as the candidate's natural fit policy;
• all residual memory as KV;
• unified memory as a refusal of every offload mechanism.

The measured partition itself is also stored as authored totals plus prose. Preserve the header-census program/output digest so the 407,686,809,600-byte result is re-derivable rather than another transcribed number that agrees with a second derivation.

10. P1 — module presence is weaker than quantization-path availability

A glob finding modelopt.py establishes a package file, not that the exact modelopt quantization config parses, registers, maps the ignore list, and selects valid linear/MoE kernels for this model. Keep module presence as its own observation; do not call QuantizationMethodShippedByRuntime established until the import/registry/config path runs.

Acceptance bar

1. Artifact bytes remain an artifact census; runtime fit is derived from an exact load/placement plan or a real load receipt.
2. Residual memory and KV capacity are separate standings.
3. The capability probe follows the exact ModelOpt NVFP4 MoE/linear selector for this image and checkpoint.
4. Missing evidence remains Indeterminate, distinct from measured incompatibility.
5. Runtime build lineage, architecture observations, and capability receipts preserve provenance/conflicts.
6. The current Group B runtime authority is actually cut over or explicitly left as a named frontier.
7. The generic checkpoint manifest moves out of the Flash product module.
8. Offload refusal is narrowed to the mechanism actually ruled out.

[briansrls]

SOURCE HOLD — current head f76d541b28b6add325e13a3ad8245a3227c77d4e

Re-review after the full 378-name architecture dump was added. That change legitimately strengthens the runtime registry evidence and removes the earlier “asked membership only” limitation. It does not repair the deployment-fit or runtime-capability findings in review 5244193184.

What the new commit fixes

• The live image now has a full ArchitectureRegistryReading, rather than two asked rows plus a transcribed count/digest.
• serving_arm may consume that registry dump at the intended strength.

Residuals on this exact head

1. Artifact bytes are still divided evenly by TP degree and called runtime resident weights. There is still no per-tensor TP/EP/replication/load projection, no exclusion of unloaded nextn/MTP tensors, and no transformed-weight/padding/runtime overhead. TP4 refusal and TP8 fit therefore remain unestablished.

2. The artifact residual is still named KV headroom. It excludes non-KV runtime, activation, graph, workspace, allocator and memory-pressure costs; the 121 GiB input is still a rounded live reading presented at byte precision.

3. The capability question is still one dense CUTLASS op. The exact vLLM revision has several NVFP4 linear backends and a separate multi-backend NVFP4 MoE selector. Since the artifact census says only routed experts are NVFP4, the actual ModelOpt MoE selector/configuration is the load-bearing path. An absent torch.ops._C.cutlass_scaled_mm_supports_fp4 cannot be the sole runtime blocker.

4. Missing evidence still becomes ProjectionRefused. Admission may fail closed, but the product standing must preserve Impossible versus Indeterminate/CalibrationRequired.

5. Build genealogy is still overstated: the image says VLLM_BUILD_COMMIT=unknown, while a package version claim is installed into the positive source_revision field.

6. The current Group B consumers are still not cut over. The PR models the new runtime row but deliberately leaves the launch planner, compatibility standing, and selection on the old authority; the stale current-state class remains live.

7. The generic checkpoint manifest still lives in the Flash product module. Full GLM and RadixArk import their generic shape/mint from a sibling product authority.

8. Expert-offload refusal is still too broad, and 12.74 GB/token remains a worst-case all-miss transfer bound. What is established is only that GB10 has no distinct larger local host-DRAM tier.

9. modelopt.py file presence still does not establish the exact ModelOpt config/selector/kernel path.

The architecture-dump improvement is good and should remain. The remaining acceptance bar from review 5244193184 stands.

[briansrls]

SOURCE HOLD — PR #11570 @ f76d541b28b6add325e13a3ad8245a3227c77d4e

The upstream decomposition is the strongest of the three child PRs. The RadixArk artifact has its own authority, the MTP/nextn omission was genuinely corrected, and the representative expert/header cross-check is useful. The deployment projection then promotes an ideal byte split and several historical transcriptions into claims stronger than they support.

1. P0 — total checkpoint bytes divided by rank count is not a residency proof

weights_per_rank_bytes = ceil(total_safetensors_bytes / ranks) assumes every byte in the checkpoint is evenly sharded across TP ranks. That is an ideal aggregate lower bound, not the runtime placement law.

The artifact contains components with different placement semantics:

• routed experts;
• shared experts;
• embeddings / lm_head;
• dense layers;
• attention and norms;
• nextn/MTP parameters;
• quantization scales and metadata.

Some may shard on different axes, some may replicate, and TP versus expert-parallel placement matters. EightSparkTp8 currently supplies only the integer 8. It does not prove how this architecture/runtime places each component.

Therefore neither of these is established:

TP4 requires exactly total/4 bytes per rank
TP8 requires exactly total/8 bytes per rank

Model a component population and a runtime/topology placement projection. The fit may expose an ideal lower bound while placement is unread, but it may not admit TP8 from division alone.

2. P0 — the remaining bytes are not “KV headroom”

The fold computes:

usable engine budget - checkpoint bytes

and names the result kv_headroom_per_rank. That residual also owes at least:

• runtime/non-torch memory;
• CUDA graph captures;
• activations/workspaces;
• collective and kernel buffers;
• allocator fragmentation/alignment;
• the resolved model-specific KV layout.

The live GLM work already established that available KV bytes are derived only after those terms are profiled/subtracted. The current 51.03 GB and 27.05 GB values are, at best, residual_budget_before_nonweight_allocations; they are not KV capacity and cannot be compared as “more KV than the live arm.”

This is exactly the same class as the withdrawn GPU KV cache size / context length arithmetic: a real aggregate is being given a more specific interpretation than its mechanism permits.

3. P0 — ProjectionRefused conflates impossibility, measured incompatibility, and missing instrumentation

TP4 has a structural fit refusal under this conservative budget. TP8 has a different standing: the artifact appears to fit under the ideal split, while the FP4 discriminator is ungrounded in this build.

Those must not share one constructor.

Use something like:

StructurallyRefused
MeasuredIncompatible
CalibrationRequired / ProjectionIndeterminate
StaticallyAdmitted

KernelProbeSymbolUngrounded is correctly not a negative answer. It should yield CalibrationRequired, not a deployment refusal. The trigger should be the smallest runtime-specific discriminator—potentially an exact ModelOpt FP4 load/kernel smoke—not an open-ended search for another magic symbol.

4. P0 — the new runtime row promotes a historical report into stronger artifact identity than it has

The row is keyed to a real Docker config ID, and it honestly states that VLLM_BUILD_COMMIT=unknown. It nevertheless fills runtime_artifact_identity.source_revision from the Python package version's g8d09804c8 suffix and carries a wheel-set reconstruction from prose/docker history.

Those are different evidence standings:

content identity: established by Docker config ID
package self-report: vLLM version string says g8d09804c8
base build provenance: unknown
observed derived layers: historical docker-history report
reproducible source-to-image chain: unestablished

Do not fill an exact source-revision field with a package self-report when the image's own build provenance says unknown. Either widen the artifact identity to carry claimed/self-reported/unknown separately, or keep this as an observed opaque runtime image with an explicit chain gap.

The report itself is also an authored record with a prose reported_by; the raw registry dump, docker inspect/history and probe outputs are not content-addressed carriers or outputs of an executing producer in this PR.

5. P0 — the corpus lie this PR discovered remains live

The PR correctly discovered that Group B serves sha256:c7d63d15…, while current launch/compatibility/selection authorities still name GunbcGlm53NopeDerivedGb10 / sha256:41366caf….

Adding a second runtime row does not repair that. After this PR, both identities exist while the live arm's authoritative consumers still point at the stale one. The old ExecutionCompatible receipt can continue to be read as current standing.

Preserve the old receipt as historical evidence, but bind current authority to a launch incarnation/time-validity relation or explicitly mark the stale current-standing projection superseded. The runtime row, launch planner, serving-performance subject, and compatibility consumer must converge on one exact current image.

6. P1 — module-file presence is too strong for QuantizationMethodShippedByRuntime = Established

The probe found modelopt.py in the package. That establishes a file/module-presence prerequisite. It does not establish that:

• the module imports;
• the quantization config dispatch selects it;
• this W4A4 scheme is recognized;
• required kernels/operators are available;
• this architecture can instantiate through it.

Keep separate standings such as:

QuantizationModuleFilePresent
QuantizationHandlerRegistered
CheckpointConfigAccepted
KernelPathEstablished

Architecture registry membership is likewise a registration prerequisite, not load compatibility. The final static admission should consume the strongest required facts without renaming weaker ones.

7. P1 — the all-shard “measured” partition is still a transcription in the corpus

The representative expert's 12 header entries are carried and independently cross-checked. The 407,686,809,600-byte routed-expert total and 19,905,841,664-byte nextn total are literals with a prose statement that all 47 headers were fetched and summed.

The readout command does not fetch or parse those headers, so the repository cannot re-derive those figures or go red if the pinned artifact changes. This is better research than the parent brief, but it is still a historical reported measurement at the artifact boundary.

Carry at least a content-addressed raw/header-index artifact plus a producer or generated projection. The witness should recompute the partition from that retained carrier, not merely compare one derived formula to one authored total.

8. P1 — expert offload is refused beyond what the mechanism proves

UnifiedShared proves there is no distinct larger host-DRAM tier behind the GPU, so classic GPU→host offload does not reduce the physical pool. It does not structurally prove that every alternative offload/storage policy is impossible.

The 12.74 GB/token figure is explicitly an uncached worst-case:

600 expert visits × one complete expert image

An implementation may cache hot experts, partition experts, prefetch, or use a remote tier. Those may still be commercially useless, but that is a performance/policy refusal, not a structural consequence of UnifiedShared alone.

Rename the structural result to NoDistinctHostDramTier; model NVMe/remote offload as unqualified unless a policy plus delivery envelope refuses it. Preserve the uncached bound as a bound, not the universal traffic law.

9. P1 — EightSparkTp8 is only a rank count

The projection says nothing about whether eight compatible GB10 ranks exist, form an admitted fabric group, carry the required image/checkpoint, or realize a qualified collective path. That is acceptable only if the output is explicitly a component-placement/memory projection, not a deployment projection.

A deployment projection should consume a qualified rank/fabric offer. Otherwise rename the product to IdealWeightFitProjection and leave deployment admission to the later join.

What was genuinely re-derived

The child did not simply copy the parent brief on these points:

• exact repository and safetensors byte populations;
• base GLM shape;
• representative routed-expert storage layout;
• group size 16;
• the missing bf16 nextn/MTP layer;
• the routed-expert share.

Those are valuable. The remaining adopted/transcribed facts are chiefly the live runtime report, FP4 AttributeError row, full 378-name roster, and all-47-header aggregate partition; their current prose names the instruments but does not make them reproducible producers.

Acceptance bar

1. Replace total/ranks with a component placement law, or downgrade the result to an ideal lower bound with placement unread.
2. Rename residual bytes; derive actual KV capacity only after non-weight memory and resolved KV layout.
3. Split structural refusal, measured negative, and calibration required.
4. Represent the c7d63 image as an opaque observed content identity unless exact build provenance is established; retain self-reported revision separately.
5. Reconcile/expire the stale current runtime and compatibility authorities in the same program.
6. Keep module presence, handler registration, config acceptance, and kernel support as distinct facts.
7. Retain an executable/content-addressed all-shard byte-partition producer.
8. Narrow the unified-memory offload conclusion and keep the uncached traffic figure as a bound.
9. Join any true deployment verdict to an actual qualified eight-rank fabric realization.

The correct immediate operator answer is currently:

TP4: conservative aggregate weight budget refuses.
TP8: ideal aggregate weight split appears to fit,
     actual placement and non-weight/KV budget remain unestablished,
     and FP4 execution requires calibration because the current probe is blind.

That is already useful and more honest than either “fits with 51 GB KV” or a hard FP4 refusal.

[gunbai-bot]

Addressed review 67503 (artifact /api/reviews/67503/artifacts/stdout.log) in 311f095: weight_width, input_activation_width and kv_cache_width are now std.measure BitWidth; the byte derivation reads bit_width_count over bits_per_byte(), and the fp8-scale and F32-scalar widths now come from extdeps.safetensors.format safetensors_dtype_byte_width on the dtypes the representative entries carry, so the module-local fp8_scale_bits / bits_per_byte_nat / f32_scalar_bytes rows (the same flat-scalar class, which the review did not have to name) are deleted too. The derived-equals-header witness still holds at byte grain (20/20 locally).

— sent from smart-crane-190

[gunbai-bot]

Addressed review 67520 (artifact /api/reviews/67520/artifacts/stdout.log) in 6570ecc — all three findings were right.

1+2. RuntimeImageReport / glm53_group_b_image_report are deleted. The one fact it carried without a home — modelopt module presence — is now ModeloptQuantizationModulePresent in RuntimeKernelCapability (label + probe-symbol arm, documented as module presence and never the kernel path) with a KernelObservedPresent row for the serving image's config id in glm53_derived_probe_rows, from the same run that found the FP4 discriminator missing. quantization_answer now asks capability_outcome by the runtime row's pin exactly as fp4_device_answer does, so a rebuilt image answers OutcomeUnrecorded rather than inheriting; the re-spelled version, architecture and id strings are gone with the report.

3. Fabricated zeros → refusals: ceil_div/weights_per_rank_bytes/project_weight_fit are partial (zero ranks ⇒ no projection, and project_deployment refuses "the topology has no ranks"); nvfp4_routed_experts_share_basis_points and nvfp4_share_of_native_basis_points answer none on an empty denominator; glm_5_3_moe_layer_count answers none for a dense prefix longer than the stack and the absence is carried through glm_5_3_routed_expert_visits_per_token, nvfp4_routed_experts_total_bytes and a new OffloadShapeUnprojectable arm. The s.num_hidden_layers - s.num_hidden_layers spelling is gone.

Witnesses: w_zero_ranks_has_no_projection is the RED for the zero arm; w_the_nope_runtime_has_no_modelopt_reading_and_refuses_by_name is the RED for the roster join (the NoPE pin has no modelopt row and refuses naming it, the serving pin establishes); w_module_presence_does_not_answer_the_kernel_question holds both answers in one projection. 21/21 projection and 22/22 capability-probe witnesses green locally. tp8 still refuses on the ungrounded FP4 discriminator alone.

— sent from smart-crane-190

[gunbai-bot]

Addressed review 67569 (artifact /api/reviews/67569/artifacts/stdout.log) in 3d74321: glm_5_3_model_id is deleted — confirmed by grep it had no consumer and duplicated glm_5_3_hub_repo.path; the Flash row it mirrored is consumed by the harness wire, this one was not. Readout re-derived unchanged.

— sent from smart-crane-190

[briansrls]

SOURCE HOLD — #11570 @ 3d743213a6af3b021880f54a45d48f99e0103f5e

The fixes for reviews 67503 and 67520 are real and should remain: bit widths are typed carriers; the duplicate runtime report was dissolved into the probe roster; zero-rank/empty-denominator cases now refuse instead of fabricating zeroes. The full artifact census and the MTP correction also remain valuable.

The earlier source hold on the deployment fit and KV conclusion is not repaired at this head. The current code still makes the same three promotions the hold named.

1. P0 — the projection still equates an even split of artifact bytes with runtime-resident weight placement

The operative path is still:

weights_per_rank_bytes(weights, ranks)
  = ceil(total_safetensors_bytes / rank_count)

project_on_gb10(...)
  = project_weight_fit(manifest.safetensors_bytes, topology_rank_count, ...)

and the witnesses still assert:

w_tp4_does_not_fit_the_live_utilisation
w_tp8_fits_the_live_utilisation

No component placement law or real load receipt has been added. The projection still does not answer:

• which checkpoint populations this serving mode actually loads, including the nextn/MTP population;
• which tensors are TP-sharded, EP-sharded, or replicated;
• how embeddings, lm_head, routers, norms, shared experts, scales and metadata are placed;
• whether the runtime pads, swizzles, transforms, or duplicates NVFP4 weights;
• what workspaces or runtime-owned weight representations remain resident.

EightSparkTp8 still supplies only the integer rank count. It does not supply a GLM-5.3/ModelOpt placement plan.

Therefore the current values are an ideal even-split artifact screen, not exact per-rank resident weights. They cannot mint either TP4 does not fit or TP8 fits as deployment facts.

Acceptable repairs include either:

1. model the exact loader/topology placement per component and derive residency from it; or
2. retain the current arithmetic but rename and type it at its actual strength, e.g. IdealEvenSplitArtifactScreen, with placement/runtime fit explicitly unestablished; or
3. consume a bounded exact model-load/memory-profile receipt.

2. P0 — the residual is still called KV headroom and compared as KV capacity

The type and consumers remain:

WeightsFitWithHeadroom { kv_headroom_per_rank }
kv_headroom_per_rank(...)
projection_leaves_more_kv_than_live_arm(...)

and fit_text still renders the residual as “bytes per rank left for KV.” The PR body likewise claims 51.03 GB/rank left for KV and more KV than the Flash arm.

But the arithmetic is only:

floor(rounded_121_GiB × 0.84)
- ceil(total_artifact_bytes / ranks)

Before KV, that residual still owes runtime/non-torch memory, activations, CUDA-graph reservation, collective/kernel workspaces, transformed weights, allocator rounding/fragmentation, and the resolved model-specific KV layout. The live vLLM memory-profile mechanism is precisely what derives available KV bytes after those terms; this projection does not consume it.

Rename the result to something like PreRuntimeArtifactResidual and remove every KV-capacity comparison. Actual KV headroom/capacity must come from a real load/memory-profile receipt plus the resolved layout.

The rounded gb10_unified_pool_gib = 121 input also cannot support byte-exact admission language. It is adequate for a coarse screen, not an exact byte wall.

3. P0 — an ungrounded FP4 instrument still becomes ProjectionRefused

The child reports that TP8 “refuses on the ungrounded FP4 discriminator.” That is exactly the distinction the previous review required the model not to collapse.

StaticCompatibilityAnswer correctly has:

MeasuredNegative
NotEstablished

but project_deployment feeds either non-established answer through unestablished_text into the same:

ProjectionRefused

used for the weight-fit refusal. The witness w_tp8_refuses_on_the_fp4_device_probe_alone makes that conflation an asserted product behavior.

Fail-closed admission is fine. The projection standing must nevertheless remain three-valued, for example:

ProjectionStructurallyRefused
ProjectionMeasuredIncompatible
ProjectionCalibrationRequired / ProjectionIndeterminate
ProjectionAdmitsStatically

TP8 is currently indeterminate/calibration-required, not known incompatible.

4. P0 — the FP4 discriminator is still not the runtime path this artifact needs

The sole FP4 question is still torch.ops._C.cutlass_scaled_mm_supports_fp4. Its absence establishes only that this one symbol is unavailable in this build's op namespace.

The artifact census says the NVFP4 population is the routed MoE experts. The load-bearing compatibility question is therefore the exact ModelOpt NVFP4 MoE/linear selector for this checkpoint shape, activation format, topology and runtime—or a bounded exact config/layer/model-load smoke. This vLLM revision has multiple possible NVFP4 backends; absence of one generic dense CUTLASS helper cannot decide the whole checkpoint path.

It is honest to retain KernelProbeSymbolUngrounded as the observation. It is not honest to let that one blind instrument be the sole reason a product called a deployment projection returns REFUSED.

What is mergeable from this work

The artifact-authority half is strong: base/RadixArk ownership, exact manifests, quantization classes, representative expert header accounting, the independently discovered MTP population, and the runtime registry evidence are useful. If the placement/memory/runtime-fit work is not ready, split or downgrade the projection rather than holding that artifact census behind claims it cannot yet support.

Merge-floor note

All four exact-head checks are green and GitHub reports the PR mechanically mergeable. That does not discharge the source hold: the witnesses currently prove the invalid stronger claims because those claims are what they assert.

Acceptance bar

1. Runtime fit is derived from an exact component placement/load mechanism, or the current total/ranks result is explicitly downgraded to an ideal artifact screen.
2. Artifact residual and actual KV capacity are distinct; no current field or witness calls the residual KV headroom.
3. Structural refusal, measured incompatibility, and missing calibration remain distinct top-level verdicts.
4. FP4 compatibility follows the exact ModelOpt NVFP4 MoE/linear selection path or a bounded real load, not one absent CUTLASS symbol.

Until those four are true, do not merge this deployment projection.

[gunbai-bot]

Reworked to the option-C cut in 3ce63b2, addressing the source hold (reviews 5244193184, 5244204775, 5244245607, 5245866328) point by point:

1. total/ranks is not a residency proof — the fold is now IdealEvenSplitArtifactScreen: a lower bound that can refuse a topology structurally (real placement only adds) and otherwise passes IdealSplitWithinBudgetPlacementUnread. No fit is minted anywhere; the module header lists exactly which placement facts (nextn loading, replicated tensors, TP vs EP, padding/transformed copies) are unread.
2. residual is not KV — renamed pre_runtime_artifact_residual; the KV-headroom comparison with the Flash arm is withdrawn (the serving arm's screen remains only as an input sanity check, labelled as such). The 121 GiB pool is stated as a rounded reading.
3. the FP4 question — renamed Fp4KernelPathEstablishedOnDevice; the remedy names the ModelOpt NVFP4 MoE selector for this shape on SM 121 or a bounded load of one expert layer, not the dense CUTLASS predicate; the ungrounded row stays ungrounded and is never the sole blocker (placement is always also unread).
4. verdict split — StaticFeasibilityStanding = RefusedStructurally / MeasuredIncompatible / CalibrationRequired, and no admitting arm while placement is unread. tp4 refuses structurally; tp8 is calibration required naming both the kernel path and placement. The old witness that asserted the conflation is replaced.
5. build genealogy — RuntimeArtifactIdentity.source is now a RuntimeSourceStanding; the serving image's row is PackageVersionClaimsRevision with the base's VLLM_BUILD_COMMIT=unknown stated; the key spells claimed:.
6. consumer cutover — declared frontier, not a repair: the annotation on the row names the launch planner, the NoPE compatibility standing and the selection as still pointing at the old runtime, with spark: group-B GLM native arm — RoCE transport, lane-built image, telemetry discharge, harness probe fix #11565 (arm owner) as the trigger.
7. manifest home — HubCheckpointManifest lives in extdeps.huggingface.hub; Flash, GLM-5.3 and RadixArk own only rows.
8. offload — NoDistinctHostDramTier with the all-miss figure carried as an upper bound; other strategies unqualified, not refused.
9. EightSparkTp8 is a rank count — stated on the variant and in the module header; there is no deployment verdict to join it to.
10. module presence — the question is QuantizationModuleFilePresentInRuntime and its evidence text says file presence only.
    Also: architecture_asked_answer has a conflict arm instead of last-writer-wins; the all-shard partition carries TranscribedUncited with the executing header-census producer as its read obligation (the executing producer itself is a follow-up).

Readout now: tp4 REFUSED STRUCTURALLY; tp8 CALIBRATION REQUIRED (kernel path + placement unread). 20/20 projection, 22/22 probe, 9/9 launch, 71/71 selection witnesses green locally.

— sent from smart-crane-190

[briansrls]

SOURCE HOLD — #11570 @ 3ce63b2a73888ff40d3869757fb65faedd3a17d8

The option-C recut is substantial and most of the prior hold is genuinely repaired:

• the result is now named an IdealEvenSplitArtifactScreen, not a runtime fit;
• placement and non-weight memory are explicitly unread;
• the residual is no longer called KV and the Flash/KV comparison is gone;
• structural refusal, measured incompatibility, and calibration-required are distinct arms, with no admitting arm;
• runtime-source standing, the neutral Hub manifest home, the architecture conflict arm, the transcribed partition standing, the narrowed host-DRAM conclusion, and the consumer-cutover frontier are all present.

It is not source-mergeable yet. Two load-bearing claims from the old projection still survive under the new names, and two generic folds contradict the new standing.

1. P0 — the full safetensors-file total is not a guaranteed-loaded lower bound, so TP4 is not structurally refused

The screen still uses:

manifest.safetensors_bytes / rank_count

and then promotes an over-budget result into:

FeasibilityRefusedStructurally

with the claim that “real placement can only add.” But this module itself states that the ~19.9 GB nextn/MTP population is loaded only when speculative decoding uses it. The input also includes safetensors file headers rather than only tensor payload. More generally, the exact loader may omit checkpoint populations as well as replicate, pad, transform, or add populations.

Therefore the full artifact total is not a lower bound on bytes that this serving mode must load. Runtime placement can be lower than this screen as well as higher. The original review explicitly left this distinction open: total/ranks is a lower or upper screen depending on unused versus runtime-added populations.

The current witness cements the unsupported promotion:

w_tp4_is_refused_structurally_on_the_screen

and the generic Hub authority now overclaims that safetensors_bytes is “what tensor-parallel ranks divide among themselves.” That is a runtime placement statement, not a Hub manifest fact.

Acceptable repairs:

1. make TP4 FeasibilityCalibrationRequired too, retaining “full-artifact even split exceeds the selected budget” only as a screening observation; or
2. derive a GuaranteedLoadedPayloadLowerBound from populations the exact loader necessarily loads, excluding headers and optional populations, and use only that lower bound for structural refusal.

A placement-unread screen may not say “real placement can only add” while its own source names a population that may not load.

2. P0 — the dense CUTLASS helper still answers the stronger ModelOpt NVFP4 MoE question

The prose correctly says torch.ops._C.cutlass_scaled_mm_supports_fp4 is not the load-bearing discriminator and names the exact ModelOpt NVFP4 MoE selector or a bounded expert-layer load as the required calibration.

The fold still maps the old probe as follows:

KernelObservedPresent
→ Established { question: Fp4KernelPathEstablishedOnDevice }

KernelObservedAbsent
→ MeasuredNegative { question: Fp4KernelPathEstablishedOnDevice }

So if this generic dense helper ever returns true or false, it still establishes or refutes the whole checkpoint’s routed-expert kernel path. That is the exact semantic promotion the earlier hold rejected; the current live row happens to be KernelProbeSymbolUngrounded, but the producer contract remains wrong.

Keep this observation at its actual strength—e.g. DenseCutlassFp4HelperSupport—and leave Fp4KernelPathEstablishedOnDevice unestablished, or replace its producer with the exact ModelOpt MoE selector / bounded expert-layer load. Neither a positive nor a negative answer from the current helper decides the stronger question.

3. P1 — missing model rows are classified as structural impossibility

project_static_feasibility currently maps:

no checkpoint row
no runtime row

into FeasibilityRefusedStructurally.

Those are missing corpus evidence, not impossible deployments. They belong in calibration/modeling-required standing (or a separate FeasibilityModelingRequired arm). Zero ranks can be structurally invalid; an unmodeled runtime cannot.

4. P1 — the CLI’s exit rule ignores the TP4 result it says it checks

The entry comment says success requires that neither projected row is structurally refused or measured incompatible. The implementation checks only:

standing_is_refusal(radixark_nvfp4_tp8())

Today TP4 is FeasibilityRefusedStructurally and TP8 is FeasibilityCalibrationRequired, so radixark_nvfp4_gb10_exit returns success while one of the two rows it prints is refused. Either check both rows, or rename/scope the entry explicitly to the TP8 candidate and remove the contradictory contract.

5. P1 — RuntimeSourceStanding is not applied consistently to the rows this PR migrates

The new type’s own rationale says a package self-report is not established build lineage. Yet gitcommit90_sm121_exl3_row is migrated to:

SourceRevisionEstablished

while its existing provenance says the revision is only what the community image self-reports and was not verified against that source tree. That should be PackageVersionClaimsRevision (or unknown), just as the new Group B row is. Widening the type while mechanically blessing an old self-report defeats the distinction.

6. P1 — the all-shard partition’s names still outrun its new standing

The carrier now honestly says TranscribedUncited, but the witness and comments still call it “measured” (w_routed_expert_total_derived_equals_measured, “the measured total”), and nvfp4_routed_experts_share_basis_points returns an unqualified number directly from that transcribed row. Rename the result/report at its actual standing or derive the share from the independently modeled expert layout; do not let a standing field coexist with stronger consumer vocabulary that ignores it.

Merge-floor note

GitHub reports this exact head mechanically mergeable. Exact-head workflow 35328477553 was still in progress at review time. CI does not discharge the source findings above.

Acceptance bar

1. TP4 structural refusal consumes a genuine guaranteed-loaded byte lower bound, or TP4 remains calibration-required and the artifact-total result stays only a screen.
2. The current dense CUTLASS helper cannot establish or refute the ModelOpt NVFP4 MoE kernel path.
3. Missing model rows remain missing evidence, not structural impossibility.
4. The executable entry’s status agrees with the rows it claims to evaluate.
5. Existing runtime rows are migrated to RuntimeSourceStanding at their actual evidence strength.
6. The reported all-shard partition is not called measured by consumers while it remains TranscribedUncited.

The recut is now close and the artifact-authority portion remains valuable. The remaining central issue is narrow: an ideal split of the entire on-disk artifact is not a structural lower bound when the exact serving loader may omit part of that artifact.

[gunbai-bot]

Review 5246214701's six blockers, in a78d25e:

1. tp4 not structurally refused — the screen now carries a guaranteed_payload (the derived routed-expert bytes: every mode loads them, no placement replicates them) beside the full artifact. Only GuaranteedPayloadSplitExceedsUsable refuses; FullArtifactSplitExceedsUsable is reported into the calibration text as non-dispositive. tp4 is FeasibilityCalibrationRequired (guaranteed payload 101.9 GB/rank inside the budget; full artifact 7.07 GB over). w_tp4_is_refused_structurally_on_the_screen is replaced by w_tp4_is_calibration_required_with_the_full_artifact_overrun_reported and a supplied-value RED: full-artifact one byte over is advisory, guaranteed one byte over is structural.
2. dense helper isolated — DenseCutlassFp4HelperSupport is its own question, labelled informational; Fp4MoeKernelPathEstablishedOnDevice is separate and NotEstablished by construction (no MoE-selector or expert-layer-load reading exists), and question_is_dispositive keeps a helper negative from ever making the tuple measured-incompatible.
3. missing rows — FeasibilityModelingRequired arm; zero ranks stays structural. Witness w_a_checkpoint_without_a_row_is_modeling_required.
4. exit entry — checks both rows.
5. gitcommit90 — PackageVersionClaimsRevision with its self-report stated.
6. partition naming — nvfp4_reported_partition, witness w_routed_expert_total_derived_equals_reported, and nvfp4_routed_experts_share_basis_points now derives from the modelled expert layout (shape × representative expert), returning Nat?.

21/21 projection, 22/22 probe, 9/9 launch witnesses green locally; readout now reads tp4 and tp8 both CALIBRATION REQUIRED.

— sent from smart-crane-190

[briansrls]

SOURCE HOLD — #11570 @ a78d25e34735383e4ce36db3774125eb96c19528

The six repairs from review 5246214701 are genuinely present and should remain:

• TP4 and TP8 are calibration-required rather than admitted/refused from the full-artifact split;
• the full-artifact overrun is non-dispositive;
• the dense CUTLASS helper is informational and cannot decide the separate NVFP4 MoE path;
• missing checkpoint/runtime rows are modeling-required;
• the CLI checks both rows;
• gitcommit90 carries a package-version claim rather than established lineage;
• the all-shard partition is consistently reported/transcribed, and the share is derived from the modeled expert layout.

The PR is close, but it is not source-mergeable yet. The remaining blockers concern the new GuaranteedLoadedPayload authority used to mint structural refusal.

1. P0 — the structural-refusal payload is caller-supplied and not bound to its checkpoint/runtime/load policy

project_static_feasibility accepts independently writable values:

checkpoint
runtime
manifest
guaranteed_payload: ByteSize

and screen_ideal_even_split may mint:

GuaranteedPayloadSplitExceedsUsable
→ FeasibilityRefusedStructurally

There is no typed join proving that guaranteed_payload belongs to that checkpoint revision, describes the exact runtime's load semantics, or is required to reside in the selected ranks' local/unified pools. A caller can pair the RadixArk checkpoint with another manifest or with guaranteed_payload = 0, and the structural result changes without a refusal.

The current RadixArk caller supplies the derived routed-expert artifact bytes. That establishes an artifact component population; it does not yet establish the stronger runtime fact “these bytes must be resident across this candidate's rank pools under every admitted mode.” The same PR explicitly leaves NVMe/remote/cache/offload strategies unqualified, so “guaranteed loaded under any mode” is not a consequence of the modeled artifact alone.

Introduce a subject-bound receipt, for example:

GuaranteedResidentPayloadReceipt {
  checkpoint + exact revision
  runtime / loader policy
  topology or placement domain
  offload/residency policy
  component population
  bytes
  evidence standing
}

or keep the routed-expert split as an advisory artifact screen. Structural refusal may consume only a receipt that proves the payload must reside in the capacity domain being screened. Add reds for wrong checkpoint/revision and for an unqualified/offloaded residency policy.

2. P0 — the capacity side still cannot support a byte-exact structural refusal

The screen compares against:

gb10_unified_pool_gib = 121

which its own source says came from rounded free -g, and applies the current Flash arm's 8400-basis-point policy to the candidate. The comments correctly say this is not a byte-exact admission input, but the generic fold can still turn a small overrun into FeasibilityRefusedStructurally.

A rounded lower-bound/point reading cannot prove that the exact usable capacity is below a payload near the boundary. Either:

• carry an exact byte-capacity receipt and a candidate-owned utilization policy; or
• carry the pool as an interval/standing and keep the result calibration-required unless the guaranteed lower bound exceeds the maximum possible usable capacity.

The current TP4 specimen does not take this structural arm, which is good; the generic authority nevertheless remains writable and unsound for the next candidate.

3. P1 — the neutral Hub authority still contains the placement claim this recut withdrew

extdeps.huggingface.hub still says:

safetensors_bytes is what tensor-parallel ranks divide among themselves

That is not a Hub manifest fact and directly contradicts the option-C distinction: tensor populations may be optional, replicated, TP/EP-sharded, transformed, padded, or offloaded. The neutral authority should say only that safetensors_bytes is the summed on-disk safetensors-file population at the pinned revision. Runtime placement belongs to the later placement/load receipt.

Acceptance bar

1. Structural refusal consumes a checkpoint/revision/runtime-policy-bound guaranteed-resident payload, or the routed-expert split remains advisory.
2. Structural capacity comparison consumes exact/appropriately bounded capacity plus a candidate-owned utilization policy.
3. Remove the runtime-placement assertion from HubCheckpointManifest.
4. Add the mismatched-subject/residency and capacity-bound discriminating witnesses.
5. Exact-head CI must be green and the outstanding change-request reviews superseded.

No issue remains with the six repairs reported in the handoff. The remaining distinction is narrower: a modeled artifact component is not yet a runtime-guaranteed resident payload, and a rounded host-memory reading is not yet a byte-exact structural wall.

[gunbai-bot]

Review 5246439640's three points, in bdbe4e0:

1. unbound payload — taken the second option: the payload split is advisory and cannot mint FeasibilityRefusedStructurally. Both splits report into the calibration text (screen_advisory_text); the only structural refusal left is a topology with no ranks. w_a_payload_overrun_is_calibration_required_not_structural is the RED (payload = repository total at 100 bp ⇒ calibration required, overrun reported). The subject-bound payload receipt that would let a split refuse is named in placement_unread_obligation.
2. rounded capacity — with every byte figure advisory, the rounded 121 GiB × 8400 bp backs no wall; the module header says so, and the obligation names an exact byte-capacity receipt with a candidate-owned utilisation policy.
3. hub annotation — narrowed: safetensors_bytes is the sum of the safetensors files' bytes at the exact revision, repository_total_bytes the sum over every snapshot file; what a runtime loads, shards or replicates is a placement fact owned elsewhere.

22/22 projection witnesses green locally; tp4 and tp8 both CALIBRATION REQUIRED.

— sent from smart-crane-190

[briansrls]

SOURCE HOLD — #11570 @ bdbe4e0c80b8cfbd239110b04cc0c0d12aa5337d

The three findings from review 5246439640 are repaired at the behavior level:

• neither the full-artifact split nor the supplied-payload split can currently mint a refusal;
• a payload overrun remains FeasibilityCalibrationRequired, with the exact-capacity/candidate-policy obligation named;
• HubCheckpointManifest now states only the two Hub byte sums and makes no runtime-placement claim.

The remaining block is that the old verdict/refusal authority still exists in the public model and in the annotations, even though the new ruling says every screen result is advisory.

1. P0 — “screen results cannot refuse” is mechanically arranged, not structurally represented

The module now says:

THREE ADVISORY OUTCOMES. None is a verdict.

but the type is still named IdealEvenSplitVerdict, the screen field is still verdict, and StaticFeasibilityStanding still exposes:

FeasibilityRefusedStructurally {
  screen: IdealEvenSplitArtifactScreen?,
  ...
}

project_static_feasibility still contains a Present screen -> FeasibilityRefusedStructurally branch through screen_refusal_text; that function merely returns none in every current arm. So the property is maintained by an all-none helper, while the public standing still permits a caller to author a structural refusal carrying any screen.

This is the same class the preceding reviews have been removing: the stronger interpretation remains writable even though the current producer promises not to select it.

Make the advisory status the structure:

• rename IdealEvenSplitVerdict / .verdict to a standing or advisory outcome;
• remove the screen-refusal seam and its unreachable branch;
• either remove FeasibilityRefusedStructurally until a real structural producer exists, or restrict it to a typed structural cause such as TopologyHasNoRanks that cannot carry a byte screen.

At current ServingTopology, every variant has a positive rank count, so there is no live positive producer for that arm anyway; the low-level zero-rank red does not justify a freely writable screen-based refusal in the projection result.

2. P1 — several annotations still state the superseded refusal semantics

The source still says all of the following:

• “What survives is the lower-bound refusal”;
• “THE ARITHMETIC ROUNDS IN THE REFUSING DIRECTION” and that another rounding could “pass a tuple”;
• after correctly saying only zero ranks can refuse, “So: a structural refusal when the ideal split already exceeds the budget.”

The witness also retains “ROUNDING GOES THE REFUSING WAY” and names the payload-overrun local structural, although that outcome is now explicitly advisory.

These directly contradict the implementation and the rewritten PR body. Remove or restate them at the new strength; this repository treats annotations as source claims, and this PR exists because the earlier prose/number promotion was too strong.

Merge floor

Exact-head workflow 35332189409 is still pending.

Acceptance bar

1. Advisory screen outcomes are named and typed as advisory, not as a verdict.
2. No public screen-carrying constructor or all-none seam preserves the old byte-based structural-refusal path.
3. Stale refusal/pass annotations and witness-local naming are corrected.
4. Exact-head CI is green.

The substantive option-C recut is now correct: TP4 and TP8 are both calibration-required, no KV figure is minted, the MoE selector remains unestablished, and the Hub layer no longer claims placement. The hold is on making that new boundary structural and internally consistent rather than a promise layered over the former authority.

[gunbai-bot]

Review 5246614103's three points, in c3fb0e8:

1. IdealEvenSplitVerdict → IdealEvenSplitAdvisory, field .verdict → .advisory.
2. screen_refusal_text and the screen-to-refusal branch are deleted. FeasibilityRefusedStructurally now carries a typed StructuralRefusalCause (TopologyHasNoRanks is its only variant) and no screen field, so a byte screen cannot be a refusal's cause by construction rather than by an all-none function; a real structural producer would add a variant, never a string.
3. Stale prose corrected in the module ('lower-bound refusal', 'REFUSING DIRECTION', 'byte-exact test refuses', 'structural refusal when the ideal split…') and in the witness ('REFUSING WAY', the 'structural' local).

22/22 projection witnesses green locally.

— sent from smart-crane-190

[briansrls]

SOURCE SIGN-OFF — #11570 @ c3fb0e80ae39eb867dc554a581a312880948dd4c

Review 5246614103 is discharged on this exact head.

Verified:

• the byte-screen result is now IdealEvenSplitAdvisory carried as .advisory, so its type no longer presents an advisory as a verdict;
• screen_refusal_text and the screen-to-structural-refusal branch are gone;
• FeasibilityRefusedStructurally carries only StructuralRefusalCause, currently TopologyHasNoRanks, and has no screen field, so a byte screen cannot become a structural cause by construction;
• the projection fold mints that structural arm only when the topology yields no per-rank screen; otherwise byte-screen outcomes flow only into calibration text;
• the stale lower-bound/refusing-direction/structural-overrun prose and witness-local naming are corrected;
• TP4 and TP8 remain calibration-required, placement/non-weight memory remain unread, no KV or deployment-fit claim is minted, and the MoE selector/bounded expert-layer load remains the named discriminator.

No blocking source defect found. The old change-request reviews are superseded by this approval for this exact SHA.

Merge-floor note: exact-head CI must still complete green, and the head must remain unchanged. The PR body currently says 21 serving-fit witnesses while the handoff reports 22; that metadata count is worth correcting, but it is not a source blocker and does not require a code-head change.

[gunbai-bot]

Review 67660 (artifact /api/reviews/67660/artifacts/stdout.log), in 178fed0 — all three were right, and the first was a real red I should have run:

1. EightSparkTp8 joins w_every_modelled_topology_round_trips_through_its_rank_count, and w_an_unmodelled_rank_count_refuses_rather_than_choosing_the_nearest now asks for 16 — a count the roster still does not carry — so the RED keeps discriminating. 33/33 in that module.
2. nvfp4_routed_experts_share and nvfp4_share_of_native return BasisPoint?, scale from basis_point_unity_count(); the 10000 literals are gone.
3. The partition's read_obligation now says plainly that no header-fetching producer exists in the repository and that the witness reading it is a consistency check between a derivation and a transcription, not a verification; the witness is renamed w_derived_routed_total_is_consistent_with_the_reported_census with the same statement.

22/22 projection witnesses green.

— sent from smart-crane-190

[briansrls]

SOURCE SIGN-OFF — exact head 178fed054650f263ec678508603d5738d763828b.

The one-commit delta from approved c3fb0e8 is coherent and limited to the three reported files:

• EightSparkTp8 is enrolled in the topology round-trip control, and the unmodelled-count red now uses 16. This restores the witness's discrimination after TP8 became a modeled topology; it does not weaken the refusal rule.
• The two share folds now return BasisPoint values and derive their scale from basis_point_unity_count(). Their consumers unwrap through basis_point_count, so the unit is carried rather than encoded in a Nat plus a 10000 literal.
• The RadixArk partition remains TranscribedUncited, but its standing and witness now say exactly what exists: a derivation is consistent with a transcribed census; no executing header producer exists here, so the comparison verifies neither source and cannot go red on artifact movement.

No fit/admission/KV/runtime-placement semantics from the previously approved head changed, and I found no new blocking source defect. Exact-head CI is still pending and remains the merge-floor condition.

[gunbai-bot]

Review 67671 (artifact /api/reviews/67671/artifacts/stdout.log), in 4101b70: the NoPE-derived row is now PackageVersionClaimsRevision (revision = the version string's trailing token, with runtime_defaults' own sentence about it in build_provenance), and so is the sparkrun row, whose 1967a5627 is the same class — its claimed_defaults_revision annotation already said it was not evidence of the bytes. runtime_source_key therefore spells both claimed:. The one row left as SourceRevisionEstablished is the stock vllm/vllm-openai image, whose revision is the recipe's cited integration commit for upstream's own digest — a publisher statement, not a package self-report; if that also reads as a claim to you, say so and I will retype it. 22/22, 9/9, 22/22 in the three consumer modules.

— sent from smart-crane-190

[briansrls]

SOURCE SIGN-OFF — exact head 4101b70194bee64943c099c3e4bc7d3de7f6a9a9.

The one-commit delta from approved 178fed054650f263ec678508603d5738d763828b is coherent and confined to dag/gunbc/spark/serving_arm.dag.

Verified:

• gunbc_sparkrun_ds4_row now carries PackageVersionClaimsRevision; its revision is explicitly the trailing token of the installed vLLM package version, and the provenance no longer promotes that report into byte-verified build lineage.
• glm53_nope_derived_row now carries PackageVersionClaimsRevision; its derived FlashInfer layer remains modeled separately while the base vLLM revision is correctly limited to what vllm.__version__ reported inside the image.
• The existing gitcommit90_sm121_exl3_row and current Group B glm53_derived_row already use the same claimed-revision standing, so the self-reported-runtime class is now treated consistently.
• The only remaining SourceRevisionEstablished runtime row is the stock vllm_openai_glm53_flash_row, whose revision comes from the upstream GLM/vLLM recipe authority rather than an installed-package version string.
• No checkpoint, topology, artifact-screen, feasibility, KV, FP4, or deployment-admission behavior changed from the previously approved head.

No blocking source defect found. Exact-head CI is still pending and remains the merge-floor condition; approval covers this SHA only.

[briansrls]

SOURCE SIGN-OFF — exact head a1c6b27790f2d639ce0ae4b94909e1d9bd483a0a.

The one-commit delta from approved 4101b70194bee64943c099c3e4bc7d3de7f6a9a9 removes only the unused glm_5_3_architecture_class import from gunbc.spark.runtime_architecture_registry_reading. No declaration, producer, observation, runtime-identity, artifact-screen, feasibility, witness, or admission behavior changes.

No new blocking source defect found. This approval supersedes my prior exact-head approval for the current SHA. Exact-head CI and GitHub merge admission remain the merge-floor conditions.