Как Salesforce добилась Multi-AZ отказоустойчивости для SageMaker Inference Components без потери экономии на GPU

Для критичной AI-модели недостаточно запустить SageMaker endpoint в нескольких Availability Zones. Копии конкретного Inference Component могут оказаться сосредоточены в одной зоне, и при отказе этой AZ модель потеряет доступность, даже если сам endpoint продолжит работать.

Архитектура, которую связывают с кейсом Salesforce, решает эту проблему через конфигурацию SchedulingConfig. Параметр PlacementStrategy: SPREAD задаёт распределение копий по доменам отказа, а MaxImbalance ограничивает допустимую разницу между зонами. Такой подход помогает совместить Multi-AZ отказоустойчивость с размещением нескольких моделей на общих GPU.

Точный набор параметров и детали реализации Salesforce нужно сверять с первоисточником. Ниже разобрана практическая логика такой схемы, ограничения планировщика и вопросы, которые нужно проверить перед запуском production-инференса.

Почему многозонный endpoint ещё не гарантирует отказоустойчивость модели

Multi-AZ на уровне инфраструктуры и Multi-AZ на уровне модели решают разные задачи. Endpoint может использовать ресурсы в нескольких Availability Zones, но конкретный Inference Component при этом получить копии только в одной зоне. Для системы с несколькими независимыми моделями результат может отличаться для каждого компонента.

Где возникает единая точка отказа

Представим endpoint с тремя GPU-инстансами в двух Availability Zones. На уровне endpoint инфраструктура выглядит многозонной. Однако все три копии одной критичной модели могут находиться в первой зоне. Потеря этой AZ приведёт к недоступности компонента, хотя часть инфраструктуры endpoint продолжит отвечать на запросы.

Последствия зависят от настроек маршрутизации и способности SageMaker быстро разместить копии заново:

• запросы к модели начинают завершаться ошибками;
• маршрутизация переносит нагрузку на оставшиеся компоненты;
• latency растёт из-за перестройки распределения запросов или повторного запуска копий;
• система ждёт доступную GPU-capacity, если в оставшейся зоне нет свободного ресурса;
• оператору приходится восстанавливать требуемое число копий после сбоя.

Риск нельзя оценить по одному признаку, например по числу инстансов или статусу endpoint. Нужно видеть фактическое размещение копий конкретной модели и сопоставлять его с требованиями к доступности, времени восстановления и нагрузке.

Почему обычного CopyCount недостаточно

CopyCount отвечает за число копий Inference Component. Он не описывает сам по себе, в каких Availability Zones эти копии окажутся. Три копии в одной зоне дают больше пропускной способности и локальной избыточности, но не устраняют отказ всей зоны.

Для HA-критичной модели нужно проверить две независимые характеристики:

1. сколько копий активно и выдерживают ли они штатную нагрузку;
2. как эти копии распределены между доменами отказа.

Такой подход соответствует общему принципу production-систем: отказ одной площадки не должен отключать все экземпляры критичного сервиса. В AI-инфраструктуре это касается моделей, эмбеддингов, маршрутизаторов запросов и других компонентов inference-контура.

Как SchedulingConfig меняет размещение Inference Components

SchedulingConfig задаёт правила, по которым планировщик размещает копии Inference Component на доступных ресурсах. Конфигурацию нужно читать как сочетание нескольких параметров: стратегии размещения, числа копий, допустимого дисбаланса и доступной GPU-capacity.

Логика выглядит так: оператор указывает желаемое число копий и требование к их распределению, а планировщик пытается подобрать подходящие ресурсы. Итог зависит от свободной мощности, типа GPU, уже размещённых компонентов и ограничений конкретного endpoint.

PlacementStrategy: SPREAD и распределение по AZ

Стратегия SPREAD направляет планировщик к разнесению копий по доступным доменам отказа. В контексте Multi-AZ это означает стремление распределить копии Inference Component между Availability Zones, если такая схема поддерживается типом ресурсов и текущей конфигурацией.

