Hugging Face Blog→ original

Hugging Face a accéléré l’inférence LLM de 22% grâce au batching asynchrone

Hugging Face a débloqué l’asynchronie dans l’inférence LLM. Au lieu d’alterner, le CPU et le GPU travaillent désormais en parallèle : pendant que le GPU calcule

Hugging Face a accéléré l’inférence LLM de 22% grâce au batching asynchrone
Source : Hugging Face Blog. Collage: Hamidun News.
◐ Écouter l'article

Hugging Face a trouvé un moyen simple d'accélérer la génération de tokens dans les LLMs de 22% — en faisant simplement fonctionner le CPU et le GPU simultanément au lieu d'attendre l'un l'autre. Cela ne nécessite pas de réentraînement de modèles ni de nouveaux algorithmes.

Quel Était le Problème

Dans le batching synchrone typique, le CPU prépare les données, puis le GPU les calcule, puis le CPU attend les résultats et prépare le lot suivant. Le GPU finit par être inactif environ 24% du temps — pendant que le CPU gère le prétraitement. C'est comme une chaîne de montage où à chaque étape quelqu'un regarde l'horloge. Même si le CPU fonctionne à pleine capacité, il est plus lent que le calcul GPU le plus simple, donc la carte graphique reste assise et attend de nouvelles données. En batching synchrone, un modèle de 8 milliards de paramètres avec une taille de lot de 32 a généré 8K tokens en 300 secondes avec une activité GPU de seulement 76%.

Comment l'Asynchronicité Résout le Problème

L'idée est extrêmement simple : exécuter le CPU et le GPU en parallèle via les streams CUDA. Trois streams indépendants sont utilisés — un pour transférer les données vers le GPU (H2D), un pour les calculs réels (Compute) et un pour le transfert inverse (D2H). Chaque stream rend le contrôle au CPU immédiatement sans le bloquer. Les événements CUDA sont placés entre les streams — des marqueurs qui garantissent l'ordre correct :

  • Le stream H2D marque quand les données sont chargées dans le GPU
  • Le stream Compute attend ce marqueur, calcule, pose le sien
  • Le stream D2H attend l'achèvement du calcul et récupère les résultats

Tandis que le GPU calcule le lot N, le CPU prépare déjà le lot N+1 dans un tampon mémoire différent. Aucune attente, ils travaillent en parallèle.

L'Astuce Principale du Carry-Over

La complexité est que lorsqu'une demande s'étend sur plusieurs lots, ses tokens de sortie du lot N deviennent l'entrée du lot N+1. Hugging Face a résolu ce problème avec des placeholders : lors de la préparation du lot N+1, des zéros sont placés où iront les entrées de tokens futurs, et lorsque le lot N est terminé, les zéros sont remplacés par des valeurs réelles.

« Cela permet au CPU de préparer le lot suivant sans attendre les résultats du lot actuel », explique Hugging Face.

Tout est maintenu ensemble avec des graphes CUDA avec un pool de mémoire partagé, ce qui économise même de la mémoire vidéo.

Les Chiffres Parlent d'Eux-Mêmes

Avant optimisation : GPU actif 76%, générant 8K tokens — 300,6 secondes. Après : GPU actif 99,4%, mêmes tokens — 234,5 secondes. Accélération de 22% — presque le maximum théorique pour cette architecture (le maximum théorique était 24%).

Ce Que Cela Signifie

Cela signifie que vous n'avez pas besoin de GPUs plus chers ni de réentraînement de modèles pour des améliorations sérieuses de vitesse. Le code est déjà dans la bibliothèque Transformers, la classe `ContinuousBatchingAsyncIOs`. Pour les entreprises qui génèrent de nombreux tokens, cela pourrait économiser des millions sur le matériel.

ZK
Hamidun News
Actualités IA sans bruit. Sélection éditoriale quotidienne de plus de 400 sources. Produit de Zhemal Khamidun, Head of AI chez Alpina Digital.
Qu'en pensez-vous ?
Chargement des commentaires…