Pourquoi un croquis global ne fonctionne pas pour les pages
Le service de grands modèles de langage sur un contexte long bute sur le cache key-value (KV). Le cache est lu intégralement à chaque étape de décodage. Les clés d'attention sont localement de rang faible, bien que globalement de rang élevé. Un croquis de rang faible fixe, commun aux pages, est démontrablement aveugle aux directions des pages.
À taille de résumé égale, la base propre de la page classe les pages et préserve les porteurs bien mieux. Le croquis global ne voit pas ces directions. Un résumé spectral par clé résout le problème.
Résumé spectral par page
LOCKS donne à chaque page son propre résumé spectral de rang r. Le résumé est résident : un dixième du cache à r=8 et un vingt-cinquième à r=2. La méthode reconstruit les logits intrapages. Elle estime la masse d'attention de chaque page via log-sum-exp. Puis elle ne traite que les pages supérieures.
Éléments clés :
- Nom : Page-Local Compact Key Summaries for Efficient Long-Context Decoding.
- Résumé : résumé spectral de rang r pour chaque page.
- Résidence : un dixième du cache à r=8, un vingt-cinquième à r=2.
- Reconstruction : logits intrapages.
- Estimation : masse d'attention de la page via log-sum-exp.
- Sélection : uniquement les pages supérieures.
Conclusion : le résumé occupe une fraction du cache, mais préserve les caractéristiques des pages. La sélection des pages se fait sur les données spectrales.
Sélection de blocs sans lecture des clés
La sélection elle-même ne lit pas les clés ni les valeurs des candidats. Le choix se fait uniquement sur le résumé spectral. Le résumé est parcouru intégralement à chaque étape. La lecture KV par étape chute d'un facteur 10 à 25 dans la plage de rangs indiquée.
La latence de décodage par token est réduite de moitié. À 1M de tokens sur un seul H200 NVL, l'accélération atteint 2,0× à r=8. C'est une comparaison avec l'attention dense. La sélection ne dépend pas de la lecture des clés des candidats.
Qualité sur les tâches longues
LOCKS préserve la qualité sur plusieurs types de tâches. Sur le QA de documents longs (LongBench-v1 ; Llama-3.1-8B), le résultat reste à un point du cache complet. Sur RULER, dense en retrieval, la méthode suit l'oracle LSE exact, qui lit chaque clé, jusqu'aux plus petits budgets. Sur le raisonnement long (AIME26, MATH-500 ; Qwen3-4B), la qualité se maintient plus loin que toutes les autres dans le régime des petits budgets. Les sélecteurs et les compresseurs de raisonnement fondés sur l'éviction y reculent.
Avec un budget de 2048 tokens, LOCKS égale la qualité agrégée de FullKV sur un contexte de 100K+ (GLM-4-9B-Chat-1M). La méthode ne traite pourtant que 2 % des tokens.
| Condition | Résultat |
|---|---|
| QA de documents longs (LongBench-v1 ; Llama-3.1-8B) | à un point du cache complet |
| RULER, dense en retrieval | suit l'oracle LSE exact jusqu'aux petits budgets |
| Raisonnement long (AIME26, MATH-500 ; Qwen3-4B) | maintient la qualité plus loin que toutes dans les petits budgets |
| Budget de 2048 tokens, contexte 100K+ (GLM-4-9B-Chat-1M) | égale FullKV, traite 2 % des tokens |
Conclusion : sur les tâches citées, l'approche préserve la qualité plus longtemps que les sélecteurs et les compresseurs fondés sur l'éviction.
Intégration et critère de choix
L'approche est fournie comme plugin drop-in pour vLLM non modifié. Le décodage par lots fonctionne dans des graphes CUDA complets. Aucune modification de vLLM n'est requise.
Critère de choix : contexte long, budget de tokens limité, besoin de réduire la lecture KV et la latence de décodage. Si la tâche exige une sélection de blocs sans lecture des clés des candidats, l'approche convient.
