Aller au contenu principal
Déploiement rentable de modèles vision-langage pour la détection du comportement animal sur AWS Inferentia2
InfrastructureAWS ML Blog · 2 min de lecture

Déploiement rentable de modèles vision-langage pour la détection du comportement animal sur AWS Inferentia2

Source originale ↗·

Tomofun, la startup taïwanaise à l'origine de la caméra connectée Furbo, a migré une partie de son infrastructure d'inférence IA des instances GPU Amazon EC2 vers des instances EC2 Inf2, propulsées par les puces AWS Inferentia2 conçues en interne par Amazon. Le système Furbo analyse en temps réel les flux vidéo provenant de centaines de milliers de caméras domestiques pour détecter des comportements animaux précis, aboiements, courses, activités inhabituelles, et envoyer des alertes instantanées aux propriétaires. Le modèle central est BLIP (Bootstrapping Language-Image Pre-Training), un modèle vision-langage compilé via le SDK Neuron d'AWS pour s'exécuter nativement sur Inferentia2. L'architecture déployée s'appuie sur deux couches d'Auto Scaling EC2 derrière un Elastic Load Balancer : la première traite les requêtes API, la seconde héberge les conteneurs d'inférence. Amazon CloudFront achemine les images des caméras vers ce pipeline, tandis que CloudWatch surveille la latence, le débit et les taux d'erreur en continu.

La motivation principale de cette migration est économique. L'inférence toujours active à grande échelle est fondamentalement différente de l'entraînement : elle ne nécessite pas la puissance brute des GPU, mais exige une disponibilité permanente et un coût par requête minimal. En remplaçant une partie des GPU par des instances Inf2, Tomofun réduit significativement ses dépenses d'infrastructure tout en maintenant la précision et le débit du modèle. La transition a été conçue pour être transparente : l'API Furbo peut désormais router les requêtes vers des conteneurs GPU ou Inferentia2 sans modifier la logique d'alerte en aval ni l'expérience utilisateur. Cette flexibilité permet aussi d'ajuster dynamiquement le mix en fonction de la charge et des coûts, ce qui est particulièrement précieux pour un service dont le trafic fluctue selon les heures de la journée dans de nombreux fuseaux horaires.

Cette initiative s'inscrit dans une tendance plus large du marché cloud : les grandes plateformes développent leurs propres puces d'inférence, Inferentia2 chez AWS, TPU chez Google, et les futures puces de Meta, pour offrir une alternative moins coûteuse aux GPU Nvidia dans les déploiements de production à grande échelle. Pour les entreprises gérant des millions de requêtes d'inférence quotidiennes sur des modèles de vision stabilisés, l'argument économique des accélérateurs spécialisés devient difficile à ignorer. Le cas Tomofun illustre concrètement ce compromis : conserver les GPU pour la flexibilité et les pics, tout en basculant la charge de base vers Inferentia2. Avec la prolifération des objets connectés embarquant de l'IA en périphérie, ce modèle hybride pourrait devenir la norme pour les acteurs du secteur de la "pet tech" et plus largement de l'IoT intelligent.

Dans nos dossiers

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

La mise en cache des conteneurs dans Amazon SageMaker AI accélère le déploiement des modèles
1AWS ML Blog 

La mise en cache des conteneurs dans Amazon SageMaker AI accélère le déploiement des modèles

