InfrastructureAWS ML Blog6sem· 2 min de lecture

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

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

AWS Meta IA NVIDIA

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

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

2AWS 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

3Meta Engineering ML

Meta Adaptive Ranking Model : infléchir la courbe d'inférence pour déployer des LLM dans la publicité

Meta a dévoilé l'Adaptive Ranking Model (ARM), un nouveau système de recommandation publicitaire fonctionnant à l'échelle des grands modèles de langage (LLM). Déployé sur Instagram au quatrième trimestre 2025, ARM a généré une hausse de 3 % des conversions publicitaires et de 5 % du taux de clics pour les utilisateurs ciblés. Le système atteint une complexité de calcul équivalente à celle des meilleurs LLMs — environ 10 GFLOPs par token — tout en maintenant une latence inférieure à 100 millisecondes, soit un ordre de grandeur plus rapide que l'inférence LLM standard. L'enjeu central qu'ARM résout est ce que Meta appelle le « trilemme de l'inférence » : comment faire tourner des modèles d'une complexité comparable à GPT-4 ou Llama dans un environnement publicitaire temps réel, où chaque requête doit aboutir en moins d'une seconde, pour des milliards d'utilisateurs, sans exploser les coûts d'infrastructure. La solution repose sur un routage intelligent des requêtes : plutôt que d'appliquer le même modèle à chaque impression publicitaire, ARM analyse le contexte et l'intention de l'utilisateur pour décider dynamiquement du niveau de complexité nécessaire. Les requêtes simples consomment peu de ressources ; les requêtes complexes mobilisent toute la puissance du modèle LLM-scale. Ce principe d'alignement dynamique entre complexité et contexte permet de maximiser la qualité des prédictions sans surcharger les serveurs. Trois innovations techniques rendent cela possible. Premièrement, une architecture centrée sur la requête plutôt que sur le modèle, permettant de servir un modèle à un trillion de paramètres (O(1T)) de façon économiquement viable. Deuxièmement, une co-conception modèle-matériel : les architectures sont conçues en tenant compte des contraintes précises du silicium utilisé, ce qui améliore significativement l'utilisation des GPU dans des environnements matériels hétérogènes. Troisièmement, une infrastructure de serving repensée autour d'architectures multi-cartes et d'optimisations bas-niveau spécifiques au hardware. Ce développement s'inscrit dans la course que se livrent les grandes plateformes pour intégrer l'intelligence des LLMs dans leurs systèmes de recommandation — un marché où chaque fraction de point de taux de conversion se traduit en milliards de dollars de revenus publicitaires. Pour Meta, dont plus de 98 % des revenus proviennent de la publicité, ARM représente une avancée structurelle : la preuve qu'il est désormais possible de faire fonctionner des modèles de la taille de ceux utilisés pour les chatbots dans des pipelines industriels ultra-contraints en latence et en coût.

UELes annonceurs européens utilisant Instagram et Facebook bénéficient indirectement d'un ciblage publicitaire amélioré, sans impact réglementaire ou stratégique direct pour la France ou l'UE.

InfrastructureOpinion

1 source

4VentureBeat AI

L'architecture de contexte remplace le RAG à mesure que les agents IA poussent la récupération d'information en entreprise à ses limites

Redis a lancé lundi Redis Iris, une plateforme de contexte et de mémoire conçue pour les agents d'intelligence artificielle en production. L'annonce vient du CEO Rowan Trollope et marque une évolution majeure dans la stratégie de l'entreprise, historiquement connue comme couche de cache pour les applications web. Redis Iris se positionne entre l'agent et les données dont il a besoin pour agir, en combinant cinq composants : Redis Data Integration (désormais en disponibilité générale), qui synchronise en continu les bases relationnelles, entrepôts et documents via des connecteurs pour Oracle, Snowflake, Databricks et Postgres ; un Context Retriever (en préversion) qui génère automatiquement des outils MCP à partir de modèles de données métier définis en Pydantic, avec contrôles d'accès appliqués côté serveur ; un serveur de mémoire agent pour conserver le contexte à court et long terme entre les sessions ; et Redis Flex, un moteur de stockage réécrit faisant tourner 99 % des données sur SSD et 1 % en RAM, réduisant le coût à un dixième du stockage purement en mémoire. La raison d'être de cette architecture tient à un déséquilibre structurel entre agents et humains. Trollope le formule clairement : les entreprises auront un nombre d'agents plusieurs ordres de grandeur supérieur à celui de leurs employés humains, ce qui génère une charge équivalente sur les systèmes backend. Les pipelines RAG classiques, construits pour des requêtes humaines ponctuelles, ne tiennent pas face au volume que produisent des agents opérant en continu. Redis inverse la logique : plutôt que de présupposer quelles données injecter dans le pipeline, il laisse l'agent tirer lui-même l'information via des interfaces construites pour lui. Le marché confirme l'urgence : selon le VB Pulse RAG Infrastructure Market Tracker du premier trimestre 2026, l'intention d'adoption du retrieval hybride a triplé de 10,3 % à 33,3 % entre janvier et mars, l'optimisation du retrieval est devenue la première priorité d'investissement enterprise devant l'évaluation, et les stacks de retrieval maison sont passées de 24,1 % à 35,6 % du marché. Redis n'est pas le seul acteur à repositionner son offre autour des couches de contexte agent, plusieurs fournisseurs de plateformes de données ayant fait des annonces similaires ces dernières semaines. Trollope tire le parallèle avec l'ère mobile : quand les systèmes bancaires conçus pour les guichets ont dû absorber des millions d'utilisateurs smartphone, Redis est devenu la couche de cache qui a évité une refonte totale des backends. La différence aujourd'hui, c'est que les agents ne peuvent pas écrire leur propre middleware : ils ont besoin, au moment de l'exécution, d'interfaces préparées en amont, ou ils s'arrêtent. La transition de l'infrastructure RAG vers des architectures de contexte dédiées aux agents semble donc moins être une tendance émergente qu'un basculement déjà en cours dans les grandes entreprises.

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, rédigé par un humain · désinscription en un clic