Synthèse
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é
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.
Source originale
silicon.fr