Entraînement vs inférence en IA : les différences en matière d'exigences matérielles

L'entraînement et l'inférence utilisent le même modèle pour deux tâches différentes.

Pendant l'entraînement, le système modifie le modèle.

Pendant l'inférence, le système l'utilise.

Cette distinction, apparemment simple, modifie presque toutes les exigences matérielles importantes.

L'entraînement peut durer des heures, des jours ou des semaines et privilégie un débit maximal sur de grands lots et de nombreux accélérateurs. L'inférence doit souvent répondre à un utilisateur en quelques millisecondes tout en traitant des milliers de requêtes de manière économique.

L'entraînement nécessite de la mémoire pour bien plus que les simples poids du modèle.

L'inférence peut souvent tolérer une quantification agressive qui serait inappropriée pour le processus d'entraînement.

Les clusters d'entraînement peuvent consacrer énormément de temps au transfert de gradients entre les accélérateurs.

Un service d'inférence peut se soucier davantage du temps nécessaire avant la génération du premier jeton.

C'est pourquoi demander quel est le « meilleur GPU pour l'IA » sans préciser s'il s'agit d'entraînement ou d'inférence revient à omettre l'aspect le plus important de la question.

NVIDIA décrit l'entraînement comme le processus itératif d'ajustement des poids d'un modèle à partir de données, tandis que l'inférence applique ces poids entraînés à de nouvelles entrées. La relation mathématique est étroite. Les exigences opérationnelles, elles, ne le sont pas. L'explication actuelle de NVIDIA sur l'entraînement et l'inférence couvre la distinction fondamentale. (blogs.nvidia.com)

Entraînement vs inférence IA en un coup d'œil

Le même accélérateur peut gérer les deux étapes.

‍

‍

Cela ne signifie pas pour autant qu'il soit aussi économique pour l'une que pour l'autre.

Qu'est-ce que l'entraînement en IA ?

L'entraînement en IA est le processus consistant à ajuster les paramètres d'un modèle afin d'améliorer ses résultats en fonction d'un objectif défini.

Une étape d'entraînement simplifiée se présente comme suit :

1. Envoyer les données d'entraînement à travers le modèle.
2. Générer une prédiction.
3. Comparer la prédiction avec le résultat souhaité.
4. Calculer une erreur ou une perte.
5. Propager les informations relatives à cette erreur en remontant à travers le modèle.
6. Calculer les gradients.
7. Mettre à jour les paramètres du modèle.
8. Répéter.

Ce passage en arrière est l'une des différences majeures entre l'entraînement et l'inférence.

L'inférence nécessite que le modèle calcule des résultats.

L'entraînement nécessite ces calculs, auxquels s'ajoutent les informations nécessaires pour déterminer comment le modèle doit évoluer.

Pour les grands réseaux de neurones, répéter cette opération des milliards, voire des milliers de milliards de fois, rend l'entraînement extrêmement gourmand en ressources de calcul. NVIDIA note que l'entraînement de Llama 3.1 405B a nécessité environ (3,8 × 10^{25}) opérations mathématiques sur l'ensemble du cycle d'entraînement. Ce chiffre provient des explications de NVIDIA et doit être compris comme une illustration de l'échelle impliquée plutôt que comme une exigence générale pour l'entraînement des LLM.blogs.nvidia.com)

Qu'est-ce que l'inférence IA ?

L'inférence IA est le processus consistant à utiliser un modèle entraîné pour effectuer une prédiction ou générer un résultat à partir de nouvelles données d'entrée.

Les paramètres du modèle ne sont généralement plus mis à jour.

Un modèle de vision par ordinateur peut classer une image.

Un modèle de recommandation peut classer des produits.

Un modèle de reconnaissance vocale peut convertir de l'audio en texte.

Un modèle de langage peut générer des jetons.

L'inférence est moins exigeante en calcul que l'entraînement du même modèle, dans la mesure où les gradients et les mises à jour des paramètres ne sont plus nécessaires.

Cela ne rend pas l'inférence peu coûteuse pour autant.

Un modèle au service de millions d'utilisateurs peut consommer beaucoup plus de ressources de calcul au cours de sa durée de vie opérationnelle que ce qui a été nécessaire pour l'entraîner.

Les modèles de raisonnement modernes peuvent également mobiliser une puissance de calcul importante lors de l'inférence en générant des traces de raisonnement plus longues ou en effectuant des calculs répétés avant de fournir une réponse.

L'infrastructure doit donc optimiser un problème différent :

Comment exécuter de manière répétée ce modèle entraîné avec la latence, l'échelle et le coût requis par l'application ?

Notre guide pratique de l'inférence LLM en production traite ce problème de déploiement en détail.

L'entraînement nécessite plus de mémoire vive

Une comparaison matérielle courante ne prend en compte que la taille du modèle.

Cela sous-estime considérablement la mémoire nécessaire à l'entraînement.

Supposons qu'un LLM contienne des poids occupant 20 Go.

L'inférence nécessite un accès à ces poids ainsi qu'à la mémoire d'exécution.

L'entraînement peut également nécessiter de la mémoire pour :

• les gradients ;
• les états de l'optimiseur ;
• les activations enregistrées ;
• les tampons temporaires ;
• la communication distribuée ;
• la surcharge du framework.

