Поддержка Day-0 и 5-кратный прирост производительности для Reflection Beam в Google Cloud

Сегодня компания Reflection выпустила Beam, свою первую модель с открытыми весами, созданную для того, чтобы предоставить разработчикам, исследователям и предприятиям открытый контроль и возможности настройки для передовых задач в области программной инженерии и долгосрочных агентных процессов. Выпущенная под разрешающей лицензией Apache 2.0 с контрольными точками BF16, FP8 и NVFP4, доступными на момент запуска, модель Beam устанавливает новый стандарт эффективности вывода в классе моделей с 500 млрд параметров, решая сложные задачи логического вывода и программирования с 3x to 4x higher reasoning вычислительной эффективностью по сравнению с аналогичными открытыми моделями.

Одновременно с сегодняшним релизом Google Cloud объявляет о поддержке Day 0 и готовых к использованию рецептах развертывания для обслуживания Beam на базе Google Cloud AI Hypercomputer и инфраструктуры NVIDIA AI.

Чтобы помочь разработчикам получить максимальную выгоду от эффективности токенов Beam в рабочей среде, мы совместно с Reflection оптимизировали производительность базового стека обслуживания с использованием llm-d (с vLLM) и NVIDIA Dynamo (с SGLang) в Google Cloud:

«Развернув нашу модель Beam в Google Cloud, мы достигли 5-кратного повышения производительности и 8-кратного снижения задержки для оптимизации обслуживания агентных рабочих нагрузок». — Джо Списак, вице-президент по продуктам и руководитель направления Open Source, Reflection

Благодаря сегодняшнему релизу Day 0 в Google Cloud разработчики получают:

• Совокупная эффективность модели и системы: сочетание вычислительной эффективности логического вывода Beam (в 3–4 раза выше) с системными оптимизациями на инстансах A4X Max (NVIDIA GB300 NVL72) для достижения до 5-кратного увеличения пропускной способности и 8-кратного снижения задержки*, а также на виртуальных машинах G4 (NVIDIA RTX PRO 6000) для достижения до 2-кратного увеличения пропускной способности и 8-кратного снижения задержки*.

Совокупная эффективность модели и системы: сочетание вычислительной эффективности логического вывода Beam (в 3–4 раза выше) с системными оптимизациями на инстансах A4X Max (NVIDIA GB300 NVL72) для достижения до 5-кратного увеличения пропускной способности и 8-кратного снижения задержки*, а также на виртуальных машинах G4 (NVIDIA RTX PRO 6000) для достижения до 2-кратного увеличения пропускной способности и 8-кратного снижения задержки*.

• Высокоэффективное многоходовое обслуживание: маршрутизация с учетом KV-кэша, разделение префиллинга и декодирования, спекулятивное декодирование и иерархическая выгрузка KV-кэша в Host DRAM и локальные SSD сокращают избыточное повторное вычисление промптов в ходе длительных сессий программирования.

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

• Готовые оптимизированные решения для развертывания: наши рекомендуемые рецепты, оптимизированные по производительности для агентных рабочих нагрузок с использованием llm-d и NVIDIA Dynamo, доступны в AI-Hypercomputer/gpu-recipes, репозитории llm-d и Model Garden на платформе Gemini, и их можно развернуть в несколько кликов.

Готовые оптимизированные решения для развертывания: наши рекомендуемые рецепты, оптимизированные по производительности для агентных рабочих нагрузок с использованием llm-d и NVIDIA Dynamo, доступны в , репозитории llm-d и Model Garden на платформе Gemini, и их можно развернуть в несколько кликов.

*На основе бенчмаркинга клиентов

Масштабирование вывода требует оптимизации на системном уровне

При оценке моделей для агентного программирования и использования инструментов эффективность вывода проявляется на двух разных уровнях: насколько эффективно модель рассуждает и насколько эффективно система обслуживания выполняет многоходовые циклы.

Эффективность на уровне модели: Reflection Beam

Компания Reflection разработала Beam (~501 млрд параметров всего, из которых ~23 млрд активных параметров на токен, и контекстное окно около 1 млн токенов) специально для текстовой программной инженерии и многошагового использования инструментов. Она напрямую интегрируется в инструменты программирования, которые уже используют разработчики, включая Mirror CLI от Reflection, Claude Code, Hermes, OpenCode и другие, для решения проблем на GitHub, запуска CLI и DevOps-процессов, а также выполнения долгосрочных задач.

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

Эффективность на системном уровне: оптимизированное обслуживание AI Hypercomputer

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

