Traitement par lots et utilisateurs multiples

Une requête à la fois — c'est ainsi que démarre toute session de bureau — et cela gaspille un GPU. Tout le jeu du service, c'est le traitement par lots : faire qu'une passe à travers les poids serve plusieurs requêtes d'un coup. Cette page couvre pourquoi ça marche, ce que sont réellement le batching continu et la paged attention, quand il faut un vrai moteur de service, et comment dimensionner la bête.

Pourquoi le service sériel gaspille le GPU

Rappelez-vous la formule de vitesse : chaque jeton décodé lit pour ainsi dire tous les poids actifs une fois (vitesse). En servant un flux, le GPU fait toute cette lecture pour un jeton d'un seul utilisateur. Groupez maintenant huit flux dans la même passe avant : les poids sont lus une fois et utilisés pour huit séquences — l'arithmétique supplémentaire est quasi gratuite, parce que le décodage est limité par la bande passante, pas le calcul. La vitesse par flux baisse à peine tandis que le débit total grimpe presque linéairement, jusqu'à saturation de la bande passante ou de la mémoire KV. Ce seul fait est toute l'économie du service local.

Batching statique vs continu

La version naïve — le batching statique — groupe des requêtes arrivées ensemble et exécute le lot jusqu'à ce que chaque membre finisse. Ça marche, mal :

Le batching continu (au niveau itération) — le défaut dans vLLM et SGLang — explique pourquoi ces moteurs tiennent sous le vrai trafic tandis que les serveurs naïfs s'effondrent.

Paged attention : corriger la fragmentation du KV

Chaque requête active a besoin de mémoire de cache KV (voir cache KV). L'ancienne approche réservait d'emblée le contexte maximal de chaque requête — donc un chat utilisant 2k jetons pouvait tenir un bloc de 32k réservé, verrouillé et inutilisable par quiconque d'autre. La majeure partie du pool KV restait inactive. La paged attention stocke le KV en blocs à taille fixe alloués à la demande, comme un OS pagine la mémoire : le gaspillage passe de la majorité (les auteurs de vLLM rapportaient 60–80% dans leur papier) à quelques pourcents, plusieurs fois plus de séquences simultanées tiennent, et le débit suit. Même idée, désormais standard dans les moteurs de service.

Coût pour vous : rien de visible — c'est un changement d'allocateur ; vous voyez juste une capacité simultanée plus élevée sur le même GPU.

Quand il faut un vrai moteur de service

Le coin des jeux de ce forum est l'exemple canonique de la dernière ligne : les matchs échecs et janggi exécutent plusieurs agents, chacun demandant un coup environ chaque seconde — petits prompts, nombreux flux, prompts système partagés. C'est exactement la charge qui veut un moteur de service avec batching, pas ollama run en boucle (voir agents).

Débit vs latence

Chaque réglage échange l'un contre l'autre : de plus gros lots montent le tok/s total tout en baissant légèrement la vitesse par flux, et la file d'attente monte le TTFT en charge. Un assistant de code pour une personne veut la concurrence plafonnée à 1–2 pour que le flux de l'humain ne fasse jamais la file. Un service de chat pour trente personnes veut des lots pleins. Décidez qui vous êtes avant de régler (voir service pour TTFT vs décodage comme mesures séparées).

Ce qui ressemble le plus à un repas gratuit, c'est le cache de préfixe (SGLang) : les longs prompts répétés deviennent un préremplissage quasi nul, ce qui est la plupart des charges d'agents.

Options pratiques

# llama.cpp : slots de décodage parallèles (le contexte est réparti entre slots)
llama-server -m model.gguf -c 32768 -np 4

# Ollama : requêtes parallèles par modèle (redémarrer le service après réglage)
export OLLAMA_NUM_PARALLEL=4

# vLLM : les deux qui comptent
vllm serve model --max-num-seqs 32 --gpu-memory-utilization 0.90

La file se forme en amont de tout cela : quand chaque slot est occupé, les nouvelles requêtes attendent. Surveillez la profondeur de file et le TTFT, pas les vibes.

Fixez aussi des limites en amont : un reverse proxy avec plafond de connexions échoue vite et honnêtement, là où une file profonde échoue lentement et mystérieusement.

Planification de capacité, en gros

Ce qu'une requête coûte au-delà des poids, c'est le cache KV, par jeton, pour tout son contexte :

octets KV/jeton ≈ 2 × layers × kv_heads × head_dim × bytes_per_value

Exemple détaillé, modèle dense 8B typique (32 couches, 8 têtes KV, dimension de tête 128, valeurs fp16) : 2 × 32 × 8 × 128 × 2 B ≈ 131 KB par jeton → une conversation de 2k jetons ≈ 256 MiB de KV → dix tels chats ≈ 2.5 GB par-dessus les ~5 GB de poids.

(le 2 est pour K et V ; voir cache KV). Les agents à long contexte sont donc bien plus chers par requête que le chat. Tableau de confort approximatif, fortement prudent — contextes de longueur chat, ordre de grandeur seulement :

Mesurez avec vos vrais prompts : la longueur de contexte déplace ces chiffres plus que toute autre variable.

Signaux que vous êtes saturé

• Le TTFT grimpe de millisecondes à des secondes au fil de la journée.
• Profondeur de file durablement au-dessus de zéro ; requêtes en attente avant le premier jeton.
• tok/s par flux qui fléchit à mesure que les lots se serrent.
• Logs vLLM montrant préemption ou recalcul de KV — pression mémoire, pas lenteur du modèle.

L'un de ceux-ci : plafonnez le contexte, quantifiez le cache KV, ou ajoutez du GPU — dans cet ordre de bon marché — avant que vos utilisateurs ne se plaignent fort.

Tracez le TTFT et la profondeur de file sur une journée — une montée régulière signifie capacité, une dent de scie signifie des rafales que vous pouvez absorber avec une file.

Louer vs acheter, esquissé

À ce jour, un GPU loué de classe 24GB tourne à environ $0.50–2/heure, et une carte 24GB d'occasion coûte quelques centaines de dollars — seuil de rentabilité vers 300–1,000 heures de génération réelle. Le local gagne sur la confidentialité, la latence et l'absence de limites de débit (le cadrage dans pourquoi local) ; la location gagne sur la demande en rafales et les modèles de classe 80GB qu'aucune carte grand public ne tient (voir calcul de VRAM pour qui tient où). La plupart des gens surestiment leurs heures — instruentez une vraie semaine avant de décider.

Voir aussi : vitesse · cache KV · servir un endpoint · calcul de VRAM