Нагрузки ИИ создают нагрузку на корпоративные хранилища данных

При поддержке F5

Обучение моделей — это пакетная задача, а агентное извлечение данных (agentic retrieval) — транзакционная. К сожалению, большинство предприятий в настоящее время запускают транзакционные рабочие нагрузки ИИ на объектном хранилище, которое они проектировали и эксплуатировали для пакетных задач. Это несоответствие становится причиной значительного числа сбоев в продакшене по мере того, как ИИ-агенты и RAG (генерация, дополненная поиском) выходят за рамки пилотных сред.

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

«Обучение сообщает вам о своих потребностях перед началом работы, но агентное извлечение принимает решения во время выполнения, поэтому я не знаю, о чем они спросят, когда они спросят и в каком объеме», — говорит Марк Менгер (Mark Menger), архитектор решений по технологическим альянсам в F5. — Никто не проектирует систему под такие сценарии так же, как их проектировали для пакетной обработки».

Агенты переворачивают традиционную модель доступа

Обучение считывает крупные объекты последовательно из известного кластера графических процессоров с предварительно подготовленным рабочим набором, выполняя по одной задаче в системе за раз. Агентное извлечение меняет практически каждый из этих атрибутов. Трафик поступает в виде больших объемов запросов GET для мелких объектов вперемешку с вызовами PUT, HEAD и LIST, которые извлекают метаданные. Совокупность клиентов характеризуется высокой кардинальностью, поскольку агенты порождают других агентов, а несколько тенантов по умолчанию делят один путь. Клиент, который принимает решение о том, что запросить, является вероятностной системой, реагирующей на входные данные, которые предприятие не контролирует, в результате чего уровень приложения перестает быть достаточным фильтром для того, что попадает к данным.

Параллелизм затем усиливает задержку, присущую каждому из этих мелких запросов. По словам Менгера, это можно сравнить с оживленным холлом банка.

«Если в холле никого нет и один человек подходит к одному операционисту для проведения очень крупной транзакции, система остается отзывчивой, — говорит он. — В случае с агентами у вас есть много людей в очереди, ограниченное число операционистов, и эти операционисты работают только с определенной скоростью. Задержка перестает быть проявлением производительности системы и становится проявлением размера этой очереди».

Пилотный трафик ничего не прогнозирует

Веерное распространение (fan-out) стимулирует рост объема: один промпт превращается в несколько запросов на извлечение, эти запросы запускают вызовы инструментов, а вызовы инструментов порождают новые запросы на извлечение, поэтому соотношение запросов к людям не имеет стабильного значения, а пилотные среды теряют свою предсказательную способность. Потенциальное число агентов и субагентов, которые они вызывают, количество инструментов, вызываемых всеми этими агентами, количество корпоративных систем, задействуемых этими инструментами, и количество запросов, которые они могут сделать, просто поражает воображение.

«Пол-дюжины агентов в лабораторной среде работают без происшествий, — говорит Менгер. — Но если вы очень целенаправленно не задумываетесь о том, как будет выглядеть масштабирование на второй день, вы не увидите этого в ходе пилотного проекта. Все идет хорошо до определенного момента, а когда он наступает, ситуация становится критической».

Агенты не создают обратного давления (backpressure)

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

«Если бы это был всего один клиент, вежливо повторяющий запрос каждые 10, 15 или 20 секунд, это одно, — говорит Менгер. — Но если у вас есть 1000 или 10 000 одновременных клиентов, которые одновременно выполняют повторные попытки, вы перегружаете систему именно тогда, когда она сообщила вам, что ей нужно свободное пространство».

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

Как эти сценарии сбоев выглядят в продакшене

Компания F5 наблюдала эту закономерность у глобального производителя электроники в Азиатско-Тихоокеанском регионе, где RAG-приложения и агенты извлекают документы, изображения и другие входные данные из кластеров хранения для поддержки принятия решений на производственной линии. Устройства IoT одновременно передают телеметрию в эти кластеры, в то время как ИИ-потребители активно считывают данные из них, и уровень доставки данных ИИ должен определять, какой поток получает приоритет в условиях нагрузки.

