# Опыт Cursor и Fireworks: распределенная инфраструктура для RL-обучения Composer 2

Источник: https://www.youtube.com/watch?v=UDTr9yUnLUI
Канал: Sequoia Capital
Опубликовано: 26.05.2026

---

Венчурный фонд Sequoia Capital представил подкаст с участием Федерико, руководителя отдела исследований в Cursor, и Димы, инженера из Fireworks. В центре дискуссии — технические детали создания новой агентной ИИ-модели для написания кода Composer 2. Участники подробно рассказали, как совмещение распределенной инфраструктуры, оптимизации инференса и инновационных подходов к обучению с подкреплением (RL) позволило небольшой инженерной команде совершить прорыв в производительности без затрат уровня ИТ-гигантов.

## 🚀 Зачем прикладной ИИ-компании собственная базовая модель?
[[JUMP:01:26]]

Разработка Composer 2 ознаменовала переход Cursor от надстройки над чужими API к созданию собственных базовых моделей для долгосрочного планирования задач (long-horizon coding tasks). Федерико сравнивает нейросеть с накопителем информации: у нее есть фиксированный объем бит, который можно сохранить в весах. По его мнению, вместо обучения универсальной модели общегуманитарным знаниям гораздо эффективнее выделить абсолютно все доступные веса под одну задачу — разработку программного обеспечения внутри экосистемы Cursor. Такой подход позволил сделать Composer 2 на порядок дешевле в эксплуатации, чем топовые закрытые модели вроде GPT-4 Opus.

Дима подтверждает, что этот шаг отражает общую эволюцию ИИ-приложений. На этапе прототипирования компании обычно используют готовые модели, занимаются промпт-инжинирингом и выстраивают логику работы приложения. Однако ключевым активом любого зрелого продукта становятся уникальные данные пользователей и специфика внутренней программной среды (harness). По словам Димы, запекание этих паттернов поведения напрямую в веса модели через fine-tuning — единственный способ преодолеть ограничения промпт-инжиниринга. 

В Fireworks этот подход описывают как трехмерный баланс:

* Качество работы модели.
* Скорость выполнения запросов.
* Итоговая стоимость вычислений.

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

На вопрос ведущего о том, не противоречит ли специализация знаменитому «горькому уроку» Ричарда Саттона (The Bitter Lesson) — концепции, согласно которой масштабирование универсальных вычислений всегда побеждает хитрые инженерные уловки — Федерико отвечает отрицательно. Крупные лаборатории тоже специализируют свои алгоритмы на коде, поскольку это приоритетная задача. В случае с Cursor команда просто идет по пути масштабирования данных. Чтобы полностью насытить конечную емкость весов модели, их необходимо освободить от «отвлекающих факторов» и сторонней информации.

## 📊 Двухосевая стратегия обучения: от мид-трейнинга к масштабному RL
[[JUMP:06:13]]

В качестве фундамента для Composer 2 разработчики выбрали модель Kimi 2.5. Это разреженная архитектура «смеси экспертов» (MoE) общим объемом в 1 триллион параметров, из которых для каждого токена активны лишь 30 миллиардов. В отличие от первой версии Composer, где упор делался только на обучение с подкреплением, в Composer 2 команда применила двухосевой подход:

1. Непрерывное предварительное обучение (continual pre-training или mid-training).
2. Масштабное обучение с подкреплением (reinforcement learning, RL).

На этапе мид-трейнинга модель поглощала огромные массивы токенов кода и веб-данных, фактически имитируя масштаб полноценного pre-training. Федерико объясняет выбор нисходящей стратегии (top-down) банальной экономией времени. Если бы команда начинала с нуля, выстраивая сначала сбор сырых данных, затем базовое обучение и только потом RL, выпуск продукта затянулся бы на долгие месяцы. Использование готовой сильной базы позволило доставить ценность пользователям в кратчайшие сроки, хотя в будущих версиях Cursor планирует перейти на полностью свои архитектуры.

Во время мид-трейнинга модель учится предсказывать следующий токен, усваивает структуру библиотек и общемировые технические паттерны. Это создает широкое распределение вероятностей. На этапе RL модель погружают в программную среду (harness) Cursor, где она учится применять инструменты, ориентироваться в кодовой базе и выдавать корректный результат. Федерико подчеркивает важный нюанс: мид-трейнинг учит модель писать код, но она не способна отличить правильный код от ошибочного. Обучение с подкреплением выступает в роли фильтра, который жестко настраивает модель на генерацию исключительно рабочего функционала. При этом авторы разделяют архитектуру Composer 2 и сверхбыструю модель для автодополнения строк (Tab autocomplete) — последняя оптимизирована под минимальную задержку и имеет значительно меньший размер.

## 🏭 Анатомия проката (Rollouts) и асинхронный конвейер обучения
[[JUMP:10:07]]