Selon l'optimiseur, le format numérique, l'architecture du modèle, la taille des lots et la méthode d'entraînement, ces structures supplémentaires peuvent largement dépasser la mémoire occupée par les poids eux-mêmes.

C'est pourquoi un modèle qui tient aisément sur un seul GPU pour l'inférence peut ne pas y tenir pour un entraînement complet.

Les activations font croître la mémoire d'entraînement avec la charge de travail

Lors de la passe avant, chaque couche du modèle produit des valeurs intermédiaires appelées activations.

L'entraînement nécessite bon nombre de ces valeurs ultérieurement lors de la rétropropagation.

Leur conservation consomme de la mémoire.

Augmentation :

• de la taille des lots ;
• de la longueur de séquence ;
• de la largeur du modèle ;
• la profondeur du modèle ;

et la mémoire d'activation peuvent augmenter considérablement.

Des techniques telles que le point de contrôle d'activation permettent d'échanger du calcul supplémentaire contre de la mémoire en enregistrant moins de valeurs intermédiaires et en recalculant certaines d'entre elles lors de la passe arrière.

Encore une fois, le choix du matériel ne peut pas se baser uniquement sur le nombre de paramètres.

L'état de l'optimiseur peut être coûteux

L'entraînement nécessite également de conserver les informations utilisées par l'algorithme d'optimisation.

Les optimiseurs de la famille Adam, par exemple, conservent des valeurs supplémentaires pour les paramètres du modèle.

Cela génère une surcharge mémoire importante lors de l'entraînement de milliards de paramètres.

Les systèmes d'entraînement distribués utilisent des techniques telles que le partitionnement des états de l'optimiseur, des gradients et des paramètres du modèle entre les accélérateurs afin de réduire les besoins en mémoire par appareil.

C'est l'une des raisons pour lesquelles les grands systèmes d'entraînement s'étendent souvent sur de nombreux GPU, même lorsque le débit arithmétique brut n'est pas la seule contrainte.

L' état du modèle doit être stocké quelque part.

L'inférence remplace les gradients par le cache KV

L'inférence élimine une grande partie de l'état d'entraînement.

Pour les LLM basés sur des transformeurs, un autre consommateur de mémoire important apparaît : le cache KV.

Lors de la génération, le modèle stocke les représentations des clés et des valeurs des jetons précédemment traités afin de ne pas avoir à recalculer tout l'historique d'attention à chaque nouveau jeton produit.

Cela accélère considérablement la génération.

Cela signifie également que l'utilisation de la mémoire augmente en fonction de :

• la longueur de la séquence ;
• la taille du lot ;
• le nombre de requêtes simultanées ;
• l'architecture du modèle ;
• la précision du cache.

Un serveur capable de gérer confortablement une conversation peut manquer de mémoire s'il doit traiter des centaines de longues conversations.

Ainsi, l'entraînement et l'inférence se préoccupent tous deux de la mémoire, mais pour des raisons différentes.

Le matériel d'entraînement privilégie généralement le débit

L'entraînement tend à favoriser l'exécution du maximum de calculs utiles au fil du temps.

Si un modèle met deux semaines à s'entraîner, réduire ce délai à une semaine présente une valeur évidente.

Des tailles de lots importantes permettent de maintenir les accélérateurs en activité.

Plusieurs GPU peuvent traiter différentes données simultanément.

Les grands modèles peuvent être répartis entre plusieurs processeurs.

L'infrastructure peut privilégier le débit total car aucun utilisateur n'attend la fin de chaque exemple d'entraînement individuel.

Cela ne signifie pas que la latence est sans importance dans l'entraînement distribué. Une communication lente peut bloquer tous les GPU.

La latence importante est toutefois généralement celle de la communication entre machines au sein du système d'entraînement, plutôt que la latence perçue par l'utilisateur.

L'inférence doit trouver un équilibre entre latence et débit

L'inférence en production poursuit deux objectifs contradictoires.

Traiter chaque requête rapidement.

Traiter autant de requêtes que possible.

Ces objectifs peuvent entrer en conflit.

Le regroupement de plusieurs requêtes en lots (batching) améliore l'utilisation des accélérateurs et le débit.

Attendre un lot plus important peut augmenter la latence.

Les recommandations actuelles de NVIDIA en matière d'inférence décrivent directement ce compromis : les charges de travail hors ligne peuvent utiliser de grands lots pour favoriser le débit, tandis que les applications en temps réel nécessitent des contraintes de latence plus strictes. (Guide de performance d'inférence NVIDIA)

Cela fait apparaître des métriques qui importent beaucoup moins lors de l'entraînement.

Pour le service de LLM, celles-ci incluent :

• le temps jusqu'au premier jeton ;
• le temps par jeton de sortie ;
• le nombre de jetons par seconde ;
• le nombre de requêtes par seconde ;
• la latence P50/P95/P99 ;
• le temps d'attente en file ;
• le débit utile (goodput) ;
• le coût par jeton.

Nous expliquons ces points dans notre Guide des métriques d'inférence LLM.

L'entraînement privilégie les grands lots

