847 tensors. That's what goes into a working Gemini Nano v3: FFN projections (gate, up, down) for 35 layers, attention matrices (Q, K, V, O) for 35 layers, seven types of normalization parameters, AltUp routing coefficients, PLE per-layer embeddings, LAuReL residual projections, three global AltUp tensors, and the main embedding table.
847 tenseurs. C'est ce qu'il faut pour un Gemini Nano v3 fonctionnel : projections FFN (gate, up, down) pour 35 couches, matrices d'attention (Q, K, V, O) pour 35 couches, sept types de paramètres de normalisation, coefficients de routage AltUp, embeddings PLE par couche, projections résiduelles LAuReL, trois tenseurs AltUp globaux, et la table d'embedding principale.
Each tensor type had its own extraction problem.
Chaque type de tenseur avait son propre problème d'extraction.
The alignment bugLe bug d'alignement
Four of 35 layers (L16, L17, L18, L28) failed dequantization. Root cause: floating-point offset arithmetic producing offsets not aligned to 4 bytes. A calculated gap of 16,911,433 bytes is 1 byte off from 4-byte alignment, which shifts all float32 reads and produces systematic garbage. Fix: interpolate from the 31 validated layers, then scan at 4-byte steps in a narrow window.
Quatre couches sur 35 (L16, L17, L18, L28) échouaient à la déquantification. Cause : l'arithmétique d'offset en virgule flottante produisait des offsets non alignés sur 4 octets. Un gap calculé de 16 911 433 octets est décalé d'1 octet par rapport à l'alignement 4 octets, ce qui décale toutes les lectures float32 et produit du garbage systématique. Correction : interpoler depuis les 31 couches validées, puis scanner par pas de 4 octets dans une fenêtre étroite.
The padding directionLa direction du padding
Chrome's XNNPACK runtime appends 3-13 KB of trailing metadata after Q/K/V attention tensors. My initial extraction code skipped bytes at the start of the file instead of the end, shifting all attention data by thousands of bytes and mixing adjacent rows. The GGUF loaded fine, ran at full speed, produced garbage. Cosine similarity against source jumped from 0.02 (random) to 1.000000 once I fixed the skip direction.
Le runtime XNNPACK de Chrome ajoute 3-13 Ko de métadonnées à la fin des tenseurs d'attention Q/K/V. Mon code d'extraction initial sautait les octets au début du fichier au lieu de la fin, décalant toutes les données d'attention de milliers d'octets et mélangeant les lignes adjacentes. Le GGUF se chargeait sans problème, tournait à pleine vitesse, produisait du garbage. La similarité cosinus contre la source est passée de 0,02 (aléatoire) à 1,000000 une fois la direction du skip corrigée.
The L19 trapLe piège L19
Layer 19 is where the attention format transitions from separate Q/K/V/O tensors to a fused QKV block. Unlike layers 20-34 which share K/V weights with earlier layers, L19 has its own K/V projections embedded in the fused block. My extraction treated it as Q-only, leaving K/V as placeholder data filled with Inf values. No load-time warning. Silent corruption that caused multiple regressions across builds.
La couche 19 est celle où le format d'attention passe de tenseurs Q/K/V/O séparés à un bloc QKV fusionné. Contrairement aux couches 20-34 qui partagent les poids K/V avec des couches antérieures, L19 a ses propres projections K/V embarquées dans le bloc fusionné. Mon extraction l'a traitée comme Q uniquement, laissant K/V en données placeholder remplies de valeurs Inf. Aucun avertissement au chargement. Corruption silencieuse qui a causé de multiples régressions entre les builds.
Corruption in the source fileCorruption dans le fichier source
Seven layers contain corrupted values ranging from 1e17 to 1e38 in their norm and scale parameters. Not extraction bugs; the corruption exists in Chrome's weights.bin itself. 25 corrections total, fixed by copying from the nearest clean neighbor layer.
Sept couches contiennent des valeurs corrompues allant de 1e17 à 1e38 dans leurs paramètres de norms et scales. Pas des bugs d'extraction : la corruption existe dans le weights.bin de Chrome lui-même. 25 corrections au total, corrigées en copiant depuis la couche voisine la plus propre.
LAuReL transpositionTransposition LAuReL
Chrome stores these tensors in a different memory layout than what the GGML runtime expects. The writer must transpose the data during requantization, not just swap the declared dimensions.
Chrome stocke ces tenseurs dans un layout mémoire différent de ce qu'attend le runtime GGML. Le writer doit transposer les données pendant la requantification, pas simplement permuter les dimensions déclarées.