При двух зонах и четырёх копиях ожидаемая цель может выглядеть как распределение 2+2. При трёх зонах и шести копиях, как 2+2+2. Это примеры целевого баланса, а не гарантия результата для любого endpoint.

SPREAD не создаёт GPU-capacity из воздуха. Если в одной зоне нет подходящего ресурса, планировщик может столкнуться с ожиданием, частичным размещением или менее равномерной схемой, если это допускает заданный дисбаланс. Поэтому статус конфигурации нужно оценивать вместе с фактическим placement и доступностью компонентов.

Какие условия могут помешать равномерному размещению

На результат влияют несколько факторов:

• дефицит GPU нужного типа в одной или нескольких Availability Zones;
• разный объём свободной памяти и вычислительной мощности;
• занятые ресурсы других Inference Components;
• изменение числа копий во время scale-out;
• удаление копий при scale-in;
• ограничения по размеру модели, VRAM и параллельной обработке запросов.

Заданная стратегия показывает намерение оператора. Фактическое состояние нужно проверять после создания endpoint, после изменения нагрузки и после каждого масштабирования. Иначе Multi-AZ может остаться свойством схемы на бумаге.

MaxImbalance: насколько равномерным должно быть размещение

MaxImbalance нужен для управления компромиссом между равномерностью и доступностью ресурсов. Параметр ограничивает допустимую разницу в размещении копий между зонами или другими доменами, которые учитывает планировщик. Точную формулу и допустимые значения нужно сверять с актуальной спецификацией AWS, поскольку они зависят от конкретного API и версии функции.

Как читать MaxImbalance на простом примере

Возьмём условную схему с двумя Availability Zones и четырьмя копиями модели. При строгом требовании баланса целевая раскладка выглядит как 2+2. Если допускается разница в одну копию, планировщик может принять вариант 3+1, когда это помогает быстрее использовать доступную capacity.

Для шести копий в трёх зонах симметричный вариант выглядит как 2+2+2. Более мягкое ограничение может допустить 3+2+1. Такой пример иллюстрирует принцип, но не подтверждает конкретную семантику числового значения MaxImbalance для вашей версии SageMaker.

Проверять нужно не только значение параметра, но и его эффект в реальном окружении: количество копий в каждой зоне, время размещения, ошибки запуска и доступность GPU.

Балансировка против доступности GPU

Малый допустимый дисбаланс повышает требования к capacity. Если одна зона временно не располагает нужным GPU, строгое распределение может задержать запуск новых копий или масштабирование. Более мягкая политика ускоряет размещение, но оставляет большую концентрацию риска.

Выбор зависит от критичности модели:

• для модели, которая обслуживает обязательный пользовательский сценарий, приоритетом может быть межзонная избыточность;
• для второстепенной модели допустим больший дисбаланс ради меньшей стоимости и быстрого scale-out;
• для batch-инференса можно принять более длительное ожидание capacity, если задержка не влияет на пользовательский запрос.

Универсального значения MaxImbalance нет. Его нужно выбирать вместе с RTO, требуемой доступностью, бюджетом и реальной ёмкостью зон.

Как сохранить экономию на GPU при Multi-AZ размещении

SageMaker Inference Components позволяют размещать несколько моделей или компонентов на общих GPU-инстансах. Экономия возникает за счёт более высокой утилизации ресурса: каждой модели не требуется отдельный инстанс, если их требования к памяти, latency и пропускной способности совместимы.

Что именно экономит мульти-модельное размещение

Отдельный GPU-инстанс под каждую небольшую модель часто простаивает. Совместное размещение позволяет разделить вычислительный ресурс между несколькими компонентами, особенно когда их пики нагрузки не совпадают. Это снижает число незагруженных GPU и упрощает управление endpoint.

Цена такой схемы зависит от нескольких параметров:

• объёма VRAM, который занимает каждая модель;
• частоты и длительности пиковых запросов;
• конкуренции компонентов за GPU и CPU;
• требований к latency и throughput;
• числа резервных копий в разных Availability Zones;
• времени загрузки модели после запуска новой копии.

