Améliorer l'inférence de l'IA : techniques avancées et meilleures pratiques

Lorsqu'il s'agit d'applications basées sur l'IA en temps réel, comme les voitures autonomes ou surveillance des soins de santé, même une seconde supplémentaire pour traiter une entrée peut avoir de graves conséquences. Les applications d'IA en temps réel nécessitent des GPU et une puissance de traitement fiables, ce qui était jusqu'à présent très coûteux et prohibitif pour de nombreuses applications.

En adoptant un processus d’inférence optimisant, les entreprises peuvent non seulement maximiser l’efficacité de l’IA ; elles peuvent également réduire la consommation d’énergie et les coûts opérationnels (jusqu’à 90 %) ; améliorer la confidentialité et la sécurité ; et même améliorer la satisfaction des clients.

Problèmes d'inférence courants

Certains des problèmes les plus courants auxquels sont confrontées les entreprises lorsqu’il s’agit de gérer l’efficacité de l’IA incluent les clusters de GPU sous-utilisés, le recours par défaut à des modèles à usage général et le manque de visibilité sur les coûts associés.

Les équipes provisionnent souvent des clusters de GPU pour les pics de charge, mais entre 70 et 80 % du temps, ils sont sous-utilisés en raison de flux de travail inégaux.

De plus, les équipes utilisent par défaut de grands modèles polyvalents (GPT-4, Claude), même pour des tâches qui pourraient être exécutées sur des modèles open source plus petits et moins coûteux. Les raisons ? Un manque de connaissances et une courbe d'apprentissage abrupte pour la création de modèles personnalisés.

Enfin, les ingénieurs manquent généralement d'informations sur le coût en temps réel de chaque demande, ce qui entraîne des factures salées. Des outils comme PromptLayer et Helicone peuvent les aider à obtenir ces informations.

En raison d’un manque de contrôle sur le choix, le traitement par lots et l’utilisation des modèles, les coûts d’inférence peuvent augmenter de manière exponentielle (jusqu’à 10 fois), gaspiller des ressources, limiter la précision et diminuer l’expérience utilisateur. 

Consommation d'énergie et coûts d'exploitation

L'exécution de LLM plus grands comme GPT-4, Llama 3 70B ou Mixtral-8x7B nécessite beaucoup plus de puissance Par jeton. En moyenne, 40 à 50 % de l'énergie utilisée par un centre de données alimente les équipements informatiques, avec 30 à 40 % supplémentaires consacrés au refroidissement des équipements.

Par conséquent, pour une entreprise fonctionnant 24 heures sur 24 pour l'inférence à grande échelle, il est plus avantageux d'envisager un fournisseur sur site plutôt qu'un fournisseur de cloud pour éviter de payer un coût supplémentaire et consommer plus d'énergie.

Confidentialité et sécurité

Selon le Cisco's Étude comparative sur la confidentialité des données 2025, "64 % des personnes interrogées craignent de partager par inadvertance des informations sensibles en public ou avec des concurrents, mais près de la moitié admettent avoir saisi des données personnelles d'employés ou non publiques dans les outils GenAI. Cela augmente le risque de non-conformité si les données sont mal enregistrées ou mises en cache. 

Une autre possibilité de risque est l'exécution de modèles dans différentes organisations clientes sur une infrastructure partagée ; cela peut entraîner des violations de données et des problèmes de performances, et il existe un risque supplémentaire que les actions d'un utilisateur aient un impact sur d'autres utilisateurs. Par conséquent, les entreprises préfèrent généralement les services déployés dans leur cloud.

Satisfaction client

Lorsque les réponses mettent plus de quelques secondes à apparaître, les utilisateurs abandonnent généralement, ce qui conforte les ingénieurs dans leur volonté de suroptimiser l'expérience pour une latence nulle. De plus, les applications présentent des « obstacles tels que les hallucinations et l'inexactitude qui peuvent limiter l'impact et l'adoption à grande échelle », selon un Communiqué de presse de Gartner.

Avantages commerciaux de la gestion de ces problèmes

L'optimisation du traitement par lots, le choix de modèles adaptés (par exemple, le passage de Llama 70B ou de modèles à code source fermé comme GPT à Gemma 2B lorsque cela est possible) et l'amélioration de l'utilisation du GPU peuvent réduire les coûts d'inférence de 60 à 80 %. L'utilisation d'outils comme vLLM peut être utile, tout comme le passage à un modèle de paiement à l'utilisation sans serveur pour un flux de travail saturé. 

Prenons l'exemple de Cleanlab. a lancé le Modèle de langage fiable (TLM) à ajouter Un score de fiabilité est attribué à chaque réponse LLM. Ce système est conçu pour des résultats de haute qualité et une fiabilité accrue, ce qui est essentiel pour les applications d'entreprise afin d'éviter les erreurs incontrôlées. Avant Inferless, Cleanlabs connaissait une augmentation des coûts liés aux GPU, car ceux-ci fonctionnaient même lorsqu'ils n'étaient pas utilisés activement. Leurs problèmes étaient typiques des fournisseurs de GPU cloud traditionnels : latence élevée, gestion des coûts inefficace et environnement complexe à gérer. Grâce à l'inférence sans serveur, ils ont réduit leurs coûts de 90 % tout en maintenant les niveaux de performance. Plus important encore, ils ont été opérationnels en deux semaines, sans frais d'ingénierie supplémentaires.

Optimisation des architectures de modèles

Les modèles fondamentaux comme GPT et Claude sont souvent entraînés pour la généralité, et non pour l'efficacité ou des tâches spécifiques. En ne personnalisant pas les modèles open source pour des cas d'utilisation spécifiques, les entreprises gaspillent de la mémoire et du temps de calcul pour des tâches qui ne nécessitent pas cette évolutivité.

