Auto-hébergement LLM : maîtrisez votre IA et réduisez les coûts

Comprendre l'auto-hébergement des LLM

L'évolution des modèles de langage de grande taille

L'idée d'héberger soi-même un modèle de langage de grande taille (LLM) n'est plus réservée aux chercheurs ou aux infrastructures massives de machine learning. Aujourd'hui, avec le modèle adéquat, un GPU performant et quelques outils éprouvés, il est possible de faire tourner un LLM de qualité production sur une machine unique sous votre contrôle.

Plusieurs raisons peuvent vous pousser à envisager cette solution :

• Votre facture liée à OpenAI ou Anthropic est devenue insoutenable.
• Vous avez des données sensibles qui ne doivent pas quitter votre environnement sécurisé.
• Vos workflows d'agents consomment d'énormes quantités de tokens quotidiennement.
• Vous désirez un comportement IA personnalisé que les simples prompts ne peuvent offrir.

Si vous vous reconnaissez dans ces situations, cet article est fait pour vous. Sinon, vous êtes tout de même au bon endroit pour découvrir les possibilités offertes par l'auto-hébergement des LLM.

Dans ce guide, je vais vous accompagner pas à pas pour déployer un LLM sur votre propre infrastructure. Nous aborderons la sélection des modèles, le choix des instances, et les raisons derrière ces décisions. Je vous fournirai également un modèle de déploiement à coût zéro pour votre propre LLM, compatible avec OpenAI ou Anthropic.

À la fin de ce guide, vous saurez :

• Quels benchmarks sont cruciaux pour les LLM qui doivent résoudre des problèmes complexes d'agents.
• L'impact de la quantification sur les performances.
• Les types d'instances et de GPUs adaptés pour un hébergement sur une seule machine.
• Les modèles à privilégier.
• Comment utiliser un LLM auto-hébergé sans réécrire toute une base de code API existante.
• Comment rendre l'auto-hébergement économiquement viable.

Note : Ce guide se concentre sur le déploiement de LLM orientés agents, et non sur des modèles généralistes massifs qui dépassent souvent les besoins réels.

Les avantages de l'auto-hébergement

La principale raison d'envisager l'auto-hébergement est la gestion des données sensibles. Cela inclut les dossiers médicaux, le code source propriétaire, les données utilisateur, les documents financiers ou stratégiques qui ne doivent jamais quitter votre pare-feu.

L'auto-hébergement élimine la dépendance aux API tierces et réduit le risque de violation des données ou de non-conformité avec des politiques de confidentialité strictes.

• Prévisibilité des coûts : Les tarifs des API augmentent linéairement avec l'utilisation. Pour les charges de travail d'agents, souvent élevées en termes de tokens, gérer sa propre infrastructure GPU permet de réaliser des économies d'échelle.

• Méthodes de fine-tuning : Des techniques comme LoRA et QLoRA permettent d'affiner le comportement d'un LLM ou d'ajuster son alignement, en optimisant l'utilisation des outils, en modifiant le style de réponse ou en se concentrant sur des données spécifiques à un domaine.

Pourquoi opter pour une seule machine ?

Bien que ce ne soit pas une obligation, opter pour une seule machine simplifie grandement le processus. Déployer sur une machine unique avec un seul GPU est relativement simple. Une machine avec plusieurs GPUs est également envisageable avec les bonnes configurations. Cependant, le débogage de l'inférence distribuée sur plusieurs machines peut s'avérer complexe.

Pour simplifier le processus, nous nous concentrerons sur une machine unique et un seul GPU. À mesure que vos besoins d'inférence augmentent, vous pourrez évoluer sur une seule machine. Ensuite, vous pourrez envisager des déploiements multi-machines ou de style Kubernetes.

Quels benchmarks privilégier ?

Le paysage des benchmarks pour les LLM est vaste et souvent déroutant. Il existe de nombreux classements, mais la plupart ne sont pas pertinents pour notre cas d'utilisation. Nous devons cibler les benchmarks qui mettent en avant les LLM excelling dans les tâches de style agent.

Nous recherchons des LLM capables de :

• Suivre des instructions complexes et multi-étapes.
• Utiliser des outils de manière fiable : appeler des fonctions avec des arguments bien formés, interpréter les résultats et décider des actions suivantes.
• Raisonner avec des contraintes : traiter des informations potentiellement incomplètes sans générer de réponses incorrectes.
• Écrire et comprendre du code : interagir avec des APIs et générer du code à la volée pour étendre l'espace d'action et améliorer l'utilisation des outils.

Voici les benchmarks à considérer :

• Berkeley Function Calling Leaderboard (BFCL v3) : Évalue la précision des appels de fonction/outils à travers des invocations simples, parallèles, imbriquées et multi-étapes. Il teste directement la capacité dont dépendent le plus vos agents : l'utilisation structurée des outils.

• IFEval (Instruction Following Eval) : Mesure l'adhésion stricte à la mise en forme, aux contraintes et aux instructions structurelles. Les agents ont besoin d'une stricte adhésion aux instructions.

• τ-bench (Tau-bench) : Évalue l'accomplissement de tâches d'agents E2E dans des environnements simulés. Mesure la compétence agentique réelle, ce LLM peut-il réellement accomplir un objectif sur plusieurs tours ?

• SWE-bench Verified : Évalue la capacité à résoudre de véritables problèmes GitHub de dépôts open-source populaires. Si vos agents écrivent ou modifient du code, c'est la référence.

• WebArena / VisualWebArena : Évalue l'accomplissement de tâches dans des environnements web réalistes. Très utile si votre agent doit utiliser une interface web.

Note : Obtenir des scores de benchmark fiables sur tous ces éléments, en particulier pour les modèles quantifiés, est difficile. Vous devrez faire preuve de discernement, en supposant que le modèle à pleine précision respecte le tableau de dégradation des performances ci-dessous.

La quantification expliquée

Les paramètres d'un modèle sont stockés sous forme de nombres. À pleine précision (FP32), chaque poids est un nombre à virgule flottante de 32 bits — 4 octets. La plupart des modèles modernes sont distribués en FP16 ou BF16 (demi-précision, 2 octets par poids). Vous verrez cela comme la référence pour chaque modèle.

La quantification réduit le nombre de bits utilisés pour représenter chaque poids, réduisant ainsi l'exigence en mémoire et augmentant la vitesse d'inférence, au prix d'une certaine précision.

Il existe plusieurs méthodes de quantification, certaines étant plus efficaces que d'autres pour maintenir les performances avec une précision de bits réduite.

Choisir le bon GPU

Bien que plusieurs types de GPU soient disponibles, le paysage sur AWS, GCP et Azure peut être principalement distillé dans les options suivantes, en particulier pour les déploiements sur une seule machine avec un seul GPU :

• H100 : Architecture Hopper, 80 Go de VRAM
• A100 : Architecture Ampere, 40 Go/80 Go de VRAM
• L40S : Architecture Ada Lovelace, 48 Go de VRAM
• L4 : Architecture Ada Lovelace, 24 Go de VRAM
• A10/A10G : Architecture Ampere, 24 Go de VRAM
• T4 : Architecture Turing, 16 Go de VRAM

Les meilleurs compromis en termes de performances et de coûts se trouvent dans la gamme L4, L40S et A100, l'A100 offrant les meilleures performances (en termes de capacité de modèle et de charges de travail multi-utilisateurs). Si vos tâches d'agents sont simples et nécessitent moins de débit, il est sûr de rétrograder vers L4/A10. Ne passez pas à l'H100 à moins d'en avoir réellement besoin.