Skip to main contentSkip to footer

Mixture-of-Kittens ускоряет обучение MoE-моделей: что открыла Cursor

Инженер настраивает GPU-серверы для распределённого обучения MoE-моделей в дата-центре

4 августа 2026 года Cursor открыла исходный код Mixture-of-Kittens (MoK) — мегакернела для обучения моделей с архитектурой mixture-of-experts. Проект не является новой нейросетью или готовым облачным сервисом: это узкоспециализированный инфраструктурный компонент, который объединяет вычисления MoE-слоя и обмен данными между GPU.

По результатам Cursor, в производственном обучении на 512 ускорителях GB300 прирост составил около 41% по метрике tokens per second per GPU. Цифра выглядит впечатляюще, но применять её ко всем AI-кластерам нельзя: результат получен на конкретном оборудовании, с конкретной модельной архитектурой и внутренним стеком компании.

Почему MoE-слой становится узким местом

В mixture-of-experts-моделях для каждого токена активируется не вся сеть, а выбранная маршрутизатором группа «экспертов». Такой подход позволяет увеличивать общую ёмкость модели без пропорционального роста вычислений на каждом токене. Но при распределённом обучении эксперты размещаются на разных GPU, поэтому токены нужно постоянно пересылать между ускорителями.

Обычная схема состоит из трёх последовательных этапов: отправить токены на GPU с нужными экспертами, выполнить матричные операции, затем вернуть результаты. На больших кластерах обмен через NVLink способен занимать сопоставимое с вычислениями время. Cursor сообщает, что в отдельных конфигурациях MoE-слой потреблял более половины общего времени обучения её модели Composer.

Что именно делает Mixture-of-Kittens

MoK объединяет коммуникацию и вычисления в один детерминированный CUDA-мегакернел. Вместо серии отдельных запусков система распределяет потоковые мультипроцессоры GPU между передачей данных и вычислением экспертных слоёв, перекрывая эти операции по времени.

  • Выбирает направление обмена. Для прямой отправки токенов используется pull-механизм, а для возврата результата — push. По микротестам Cursor, pull при дисбалансе экспертов давал до 29% больше полезной пропускной способности NVLink.
  • Повторно использует расписание. Таблица маршрутов строится один раз на GPU и применяется в прямом и обратном проходах. Её построение занимало менее 3% времени MoE-слоя.
  • Убирает синхронизацию с CPU. Кольцевой буфер на несколько сотен мегабайт принимает меняющееся число токенов без выделения памяти процессором на каждом шаге и без отбрасывания лишних токенов.
  • Сохраняет воспроизводимость. Фиксированный порядок операций даёт побитово одинаковый результат при одинаковом входе независимо от порядка аппаратного планирования.

Поддерживаются режимы BF16 и MXFP8, прямой и обратный проходы. Проект ориентирован на MoE-слои в стиле DeepSeek-V3, похожие формы которых используются в семействах Qwen, Kimi, GLM и DeepSeek.

Что показали тесты Cursor

Однослойные тесты проводились внутри одной стойки GB300 NVL72 с expert parallelism degree 64 и 2048 токенами на GPU до маршрутизации. Сравнивались NCCL с PyTorch, DeepEP, TransformerEngine и HybridEP с Megatron.

  • до 2,37 раза быстрее в прямом проходе MXFP8;
  • до 1,78 раза быстрее в обратном проходе MXFP8;
  • до 1,92 раза быстрее в прямом проходе BF16;
  • до 1,58 раза быстрее в обратном проходе BF16.

В отдельном сквозном тесте производственного стека на 512 GPU показатель вырос с 760,9 до 1070,2 токена в секунду на ускоритель — в 1,41 раза. Это наиболее полезная цифра для оценки эффекта, поскольку она учитывает не только изолированный слой. Однако методика и контроль над окружением принадлежат самой Cursor, а независимых воспроизведений на момент публикации этого разбора нет.

Кому проект действительно пригодится

Mixture-of-Kittens не предназначена для обычного сервера с несколькими видеокартами. В официальных требованиях указаны ускорители NVIDIA Blackwell SM100 или SM103 — например, GB200 либо GB300 NVL72, Python 3.12+, PyTorch 2.10+ и CUDA 13.0+. Оптимальные параметры зависят от формы модели, числа токенов и распределения экспертов, поэтому перед продакшеном нужен отдельный цикл профилирования.

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

Что это означает для Узбекистана

Для формирующейся AI-инфраструктуры Узбекистана релиз показывает важный приоритет: закупка ускорителей должна сопровождаться компетенциями по системному ПО, профилированию CUDA и распределённому обучению. Без такого слоя дорогие GPU могут простаивать из-за обмена данными, синхронизации или неоптимального размера задач.

Локальным дата-центрам и интеграторам стоит заранее включать в пилоты не только скорость отдельного ускорителя, но и сквозные метрики: токены в секунду на GPU, загрузку NVLink, время простоя, энергопотребление на обучающий шаг и стабильность результатов. Открытая лицензия Apache 2.0 позволяет изучать и изменять MoK, но текущая аппаратная специализация ограничивает прямое применение.

Что проверить перед экспериментом

  • совпадает ли архитектура ускорителей с SM100 или SM103;
  • соответствуют ли версии PyTorch и CUDA требованиям проекта;
  • есть ли MoE-слой в профиле среди главных узких мест;
  • можно ли воспроизвести базовый тест на собственной форме модели;
  • как изменились сквозная скорость, память и численная стабильность, а не только локальный бенчмарк.

Техническая оговорка: заявленные ускорения относятся к измерениям Cursor и не гарантируют аналогичный результат на другом оборудовании, модели или программном стеке. Перед производственным внедрением необходимы собственные тесты и проверка совместимости.

Первоисточники

Интересное