Уровень данных F5 повышает эффективность графических процессоров для ИИ

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

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

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

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

«Традиционные шаблоны доступа к хранилищам не были рассчитаны на высокопараллельные, пульсирующие многопользовательские рабочие нагрузки ИИ», — отмечает Мэгги Стрингфеллоу (Maggie Stringfellow), вице-президент по управлению продуктами BIG-IP. — «Эффективное перемещение данных для ИИ требует отдельного уровня доставки данных, предназначенного для абстрагирования, оптимизации и защиты потоков данных независимо от систем хранения, поскольку экономика GPU делает неэффективность мгновенно видимой и дорогостоящей».

Почему рабочие нагрузки ИИ перегружают объектное хранилище

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

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

Нагрузка на S3-совместимые системы со стороны рабочих нагрузок ИИ носит многомерный характер и существенно отличается от традиционных паттернов приложений. Здесь дело меньше в чистой пропускной способности и больше в параллелизме, нагрузке на метаданные и факторах веерной рассылки (fan-out). Обучение и дообучение создают особенно сложные шаблоны, такие как массовое параллельное чтение объектов малого и среднего размера. Эти рабочие нагрузки также включают многократные проходы через данные обучения по эпохам и периодические всплески записи контрольных точек.

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

Риски жесткой привязки фреймворков ИИ к хранилищу

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

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

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

«Мы видим, как крупные рабочие нагрузки обучения или дообучения перегружают инфраструктуру хранения, и она падает», — объясняет он. — «В таких масштабах восстановление никогда не измеряется секундами. Минуты, если вам повезет. Обычно — часы. Графические процессоры теперь не получают питания. Они испытывают голод по данным. Эти высокоценные ресурсы все то время, пока система лежит, имеют отрицательную окупаемость инвестиций (ROI)».

Как независимый уровень доставки данных повышает использование GPU и стабильность

Финансовый эффект от внедрения независимого уровня доставки данных выходит за рамки предотвращения катастрофических сбоев.

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

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

Использование программируемой точки контроля между вычислениями и хранилищем

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

«Внедрение уровня доставки между вычислениями и хранилищем помогает определить границы ответственности», — говорит Менгер. — «Вычисления — это исполнение. Хранилище — это долговечность. Доставка — это надежность».

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

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

Решение проблем безопасности при доставке данных ИИ

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

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

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

Заглядывая в будущее, Стрингфеллоу отмечает, что требования к доставке данных будут только расти.

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

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