Даже когда сама модель генерирует в 3–4 раза меньше токенов логического вывода на каждом шаге, накопленное контекстное окно между шагами создает две серьезные инфраструктурные проблемы:

Во-первых, вычисления префиллинга становятся узким местом. Стандартные балансировщики нагрузки Kubernetes распределяют запросы с использованием алгоритма round-robin без сохранения состояния. Когда инструмент программирования отправляет 15-й шаг сессии, он часто попадает на другую реплику, отличную от 14-го шага. Эта реплика вынуждена пересчитывать весь исторический промпт с нуля, тратя впустую вычислительные ресурсы GPU и создавая длинные очереди префиллинга, которые задерживают других пользователей.

Во-вторых, декодирование становится ограниченным емкостью KV-кэша. Хранение KV-кэшей с длинным контекстом для десятков одновременных агентных сессий быстро заполняет память с высокой пропускной способностью (HBM) графического процессора. Как только HBM заполняется, механизм обслуживания должен вытеснять старые блоки KV. Как только эти блоки вытесняются, частота попаданий в кэш падает, а пропускная способность GPU снижается.

Чтобы сохранить эффективность модели Beam на уровне кластера, стек обслуживания должен быть оптимизирован как распределенная система. Именно поэтому наши рецепты объединяют Beam с (с vLLM) и NVIDIA Dynamo (с SGLang).

Внутри архитектуры вывода AI Hypercomputer

Чтобы запускать контрольные точки BF16, FP8 и NVFP4 модели Beam с максимальной эффективностью в день запуска, мы разработали вертикально интегрированную архитектуру на базе AI Hypercomputer, где каждый уровень отвечает за определенную часть жизненного цикла агентного обслуживания.

Системно-оптимизированная архитектура для обслуживания агентного трафика

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

• Маршрутизация с учетом префиксов и нагрузки (GKE + llm-d EPP / маршрутизатор Dynamo): отслеживает кэшированные префиксы и глубину очереди на рабочих подах, направляя каждый последующий шаг от инструмента программирования к реплике, содержащей его «теплый» KV-префикс, предотвращая переполнение очереди с помощью управления потоком на основе приоритета шагов.

Маршрутизация с учетом префиксов и нагрузки (GKE + llm-d EPP / маршрутизатор Dynamo): отслеживает кэшированные префиксы и глубину очереди на рабочих подах, направляя каждый последующий шаг от инструмента программирования к реплике, содержащей его «теплый» KV-префикс, предотвращая переполнение очереди с помощью управления потоком на основе приоритета шагов.

• Дезагрегированные вычисления и спекулятивное декодирование (инстансы A4X Max и G4): запускают vLLM и SGLang с поддержкой нативного Blackwell NVFP4, параллелизма экспертов (EP) для 23 млрд активных экспертов Beam, параллельного внимания по данным (Data-Parallel Attention) и спекулятивного декодирования DFlash2. Разделение пулов префиллинга и декодирования (P/D) гарантирует, что интенсивные всплески промптов никогда не остановят генерацию активных токенов.

Дезагрегированные вычисления и спекулятивное декодирование (экземпляры A4X Max и G4): запуск vLLM и SGLang с использованием нативных Blackwell NVFP4, параллелизма экспертов (EP) для 23B активных экспертов Beam, Data-Parallel Attention и спекулятивного декодирования DFlash2. Разделение пулов префилла и декодирования (P/D) гарантирует, что интенсивные всплески промптов никогда не замедлят генерацию активных токенов.

• Многоуровневый KV-кэш (память GPU -> DRAM и локальный SSD). Активные блоки KV остаются в высокоскоростной памяти GPU (уровень 1), в то время как «теплые» блоки KV, вытесненные во время длительных сессий, перемещаются в хост-память CPU DRAM и локальные NVMe SSD (уровень 2) через OffloadingConnector в vLLM или HiCache в SGLang, что позволяет извлекать исторический контекст за миллисекунды, а не пересчитывать его с нуля.

Многоуровневый KV-кэш (память GPU -> DRAM и локальный SSD). Активные блоки KV остаются в высокоскоростной памяти GPU (уровень 1), в то время как «теплые» блоки KV, вытесненные во время длительных сессий, перемещаются в хост-память CPU DRAM и локальные NVMe SSD (уровень 2) через OffloadingConnector в vLLM или HiCache в SGLang, что позволяет извлекать исторический контекст за миллисекунды, а не пересчитывать его с нуля.

Системные оптимизации для многоходовых агентных рабочих нагрузок

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

