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

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

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

Problèmes courants d’inférence

Certains des problèmes les plus courants rencontrés par les entreprises lorsqu’il s’agit de gérer les efficacités de l’IA incluent les grappes de GPU sous-utilisées, le recours à des modèles généraux et le manque de visibilité sur les coûts associés.

Les équipes provisionnent souvent des grappes de GPU pour la charge de pointe, mais entre 70 et 80 pour cent du temps, elles sont sous-utilisées en raison de flux de travail inégaux.

En outre, les équipes font appel à de grands modèles généraux (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 chers. Les raisons ? Un manque de connaissances et une courbe d’apprentissage abrupte pour la construction de modèles personnalisés.

Enfin, les ingénieurs manquent généralement de visibilité sur le coût réel de chaque requête, ce qui entraîne des factures importantes. Des outils comme PromptLayer, Helicone peuvent aider à fournir cette visibilité.

Avec un manque de contrôle sur le choix du modèle, le regroupement et l’utilisation, 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 grands LLM comme GPT-4, Llama 3 70B ou Mixtral-8x7B nécessite beaucoup plus de puissance par jeton. En moyenne, 40 à 50 pour cent de l’énergie utilisée par un centre de données alimente l’équipement informatique, avec 30 à 40 pour cent supplémentaires dédiés au refroidissement de l’équipement.

Par conséquent, pour une entreprise qui exécute des inférences à grande échelle en continu, il est plus bénéfique de considérer un fournisseur sur site par opposition à un fournisseur cloud pour éviter de payer un coût premium et consommer plus d’énergie.

Confidentialité et sécurité

Selon l’étude 2025 Data Privacy Benchmark Study de Cisco, « 64 % des répondants s’inquiètent de partager involontairement des informations sensibles publiquement ou avec des concurrents, mais près de la moitié admettent avoir saisi des données personnelles d’employés ou non publiques dans des outils de GenAI. » Cela augmente le risque de non-conformité si les données sont enregistrées ou mises en cache de manière incorrecte. Un autre risque est de faire fonctionner des modèles sur différentes organisations clientes sur une infrastructure partagée ; cela peut entraîner des failles de sécurité et des problèmes de performance, et il existe un risque supplémentaire que les actions d’un utilisateur affectent d’autres utilisateurs. Par conséquent, les entreprises préfèrent généralement les services déployés dans leur propre cloud.

Satisfaction client

Lorsque les réponses mettent plus de quelques secondes à apparaître, les utilisateurs abandonnent généralement, ce qui justifie les efforts des ingénieurs pour sur-optimiser pour une latence nulle. De plus, les applications présentent des « obstacles tels que des hallucinations et des inexactitudes qui peuvent limiter l’impact et l’adoption généralisés, » selon un communiqué de presse de Gartner.

Avantages commerciaux de la gestion de ces problèmes

L’optimisation du regroupement, le choix de modèles de la bonne taille (par exemple, passer de Llama 70B ou de modèles à source fermée comme GPT à Gemma 2B lorsque cela est possible) et l’amélioration de l’utilisation des GPU peuvent réduire les factures d’inférence de 60 à 80 pour cent. L’utilisation d’outils comme vLLM peut aider, tout comme le passage à un modèle serveurless pay-as-you-go pour un flux de travail irrégulier.

Prenez Cleanlab, par exemple. Cleanlab a lancé le Trustworthy Language Model (TLM) pour ajouter un score de fiabilité à chaque réponse LLM. Il est conçu pour des sorties de haute qualité et une fiabilité améliorée, ce qui est essentiel pour les applications d’entreprise pour prévenir les hallucinations non contrôlées. Avant Inferless, Cleanlabs a connu une augmentation des coûts de GPU, car les GPU fonctionnaient même lorsqu’ils n’étaient pas activement utilisés. Leurs problèmes étaient typiques des fournisseurs de cloud GPU traditionnels : latence élevée, gestion des coûts inefficace et environnement complexe à gérer. Avec l’inférence serveurless, ils ont réduit les coûts de 90 pour cent tout en maintenant les niveaux de performance. Plus important encore, ils sont passés en production en deux semaines sans frais supplémentaires de surcoût d’ingénierie.

Optimisation des architectures de modèles

Les modèles de base comme GPT et Claude sont souvent formé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 n’en ont pas besoin.

Les nouveaux circuits de GPU comme H100 sont rapides et efficaces. Ceux-ci sont particulièrement importants lors de l’exécution de grandes opérations comme la génération de vidéos ou les tâches liées à l’IA. Plus de cœurs CUDA augmentent la vitesse de traitement, surpassant les GPU plus petits ; les cœurs de tenseur de NVIDIA 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 grands modèles d’IA nécessitent un espace important. Cette mémoire supplémentaire permet au GPU d’exécuter des modèles plus grands sans compromettre la vitesse. À l’inverse, la performance des petits GPU qui ont moins de VRAM souffre, car ils déplacent les données vers une RAM système plus lente.

Plusieurs avantages de l’optimisation de l’architecture de modèle incluent les économies de temps et d’argent. Tout d’abord, passer d’un transformateur dense à des variantes optimisées LoRA ou FlashAttention peut réduire de 200 à 400 millisecondes le temps de réponse par requête, ce qui est crucial dans les chatbots et les jeux, par exemple. De plus, les modèles quantifiés (comme 4 bits ou 8 bits) nécessitent moins de VRAM et fonctionnent plus rapidement sur des GPU moins chers.

À long terme, l’optimisation de l’architecture de modèle économise 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 de 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 — suppression de poids ou de couches moins utiles (structurés ou non structurés)
• Distillation — formation d’un modèle « étudiant » plus petit pour imiter la sortie d’un modèle plus grand

Compression de la taille du modèle

Les modèles plus petits signifient une inférence plus rapide et une infrastructure moins coûteuse. Les grands modèles (13B+, 70B+) nécessitent des GPU coûteux (A100s, H100s), une grande quantité de VRAM et plus de puissance. Les compresser permet de les exécuter sur un matériel moins coûteux, comme des A10s ou des T4s, avec une latence beaucoup plus faible.

Les modèles compressés sont également critiques pour l’exécution sur appareil (téléphones, navigateurs, IoT) de l’inférence, car les modèles plus petits permettent de servir plus de requêtes simultanées sans mettre à l’échelle l’infrastructure. Dans un chatbot avec plus de 1 000 utilisateurs simultanés, passer d’un modèle de 13B à un modèle compressé de 7B a permis à une équipe de servir plus du double du nombre d’utilisateurs par GPU sans pics de latence.

Utilisation de matériel spécialisé

Les CPU à usage général ne sont pas conçus pour les opérations tensorielles. Un matériel spécialisé comme les NVIDIA A100s, H100s, Google TPUs ou AWS Inferentia peut offrir une inférence plus rapide (entre 10 et 100 fois) pour les LLM avec une meilleure efficacité énergétique. Réduire même 100 millisecondes par requête peut faire une différence lors du traitement de millions de requêtes par jour.

Envisagez cet exemple hypothétique :

Une équipe exécute LLaMA-13B sur des GPU A10 standard pour son système RAG interne. La latence est d’environ 1,9 seconde, et ils ne peuvent pas regrouper beaucoup en raison des limites de VRAM. Ils passent donc à des H100 avec TensorRT-LLM, activent FP8 et noyau d’attention optimisé, augmentent la taille du lot de 8 à 64. Le résultat est de réduire la latence à 400 millisecondes avec une augmentation de cinq fois du débit.
En conséquence, ils sont en mesure de servir cinq fois plus de requêtes sur le même budget et de libérer les ingénieurs de la navigation dans les goulets d’étranglement de l’infrastructure.

Évaluation des options de déploiement

Différents processus nécessitent des infrastructures différentes ; un chatbot avec 10 utilisateurs et un moteur de recherche servant un million de requêtes par jour ont des besoins différents. S’engager à fond dans le cloud (par exemple, AWS Sagemaker) ou des serveurs GPU DIY sans évaluer les ratios coût-performance conduit à des dépenses gaspillées et à une mauvaise expérience utilisateur. Notez que si vous vous engagez tôt dans un fournisseur de cloud fermé, la migration de la solution plus tard est douloureuse. Cependant, évaluer tôt avec une structure pay-as-you-go offre des options plus tard.

L’évaluation comprend les étapes suivantes :

• Benchmarker la latence du modèle et le coût sur les plateformes : exécuter des tests A/B sur AWS, Azure, des grappes de GPU locales ou des outils serveurless pour répliquer.
• Mesurer les performances de démarrage à froid : cela est particulièrement important pour les charges de travail serveurless ou basées sur les événements, car les modèles se chargent plus rapidement.
• Évaluer l’observabilité et les limites de mise à l’échelle : évaluer les métriques disponibles et identifier le nombre maximal de requêtes par seconde avant de se dégrader.
• Vérifier la prise en charge de la conformité : déterminer si vous pouvez faire respecter les règles de données liées à la géographie ou les journaux d’audit.
• Estimer le coût total de possession. Cela devrait inclure les heures de GPU, le stockage, la bande passante et les frais généraux pour les équipes.

En résumé

L’inférence permet aux entreprises d’optimiser leurs performances d’IA, de réduire la consommation d’énergie et les coûts, de maintenir la confidentialité et la sécurité et de garder les clients satisfaits.