Вертикальная мобильность: Инференс от MVP до нагрузки в триллион параметров — Ситаншу Гупта, CoreWeave

РусскийالعربيةDeutschEnglishEspañolFrançaisहिन्दी日本語한국어Português中文
AAI Engineer
컴퓨터/소프트웨어AI/미래기술

스크립트

00:00:00Всем добрый день. Меня зовут Ситаншу, я из Corvi. Сегодня я буду говорить о вертикальной
00:00:19мобильности. Название звучит довольно громко, но по сути я буду
00:00:26рассказывать о нашей платформе инференса в Corvi, которую мы создаем для обслуживания
00:00:30как маленьких, так и больших моделей и самых разных рабочих нагрузок. Коротко обо мне: я присоединился
00:00:38к Corvi всего около четырех месяцев назад и возглавляю здесь направление инференса. А до этого
00:00:44я руководил всем направлением обучения в AWS Annapurna Labs, а еще раньше — инференсом
00:00:49и обучением в Sambanova. Так что у меня солидный опыт в этой сфере. Мой рассказ
00:00:56будет построен так: я объясню используемые нами модели потребления,
00:01:00и на их основе покажу, как мы сформулировали требования к платформе, чтобы
00:01:04нам не приходилось постоянно переписывать её с нуля, а можно было планомерно развивать
00:01:09нашу систему обслуживания инференса. Также поговорим о том, почему производительность играет здесь ключевую роль.
00:01:14Думаю, кое-что из этого может перекликаться с предыдущей темой, которую здесь обсуждали.
00:01:20Модели потребления. У нас есть две основные модели. Первая — serverless (бессерверная),
00:01:29в рамках которой клиентам и пользователям вообще не нужно беспокоиться об управлении
00:01:35оборудованием, администрировании кластеров, оркестрации или о чем-либо подобном.
00:01:40Есть API, есть интерфейс: вы заходите, платите за токены и получаете готовую к работе модель.
00:01:47Самое важное здесь — это широкий выбор моделей в каталоге, к которым у клиента
00:01:54есть доступ. Я сначала расскажу о выделенных ресурсах (dedicated), а затем вернусь к serverless,
00:02:01потому что у бессерверной модели есть одна уникальная особенность. Выделенный сервис инференса (dedicated),
00:02:05который мы предоставляем, больше подходит клиентам, желающим точно знать, какое железо они используют,
00:02:11однако развертывание модели лежит на их стороне. Они используют наш сервис и наши слои оркестрации,
00:02:18но запуск модели остается за ними. Производительность модели также зависит от них — главное,
00:02:25чтобы наша платформа предоставляла необходимые возможности и настройки. Возвращаясь к serverless,
00:02:30один из интересных моментов здесь заключается в том, что типичная проблема бессерверных систем — это “беспокойный сосед” (noisy neighbor),
00:02:38когда, если все одновременно шлют запросы к одной и той же модели, у вас могут регулярно вылетать таймауты
00:02:43в зависимости от объёма ресурсов за этой моделью. Поэтому еще одна функция, которую мы предлагаем для serverless,
00:02:48— это так называемая зарезервированная пропускная способность (provisioned throughput). Если вы как клиент знаете свой профиль трафика
00:02:55и передадите нам эти данные, мы сможем выделить под вас персональную мощность
00:03:00на уровне инфраструктуры. Вам по-прежнему не нужно думать, на каком именно железе всё работает,
00:03:04главное, что соблюдаются ваша пропускная способность и SLA.
00:03:07Это ещё одна опция в рамках бессерверной модели, где оплата всё так же идет за токены,
00:03:12но при этом вы гарантированно защищены от проблемы “беспокойного соседа”.
00:03:19Давайте кратко разберем несколько типов рабочих нагрузок и их профилей,
00:03:27с которыми мы сталкиваемся. Соотношение между ними постоянно меняется, хотя агентские системы (agentic)
00:03:32сейчас на самом пике. Агентские нагрузки и чаты довольно похожи: у них обычно очень большая длина
00:03:39входной последовательности (input sequence) и очень маленькая длина выходной. Главная же разница между ними в том,
00:03:43что многошаговые диалоги (multi-turn) в агентских системах требуют сверхнизкой задержки, в отличие от чатов, где после ответа
00:03:50пользователю нужно время, чтобы прочитать его и обдумать следующий шаг. Так что здесь есть
00:03:56свои особенности. И это ключевое отличие в конечном счете сводится
00:04:01к нюансам управления KV-кэшем. Но оба этих типа работают в реальном времени. Еще один пример задач реального времени —
00:04:09голосовые и видеопотоки, требующие непрерывного стриминга и критичные к задержкам. Для агентских систем и чатов
00:04:16требования в основном касаются пропускной способности, а не задержки, тогда как голосовой и видеопоток
00:04:23абсолютно чувствительны к latency. Что касается пакетной обработки (batch), то здесь требования SLA максимально
00:04:32мягкие. Задержки допустимы в секунды и минуты, а у некоторых клиентов — даже в часы.
00:04:37Они говорят: “Дайте нам окно обработки на 10–12 часов, мы загрузим всё, что есть,
00:04:44а вы обработаете, когда будут свободные мощности”. И эти пакетные нагрузки играют важную роль
00:04:52в определении архитектурных решений, которые мы закладываем в стек. Представьте
00:04:59эти четыре разных профиля нагрузки. Во временном измерении вам нужно умело манипулировать
00:05:04их характеристиками, чтобы выжать максимум из имеющейся инфраструктуры.
00:05:12Я опишу на верхнем уровне, как устроен наш стек прямо сейчас, и разберу
00:05:19путь прохождения запроса. Для обеих моделей, serverless и dedicated, в правой части
00:05:24экрана видно, что на стороне платформы запрос поступает в control plane для
00:05:31авторизации, ограничения частоты запросов (rate limiting), учета использования и т. д. — чтобы корректно формировать счета.
00:05:37Также здесь задействован мониторинг (observability), чтобы контролировать соблюдение зафиксированных в SLA условий.
00:05:45Ниже, на уровне самой платформы, я схематично показал, что у нас есть различные
00:05:52движки инференса: vLLM, SGLang и TensorRT-LLM, но за этим кроется еще множество деталей, о которых я упомяну.
00:06:00А еще ниже, в зеленом блоке, показаны самые разные типы аппаратных ресурсов.
00:06:09Платформа должна быть достаточно гибкой, чтобы распределять нагрузки
00:06:15между различными поколениями эти GPU — в частности, графических процессоров NVIDIA,
00:06:21которые мы используем. Давайте рассмотрим пару примеров. Допустим, запрос отправляется
00:06:31со стороны клиента из приложения, ноутбука или через агента. Он попадает на шлюз (gateway).
00:06:36Попав на шлюз, он, как я уже говорил, проходит через аутентификацию на уровне control plane,
00:06:42после чего уходит в ветку serverless или dedicated. В случае с serverless
00:06:48оплата идет за токены, поэтому здесь отслеживается объем потребления — не само содержимое,
00:06:53а именно количество токенов, так как мы строго соблюдаем политику нулевого хранения данных (ZDR).
00:06:59В зависимости от типа доступа — мультиарендного (multi-tenancy) или зарезервированного (provisioned),
00:07:05роутер понимает, нужно ли направить запрос к сфокусированным инстансам,
00:07:12выделенным под клиентов с гарантированной пропускной способностью, либо в общий пул.
00:07:17Роутер в этой цепочке выполняет важнейшую роль, поскольку именно он отвечает за
00:07:26принятие решений с учетом состояния KV-кэша (kvcache-aware routing). Почему это так важно? Потому что, как я отметил
00:07:31при разборе профилей нагрузки, агентские сценарии требуют огромной длины входного
00:07:39контекста. И основная часть этого контекста — порядка 80-90%, в зависимости от компании
00:07:44и специфики клиента — совпадает в самых разных запросах.
00:07:51Поэтому нет никакого смысла заново выполнять этап pre-fill для одной и той же информации.
00:07:57Pre-fill крайне ресурсоемок и затратен по вычислительной мощности, поэтому чем чаще вы попадаете в кэш,
00:08:04тем больше экономно расходуете ресурсы. Именно поэтому в ценах на токены у провайдеров есть стандартный тариф
00:08:11на входные токены и ощутимо более дешевый — на закэшированные. Caching здесь критически важен.
00:08:18Как именно разделять аппаратные ресурсы, зависит от конфигурации платформы,
00:08:26и мы даем возможность выбирать подходящий вариант. Можно настроить дезинтеграцию фаз pre-fill и decode (P/D disaggregation),
00:08:31если это оправдано задачей, либо отказаться от нее, так как дезинтеграция pre-fill и decode выгодна далеко не всегда.
00:08:41Рассмотрим другой сценарий. Посмотрим, что происходит в случае с dedicated-клиентом.
00:08:48Выделенный клиент также идет через шлюзы, которые изолированы специальным образом.
00:08:55Оплата при этом привязана не к токенам, а к фактическому времени использования каждого GPU в час.
00:09:03Запросы идут через приватный шлюз, что полностью исключает проблему “беспокойного соседа”.
00:09:09Логика роутера здесь аналогична: при наличии похожих запросов максимально задействуется кэш.
00:09:18В зависимости от конфигурации развертывания на своих выделенных GPU
00:09:24клиент сам решает, нужна ли ему раздельная обработка pre-fill и decode.
00:09:29Он может выбрать движок: vLLM, SGLang или TensorRT-LLM. Исходя из объема зарезервированных
00:09:35мощностей, клиент решает, поднять ли единый сервис с возможностью масштабирования
00:09:42на весь кластер, либо развернуть несколько разных моделей и инстансов.
00:09:47Также стоит упомянуть о важной особенности роутера:
00:09:54он поддерживает работу с гетерогенной инфраструктурой в разных зонах и регионах.
00:09:59Балансировка нагрузки в таких условиях — задача весьма непростая.
00:10:04Поэтому приоритетный порядок, которому мы обычно следуем, — это локальность KV-кеша, а затем перенаправление на наименее загруженный узел.
00:10:16Вот так. Еще один вариант прохождения запросов,
00:10:21который может быть не до конца виден на схеме — это пакетные задачи (batch).
00:10:25Для пакетной обработки мы используем имеющиеся мощности клиента. К примеру,
00:10:31тот же dedicated-клиент днем выполняет интерактивные задачи реального времени,
00:10:37а вечером и ночью хочет запустить пакетные вычисления. Те же самые мощности
00:10:43можно перераспределить по расписанию под batch-нагрузки. В нашем API есть методы управления масштабированием,
00:10:51и если по графику заложено уменьшение интерактивных ресурсов,
00:10:56система высвобождает их и отдает под ночную пакетную обработку.
00:11:05Я уже немало рассказал об оптимизации KV-кэша, но хочу еще раз подчеркнуть этот момент,
00:11:10поскольку это один из наиболее интересных аспектов. Чем чаще вы попадаете в кэш,
00:11:19то избавитесь от затрат на префилл — самый дорогой этап.
00:11:26Повторное использование KV-кэша в агентах на разных шагах взаимодействия
00:11:31тоже экономит ресурсы, ведь во входном контексте много одинаковых префиллов.
00:11:38Возьмём, к примеру, чаты. Выгрузка KV-кэша здесь крайне важна,
00:11:43поскольку между репликами пользователей проходит довольно много времени.
00:11:49И если мы полностью удалим кэш нашей беседы,
00:11:57следующий вопрос в том же чате будет обрабатываться дольше.
00:12:02Поэтому вместо удаления кэша и повторного префилла применяются техники...
00:12:08Мы используем свои разработки, а из внешних известны LM Cache и Mooncake.
00:12:17Суть в том, что мы сбрасываем KV-кэш в высокоскоростное хранилище,
00:12:21сохраняя эти префиллы. И когда приходит очередной запрос в рамках этого чата,
00:12:28кэш моментально загружается обратно в HBM.
00:12:37Что касается рычагов оптимизации производительности...
00:12:41Мы уже обсудили PD DSAG. Но есть также квантование и спекулятивное декодирование.
00:12:48И грамотный выбор степени и стратегий параллелизации невероятно важен.
00:12:54Два главных инструмента, с которыми мы работаем — квантование до NVFP4 и spec dec.
00:13:01Мы предлагаем функцию обучения спекулятивных моделей на данных клиента,
00:13:07что повышает процент принятых токенов и существенно увеличивает
00:13:12пропускную способность генерации. Этот процесс происходит асинхронно:
00:13:20получаем данные, обучаем спекулятор и внедряем его в окружение клиента,
00:13:26если есть такая задача. Здесь представлены три скриншота —
00:13:32это результаты работы нашей команды за последний месяц. Видно, как мы быстро
00:13:39возглавили лидерборд по Kimi 2.6 и 2.7. Данные взяты из Artificial Analysis.
00:13:46Но, возвращаясь к предыдущей сессии: можно ли этому верить? Поэтому для GLM у меня
00:13:52данные из OpenRouter. Artificial Analysis тестирует очень специфические нагрузки.
00:13:58OpenRouter же показывает реальный трафик пользователей. Вот график Weights & Biases.
00:14:05Брендинг отличается, но Weights & Biases — это, по сути, Cirrascale. Мы купили их
00:14:09около года назад. И как видите, скорость нашего развёртывания практически
00:14:16сопоставима с показателями Fireworks Fast. Но главное, на чём я хочу
00:14:21сделать акцент — это лежащие в основе методы оптимизации. Это критически важно,
00:14:27потому что в конечном счёте мы стремимся дать клиенту наилучшее соотношение цены и качества.
00:14:36Краткий итог: единая платформа — вот на чём я хотел сделать акцент.
00:14:44Две модели потребления: Serverless и Dedicated. При этом для Serverless
00:14:49доступны два варианта оплаты: Pay-as-you-go и Provisioned Throughput,
00:14:53а суммарный эффект достигается за счёт оптимизации всего стека.
00:15:01На этом всё. Всем спасибо!

