Агенты искусственного интеллекта разрушают стереотипы пакетной обработки данных, лежащие в основе объектного хранения.

Персонал VB

Представлено компанией F5

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

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

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

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

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

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

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

Данные о пилотном трафике ничего не предсказывают

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

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

Агенты не оказывают обратного давления

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

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

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

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

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

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

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

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

Знание протокола обеспечивает работоспособность контрольной точки.

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

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

Фуад Шмайни, глобальный архитектор решений в области ИИ и безопасности в F5, говорит, что увеличение пропускной способности не затрагивает базовую архитектуру. «Покупка дополнительных мощностей оставляет эти проблемы нетронутыми. Увеличение пропускной способности никак не влияет на задержку в хвосте распределения при импульсной нагрузке на небольшие объекты, а дополнительные узлы за одним недифференцированным путем расширяют область коррелированных отказов».

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

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

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

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

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

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

Источник: venturebeat.com