Multi-AZ добавляет ресурсные расходы, потому что резервные копии нужно разместить в нескольких зонах. Inference Components помогают контролировать эти расходы через совместное использование GPU, но не отменяют стоимость дополнительной избыточности.

При выборе железа полезно учитывать не только пиковую производительность GPU, но и фактическую загрузку памяти. Модель может помещаться в VRAM по отдельности, но терять latency при совместной работе с несколькими компонентами.

Цена отказоустойчивости в ресурсах и стоимости

Условно можно сравнить три схемы:

Схема	Распределение	Основной риск
Одна копия	Одна зона	Отказ копии или AZ отключает модель
Несколько копий без политики placement	Распределение не определено заранее	Все копии могут сконцентрироваться в одной зоне
Несколько копий с SPREAD	Копии стремятся разойтись по AZ	Результат зависит от capacity и допустимого дисбаланса

Общие GPU снижают стоимость размещения нескольких моделей, но не делают резервирование бесплатным. Финансовую модель нужно строить по числу копий, типу GPU, уровню загрузки и запасу мощности для восстановления после отказа.

Об особенностях GPU-инфраструктуры и выборе ускорителей для AI-нагрузок можно дополнительно прочитать в разборе производительности моделей на GPU GB10.

Почему для HA-критичных моделей нельзя оставлять CopyCount: 1

CopyCount: 1 означает, что у компонента есть одна активная копия. Она может обслуживать запросы, но физически не может одновременно находиться в двух Availability Zones. При потере зоны система теряет единственный экземпляр модели.

CopyCount: 1, несколько копий и реальная защита от сбоя AZ

Одна копия подходит для разработки, тестов, нерегулярного batch-инференса или сценариев, где восстановление после сбоя допустимо. Для пользовательского сервиса с жёстким требованием доступности она создаёт single point of failure.

Две копии дают возможность разнести компонент по двум зонам, но только при подходящей стратегии placement и наличии capacity. Три копии расширяют варианты распределения в трёхзонной конфигурации, однако само число не подтверждает межзонную избыточность. Проверять нужно фактический placement.

Даже при нескольких копиях остаются отдельные риски:

• одна зона может временно не иметь свободного GPU;
• все копии могут обслуживать пик нагрузки и не оставить запаса;
• после масштабирования распределение может измениться;
• модель может долго загружаться на новый GPU;
• ошибка конфигурации endpoint может затронуть все копии.

Как выбрать CopyCount для критичной модели

Количество копий выбирают по четырём группам параметров:

1. число Availability Zones, которые должны сохранять работоспособность;
2. пиковая нагрузка и требуемый запас throughput;
3. допустимое время восстановления после потери зоны или копии;
4. доступная GPU-capacity и бюджет.

Если сервис должен пережить потерю одной AZ без заметного ухудшения latency, минимум две копии нужно распределить между двумя зонами. При трёхзонной архитектуре требования могут быть выше, если оставшиеся зоны должны выдержать весь трафик. Точное число нужно подтвердить нагрузочным и отказным тестированием.

Масштабирование: почему распределение нужно проверять после scale-out и scale-in

Стартовая конфигурация описывает состояние в момент запуска. При росте нагрузки SageMaker добавляет копии, а при снижении может удалять их. Каждый такой шаг способен изменить баланс между Availability Zones.

Роль ScaleInPolicy: CONSOLIDATION

ScaleInPolicy: CONSOLIDATION следует рассматривать как механизм уплотнения размещения при снижении нагрузки. Когда запросов становится меньше, система может освобождать ресурсы и собирать оставшиеся компоненты на меньшем числе инстансов.

Для мульти-модельного endpoint это помогает сократить простой GPU. Для HA-критичной модели возникает конфликт: консолидация может уменьшить число резервных ресурсов или приблизить копии к одной зоне. Точное поведение политики зависит от реализации функции и параметров SageMaker, поэтому его нужно подтверждать по документации и проверять в тестовой среде.

Политика scale-in не должна автоматически удалять последнюю копию из зоны, которая нужна для отказоустойчивости. Ограничения на минимальное число копий и правила размещения следует проектировать совместно.