핵심 요약

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

하이라이트

  • Мультиарендная бессерверная инфраструктура с опцией зарезервированной пропускной способности (provisioned throughput) предотвращает проблему «беспокойного соседа» (noisy neighbor), сохраняя при этом оплату за токены.

  • Маршрутизация с учетом KV-кэша (kvcache-aware routing) исключает повторный ресурсоемкий этап pre-fill, который составляет от 80% до 90% совпадающего контекста в агентских системах.

  • Сброс KV-кэша в высокоскоростное хранилище с последующей подгрузкой в HBM решает проблему задержек при обработке длительных паузах между репликами в чатах.

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

  • Перераспределение высвобождающихся ресурсов интерактивных сервисов в ночное время позволяет выполнять объемные пакетные вычисления (batch) без покупки дополнительного оборудования.

타임라인

Модели потребления: Serverless и Dedicated

  • Бессерверная модель (serverless) полностью снимает с пользователя задачи администрирования оборудования и оркестрации.
  • Выделенные сервисы (dedicated) дают прямой контроль над аппаратурой, перекладывая оптимизацию и развертывание модели на сторону клиента.
  • Зарезервированная пропускная способность внутри serverless-модели устраняет задержки от «беспокойных соседей».

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

Профили рабочих нагрузок и особенности задержки

  • Агентские нагрузки критичны к задержке из-за многошаговых диалогов, в отличие от стандартных текстовых чатов.
  • Потоковые голосовые и видеоданные требуют минимального latency, тогда как чаты критичнее к пропускной способности.
  • Пакетная обработка допускает задержки вплоть до 10–12 часов и служит регулятором загрузки инфраструктуры.

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

