Slack рассказал, как за четыре этапа превратил свою AI-инфраструктуру в мультиоблачную AI-платформу: компания ушла от самостоятельно обслуживаемого Amazon SageMaker к схеме с AWS Bedrock и Google Cloud Vertex AI. Результат звучит не декоративно: качество на сложных задачах рассуждения выросло примерно на 10%, а задержка для коротких промптов снизилась примерно на 67%. Для русскоязычных команд, которые строят AI-функции поверх чужих моделей, это хороший холодный душ: зависимость от одного облака быстро превращается из удобства в операционный риск.
О трансформации, как пишет InfoQ, Slack рассказал как о последовательной инженерной эволюции, а не как о внезапном архитектурном озарении. И это, пожалуй, самая полезная часть истории. Компания не начинала сразу с красивой схемы про отказоустойчивость и интеллектуальную маршрутизацию. Сначала у нее была вполне понятная конструкция: Amazon SageMaker в escrow VPC, доступ через cross-account IAM roles, жесткая изоляция и полный контроль над средой. На бумаге все выглядело солидно. На практике это означало ручной прогноз мощностей, плановое расширение кластеров и постоянную оглядку на дефицитные A100 и H100. Когда у тебя миллионы ежедневных пользователей и AI-функции уже встроены в продукт, ошибка в планировании GPU перестает быть внутренней проблемой платформенной команды и становится проблемой клиента.
Следующим этапом стал переход на Amazon Bedrock. Slack объясняет эту миграцию прагматично: инфраструктурная рутина съедала слишком много внимания, а доступ к новым моделям, в частности Anthropic, хотелось получать быстрее. Bedrock убрал необходимость напрямую управлять GPU-резервами и дал команде возможность переключиться с обслуживания железа на качество моделей и продуктовые сценарии. Переход провели через compliance-review, нагрузочное тестирование и rollout через feature flags; компания отдельно подчеркивает, что обошлась без инцидентов, заметных для пользователей. Для любой корпоративной платформы это, вероятно, самый интересный фрагмент кейса: не сам факт миграции, а то, что ее можно провести без публичного пожара, если не пытаться менять все сразу и не выключать предохранители.
Но Bedrock не решил все. Slack пишет, что нагрузка на AI-сервинг может колебаться до 10 раз между пиковыми и тихими периодами. Для таких качелей команда собрала гибридную модель емкости: интерактивный трафик отправляли на Provisioned Throughput с более предсказуемой задержкой, а фоновые и всплесковые нагрузки сбрасывали в On-Demand. Это сняло часть проблем с масштабированием больших AI-нагрузок и сделало поведение платформы более управляемым. Однако фундаментальный изъян остался на месте: даже хорошо настроенная система все еще зависела от одного провайдера. В 2026 году это уже не просто архитектурный вкус, а ограничение по устойчивости, доступности моделей и скорости экспериментов.
Именно поэтому Slack пошел дальше и добавил Google Cloud Vertex AI, превратив стек в мультиоблачную AI-платформу. Здесь начинается та часть, которую стоит читать всем, кто сейчас рисует очередной «LLM gateway» в корпоративном Confluence. Чтобы разные провайдеры вели себя как единая платформа, Slack пришлось строить абстрактный слой поверх облачных API. В него вошли secretless-аутентификация, нормализация API, единая наблюдаемость и интеллектуальная маршрутизация между провайдерами. Сервисы оцениваются по time-to-first-token, p90 latency и частоте 5xx-ошибок; если один из контуров деградирует, трафик можно увести в другой. Тот же слой позволяет делать A/B-тесты и аккуратно раскатывать модели, не переписывая прикладную логику под каждый новый endpoint.
Это важный сдвиг в самом подходе к AI-платформе. Еще год-два назад многие команды воспринимали выбор модели как почти неотделимый от выбора облака: пришли в экосистему, подключились к одному managed-сервису и дальше живете по его правилам, тарифам и roadmap. Slack показывает обратную логику: модельный слой нужно отделять от прикладного как можно раньше, иначе любое изменение провайдера превращается в проект миграции с кучей скрытых зависимостей. Особенно это критично для компаний, которые хотят одновременно держать SLA, контролировать задержки и не ждать, пока нужная модель появится именно у их текущего поставщика.
Важен и отраслевой контекст. История Slack не выглядит экзотикой. InfoQ приводит похожие примеры: инженеры Padiso описывали маршрутизацию запросов к Anthropic Claude через Bedrock, Vertex AI и прямой API Anthropic, чтобы повысить устойчивость и ослабить зависимость от одного канала. BentoML тоже продвигает мультиоблачный и кросс-региональный inference с маршрутизацией по задержке и доступности. То есть на рынке постепенно формируется практическая норма: если AI-нагрузка уже влияет на пользовательский опыт и выручку, «один провайдер на все случаи жизни» начинает выглядеть как временная мера, а не как целевая архитектура.
Для разработчиков и продуктовых команд из этого кейса следует довольно приземленный вывод. Главная ценность мультиоблачной AI-платформы не в том, чтобы поставить у себя еще один логотип облака на слайд. Ценность в том, чтобы сделать модельный слой заменяемым: измерять time-to-first-token, смотреть на p90, уметь быстро уводить трафик с деградировавшего провайдера, тестировать новые модели без перепаковки продукта и не зависеть от того, где именно сегодня есть нужная емкость и нужный релиз. Для бизнеса это означает меньше инфраструктурного заложничества и больше пространства для переговоров с поставщиками. Для платформенных инженеров, правда, есть плохая новость: мультиоблако не отменяет сложность, оно просто переводит ее с уровня GPU-кластеров на уровень абстракций, метрик и политики маршрутизации.
На этом фоне вопрос уже не в том, пойдут ли крупные продуктовые компании в мультиоблачный AI-сервинг, а в том, где они проведут границу. Одни ограничатся резервным провайдером на случай деградации основного. Другие, как Slack, будут строить слой, в котором облако становится взаимозаменяемой деталью, а конкуренция идет за качество модели, задержку и доступность. Похоже, именно такая архитектура и становится базовой для тех, кто не хочет однажды обнаружить, что их AI-функции отлично масштабируются ровно до первого чужого сбоя.