Что проверять после изменения количества копий

• фактическое число активных копий;
• Availability Zone каждой копии;
• доступность свободной GPU-capacity;
• latency, ошибки и процент успешных запросов;
• загрузку GPU, VRAM и CPU;
• время запуска новых копий;
• изменение стоимости inference;
• соответствие фактического состояния SchedulingConfig.

Проверять общий статус endpoint недостаточно. Он может быть доступен, пока отдельная критичная модель лишена ожидаемой избыточности.

ODCR и мониторинг: как не потерять отказоустойчивость в эксплуатации

Стратегия placement работает только при наличии подходящей вычислительной ёмкости. Поэтому Multi-AZ конфигурацию нужно связывать с планированием GPU-capacity и наблюдаемостью.

Когда резервирование мощности через ODCR оправдано

ODCR может быть оправдан для предсказуемой критичной нагрузки, когда задержка получения GPU после сбоя неприемлема. Резервирование помогает заранее обеспечить нужный ресурс, но не заменяет PlacementStrategy: SPREAD, контроль CopyCount и проверку фактического распределения.

Перед использованием ODCR нужно оценить:

• какой тип GPU требуется компонентам;
• сколько копий нужно поддерживать в каждой зоне;
• какой запас нужен для scale-out и восстановления;
• как меняется потребление в течение суток;
• оправдывает ли стоимость резервирования риск дефицита capacity.

Резервировать одну общую ёмкость без учёта зон недостаточно. Для Multi-AZ важна доступность подходящего ресурса именно там, где должна работать копия.

Какие сигналы мониторить в SageMaker AI Insights

SageMaker AI Insights и другие средства observability нужно использовать как часть регулярного контроля production AI-системы. Набор доступных метрик и представлений следует сверять с актуальными возможностями сервиса.

Минимальный набор вопросов для мониторинга:

• доступен ли каждый Inference Component;
• как меняются latency и доля ошибок;
• сколько копий активно после scale-out и scale-in;
• как распределена нагрузка между зонами;
• есть ли различия в загрузке GPU и VRAM;
• возникают ли задержки при запуске новых копий;
• как меняется inference cost при росте числа компонентов;
• сохраняется ли ожидаемый уровень reliability после отказа зоны.

Наблюдаемость должна включать failure modes, стоимость, задержку и фактическую доступность. Общая рекомендация для production AI-систем, включая RAG, embeddings и агентные сценарии, остаётся одинаковой: метрики нужно связывать с пользовательским результатом, а не собирать ради самого дашборда.

Итоговая схема проверки Multi-AZ конфигурации

1. Определите, сколько копий нужно модели при штатной и пиковой нагрузке.
2. Задайте PlacementStrategy: SPREAD, если функция и тип ресурсов поддерживают нужное распределение.
3. Выберите MaxImbalance с учётом требований к доступности и реальной capacity.
4. Проверьте, что CopyCount больше единицы для модели, которая должна пережить отказ AZ.
5. Оцените GPU-capacity в каждой зоне и необходимость ODCR.
6. Проверьте фактическое размещение после запуска, scale-out и scale-in.
7. Настройте мониторинг доступности, latency, ошибок, нагрузки GPU и стоимости inference.
8. Проведите нагрузочный и отказной тест, если условия эксплуатации это допускают.

Кейс Salesforce показывает полезную архитектурную идею: Multi-AZ нужно проектировать на уровне конкретного Inference Component, а совместное использование GPU позволяет контролировать цену резервирования. Но конфигурация не даёт автоматической гарантии при дефиците capacity, изменении нагрузки или неверно выбранном числе копий.

Перед публикацией или запуском production-схемы точные значения и ограничения SchedulingConfig, SPREAD, MaxImbalance, ScaleInPolicy: CONSOLIDATION и SageMaker AI Insights нужно сверить с актуальными материалами AWS и первоисточником кейса Salesforce.

Для общего контекста по запуску open-source моделей и AI-инфраструктуре SageMaker пригодится разбор партнёрства Hugging Face и AWS.

Подписаться на канал