📰 🧵 Discussion : KV Cache et Paged Attention, l'arme absolue contre l'OOM ?

## 👤 Profils des intervenants

* **SysAdmin_Pro** : Membre "Senior DBA", 1850 messages. Très pragmatique, axé sur l'optimisation matérielle locale, l'architecture vLLM et la chasse au gaspillage de VRAM. Style de langage précis, technique et orienté production.
* **AI_Dev_Curious** : Membre "Intermédiaire", 420 messages. Enthousiaste mais se heurte souvent à des limites matérielles (OOM). Cherche à comprendre les mécanismes sous-jacents sans pour autant basculer dans une usine à gaz logicielle.

## 🧵 Discussion : KV Cache et Paged Attention, l'arme absolue contre l'OOM ?

```text
SysAdmin_Pro – Posté le 30/06/2026 à 16:15

Salut le forum. Je viens de revoir une conf d'IBM Tech sur la gestion de l'inférence à grande échelle et je voulais ouvrir un thread sur la configuration des moteurs vLLM, en particulier pour ceux qui auto-hébergent localement.

Pour faire simple : quand on lance un modèle (mettons un Llama 13B qui bouffe déjà 26 Go de VRAM rien que pour les poids du modèle), les 35 % restants d'une carte de 40 Go partent direct dans le KV Cache. Le vrai problème historique, c'est la fragmentation interne. Les systèmes classiques pré-allouent un bloc contigu gigantesque basé sur la taille de contexte max (par exemple 2048 tokens), même si l'utilisateur n'en demande que 200. Résultat : 60 à 80 % de la mémoire dédiée au cache est purement gaspillée.

La Paged Attention règle ça en découpant le KV Cache en pages non contiguës de 16 tokens (exactement comme la mémoire virtuelle d'un OS). Vous tournez à combien en ratio d'allocation sur vos pipelines de production ou vos setups locaux ?

```

```text
AI_Dev_Curious – Posté le 30/06/2026 à 16:42

@SysAdmin_Pro : Merci pour le résumé, ça pose bien les bases. De mon côté, je galère pas mal avec des erreurs Out-Of-Memory (OOM) dès que je pousse la concurrence au-delà de 5 utilisateurs simultanés sur mon instance locale.

J'avoue que la Paged Attention a l'air magique sur le papier, mais en pratique, la latence "Time to First Token" (TTFT) reste super élevée quand je balance un long prompt. Le "prefill phase" est hyper lourd au niveau calcul pur. Est-ce que la Paged Attention aide vraiment sur ce point précis, ou est-ce que ça ne fluidifie que la phase de décodage (token par token) ? 😭

```

```text
SysAdmin_Pro – Posté le 30/06/2026 à 17:05

@AI_Dev_Curious : Tu confonds deux goulots d'étranglement différents. La phase de prefill est compute-bound (limitée par la puissance de calcul du GPU), alors que la phase de decode est memory-bound (limitée par la bande passante mémoire). La Paged Attention optimise le décodage en évitant de recalculer les clés et valeurs des tokens précédents à chaque étape.

Si ton problème c'est le TTFT sur des prompts longs, tu as deux leviers majeurs à activer dans vLLM :

1. Le prefix caching : Si tes utilisateurs partagent un prompt système identique (comme dans un agent de code ou un pipeline RAG), vLLM calcule le prefill une seule fois, le stocke dans le cache physique via un système de hashage, et les requêtes suivantes sautent complètement cette étape. Le gain de temps est colossal.

2. Le chunked prefill : Par défaut, vLLM traite le prefill entièrement avant de reprendre le décodage, ce qui fait bégayer les tokens en cours de génération pour les autres utilisateurs. En activant le mode chunked, tu découpes le prefill en blocs pour occuper le budget de calcul restant sans bloquer le flux. Tu peux facilement gratter 50 % de throughput global.

Regarde aussi du côté du paramètre "gpu_memory_utilization". Par défaut il est à 0.9. Si tu as des workloads stables, tu peux le pousser à 0.95 pour tasser plus de requêtes, ou le descendre à 0.8 si tes rafales provoquent des crashs.

```

```text
AI_Dev_Curious – Posté le 30/06/2026 à 17:28

@SysAdmin_Pro : Ah ouais, d'accord ! Je comprends mieux pourquoi mon GPU faisait du surplace entre deux lectures mémoire. Je n'avais pas du tout activé le prefix caching alors que mes agents réinjectent le même contexte de base à chaque fois... Quelle perte de cycles. 🤦‍♂️

Je vais aller tweaker mes scripts pour intégrer le chunked prefill et le découpage de blocs. Pour la latence interactive, j'ai vu aussi qu'on pouvait coupler ça avec du speculative decoding (utiliser un petit modèle draft pour proposer des tokens validés ensuite par le gros modèle en une seule passe). Tu as testé ? Ça vaut le coup ou c'est encore une couche de complexité pour rien ?

```

```text
SysAdmin_Pro – Posté le 30/06/2026 à 17:35

@AI_Dev_Curious : Le speculative decoding, c'est très efficace mais c'est un compromis. Quand ta concurrence est faible, ton GPU a des cycles de calcul "inactifs" pendant les lectures mémoire du décodage. Le petit modèle draft en profite pour bosser. La qualité de sortie reste mathématiquement identique au gros modèle seul.

Par contre, attention : si ton instance tourne déjà à très haute concurrence, tes lots (batches) saturent déjà le GPU. Dans ce cas, les gains du speculative decoding s'effondrent. C'est à réserver uniquement si ta priorité absolue est la latence interactive sur un faible nombre d'utilisateurs simultanés. Si tu veux tester sans surcoût, vLLM intègre un "ngram speculator" natif via l'argument dédié, c'est idéal pour du texte très structuré ou répétitif.

Bref, commence par optimiser tes blocs de cache, le reste c'est du bonus pour peaufiner les derniers millisecondes. 😉

```