Salesforce использует элементы управления SageMaker для распределения моделей Agentforce по зонам доступности.

Что случилось

AWS сообщает, что Salesforce развернула модели Agentforce с компонентами вывода SageMaker и использовала новый параметр SchedulingConfig для распределения копий модели по зонам доступности и экземплярам. Salesforce сообщила о восьмикратном сокращении затрат на инфраструктуру за счет совместного размещения нескольких моделей на общих графических процессорах, но поведение размещения по умолчанию не гарантировало двухзонную устойчивость, необходимую для ее производственных моделей.

AWS и Salesforce описывают проблему обслуживания продукции, связанную с Agentforce, основой искусственного интеллекта агентов Salesforce. Компоненты вывода SageMaker позволяют нескольким моделям совместно использовать инфраструктуру на базе графического процессора, что, по словам источника, сократило затраты на инфраструктуру Salesforce в восемь раз. Компромисс заключался в том, что алгоритм размещения SageMaker по умолчанию оценивал каждую операцию развертывания независимо. Таким образом, копии конкретной модели могут быть распределены неравномерно, даже если сама конечная точка использует несколько зон доступности. Этой многозонной конфигурации на уровне конечной точки недостаточно, чтобы гарантировать распределение на уровне модели. Проблема заключалась именно во взаимосвязи между общей инфраструктурой и размещением отдельных экземпляров модели.

Новый элемент управления предоставляется через параметр SchedulingConfig в API CreateInferenceComponent. Его параметр AvailabilityZoneBalance определяет, насколько равномерно копии распределяются между зонами, а PlacementStrategy контролирует размещение внутри каждой зоны. SPREAD распределяет копии по как можно большему количеству экземпляров, чтобы улучшить изоляцию ошибок; BINPACK размещает копии на меньшем количестве экземпляров для улучшения использования. Источник сообщает, что Salesforce выбрала SPREAD из-за своих требований к высокой доступности производства. Эти настройки четко определяют предполагаемое поведение размещения во время развертывания и связывают выбор распределения с преследуемой оперативной целью.

AWS представляет собой двухзонный пример с четырьмя экземплярами и четырьмя копиями модели. При использовании SPREAD и максимальном дисбалансе в одну копию предполагаемый результат — две копии в каждой зоне. Для модели, требующей только две копии, максимальный нулевой дисбаланс нацелен ровно на одну копию на зону. Предполагается, что одни и те же параметры планирования останутся в силе во время горизонтального масштабирования, масштабирования, а также обновлений конечной точки или компонента вывода. Источник также рекомендует использовать стратегию консолидации для долгосрочной очистки после повторяющихся операций масштабирования. Вместе эти детали описывают размещение как постоянную задачу планирования, а не настройку, применяемую только один раз при первоначальном развертывании.

Подробности об источнике: aws.amazon.com ↗

Почему это важно

Развертывание решает практическую проблему обслуживания систем искусственного интеллекта: конечная точка с несколькими зонами все равно может оставить все копии одной модели сосредоточенными в одной зоне или экземпляре. Эта конфигурация дает корпоративным командам явные средства управления для балансировки размещения зон доступности и выбора между изоляцией отказов и более высоким уровнем использования.

Различие между устойчивостью на уровне конечных точек и на уровне модели важно для организаций, использующих множество моделей ИИ в общей инфраструктуре. Конечная точка с несколькими зонами не гарантирует автоматически наличие копии каждой модели в каждой зоне. Если копии модели сконцентрированы, сбой экземпляра или сбой зоны может привести к удалению этой модели, даже если другие рабочие нагрузки на конечной точке останутся доступными. Это означает, что структура широкой зоны доступности может выглядеть устойчивой, оставляя открытой конкретную модель. Поэтому вопрос о размещении должен оцениваться на уровне экземпляров каждой модели.

