L'inférence LLM en production : un guide pratique

L'entraînement attire l'attention. L'inférence porte la charge. Le trafic est dense, la longueur des instructions varie et les gens s'attendent à ce que des mots apparaissent à l'écran presque immédiatement. Pour tenir cette promesse, vous avez besoin d'une configuration de serveurs qui traite la mémoire, le traitement par lots et les coûts comme des préoccupations de premier ordre. Il existe toujours un équilibre entre la minimisation de la latence et l'optimisation du débit lors de l'optimisation de l'inférence LLM. Une faible latence est essentielle pour les applications interactives afin de garantir une bonne expérience utilisateur.

Vous voulez configurer votre propre serveur de modèles ? Compute permet de choisir une instance pour un déploiement autogéré. Vérifiez le moteur, le matériel et les options de connexion disponibles. Pour un modèle géré, consultez séparément l’offre Hivenet Inference API.

Pourquoi l'inférence est difficile

Les demandes arrivent par rafales et les invites ont des longueurs variables. Pour un modèle Transformer autorégressif, le cache KV se construit pendant le préremplissage, puis s’allonge au décodage. Sur un déploiement GPU, poids, cache et espaces de travail partagent la VRAM ; les limites de mémoire et de calcul peuvent affecter l’attente et le débit.

Votre objectif est simple à définir : maintenir une faible latence tout en diffusant autant de jetons par seconde que nécessaire à vos utilisateurs, sans dépasser le budget. L'équilibre entre latence et débit est essentiel pour optimiser l'inférence LLM, car les deux indicateurs ont un impact significatif sur les performances et les coûts. L'évaluation des performances du LLM implique le suivi de ces indicateurs afin de garantir un fonctionnement efficace et rentable. L'un des plus grands défis de l'inférence LLM est son coût de calcul, qui peut entraîner une latence et des dépenses élevées. La latence est cruciale pour l'expérience utilisateur dans les applications interactives en temps réel.

Les indicateurs à surveiller

Voici les indicateurs clés généralement mesurés lors de l'évaluation des performances d'inférence LLM :

• Délai jusqu’au premier jeton (TTFT). Côté client, mesurez le temps entre l’envoi de la requête et la réception du premier jeton non vide. L’attente, le préremplissage et le réseau y contribuent.
• Jetons par seconde (TPS). Précisez si la mesure concerne une réponse ou le débit agrégé du serveur. Elles ne décrivent pas la même chose.
• Débit. Comptez les requêtes terminées ou les jetons produits par unité de temps, avec des objectifs de latence définis. Le nombre de requêtes simultanées est une mesure de concurrence, pas un débit.
• Latence entre jetons (ITL). Mesurez le délai entre les livraisons de jetons et ses percentiles. Documentez la définition de l’outil, car les réponses peuvent arriver par groupes de jetons.

Mesurez aussi la latence de bout en bout et ses percentiles. Comparez les définitions des métriques et conservez le même modèle, tokenizer et profil de requêtes : des TPS obtenus avec des tokenizers différents ne sont pas directement équivalents.

Choisir une configuration pour votre charge

Vérifiez les configurations disponibles, l’image compatible et le tarif actif avant de lancer une instance. Configurez et testez votre serveur avant de lui envoyer du trafic.

Ouvrir la console Compute

Architectures de déploiement

Un seul GPU. Commencez ainsi si les poids, le cache KV et les espaces de travail tiennent en mémoire avec la charge prévue. La seule étiquette « 7B » ou « 13B » ne garantit pas qu’un modèle tienne sur une carte.

Plusieurs GPU. Le parallélisme tensoriel ou par pipeline peut répartir un modèle lorsque le moteur le permet. La mémoire ne fusionne pas automatiquement et les communications ont un coût. Comparez aussi des répliques indépendantes pour augmenter la capacité en requêtes.

Mise à l’échelle horizontale. Répartissez les requêtes entre plusieurs répliques derrière une passerelle. Un routage tenant compte du cache peut aider, mais une session persistante ne garantit pas la réutilisation d’un préfixe et peut déséquilibrer la charge. Testez aussi les pannes et l’isolation entre utilisateurs.

Points de terminaison sans serveur. Vérifiez les limites de capacité, la tarification et les éventuels démarrages à froid du fournisseur. Cette option générale ne décrit pas le fonctionnement actuel à répliques fixes de Hivenet Inference API.

La flotte GPU Compute actuelle utilise des RTX 5090 avec 32 Go par GPU ; les RTX 4090 ne sont plus proposées. Vérifiez la capacité, le prix et la compatibilité du moteur dans la configuration choisie.

