fix(MODEL-TEXT-GLM4-MOE-LITE-ROUTER-F32): GLM's router is fp32 because Glm4MoE says so, not because a config key does

[localai-org-maint-bot]

Glm4MoeLiteForCausalLM (GLM-4.7-Flash) computed its MoE router logits in
bf16. Upstream computes them in fp32, unconditionally, and it does so
because GLM's MoE block is a different class from DeepSeek-V2's — not because
of anything in the config.

The divergence, read at the pin the goldens were captured on (5559679229)

Upstream Glm4MoeLiteForCausalLM does not use DeepseekV2MoE. Its MoE block is
Glm4MoeLite, a bare subclass of Glm4MoE (glm4_moe_lite.py:86-87,
instantiated at :161-165), whose gate is
nn.Linear(hidden_size, n_routed_experts, bias=False, dtype=torch.float32)
(glm4_moe.py:141-146), fed hidden_states.to(dtype=torch.float32) (:218),
declared router_logits_dtype=torch.float32 (:205). No config key
participates.

DeepseekV2MoE resolves the same dtype from the config instead —
GateLinear(..., out_dtype=_get_moe_router_dtype(config))
(deepseek_v2.py:308-314, :123-133) — which returns fp32 only for
model_type == "glm_moe_dsa" or an explicit moe_router_dtype: "float32".

This port composes the DeepSeek-V2 forward and loader for GLM, so GLM's dtype
came from deepseek_v2_weights.cpp:332 and deepseek_v2.cpp:363 sized the logit
buffer from it. The published zai-org/GLM-4.7-Flash config.json declares no
moe_router_dtype and its model_type is glm4_moe_lite, so the flag resolved
false.

The change

ParseGlm4MoeLiteParams in the GLM registry TU composes
ParseDeepseekV2Params(config, allow_mtp_tail=true) and then sets
router_dtype_is_f32 = true, which is what Glm4MoeLite being Glm4MoE means
in a port that composes them. All three GLM registry hooks —
parse_config, load_weights, make_kv_cache — resolve through it, so the
params the forward reads cannot drift from the params the config hook validated.

ParseDeepseekV2Params is untouched and still does not read model_type, which
deepseek_v2_weights.cpp:321-330 argues for and is right about: that parser
serves DeepseekV2ForCausalLM. GLM-5.3 already carries its own answer the same
way (glm_moe_dsa.cpp:353).

Measured, not argued

deepseek_v2.h:164-168 says "a token gate cannot see this either way". That
holds for a store that is merely too WIDE. It does not hold for one that is too
NARROW in front of a top-k, and GLM routes top-4 of 64 with noaux_tc
sigmoid scoring plus an e_score_correction_bias, norm_topk_prob: true and
routed_scaling_factor: 1.8. New case T3 drives vt::MoeRouterTopK at exactly
that configuration:

bf16 router store changed the top-4 SET for 34/4096 tokens (0.830078%)

A changed SET is a different expert's weights running. It is bimodal, not a
tolerance. Two more measurements from the same file:

router dtype observable in the GLM forward: 6/16 seeds differ, worst |f32 - bf16| logit = 0.00100262
separating checkpoint seed = 61

RED and GREEN, both counts

Built -O0, CPU only (this host has no CUDA toolkit), at c796fea41.

Before the one-line repair, whole file in place:

[doctest] test cases:  5 |  2 passed | 3 failed | 0 skipped
[doctest] assertions: 23 | 20 passed |  3 failed

After:

[doctest] test cases:     5 |     5 passed | 0 failed | 0 skipped
[doctest] assertions: 16085 | 16085 passed | 0 failed

Mutations

Every one rebuilt (BUILD_RC=0 each time, so nothing here was caught by the
compiler instead of by a test) and restored, each restore verified by
sha256sum -c against a baseline taken before the first mutation.

#	Mutation	Result
M1	remove p.router_dtype_is_f32 = true;	RED 5 | 2 passed | 3 failed, assertions: 23 | 20 passed | 3 failed
M2	delete the production loader call site weights.params = ParseGlm4MoeLiteParams(config);	RED 5 | 4 passed | 1 failed, 2 assertions — only T4, reporting the registry's output as the bf16 arm
M3	remove the bf16 round trip T3 rests on	RED, SET differences fall to 0/4096
M4	make T2's second arm f32 as well	RED, 0/16 seeds differ, worst 0

M2 is the reachability result. T4 goes in through ModelRegistry::Load over a
synthetic GLM-4.7-Flash checkpoint written to disk and ModelRegistry::Forward
on its default configuration (gather_logits true, so the device-resident arm),
and compares the registry's own logits to the two arms built from the same bytes
by the same loader. Without the loader call site it reds while T1, T2 and T3 stay
green, which is exactly what that call site owes.