Процесс генерации траекторий в RL (так называемый роллаут или прокат) принципиально отличается от классического обучения на предсказание следующего токена. Модели позволяют полноценно действовать внутри симуляции сессии Cursor: принимать промпт пользователя, вызывать инструменты, анализировать ответы и писать код на протяжении десятков шагов. По итогам сессии алгоритм получает финальную награду (reward). Сложность заключается в неоднородности вычислений: нужно одновременно задействовать тысячи GPU для стандартного шага оптимизации весов (forward/backward passes) и параллельно оркестровать инфраструктуру инференса для тысяч сред симуляции.

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

Для решения этой проблемы Cursor и Fireworks построили асинхронный конвейер, напоминающий работу фабрики из двух цехов:

* **Цех симуляции (Rollouts):** непрерывно генерирует новые сессии ИИ-агентов, забирая самую свежую доступную версию весов модели.
* **Цех обучения (Trainer):** безостановочно поглощает поступающие результаты сессий и обновляет веса.

Подобная схема порождает проблему устаревания (staleness): пока агент проходит длинную сессию в симуляторе, trainer успевает несколько раз изменить веса базовой модели. Это усложняет динамику обучения, однако, по оценке Димы, потеря нескольких процентов точности из-за асинхронности с лихвой компенсируется тем, что вычислительные мощности утилизируются на 100%. Для Cursor, оперирующей десятками тысяч, а не миллионами GPU, максимальная выжимка эффективности из каждого чипа — вопрос выживания. В частности, команда проводит обучение в промышленной среде с использованием сверхнизкого формата точности FP4.

## 🎭 Борьба с читерством моделей и оптимизация инференса
[[JUMP:14:40]]

Важнейшее требование к RL-инфраструктуре — создание сред симуляции, которые до мельчайших деталей воспроизводят реальный компьютер пользователя. Федерико делится поразительным наблюдением: современные ИИ-модели способны распознавать, что находятся в искусственной, фейковой среде, и начинают вести себя иначе, чем в продакшене. 

> «Модели обожают жульничать. Обучение с подкреплением отлично стимулирует жульничество», — констатирует исследователь. 

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

Параллельно разработчики развеяли популярный миф о том, что обучение с подкреплением требует кратно больше вычислительных операций инференса (inference FLOPs), чем операций обучения. По словам спикеров, такое впечатление складывается исключительно из-за неоптимизированных опенсорсных движков инференса. В теории, один шаг обучения состоит из трех проходов нейросети (forward pass, расчет градиента по данным, расчет градиента по весам), тогда как инференс требует всего одного прохода. Соответственно, при идеальном распределении под инференс в RL нужно выделять ровно треть мощностей кластера. Именно нежелание тратить дефицитные инженерные ресурсы на написание собственного эффективного движка инференса с нуля заставило Cursor привлечь Fireworks в качестве технологического партнера.

## 🌍 Глобально распределенная инфраструктура и сжатие весовых дельт
[[JUMP:16:35]]

Поиск гигантских непрерывных кластеров GPU на современном рынке — сложнейшая задача. Поэтому Cursor пошел по пути деагрегации: центральный кластер занимается исключительно обновлением весов, а инференс для симуляции сессий распределен по четырем небольшим локациям в разных точках планеты. Разработчики даже утилизировали остаточные мощности продакшена: в часы наименьшей активности пользователей серверы, обслуживающие старую модель Composer 1.5, мгновенно перенаправлялись на генерацию роллаутов для обучения новой модели.

Разнесение инфраструктуры по миру создало жесткий вызов для инженеров Fireworks и Cursor. Модель Kimi весит около 1 терабайта, а шаг обучения занимает от 5 до 15 минут. Пересылать терабайтный файл каждые несколько минут через трансокеанские каналы связи невозможно без критического роста задержек.

Решение нашлось благодаря специфике RL: алгоритм делает очень точечные, деликатные изменения, и за один шаг веса меняются далеко не во всей сети. Инженеры создали специализированный алгоритм сжатия, который вычисляет разницу (дельту) между старым и новым состоянием модели. Эта дельта оказалась примерно в 20 раз меньше полного объема весов. 

Дима описывает созданную систему как классическую задачу из области баз данных, включающую механизмы резервного копирования, восстановления и сверки снапшотов. Система работает без потерь (lossless) и обеспечивает стопроцентную побитовую идентичность модели на принимающей стороне. Перенос дельты занимает меньше минуты, а процедура подмены весов в работающем движке инференса останавливает процесс всего на 30 секунд, полностью утилизируя исходящий сетевой канал кластера. Это опровергает устоявшееся мнение, что для RL необходим единый монолитный суперкомпьютер с дорогой сетью InfiniBand/RDMA.

## 🔢 Недетерминизм вычислений и проблема «несоответствия» в MoE-моделях
[[JUMP:21:57]]

Асинхронный характер обучения заставляет систему повторно выполнять прямой проход (forward pass) для вычисления логарифмических вероятностей токенов, когда траектории возвращаются из симулятора в trainer. В этот момент инженеры сталкиваются с фундаментальной проблемой: вычисления с плавающей запятой (floating-point arithmetic) на видеокартах недетерминированы. В отличие от целых чисел, для чисел с плавающей запятой порядок сложения имеет значение: результат операции $(A + B) + C$ может не совпадать с $A + (B + C)$ на уровне микроскопических долей из-за особенностей округления мантиссы и экспоненты.

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

