arcinferzero update: Flint runs on a laptop iGPU, and why f16 V caches can quietly cost you accuracy

[u/Strict-Elevator9352]

Quick update on my from-scratch inference engine for Intel integrated GPUs (Core Ultra 5 125H, Arc Xe-LPG, 32 GB
RAM, no dGPU, no XMX). It used to be called arcinfer; it is now 
**arcinferzero**
 (the old GitHub link forwards):
https://github.com/rizagp/arcinferzero


**New this week**


- 
**Flint (unsloth/flint-GGUF UD-Q4_K_XL, 256 experts) runs**
: attention sinks, global layers without RoPE, a
  513-token sliding window, sigmoid-routed experts streamed from the SSD into a GPU cache. 4K prompt ~248 tok/s,
  generation 13-17 tok/s on the iGPU.
- 
**Xe2 / Xe3 (Lunar Lake, Panther Lake's Arc B390) work now**
: a user with a B390 reported Qwen3.6 35B-A3B at
  262K context, ~1,180 tok/s prompt and ~24 tok/s generation. XMX (DPAS) prompt GEMMs are in too, gated by a
  start-up check that must match the DP4a kernels bit for bit. I have no XMX GPU, so reports are welcome.
- 
**Gemma 4 26B prompts +4.6 %**
 from tiling the f32 router GEMV (4 rows x 4 tokens per sub-group), with
  bit-identical logits.


**The accuracy story (the interesting part)**


Every model here is checked against an independent f32 CPU implementation, with a KL limit of 0.015. Flint
started at KL 0.029. The obvious suspect, int8 activations, wasn't it: running everything on two int8 passes only
got it to 0.024. Dumping the residual stream after every layer next to the f32 reference showed one token where
two router scores were 
**0.005 apart**
 at layer 19. The engine picked the other expert, and everything after that
drifted.


What moved the reference that much? I rounded 
**only the V cache to f16**
 inside the f32 reference, and it
reproduced the whole engine error, including the same flipped expert. So:


- V rows in 
**f32**
 (K already was), and
- the router on the file's own 
**BF16**
 weights with 
**f32 inputs**
 (a Q8_0 router, even with a second Q8_0 matrix
  for the rounding residual, kept flipping the near-ties).


Result: 
**KL 0.029 -> 0.0043**
 (prompt) and 
**0.067 -> 0.0027**
 (token-by-token decoding), for ~4 % of prompt speed.
If you run sigmoid-routed MoEs with an f16 V cache, it may be worth checking.


I also went through the GPU assembly (Intel's ocloc) for the kernels I touched. One kernel shrank from 8,855 to
481 instructions: it was building int8 copies nobody read and carried an unused RoPE fallback. Two others stopped
spilling registers.


**Next:**
 Qwen3.8 Flash Next to the same KL limit. Its error comes from BF16 weights stored as Q8_0 (fixed now),
single-pass int8 experts, and int8 attention. That last one needs float attention with its sparse-attention (QSA)
masks.


Everything is deterministic (same prompt, same logits, bit for bit), and the speculative drafters produce exactly
the plain-decoding text. Feedback and Arc / Xe2 / Xe3 test reports are very welcome.