Déployer des modèles de langage larges (LLM) à grande échelle dépend moins de l'architecture du modèle que de l'infrastructure sous-jacente. À mesure que les organisations passent du concept de preuve de concept à la production, le goulot d'étranglement se déplace de la taille du modèle vers le débit et la latence. Un serveur configuré pour l'entraînement est rarement optimisé pour l'inférence. Dans cet article, nous explorons les benchmarks et configurations critiques nécessaires pour maximiser l'utilisation des GPU pour le service de LLM à haut débit.
Définir vos métriques : Débit vs Latence
Avant de sélectionner le matériel, vous devez définir ce que signifie « haut débit » pour votre cas d'utilisation spécifique. Construisez-vous un chatbot nécessitant une latence de temps jusqu'au premier jeton (TTFT) inférieure à une seconde, ou un pipeline de génération de contenu automatisé privilégiant les jetons par seconde (TPS) ?
Pour un débit pur, vous devez maximiser l'utilisation du calcul. Cela implique souvent de regrouper dynamiquement les requêtes. Cependant, un regroupement agressif augmente la latence pour les requêtes individuelles. L'objectif est de trouver le « point idéal » où la mémoire GPU est entièrement utilisée par les lots actifs sans provoquer de délais de file d'attente excessifs.
La pile logicielle : Choisir le bon moteur d'inférence
La bibliothèque par défaut `transformers` de Hugging Face est excellente pour le prototypage mais inefficace pour la production en raison de l'absence de gestion de la mémoire paginée et du regroupement continu. Pour un haut débit, envisagez des moteurs spécialisés tels que vLLM ou TensorRT-LLM.
L'une des gains les plus significatifs provient de l'utilisation de PagedAttention, qui résout le problème de fragmentation de la mémoire inhérent aux mécanismes d'attention traditionnels. Cela vous permet de regrouper davantage de séquences dans la mémoire GPU simultanément, augmentant ainsi directement le débit.
Sélection du matériel et topologies NVLink
Tous les GPU ne se valent pas dans un cluster. Pour l'inférence LLM, la bande passante mémoire est souvent le facteur limitant, et non seulement les FLOPs bruts. Lors de l'exécution de modèles dépassant la mémoire d'un seul GPU (par exemple, 70 milliards de paramètres), vous devez diviser le modèle sur plusieurs GPU.
L'interconnexion est importante. Un serveur avec quatre GPU A100 connectés via PCIe 4.0 souffrira de surcharges de communication lors de la parallélisation des tenseurs. En revanche, les serveurs équipés de NVLink ou NVSwitch (comme la plateforme HGX) permettent des transferts de données entre GPU proches de la vitesse de la mémoire. Le benchmarking doit toujours comparer les configurations connectées via PCIe à celles connectées via NVLink pour quantifier la pénalité de latence.
Benchmarking pratique avec vLLM
Pour benchmarker la configuration de votre serveur, utilisez des outils qui simulent le trafic réel. Le script Python suivant montre comment benchmarker un modèle à l'aide de la bibliothèque `vLLM`, en mesurant à la fois la latence et le débit.
import vllm
from vllm import LLM, SamplingParams
# Définir le modèle et le tokenizer
model_name = "meta-llama/Llama-2-7b-chat-hf"
# Configurer le LLM avec le décodage spéculatif et la parallélisation des tenseurs
llm = LLM(
model=model_name,
tensor_parallel_size=4, # Ajuster en fonction du nombre de vos GPU
dtype="float16",
max_num_batched_tokens=8192,
max_num_seqs=256
)
# Générer des invites d'exemple
prompts = ["Hello, my name is", "The capital of France is"]
# Définir les paramètres d'échantillonnage
sampling_params = SamplingParams(temperature=0.8, top_p=0.95, max_tokens=100)
# Exécuter le benchmark
outputs = llm.generate(prompts, sampling_params)
# Afficher les résultats
for output in outputs:
prompt = output.prompt
generated_text = output.outputs[0].text
print(f"Prompt: {prompt!r}, Generated: {generated_text!r}")Lors de l'exécution de ce benchmark, surveillez l'utilisation du GPU à l'aide de `nvidia-smi` ou `nvtop`. Vous souhaitez voir une utilisation soutenue supérieure à 90 %. Si l'utilisation est faible, votre goulot d'étranglement est probablement lié à l'E/S (chargement des invites depuis le disque) ou à la tokenisation limitée par le CPU, et non au GPU lui-même.
Conclusion
Le benchmarking des configurations de serveurs GPU pour l'inférence LLM est un processus itératif. Commencez par sélectionner un moteur d'inférence optimisé comme vLLM, puis soumettez votre matériel à des tests de charge pour identifier les goulets d'étranglement dans la bande passante mémoire ou la latence d'interconnexion. En alignant votre topologie matérielle avec vos exigences de débit, vous pouvez réduire considérablement les coûts d'inférence tout en maintenant de hautes performances.