Salesforce utilise les contrôles SageMaker pour diffuser les modèles Agentforce dans les zones de disponibilité

Que s'est-il passé

AWS indique que Salesforce a déployé des modèles Agentforce avec les composants d'inférence SageMaker et a utilisé le nouveau paramètre SchedulingConfig pour distribuer des copies de modèles entre les zones de disponibilité et les instances. Salesforce a signalé une réduction de 8 fois des coûts d'infrastructure grâce au co-hébergement de plusieurs modèles sur des GPU partagés, mais le comportement de placement par défaut ne garantissait pas la résilience à deux zones requise pour ses modèles de production.

AWS et Salesforce décrivent un problème de service de production impliquant Agentforce, la base d'IA de Salesforce pour les agents. Les composants d'inférence SageMaker permettent à plusieurs modèles de partager une infrastructure basée sur GPU, ce qui, selon la source, a réduit de huit fois les coûts d'infrastructure de Salesforce. Le compromis était que l’algorithme de placement par défaut de SageMaker évaluait chaque opération de déploiement indépendamment. Les copies d'un modèle particulier pourraient donc être inégalement réparties, même lorsque le point de terminaison lui-même utilisait plusieurs zones de disponibilité. Cela a laissé une configuration multizone au niveau du point de terminaison insuffisante pour garantir la distribution au niveau du modèle. Le problème était spécifiquement la relation entre l'infrastructure partagée et le placement de copies de modèles individuelles.

Le nouveau contrôle est exposé via le paramètre SchedulingConfig dans l'API CreateInferenceComponent. Son paramètre AvailabilityZoneBalance régit la manière dont les copies sont réparties uniformément entre les zones, tandis que PlacementStrategy contrôle le placement dans chaque zone. SPREAD distribue des copies sur autant d'instances que possible pour améliorer l'isolation des pannes ; BINPACK place des copies sur moins d'instances pour améliorer l'utilisation. La source indique que Salesforce a sélectionné SPREAD pour ses exigences de haute disponibilité en production. Ces paramètres rendent explicite le comportement de placement prévu au moment du déploiement et relient le choix de la distribution à l'objectif opérationnel poursuivi.

AWS donne un exemple à deux zones avec quatre instances et quatre copies d'un modèle. Avec SPREAD et un déséquilibre maximum d'une copie, le résultat attendu est de deux copies dans chaque zone. Pour un modèle ne nécessitant que deux copies, un déséquilibre maximum de zéro vise exactement une copie par zone. Les mêmes paramètres de planification sont destinés à rester en vigueur pendant les mises à jour de scale-out, scale-in et de points de terminaison ou de composants d'inférence. La source recommande également une stratégie de consolidation pour un nettoyage à plus long terme après des opérations de détartrage répétées. Ensemble, ces détails décrivent le placement comme une préoccupation de planification continue plutôt que comme un paramètre appliqué une seule fois lors du déploiement initial.

Détails de la source: aws.amazon.com ↗

Pourquoi c'est important

Le déploiement résout un problème pratique lié au service des systèmes d'IA : un point de terminaison multizone peut toujours laisser toutes les copies d'un modèle concentrées dans une seule zone ou instance. La configuration donne aux équipes d'entreprise des contrôles explicites pour équilibrer le placement des zones de disponibilité et choisir entre l'isolation des pannes et une utilisation plus élevée.

La distinction entre la résilience au niveau du point final et au niveau du modèle est importante pour les organisations qui exploitent de nombreux modèles d’IA sur une infrastructure partagée. Un point de terminaison multizone ne garantit pas automatiquement que chaque modèle dispose d’une copie dans chaque zone. Si les copies d'un modèle sont concentrées, une panne d'instance ou une panne de zone peut supprimer ce modèle même si d'autres charges de travail sur le point de terminaison restent disponibles. Cela signifie qu’une conception à large zone de disponibilité peut sembler résiliente tout en laissant un modèle particulier exposé. La question du placement doit donc être évaluée au niveau des exemplaires de chaque modèle.