Архитектура платформы и умная маршрутизация

  • Маршрутизатор с учетом KV-кэша приоритетно направляет запросы с совпадающим контекстом на узлы с готовым кэшем.
  • Разделение фаз pre-fill и decode применяют гибко в зависимости от конфигурации и целесообразности задачи.
  • Приватные шлюзы для выделенных клиентов обеспечивают полное изолирование сетевого трафика.

Единый control plane обрабатывает авторизацию, ограничение частоты запросов, учет потребления токенов в рамках политики нулевого хранения данных (ZDR) и мониторинг SLA. На исполнительном уровне поддерживаются движки vLLM, SGLang и TensorRT-LLM поверх гетерогенного парка GPU NVIDIA. Маршрутизатор первоначально учитывает локальность KV-кэша, а затем балансирует нагрузку по наименее загруженным узлам. В ночное время ресурсы автоматически перераспределяются с интерактивных задач на пакетную обработку.

Оптимизация KV-кэша и ускорение генерации

  • Выгрузка KV-кэша в быструю внешнюю память предотвращает повторные затраты на этап pre-fill.
  • Квантование NVFP4 и спекулятивное декодирование служат базовыми рычагами повышения производительности.
  • Асинхронное обучение спекулятивных моделей повышает процент принимаемых токенов.

Устранение затрат на фазу pre-fill дает наибольшую экономию вычислений, так как до 90% входного контекста в смежных запросах совпадает. Для длинных пауз в чатах используются технологии сброса кэша во внешнее высокоскоростное хранилище с последующей мгновенной загрузкой в HBM GPU при поступлении нового сообщения. Автоматизированное обучение персональных спекуляторов под данные клиента наращивает итоговую скорость генерации и пропускную способность платформы.

커뮤니티 글

아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!

이 영상에 대해 글쓰기