Aller au contenu principal
InfrastructureLatent Space · 2 min de lecture

L'ingénierie de l'inférence en pratique, avec Philip Kiely et Ali Taha (Baseten)

Source originale ↗·
L'ingénierie de l'inférence en pratique, avec Philip Kiely et Ali Taha (Baseten)
▶ Voir sur YouTube

Baseten, plateforme d'infrastructure pour l'inférence de modèles d'IA, a levé un tour de financement colossal de 13 milliards de dollars, rejoignant le cercle restreint des nouvelles licornes de l'infrastructure IA aux côtés de Nvidia et Intel, principales bénéficiaires de ce que certains appellent "l'inflexion de l'inférence". Dans un épisode récent du podcast Latent Space, animé par swyx et Vibhu, deux ingénieurs de Baseten, Philip Kiely et Ali Taha, détaillent ce qui se passe concrètement après la sortie d'un nouveau modèle open source, avant qu'il ne devienne une API rapide et fiable. Ali Taha a récemment publié une analyse très commentée du modèle Kimi K3, tandis que Philip Kiely a pris la parole à la conférence AI Engineer et publié un ouvrage de référence sur l'ingénierie de l'inférence. Les deux experts expliquent notamment comment, lors d'une expérience sur le modèle GLM-5.2, une quantification plus poussée a permis d'augmenter le débit de 20 % tout en préservant la qualité des benchmarks, les erreurs introduites dans différentes couches du modèle s'annulant mutuellement.

Cette discipline, quasi inexistante il y a trois ans, est devenue l'un des enjeux techniques majeurs de l'IA générative. Elle répond à une question distincte de celle de l'entraînement des modèles : comment transformer des poids de réseaux de neurones en un produit rapide, fiable et rentable à grande échelle. Les techniques évoquées, routage sensible au cache, séparation des phases de préremplissage et de décodage sur des GPU distincts, décodage spéculatif utilisant un petit modèle pour accélérer un plus grand, ou déplacement optimisé du cache KV, permettent des gains de performance allant de 20 % à parfois 200 %, avec des déploiements jusqu'à dix fois plus rapides. Pour l'industrie, cela signifie des coûts d'exploitation réduits et une meilleure fiabilité des API, un enjeu direct pour toute entreprise déployant des modèles à grande échelle plutôt que de dépendre d'API partagées.

Les deux ingénieurs reviennent aussi sur des cas concrets, comme la greffe d'un encodeur visuel du modèle Kimi directement sur GLM-5.2 sans modifier le modèle de langage sous-jacent, ou la gestion de requêtes atteignant 200 000 tokens. La conversation s'élargit ensuite à des sujets plus larges : la plateforme NVIDIA Dynamo, les futurs GPU Rubin, la question de savoir si le matériel évolue vers des puces IA programmables, ainsi que la convergence croissante entre entraînement et inférence, notamment via l'apprentissage continu s'appuyant sur des caches KV persistants, une piste qui pourrait redéfinir la frontière entre ces deux étapes historiquement séparées.

Cet article vous a été utile ?

Vu une erreur factuelle dans cet article ? Signalez-la. Toutes les corrections valides sont publiées sur /corrections.

À lire aussi

Surveiller et déboguer l'inférence IA générative avec SageMaker sur CloudWatch
1AWS ML Blog 

Surveiller et déboguer l'inférence IA générative avec SageMaker sur CloudWatch