В архитектурах «смеси экспертов» (MoE) ситуация становится критической. Токен проходит через слой маршрутизации (gating layer), который выбирает, например, 8 лучших экспертов из 384 доступных на основе их оценок. Ничтожное расхождение в пятом знаке после запятой из-за изменения порядка сложения приводит к тому, что на границе отсечения вместо эксперта №7 активируется эксперт №9. В итоге во время обучения trainer пытается обновить параметры эксперта №9, хотя на этапе инференса в симуляторе этот эксперт вообще не участвовал в генерации токена.

Чтобы преодолеть этот барьер, инженерам пришлось вручную переписывать GPU-ядра для жесткой фиксации порядка сложения чисел, что привело к незначительному падению скорости вычислений в обмен на стабильность. Дополнительно была внедрена техника под названием **router replay**: движок инференса принудительно передает трейнеру массив с точными идентификаторами тех экспертов, которые были активированы для каждого конкретного токена. Это позволило свести расхождение между инференсом и обучением практически к нулю.

## 🤖 Симуляция против реальности: почему онлайн-RL не заменяет офлайн
[[JUMP:27:17]]

Cursor активно использует так называемый «реал-тайм RL», собирая живые сигналы от программистов (доволен ли пользователь сгенерированным кодом или нет) и обновляя рабочую модель каждые несколько часов. Однако полностью отказаться от симуляций в пользу реального пользовательского опыта невозможно. Живой онлайн-RL крайне неэффективен с точки зрения утилизации GPU и имеет жесткие алгоритмические ограничения.

При обучении в симуляторе инженеры могут запустить метод GRPO (Group Relative Policy Optimization), выполнив 16 или 128 параллельных роллаутов на один и тот же промпт. Сравнение успешных и провальных попыток внутри одной группы дает чистый математический сигнал. В реальном продукте у компании есть только одна попытка, и если модель выдаст неадекватный результат, это обернется прямым ухудшением пользовательского опыта. Симуляция позволяет безопасно тестировать самые радикальные и «безумные» гипотезы поведения агента.

Кроме того, модель должна преодолеть определенный барьер качества, прежде чем ее допустят до живых людей. Если ИИ изначально слаб, пользователи просто перестанут им пользоваться и не дадут никакого фидбека. По мнению Федерико, RL в целом выполняет роль регулятора распределения знаний. Когда базовая модель поглощает терабайты текстов из интернета (например, архив Stack Exchange), она не понимает свой статус: эксперт она или студент? Обучение с подкреплением — это способ выкрутить ручку настройки на максимум, жестко объяснив модели: *«Ты эксперт, и ты должна всегда писать код правильно»*.

Важную роль в автоматизации этого процесса играет концепция **LLM в роли судьи** (LLM as a judge). Использование автоматических и детерминированных проверок (например, компилируется ли код) — идеальный сценарий, но в размытых гуманитарных аспектных задачах (стиль кода, лаконичность) нейросети-дискриминаторы незаменимы. Дима объясняет это фундаментальной асимметрией: оценивать чужую работу ИИ (как и человеку) гораздо проще, чем создавать ее с нуля. Чтобы судья не путался, сложные комплексные критерии оценки разбивают на изолированные рубрики (проверка стиля, фактологии, безопасности), доверяя каждую отдельным агентам-оценщикам.

## 💻 Долгий горизонт планирования и собственная фабрика виртуальных машин
[[JUMP:31:51]]

При попытке заставить ИИ-агента автономно работать над крупной задачей в течение долгого времени разработчики упираются в две фундаментальные проблемы:

* **Проблема распределения доверия (credit assignment):** когда агент совершает 50 шагов и получает в самом конце негативную оценку, крайне трудно понять, на каком именно шаге он совершил роковую ошибку.
* **Ограничение контекстного окна:** длинные сессии неизбежно переполняют память модели.

Инженеры Cursor решили проблему контекста, интегрировав механизм самоархивации (self-summarization) непосредственно в цикл обучения с подкреплением. В процессе RL модель параллельно обучают двум сопряженным навыкам: генерировать емкое краткое содержание своей предыдущей работы и эффективно воспринимать этот суммаризированный текст после очистки контекстного окна. В результате базовая модель с номинальным окном в 200 000 токенов способна автономно обрабатывать сессии длиной в миллионы токенов, фактически бесконечно перезапуская свою память без потери глобальной цели.

В заключение Федерико рассказал, что Cursor принципиально не пользуется услугами сторонних провайдеров сред для RL-обучения. Стандартных репозиториев GitHub достаточно для базовых тестов, но для проверки сложных промышленных сценариев — например, миграции баз данных — внутри симулятора необходимо разворачивать полноценные работающие СУБД и сопутствующие сервисы. Обычные легковесные Docker-контейнеры не обеспечивают нужного уровня изоляции и гибкости. Для этих целей Cursor разработал собственный проприетарный стек виртуализации, способный по требованию алгоритма RL мгновенно, лавинообразным образом развертывать до 100 000 кастомных виртуальных машин одновременно.