Répartir la charge : comment Salesforce assure la haute disponibilité multi-AZ avec les composants d'inférence SageMaker
Salesforce a déployé Amazon SageMaker AI Inference Components (IC) pour faire tourner Agentforce, sa plateforme d'agents IA, avec une disponibilité multi-zone (Multi-AZ). Cette technologie permet d'héberger plusieurs modèles sur des GPU partagés et a permis à Salesforce de réduire ses coûts d'infrastructure d'un facteur 8. Mais l'algorithme de placement par défaut des IC optimise chaque déploiement indépendamment, sans tenir compte de l'équilibrage entre zones de disponibilité (AZ), ce qui pouvait laisser des copies d'un même modèle concentrées sur une seule instance ou une seule AZ. Or Salesforce impose en interne un support obligatoire sur au moins deux AZ pour tout modèle en production. Pour résoudre ce problème, l'équipe a utilisé le nouveau paramètre SchedulingConfig de l'API CreateInferenceComponent d'AWS, avec ses sous-paramètres AvailabilityZoneBalance et PlacementStrategy. Dans un exemple concret cité dans l'article, un modèle nommé "salesforce-einstein-llm-v2" est déployé avec 4 copies réparties sur un endpoint de 4 instances, 2 par AZ, grâce à la stratégie SPREAD et un paramètre MaxImbalance limité à 1 copie d'écart maximum entre zones.
Résumé et traduction réalisés par Le Fil IA à partir de AWS ML Blog. Lire l'article original →
Cette avancée technique répond à un enjeu de résilience critique pour les entreprises qui déploient des modèles d'IA à grande échelle en production. Sans répartition équilibrée entre zones, une panne d'instance ou d'une AZ entière peut rendre un modèle totalement indisponible, un risque inacceptable pour des systèmes d'agents IA utilisés en contexte commercial comme Agentforce. En donnant aux utilisateurs un contrôle fin sur le placement des copies de modèles, AWS permet aux entreprises de concilier deux objectifs jusque-là difficiles à combiner : l'efficacité économique du partage de GPU entre plusieurs modèles, et les exigences de conformité et de continuité de service propres aux environnements de production critiques. Ce type de garantie devient un critère de choix pour les grands comptes qui évaluent les plateformes cloud pour héberger leurs charges de travail d'inférence IA.
Ce développement s'inscrit dans la montée en puissance des architectures d'inférence mutualisées, où plusieurs modèles partagent les mêmes ressources GPU pour réduire les coûts, une tendance née de la pression économique croissante liée au déploiement de grands modèles de langage. Les Inference Components de SageMaker avaient déjà permis à des entreprises comme Salesforce de réaliser des économies substantielles, mais la gestion fine de la haute disponibilité restait un point faible face aux exigences de conformité des grandes organisations. En ouvrant le paramétrage du placement des copies aussi bien à l'échelle des instances qu'à celle des zones de disponibilité, AWS renforce sa position face à d'autres fournisseurs cloud sur le segment de l'infrastructure IA d'entreprise. La capacité à gérer dynamiquement le scaling tout en préservant l'équilibre entre zones laisse présager d'autres affinements à venir, à mesure que les entreprises industrialisent leurs déploiements d'agents IA et exigent des garanties de service toujours plus strictes.
Les entreprises européennes déployant des modèles IA sur AWS SageMaker pourraient utiliser cette nouvelle fonctionnalité pour améliorer la résilience de leurs infrastructures, sans impact réglementaire direct sur la France ou l'UE.
La vraie info c'est pas les 8x d'économies, c'est le SchedulingConfig qui force le SPREAD entre AZ. Sans ça, tu partages tes GPU pour payer moins cher et tu recrées exactement le point de panne unique que le multi-AZ était censé éliminer. C'est le genre de détail d'API qui décide si Agentforce tient debout un vendredi soir ou pas, et ça va devenir un critère de sélection cloud pour les grands comptes bien avant les benchmarks de perf.