F5 повышает надежность доставки данных для ИИ

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

Когда предприятия переносят рабочие нагрузки ИИ из стадии пилотных проектов в продакшн, доставка данных часто становится ключевым фактором, определяющим способность таких систем к надежному масштабированию. Архитектуры «точка-точка», соединяющие хранилище напрямую с вычислениями, отлично работают в условиях демонстрации, но зачастую дают сбой при непрерывном одновременном трафике в рабочей среде. Результатом становятся зависшие конвейеры инференса, задержки в RAG-системах, недоиспользованные графические процессоры (GPU) и нарушения соглашений об уровне обслуживания (SLA), что влечет за собой прямые бизнес-последствия.

«Организации успешно выводят ИИ на операционный уровень тогда, когда их инфраструктура создана с расчетом на реальные сбои, а не только на контролируемые условия», — отмечает Хантер Смит (Hunter Smit), старший менеджер по продуктовому маркетингу в F5.

Производственный трафик обнажает архитектурные уязвимости

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

«Архитектуры «точка-точка», где S3-клиент напрямую соединяется с S3-хранилищем, не обладают устойчивостью», — говорит Пол Пинделл (Paul Pindell), главный архитектор решений по технологическим альянсам в F5. «Если выходит из строя один узел хранения, деградирует весь трафик к этому кластеру, а в некоторых случаях кластер может выйти из строя полностью».

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

Истинная цена простаивающих конвейеров и недоиспользованных GPU

«Руководители предприятий склонны оценивать ИИ-инфраструктуру через призму загрузки графических процессоров, но отличие ИИ от традиционных детерминированных рабочих нагрузок заключается в том, что инфраструктура непрерывно влияет на эти результаты при каждом взаимодействии», — подчеркивает Тану Мутреджа (Tanu Mutreja), старший директор по управлению продуктами в F5. «В средах ИИ инфраструктура перестает быть лишь бэкенд-задачей. С каждой транзакцией она формирует пользовательский опыт, качество, отказоустойчивость и стоимость».

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

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

Создание готового к продакшену уровня доставки данных

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

Превращение доставки данных в первоклассный уровень инфраструктуры требует реализации трех свойств:

Наблюдаемость (Observability) обеспечивает видимость задержек, пропускной способности и состояния потоков в реальном времени.

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

Отказоустойчивость с учетом сбоев (Failure-awareness) закладывает устойчивость к деградированным сетям, троттлингу хранилищ и сбоям в работе сервисов.

В архитектуре, разработанной F5 для Dell ObjectScale, F5 BIG-IP располагается между ObjectScale и ИИ-вычислениями в качестве программируемой точки контроля на границе хранилища.

«Мы сталкивались с ситуациями, когда неправильная конфигурация на уровне ИИ-вычислений фактически устраивала DDoS-атаку на инфраструктуру S3-хранилища», — рассказывает Пинделл. «Конечно, не из злонамеренных побуждений, а скорее в духе «О нет, что же я наделал?», но это все равно привело к выводу хранилища из строя для всей организации».

Размещение BIG-IP в качестве контроллера доставки приложений между слоями хранения и вычислений защищает хранилище с помощью QoS, лимитов скорости и ограничений соединений, поддерживая его устойчивость и работоспособность при таких нагрузках. Тестирование, подтвержденное SecureIQLab, показало, что эта защита не достигается за счет снижения пропускной способности, что имеет критическое значение с точки зрения архитектуры, отмечает Пинделл.

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

Дополнительная сложность гибридного и мультиоблачного ИИ

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

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

Что отличает рабочий ИИ от вечных пилотных проектов

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

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

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

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

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