Функция размещения связывает требования к надежности с явным компромиссом в отношении ресурсов. SPREAD может уменьшить количество копий модели, потерянных в случае сбоя экземпляра, а BINPACK может улучшить использование ускорителя за счет концентрации рабочих нагрузок. Для Salesforce источник представляет этот выбор как способ сохранить экономическую выгоду от хостинга с несколькими моделями графических процессоров, одновременно соблюдая внутреннее требование, согласно которому каждая производственная модель должна иметь поддержку двух зон. Конфигурация не устраняет компромисс; это дает командам возможность напрямую выбирать, как их копии будут занимать доступные экземпляры и зоны.

Сообщаемый результат имеет важное значение для корпоративных операций ИИ, поскольку он переносит высокую доступность из общей цели архитектуры в настройки развертывания, которые можно проверять и управлять. Источник сообщает, что Salesforce добилась соответствия требованиям двух зон для своего модельного парка, сохранила экономию на совместном хостинге, сохранила распределение во время масштабирования и избежала нарушения баланса зон во время обновлений модели. Это претензии со стороны AWS, а не результаты независимой проверки эффективности. В сообщении не уточняется, как вела себя система во время реального сбоя в зоне и были ли одинаковые условия для каждой модели и региона. Таким образом, отчет о реализации полезен для понимания механизма контроля и его заявленного результата, оставляя при этом независимую проверку открытой.

Что посмотреть дальше

Источник не предоставляет независимых измерений времени безотказной работы, результатов испытаний на сбои, данных о задержке или полного учета заявленного снижения затрат. Командам, применяющим этот шаблон, необходимо будет проверить пропускную способность в каждой целевой зоне, отслеживать размещение после масштабирования и определять, соответствует ли размещение с максимальными усилиями их собственным требованиям соответствия.

Емкость остается главным ограничением. AWS рекомендует резервировать мощность по требованию в каждой целевой зоне доступности для регионов с ограниченными зонами, а источник сообщает, что Salesforce предварительно предоставляет зарезервированную мощность графического процессора, чтобы помочь обеспечить сбалансированное размещение. Без достаточной мощности SageMaker может частично развернуть копии на доступных экземплярах, поскольку описанный режим принудительного применения является разрешительным. Это делает эту функцию пригодной для использования в условиях ограничений, но может сделать окончательный дистрибутив менее сбалансированным, чем предполагалось. Следовательно, желаемая конфигурация и фактически достигнутое размещение могут различаться, если требуемая мощность доступна не в каждой целевой зоне.

Операторам необходимо будет следить за тем, сохраняется ли желаемое размещение с течением времени. Источник указывает на метрики SageMaker AI Insights и CloudWatch, охватывающие перекос в зоне доступности, количество копий компонентов вывода по зонам, ребалансировку событий и продолжительности, а также ошибки недостаточной емкости. Он также предупреждает, что критически важный компонент высокой доступности не следует сокращать до одной копии, поскольку одна копия не может охватывать две зоны. Практический вопрос заключается в том, насколько быстро команды обнаруживают и устраняют дисбаланс, прежде чем он станет проблемой доступности. Мониторинг должен охватывать как количество копий, так и их распространение, особенно если масштабирование и обновления меняют развертывание.

Важные подробности от источника остаются неизвестными. В нем не указаны задействованные географические регионы, количество охваченных производственных конечных точек или моделей, стоимость зарезервированной мощности, влияние на задержку и пропускную способность или целевой показатель доступности, которого пыталась достичь компания Salesforce. Он также не обеспечивает сравнительное тестирование отказов по сравнению с алгоритмом по умолчанию. Поэтому корпоративные команды должны рассматривать эту публикацию как образец реализации и результат, сообщаемый заказчиком, а затем проверять мощность, поведение при отказе, мониторинг и общую стоимость в своих собственных средах. Эти проверки необходимы, чтобы определить, применим ли заявленный баланс между устойчивостью и использованием к их собственным рабочим нагрузкам и условиям эксплуатации.

Сопутствующие руководства и викторины