KVarN: Variance-Normalized KV-Cache Quantization [R]

## KVarN : Quantification KV-Cache par normalisation de variance — Pourquoi ce papier compte

### Ce que fait réellement KVarN

Le KV-Cache est le goulot d'étranglement mémoire central des LLMs en inférence longue : pour un modèle 70B avec une fenêtre de 128k tokens, le cache K/V peut dépasser 100 GB en fp16. Les approches existantes (KIVI, KVQuant, FP8 natif de vLLM) compressent déjà, mais toutes subissent une dégradation mesurable sur les benchmarks de raisonnement multi-étapes, précisément là où la longueur de séquence est la plus grande.

KVarN combine deux opérations : (1) une rotation Hadamard appliquée aux matrices K et V avant quantification, et (2) une normalisation de variance sur les deux axes (tokens et dimensions). Le résultat est ensuite arrondi au plus proche (round-to-nearest), sans quantificateur appris ni calibration coûteuse. La simplicité est délibérée : pas de lookup table, pas de codebook, pas de fine-tuning.

### L'analyse d'erreur qui justifie le design

Le papier (arXiv 2606.03458) part d'une observation asymétrique : dans un budget MSE fixe, corriger quelques grandes erreurs est disproportionnellement plus utile que réduire uniformément de nombreuses petites erreurs. En contexte decode-heavy, les erreurs s'accumulent token après token — une grande erreur à l'étape t se propage et amplifie les erreurs aux étapes t+1, t+2, etc.

L'identification de la source : ces grandes erreurs proviennent principalement de mauvaises "token-scales", c'est-à-dire de tokens dont la magnitude dans l'espace K/V est anormalement élevée (les outliers bien documentés depuis LLM.int8() et SmoothQuant). La normalisation de variance par token neutralise exactement ce phénomène avant que la rotation Hadamard ne redistribue l'énergie résiduelle uniformément sur toutes les dimensions.

### Chiffres concrets

- **Compression 3-4x** sur le KV-Cache (équivalent à passer de fp16 à ~4 bits effectifs) - **0-1% de perte** sur AIME24, benchmark de mathématiques compétitives qui nécessite des chaînes de raisonnement de plusieurs milliers de tokens — le cas d'usage le plus défavorable pour la quantification cumulative - **Accélération mesurée sur vLLM** par rapport à la baseline fp16, ce qui n'est pas acquis : KIVI et plusieurs variantes récentes compressent la mémoire mais n'accélèrent pas le throughput wall-clock à cause de l'overhead de décompression - Implémentation disponible sur le repo Huawei CSL : `huawei-csl/KVarN`

### Pourquoi le setting decode-heavy change tout

Les benchmarks standards (MMLU, HellaSwag) utilisent des séquences courtes où le prefill domine. AIME24, le code-gen multi-fichiers, et les agents avec mémoire longue sont des settings où le decode représente 80-95% du compute. C'est précisément là que les erreurs de quantification s'accumulent de façon non-linéaire.

Avant KVarN, l'état de l'art pratique pour ces settings était soit : - FP8 KV-Cache (support natif vLLM 0.6+) : ~2x compression, perte quasi-nulle mais limitée aux GPUs H100/H200 avec hardware FP8 - KIVI (INT4 par groupe) : 4x compression mais dégradation notable sur raisonnement long - KVQuant : meilleure précision que KIVI mais overhead de calibration et pas d'accélération wall-clock documentée

KVarN prétend occuper le quadrant "compression élevée + précision préservée + accélération réelle" sur hardware standard.

### Perdants potentiels

**FlashAttention + FP8 natif** : si KVarN tient ses promesses sur A100 (pas seulement H100), l'argument "attendez le hardware FP8" perd de sa force. **KVQuant et KIVI** : positionnés sur le même segment, ils devront répondre sur le benchmark AIME24 et sur le throughput vLLM mesuré. **Les fournisseurs cloud** qui ont investi dans des pipelines de calibration KV-Cache complexes voient une méthode sans calibration arriver avec des chiffres comparables.

### Réserves à vérifier

Le papier est signé Huawei CSL — l'implémentation vLLM est disponible mais les benchmarks hardware sont à reproduire indépendamment. La rotation Hadamard a un coût O(d log d) non négligeable sur de très grandes dimensions de modèle (d=8192+ pour les modèles 70B+). L'overhead réel sur des séquences courtes (<2k tokens) n'est pas détaillé dans l'extrait. Enfin, "0-1% de perte" sur AIME24 mérite une lecture attentive de la méthodologie : nombre de runs, température, pass@k vs greedy.