VMware Cloud Foundation спонсировала этот пост.
Uber, один из первых сервисов заказа такси, разработал распределенную инфраструктуру еще до того, как большинство людей даже подумали о ней для своего предприятия. До перехода на Kubernetes три года назад он управлял Mesos.
Сейчас компания переходит от локального использования к мультиоблаку, что имеет свои плюсы и минусы, поскольку Uber пытается оптимизировать использование графических процессоров несколькими облачными провайдерами, совмещать рабочие нагрузки и создавать сплоченную конвергентную инфраструктуру.
В презентации на совместном мероприятии AI Day на KubeCon + CloudNativeCon North America в Атланте в этом месяце Эндрю Люнг, старший инженер Uber, предложил взглянуть на то, каково это для компании, которая выполняет рабочие нагрузки искусственного интеллекта, перейти от локального подхода к мультиоблачному подходу.
История Uber показывает разрыв между данными и вычислениями в корпоративных архитектурах, где взаимозаменяемость графических процессоров является основной проблемой. То, как компании адаптируются к использованию моделей ИИ, будет зависеть от вариантов их использования и от того, каких облачных провайдеров они используют. Для Uber теперь это означает управление несколькими поставщиками облачных услуг для оптимизации рабочих нагрузок, что создает свои собственные компромиссы.
Проблемы разделения данных и вычислений
По словам Люнга, Uber использует прогнозные модели с 2018 года. Теперь компания использует модели искусственного интеллекта на своем предприятии для определения примерного времени прибытия автомобиля, ценообразования, обнаружения мошенничества и рейтинговой ленты Uber Eats. Сейчас компания использует большие языковые модели (LLM) для пользовательских и внутренних инструментов. Компания начала использовать приложения искусственного интеллекта для торговых витрин и агентские системы для внутренних рабочих процессов.
Uber использует поставщиков облачных услуг для разных случаев использования, но разделение данных и вычислений повлияло на его внутреннюю инфраструктуру. То, как их команды собрали свои стеки Kubernetes, отражает то, как их данные и вычисления разделены, что позволяет им оптимизировать работу для каждого облака, но усложняет построение конвергентной инфраструктуры.
По словам Люна, инженерные группы обслуживают озеро данных, работающее у одного облачного провайдера. Они используют отдельного облачного провайдера для вывода и других микросервисов. Следующий шаг: преодолеть разрыв между облаками, которые они используют.
Это само по себе создает проблему, когда это имеет бизнес-целесообразный характер, особенно в отношении графических процессоров и их мощности. Даже для Uber графические процессоры немногочисленны и дороги. При распределении по нескольким облачным сервисам становится сложно использовать весь потенциал графических процессоров.
Работа с графическими процессорами не совсем безопасна для облачных вычислений по сравнению с управлением центральными процессорами, добавил Люн, где переносимость более проста.
«И поэтому нам в конечном итоге приходится думать о вариантах использования, которые могут либо полностью находиться в пределах одного поставщика облачных услуг, чтобы я мог объединить обучение и обслуживание, либо мне нужно думать о случаях использования, в которых имеет смысл фактически передавать данные от одного поставщика к другому, чтобы облегчить возможность использования этих вычислений», — сказал Люнг.
«Это не делает процесс настолько гладким, каким мог бы быть, и вам нужно целенаправленно думать о том, какие рабочие нагрузки вы собираетесь объединить».
А что касается емкости? Разрозненность и чрезмерная индексация представляют собой собственный набор проблем.
«В итоге мы получили инфраструктуру Kubernetes, ориентированную на пакетную обработку, и инфраструктуру Kubernetes, ориентированную на микросервисы», — сказал Люнг. «Различие заключалось в том, что оборудование было разделено на уровне кластера, поэтому у нас были выделенные кластеры графических процессоров, которые просто обслуживали рабочие нагрузки графических процессоров, и несколько кластеров на базе ЦП, обслуживающих рабочие нагрузки ЦП.
«Но это привело к разрознению фактической мощности и в конечном итоге привело к своего рода чрезмерной индексации кластера Kubernetes как абстракции для оборудования, вместо того, чтобы использовать многое из того, что мы можем сделать внутри самого Kubernetes».
Накладные расходы на аварийное восстановление
Аварийное восстановление требует больше накладных расходов при выполнении рабочих нагрузок ИИ, сказал Леунг в ответ Мадхури Йечури, генеральному директору Elotl, который взял интервью у Люнга на совместном заседании AI Day. Опять же, в игру вступает проблема использования графических процессоров. Шаблоны с процессорами не применяются.
«Это становится все более сложным для инфраструктуры графических процессоров, учитывая ее стоимость и дефицит», — сказал Люнг. «Это гораздо труднее смириться, когда вы видите, сколько дополнительных накладных расходов вам нужно нести для графического процессора, а также учитывая тот факт, что рабочие нагрузки графического процессора не так взаимозаменяемы, как рабочие нагрузки процессора, где я не могу сейчас так же легко динамически упаковать восемь рабочих нагрузок в один графический процессор, тогда как я мог бы просто втиснуть все в один процессор».
Отказоустойчивость также проблематична. Вы не можете просто перемещать рабочие нагрузки графического процессора, как рабочие нагрузки процессора.
«Эта штука оптимизирована для этого конкретного оборудования, с этой конкретной конфигурацией», — сказал Люн. «Если я выполняю аварийное переключение, я не обязательно смогу просто на лету переместить его в другую аппаратную конфигурацию».
Будущее агентских рабочих процессов
Агентские рабочие процессы для Uber — это другое дело. Компания строит и совершенствует существующие модели посредством нескольких инициатив по разработке агентных систем для своих внутренних инструментов и обеспечению поддержки на основе LLM во всех внутренних системах. Но он по-прежнему представляет собой меньшую часть использования графического процессора.
«Но по мере того, как мы увеличиваем инвестиции там, они могут стать более масштабными», — сказал Люнг. «Например, прогнозные модели, которые мы обучали, вряд ли удвоятся в размерах, потому что они обычно растут вместе с ростом бизнеса».
По его словам, может наступить день, когда Uber разблокирует какой-то агентный рабочий процесс и внедрит его повсюду, что будет означать значительное увеличение того, что им нужно поддерживать с помощью графических процессоров.
Но как насчет использования? Этот вопрос рассматривает Uber.
«Многие наши инвестиции в такого рода агентские рабочие процессы часто носят экспериментальный характер, но все же требуют нетривиального воздействия», — сказал Люнг. «И, будучи экспериментальным продуктом, они не обязательно находятся в производстве. Поэтому они не принимают постоянные, постоянно включенные, большие объемы трафика, что заставляет сомневаться в том, действительно ли в конечном итоге выделенные для этой штуки графические процессоры являются их лучшим использованием».
Uber использует Рэя почти исключительно для обучения. Ray — это единая платформа для масштабирования приложений AI и Python. Инфраструктура работает через их обычную пакетную инфраструктуру, которая также запускает Spark и другие внутренние рабочие нагрузки пакетной обработки.
Типичный рабочий процесс ИИ будет состоять из нескольких этапов предварительной обработки данных и задач, подобных ETL. Они могли бы работать на Spark, если бы ориентировались на ETL, а большая часть обучающих нагрузок выполнялась бы через Ray. Nvidia Triton обеспечивает поддержку прогнозных моделей по мере роста использования vLLM для сценариев использования LLM. Модели оптимизируются с помощью TensorRT для конкретного оборудования, а затем запускаются в среде выполнения ONNX.
Нерешенная проблема: сделать графические процессоры более взаимозаменяемыми
По словам Люнга, то, как Uber делает графические процессоры более взаимозаменяемыми, начинается с решения проблемы их кластеров. Для Uber повышение взаимозаменяемости графических процессоров остается нерешенной проблемой.
«Различные типы графических процессоров с разными конфигурациями памяти и архитектурами не могут полностью заменить друг друга», — сказал Люнг. «Сегодня, учитывая то, как у нас настроены кластеры, кластер является границей. И поэтому мы отходим от кластера как от своего рода отдельного хранилища, чтобы помочь сделать его более взаимозаменяемым в качестве первого шага».
Команды Uber запускали аутентификацию и другие службы на малоиспользуемых графических процессорах. Но перенос этих сервисов в кластеры ЦП позволил повысить производительность и высвободить ресурсы графического процессора.
Проблемы с графическими процессорами усложняют наблюдаемость. Uber использует Nvidia, но также рассматривает возможность оборудования AMD. У каждого провайдера разные показатели.
Адаптация к новым метрикам
Раннее использование ИИ привело к накоплению технического долга перед Uber. Его команды обновили свой состав, выровняли и модернизировали. Недавно они перенесли свои старые показатели графического процессора на основе Cadvisor, который не поддерживал новые модели.
Люнг сказал, что инженерам Uber пришлось адаптироваться к графическому процессору и различиям в показателях.
«Произошло то, что мы рекламировали эти низкоуровневые метрики, на основе которых другие команды начали строить свои информационные панели, метрики и системы», — сказал Люнг. «И затем, когда мы думаем о том, окей, мы хотим перенести это в другой набор показателей. Ну, вся компания привязана к этому небольшому набору показателей».
Они изучают возможность создания собственного API.
«В конечном итоге вы получите смесь множества различных показателей и нюансов относительно того, что каждый из них означает и как команды должны его понимать, когда они пытаются думать о высокоуровневом использовании, экономической эффективности или использовании памяти», — сказал Люнг.
«И поэтому мы пытаемся создать метрики почти как API, где у нас есть конкретные метрики платформы, которые мы раскрываем, которые мы затем потенциально можем получить из множества метрик, специфичных для конкретного поставщика. Это не требует от пользователя столь глубокого погружения в метрики модели какого-либо конкретного поставщика».
VMware Cloud Foundation — это частная облачная платформа со встроенной средой выполнения Kubernetes и доступом самообслуживания для запуска приложений, созданных как на виртуальных машинах, так и на контейнерах. Упростите инфраструктуру, сократите затраты и сложность, а также повысьте эффективность — одна платформа, одна операционная модель для всех рабочих нагрузок. Узнайте больше Последние новости от VMware Cloud Foundation ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной новости. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Алекс Уильямс — основатель и издатель The New Stack. Он давний технологический журналист, работавший в TechCrunch, SiliconAngle и в компании, которая сейчас известна как ReadWrite. Алекс работает журналистом с конца 1980-х годов, начиная с… Читать далее от Алекса Уильямса
