feat(minimax-h3): load the bf16 TEXT ENCODER (14 shards, 63 GB) and measure what Q4_K_M costs the conditioning

[localai-bot]

Stacked on #99 → #98. Retarget to main once those merge — the diff below is this row alone (898 non-exempt lines).

What this enables

Every H3 render so far conditioned on a Q4_K_M Qwen3-VL-32B text encoder, and nobody had measured what that quantization does to the conditioning tensor. It was not measurable: --encoder only ever accepted a GGUF, and the unquantized tower ships as 14 safetensors shards, 63 GB.

• MiniMaxH3EncoderConfigFromShards derives the geometry from the shard index's shapes alone, with the same recovery rules and the same non-shape defaults (rope_theta, mrope_section, rms_norm_eps, selected_layer) as the GGUF loader — so an A/B cannot end up comparing two different RoPEs.
• StreamMiniMaxH3EncoderShardsToDevice fills the same MiniMaxH3EncoderDeviceWeights::views map the GGUF arm fills, over bf16 instead of ggml blocks. Projections upload directly out of the read-only mmap, and the [q|k|v] / [gate|up] row fusions are done on the device, into offsets of one allocation — so even the one transform this loader performs costs no host copy.
• MiniMaxH3EncoderEmbedTokensFromShards gathers embedding rows straight out of the mmap'd shard; the table is [151936, 5120] and a prompt touches a few dozen rows.
• A bf16-weight widen step in MiniMaxH3EncoderTextForwardDevice (scratch reused across layers), because vt::MatmulBT needs one dtype for both operands and these activations are f32. The 50 layers H3 runs are 48.8 GiB bf16 against 97.5 GiB f32 on a 122 GiB unified pool. bf16→f32 is exact, so this is a residency choice, not a precision one — and it is gated as such.
• --encoder <dir> and --encoder-only in examples/minimax_h3_gen. --encoder-only skips the DiT entirely, dropping peak from ~96 GiB to ~49 GiB — on this box the difference between a run and an OOM reboot.

No new forward. The encoder graph is byte-for-byte the same code for both arms. That is what makes the quantization question measurable rather than arguable.

The measurement

Q4_K_M vs bf16 encoder, same 233-token prompt, same forward, on Thor:

per-token cosine	0.99745 mean, 0.909 min
rel RMS	0.0340 overall, 0.0685 excluding the attention sink
median rotation	3.5°
is it a scale change?	No — best rescale only moves 0.0340 → 0.0328
calibration arm	a one-word prompt edit moves the same energy, but touches 172/233 tokens; the quantization touches 232/233

So: the Q4_K_M encoder shifts the conditioning about as much as editing one word of the prompt does — but diffusely, spread across nearly every token instead of concentrated where the edit was.

Gates I ran, post-rebase

• test_minimax_h3 75/75 cases, 55609 assertions, clean Release build of libvllm.a, test_minimax_h3, minimax-h3-gen. Full scripts/agent-preflight.sh: green.
• Shards resolve, fuse and stream: a synthetic 4-shard encoder at the real name spellings; every fused view memcmp-exact against q ++ k ++ v / gate ++ up for every layer; unfused projections byte-exact; separate names gone; final norm, lm_head and the vision tower deliberately not bound; truncation honoured; embedding gather exact and out-of-range throwing.
• The loader RAN, and is not the GGUF path: MiniMaxH3EncoderShardStreamStats asserted on shards / layers / views / fused groups / direct-vs-converted uploads, with host_peak_bytes equal to one norm — the peak cannot scale with the model — and the views are kBF16, a dtype the GGUF loader can never produce.
• The widening is exact: the same checkpoint written BF16 and F32 (bf16-rounded values) streams to kBF16 and kF32 views respectively, and the two full encoder forwards are bit-identical (memcmp == 0). The A/B cannot be confounded by the widening.

What is NOT claimed

• This does not establish that the render changes. The number is a conditioning-tensor diff. Whether a 0.99745-cosine, diffusely-rotated conditioning produces a visibly different video is exactly the question this does not answer; the render A/B on the saved embeds is owed and is why --save-embeds exists.
• No bf16 render exists on either branch of this stack. No bf16-vs-quantized DiT quality or speed number is claimed.
• The conditioning numbers are from one prompt on Thor (sm_110). They are a first measurement, not a distribution.
• The real 63 GB encoder load and its measured peak RSS on GB10 are not re-verified here.

Rebase note

origin/main grew a vision-conditioning path in the encoder block (--cond-image: merged features masked-scattered into inputs_embeds plus the 3 DeepStack taps) after this branch was written. This branch had refactored that whole block into a text-only EncodeH3Prompt helper, which would have silently dropped it. Resolved by keeping main's inline block for the run path and scoping EncodeH3Prompt to --encoder-only, which is text-only by design. Both capabilities survive.

[localai-bot]

Force-pushed twice since opening:

1. Rebased onto the fixed stack — feat(minimax-h3): the ORIGINAL bf16 DiT release is indexable — 13 shards, 66.3 GB #98 gained a UBSan fix (misaligned 16-bit safetensors load) that this branch's test path also reaches.
2. Repaired stray conflict markers that VK-C bench: coopmat GEMM is 11.1x-32.9x over our scalar kernel on Thor #101 merged onto main. .agents/benchmark-record.md on origin/main literally contains <<<<<<< HEAD / ======= / >>>>>>> origin/main around the Vulkan-coopmat and Kimi-Linear sections (lines ~14539–14596). Both sections are real evidence in an append-only record, so both are kept and only the scaffolding is removed. Nothing was dropped.