Les grands lots d'entraînement peuvent améliorer l'utilisation du matériel, car un même ensemble de poids de modèle peut être réutilisé pour de nombreuses entrées pendant que les accélérateurs restent sollicités.

C'est pourquoi les systèmes d'entraînement traitent souvent des centaines, des milliers, voire davantage d'exemples sous forme de lot global réparti sur plusieurs accélérateurs.

Le traitement par lots en inférence est davantage contraint par l'expérience utilisateur.

Une tâche d'inférence par lots traitant 10 millions d'images peut également utiliser de grands lots.

Un chatbot interactif ne peut pas attendre indéfiniment que suffisamment de requêtes s'accumulent pour remplir l'accélérateur.

C'est pourquoi les systèmes de production utilisent des techniques telles que le traitement par lots continu, où les requêtes entrent et sortent dynamiquement du lot actif au lieu d'attendre qu'un lot fixe soit complet.

Notre guide sur le traitement par lots continu explique comment cela peut modifier l'utilisation du GPU et l'économie de l'inférence sans changer le matériel.

L'entraînement et l'inférence peuvent utiliser des précisions numériques différentes

Les réseaux de neurones ont rarement besoin que chaque calcul soit effectué en FP32.

L'entraînement utilise désormais couramment la précision mixte, incluant des formats tels que BF16, FP16, FP8, avec une accumulation en précision supérieure lorsque nécessaire.

L'objectif est de réduire le trafic mémoire et d'augmenter le débit sans déstabiliser l'optimisation ni nuire au modèle entraîné.

L'inférence offre plus de liberté.

Le modèle n'est plus en phase d'apprentissage.

Ses poids peuvent souvent être convertis en formats beaucoup plus légers tels que :

• INT8 ;
• INT4 ;
• FP8 ;
• FP4 ;
• des combinaisons de précision mixte.

Cela peut réduire considérablement les besoins en mémoire.

Une représentation sur 4 bits nécessite environ un quart du nombre de bits d'une représentation sur 16 bits, sans compter les métadonnées de quantification et les détails d'implémentation.

Cela peut modifier entièrement les exigences matérielles.

Un modèle qui nécessitait plusieurs GPU en FP16 pourrait tenir sur moins d'accélérateurs après quantification.

Cependant, des poids plus petits ne garantissent ni une qualité équivalente ni une vitesse proportionnelle. Le matériel doit disposer de noyaux efficaces pour le format choisi.

Notre guide de quantification LLM aborde ces compromis.

L'entraînement nécessite une communication entre accélérateurs

Une fois que l'entraînement est réparti sur plusieurs GPU, la communication devient un facteur déterminant de la performance.

Dans le parallélisme de données, plusieurs GPU conservent des répliques du modèle et traitent des données différentes. Le système doit synchroniser les gradients.

Dans parallélisme tensoriel, des parties d'opérations individuelles sont réparties entre les accélérateurs.

Dans le parallélisme de pipeline, différents groupes de couches s'exécutent sur des appareils distincts.

Des systèmes d'entraînement plus élaborés combinent plusieurs méthodes.

Ces accélérateurs nécessitent donc une communication rapide.

La bibliothèque NCCL de NVIDIA fournit des opérations collectives telles que AllReduce pour les charges de travail multi-GPU et multi-nœuds, et le développement actuel de NCCL continue de cibler la latence et la bande passante de communication pour l'entraînement comme pour l'inférence. (NVIDIA NCCL)

À grande échelle, acheter des GPU en ignorant l'interconnexion peut produire un cluster coûteux dont les processeurs attendent constamment les uns après les autres.

L'inférence nécessite parfois la même interconnexion

L'inférence distribuée peut également nécessiter une communication à haut débit entre les accélérateurs.

Un modèle trop volumineux pour un seul appareil peut être fragmenté sur plusieurs GPU.

Le parallélisme tensoriel permet de diviser les couches entre les accélérateurs.

Les modèles de type « mixture-of-experts » peuvent transférer des tâches entre les appareils.

Les systèmes d'inférence à grande échelle peuvent même séparer le préremplissage et le décodage sur différents groupes d'accélérateurs.

Les interconnexions rapides ne sont donc pas réservées à l'entraînement.

La priorité est différente.

L'entraînement optimise souvent le débit d'une tâche distribuée colossale.

L'inférence doit préserver un débit utile tout en respectant les objectifs de latence de service pour de nombreuses requêtes indépendantes.

Le stockage revêt une importance différente

L'entraînement a besoin de données.

Potentiellement en quantités énormes.

L'infrastructure doit être capable de diffuser les jeux de données d'entraînement assez rapidement pour que les accélérateurs coûteux ne restent jamais inactifs en attendant des données.

L'entraînement génère également des points de contrôle afin qu'une tâche longue puisse se remettre d'une défaillance ou être reprise ultérieurement.

L'inférence a généralement des besoins en données plus légers.

Elle doit tout de même charger les poids du modèle, parfois très lourds, et peut dépendre du stockage pour :

• les adaptateurs ;
• les artefacts mis en cache ;
• les journaux ;
• les données de récupération ;
• l'état de l'application.

La pression se déplace : il ne s'agit plus d'alimenter un pipeline d'entraînement massif, mais de maintenir un service déployé réactif et disponible.

