Концепция допускает ошибки в передаче данных. Операционный ИИ этого не допускает.

Персонал VB

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

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

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

Производственный трафик выявляет архитектурные недостатки.

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

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

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

Реальная стоимость застоявшихся конвейеров обработки данных и недоиспользования графических процессоров.

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

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

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

Создание готового к производственному использованию уровня доставки данных

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

Чтобы сделать доставку данных первоклассным уровнем, необходимо заложить в нее три свойства:

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

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

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

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

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

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

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

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

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

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

Чем отличается производственный ИИ от вечных пилотов?

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

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

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

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

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

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