La fonctionnalité de placement relie les exigences de fiabilité à un compromis explicite en matière de ressources. SPREAD peut réduire le nombre de copies de modèle perdues en cas de panne d'instance, tandis que BINPACK peut améliorer l'utilisation de l'accélérateur en concentrant les charges de travail. Pour Salesforce, la source présente ce choix comme un moyen de conserver l’avantage économique de l’hébergement GPU multimodèle tout en répondant à une exigence interne selon laquelle chaque modèle de production prend en charge deux zones. La configuration ne supprime pas le compromis ; cela donne aux équipes un moyen direct de choisir comment leurs copies occupent les instances et les zones disponibles.

Le résultat rapporté est conséquent pour les opérations d'IA d'entreprise, car il fait passer la haute disponibilité d'un objectif d'architecture général à des paramètres de déploiement qui peuvent être inspectés et gérés. La source indique que Salesforce a atteint la conformité à deux zones pour sa flotte modèle, préservé ses économies de co-hébergement, maintenu la distribution pendant la mise à l'échelle et évité de rompre l'équilibre des zones lors des mises à jour du modèle. Il s'agit d'affirmations provenant du compte de réussite client AWS, et non de résultats de performances audités de manière indépendante. Le message n'établit pas comment le système s'est comporté lors d'une panne de zone réelle ni si chaque modèle et chaque région avaient des conditions identiques. Le compte rendu de mise en œuvre est donc utile pour comprendre le contrôle et son résultat déclaré, tout en laissant ouverte une validation indépendante.

Que regarder ensuite

La source ne fournit pas de mesures indépendantes de disponibilité, de résultats de tests de panne, de données de latence ou de comptabilisation complète de la réduction des coûts signalée. Les équipes qui adoptent ce modèle devront vérifier la capacité dans chaque zone cible, surveiller le placement après la mise à l'échelle et déterminer si le placement au mieux répond à leurs propres exigences de conformité.

La capacité reste une limitation centrale. AWS recommande des réservations de capacité à la demande dans chaque zone de disponibilité cible pour les régions limitées par zone, et la source indique que Salesforce a pré-provisionné une capacité GPU réservée pour aider à obtenir un placement équilibré. Sans capacité suffisante, SageMaker peut déployer partiellement des copies sur les instances disponibles car le mode d'application décrit est permissif. Cela rend la fonctionnalité utilisable sous contrainte, mais cela peut laisser la distribution finale moins équilibrée que prévu. La configuration souhaitée et le placement réellement réalisé peuvent donc différer lorsque la capacité requise n'est pas disponible dans chaque zone cible.

Les opérateurs devront surveiller si le placement souhaité persiste dans le temps. La source pointe vers les métriques SageMaker AI Insights et CloudWatch couvrant l'asymétrie des zones de disponibilité, le nombre de copies des composants d'inférence par zone, le rééquilibrage des événements et de la durée, ainsi que les erreurs de capacité insuffisante. Il avertit également qu'un composant critique HA ne doit pas être réduit à une seule copie, car une copie ne peut pas s'étendre sur deux zones. La question pratique est de savoir avec quelle rapidité les équipes détectent et corrigent un déséquilibre avant qu’il ne devienne un problème de disponibilité. La surveillance doit couvrir à la fois le nombre de copies et leur distribution, d'autant plus que la mise à l'échelle et les mises à jour modifient le déploiement.

Les détails importants restent inconnus de la source. Il n'indique pas les régions géographiques impliquées, le nombre de points de terminaison de production ou de modèles couverts, le coût de la capacité réservée, l'effet sur la latence et le débit, ni l'objectif de disponibilité que Salesforce tentait d'atteindre. Il ne fournit pas non plus de tests de défaillance comparatifs par rapport à l'algorithme par défaut. Les équipes d'entreprise doivent donc traiter la publication comme un modèle de mise en œuvre et un résultat rapporté par le client, puis valider la capacité, le comportement de basculement, la surveillance et le coût total dans leurs propres environnements. Ces contrôles sont nécessaires pour déterminer si l’équilibre déclaré entre résilience et utilisation s’applique à leurs propres charges de travail et conditions d’exploitation.

Guides et quiz associés