Hurwitz Quaternion Multiplicative Quantization for KV Cache Compression

## HQMQ : Compression du cache KV sans calibration via quaternions de Hurwitz

### Ce qui se passe concrètement

Le cache KV est devenu l'un des goulots d'étranglement les plus coûteux de l'inférence LLM à long contexte. Pour Llama-3-70B avec un contexte de 128k tokens, ce cache occupe 43 GB en fp16 — soit souvent plus que les poids du modèle eux-mêmes sur certaines configurations. HQMQ (Hurwitz Quaternion Multiplicative Quantization) propose une compression jusqu'à 5.05× de ce cache, ramenant ces 43 GB à 8.5 GB, sans nécessiter de données de calibration.

### La mécanique : pourquoi les quaternions de Hurwitz

L'idée centrale est géométrique. Chaque chunk de 4 éléments consécutifs d'un vecteur K ou V est traité comme un quaternion unitaire sur la sphère S³. La quantification décompose ce quaternion en un produit q_p · q_s, où q_p appartient au groupe de Hurwitz 2T (24 sommets du 24-cell, angle minimal entre paires de 60°) et q_s est tiré d'un codebook secondaire par (couche, tête) de S quaternions aléatoires.

L'astuce mathématique exploitée : la multiplication à gauche par un quaternion unitaire est une isométrie de S³. Cela signifie que les 24 éléments de 2T "tournent" les S vecteurs du codebook secondaire de manière uniforme, produisant 24S mots de code effectifs pour seulement S paramètres stockés. En pratique, S=8 donne 192 mots de code effectifs à ~3.79 bits, S=32 donne 768 mots de code à ~5 bits.

Conséquence directe : l'initialisation aléatoire du codebook secondaire suffit. La variance de perplexité entre seeds différentes reste inférieure à 1.5%, ce qui élimine le besoin de calibration — contrairement à KIVI, QuIP# ou d'autres méthodes qui nécessitent un corpus de calibration représentatif.

### Le problème des outliers : Med3×

Les architectures modernes (Qwen2.5, Qwen3) présentent des outliers sévères dans les activations KV. Sans traitement, int4 naïf s'effondre à des perplexités supérieures à 10⁴ sur ces modèles — rendant le modèle inutilisable. HQMQ intègre une étape d'extraction d'outliers par multiplicateur médian par batch (C=3, sans calibration) qui récupère la qualité fp16 à ±0.02–0.10 points de perplexité à ~5 bits sur Qwen2.5-7B et Qwen3-8B.

### Les chiffres qui comptent

**Comparaison avec int4 naïf** : HQMQ domine Pareto int4 naïf de 3× à 1900× selon le modèle et le budget de bits. Le facteur 1900× correspond aux cas Qwen où int4 s'effondre complètement.

**Comparaison avec KIVI-4** (la baseline calibrée la plus forte) : À 3.79 bits (16% moins de bits que KIVI-4 à ~4.5 bits), HQMQ est à ≤1 pt sur CoQA, ≤0.6 pt sur TruthfulQA, ≤2.3 pts sur GSM8K — sans passe de calibration. Sur Mistral-7B, la précision zero-shot à 3.79 bits correspond à fp16.

**Qualité absolue** : Sur Mistral-7B et Qwen3-8B, HQMQ atteint fp16 à ±0.02–0.03 points de perplexité à ~5 bits. C'est une marge quasi-nulle pour une compression 3× du cache.

### Qui perd dans ce scénario

**Les fournisseurs de solutions de calibration KV** : KIVI, SmoothQuant-KV, et méthodes similaires justifiaient leur complexité opérationnelle (collecte de données de calibration, passes supplémentaires) par une meilleure qualité. HQMQ réduit cet avantage à quelques points sur des benchmarks spécifiques tout en éliminant la contrainte de calibration.

**Les approches purement int4/int8** : Sur les architectures avec outliers (Qwen2.5, Qwen3, et probablement les futurs modèles), int4 naïf devient inutilisable. HQMQ offre une alternative structurée qui gère ces cas sans tuning.

**Les déploiements contraints en mémoire** : L'impact est maximal pour les scénarios long-contexte. À 128k tokens sur Llama-3-70B, passer de 43 GB à 8.5 GB de cache KV peut faire la différence entre un déploiement sur 2×A100 80GB versus 4×A100 — soit un facteur 2 sur le coût d'infrastructure.

### Limites et questions ouvertes

La méthode est évaluée sur cinq modèles (Mistral-7B, Llama-3-8B, Qwen2.5-7B, Qwen3-8B, gpt-oss-20b MoE). L'extension aux modèles avec attention sliding window ou architectures hybrides (Mamba, RWKV) n'est pas couverte. La latence de décompression à l'inférence n'est pas quantifiée dans l'abstract — point critique pour les applications temps-réel où la compression KV doit s'accompagner d'un overhead de décodage acceptable. L'absence de calibration est un avantage opérationnel fort, mais la dépendance à un codebook secondaire par (couche, tête) introduit un overhead de stockage de métadonnées à évaluer pour les très grands modèles.