La fiabilité a des significations différentes

Une tâche d'entraînement peut durer plusieurs jours.

Une défaillance matérielle survenant vers la fin de l'exécution peut anéantir une quantité considérable de calculs utiles si les points de contrôle sont mal gérés.

L'infrastructure d'entraînement nécessite donc :

• points de contrôle ;
• détection des pannes ;
• reprise ;
• communication distribuée stable ;
• ordonnancement des tâches.

L'inférence est généralement un service de production.

La fiabilité devient :

• disponibilité ;
• taux de réussite des requêtes ;
• latence prévisible ;
• basculement ;
• répartition du trafic ;
• gestion de la surcharge.

Une charge de travail cherche à éviter la perte d'une semaine de travail.

L'autre cherche à éviter la perte de la prochaine requête utilisateur.

Le réglage fin est un entraînement

Le réglage fin est parfois décrit comme s'il s'agissait d'une troisième catégorie computationnelle.

D'un point de vue matériel, il appartient au domaine de l'entraînement.

Les paramètres du modèle, ou un sous-ensemble sélectionné de ceux-ci, sont mis à jour.

Le réglage fin complet peut nécessiter une mémoire importante pour les gradients et l'état de l'optimiseur.

Les méthodes à paramètres efficaces telles que LoRA modifient moins de paramètres et peuvent réduire considérablement la charge d'entraînement.

QLoRA va plus loin en combinant des poids de modèle de base quantifiés avec des adaptateurs de bas rang entraînables.

Cela permet d'effectuer un réglage fin utile sur du matériel qui ne pourrait jamais prendre en charge l'entraînement complet du même modèle.

La distinction importante reste de savoir si le modèle est modifié.

Si des paramètres sont en cours d'apprentissage, vous effectuez un entraînement.

L'entraînement à partir de zéro représente une charge de travail très différente du réglage fin

L'expression « entraînement IA » couvre un éventail énorme.

L'entraînement d'un modèle de pointe à partir de zéro peut impliquer d'immenses clusters d'accélérateurs fonctionnant pendant des mois.

Le réglage fin d'un modèle 7B existant avec LoRA peut tenir sur un seul GPU.

Un petit réseau de vision par ordinateur pourrait s'entraîner sur un ordinateur portable.

Les recommandations matérielles doivent donc préciser la méthode d'entraînement.

‍

‍

« L'entraînement nécessite huit GPU » est tout aussi faux que « l'inférence tient sur un seul ».

Le modèle et la méthode déterminent les besoins.

L'inférence varie également de minuscule à énorme

À l'autre extrémité :

‍

‍

C'est pourquoi le CPU vs GPU vs NPU choix doit être abordé aussi bien dans le cadre de l'entraînement que de l'inférence.

Le matériel d'entraînement est souvent conçu pour une montée en charge horizontale (scale-out)

L'entraînement de grands modèles tire profit de l'ajout d'accélérateurs tant que la charge de travail continue de s'adapter efficacement.

Cela rend plusieurs propriétés matérielles particulièrement importantes :

• la mémoire de l'accélérateur ;
• la bande passante mémoire ;
• l'interconnexion des accélérateurs ;
• la bande passante réseau ;
• la communication collective ;
• la capacité du CPU hôte ;
• le stockage haute vitesse.

La documentation actuelle de Google sur les TPU l'illustre directement. Les TPU Pods connectent de nombreux accélérateurs via un réseau dédié à haute vitesse, et les conseils de Google en matière d'entraînement recommandent de maintenir la taille des lots par cœur à mesure que les configurations TPU augmentent pour améliorer la mise à l'échelle. (Entraînement sur Google Cloud TPU)

La puce n'est qu'un composant de la machine d'entraînement.

L'infrastructure reliant les puces en est un autre.

Le matériel d'inférence peut optimiser une tâche plus spécifique

L'inférence stable crée une opportunité pour des processeurs plus spécialisés.

AWS a initialement distingué ces deux domaines de manière visible :

• Trainium pour l'entraînement ;
• Inferentia pour l'inférence.

Cette frontière est devenue moins rigide. Le positionnement actuel d'AWS Trainium inclut à la fois l'entraînement et l'inférence à grande échelle, tandis qu'Inferentia reste spécifiquement conçu pour l'inférence. Tous deux utilisent la pile logicielle AWS Neuron. (AWS Trainium, AWS Inferentia)

Les TPU de Google prennent également en charge ces deux étapes.

La documentation actuelle des Cloud TPU prend en charge l'entraînement et le réglage fin ainsi que le déploiement, y compris l'inférence LLM via vLLM sur les générations de TPU plus récentes. (Inférence Google Cloud TPU)

La leçon plus large est importante :

le matériel d'entraînement et le matériel d'inférence sont des catégories de charge de travail, et non des espèces de processeurs rigides.

Un processeur peut être performant dans les deux domaines.

Les GPU occupent une place centrale car la flexibilité a de la valeur

Les GPU restent utiles tout au long du cycle de vie complet d'un modèle.

Le même environnement GPU permet souvent de :

1. explorer le modèle ;
2. l'entraîner ou l'affiner ;
3. l'évaluer ;
4. exécuter des inférences par lots ;
5. déployer un serveur ;
6. analyser les goulots d'étranglement ;
7. tester le modèle suivant.

