Pendant la génération, un modèle réutilise les clés et valeurs d’attention déjà calculées. Ce cache KV grandit avec le nombre de séquences et leur longueur, et peut devenir la principale contrainte mémoire du serveur.
Le problème de l’allocation contiguë
Si chaque requête réserve dès le départ un grand bloc contigu correspondant à sa longueur maximale, une partie reste inutilisée et la mémoire se fragmente. Les longueurs réelles étant imprévisibles, ce gaspillage réduit le nombre de requêtes simultanées.
L’idée de PagedAttention
PagedAttention découpe le cache KV en blocs et maintient une table qui associe les blocs logiques d’une séquence à des blocs physiques. Le principe rappelle la mémoire virtuelle : une séquence peut grandir sans exiger une zone contiguë, et les blocs sont alloués à mesure des besoins.
Cette organisation facilite également le partage de blocs pour certains préfixes communs. Elle ne rend pas la mémoire illimitée : modèle, contexte et concurrence doivent toujours respecter la capacité disponible.
Le batching continu
Un batch statique attend que toutes ses séquences terminent. Avec le batching continu, le moteur retire les requêtes achevées et insère de nouvelles requêtes entre les étapes de génération. Le GPU reste mieux occupé malgré des réponses de longueurs différentes.
Effets opérationnels
Le débit global peut augmenter, mais la latence individuelle dépend de la charge et de l’ordonnancement. Surveillez la file d’attente, l’utilisation du cache KV, le temps au premier token et les tokens générés par seconde. Limitez les contextes et sorties excessifs pour éviter qu’une requête monopolise la capacité.
PagedAttention et le batching continu expliquent une partie de l’efficacité de vLLM ; le gain réel dépend du modèle, du matériel et de la distribution de vos requêtes. Mesurez toujours avec une charge représentative.