Amazon Web Services a enrichi son service SageMaker AI d'un système de supervision avancé pour les endpoints d'inférence en temps réel : la plateforme émet désormais plus de 100 métriques détaillées couvrant la santé GPU, la latence au niveau des tokens, la pression sur le cache KV, la répartition du trafic entre zones de disponibilité et les diagnostics de démarrage à froid. Ces données alimentent automatiquement un tableau de bord intégré appelé SageMaker Insights, accessible directement depuis la console Amazon CloudWatch sous la section « Infrastructure Monitoring ». Le tableau de bord s'organise en trois vues, Performance, Capacité, Fiabilité, et exploite les métriques via une interface compatible PromQL, permettant également leur intégration dans des outils tiers comme Grafana ou Datadog. Deux architectures d'endpoints sont supportées : les endpoints mono-modèle (SME), où chaque modèle dispose de ses propres instances GPU, et les endpoints à composants d'inférence (IC), qui permettent à plusieurs modèles de partager la même infrastructure GPU avec une mise à l'échelle indépendante par modèle. Cette évolution répond à un besoin critique des équipes MLOps et SRE qui gèrent en production des dizaines de modèles sur des centaines d'instances GPU. Jusqu'ici, diagnostiquer un pic de latence P99 sur un endpoint LLM exigeait de déterminer en quelques minutes si la cause était une saturation de la mémoire GPU, un cache KV saturé, un déséquilibre de trafic entre zones ou une politique d'autoscaling trop lente, sans outillage natif pour y répondre rapidement. Le nouveau système supprime la nécessité de configurer manuellement des dashboards Grafana et des exporteurs Prometheus, ce qui représente un gain opérationnel significatif. Les métriques sont émises nativement au format OpenTelemetry, standard ouvert qui facilite l'interopérabilité avec l'écosystème d'observabilité existant des entreprises. La montée en puissance de l'inférence LLM en production a profondément modifié les priorités des équipes d'infrastructure machine learning : si l'entraînement des modèles concentrait autrefois l'essentiel de l'attention, c'est désormais le « serving » à grande échelle qui pose les défis les plus complexes, notamment en termes de coût GPU, de disponibilité et de gestion multi-modèles. L'architecture IC, recommandée par AWS pour les charges de travail IA génératives en production, permet de mutualiser l'infrastructure GPU entre plusieurs modèles et d'assurer la haute disponibilité via une distribution des répliques entre zones de disponibilité. Cette annonce s'inscrit dans une compétition accrue entre les grands fournisseurs cloud, AWS, Google Cloud et Azure, pour proposer des environnements de déploiement LLM clés en main, où l'observabilité devient un argument différenciant à mesure que les équipes industrialisent leurs pipelines d'inférence.

UELes équipes MLOps et SRE européennes industrialisant des pipelines d'inférence LLM en production bénéficient indirectement d'un outillage d'observabilité natif, réduisant la complexité opérationnelle sans configuration manuelle de Prometheus/Grafana.

InfrastructureOpinion
1 source
Le tournant de l'inférence
2Latent Space 

Le tournant de l'inférence

L'inférence est devenue le nouveau champ de bataille stratégique de l'intelligence artificielle. En quelques jours, deux signaux forts ont traversé l'industrie : Noam Brown a déclaré que "la puissance de calcul d'inférence est une ressource stratégique, actuellement sous-évaluée", tandis que Sam Altman affirmait qu'OpenAI devait "dans une large mesure devenir une entreprise d'inférence IA". Ces déclarations interviennent dans le sillage du lancement très réussi de GPT-4.5, mais aussi des chiffres publiés par Lip-Bu Tan, PDG d'Intel, lors de son appel aux résultats du premier trimestre 2026 : la demande en CPU, et non en GPU, est en hausse significative, tirée précisément par les nouveaux usages d'inférence à grande échelle. Jensen Huang, PDG de Nvidia, avait posé les bases de ce constat lors de sa keynote GTC : la demande en calcul a été multipliée par 10 000 en deux ans, l'usage par 100, ce qui représente selon lui une multiplication globale de un million fois en deux ans à peine. Ce basculement n'est pas qu'une métaphore : il redessine concrètement les priorités d'investissement de toute l'industrie. Pendant deux ans, les grandes entreprises tech ont massivement réorienté leurs budgets vers les GPU pour l'entraînement des modèles, au détriment de la maintenance et du renouvellement de leur parc CPU. Or, les agents IA en production, les environnements de simulation pour le renforcement par apprentissage (RL gyms), les outils comme Claude Code, tout cela tourne sur des CPU. Résultat : une potentielle pénurie de CPU se profile, non pas parce que la demande explose de façon spectaculaire comme pour les GPU, mais parce que le cycle naturel de renouvellement de cinq à six ans coïncide avec une sous-capitalisation chronique. Pour les startups comme pour les géants, le goulot d'étranglement se déplace : plus de capacité d'inférence se traduirait directement en plus de revenus, plus d'utilisateurs, des modèles plus performants. Ce moment marque une transition de phase dans l'économie de l'IA. L'ère de l'entraînement massif cède la place à celle du déploiement et du raisonnement continu : chaque fois qu'un modèle pense, agit, lit ou génère du texte, il infère. Cette boucle vertueuse, plus de capacité, plus de tokens, plus d'intelligence, est désormais le moteur central de la compétition entre OpenAI, Anthropic, Google et les autres. Les acteurs qui sécuriseront le plus de capacité d'inférence, que ce soit via des partenariats avec des fournisseurs cloud, des investissements dans des datacenters ou des puces propriétaires, prendront un avantage structurel difficile à rattraper. Le secteur CPU, longtemps dans l'ombre des GPU, redevient soudainement stratégique.