Cette continuité offre une réelle valeur opérationnelle.

Un processeur d'inférence spécialisé peut finir par surpasser le GPU sur le plan économique une fois que la charge de travail en production devient importante et prévisible.

Lors du développement, passer d'un environnement matériel spécifique à un autre peut coûter plus cher en temps d'ingénierie que ce qu'il permet d'économiser.

C'est pourquoi notre guide sur l'inférence : accélérateur IA vs GPU soutient que la spécialisation doit justifier ses contraintes.

Les NPU sont surtout pertinents pour l'inférence

Les NPU qui équipent désormais les ordinateurs portables et les appareils clients sont principalement conçus pour une inférence efficace.

Ils prennent en charge les charges de travail de réseaux neuronaux compatibles sans solliciter intensivement le CPU ou le GPU.

C'est une solution idéale pour :

• la transcription ;
• le traitement audio ;
• effets vidéo ;
• vision par ordinateur ;
• IA générative locale prise en charge.

Mais le terme NPU englobe bien plus que le matériel pour ordinateurs portables. Certaines plateformes NPU de classe serveur prennent également en charge l'entraînement.

Nos guides sur ce qu'est un NPU et NPU vs GPU expliquent pourquoi il est nécessaire de préciser la classe de l'accélérateur avant d'affirmer ce que les NPU peuvent ou ne peuvent pas faire.

L'IA en périphérie est avant tout une question d'inférence

La plupart des systèmes déployés en périphérie n'ont pas besoin d'apprendre un grand modèle à partir de zéro.

Ils ont besoin de l'utiliser.

Une caméra détecte des objets.

Une machine détecte des anomalies.

Un ordinateur portable effectue une transcription.

Un robot assure une perception locale.

L'entraînement peut se dérouler ailleurs sur du matériel plus vaste et plus flexible.

Le modèle optimisé est ensuite déployé sur l'appareil.

Cette division permet au matériel de périphérie de rester compact, efficace et prévisible.

Notre guide du matériel d'IA en périphérie aborde ce modèle d'entraînement dans le cloud et d'inférence en périphérie, ainsi que plusieurs alternatives hybrides.

Entraînement vs inférence des LLM

Les grands modèles de langage accentuent particulièrement cette distinction matérielle.

Entraînement de LLM

L'entraînement à partir de zéro peut nécessiter :

• une très grande mémoire d'accélérateur ;
• une bande passante mémoire élevée ;
• de grands lots de données ;
• un parallélisme de données distribué ;
• un parallélisme tensoriel ou de pipeline ;
• des interconnexions d'accélérateurs rapides ;
• un stockage des points de contrôle ;
• une fiabilité pour les tâches de longue durée.

La question de la performance tend à être :

À quelle vitesse pouvons-nous atteindre la qualité de modèle requise ?

Inférence de LLM

Le déploiement du modèle déplace la question vers :

Combien de jetons utiles pouvons-nous fournir en respectant les contraintes de latence et de coût ?

Désormais, l'infrastructure se concentre sur :

• TTFT ;
• TPOT ;
• jetons par seconde ;
• le traitement par lots ;
• la mémoire cache KV ;
• la concurrence ;
• le chargement du modèle ;
• la quantification ;
• la mise en file d'attente ;
• le coût par jeton.

Le GPU peut être identique.

L'objectif d'optimisation, lui, ne l'est pas.

Le préremplissage et le décodage rendent l'inférence elle-même hétérogène

Même l'inférence LLM peut se diviser en deux comportements matériels distincts.

Pendant le préremplissage, le modèle traite tous les jetons d'entrée et construit le cache KV initial.

Cette phase offre une capacité de calcul parallèle substantielle.

Pendant le décodage, le système génère un jeton à la fois et lit de manière répétée les poids ainsi que l'état d'attention mis en cache.

Le décodage peut devenir extrêmement sensible aux transferts de mémoire.

Les systèmes de service modernes peuvent optimiser ces phases différemment, et les déploiements à grande échelle peuvent même les exécuter sur des groupes de matériel distincts.

Ainsi, le « matériel d'inférence » devient une collection de sous-problèmes à part entière.

C'est une autre raison pour laquelle les TOPS ou FLOPS de crête ne peuvent pas trancher le choix. Notre guide sur les TOPS, les FLOPS et les mesures de performance IA utiles explique ce qu'il faut mesurer à la place.

Mesures de performance d'entraînement

Les meilleures mesures d'entraînement décrivent la progression vers un modèle utilisable.

Mesurer :

‍

‍

MLPerf Training suit ce principe en comparant le temps nécessaire aux systèmes pour entraîner des charges de travail définies jusqu'à des objectifs de qualité spécifiés, plutôt que de classer les systèmes uniquement sur la base des FLOPS de crête. (MLPerf Training)

Mesures de performance d'inférence

L'inférence en production nécessite une grille d'évaluation différente.

Mesurer :

‍

‍

MLPerf Inference évalue de la même manière des charges de travail définies dans des scénarios de déploiement et selon des objectifs de qualité, plutôt que de considérer les performances d'entraînement comme un indicateur pour la mise en service. (MLPerf Inference)

