Slack’s journey to a multicloud AI infrastructure began with an initial deployment on AWS SageMaker. To keep user data in-house, the company ran large language models inside an isolated VPC, distributed across multiple AWS regions for availability. But scaling latency, intermittent access to A100 and H100 GPUs, and the need to overprovision to meet service-level agreements created significant operational overhead. The team initially resorted to cron-based scaling and on-demand capacity reservations, but soon sought a more automated approach.

In mid-2024, Slack migrated to AWS Bedrock, drawn by its managed service model and faster access to the latest models—some of which arrived weeks or months later on SageMaker. Bedrock, which had achieved FedRAMP Moderate certification, allowed Slack to match compute more precisely to workloads. Latency-sensitive interactive features like channel summarization used provisioned throughput, while predictable, bursty tasks like the daily recap consumed on-demand capacity. This mix reduced idle resources, but the “Today” view still forced provisioning for US peak traffic, leaving capacity underutilized in Europe and Asia.

Provisioned throughput introduced its own friction: monthly or multi-month commitments clashed with the rapid evolution of LLMs. Slack often waited for contracts to expire before switching models. The company gradually moved almost all workloads to on-demand infrastructure, using a spillover mechanism. Bedrock excelled at multi-region routing based on availability, but the shared resource model brought variable service performance and a new concentration risk—a single infrastructure failure could cascade. To counter this, Slack built a model hierarchy for each AI feature, with automated failover triggered by metrics like time-to-first-token, request throttling, or customer satisfaction scores.

Neither this nor Bedrock’s model catalog could fully insulate Slack from global outages, and catalogs differed between cloud providers. Those factors pushed Slack toward multicloud. Officially extending Slack AI to Google Cloud’s Vertex AI in early 2026, Slack reported a roughly 10% improvement in quality metrics for complex reasoning tasks and a 67% reduction in latency on small, low-token workloads. The expanded catalog also enabled more sophisticated traffic routing, employing circuit breakers and A/B testing.

Adopting multicloud required significant engineering: a secretless authentication layer and a unified API normalization stack to eliminate cold starts, a consolidated monitoring dashboard because native tools left blind spots, and new cost-tracking mechanisms to handle workloads shifting dynamically between clouds. Engineers had to become fluent in both ecosystems. Taken together, the move gave Slack the resilience and flexibility to navigate the rapidly shifting LLM landscape, while delivering faster, more reliable AI features to users.

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.