SparDA: Sparse Decoupled Attention for Efficient Long-Context LLM Inference

## SparDA : NVlabs résout le double goulot d'étranglement de l'attention sparse sur contextes longs

### 1. Le problème précis que SparDA adresse

L'attention sparse est déjà un acquis pour réduire la complexité computationnelle sur les contextes longs — mais elle laisse deux problèmes structurels intacts. Premier problème : le cache KV continue de croître linéairement avec la longueur de séquence, forçant l'offload vers la RAM CPU, ce qui crée un goulot PCIe. Deuxièmement, l'étape de sélection sparse elle-même conserve une complexité O(T²) — elle peut donc dominer le coût total de l'attention sur les très longs contextes, annulant une partie du gain théorique. Ces deux problèmes coexistaient dans les approches précédentes (Quest, InfLLM, MagicPIG, SnapKV) sans solution unifiée.

### 2. L'architecture : une quatrième projection par couche

SparDA ajoute une projection "Forecast" par couche, aux côtés de Q, K et V. Cette projection prédit les blocs KV dont la couche suivante aura besoin — pas la couche courante. Ce décalage d'une couche est la clé : il permet de lancer le préchargement CPU→GPU des blocs KV en parallèle de l'exécution de la couche actuelle, masquant ainsi la latence PCIe. Le coût paramétrique est inférieur à 0,5% de paramètres supplémentaires. L'entraînement ne touche que les projections Forecast, par distillation de la distribution d'attention du sélecteur original — pas de réentraînement complet du modèle.

L'implémentation GQA (Grouped Query Attention) est particulièrement soignée : une seule tête Forecast par groupe GQA, contre une tête de sélection par tête de requête dans les approches multi-head classiques. Cela réduit directement l'overhead de sélection, qui était précisément le second goulot identifié.

### 3. Les chiffres réels sur modèles 8B

Sur deux modèles 8B pré-entraînés avec attention sparse : - **1,25× speedup prefill** vs baseline sparse avec offload - **1,7× speedup decode** vs baseline sparse avec offload - **5,3× throughput decode** vs baseline sparse sans offload, grâce à l'augmentation des batch sizes feasibles sur un seul GPU

Le dernier chiffre mérite attention : le 5,3× n'est pas un speedup sur requête unique, c'est un gain de débit obtenu parce que SparDA permet d'augmenter la taille de batch sur un GPU unique — l'offload libère de la VRAM, et la latence PCIe étant masquée, le coût de cet offload disparaît effectivement. La précision est maintenue ou légèrement améliorée sur les deux modèles testés.

### 4. Qui perd, qui gagne, et ce qui reste ouvert

**Gagnants directs** : les équipes déployant des LLMs 8B+ sur contextes longs (>32K tokens) avec contrainte GPU unique ou multi-GPU serrée. L'infrastructure d'inférence existante basée sur vLLM ou TensorRT-LLM devra intégrer la logique de préchargement lookahead — ce n'est pas un drop-in.

**Perdants potentiels** : les approches d'offload KV sans prédiction lookahead (InfLLM, certaines configurations SnapKV) deviennent moins compétitives sur le ratio latence/coût. Les solutions purement hardware (NVLink haute bande passante pour éliminer le goulot PCIe) perdent une partie de leur justification économique si le goulot est masqué logiciellement.

**Limites non résolues** : SparDA nécessite des modèles pré-entraînés avec attention sparse — elle ne s'applique pas directement à des modèles denses existants sans phase d'adaptation. Les benchmarks sont limités à deux modèles 8B ; la généralisation à 70B+ ou aux architectures MoE n'est pas démontrée. La qualité de la prédiction Forecast sur des distributions de tokens très hétérogènes (code, multilingue, très long document) reste à évaluer en production.

Le code source est disponible sur github.com/NVlabs/SparDA. Compte tenu de l'origine NVlabs, une intégration dans l'écosystème TensorRT-LLM est probable à moyen terme.