Le meilleur GPU pour l'entraînement n'est pas forcément le meilleur pour l'inférence

Imaginons deux GPU.

Le GPU A dispose de plus de mémoire et d'une meilleure communication multi-GPU.

Le GPU B possède moins de mémoire, mais offre un meilleur rapport prix-performance pour la précision et la taille de modèle utilisées en production.

Le GPU A pourrait être le système le plus adapté à l'entraînement.

Le GPU B pourrait être le système le plus adapté à l'inférence.

Tout dépend de la charge de travail.

Pour l'entraînement, une VRAM supplémentaire permet :

• des lots plus importants ;
• des séquences plus longues ;
• un réglage fin complet ;
• des modèles plus volumineux ;
• moins de compromis liés à la mémoire.

Pour l'inférence, payer pour de la mémoire inutilisée peut s'avérer inutile.

À l'inverse, une charge de travail d'inférence avec des contextes immenses ou des centaines de requêtes simultanées peut nécessiter plus de mémoire qu'une expérimentation d'entraînement modeste.

Il n'existe pas de classement permanent.

La taille du modèle n'est que le point de départ du dimensionnement matériel

Une estimation approximative du poids du modèle est utile.

Mais un dimensionnement complet doit inclure :

Entraînement

poids + activations + gradients + état de l'optimiseur + tampons temporaires + surcharge du framework

Inférence

poids + cache KV + activations + tampons d'exécution + surcharge liée au traitement par lots/concurrence

Prévoyez ensuite une marge de manœuvre.

Faire fonctionner un GPU à la limite absolue de sa mémoire disponible rend le déploiement fragile et limite les futures tailles de lots, longueurs de contexte ou modifications de modèle.

La quantification est plus déterminante pour le choix du matériel d'inférence

La quantification peut réduire les besoins en entraînement via des méthodes comme QLoRA.

Son impact le plus important sur l'infrastructure est généralement visible lors de l'inférence.

Réduire la précision des poids signifie :

• moins de mémoire ;
• moins de transfert de données ;
• potentiellement plus de capacité de modèle par accélérateur ;
• potentiellement un débit plus élevé.

Cela peut faire passer la réponse de :

inférence multi-GPU

vers :

inférence sur GPU unique

dont les modifications coûtent bien plus cher qu'une légère amélioration des performances.

C'est pourquoi l'optimisation des modèles doit intervenir avant l'achat définitif de l'infrastructure.

Le travail du CPU ne disparaît à aucune de ces étapes

L'entraînement comme l'inférence incluent des tâches qui n'ont pas forcément leur place sur un GPU.

Les pipelines d'entraînement peuvent utiliser les CPU pour :

• le chargement des données ;
• la décompression ;
• l'augmentation ;
• le prétraitement ;
• l'orchestration.

Les services d'inférence utilisent les CPU pour :

• la mise en réseau ;
• l'analyse des requêtes ;
• l'authentification ;
• la tokenisation ;
• la récupération ;
• la logique applicative ;
• le post-traitement.

Payer des tarifs GPU pour des étapes de pipeline limitées par le CPU peut entraîner un gaspillage de capacité.

Notre guide sur les machines virtuelles vCPU et quand vous n'avez pas besoin de GPU recommande de diviser les pipelines afin que l'accélérateur coûteux ne soit utilisé que là où l'accélération modifie le résultat.

Une matrice de décision matérielle pratique

‍

‍

Il s'agit de points de départ.

Évaluez la charge de travail avant de faire votre choix final.

Comment choisir le matériel pour l'entraînement

Posez-vous ces questions dans l'ordre.

1. Effectuez-vous un pré-entraînement, un réglage fin complet ou utilisez-vous des adaptateurs ?

Ces tâches ont des besoins en mémoire radicalement différents.

2. Quelle quantité d'état du modèle doit tenir en mémoire ?

Calculez les poids, les gradients, l'état de l'optimiseur et les activations attendues.

3. De quelle taille de lot et de quelle longueur de séquence avez-vous besoin ?

Les deux influencent la mémoire et le débit.

4. La tâche tient-elle sur un seul accélérateur ?

Si oui, la complexité liée à la distribution est peut-être inutile.

5. Si ce n'est pas le cas, comment le modèle va-t-il passer à l'échelle ?

Parallélisme de données ?

Parallélisme de tenseurs ?

Parallélisme de pipeline ?

Une combinaison des deux ?

6. L'interconnexion est-elle assez rapide ?

L'ajout de GPU n'est utile que si la charge de travail utile augmente plus vite que le coût de communication.

7. Quelle est la valeur du temps d'entraînement ?

Si réduire un entraînement de deux semaines à trois jours apporte une réelle valeur ajoutée au projet, payer pour un débit supérieur peut se justifier.

Si le modèle n'est entraîné qu'une fois par trimestre, une exécution plus lente mais moins coûteuse peut être préférable.

Comment choisir le matériel pour l'inférence

Les questions changent.

1. Quel modèle et quelle précision allez-vous déployer ?

Évaluez la représentation utilisée en production, et non le point de contrôle de l'entraînement.

2. Quelle latence est nécessaire pour les utilisateurs ?

