Salesforce divise par huit les coûts d’Agentforce avec SageMaker

Salesforce déploie Agentforce avec une exigence de haute disponibilité sur plusieurs zones de disponibilité AWS. L’équipe devait satisfaire une règle interne imposant deux zones pour chaque modèle de production. Les composants d’inférence Amazon SageMaker réduisaient déjà les coûts d’infrastructure par huit. Cette baisse venait de l’hébergement de plusieurs modèles sur des GPU partagés. Leur placement par défaut ne garantissait toutefois pas une répartition équilibrée entre zones. Salesforce a donc utilisé la fonctionnalité IC Placement, exposée par le paramètre SchedulingConfig de l’API CreateInferenceComponent. Cette configuration permet de contrôler la répartition des copies entre instances et zones. Elle vise ainsi la conformité Multi-AZ d’Agentforce, la plateforme d’IA de Salesforce pour ses agents.

Le placement par défaut concentrait potentiellement les copies d’un modèle dans une même zone. L’algorithme SageMaker optimisait chaque opération de déploiement séparément. Il répartissait les nouvelles copies entre instances sans considérer l’équilibre global entre zones. Une panne d’instance pouvait donc interrompre plusieurs copies du même modèle. Une panne de zone pouvait rendre le modèle entièrement indisponible. Un point de terminaison utilisant plusieurs zones ne suffisait donc pas à satisfaire la règle interne de Salesforce. La nouvelle configuration ajoute deux contrôles. AvailabilityZoneBalance équilibre les copies entre zones avec une tolérance configurable. PlacementStrategy choisit ensuite leur répartition entre instances à l’intérieur de chaque zone. Agentforce constitue la plateforme concernée par cette architecture.

SageMaker équilibre les copies

Le scénario Salesforce utilise quatre instances réparties équitablement entre deux zones. L’équipe déploie quatre copies d’un modèle sur ce point de terminaison. Avec PlacementStrategy réglé sur SPREAD, SageMaker place une copie sur chaque instance. Deux copies se trouvent ainsi dans la première zone et deux dans la seconde. Le paramètre MaxImbalance réglé à 1 autorise au maximum une copie d’écart entre deux zones. Pour un modèle plus léger nécessitant deux copies, MaxImbalance réglé à 0 vise une copie exactement par zone. La configuration fournie utilise aussi 65 536 mégaoctets de mémoire minimale et un accélérateur par copie. Le cache des artefacts est activé pour accélérer la montée en charge.

La stratégie SPREAD privilégie l’isolation des pannes plutôt que la densité d’utilisation des instances. À l’inverse, BINPACK regroupe les copies sur moins d’instances pour améliorer l’utilisation des ressources. Salesforce a retenu SPREAD pour limiter l’impact d’une panne d’instance. Le déploiement peut aussi concerner des modèles nécessitant plusieurs accélérateurs par copie. SageMaker applique alors la même logique de répartition entre zones et instances. Lors d’une montée en charge, les nouvelles copies maintiennent la distribution configurée. Lors d’une réduction, SageMaker retire les copies de manière symétrique entre zones. Un modèle critique ne doit jamais utiliser une seule copie. Une copie unique ne peut résider que dans une seule zone.

Salesforce conserve l’équilibre

La consolidation complète le placement après plusieurs cycles de montée et de réduction en charge. Salesforce peut configurer la stratégie CONSOLIDATION dans la ScaleInPolicy du point de terminaison. Un processus en arrière-plan regroupe alors les copies et libère les instances inutilisées. Cette opération respecte les contraintes d’équilibre entre zones. La capacité réservée à la demande est recommandée par AWS dans les régions contraintes. Salesforce préprovisionne ainsi des GPU réservés dans chaque zone cible. Sans cette capacité, les contraintes d’approvisionnement peuvent limiter la répartition recherchée. SageMaker autorise néanmoins un déploiement partiel lorsque la capacité empêche un équilibre complet. Les copies sont alors placées sur les instances disponibles, avec un équilibre potentiellement inférieur. Le billet technique d’AWS détaille cette implémentation. Pour aller plus loin, consultez notre guide sur réduire ses coûts grâce à l’IA.