Amazon Web Services vient d'annoncer une nouvelle fonctionnalité pour SageMaker AI : le cache des images de conteneurs lors des événements de mise à l'échelle. Concrètement, cette optimisation réduit jusqu'à 51 % la latence de démarrage lors du lancement de nouvelles instances, et jusqu'à 2x pour les modèles d'IA générative en conditions réelles. Pour illustrer le gain : avec le modèle Qwen3-8B (16 Go) sur une instance ml.g6.2xlarge et le conteneur LMI de SageMaker (17,7 Go compressé), la latence de démarrage passe de 525 secondes à 258 secondes. Avant le cache, le téléchargement de l'image depuis Amazon ECR prenait à lui seul 333 secondes, en parallèle du téléchargement des poids du modèle depuis S3 (168 secondes). Avec le cache, l'image est déjà disponible localement (0 seconde), et le téléchargement du modèle tombe à 77 secondes, la compétition pour la bande passante réseau étant éliminée. L'enjeu est considérable pour les équipes qui déploient des modèles de langage en production. Lors d'un pic de trafic, chaque seconde de latence au démarrage d'une nouvelle instance se traduit directement en requêtes non servies ou en surcoût d'instances pré-chauffées. Les workloads d'IA générative sont particulièrement touchés car ils utilisent des conteneurs très volumineux, LMI (basé sur vLLM), vLLM natif, NVIDIA Triton, qui pouvaient représenter la majeure partie du temps d'initialisation. La fonctionnalité s'applique aux deux architectures d'endpoints SageMaker : les endpoints à modèle unique (où chaque nouvelle instance héberge sa propre copie du modèle) et les endpoints à composants d'inférence (où de nouvelles instances sont lancées uniquement quand aucune instance existante n'a la capacité suffisante). Si le cache est indisponible, SageMaker revient automatiquement au téléchargement depuis ECR, sans interruption de service. Cette annonce s'inscrit dans une stratégie progressive d'AWS pour réduire la latence de mise à l'échelle sur SageMaker. La plateforme avait déjà introduit des métriques CloudWatch sub-minute permettant de détecter les besoins de scale-out jusqu'à 6 fois plus vite, ainsi qu'un cache de données par instance pour les composants d'inférence réutilisant des instances déjà en cours d'exécution. Mais ces solutions précédentes ne couvraient pas le cas où une toute nouvelle instance devait être lancée, le scénario le plus coûteux. Le cache de conteneurs comble précisément ce manque. Dans un contexte où la concurrence entre AWS, Google Cloud et Azure s'intensifie sur les performances d'inférence, cette optimisation renforce la position de SageMaker pour les déploiements LLM à grande échelle, notamment dans les entreprises qui font face à des pics de charge imprévisibles.

UELes entreprises françaises et européennes déployant des LLMs sur Amazon SageMaker bénéficieront directement de cette réduction de latence au scale-out, sans configuration supplémentaire.

InfrastructureActu
1 source
OpenAI et Broadcom annoncent une puce dédiée à l'inférence de grands modèles de langage
2Ars Technica AI 

OpenAI et Broadcom annoncent une puce dédiée à l'inférence de grands modèles de langage

OpenAI et Broadcom ont annoncé conjointement une nouvelle puce baptisée Jalapeño, conçue spécifiquement pour l'inférence de grands modèles de langage (LLM) dans les centres de données à grande échelle. Les deux entreprises présentent ce composant comme la première génération d'un partenariat à long terme, avec l'ambition d'affiner et d'améliorer le design des puces au fil des générations successives. Cette annonce marque une étape significative dans la stratégie d'OpenAI pour maîtriser sa propre chaîne d'approvisionnement en silicium. L'inférence, soit le processus par lequel un modèle génère des réponses en temps réel, représente la charge computationnelle la plus coûteuse et la plus constante pour une entreprise comme OpenAI, qui sert des centaines de millions d'utilisateurs via ChatGPT et ses API. Disposer d'une puce dédiée, optimisée pour ce cas d'usage précis, pourrait réduire drastiquement les coûts opérationnels et diminuer la dépendance d'OpenAI envers Nvidia, dont les GPU dominent aujourd'hui le marché de l'IA. Cette démarche s'inscrit dans une tendance de fond : les géants du numérique cherchent tous à s'affranchir de Nvidia en développant leurs propres accélérateurs. Google a ses TPU, Amazon son Trainium, Microsoft son Maia, Apple son Neural Engine. Broadcom, qui fabrique déjà des puces personnalisées pour Google et Meta, s'affirme comme le partenaire industriel privilégié de cette nouvelle vague. Le fait qu'OpenAI rejoigne ce mouvement avec un chip nominalement dédié à l'inférence signale que la société considère désormais le contrôle du matériel comme un avantage concurrentiel structurel, et non plus une simple option.

InfrastructureOpinion
1 source
Comment AWS accélère l'entraînement des modèles d'IA pour les effets visuels chez Outpost VFX
3AWS ML Blog 

Comment AWS accélère l'entraînement des modèles d'IA pour les effets visuels chez Outpost VFX

Outpost VFX, studio d'effets visuels opérant au Royaume-Uni, au Canada et en Inde, a multiplie par 8 la vitesse d'entrainement de ses modèles d'intelligence artificielle dédiés au remplacement de visages dans les productions cinéma et sériés, grâce a une infrastructure cloud AWS. L'entreprise, cliente d'AWS depuis 2022, a collabore avec les équipes du Generative AI Innovation Center pour moderniser ses algorithmes. Auparavant, Outpost VFX entrainait ses modèles sur des stations de travail équipées de cartes graphiques RTX 3090, en alimentant les algorithmes avec de petits jeux de données d'acteurs et de leurs doublures. Ce processus prenait entre une et deux semaines par cycle d'affinage, et la technologie ne pouvait exploiter qu'un seul GPU a la fois, ce qui limitait l'accès a la mémoire vidéo et donc la capacité de traitement. Le studio est passe a des instances Amazon EC2 de type P5, équipées de GPU NVIDIA H100 conçus pour l'entrainement distribue, et reliées par une interconnexion NV Link plus performante que la communication PCIe utilisée sur les instances de la série G. Ce changement transforme concrètement le quotidien des équipes de production. Les méthodes traditionnelles de remplacement de visages, qu'il s'agisse de compositing ou de techniques spécialisées de rajeunissement ou de vieillissement numérique, nécessitaient plus de cinq jours pour produire une première version soumise a validation du réalisateur. Ce délai constituait un goulot d'étranglement des les premières étapes du processus d'approbation, une phase pourtant critique pour le respect des plannings. En accélérant l'entrainement, Outpost VFX réduit les délais de livraison aux clients, limite les couts lies aux itérations multiples et accélère les boucles de retour créatif, des enjeux cruciaux dans une industrie ou chaque jour de retard se répercute sur l'ensemble du calendrier de production. Cette évolution s'inscrit dans une demande plus large de scalabilité, de sécurité et de qualité. Outpost VFX avait identifie trois besoins techniques prioritaires: la possibilité de paralléliser l'entrainement sur plusieurs GPU pour sortir des limites du mono-GPU, le respect de standards de sécurité stricts pour traiter des données de production hautement sensibles dans un environnement cloud ségrégué, et une architecture capable de gérer des jeux de données plus volumineux ainsi que des images en plus haute résolution afin d'améliorer la qualité des résultats. La solution a consiste a adapter le code existant du modèle de remplacement de visages pour qu'il fonctionne en entrainement distribue sur des instances P5 dans un environnement cloud sécurisé, aligne sur l'infrastructure déjà virtualisée du studio. L'expérience d'Outpost VFX illustre une tendance plus générale dans l'industrie des effets visuels, ou les studios cherchent a combiner puissance de calcul a la demande et exigences de confidentialité pour accélérer des workflows IA jusque-la freines par des contraintes matérielles locales.

InfrastructureActu
1 source
Les clés de la flexibilité de l'IA en Europe : guide sur l'inférence interrégionale pour le traitement des données et l'accès aux modèles
4AWS ML Blog 

Les clés de la flexibilité de l'IA en Europe : guide sur l'inférence interrégionale pour le traitement des données et l'accès aux modèles

Amazon Web Services a introduit une fonctionnalité appelée Cross-Region Inference (CRIS) dans Amazon Bedrock, son service d'IA générative managé, permettant aux entreprises européennes de router automatiquement leurs requêtes d'inférence vers plusieurs régions AWS au sein de zones géographiques prédéfinies. Concrètement, lorsqu'une application envoie une requête à un modèle comme Claude d'Anthropic ou un modèle Amazon Nova, CRIS peut la rediriger dynamiquement vers la région disposant de la meilleure capacité disponible, tout en maintenant les données dans un périmètre géographique contrôlé. Pour l'Europe, AWS propose des profils EU CRIS dont toutes les régions de destination sont situées exclusivement au sein de l'Union européenne. Les données transmises restent chiffrées et circulent uniquement sur le réseau privé AWS, sans jamais transiter par l'internet public. Ce mécanisme répond à un problème concret que rencontrent les entreprises européennes : la saturation des capacités de calcul GPU en période de forte demande, qui se traduit par des latences élevées ou des erreurs de disponibilité. En distribuant les requêtes sur plusieurs régions, les applications deviennent plus résilientes aux pics de charge et aux pannes locales. Du point de vue réglementaire, les profils EU CRIS sont conçus pour faciliter la conformité au RGPD, puisque le traitement reste borné à l'UE, un critère déterminant pour les secteurs soumis à des exigences strictes de résidence des données comme la finance, la santé ou les services publics. AWS souligne également que certains modèles sont disponibles à tarif réduit via les profils globaux CRIS, ajoutant un argument économique à l'argument technique. La pression réglementaire européenne sur le traitement des données par des fournisseurs cloud américains s'est intensifiée ces dernières années, notamment après les décisions de la CJUE sur les transferts transatlantiques de données. Les grands hyperscalers comme AWS, Google Cloud et Microsoft Azure ont tous investi massivement dans des infrastructures européennes et des offres de souveraineté pour répondre à ces contraintes. CRIS s'inscrit dans cette logique : plutôt que de forcer les clients à choisir une seule région et à subir ses limitations de capacité, AWS propose une abstraction qui optimise automatiquement tout en respectant les frontières réglementaires. La prochaine étape logique sera l'extension de ces profils géographiques à d'autres zones comme le Moyen-Orient ou l'Asie-Pacifique, et l'intégration de contrôles plus fins permettant aux entreprises de définir elles-mêmes les régions autorisées selon leurs obligations contractuelles ou sectorielles.

UELa fonctionnalité EU CRIS d'AWS Bedrock permet aux entreprises européennes de maintenir leurs traitements d'inférence IA exclusivement dans les frontières de l'UE, facilitant la conformité RGPD pour les secteurs finance, santé et services publics soumis à des exigences strictes de résidence des données.

InfrastructureOpinion
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