feat(apertus): block-major TensorData wiring for NATIVE_OPTIMIZED Q4_K E2E

[michalharakal]

Summary

Towards #100. Three connected fixes that mirror Gemma's Q4_K end-to-end path so the standard transformer DSL forward can consume Apertus quantized weights instead of crashing at the first matmul.

What's in

1. Per-tensor quant sidecar on ApertusWeights — new quantTypes / logicalShapes / quantBytes fields. Default empty; non-NATIVE_OPTIMIZED callers see no change.

2. New jvmMain ApertusMemSegConverter mirroring GemmaMemSegConverter:

   • Q4_K → Q4_KBlockTensorData with row-major → block-major relayout (144 B/block)
   • Q6_K → Q6_KBlockTensorData (210 B/block)
   • Q4_0 / Q8_0 → Q4MemorySegmentTensorData / Q8MemorySegmentTensorData
   • Q5_K → fallback to FP32 dequant (no packed kernel yet; Apertus-8B Q4_K_S has only 8 of these)
     Drains the loader's quantBytes as it goes and drops the sidecar maps from the result so we don't carry 5 GB of one-shot byte data through the runtime.

3. Loader produces logical [out, in] shapes, not GGUF [in, out] — fixes two long-standing latent bugs:

   • GGUF lists dims fastest-varying-first; the rest of this codebase follows PyTorch [out, in]. Added logicalShape() helper that reverses (mirrors Gemma's reversedShape); replaced every loader callsite.
   • createTensor was running transposeColumnMajorToRowMajor on every 2D tensor and flipping its shape on top of the un-reversed input. After the shape fix, that transpose was actively scrambling data. Simplified to a direct fromFloatArray with the logical shape.
     Neither tripped a unit test because Apertus DSL pipeline tests use synthetic FP32 weights via fromWeights, bypassing this whole loading path.

End-to-end status against unsloth/Apertus-8B-Instruct-2509-GGUF Q4_K_S

Stage	Result
peek() / tensor presence / loadQuantized()	✅
ApertusNetworkLoader.fromGguf().load() (module build)	✅ 12 GB heap
Embedding lookup (token_embd dequant + gather)	✅ produces correct [1, dim] per-token vector
Q4_K transpose + matmul through attention projections	✅ no longer throws
Full forward(BOS) runs to completion	✅ ~30 s, 18 GB heap
Logits are finite	❌ all-NaN — xIELU formula / param-space mismatch, tracked in #103

Why merge as-is

The activation (#103) is an independent thread — formula audit against the HF Apertus reference, not loader work. Everything in this PR is necessary and correct for the loader/converter side; punting the merge until #103 is solved would block any other Apertus loader work that depends on the corrected shapes and the converter API.

When #103 lands, the existing forward pass on real Apertus produces finite logits and greedy generate smoke tests in ApertusRealGgufLoadingTest should pass without additional loader changes.

Test plan

• peek detects apertus architecture and reads metadata fields — ✅
• streaming reader exposes every tensor required by the apertus loader — ✅
• loadQuantized fully populates ApertusQuantizedWeights from real GGUF — ✅
• ApertusNetworkLoader fromGguf builds module from real Q4_K_S GGUF — ✅ (12 GB heap)
• forward pass on real Apertus produces finite logits of vocab size — ❌ NaN, blocked on Apertus xIELU formula / param-space mismatch — forward pass NaN's on real Apertus-8B Q4_K_S #103
• greedy generate on real Apertus produces in-vocab token sequence — ❌ blocked on Apertus xIELU formula / param-space mismatch — forward pass NaN's on real Apertus-8B Q4_K_S #103
• xIELU formula audit vs HF Apertus reference — Apertus xIELU formula / param-space mismatch — forward pass NaN's on real Apertus-8B Q4_K_S #103

🤖 Generated with Claude Code