В мире искусственного интеллекта, где каждый процент прироста производительности может означать миллионы долларов экономии на вычислительных ресурсах, компания Cursor Research совершила прорыв, который переписывает правила игры для разработчиков больших языковых моделей (LLM). Они открыли исходный код под названием Mixture-of-Kittens (MoK) — это не просто библиотека, а сложнейшее программное обеспечение, представляющее собой «мега-ядро» (megakernel) для обучения моделей с архитектурой Mixture of Experts (MoE). Это решение, лежащее в основе моделей Composer, объединяет все шаги коммуникации и вычислений MoE в единый детерминированный процесс.
Результаты тестирования впечатляют: команда Cursor сообщает о повышении пропускной способности (throughput) до 2.37 раз по сравнению с сильнейшими публичными базовыми вариантами. MoK уже активно используется для обучения моделей Composer на десятках тысяч GPU. Однако, как и любое передовое технологическое решение, MoK накладывает строгие требования к аппаратному обеспечению, что делает его доступным не для всех, а лишь для организаций с доступом к самым мощным серверным стойкам NVIDIA.
01Что такое Mixture-of-Kittens (MoK) и почему это важно?
Чтобы понять масштаб инновации, нужно взглянуть на архитектуру современных LLM. Модели типа Mixture of Experts (MoE) позволяют создавать огромные модели, которые при инференсе (использовании) активируют лишь небольшую часть параметров. Это делает их эффективными. Однако на этапе обучения (training) процесс становится крайне сложным. Данные должны маршрутизироваться между разными «экспертами» (подмоделями), что требует интенсивного обмена данными между графическими процессорами (GPU).
Проблема заключается в том, что коммуникация между GPU часто становится «узким горлышком» (bottleneck). В традиционных подходах шаги отправки данных (dispatch) и их сбора (combine) выполняются раздельно, что приводит к простоям оборудования. MoK решает эту проблему, сливая все эти операции в одно целое — «мега-ядро». Это не просто оптимизация кода, это фундаментальная переработка того, как данные перемещаются внутри кластера GPU.
Cursor утверждает, что их подход обеспечивает детерминированность вычислений. В контексте обучения AI это критически важно, так как позволяет точно воспроизводить результаты экспериментов, что необходимо для научных исследований и отладки моделей. MoK уже доказал свою состоятельность, работая в продакшене на десятках тысяч GPU, что говорит о его высокой стабильности и масштабируемости.
02Аппаратные требования: барьер входа для новичков
Несмотря на открытость исходного кода под лицензией Apache-2.0, MoK не является решением «для всех». Аппаратный порог входа здесь исключительно высок. Для работы MoK требуется графический процессор архитектуры NVIDIA Blackwell с SM100 или SM103. На практике это означает необходимость использования серверных стоек GB200 NVL72 или GB300 NVL72.
Почему это важно для российского пользователя или исследователя? Потому что доступ к таким мощностям в РФ ограничен санкциями и логистическими сложностями. Реалистичными пользователями MoK становятся:
- Фронтьер-лаборатории (frontier labs) — ведущие мировые ИИ-лаборатории.
- Финансируемые стартапы в сфере ИИ, имеющие доступ к облачным GPU.
- Национальные вычислительные центры.
- Провайдеры GPU-неоклаудов.
Команды, работающие на одном узле или имеющие доступ лишь к ограниченному числу GPU, не смогут извлечь пользу из MoK. Архитектура NVL72 предполагает объединение множества GPU в одной стойке в единый домен NVLink. Это позволяет осуществлять тонкозернистый оверлэп (перекрытие) операций, что невозможно на меньших конфигурациях. Кроме того, требуется программная среда: Python 3.12+, PyTorch 2.10+ и CUDA Toolkit 13.0+. Буферы между GPU опираются на симметричную память PyTorch, что требует глубокой интеграции с экосистемой NVIDIA.
03Эволюция проблемы: от вычислений к коммуникации
Ранее команда Cursor уже работала над оптимизацией вычислительной стороны. Они написали собственные ядра для MXFP8 и NVFP4 (форматы с пониженной точностью для ускорения обучения и инференса), а также разработали путь «warp decode» для MoE-инференса. Однако в реальных условиях производства оказалось, что именно коммуникация между GPU стала главным ограничителем скорости.
Слой MoE может потреблять более половины всего времени обучения модели. Переход на стойки GB300 NVL72 изменил природу проблемы. Хотя множество GPU в одной стойке NVLink позволяют эффективно перекрывать операции, встроенные процессоры Grace CPU оказались относительно медленными по сравнению с мощными GPU. Это создало новую проблему: синхронизация между CPU и GPU стала критической точкой задержки. Поэтому в MoK была предпринята агрессивная попытка минимизировать взаимодействие CPU-GPU, исключив процессор из критического пути выполнения задач.
04Три ключевых архитектурных решения
Успех MoK базируется на трех фундаментальных инженерных решениях, которые кардинально меняют подход к обработке данных в MoE-моделях.
1. Выбор направления коммуникации для каждой операции
Существующие подходы, такие как DeepEP, опираются на передачу данных по принципу «push» (отправка). Однако микробенчмарки Cursor показали, что при push-передаче меньше байтов перемещается в одном направлении, оставляя обратную полосу NVLink практически пустой. Это неэффективно.
MoK использует гибридный подход. Для диспетчеризации (dispatch) в прямом проходе используется принцип pull (запрос данных). Это обеспечивает до 29% более высокой утилизации пропускной способности NVLink при дисбалансе экспертов. Кроме того, pull-механизм устраняет необходимость в сигналах завершения между GPU. Время отправки с
Источник: MarkTechPost ↗