Les moteurs en un coup d'œil

vLLM. Moteur de service avec traitement par lots continu, gestion du cache KV et serveur compatible avec certaines API OpenAI. Vérifiez les modèles, routes et options pris en charge dans la version déployée.

Text Generation Inference (TGI). La documentation Hugging Face indique désormais un mode de maintenance. Pour un nouveau déploiement, examinez les moteurs activement développés recommandés par le projet, selon vos modèles et votre matériel.

TensorRT-LLM. Moteur NVIDIA pour le matériel et les modèles pris en charge. Les performances dépendent de la configuration ; prévoyez de tester et d’optimiser votre charge plutôt que de supposer une vitesse maximale.

Ollama. Idéal en local ou pour les configurations simples à boîtier unique. Moins axé sur les API à trafic élevé.

Choisissez en fonction du profil de trafic, de la prise en charge des modèles et du niveau de réglage que vous souhaitez acquérir.

Contexte et mémoire

Les invites longues, les sorties longues et les requêtes simultanées augmentent les besoins du cache KV. Le coût exact dépend aussi de l’architecture et de la précision du cache. Fixez des limites de contexte et de concurrence, puis surveillez les préemptions et les erreurs. Voici trois approches à évaluer :

• Génération augmentée par récupération (RAG). Récupérez les passages utiles et limitez leur volume. RAG ne raccourcit pas automatiquement les invites et ajoute un travail de récupération ; mesurez la qualité et la latence de l’ensemble.
• Gestion du cache. vLLM peut organiser le cache en blocs. La réutilisation des préfixes est une optimisation distincte qui dépend des jetons communs et des réglages ; vérifiez les mécanismes d’isolation lorsque plusieurs utilisateurs partagent le service.
• Quantification. Selon la méthode, elle réduit la précision des poids, des activations ou du cache. Ces éléments ne sont pas nécessairement quantifiés ensemble. Testez la mémoire, la performance et la qualité sur des données représentatives.

Quantification, en bref

Une précision réduite peut économiser de la mémoire, mais les gains de débit et les pertes de qualité varient. AWQ et GPTQ sont notamment utilisés pour quantifier les poids. Vérifiez les formats et matériels pris en charge, puis comparez les résultats à une référence. Une faible dégradation de qualité ne doit pas être supposée.

Choix de matériel

• La mémoire d’abord. Additionnez les poids, le cache et les espaces de travail. Une carte de 24 Go peut convenir à certaines configurations 7B, pas à tous les contextes ni niveaux de concurrence. Le guide de choix du GPU pour l’inférence détaille ce dimensionnement.
• Le calcul et la bande passante ensuite. Le préremplissage est souvent limité par le calcul et le décodage à faible taille de lot par la bande passante mémoire. Mesurez les goulots d’étranglement ; le nombre de cœurs seul ne prédit pas les performances.
• Placement sur le réseau. Placez le terminal à proximité des utilisateurs. La latence du réseau s'accumule rapidement. FlashAttention réorganise les calculs du mécanisme d'attention afin de réduire les besoins en bande passante mémoire.

L'optimisation de la sélection du matériel et des stratégies de traitement par lots est essentielle pour optimiser la rentabilité de l'inférence LLM, en équilibrant les performances avec les coûts des ressources et de l'infrastructure.

Vérifiez les emplacements disponibles pour le service et le modèle choisis. Les régions Compute et Inference API peuvent différer. Dans l’Inference API, « Global » laisse Hivenet attribuer un emplacement disponible ; vérifiez son résultat dans les détails du point de terminaison.

Des coûts qui comptent

• Heures-GPU. Dimensionnez le matériel selon le modèle et le trafic. Vérifiez si le tarif s’applique au GPU, à l’instance ou à une réplique gérée avant de calculer le coût.
• Temps d’inactivité. Utilisez uniquement les contrôles d’arrêt et de mise à l’échelle pris en charge par votre déploiement. Hivenet Inference API utilise actuellement des répliques fixes sans autoscaling. Vérifiez la facturation et la capacité disponible avant un redémarrage.
• Jetons inutiles. Réduisez les passages superflus et fixez une limite de sortie adaptée. Le streaming rend la progression visible mais ne réduit pas à lui seul le calcul ni la facturation.
• Taille du lot Des tailles de lots plus élevées peuvent conduire à une utilisation plus efficace du GPU, mais peuvent augmenter la latence pour les demandes individuelles. Des lots de plus grande taille peuvent améliorer le débit mais entraînent généralement une augmentation de la latence. Le mode Streaming permet aux LLM de fournir des sorties incrémentielles, améliorant ainsi l'expérience utilisateur. L'optimisation du débit avec des tailles de lots optimales peut améliorer considérablement la rentabilité en utilisant au mieux les ressources matérielles disponibles.