Les puces GPU récentes, comme le H100, sont rapides et efficaces. Ces caractéristiques sont particulièrement importantes pour l'exécution d'opérations à grande échelle, comme la génération vidéo ou les tâches liées à l'IA. Un plus grand nombre de cœurs CUDA augmente la vitesse de traitement, surpassant ainsi les GPU plus petits ; NVIDIA Noyaux tenseurs sont conçus pour accélérer ces tâches à grande échelle.

La mémoire GPU est également importante pour optimiser les architectures de modèles, car les modèles d'IA volumineux nécessitent un espace important. Cette mémoire supplémentaire permet au GPU d'exécuter des modèles plus volumineux sans compromettre la vitesse. À l'inverse, les performances des GPU plus petits, dotés de moins de VRAM, sont affectées, car ils déplacent les données vers une RAM système plus lente.

L'optimisation de l'architecture des modèles présente plusieurs avantages, notamment des gains de temps et d'argent. Tout d'abord, le passage d'un transformateur dense à des variantes optimisées pour LoRA ou FlashAttention peut réduire le temps de réponse par requête de 200 à 400 millisecondes, un atout crucial pour les chatbots et les jeux, par exemple. De plus, les modèles quantifiés (4 ou 8 bits, par exemple) nécessitent moins de VRAM et s'exécutent plus rapidement sur des GPU moins coûteux. 

À long terme, l’optimisation de l’architecture du modèle permet d’économiser de l’argent sur l’inférence, car les modèles optimisés peuvent fonctionner sur des puces plus petites.

L’optimisation de l’architecture du modèle implique les étapes suivantes :

• Quantification — réduction de la précision (FP32 → INT4/INT8), économie de mémoire et accélération du temps de calcul
• Élagage — supprimer les poids ou les couches moins utiles (structurés ou non structurés)
• Distillation — former un modèle « étudiant » plus petit pour imiter la sortie d’un modèle plus grand 

Compression de la taille du modèle

Modèles plus petits Cela signifie une inférence plus rapide et une infrastructure moins coûteuse. Les modèles volumineux (13 B+, 70 B+) nécessitent des GPU coûteux (A100, H100), une VRAM élevée et davantage de puissance. Leur compression leur permet de fonctionner sur du matériel moins cher, comme les A10 ou les T4, avec une latence bien plus faible. 

Les modèles compressés sont également essentiels pour l'exécution d'inférences sur appareils (téléphones, navigateurs, IoT), car des modèles plus petits permettent de traiter davantage de requêtes simultanées sans nécessiter de mise à l'échelle de l'infrastructure. Dans un chatbot comptant plus de 1,000 13 utilisateurs simultanés, le passage d'un modèle compressé de 7 B à XNUMX B a permis à une équipe de traiter plus du double d'utilisateurs par GPU sans pics de latence.

Tirer parti du matériel spécialisé

Les processeurs à usage général ne sont pas conçus pour les opérations tensorielles. Des matériels spécialisés comme les NVIDIA A100, H100, les Google TPU ou AWS Inferentia peuvent offrir une inférence plus rapide (entre 10 et 100 fois) pour les LLM, avec une meilleure efficacité énergétique. Gagner ne serait-ce que 100 millisecondes par requête peut faire la différence lors du traitement de millions de requêtes quotidiennes.

Considérez cet exemple hypothétique :

Une équipe utilise LLaMA-13B sur des GPU A10 standard pour son système RAG interne. La latence est d'environ 1.9 seconde, et les lots sont limités en raison des limites de la VRAM. Elle passe donc à des H100 avec TensorRT-LLM, active FP8 et un noyau d'attention optimisé, et augmente la taille des lots de 64 à 400. Résultat : la latence est réduite à XNUMX millisecondes et le débit est multiplié par cinq.
Ils sont ainsi en mesure de répondre aux demandes cinq fois avec le même budget et de libérer les ingénieurs des goulots d’étranglement de l’infrastructure.

Évaluation des options de déploiement

Des processus différents requièrent des infrastructures différentes ; un chatbot avec 10 utilisateurs et un moteur de recherche traitant un million de requêtes par jour ont des besoins différents. Opter pour le cloud (par exemple, AWS Sagemaker) ou des serveurs GPU DIY sans évaluer le rapport coût-performances entraîne des dépenses inutiles et une expérience utilisateur médiocre. Notez que si vous vous engagez tôt auprès d'un fournisseur de cloud fermé, la migration ultérieure de la solution est complexe. Cependant, une évaluation précoce avec une structure de paiement à l'utilisation vous offre des options à long terme.

L’évaluation comprend les étapes suivantes :

• Latence et coût du modèle de référence sur toutes les plateformes : exécutez des tests A/B sur AWS, Azure, des clusters GPU locaux ou des outils sans serveur pour les répliquer.
• Mesurer les performances de démarrage à froid : ceci est particulièrement important pour les charges de travail sans serveur ou pilotées par événements, car les modèles se chargent plus rapidement. 
• Évaluez l’observabilité et les limites de mise à l’échelle : évaluez les métriques disponibles et identifiez le nombre maximal de requêtes par seconde avant toute dégradation.
• Vérifiez la prise en charge de la conformité : déterminez si vous pouvez appliquer des règles de données géolocalisées ou des journaux d’audit.
• Estimez le coût total de possession. Ce coût doit inclure les heures de GPU, le stockage, la bande passante et les frais généraux pour les équipes.

La ligne de fond

L'inférence permet aux entreprises d'optimiser les performances de leur IA, de réduire leur consommation d'énergie et leurs coûts, de préserver la confidentialité et la sécurité et de satisfaire leurs clients.