[ncylich]

Problem

a8f634a6 (#723) folded the gemma4 audio soft-token 1/16 out of the runtime graph and into the converted embed_audio_proj.weights file. Correct for the CPU path (it binds that scaled file at runtime), but silently wrong for the NPU path: the audio .mlpackage is traced directly from the in-memory torch module, which holds the original, unscaled projection weight, and the .mlpackage never reads that converted file.

gemma4 multimodal embedders have no post-projection norm (only a pre-projection one) — verified: embed_vision/embed_audio expose only embedding_projection + embedding_pre_projection_norm, and no embed_*_post_proj_norm.weights is produced. So the projection magnitude is the soft-token magnitude and nothing renormalizes it. Both audio and vision NPU soft tokens were 16x too large (vision was previously assumed safe via a post-projection RMSNorm — that norm does not exist for this family, so the assumption was wrong).

The deeper issue is structural: the ÷16 reparam lived in two disjoint copies (the canonical gemma4_scale_factor() and a hardcoded block in tensor_io.py), and a third weight consumer (NPU baked weights) consulted neither.

Fix

Make gemma4_scale_factor() the single source of truth, consumed by all three weight-emission paths.

• convert: add the projection basenames to GEMMA4_DIV_BASENAMES and collapse the hardcoded tensor_io.py gemma4 block to call gemma4_scale_factor(). Factors are identical for every converted weight (verified over 2133 names), so stored weights are byte-for-byte unchanged.
• transpile: reparameterize both projection weights with that same function before the NPU trace, applied as a reversible context manager so the shared module is restored before CPU IR capture. Wired in via one optional npu_reparam field on ComponentModuleSpec, keeping the family-agnostic NPU pipeline free of gemma4 specifics.

Verification

• Static equivalence: gemma4_scale_factor matches the old hardcoded block on all 2133 real converted filenames (0 mismatches) → CPU conversion output unchanged.
• NPU audio (.mlpackage vs torch adapter, same test.wav inputs): RMS(NPU)/RMS(torch unscaled) = 0.0626 ≈ 1/16; RMS(NPU)/RMS(torch ÷16) = 1.002 ≈ 1.0; cosine identical scaled-vs-unscaled → change is magnitude-only.
• NPU vision (direct .mlpackage ratio, with vs without reparam): RMS ratio = 0.062500 = exactly 1/16, cosine 1.000000. Confirmed gemma4 vision has no post-projection norm (so it was 16x hot too, now matches CPU).
• Relevant unit suites pass (test_transpile_weight_compat, test_component_partition, test_optimize_gemma4_attention).

Deploy

Convert output is unchanged, so no reconvert is required. Affected gemma4 NPU bundles must be re-transpiled (--npu) to pick up the corrected audio and vision .mlpackages.

[kar-m]

tested pre and post PR NPU performance, audio is fixed from a bad regression, vision is just a tiny bit better post-PR. LGTM

[HenryNdubuaku]

@ncylich just resolve the conflicts here

[kar-m]

tested, lgtm

[kar-m]

again looks good

[kar-m]

approve