Quand des modèles arrivent sur SageMaker plusieurs semaines voire plusieurs mois après leur lancement sur Bedrock, cela peut donner envie de migrer d’un service à l’autre.
Mi-2024, Slack avait fait la bascule… en partie sur ce fondement. En toile de fond, l’intégration recénte de fonctionnalités de recherche et de résumé portées par des LLM.
SageMaker et les « travaux de plomberie »
L’architecture initiale déployée sur SageMaker impliquait un VPC d’entiercement. Les LLM s’y exécutaient, Slack pouvant par là même garantir aux utilisateurs que leurs données « [restaient] en interne ».
Pour maximiser la disponibilité, ces conteneurs furent déployés sur plusieurs régions AWS. Cela ne résolvait toutefois pas la latence de mise à l’échelle. Ni la disponibilité intermittente des GPU A100 et H100, ainsi que la nécessité de surprovisionner pour respecter les SLA.
Slack avait éliminé le problème de scaling avec de la planification cron. Et celui du surprovisionnement en passant par de la réservation de capacité à la demande.
À la coordination manuelle et aux « travaux de plomberie », il a cependant fini par privilégier une gestion automatisée de la capacité. Bedrock la lui a apportée… en plus, donc, d’un accès plus rapide aux derniers modèles.
Malgré Bedrock, de la capacité restait sous-utilisée
Mi-2024, Bedrock satisfaisait les attentes de Slack en matière de sécurité et de conformité (il avait obtenu la certification FedRAMP, niveau intermédiaire). Au-delà de l’aspect managé (plus besoin de gérer individuellement des instances GPU), il a permis d’adapter le compute aux charges de travail. En jouant, en l’occurrence, entre le débit provisionné et la capacité à la demande.
La première option fut utilisée pour les fonctionnalités interactives sensibles à la latence, comme le résumé de canal.
La seconde le fut pour les workloads prévisibles à fort pic de charge, tel le récapitulatif quotidien.
Cette association a contribué à réduire les ressources inutilisées. Il a néanmoins fallu, pour assurer une bonne expérience sur certaines fonctionnalités, se caler sur un pic de trafic, quand bien même il n’était atteint que dans une région géographique. Ce fut le cas pour le brief quotidien, dit « vue Aujourd’hui ». L’usage était plus important aux États-Unis qu’en Europe et en Asie, engendrant une sous-utilisation de capacité.
Un effet de verrouillage avec le débit provisionné
Le débit provisionné présentait un autre écueil : la nécessité de s’engager sur 1 à 6 mois. Dans l’univers des LLM, où les progrès sont rapides, cela réduit l’aptitude à suivre la cadence. Slack choisissait effectivement souvent d’attendre que ses engagements arrivent à expiration pour changer de modèle.
Dans ce contexte, tout a progressivement migré vers de l’infra à la demande, moyennant une étape intermédiaire basée sur un système de débordement. Bedrock s’est révélé efficace pour faire du routage multirégion en fonction de la disponibilité. Mais le modèle de ressources partagées a engendré des niveaux de service variables – un problème qui ne se posait pas avec le débit provisionné. Et soulevé un risque de concentration, autrement dit d’exposition aux pannes sur l’infrastructure globale.
Slack a donc construit une forme de résilience. Il a établi, pour chaque fonctionnalité IA, une hiérarchie de modèles. Un basculement s’orchestrait en cas de dégradation de certains indicateurs (délai pour le premier token, plafonnement du débit de requête, niveau de satisfaction client…).
Du multicloud… moyennant normalisation
Ce mécanisme ne protégeait pas contre l’exposition aux pannes globales. Slack avait par ailleurs constaté que les catalogues de modèles différaient entre clouders. Deux aspects qui ont motivé le passage au multicloud.
Début 2026, Slack AI s’étendait officiellement à Google Cloud. Il affirme qu’ajouter le catalogue de Vertex AI à celui de Bedrock lui a permis d’améliorer d’environ 10 % ses indicateurs de qualité sur les « tâches de raisonnement complexe ». Et de réduire de 67 % la latence sur les « petits » workloads (peu gourmands en tokens).
Le multicloud lui a aussi permis d’implémenter davantage de stratégies de routage du trafic, à base de divers circuit breakers et d’A/B testing. Pour résoudre le problème des démarrages à froid, il a implémenté une authentification sans secrets et une couche de normalisation API. Il a aussi fallu développer une stack unifiée pour le monitoring, les dashboards natifs de l’un et de l’autre laissant des zones d’ombre. S’est également posé le défi du suivi des coûts, plus délicat lorsque des workloads basculent dynamiquement entre clouds. Quant aux ingés, ils ont dû se former sur les deux écosystèmes…
Illustration principale générée par IA
The post D’AWS à GCP, comment l’IA de Slack est devenue multicloud appeared first on Silicon.fr.