F5 воспроизвела оба сценария сбоев в своей лаборатории на 32-узловом корпоративном кластере объектного хранения. Подключив клиентов S3 непосредственно к кластеру, команда создала некорректный трафик и проследила за развитием каскада сбоев.

«Все началось с одного или двух узлов, а затем распространилось по всей системе, — говорит Менгер. — Внезапно сервис просто перестал отвечать. Состояние перешло от „я испытываю трудности“ к полному отсутствию ответа от кого-либо».

Размещение контроллера доставки приложений (в данном случае BIG-IP от F5) между клиентами и кластером изменило оба сценария. Контроллер перехватил некорректный трафик, для корректных клиентов не было зафиксировано измеримого влияния, а кластер остался работоспособным. Когда команда отключила два узла, клиенты, подключенные напрямую к кластеру, столкнулись с пиками ошибок и полными сбоями, в то время как контроллер перенаправил трафик в обход вышедших из строя узлов. Трафик, проходивший через BIG-IP, отклонялся в пределах шести процентов от базового уровня при прямом подключении, что опровергает стандартное возражение о том, что добавление точки контроля между клиентами и хранилищем замедляет все процессы.

Понимание протоколов обеспечивает работу точки контроля

Доставка данных для ИИ создает интеллектуальный уровень трафика на границе между вычислительными мощностями и хранилищем, и его полезность основана на чтении семантики хранилища, а не пакетов и портов. Контроллер, который распознает бакеты, методы и тенанты, может осуществлять маршрутизацию к определенным кластерам или узлам, применять ограничения и квоты для каждого тенанта в едином месте, а также ограничивать скорость по операциям. Вызовы LIST показывают, почему такая детализация имеет значение. Клиенты, одновременно обновляющие свое представление о кластере, могут снизить производительность кластера примерно на 75%, согласно данным технологического партнера F5. Но существует грань между таким поведением и традиционной балансировкой нагрузки.

«Контроллер доставки приложений, осуществляющий двунаправленное управление радиусом поражения (blast radius control), уделяет пристальное внимание отзывчивости и работоспособности каждого узла, проактивно ограничивает трафик к нездоровым узлам, чтобы дать им передышку, и направляет трафик на здоровые узлы, благодаря чему у проблемных узлов повышается вероятность восстановления», — объясняет Менгер.

Фуад Хмайни (Fouad Chmainy), глобальный архитектор решений по ИИ и безопасности в F5, отмечает, что добавление емкости оставляет лежащую в основе архитектуру без изменений. Покупки емкости оставляют эти проблемы нерешенными. Большая пропускная способность никак не помогает справиться с хвостом задержек (tail latency) при нагрузке в виде пакетов мелких объектов, а дополнительные узлы за единым недифференцированным путем увеличивают область коррелированных сбоев.

Почему увеличение емкости не может решить архитектурную проблему

Добавление емкости также никак не помогает различать рабочие нагрузки. Оно не способно отделить легитимный запрос на извлечение данных от зациклившегося процесса или помешать одному тенанту потреблять больше своей доли. Решение этих проблем требует архитектурного подхода, добавляет Менгер.

«Предприятиям необходим устойчивый и безопасный парадный вход для хранения данных, — объясняет Хмайни. — В то время как раньше перед хранилищем обычно устанавливался стандартный программный балансировщик нагрузки, все больше организаций будут видеть долгосрочную ценность в доступности, отказоустойчивости и безопасности этих данных при правильном архитектурном проектировании».

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

«Ваша способность тратить деньги не обязательно равна вашей способности создать хорошо спроектированное решение, — говорит Хмайни. — Если предположить, что я добьюсь огромного успеха, как выглядит успех в масштабах ИИ? Он выглядит так, как ничего из того, что вы видели раньше. Подключите это ко всем своим корпоративным системам без средств контроля радиуса поражения, и вы получите потенциал серьезно подорвать свой бизнес».

Спонсорские статьи — это контент, подготовленный компанией, которая либо оплачивает публикацию, либо имеет деловые отношения с VentureBeat, и такие материалы всегда четко отмечены. Для получения дополнительной информации обращайтесь по адресу sales@venturebeat.com.