UELe goulot d'étranglement sur la capacité d'inférence CPU affecte directement les startups et entreprises européennes déployant des agents IA en production, qui devront repenser leurs priorités d'investissement infrastructure.

💬 C'est le pivot qu'on sentait venir depuis le lancement massif des agents en prod. Pendant deux ans, tout le monde a empilé des GPU pour l'entraînement, en laissant vieillir le parc CPU, et là c'est ce même parc qui devient le goulot d'étranglement pour l'inférence à grande échelle. Celui qui sécurise de la capacité d'inférence aujourd'hui prend une avance structurelle, pas juste technologique.

InfrastructureOpinion
1 source
Amazon Bedrock lance l'inférence d'IA générative en Asie-Pacifique (Nouvelle-Zélande)
3AWS ML Blog 

Amazon Bedrock lance l'inférence d'IA générative en Asie-Pacifique (Nouvelle-Zélande)

Amazon Web Services vient d'ouvrir l'accès à Amazon Bedrock depuis la région Asie-Pacifique (Nouvelle-Zélande), identifiée sous le code ap-southeast-6 et basée à Auckland. Les clients néo-zélandais peuvent désormais appeler directement les modèles d'Anthropic, Claude Opus 4.5 et 4.6, Sonnet 4.5 et 4.6, et Haiku 4.5, ainsi que les modèles Amazon Nova 2 Lite, sans passer par une région étrangère. Le mécanisme repose sur l'inférence cross-région : lorsqu'une requête est émise depuis Auckland, Amazon Bedrock la distribue dynamiquement vers une ou plusieurs régions de destination, Auckland elle-même, Sydney (ap-southeast-2) ou Melbourne (ap-southeast-4), en fonction de la charge et de la disponibilité. Toutes les données transitent exclusivement sur le réseau privé AWS, chiffrées en transit, sans jamais passer par l'internet public. Les appels sont enregistrés dans AWS CloudTrail depuis la région source, et les logs d'invocation peuvent être dirigés vers CloudWatch ou S3 dans la même région. Cette disponibilité régionale répond à une demande concrète des entreprises néo-zélandaises soumises à des exigences de résidence des données. Le profil géographique « AU » permet désormais de garantir que les traitements d'inférence restent dans le périmètre Australie–Nouvelle-Zélande, ce qui est décisif pour des secteurs comme la santé, la finance ou les services publics, où la localisation des données est une contrainte légale ou réglementaire. En parallèle, les organisations sans contrainte de résidence peuvent opter pour le profil global, qui route vers n'importe quelle région commerciale AWS dans le monde pour maximiser le débit disponible. Ce double choix de routage offre une flexibilité opérationnelle rare sur le marché du cloud. Amazon Bedrock s'étend ainsi progressivement dans la zone Pacifique, une région stratégique pour AWS face à la concurrence de Google Cloud et Microsoft Azure, qui ont également multiplié leurs ouvertures de datacenters locaux ces dernières années. La Nouvelle-Zélande, bien que marché de taille modeste, représente un point d'ancrage important pour les entreprises multinationales opérant dans la région ANZ. L'intégration d'Auckland dans le profil cross-région AU, sans modifier les comportements existants de Sydney et Melbourne, illustre une approche incrémentale conçue pour ne pas perturber les architectures déjà en production. La prochaine étape probable sera l'élargissement du catalogue de modèles accessibles depuis cette nouvelle région source, au fur et à mesure que les capacités d'inférence locales monteront en charge.