Примечание к чтению этих графиков. Две конфигурации нельзя сравнивать напрямую. NVIDIA Dynamo работал на экземплярах A4X Max с 32 графическими процессорами NVIDIA GB300 NVL72; llm-d работал на виртуальных машинах G4 с 8 графическими процессорами NVIDIA RTX PRO 6000. Каждый график показывает прирост по сравнению с базовым уровнем на том же оборудовании. Большее количество реплик дает маршрутизатору больше «теплых» KV-кэшей для обращения и больше возможностей для разделения префилла и декодирования, поэтому прирост увеличивается вместе с масштабированием развертывания. И llm-d, и NVIDIA Dynamo масштабируются вверх и вниз в соответствии с базовой инфраструктурой.

Оптимизированная производительность NVIDIA Dynamo по сравнению с базовым развертыванием Reflection's Beam

Оптимизированная производительность llm-d по сравнению с базовым развертыванием Reflection's Beam

На обеих платформах многоуровневое применение этих оптимизаций смещает границу Парето, обеспечивая одновременно более высокую пропускную способность и более быструю интерактивность для пользователя:

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

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

• Маршрутизация с учетом KV-кэша и управлением потоками. Включение маршрутизации с учетом префиксов в NVIDIA Dynamo или Sticky EPP в llm-d с управлением потоками по приоритету хода позволяет привязывать траектории многоходовых агентов к реплике, хранящей их «теплый» KV-кэш, что немедленно сокращает задержку до первого токена (TTFT) и высвобождает вычислительные ресурсы GPU, что приводит к значительному увеличению пропускной способности токенов.

Маршрутизация с учетом KV-кэша и управлением потоками. Включение маршрутизации с учетом префиксов в NVIDIA Dynamo или Sticky EPP в llm-d с управлением потоками по приоритету хода позволяет привязывать траектории многоходовых агентов к реплике, хранящей их «теплый» KV-кэш, что немедленно сокращает задержку до первого токена (TTFT) и высвобождает вычислительные ресурсы GPU, что приводит к значительному увеличению пропускной способности токенов.

• Выгрузка KV-кэша в хост-память DRAM и локальный SSD (LSSD). Выгрузка вытесненных блоков KV из памяти GPU в хост-память DRAM и локальные NVMe SSD предотвращает «кэш-трешинг» (избыточное вытеснение), когда десятки сессий кодирования с длинным контекстом превышают емкость памяти GPU на устройстве.

Выгрузка KV-кэша в хост-память DRAM и локальный SSD (LSSD). Выгрузка вытесненных блоков KV из памяти GPU в хост-память DRAM и локальные NVMe SSD предотвращает «кэш-трешинг» (избыточное вытеснение), когда десятки сессий кодирования с длинным контекстом превышают емкость памяти GPU на устройстве.

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

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

Начните работу и встретимся на PyTorchCon и GTC Berlin

В этом блоге мы рассмотрели, как можно использовать оптимизации на системном уровне для масштабирования производительности при обслуживании семейства моделей Reflection's Beam для агентных рабочих нагрузок. Все манифесты Kubernetes, конфигурации маршрутизаторов и скрипты для бенчмаркинга из этой статьи являются открытым исходным кодом и готовы к запуску в вашем собственном кластере GKE.

• Разверните оптимизированный стек: изучите руководства по запуску Reflection’s Beam с llm-d и NVIDIA Dynamo в AI-Hypercomputer/gpu-recipes repository on A4X Max и G4, а также Model Garden на платформе Gemini.
• Скачайте веса: получите чекпоинты Apache 2.0 BF16, FP8 и NVFP4 на странице Reflection на Hugging Face.
• Посетите нас на llm-d и конференции PyTorch в Сан-Хосе: если вы планируете посетить конференцию PyTorch North America в Сан-Хосе в октябре, загляните на сессии сообщества llm-d и стенд Google Cloud №. Мы проведем живые демонстрации маршрутизации с учетом KV-кэша, дезагрегации P/D и многоуровневого кэширования KV для агентных рабочих нагрузок.
• Приходите к нам на NVIDIA GTC Berlin: если вы будете на NVIDIA GTC Berlin, свяжитесь с нами на нашем стенде №3026 или в Google Cloud Hub по адресу w3.hub: всего в 5 минутах ходьбы от места проведения. Узнайте больше о наших сессиях.
• Инфраструктура ИИ
• Контейнеры и Kubernetes
• ИИ-гиперкомпьютер
• Вычисления
• llm-d