nx_dequant_iter.nx

nx_dequant_iter.nx -- per-block Q4_K dequant iterator. Architectural step toward conductor Phase C (dispatcher with fused dequant+matmul). Instead of materializing a whole tensor's worth of Q10 i64 storage, the dispatcher will hold a small per-block iterator that amortizes the 8-scale-8-min unpack across the 256 value reads from that block. A matmul kernel asks the iterator for individual values (or sub-block batches) on demand. Why this matters (HONESTLY, no perf claim attached): The existing nx_gguf_dequant_q4_k writes ALL 256 values of every super-block into a flat output buffer. For Llama-7B's ~7B params at 256 values/block that's ~27 million blocks materialized eagerly. At ~11 ns/value (qemu-riscv64 measurement from nx_dequant_bench, 2026-05-19) that's ~77 seconds of pure dequant if the substrate ever materializes the full model. The iterator pattern (this brick) DOES NOT make per-value dequant faster. It enables the SCAFFOLDING for a future dispatcher that dequants only the blocks a given matmul tile reads. Whether the dispatcher delivers net latency wins vs the materialize-everything path depends on the matmul access pattern and remains to be measured -- not claimed here. What this brick DOES claim, narrowly: - One-time per-block setup: read f16 d + dmin, unpack 8 scales + 8 mins from the 12-byte packed header (one constant-time pass) - Constant-time per-value access: nx_q4k_iter_value(it, idx) does index math + nibble extract + (d * sc) * q - dmin * m - Bit-exact match against nx_gguf_dequant_q4_k for the same block bytes (verified by smoke) genealogy_id: ggml_q4k_block_canon + iterator_pattern_canonical lineage_id: substrate_dequant_iter_v1_q4k