L'équilibre entre latence et débit est essentiel pour optimiser l'inférence LLM, car les deux indicateurs ont un impact significatif sur les performances et la rentabilité.

Pour une première estimation, divisez les jetons de sortie quotidiens par le débit agrégé mesuré du déploiement avec un profil d’entrée comparable. Le résultat est en secondes : divisez par 3 600 pour obtenir les heures, puis tenez compte du nombre de GPU et de l’unité facturée. Ajoutez l’inactivité, la redondance et la marge pour les pics. Exemple : 3 600 000 jetons à 1 000 jetons/s correspondent à une heure de fonctionnement, soit deux heures-GPU pour deux GPU actifs. Ce calcul ne remplace pas un test de charge.

Fiabilité et observabilité

L'analyse comparative des performances du LLM et l'évaluation des performances du LLM à l'aide de mesures clés sont essentielles pour garantir des déploiements fiables et efficaces. Le suivi de ces indicateurs aide les équipes à comprendre la capacité du système, à identifier les goulots d'étranglement et à optimiser l'utilisation des ressources.

Suivez au moins :

• Taux de demandes, longueur de file d'attente, TTFT, TPS
• Occupation du cache KV, préemptions et mémoire GPU ; taux de réutilisation des préfixes si cette fonction est activée
• Utilisation des ressources d'inférence des modèles (utilisation du GPU et besoins en mémoire pendant l'inférence)
• Types d'erreurs : OOM, timeouts, 5xx
• La surveillance de l'utilisation de la bande passante des modèles (MBU) peut aider à comparer l'efficacité de différents systèmes d'inférence.

Les mesures d'analyse comparative courantes incluent le délai jusqu'au premier jeton (TTFT) et le nombre de jetons par seconde (TPS), qui sont essentiels pour évaluer les performances du système. L'analyse comparative des LLM est essentielle pour évaluer leurs performances et leur efficacité dans des applications réelles, afin d'aider les équipes à identifier les domaines à améliorer et à optimiser. L'évaluation des performances des LLM implique l'utilisation de divers outils qui définissent, mesurent et calculent les métriques différemment. L'analyse comparative des performances permet d'identifier les problèmes liés à l'efficacité et à l'optimisation des modèles. La combinaison des tests de charge et de l'analyse comparative des performances fournit une compréhension complète des capacités de déploiement du LLM. L'analyse de la courbe de latence est également importante pour comprendre le compromis entre la taille du lot et la latence, et comment les différentes configurations affectent le débit et les temps de réponse.

Alerte lorsque le TTFT augmente ou que le TPS diminue sous une charge constante. Cela est souvent le signe d'une pression de la mémoire, d'un mauvais traitement par lots ou de problèmes de performances.

Sécurité et résidence des données

Chiffrez les connexions, faites tourner les clés et limitez l’accès. Définissez les données journalisées, leur durée de conservation et leur suppression. Vérifiez aussi les emplacements des services de récupération, stockage, surveillance et sauvegarde ; la région du serveur ne décrit pas à elle seule tout le parcours des données.

Avant d’exposer un serveur autogéré sur Compute, vérifiez sa configuration réseau, le port, le pare-feu et l’authentification. Les instructions de connexion décrivent les prérequis d’accès. Une URL HTTPS ne remplace pas le contrôle d’accès.

Construisez ou achetez

Choisissez Compute pour gérer l’instance, le moteur et le serveur vous-même. Choisissez Hivenet Inference API si un modèle et une variante gérés répondent au besoin. Suivez les instructions de requête du point de terminaison, avec l’URL, la valeur du modèle et la clé API exactes. Testez les options et réponses attendues avant de transférer le trafic.

FAQ

Qu'est-ce que le TTFT et pourquoi est-ce important ?

Le délai d'arrivée du premier jeton est l'intervalle entre l'envoi d'une invite et l'affichage du premier jeton. Le TTFT court améliore la perception de la vitesse et de la confiance. Les gens ressentent ce chiffre plus que tout autre. La latence des requêtes de bout en bout (e2e_latency) inclut le temps entre l'envoi d'une demande et la réception du jeton final, fournissant ainsi une mesure plus large de l'expérience utilisateur.

Combien d'utilisateurs simultanés un GPU peut-il desservir ?