InfrastructureActu
1 source
4AWS ML Blog 

Bonnes pratiques pour l'inférence sur Amazon SageMaker HyperPod

Amazon a enrichi sa plateforme SageMaker HyperPod d'un ensemble de fonctionnalités dédiées à l'inférence de modèles d'IA générative, avec pour promesse affichée une réduction du coût total de possession allant jusqu'à 40%. La solution s'appuie sur Amazon Elastic Kubernetes Service (EKS) comme orchestrateur et permet de créer un cluster en quelques clics depuis la console SageMaker AI. Deux modes de configuration sont proposés : une installation rapide avec des ressources par défaut, et une installation personnalisée permettant d'intégrer des infrastructures existantes. Une fois le cluster actif, l'opérateur d'inférence intégré permet de déployer des modèles directement depuis des buckets S3, des systèmes de fichiers FSx for Lustre, ou depuis le catalogue SageMaker JumpStart, sans écrire une seule ligne de code. Des notebooks d'exemple couvrent les cas d'usage courants : modèles préconstruits, modèles fine-tunés, configurations personnalisées. L'enjeu central de cette mise à jour est la gestion dynamique des ressources GPU, historiquement coûteuse et complexe à piloter. HyperPod introduit une architecture de scalabilité à deux niveaux : KEDA (Kubernetes Event-Driven Autoscaling), un projet open source de la Cloud Native Computing Foundation, gère l'autoscaling des pods en fonction de métriques temps réel comme la longueur de la file de requêtes, la latence, ou des métriques CloudWatch et Prometheus personnalisées. KEDA peut réduire le nombre de pods à zéro en l'absence de trafic, supprimant ainsi les coûts à l'arrêt. En parallèle, Karpenter opère au niveau des nœuds de calcul : il provisionne ou retire des instances selon les besoins des pods en attente, et tourne dans le plan de contrôle EKS, ce qui évite tout surcoût lié à l'autoscaler lui-même. Cette combinaison permet de passer de zéro à une charge de production en réponse à la demande réelle. Ce lancement intervient dans un contexte où le déploiement de modèles de fondation à grande échelle est devenu un point de friction majeur pour les équipes IA en entreprise : infrastructure difficile à calibrer, pics de trafic imprévisibles, surinvestissement GPU, et délais de mise en production allongés. AWS positionne HyperPod comme une réponse complète à ce trilemme coût-performance-simplicité, en absorbant la complexité opérationnelle dans une couche managée. La plateforme concurrence directement les offres de Google (Vertex AI) et Microsoft Azure (ML endpoints managés), qui proposent des approches similaires. Les suites probables incluent une intégration plus poussée avec les outils d'observabilité AWS et une extension du support à d'autres architectures de modèles, alors que la course aux infrastructures d'inférence efficaces s'intensifie dans tout le secteur cloud.

InfrastructureActu
1 source

Recevez l'essentiel de l'IA chaque jour

Une sélection éditoriale quotidienne, sans bruit. Directement dans votre boîte mail.

Recevez l'essentiel de l'IA chaque jour

Gratuit · 1 email le matin, l'essentiel de l'IA · désinscription en un clic