Эксплуатация распределенных систем инференса в масштабе — Нишант Гупта и Наман Ахуджа, Meta
AAI Engineer
Computing/SoftwareInternet Technology
Transcript
00:00:00Всем доброе утро. Добро пожаловать на первый доклад Influence Talk в заключительный день AI Engineering
00:00:17World Fair. Меня зовут Нишан Гупта, и сегодня со мной мой коллега Наман Ахуджа.
00:00:23Мы работаем над инфраструктурой эффективности, обучения и инференса в Meta.
00:00:27Сегодня мы поговорим о том, как управлять распределёнными системами инференса в больших масштабах.
00:00:32Как мы знаем, инференс — это уже не просто исследовательский артефакт, встроенный в продукт.
00:00:37Это фундаментальная нагрузка гипермасштабируемой инфраструктуры, которая растёт огромными темпами.
00:00:43Трафик инференса уже опережает крупнейшие микросервисы в мире,
00:00:47а темпы его роста — самые высокие среди всех рабочих нагрузок, что мы видели.
00:00:54Давайте вернёмся примерно в 2008 год и попытаемся сравнить эру ИИ с эрой облачных технологий.
00:01:00Примерно в 2008 году облако начиналось с виртуальных машин.
00:01:05Самой интересной инженерной задачей была виртуализация.
00:01:07Затем со временем ценность сместилась выше по стеку, к планировщикам вроде Borg, Kubernetes, Mesos.
00:01:14Затем к Service Mesh, автомасштабированию и различным платформам, построенным поверх них.
00:01:18Именно слой оркестрации аккумулировал основную ценность и сложность.
00:01:24ИИ движется по той же траектории, только всё сжалось до нескольких лет вместо десятилетия.
00:01:30Мы начали с простых моделей, работающих на GPU.
00:01:33Затем мы увидели эволюцию фреймворков для обслуживания моделей, таких как vLLM, TorchServe, Triton, а сейчас в реальном времени наблюдаем появление слоя оркестрации, который решает сложные задачи маршрутизации, управления KV-кэшем, разделения prefill/decode и мультиплексирования моделей.
00:01:51На следующем этапе эры ИИ дело не только в лучших моделях, ядрах или оптимизациях.
00:01:57Дело во всей экосистеме.
00:01:58Дело в Control Plane и оркестрации, и именно на этом мы сосредоточимся в данном докладе.
00:02:06Итак, давайте немного поговорим о взрывном росте агентных запросов.
00:02:09В классическом веб-обслуживании до появления ИИ-инференса производительность масштабировалась примерно линейно с числом пользователей, в зависимости от типа нагрузки.
00:02:17Вдвое больше пользователей — почти вдвое больше QPS, вдвое больше инфраструктурного парка (без оптимизаций), а планирование ресурсов было простым расчётом в таблице.
00:02:28В новом агентном обслуживании мощности масштабируются как количество пользователей × количество вызовов на пользователя × количество токенов, что варьируется от модели, оптимизаций и используемого оборудования.
00:02:40У чат-бота может быть один вызов модели за реплику, у копайлотов это число растёт до 10–20, у исследовательских агентов — до 50, а у автономных систем без участия человека речь идёт уже о тысячах вызовов.
00:02:54Главный вывод: нельзя планировать ресурсы для агентов так же, как мы делали это для микросервисов.
00:03:00Нам нужно думать об эластичности и внедрять планирование и контроль допуска с учётом специфики нагрузки.
00:03:08Теперь давайте подробнее разберём плюсы, минусы и различия между традиционным обслуживанием микросервисов и современным ИИ-инференсом по ключевым направлениям.
00:03:19Форма запроса.
00:03:20Микросервисы предполагают короткие однотипные запросы, тогда как запросы к LLM могут варьироваться от 50 до 100 000 токенов, с огромной разницей в вычислительном профиле между этапами prefill и decode.
00:03:33Пакетная обработка: классические стеки микросервисов делали батчинг в основном на уровне балансировщика, если вообще делали.
00:03:40Однако для LLM требуется непрерывный батчинг в реальном времени, иначе пропускная способность падает на порядок и более.
00:03:48Состояние.
00:03:49Большинство классических микросервисов не сохраняли состояние (если не брать уровень хранения данных).
00:03:54При этом инференс LLM требует огромного состояния для каждого запроса — KV-кэша, который очень дорого создавать и ещё дороже терять.
00:04:02Единицы масштабирования.
00:04:03Единицы масштабирования.
00:04:05Традиционные микросервисы мы могли запускать на дешёвых CPU в подах.
00:04:11Но для современного инференса нужны GPU, которые в 100 раз дороже, закупаются в 10 раз дольше, и их нельзя выделять с запасом бездумно.
00:04:20Иначе это приведёт к колоссальным убыткам.
00:04:23Характер сбоев.
00:04:25В традиционных микросервисах при падении хоста или пода мы могли просто перезапустить его.
00:04:34И при необходимости восстановить состояние.
00:04:36Однако при инференсе моделей переход от холодного старта к горячему занимает огромное время.
00:04:42Если GPU сбоит посреди генерации (decode), могут потеряться тысячи токенов, что вызовет рост очередей.
00:04:50Главный вывод: узкое место — это не просто модель.
00:04:53Это сама оркестрация.
00:04:58Как видно из этих скрытых решений за промптом, при вызове агентного приложения происходит целая серия незаметных шагов.
00:05:06Нужно пройти аутентификацию.
00:05:07Выбрать модель под тип запроса.
00:05:09Определить регион для обработки.
00:05:11Выполнить контроль допуска.
00:05:12Проверить наличие в кэше.
00:05:14Запустить вычисления на GPU.
00:05:17Сформировать батч.
00:05:18И сделать ещё целую кучу действий.
00:05:19Как мы видим, из всех этих шагов непосредственно модели касается только один — prefill/decode.
00:05:25Независимо от того, используется ли дезагрегированный инференс или нет.
00:05:29Остальные шаги завязаны на инфраструктуру.
00:05:31Интеллект может быть в модели, но экономика, надёжность и пользовательский опыт зависят от инфраструктуры.
00:05:38Именно поэтому платформенные команды во многих компаниях оказывают на качество и успех продукта гораздо больше влияния, чем раньше.
00:05:50Большинство из присутствующих в этом зале обладают глубокой экспертизой на одном, двух или трёх уровнях.
00:05:54Кто-то отвечает за ядра или их оптимизацию.
00:05:57Кто-то за маршрутизацию или сам продукт.
00:05:59Кто-то управляет GPU-инфраструктурой или кластером.
00:06:03Но лишь немногие работали со всем стеком или проектировали его сквозным образом.
00:06:08Как видите, сами по себе эти уровни не новы.
00:06:11Они существуют уже 20 лет или дольше.
00:06:13Новым является их сочетание и плотная взаимосвязь.
00:06:18Решение на уровне маршрутизации меняет процент попадания в кэш на уровне модели, что меняет состав батча, загрузку GPU и, в свою очередь, решение об автомасштабировании.
00:06:32Всё тесно связано между собой.
00:06:33Когда возникает просадка в инференсе, недостаточно понимать только то, что произошло на уровне кэширования или контроля допуска.
00:06:41Нужно смотреть на стек целиком сверху вниз.
00:06:43И зафиксировав проблему, крайне важно определить, на каком именно уровне узкое место, чтобы правильно инвестировать ресурсы.
00:06:54Давайте подробнее рассмотрим путь промпта: будь то генерация изображения, исследовательская задача или сложная мультиагентная оркестрация, процесс включает примерно следующие этапы.
00:07:08Промпт поступает на шлюз (gateway).
00:07:10Затем переходит к роутеру, где проверяется кэш, если подобный запрос уже встречался.
00:07:17Далее запрос передаётся планировщикам, определяющим, на каком GPU-кластере и оборудовании его выполнить.
00:07:22Это могут быть чипы NVIDIA, AMD или собственные ускорители, отправляющие задачу в соответствующий среда выполнения (vLLM, SGLang и т. д.).
00:07:30После этого ответ отдаётся пользователю потоком согласно метрикам SLO (время до первого токена и задержка между токенами) с соблюдением нужной пропускной способности.
00:07:41Как видно, инференс работает подобно распределённой транзакции.
00:07:45Каждая стрелка на этой схеме — сетевой перенос (hop).
00:07:47На каждом из них возможны повторные попытки.
00:07:50Превышения таймаута.
00:07:51Фолбэки.
00:07:53И даже фатальные сбои.
00:07:54И для каждого из этих участков есть свои SLO, при этом данные передаются потоком обратно пользователю.
00:08:00Если происходит сбой, обработать частичные ошибки намного сложнее, чем при обычном RPC-вызове.
00:08:06Представьте ситуацию: пользователю уже отправлено 200 токенов, и вдруг GPU-хост отключается из-за планового или непланового
00:08:15техобслуживания.
00:08:16Нельзя просто сделать повторную попытку.
00:08:17Нужен целостный подход.
00:08:19Вот почему нельзя закладывать надёжность только на крайних узлах (at the edge).
00:08:23Она должна быть свойством Control Plane, ведь именно Control Plane видит весь рабочий процесс.
00:08:31Теперь поговорим о планировщиках и некоторых оптимизациях.
00:08:37Для традиционных микросервисов упаковывание ресурсов (bin packing) оценивалось по трём-четырём измерениям.
00:08:43Это могли быть CPU, память или 4 домена отказоустойчивости в зависимости от того, используете ли вы AWS или собственное облако.
00:08:52Для инференса планировщик должен учитывать как минимум 7 осей при распределении конкретного запроса.
00:08:59Он должен учитывать тип GPU.
00:09:00В вашем кластере может быть множество разнородных карт: H100, B200 с разной топологией сети.
00:09:09Он должен знать о запасе HBM и состоянии KV-кэша.
00:09:13Веса моделей: загружены ли они, разогреты ли, или требуется холодный старт.
00:09:19Планировщик должен учитывать приоритет арендатора (tenant).
00:09:21В мультиарендном кластере может работать множество клиентов с разными профилями SLO.
00:09:27Мы также должны знать контекст рабочего процесса.
00:09:30Находимся ли мы на третьем шаге рассуждений, потратившем $X, или в начале процесса, который можно прервать при перегрузке?
00:09:39Нужно учитывать бюджет задержки в зависимости от типа создаваемого агентного приложения.
00:09:44Это подводит нас к необходимости внедрения планирования с учётом агентной логики.
00:09:49Нужно размещать задачу там, где она выполнится быстрее и дешевле всего, а не просто отправлять на случайный GPU.
00:09:58Конкретный пример: планировщик должен понимать, что запрос R находится на третьем этапе цепочки из пяти шагов,
00:10:05и на шагах 1 и 2 уже потрачено X + Y долларов.
00:10:09При сбое на третьем этапе весь процесс прервётся, а вычислительные ресурсы будут сброшены впустую.
00:10:14Вот почему оркестрация с учётом рабочих процессов чрезвычайно важна —
00:10:18она меняет решения по контролю допуска, приоритетам и логике повторных попыток.
00:10:25Теперь поговорим об оптимизациях.
00:10:27Я не буду углубляться в детали всех существующих видов оптимизации.
00:10:29На эту тему есть много исследований, но я хочу поделиться фреймворком,
00:10:34который сам люблю использовать: его можно представить в виде четырёх квадрантов.
00:10:40Первое: можно ли избежать работы?
00:10:42То есть пропустить её полностью за счёт префиксного, семантического кэширования или кэширования ответов?
00:10:48Второе: можно ли разделить работу?
00:10:51Могут ли несколько запросов использовать вычисления совместно через батчинг?
00:10:54Сюда входят непрерывный батчинг, prefill/decode, chunked prefill, спекулятивный декодинг.
00:10:59Третье: можно ли перенаправить работу?
00:11:01Можем ли мы перенаправить её на более дешевую модель или ближе к пользователю?
00:11:05В основном за счет маршрутизации: можно ли направить запрос к меньшей модели, в более дешевый регион или применить иные методы?
00:11:12И наконец, можем ли мы отложить работу?
00:11:13Можем ли мы подождать лучшего момента с помощью контроля допуска и очередей, что требует понимания классов приоритета этих запросов и внедрения планирования с учетом дедлайнов?
00:11:25Этот фреймворк очень эффективен, поскольку он применим к самым разным стекам.
00:11:29Возможно, вы используете VLM, SGLang или TensorRT, но любая техника вписывается в один из этих четырех квадрантов.
00:11:35Задумываясь об оптимизации нашей модели, мы должны сопоставлять и сравнивать её с предыдущими методами,
00:11:41чтобы понять, как они сочетаются друг с другом.
00:11:47Когда мы думаем о масштабировании, важно учитывать не только производительность модели.
00:11:51Мы также должны брать в расчет расходы и экономику.
00:11:54Здесь крайне важно понимать, какую именно метрику мы пытаемся оптимизировать.
00:11:58Потому что затраты — это не только стоимость GPU или модели.
00:12:02Это стоимость всех этих параметров, повторных попыток, хранения, сбоев, сети и, конечно, операционные расходы на разработку и прочее.
00:12:09Важно понимать, каков ключевой показатель эффективности вашего продукта, который принесет пользу пользователям.
00:12:17Поэтому недостаточно оптимизировать только стоимость токена или стоимость запроса.
00:12:22Нам нужно оптимизировать стоимость успешной задачи, ведь именно это действительно важно для пользователей.
00:12:26И если вам удастся оптимизировать этот показатель, итоговая стоимость продукта снизится, а пользователи будут намного счастливее.
00:12:36Теперь поговорим о надежности, немного о том, что нужно для предотвращения каскадных сбоев.
00:12:43История сбоя — это не просто вытеснение или отказ GPU.
00:12:46Самое интересное — это последующая петля обратной связи.
00:12:49Производительность GPU может падать, задержка растет, клиент совершает повторные попытки, глубина очереди увеличивается, исправные GPU перегружаются, что вызывает новые повторы и полноценный сбой всего региона.
00:13:02Это классический каскадный сбой, но с особенностью генеративных приложений — KV-кэшем.
00:13:09Мы не можем просто так перезапуститься или перенаправить трафик на другой кластер.
00:13:13Холодный пул должен прогреться, прежде чем сможет принять трафик, а пока горячий пул вынужден брать все запросы на себя.
00:13:20Вот почему так важно продуманно проектировать разрыватели циклов.
00:13:24Автоматические выключатели на уровне маршрутизации, контроль допуска, а также вместо простая очередь — сброс нагрузки, привязанный к глубине очереди, а не только к загрузке CPU или памяти.
00:13:34И нам также необходимо учитывать лимиты повторных попыток, ведь без этого затраты могут вырасти гораздо быстрее.
00:13:43Теперь я передам слово моему коллеге Наману, чтобы он продолжил доклад.
00:13:50Спасибо.
00:14:20Я передаю слово моему коллеге Наману.
00:14:22Я передаю слово моему коллеге Наману.
00:14:25Я передаю слово моему коллеге Наману.
00:14:26Я передаю слово моему коллеге Наману.
00:14:27Я передаю слово моему коллеге Наману.
00:14:28Я передаю слово моему коллеге Наману.
00:14:29Я передаю слово моему коллеге Наману.
00:14:30Я передаю слово моему коллеге Наману.
00:14:31Я передаю слово моему коллеге Наману.
00:14:32Я передаю слово моему коллеге Наману.
00:14:33Я передаю слово моему коллеге Наману.
00:14:34Я передаю слово моему коллеге Наману.
00:14:35Я передаю слово моему коллеге Наману.
00:14:36Я передаю слово моему коллеге Наману.
00:14:54Отлично, кажется, работает.
00:14:57Извините за задержку.
00:14:58Итак, когда инференс достигает промышленного масштаба,
00:15:00он становится очень похож на распределенную систему.
00:15:03Мы больше не просто вызываем модель.
00:15:06Это превращается в классическую задачу распределенных систем.
00:15:09В распределенных системах мы говорим об очередях, планировании,
00:15:13автомасштабировании и изоляции сбоев.
00:15:14Это лишь некоторые из аспектов.
00:15:16У инференса есть все эти проблемы,
00:15:18но теперь появляются новые ограничения.
00:15:20Вместо одной лишь памяти CPU у нас есть CPU, HBM, KV-кэш
00:15:25и стоимость за успешную задачу.
00:15:27Поэтому ключевым становится вопрос:
00:15:28как платформа узнает, что делать дальше?
00:15:31И вот здесь вступает в игру наблюдаемость.
00:15:34Дело не только в дашбордах.
00:15:35Речь о том, как передавать входной сигнал в контур управления.
00:15:39Телеметрия, данные, анализ. Анализ определяет решения,
00:15:43запускает изменения в планировании и маршрутизации,
00:15:45и в конце мы просто повторяем цикл.
00:15:47Я дам краткий обзор ключевых метрик.
00:15:50Первая — время до первого токена (TTFT),
00:15:52которая показывает, сколько времени реально требуется,
00:15:56чтобы получить первый ответ.
00:15:58Затем у нас есть коэффициент утилизации,
00:16:00который говорит о том, что является узким местом — память или вычисления.
00:16:04У нас есть метрика «успех на доллар», которая показывает,
00:16:06действительно ли платформа выполняет свои задачи
00:16:08и работает эффективно.
00:16:10И наконец, сквозная задержка (end-to-end latency),
00:16:12которая показывает общее время,
00:16:15затраченное на всем пути выполнения запроса.
00:16:19Существует ключевой компромисс между задержкой, стоимостью и пропускной способностью.
00:16:22Получить всё и сразу невозможно.
00:16:24Это очень похоже на теорему CAP.
00:16:26Если я увеличу размер батча,
00:16:28я повышу пропускную способность и экономическую эффективность,
00:16:31но могу ухудшить задержку в хвостовых значениях.
00:16:33Если я использую спекулятивное декодирование,
00:16:35я могу сократить задержку, но появятся дополнительные вычисления.
00:16:38В конечном счете, как вы знаете, растет стоимость за токен.
00:16:41И наконец, я могу взять простую, более легкую модель.
00:16:44Я сокращу задержку и затраты,
00:16:45но качество ответа будет низким.
00:16:48Придется делать анализ сбоев, совершать повторы,
00:16:50что снова поднимет стоимость.
00:16:52Так что каждое решение по инференсу сдвигает
00:16:54систему куда-то внутри этого треугольника.
00:16:56И наша задача — найти идеальную конфигурацию.
00:16:58Теперь это просто задача оптимизации.
00:17:03И именно к этому сейчас движется индустрия.
00:17:05Инференсу необходим собственный слой управления (control plane).
00:17:07Всё, что мы обсудили: маршрутизация, пакетирование, кэширование,
00:17:10планирование, надежность —
00:17:12больше не могут быть разрозненными ручками настройки.
00:17:15Они объединяются в единый логический уровень.
00:17:17Назовем его управляющим слоем инференса.
00:17:19Раньше в распределенных системах мы управляли виртуальными машинами.
00:17:21У нас были планировщики автомасштабирования.
00:17:23Затем появился Kubernetes, превративший все это в control plane.
00:17:27Инференс сейчас проходит через аналогичную трансформацию.
00:17:30Модели становятся ресурсами.
00:17:32GPU, KV-кэш, токены, задержки и затраты теперь распределяются планировщиком.
00:17:36Слой управления решает, какие модели обслуживают конкретный запрос
00:17:40и как он объединяется в батч.
00:17:42Поэтому, создаем ли мы этот уровень внутри компании,
00:17:44используем open-source или готовое решение от вендора,
00:17:46главный принцип проектирования — исходить из того, что этот слой будет существовать.
00:17:50Теперь давайте обсудим практические уроки,
00:17:53полученные нами при работе с AI-инфраструктурой,
00:17:55и то, как они применимы здесь.
00:17:57Первый урок: узкие места инфраструктуры
00:18:00обычно проявляются раньше, чем узкие места моделей.
00:18:02В реальной эксплуатации сбои возникают часто,
00:18:04но они могут быть связаны лишь с планированием, маршрутизацией
00:18:07или падением производительности каналов.
00:18:08То есть они не относятся к самому инференсу.
00:18:10Это проблемы именно инфраструктуры.
00:18:12Затем идет эластичность.
00:18:14Системе необходима эластичность.
00:18:15Можно добавить больше GPU, но это не решит проблему по-настоящему.
00:18:18Мы просто маскируем дефект.
00:18:20Наше решение — умное планирование,
00:18:24которое важнее наращивания мощности.
00:18:26Тот же парк оборудования может работать очень оптимально,
00:18:28в зависимости от того, как вы планируете его загрузку
00:18:30или как объединяете запросы в батчи.
00:18:31Затем у нас идут контуры автоматического управления, превосходящие ручной подход.
00:18:35Платформа должна считывать метрики, распознавать аномалии
00:18:37и автоматически подстраивать систему.
00:18:39Таким образом, главный вывод: не оптимизируйте под токены.
00:18:43Оптимизируйте под успешно выполненные задачи.
00:18:48И вот вам главная идея для размышления напоследок.
00:18:51Первая фаза развития AI-инфраструктуры строилась вокруг создания более совершенных моделей.
00:18:54Мы инвестировали много времени в улучшение моделей,
00:18:56в то, чтобы сделать их более умными,
00:18:58и в разработку более качественных бенчмарков.
00:19:00Текущий этап посвящен ускорению инференса,
00:19:03снижению задержки, оптимизации пакетирования
00:19:05и более эффективному использованию GPU.
00:19:08Но следующий этап будет связан с оркестрацией.
00:19:10Это означает, что GPU, память, кэш и все остальное —
00:19:13все это лишь ресурсы,
00:19:14и ими необходимо грамотно управлять и планировать их работы.
00:19:17Команды, которые поймут это на раннем этапе,
00:19:19построят инфраструктуру будущего.
00:19:21И заключающая мысль:
00:19:23инфраструктура — это больше не задача отдачи моделей.
00:19:25Это задача оркестрации.
00:19:27Спасибо.
00:19:29Спасибо.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video