L'inférence interactive et l'inférence par lots ont des modèles économiques différents.

3. Quel niveau de concurrence prévoyez-vous ?

Cela détermine les besoins en matière de file d'attente, de traitement par lots et de cache KV.

4. Quelle quantité de mémoire le trafic réel exige-t-il ?

Prenez en compte le contexte et les requêtes simultanées.

5. Quelle est la stabilité du modèle ?

Les changements fréquents de modèles favorisent une infrastructure flexible.

6. Le matériel spécialisé peut-il l'exécuter ?

Vérifiez le modèle exact, les opérateurs, la précision et la pile de service.

7. Quel est le coût d'une requête utile ?

Comparez l'économie globale du système plutôt que le prix du périphérique.

Où se situe Compute avec Hivenet

L'entraînement et l'inférence autogérée bénéficient tous deux d'une infrastructure où vous contrôlez l'environnement logiciel.

Compute avec Hivenet est cette voie.

Pour l'entraînement et le réglage fin, vous contrôlez l'environnement d'exploitation, les frameworks, les jeux de données, le code du modèle, la précision et l'expérimentation.

Pour l'inférence, vous pouvez contrôler le serveur de modèle, la stratégie de traitement par lots, la quantification, l'exécution et l'application environnante.

Cela rend Compute particulièrement utile lorsque la charge de travail est encore en évolution ou lorsque vous devez comparer plusieurs approches avant de définir la configuration de production.

La bibliothèque de benchmarks de Hivenet mesure des charges de travail réelles, incluant la virtualisation GPU, le comportement d'inférence et la communication multi-GPU, plutôt que de traiter les spécifications théoriques des puces comme des résultats de production.

Pour un exemple actuel, les tests d'inférence de la RTX 5090 de Hivenet utilisent un modèle défini, un moteur de service, une configuration de prompt et une charge de requête plutôt que d'estimer le débit de jetons à partir des spécifications arithmétiques de pointe.

Où se situe l'API d'inférence Hivenet

Une fois que la tâche devient :

déployez ce modèle de manière fiable via une API

vous n'avez peut-être plus besoin d'un contrôle direct sur la machine.

L' API d'inférence Hivenet fournit des points de terminaison gérés compatibles avec OpenAI pour cette approche.

Cela permet une séparation utile du cycle de vie du modèle :

Expérimentez, entraînez, affinez et gérez vous-même sur Compute.

Utilisez un point de terminaison d'inférence géré lorsque vous n'avez plus besoin de gérer vous-même la couche de service.

Les charges de travail se chevauchent, mais la responsabilité opérationnelle change.

Cette différence est tout aussi importante que le processeur lui-même.

L'entraînement et l'inférence peuvent utiliser le même matériel pour de bonnes raisons

La spécialisation est intéressante à grande échelle.

Elle peut aussi arriver trop tôt.

Maintenir l'entraînement et l'inférence sur la même plateforme GPU peut faciliter le développement car :

• la prise en charge des frameworks reste familière ;
• les points de contrôle sont faciles à transférer ;
• les outils de débogage restent les mêmes ;
• les expérimentations de modèles ne nécessitent pas de nouveau port matériel ;
• la même infrastructure peut gérer l'évaluation et les tests de production.

Une fois que la charge de travail en production devient importante et prévisible, il devient intéressant d'évaluer une plateforme d'inférence spécialisée.

Le cycle de vie peut donc se présenter comme suit :

Recherche GPU → Entraînement GPU → Inférence GPU → Inférence spécialisée si la rentabilité le justifie

plutôt que de choisir l'architecture d'inférence finale avant que le modèle ne soit stabilisé.

FAQ sur l'entraînement et l'inférence en IA

Quelle est la différence entre l'entraînement et l'inférence en IA ?

L'entraînement ajuste les paramètres d'un modèle à l'aide de données et d'un processus d'optimisation. L'inférence utilise les paramètres entraînés qui en résultent pour produire des prédictions ou des contenus générés à partir de nouvelles entrées.

L'entraînement nécessite-t-il plus de puissance de calcul que l'inférence ?

Pour une exécution unique du même modèle, l'entraînement nécessite généralement plus de calcul car il inclut la rétropropagation et la mise à jour des paramètres. Les services d'inférence à grande échelle peuvent toutefois consommer une puissance de calcul totale énorme, car le modèle entraîné peut être exécuté des millions ou des milliards de fois.

L'entraînement nécessite-t-il plus de mémoire GPU que l'inférence ?

Généralement, pour un même modèle et une même précision. L'entraînement nécessite des gradients, des activations, des états d'optimiseur et d'autres données de travail en plus des poids du modèle. L'inférence élimine une grande partie de cet état, mais peut consommer une mémoire importante via le cache KV, les contextes longs et la concurrence.

Le même GPU peut-il être utilisé pour l'entraînement et l'inférence ?

Oui. Les GPU sont largement utilisés pour les deux. La configuration optimale peut différer, car l'entraînement privilégie le débit, la mémoire et la mise à l'échelle, tandis que l'inférence peut privilégier la latence, la concurrence et le coût.

Pourquoi l'entraînement est-il généralement plus complexe que l'inférence ?