Regression

suite	result
test_glm4_moe_lite_router_dtype	5/5, 16085 assertions
test_glm4_moe_lite_load	3/3, 15 assertions
test_deepseek_v2_forward	12/12, 2061 assertions
test_deepseek_v2_load	4/4, 14 assertions
test_ops_moe_router_grouped	14/14, 941 assertions

DeepseekV2ForCausalLM is byte-identical: ParseDeepseekV2Params is unchanged.

What this does NOT claim

It does not claim the SACRED gate is fixed. Glm4MoeLiteForCausalLM matches
the pinned oracle at 69 of 128 positions (#2839, PR #2906), and no assertion in
test_glm4_moe_lite_paged_engine.cpp is touched here. That gate compares a
frozen our_ids.npy, so no forward change can move it from this host at all;
only a re-capture on a GPU with the checkpoint can. No zai-org/GLM-4.7-Flash
snapshot exists on this box or on the NAS.

T3's 0.83% is per MoE layer per token on N(0,1) synthetic logits. Taken at face
value across GLM-4.7-Flash's 46 MoE layers it would put a changed selection on
roughly a third of token positions, which is the order of the observed 59
divergent positions — but the real logit distribution is not that one, and
nothing here measures the checkpoint. The spec records it under ## Owed O1.

Upstream anchors were read at 5559679229, the goldens' own pin and the PRIOR
parity pin, not at the active e126687a9a. One token gate has now run at the
active pin and passed (b55f63ed6, merged in here), but it is a different
model's battery and no Glm4MoeLiteForCausalLM golden has been re-captured
there. Owed as O5.

Preflight, and the two gates that are red for reasons this change did not cause

scripts/agent-preflight.sh --staged exits 1. Neither failure is caused by this
change, and the exit code is not being read as the verdict either way:

• test_cpu_x86_llamacpp_floor — test_a_contended_leg_is_discarded_and_never_summarised
  expected rc 2 and got 4 while the box was at load=75.28 76.77 62.18 from
  other sessions' builds; the harness discarded the contended leg and ran out of
  retries. Re-run standalone on this same tree: Ran 10 tests ... OK.
• tools suites — test_oracle_pin.test_metadata_and_runtime_strings_differ_on_the_pin
  asserts VLLM_DISTRIBUTION_VERSION != VLLM_ORACLE_VERSION, and both now read
  0.28.1rc1.dev132+ge126687a9. Those constants come from .agents/upstream-sync.md
  through tools/bench/serve_low_common.py:107-108, neither of which this change
  touches, so it is a property of origin/main. Already open and owned as
  #2931.

Five gates SKIP for want of a cross-compiler, a CUDA toolkit or a CI-only input.
check-pr-size.py is one of them and was run by hand:
OK: every explicit path class is within its review budget.

origin/main was merged in at 15 commits (e23eeaa94) and the row's gate re-run
on the merged tree: identical counts, identical numbers. That merge falsified one
sentence of this pull request's own prose — the active-pin claim above — which is
repaired in a5b4830ea rather than left standing.

Filed on the way, owned rather than deferred

• #2929 — neartie_gap_mnats.npy
  is identically zero in 12 of 18 golden directories while our_ids diverges
  from greedy_ids at 13 to 83 positions in each. At a first divergence our
  prefix equals the oracle's, so the oracle's teacher-forced argmax there IS the
  golden token and the gap must be positive. Established from the committed
  artifacts alone; owned under this spec's ## Owed O3.
• #2930 — routed_scaling_factor
  is applied to the routing weights, where upstream applies it to the routed
  output. A recorded deviation whose only gate vehicle had a factor of 1.0, which
  made it bit-identical there; GLM's 1.8 makes it live. ## Owed O4.

Closes #2928.

FOLLOWING_AGENTS_PROTOCOL

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: AGENT:claude-opus-5 [claude-code]

[localai-org-maint-bot]

Landed on main by local operator merge at f798f621d — this PR's own merge commit is a80f16cba, which carries the reasoning as its message.

The gate was NOT green and the landing commit says so rather than implying otherwise: test_cpu_x86_llamacpp_floor's contended-leg case failed once (exit 4 NO_QUIET_WINDOW against the asserted exit 2 GIVING_UP). That case is byte-identical to main, as is the harness it executes, and the whole file passed on rerun (10 passed in 263.56s) — at a HIGHER load than it failed at, which refutes the host-load explanation I first reached for. Tracked as #2978 with that correction; nothing was weakened and no gate was re-rolled until green.