Cela dépend du modèle, de la précision, du contexte, des sorties et des objectifs de latence. Mesurez la capacité avec des requêtes représentatives. Le streaming ne crée pas de capacité de calcul supplémentaire.

Est-ce qu'un contexte long vaut RAG ?

Pas toujours. Les contextes longs sont simples mais coûteux. RAG maintient les instructions serrées et vous permet de redimensionner la récupération de manière indépendante. De nombreuses équipes utilisent un hybride.

Ai-je besoin de plusieurs GPU dès le départ ?

Commencez par un seul GPU si la mémoire et la performance suffisent. Sinon, comparez la répartition du modèle et les répliques indépendantes. Testez les modes pris en charge et le coût des communications.

Puis-je conserver des données dans l'UE ?

Si vous exigez un traitement limité à l’UE, choisissez un emplacement explicitement disponible et vérifiez les détails du point de terminaison ainsi que les autres services de votre application. Le choix « Global » ne garantit pas un placement dans l’UE.

Qu'est-ce qu'une inférence LLM ?

L'inférence LLM est le processus par lequel un grand modèle de langage génère une réponse basée sur une invite de saisie en traitant des jetons via son réseau neuronal. Lors de l'inférence, le LLM traite l'invite en activant son vaste réseau de paramètres pour prédire la séquence de jetons la plus probable. Les LLM peuvent traiter de gros volumes de texte et fournir des résumés concis d'articles ou de documents.

Quelles sont les étapes de l'inférence LLM ?

L'inférence LLM comporte généralement deux étapes : la phase de préremplissage, au cours de laquelle les jetons d'entrée sont traités, et la phase de décodage, au cours de laquelle le modèle génère des jetons de sortie un par un.

Quelle est la différence entre l'inférence et la formation LLM ?

L'entraînement consiste à ajuster les paramètres du modèle à l'aide de grands ensembles de données, tandis que l'inférence utilise le modèle entraîné pour générer des sorties sans modifier ses paramètres. Les LLM peuvent générer des articles, des articles, des textes marketing et même du code.

Que sont les moteurs d'inférence LLM ?

Il s'agit de systèmes logiciels conçus pour exécuter efficacement des LLM afin de générer des sorties, en optimisant la latence, le débit et l'utilisation des ressources.

À quoi sert vLLM ?

vLLM est un moteur d'inférence axé sur une forte simultanéité avec un traitement par lots continu et une gestion efficace du cache clé-valeur afin d'optimiser le service LLM.

Quelle est la différence entre vLLM et LLM ?

LLM fait référence au grand modèle de langage lui-même, tandis que vLLM est un moteur ou un framework permettant de servir efficacement les LLM en production.

Est-ce que vLLM est plus rapide qu'Ollama ?

Aucun moteur n’est systématiquement plus rapide. Comparez la même version du modèle, la précision, le matériel, les longueurs de requête et la concurrence. Examinez ensemble le débit, la latence et les fonctions requises.

Pourquoi vLLM est-il si rapide ?

Le traitement par lots continu et la gestion du cache peuvent améliorer l’utilisation des ressources. Leur effet dépend de la charge et des réglages ; ils ne garantissent pas une baisse de latence pour chaque requête.

Que signifie le fait de servir en LLM ?

Le service LLM fait référence au déploiement et à l'exécution de grands modèles de langage pour répondre aux demandes des utilisateurs en temps réel ou en mode batch.

Qu'est-ce qu'un moteur de service LLM ?

Il s'agit d'une plate-forme ou d'un logiciel qui héberge et gère les LLM, en gérant efficacement les demandes d'inférence.

Qu'est-ce qu'un serveur LLM ?

Serveur configuré pour exécuter des charges de travail d'inférence LLM, permettant d'accéder aux prévisions des modèles via des API ou d'autres interfaces.

Que signifie LLM en tant que juge ?

Cela fait référence à l'utilisation des LLM pour évaluer ou noter les résultats, tels que l'évaluation de la qualité du modèle ou le classement des réponses.

Qu'est-ce que les jetons par seconde ?

Le nombre de jetons par seconde (TPS) mesure le nombre de jetons qu'un LLM génère ou traite en une seconde, ce qui indique le débit.

Combien de mots font 1 000 jetons ?

Le rapport varie selon la langue, le texte et le tokenizer. Comptez les jetons avec le tokenizer du modèle utilisé plutôt que de convertir tous les textes avec un ratio fixe.

Que signifie un jeton dans l'IA ?

Un jeton est la plus petite unité de texte traitée par un modèle de langage. Il peut s'agir d'un mot, d'un sous-mot ou d'un caractère.

