Quelle configuration choisir, de l'entraînement à l'inférence des LLM
De l'entraînement à l'inférence en passant par le RAG, les configurations matérielles à mettre en place sont très différentes selon les cas d'utilisation d'un large language model (LLM). A chaque profil d'usage une infrastructure de calcul particulière sera nécessaire.
Concernant la phase d'entraînement, un petit retour en arrière s'impose. Un modèle de langue est constitué de plusieurs couches. En amont, il fait appel à une couche d'embedding non-supervisée pour vectoriser les mots. Ensuite seulement vient l'apprentissage auto-supervisé pour le traitement du langage avec les fameux transformer. A ces deux premières couches s'ajoute encore un mode d'entrainement supervisé qui permet d'apprendre à répondre aux questions sur la base de grands ensembles de données labélisées. L'objectif ? Permettre non seulement d'aligner des mots qui ont un sens (ce qui est la mission des transformers), mais aussi de gérer des scénarios de plus haut niveau : répondre à une question, converser en mode chatbot, résumé un texte… En aval, l'apprentissage par renforcement entre dans la danse. Il consiste à soumettre les réponses fournies à des experts humains qui leur attribuent une note. Sur la base de cette notation, le modèle affine la pertinence de ses résultats.
"La couche la plus gourmande en capacité de traitement, et de loin, est celle du transformer", note Didier Gaultier, head of AI chez Orange Business Digital Services France. L'entraînement complet d'un modèle comptant entre 40 et 100 milliards de paramètres impliquera de préempter une architecture d'au moins une centaine de GPU de type H100 durant un mois. Sachant que le prix d'une telle carte graphique se situe entre 25 000 et 30 000 dollars. "La capacité de calcul nécessaire est proportionnelle de manière exponentielle à la complexité du modèle", précise Didier Gaultier.
L'avantage d'augmenter le nombre de GPU ? Un surcroit de capacité permettra de réduire le temps de traitement et donc la durée de mobilisation de l'équipe de gestion du projet. "Ce qui est évidemment un facteur à avoir en tête", insiste Didier Gaultier. "L'équipe doit rester en alerte si l'entraînement ne se passe pas bien, ce qui est toujours possible en cas de mauvais paramétrage des data sets ou de la structure du réseau. Dans tous les cas, elle devra rester mobilisée pour la suite du projet."
Une facture d'un million d'euros
Au final, la facture d'un réentrainement complet peut friser le million d'euros. "C'est le cas par exemple pour réentraîner un Llama 70B de A à Z. "Il faut compter le temps de calcul, la facture énergétique, et les ressources humaines mobilisées, sans oublier l'amortissement du matériel dans le cas d'un apprentissage réalisé on-premise avec à la clé le recours à des serveurs haut de gamme de type HPE Cray. L'addition peut très vite se chiffrer facilement en centaine de milliers d'euros, voire au-delà. Ce sera par exemple l'enveloppe à mettre sur la table pour apprendre à un LLM un tout nouveau langage de programmation", pointe Didier Gaultier. "Le réentraînement complet de l'embedding à l'instruct est nécessaire quand votre base d'apprentissage contient une ontologie avec des termes qui sont entièrement inconnus du LLM."
En partant sur une infrastructure à 100% cloud, l'apprentissage d'un tout nouveau langage par la couche transformer du LLM impliquera de mobiliser environ une centaine d'instances H100 en mode Infiniband pendant environ 9 semaines. "Même à quelques euros de l'heure le GPU, on voit que le coût peut vite devenir très élevé. Et ce, sachant que beaucoup de clouds publics proposent bien des H100 tarifés à l'heure, mais pas l'Infiniband qui reste plus difficile à configurer à la volée et à conserver de manière stable", commente Didier Gaultier, avant de pondérer : "C'est rare qu'on ait à réaliser un réentraînement complet. Par exemple les langues française ou anglaise représentent souvent une bonne base de départ qui permet de ne pas repartir totalement de rien, ce qui permet dans ce cas de diviser le nombre d'heures de GPU à mobiliser."
"Le point crucial de LoRA réside dans sa capacité à modifier des modèles pré-entraînés sans les recycler entièrement"
Il sera par exemple possible de ne réentraîner qu'une partie du modèle en passant par la technique du transfert learning. Dans le cas de quelques centaines de nouveaux mots de vocabulaire, il sera ainsi envisageable de capitaliser sur l'embedding existant pour l'étendre à ce nouveau vocabulaire.
Dans la même logique, on pourra faire appel aux méthodes comme LoRA (low-rank adaptation) ou QLora (quantized LoRA). "Le point crucial de LoRA réside dans sa capacité à modifier des modèles pré-entraînés sans les recycler entièrement, réduisant ainsi les paramètres pouvant être entraînés et rendant le processus d'adaptation plus rentable. Quant à QLoRA, c'est un mélange de LoRA et de quantification qui contribue à réduire l'empreinte mémoire du modèle tout en conservant la précision essentielle pour l'entraînement", détaille Ayush Mittal, consultant chez Unite.ai. Principal avantage : réduire la puissance de calcul nécessaire tout en évitant de toucher aux poids initiaux du réseau de neurones. "Vous ne prenez donc pas de risque", ajoute Didier Gaultier. "En cas d'erreur, vous n'aurez pas à tout réentraîner car vous n'aurez pas touché au modèle de base."
Tout dépend du nombre d'utilisateurs
Qu'en est-il de l'inférence ? Elle impliquera a minima deux puissantes cartes graphiques (GPU), type H100 avec chacune 80 Go de Ram, reliées là-encore en très haut débit via une configuration réseau de type Infiniband. A cela viendront s'ajouter une ou plusieurs cartes graphiques de moindres capacité pour gérer le RAG, des A100 par exemple. "Le RAG, qui s'adosse à un modèle de vectorisation non-supervisé, implique beaucoup moins de mémoire graphique que l'entraînement des transformers", justifie Didier Gaultier.
Globalement, tout dépendra ensuite du nombre d'utilisateurs de l'application. "Avec deux cartes H100, vous pouvez servir une bonne centaine d'utilisateurs de manière confortable en partant d'un modèle de taille moyenne de 40 à 100 milliards de paramètres", estime Didier Gaultier. "Pour 400 utilisateurs simultanés, je conseille de partir sur quatre cartes H100." Un grand modèle, comptant 200 milliards de paramètres, consommera avant tout plus de mémoire vive, et impliquera donc de mettre en place un véritable cluster de GPU.