AGENTS.md makes the merged-GEMM seam a MUST-route:
Route mergeable MLP projections through layers::MlpGateUpMethodBase and
vt::MergedGemmGroup. ... If a shared seam cannot represent the upstream
behavior, extend it or record one exact tracked exception. Never hand-roll a
parallel path.
Today scripts/check-fusion-consistency.py reports:
OK (merged-gemm): 15 model TUs carry a gated MLP epilogue;
6 route gate-up through a shared merged-GEMM seam, 11 allowlisted.
11 of 15 bypass the seam. The gate is green because each is allowlisted — which
is the intended design (drift must be conscious and reviewable), but an allowlist
that holds most of the population is a seam in name only.
The allowlist splits into two very different groups
Group A — no blocker, just unfolded. Five entries whose stated reason is
pending FOLD-MIGRATE and nothing else. All are plain dense SwiGLU MLPs that the
comment itself says should be UnquantizedMlpGateUpMethod:
commandr # SwiGLU {gate;up;SiluAndMul}, merged gate_up present -> UnquantizedMlpGateUpMethod; pending FOLD-MIGRATE
glm4 # SwiGLU dense MLP -> UnquantizedMlpGateUpMethod (also on the glue allowlist); pending FOLD-MIGRATE
minicpm # SwiGLU dense MLP -> UnquantizedMlpGateUpMethod; pending FOLD-MIGRATE
minicpm3 # SwiGLU dense MLP (MLA arch) -> UnquantizedMlpGateUpMethod; pending FOLD-MIGRATE
phi3 # SwiGLU dense MLP -> UnquantizedMlpGateUpMethod (also on the glue allowlist); pending FOLD-MIGRATE
Group B — genuine architectural blockers, documented well. gemma4_moe,
laguna, minimax_h3_device, minimax_h3_video_vae_device,
minimax_h3_encoder_device, and gemma4_vision each name a specific reason the
seam cannot represent them today: f32-end-to-end activations plus rank-1 biases
the bias-free method has no slot for; ggml block-quant weights against a method
that is "by name and by contract the UNQUANTIZED arm"; a weight-residency
ownership difference (OwnedTensor/ResidentWeight vs up-front device staging).
Those are correctly parked — folding them means extending the shared layer, which
is its own work.
Scope
Fold Group A only: route the five listed models' gate/up through
layers::UnquantizedMlpGateUpMethod and remove their entries from
scripts/merged-gemm-consistency-allowlist.txt, taking the count from 6/15 routed
to 11/15 and shrinking the allowlist to the entries that state a real blocker.
Explicitly OUT of scope: every Group B entry. Extending the seam with an f32 arm,
a bias arm, a keep-quant arm, or a residency arm is a shared-layer change, not a
model fold, and each deserves its own row.
Row: FUSION-DENSE-MIGRATE under ROAD-V1-C1 — punch-list item 15 in
specs/roadmap-v1-completion.md,
whose non-blocking tail names "FUSION-DENSE-MIGRATE (route 5 drift models)".
The count matches exactly.
Gate: CPU reference backend, token-exact — each folded model's existing paged-engine
test must stay byte-identical, since this is a routing change and not a numerical
one. check-fusion-consistency.py must report the higher routed count with the
five entries gone.
AGENTS.md makes the merged-GEMM seam a MUST-route:
Today
scripts/check-fusion-consistency.pyreports:11 of 15 bypass the seam. The gate is green because each is allowlisted — which
is the intended design (drift must be conscious and reviewable), but an allowlist
that holds most of the population is a seam in name only.
The allowlist splits into two very different groups
Group A — no blocker, just unfolded. Five entries whose stated reason is
pending FOLD-MIGRATEand nothing else. All are plain dense SwiGLU MLPs that thecomment itself says should be
UnquantizedMlpGateUpMethod:Group B — genuine architectural blockers, documented well.
gemma4_moe,laguna,minimax_h3_device,minimax_h3_video_vae_device,minimax_h3_encoder_device, andgemma4_visioneach name a specific reason theseam cannot represent them today: f32-end-to-end activations plus rank-1 biases
the bias-free method has no slot for; ggml block-quant weights against a method
that is "by name and by contract the UNQUANTIZED arm"; a weight-residency
ownership difference (
OwnedTensor/ResidentWeightvs up-front device staging).Those are correctly parked — folding them means extending the shared layer, which
is its own work.
Scope
Fold Group A only: route the five listed models' gate/up through
layers::UnquantizedMlpGateUpMethodand remove their entries fromscripts/merged-gemm-consistency-allowlist.txt, taking the count from 6/15 routedto 11/15 and shrinking the allowlist to the entries that state a real blocker.
Explicitly OUT of scope: every Group B entry. Extending the seam with an f32 arm,
a bias arm, a keep-quant arm, or a residency arm is a shared-layer change, not a
model fold, and each deserves its own row.
Row:
FUSION-DENSE-MIGRATEunderROAD-V1-C1— punch-list item 15 inspecs/roadmap-v1-completion.md,whose non-blocking tail names "
FUSION-DENSE-MIGRATE(route 5 drift models)".The count matches exactly.
Gate: CPU reference backend, token-exact — each folded model's existing paged-engine
test must stay byte-identical, since this is a routing change and not a numerical
one.
check-fusion-consistency.pymust report the higher routed count with thefive entries gone.