Qu'est-ce que le TTFT ?

Le temps écoulé entre l'envoi d'une demande et la réception du premier jeton généré (TTFT) correspond à la latence entre l'envoi d'une demande et la réception du premier jeton généré.

Comment mesurer le TTFT ?

En enregistrant la différence de temps entre la soumission d'une invite et la réception du premier jeton de sortie du modèle.

Qu'est-ce que la métrique TPOT dans LLM ?

Le temps par jeton de sortie (TPOT) mesure le temps moyen nécessaire pour générer chaque jeton de sortie après le premier.

Qu'est-ce qu'un cache KV ?

Le cache KV conserve les tenseurs de clés et de valeurs calculés pendant le préremplissage et le décodage. Il permet de réutiliser cet état d’attention pour les jetons suivants.

Qu'est-ce que le cache GPU KV ?

Il s'agit du stockage des données de cache clé-valeur dans la mémoire GPU pour accélérer la génération de jetons LLM.

Qu'est-ce que le cache KV dans LLM ?

Le cache KV contient les clés et les valeurs des jetons précédents afin de calculer efficacement l'attention portée aux nouveaux jetons.

Qu'est-ce que le cache de stockage clé-valeur ?

Un stockage clé-valeur associe des valeurs à des clés pour les retrouver. Le cache KV d’un Transformer conserve des tenseurs d’attention. L’abréviation commune ne désigne pas le même mécanisme.

Qu'est-ce que le traitement par lots continu ?

L’ordonnanceur peut modifier les requêtes actives entre les itérations de génération, selon les ressources disponibles. Le guide du traitement par lots continu détaille les limites et les réglages.

Qu'est-ce qu'un lot continu ?

Le lot actif évolue entre les itérations : les requêtes terminées libèrent des ressources et des requêtes en attente peuvent être admises. Cela ne supprime pas les files d’attente ni les limites de capacité.

Quelle est la différence entre le traitement par lots en continu et le traitement par lots en vol ?

Dans la documentation TensorRT-LLM, « in-flight batching » désigne aussi le traitement par lots continu ou au niveau de l’itération. Les implémentations diffèrent ; ce n’est pas une opposition entre deux principes distincts.

Qu'est-ce que le débit et la latence LLM ?

Le débit correspond au nombre de jetons ou de requêtes qu'un LLM peut traiter par seconde ; la latence est le temps nécessaire pour générer des réponses.

Comment réduire la latence dans les LLM ?

En optimisant les stratégies de traitement par lots, en utilisant un matériel efficace, en réduisant la longueur des séquences d'entrée et en tirant parti de la mise en cache.

Quel est le plus gros problème avec le LLM ?

Les difficultés dépendent de l’application : qualité des réponses, erreurs factuelles, sécurité, latence, mémoire et coût. Définissez les critères d’acceptation de votre service au lieu de supposer un problème unique.

Quel est le débit d'un LLM ?

Il s'agit du nombre de jetons ou de requêtes qu'un LLM peut traiter par seconde dans des conditions données.

Comment tester le débit LLM ?

En mesurant les jetons générés au fil du temps sous des charges et une simultanéité contrôlées.

Le LLM utilise-t-il beaucoup de CPU ou de GPU ?

Cela dépend du moteur et du déploiement. Les GPU sont fréquents pour le calcul matriciel, mais des moteurs prennent aussi en charge le CPU et des configurations hybrides. La tokenisation et d’autres étapes peuvent rester côté CPU.

Comment augmenter le débit LLM ?

En regroupant les demandes par lots, en utilisant des moteurs d'inférence optimisés et en déployant sur de puissants GPU.

Quel GPU utiliser pour LLM ?

Les GPU dotés d'une mémoire et d'une bande passante mémoire élevées, tels que Nvidia RTX 4090 ou A100, sont couramment utilisés.

Est-ce que quelque chose de LLM utilise un GPU ?

Oui, l'inférence et l'entraînement LLM s'appuient largement sur les GPU pour le calcul parallèle.

Ai-je besoin d'un GPU pour exécuter LLM localement ?

Pour les grands modèles, un GPU est recommandé ; les petits modèles peuvent fonctionner sur des processeurs mais avec des performances réduites.

Le RTX 4090 est-il bon pour le LLM ?

Le RTX 4090 peut servir certaines charges d’inférence si la mémoire et le moteur conviennent. Il reste un exemple matériel dans cet article, pas une offre Compute actuelle : Hivenet a retiré sa flotte RTX 4090.

‍