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

Персонал VB

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

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

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

Показатели разрыва в производстве не демонстрируют

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

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

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

«Было особенно заметно, как быстро падает пропускная способность S3 при появлении задержки», — говорит Пинделл. «Даже небольшая задержка существенно снижает производительность, а по мере увеличения задержки на больших расстояниях ухудшение становится очень значительным».

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

Стоимость ненадежных путей передачи данных

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

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

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

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

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

Рассмотрение границы хранилища как контрольной точки.

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

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

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

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

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

Управление в распределенных средах

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

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

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

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

Путь от хранилища к вычислительным ресурсам как управляемая точка управления.

Для решения этих проблем корпоративным командам необходимо перестать рассматривать путь от хранилища к вычислительным ресурсам как прямое соединение и начать рассматривать его как управляемую точку управления, говорит Смит. Независимая проверка F5 BIG-IP в развертываниях хранилищ, проведенная SecureIQLab, подтвердила, что такой подход обеспечивает отказоустойчивость без потери пропускной способности.

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

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

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