Corpus VOCE · 24 septembre 2026

Cent utilisateurs interrogent un modèle presque simultanément.

Le serveur pourrait traiter chaque requête dès son arrivée.

VOCE Association11:00Archive canonique
VOCE

Publié le 24 septembre 2026 à 11:00 · Publication originale

Le serveur pourrait traiter chaque requête dès son arrivée.

C'est intuitif.

Ce n'est pas toujours efficace.

Les GPU sont conçus pour effectuer énormément d'opérations en parallèle. Une petite requête peut n'utiliser qu'une fraction de cette capacité.

Un serveur d'inférence peut donc attendre brièvement que plusieurs requêtes arrivent, les regrouper en un lot puis les présenter ensemble au GPU.

C'est le traitement par lots dynamique, ou "dynamic batching".

NVIDIA Triton Inference Server permet par exemple de définir des tailles de lots préférées et le temps maximal pendant lequel une requête peut attendre dans la file afin que d'autres la rejoignent.

Quelques centaines de microsecondes ou quelques millisecondes d'attente peuvent alors augmenter fortement le nombre de requêtes traitées par seconde.

Mais l'optimisation possède une limite.

Plus le serveur attend pour remplir ses lots, plus il augmente la latence de chaque utilisateur.

Le réglage dépend donc du service.

Une analyse nocturne de milliers d'images peut privilégier le débit. Une interaction vocale en temps réel ne possède pas le même budget d'attente.

Les requêtes n'ont pas non plus nécessairement la même taille.

Avec les modèles de langage, certaines contiennent quelques dizaines de tokens, d'autres plusieurs milliers. Les regrouper naïvement peut obliger le calcul à s'aligner sur des séquences beaucoup plus longues.

Les moteurs modernes utilisent donc des ordonnanceurs plus fins pour exploiter le GPU sans attendre qu'un lot entier soit terminé avant d'introduire de nouveaux travaux.

La vitesse ressentie par un utilisateur et l'efficacité globale de l'infrastructure deviennent ainsi deux mesures différentes.

Dans un centre de données IA, quelques millisecondes volontairement perdues peuvent permettre de récupérer beaucoup plus de calcul.

ULTRA®

Le débit maximal ne correspond pas nécessairement au coût minimal par requête.

Un GPU faiblement rempli consomme mémoire et énergie sans exploiter toutes ses unités de calcul. Augmenter le lot amortit une partie de ces coûts fixes.

Mais une requête longue peut retenir des ressources dont plusieurs courtes auraient besoin.

Les moteurs de LLM utilisent donc le "continuous batching": l'ordonnanceur peut insérer de nouvelles séquences lorsqu'une autre se termine, sans attendre la fin d'un lot figé.

La mémoire KV devient alors une ressource d'ordonnancement autant que de stockage.

Conseil: mesurer simultanément requêtes par seconde, tokens par seconde, temps jusqu'au premier token et latence p95/p99. Optimiser seulement la moyenne peut masquer les utilisateurs sacrifiés par les files d'attente.

NVIDIA Triton permet d'expérimenter le traitement par lots dynamique et ses délais de file.

La file d'attente n'est donc pas toujours le signe d'un serveur saturé. Elle peut être créée volontairement pour mieux remplir le GPU.

Faire découvrir cette publication

Partager cette recherche, ses sources et sa version intégrale.

#VOCEAssociation #Opera #MusicHistory #CulturalHeritage

LinkedIn Facebook

VOCE Academy

Continuer

← La ménopause n'est pas seulement une transition reproductive.
Xi'an. →

Ce texte appartient au corpus pédagogique et éditorial de VOCE Association. Lecture, découverte et citation sont publiques; les droits sur le texte et le corpus restent détenus par VOCE Association, sauf mention contraire. Droits du corpus.