L'entraînement doit calculer comment le modèle doit évoluer et mettre à jour ses paramètres de manière répétée. Cela nécessite des calculs et une mémoire supplémentaires par rapport à la simple évaluation du modèle entraîné.

Le réglage fin (fine-tuning) est-il de l'entraînement ou de l'inférence ?

Le réglage fin est de l'entraînement, car les paramètres du modèle ou les adaptateurs sont mis à jour.

Le LoRA est-il de l'entraînement ?

Oui. Le LoRA est un réglage fin efficace en termes de paramètres. Il entraîne un ensemble relativement restreint de paramètres de bas rang supplémentaires plutôt que de mettre à jour chaque paramètre du modèle de base.

La quantification est-elle principalement destinée à l'inférence ?

La quantification est particulièrement courante dans l'inférence, car les modèles entraînés peuvent souvent utiliser une précision moindre tout en conservant une qualité de sortie acceptable. La quantification peut également être utilisée dans les flux de travail d'entraînement et de réglage fin, notamment avec le QLoRA.

Les serveurs d'inférence ont-ils besoin de plusieurs GPU ?

Parfois. Les grands modèles peuvent nécessiter un partitionnement sur plusieurs GPU, tandis qu'un trafic élevé peut exiger plusieurs accélérateurs pour assurer la capacité. Les modèles plus petits et le trafic plus léger peuvent souvent fonctionner sur un seul GPU.

Pourquoi l'entraînement nécessite-t-il des interconnexions GPU rapides ?

L'entraînement distribué nécessite que les GPU échangent des informations telles que des gradients ou des fragments de modèle. Une communication lente laisse les accélérateurs en attente et réduit l'efficacité de la mise à l'échelle.

L'inférence nécessite-t-elle des interconnexions GPU rapides ?

C'est possible. Les très grands modèles peuvent être répartis sur plusieurs accélérateurs, et l'inférence par parallélisme tensoriel ou désagrégée peut nécessiter une communication importante. Ce n'est pas le cas pour les modèles plus petits sur un seul GPU.

Quel matériel est le meilleur pour l'entraînement en IA ?

Les GPU constituent le point de départ le plus flexible pour la plupart des entraînements en deep learning. Les TPU, Trainium et autres accélérateurs d'entraînement peuvent être de solides alternatives pour les charges de travail prises en charge à grande échelle. Le choix doit dépendre du modèle, du framework, des besoins en mémoire et de l'architecture distribuée.

Quel matériel est le meilleur pour l'inférence en IA ?

Les CPU peuvent gérer de petites charges de travail. Les GPU prennent en charge une large gamme de modèles exigeants. Les NPU conviennent aux charges de travail locales et en périphérie prises en charge. Les accélérateurs d'inférence spécialisés peuvent devenir intéressants pour des charges de travail stables et à haut volume. Évaluez le modèle exact et le modèle de trafic.

Qu'est-ce qui est le plus coûteux, l'entraînement ou l'inférence en IA ?

Cela dépend de l'échelle. L'entraînement d'un grand modèle peut être extrêmement coûteux en tant que projet unique. L'inférence peut dépasser le coût d'entraînement au fil du temps lorsqu'un modèle traite un grand nombre de requêtes en continu.

L'entraînement et l'inférence doivent-ils utiliser une infrastructure distincte ?

Parfois. La séparation est judicieuse lorsque leurs exigences diffèrent suffisamment pour améliorer les coûts ou les performances. Maintenir les deux sur la même plateforme GPU peut simplifier le développement lorsque les charges de travail sont plus petites ou encore en évolution.

Entraînez pour apprendre, provisionnez l'inférence pour l'utilisation

L'entraînement et l'inférence semblent similaires car ils exécutent le même réseau neuronal.

Leurs tâches sont différentes.

L'entraînement demande au matériel d'apprendre.

Cela implique des calculs vers l'avant, des calculs vers l'arrière, des gradients, l'état de l'optimiseur, de grands lots, de la communication et des tâches de longue durée.

L'inférence demande au matériel de produire des réponses utiles de manière répétée.

Cela fait de la latence, du débit, de l'efficacité mémoire, de la concurrence, de l'utilisation, de la fiabilité et du coût des exigences de premier ordre.

Cette distinction a des conséquences pratiques.

Un système multi-GPU à haute mémoire peut valoir l'investissement lors de l'entraînement, mais s'avérer inutile pour le modèle d'inférence final.

Une quantification agressive peut sembler peu pertinente lors de l'entraînement complet, mais transformer radicalement la rentabilité du déploiement.

Un accélérateur d'inférence spécialisé peut être inutilement restrictif lors de la phase d'expérimentation, mais devenir extrêmement attractif une fois que le modèle est exécuté un milliard de fois par mois.

Commencez par identifier l'étape du cycle de vie du modèle.

Dimensionnez ensuite le matériel en fonction de cette tâche.

Poursuivez votre lecture sur le cluster avec NPU vs GPU pour les charges de travail IA, ce qu'est un NPU, le guide pratique des accélérateurs d'IA, CPU vs GPU vs NPU, accélérateurs d'IA vs GPU pour l'inférence, matériel pour l'IA en périphérie, et TOPS vs FLOPS.

‍