Cursor's MoK демонстрирует повышение производительности на 2,37x на NVIDIA GB300 NVL72

Cursor открыл исходный код MoK, интегрировав планирование токенов, меж-GPU-коммуникацию и вычисления экспертов в один GPU-ядро. Данное решение обеспечивает на GB300 NVL72 повышение производительности прямого прохода до 2,37 раз и обратного прохода до 1,78 раз при использовании MXFP8, а также увеличение пропускной способности обучения на 512 GPU GB300 на 41% до 1070,2 токенов/с. Задержка сигнализации снизилась с 103 мкс до 18 мкс. Анализ показывает, что сегодня, когда пропускная способность NVLink достигла 130 ТБ/с, время передачи данных на GPU стало новым узким местом производительности. Этот прорыв означает, что конкуренция в области ИИ перешла в фазу «полномасштабного суверенитета»: компании, чей код находится ближе к видеопамяти и регистрам, получат большую ценовую власть.

Автор статьи, источник: LeFeng.com

21 июля NVIDIA объявила о новых результатах обучения DeepSeek-V3 с использованием GB300 NVL72: на 256 GPU производительность на один чип достигла 1 648 TFLOPS.

Менее чем через две недели Cursor открыл исходный код Mixture-of-Kittens (MoK). Вместо дальнейших усилий по ускорению матричного умножения, он полностью переписал уровень выполнения MoE, объединив планирование токенов, меж-GPU-коммуникацию и вычисления экспертов в один GPU-ядро.

Это немного противоречит интуиции, поскольку GB300 NVL72 уже разместил 72 GPU в одной доменной сети NVLink, обеспечив общую пропускную способность NVLink всего стойка на уровне 130 ТБ/с. С учетом этих характеристик передача данных между GPU должна быть достаточно быстрой.

В масштабных MoE-обучениях коммуникация все еще замедляет вычисления экспертов.

Проблема заключается в потоке данных MoE. На каждом шаге роутер заново решает, какому эксперту отправить токен, а эксперты распределены по разным GPU. Токен сначала должен быть отправлен через карты, вычислен и затем возвращен обратно; перед отправкой необходимо упорядочить позиции, а после получения — дождаться полноты данных. По мере того как MXFP8 и Blackwell Tensor Core сокращают время вычислений экспертов, эти ожидания, которые ранее могли маскироваться под вычисления, становятся всё более заметными.

Cursor делает MoK, именно с этого места начинается. Он не стремится только к тому, чтобы один Dispatch передавался как можно быстрее, а перестраивает, как токены到达 экспертов, когда начинается подсчет, а также как связь и вычисления одновременно используют GPU.

В эпоху, когда вычислительные ресурсы были доведены до предела с помощью Blackwell и NVLink, разработчики обнаружили: даже самые быстрые аппаратные средства не могут спасти неэффективное программное управление.

Открытие исходного кода MoK — это не только победа ядра, это начало эры, в которой «прикладной уровень определяет операторы»: для извлечения последних 30% вычислительной мощности стартапы в области ИИ ведут войну за власть над базовым уровнем.

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

01

«Налог на связь» MoE

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

Первый этап называется Dispatch: токен отправляется на GPU, где находится эксперт; после завершения вычислений эксперт отправляет результат обратно в исходное положение токена с помощью Combine. Обучение также включает обратное распространение, для которого выполняются еще два этапа связи в обратном направлении.

Если просто переместить большой блок непрерывных данных из A в B, NVLink уже достаточно быстр. Проблема MoE заключается в том, что распределение данных, предоставляемое Router на каждом шаге, различно.

На этом этапе один эксперт может получить много токенов, а на следующем — мало. Система должна сначала подсчитать, сколько токенов у каждого эксперта, затем определить, куда разместить эти токены на целевом GPU, и по возможности группировать данные одного эксперта вместе. Только так Grouped GEMM сможет получить упорядоченные входные данные и эффективно передать их Tensor Core.

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

Таким образом, в рамках одного «коммуникационного» этапа одновременно происходят перенос данных, генерация распределения, синхронизация и дисбаланс нагрузки. Значение 130 ТБ/с описывает пиковую пропускную способность, которую может обеспечить весь стойка, но это не означает, что каждая динамическая и фрагментарная коммуникация MoE сможет одновременно полностью загрузить все каналы.

DeepEP уже обеспечил быструю передачу данных. Это высокопроизводительная библиотека коммуникаций, ориентированная на Expert Parallel, которая предоставляет специализированные ядра Dispatch и Combine, поддерживает FP8 и позволяет управлять количеством SM, используемых для коммуникации. В последней версии можно поддерживать высокую пропускную способность связи при значительно меньшем количестве SM.

Одноуровневая MoE всё ещё должна постоянно передавать данные между Dispatch, Grouped GEMM и Combine.

Возникает следующая практическая дилемма: если дождаться достаточного количества токенов перед вычислением, матрица будет большой, и Tensor Core будут работать эффективно, но вычисления начнутся поздно; если начинать вычисления по мере поступления токенов, коммуникация и вычисления смогут раньше перекрываться, но матрица станет слишком маленькой, и многие SM GPU не получат достаточного объема работы.

Несколько CUDA Stream позволяют выполнять коммуникацию и вычисления параллельно, но сложно всегда обеспечить оптимальное распределение ресурсов GPU на обеих сторонах.

Дизайн после MoK в основном решает эту проблему «ритма».

02

Одним из самых интересных изменений в MoK стало изменение прямой рассылки с Push на Pull.

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

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

С увеличением количества участвующих GPU этот процесс планирования становится все более тяжелым. Pull изменил подход: сохраняет целевой GPU эксперта, который сам извлекает необходимые токены. Ему достаточно знать, на каком исходном GPU находится токен и в какой позиции исходных данных; размещение локально определяется самостоятельно.

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

Интересно, что Pull не передает меньше данных. В микро-бенчмарке Cursor для одного и того же блока данных BF16 размером 256×256 Push перемещает около 159,6 КБ по NVLink, тогда как Pull достигает 172,0 КБ, поскольку для чтения требуется дополнительная отправка запросов.

Преимущество Pull заключается в другом: коммуникация MoE фрагментирована и нагрузка несбалансирована. У NVLink есть отдельные каналы для двух направлений, и Pull может одновременно использовать оба направления — для запросов и возврата данных. В тестах с несбалансированной нагрузкой экспертов Cursor зафиксировал повышение использования NVLink до 29%.

Разрыв синхронизации становится более очевидным. После завершения операции Push целевой GPU должен ждать сигналов о завершении от других GPU; при большом масштабе Expert Parallel один ранг может быть связан максимум с 71 другим пиром. Pull инициируется локальным GPU самостоятельно, и данные можно использовать сразу после их получения.

В многопоточном микро-бенчмарке Cursor задержка сигнализации снизилась с примерно 103 микросекунд при Push до 18 микросекунд при Pull.

MoK также не использует Pull повсюду. В прямом направлении применяются Pull Dispatch и Push Combine; в обратном направлении используются Pull Reverse-Combine и Push Reverse-Dispatch. На этапе Dispatch необходимо переупорядочить токены из многих источников в виде входных данных для экспертов — Pull требует меньше координации. При Combine уже ясно, к какому токену должен вернуться каждый результат, поэтому проще напрямую отправить его с помощью Push.

После изменения направления связи MoK сохранил связь и экспертные вычисления в одном Megakernel.

Он разделяет SM GPU на две части. Одна часть отвечает за диспетчеризацию, объединение и управление состоянием, а другая专门 выполняет экспертные FFN. После получения пакета полных токенов коммуникационная часть уведомляет вычислительную часть с помощью локального счетчика GPU; после завершения вычислений она уведомляет коммуникационную часть передать результат обратно.

Таким образом можно напрямую определить, сколько SM использовать для связи и сколько — для вычислений, не полагаясь полностью на конкуренцию нескольких CUDA Stream. Ключевым параметром здесь является minibatch — количество токенов, передаваемых экспертам за один раз.

Он не может быть слишком большим. Слишком большой размер означает, что первые вычисления будут долго ждать. Он также не может быть слишком маленьким. Экспертная GEMM в конечном итоге должна быть разбита на множество вычислительных задач, распределяемых между SM; если токенов слишком мало, количество задач будет недостаточным, и многие SM будут простаивать.

Cursor использует wave для определения этого порога. Полный wave можно просто понимать как ситуацию, когда все вычисления SM получили задачи. MoK хочет, чтобы мини-пакет содержал как минимум два полных wave, чтобы Tensor Core имел достаточный объем задач для непрерывного выполнения.

Фактические результаты говорят сами за себя. На модели Kimi 2.5 с скрытым размером 7168 и промежуточным измерением экспертов 2048 Cursor оценивает, что мини-пакету требуется как минимум около 2368 токенов. При 512 токенах время прямого прохода MoK составляет 5,981 мс; при увеличении до 2560 токенов оно снижается до 3,425 мс. Дальнейшее увеличение не приводит к значительному улучшению скорости.

Другими словами, более мелкое разбиение коммуникации не всегда ускоряет процесс. Эффективное перекрытие требует ранней передачи данных, при этом не слишком мелкого разбиения GEMM.

Однако у MoE есть еще одна проблема: до завершения работы роутера невозможно знать, сколько токенов в итоге получит каждая GPU.

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

MoK использует Ring Token Buffer фиксированного размера. Пространство сначала заполняется токенами, поступающими в Dispatch; после завершения вычислений экспертом и передачи результата Combine, это пространство немедленно повторно используется для следующей партии токенов. Combine предыдущего макробатча может выполняться одновременно с Dispatch следующего макробатча.

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

Cursor также встроил квантование MXFP8 в пути данных Dispatch, Grouped GEMM и SwiGLU, устранив отдельный квантовый ядро и сократив количество чтений и записей промежуточных результатов в HBM.

После объединения Pull, minibatch, SM-разделов и Ring Buffer MoK действительно превращается в непрерывную MoE-конвейерную систему.

03

Бенчмарк Cursor измеряет полный слой MoE, включая планирование, маршрутизацию, экспертизные FFN, объединение и итоговое взвешенное слияние, с сравнением с NCCL + PyTorch, DeepEP, TransformerEngine и HybridEP + Megatron.

На GB300 NVL72 MoK демонстрирует максимальное ускорение в 2,37 раза для прямого прохода и в 1,78 раза для обратного прохода по сравнению с лучшими открытыми базовыми линиями для каждого сценария; для BF16 максимальное ускорение составляет 1,92 раза для прямого прохода и 1,58 раза для обратного прохода.

Более важно энд-ту-энд обучение. Исходная производственная схема Cursor уже использовала DeepEP. После замены на MoK на 512 GPU GB300 пропускная способность на один чип увеличилась с 760,9 токена в секунду до 1070,2, что составляет повышение примерно на 41%.

Также необходимо учитывать границы этой группы результатов. Cursor не опубликовал полный поэлементный абляционный анализ, поэтому невозможно точно определить, какая часть из 2,37 раз приходится на Pull, какая на Megakernel и какая на Ring Buffer.

Можно с уверенностью утверждать, что Pull улучшает использование NVLink и задержку сигнализации; остальные преимущества обусловлены комбинацией всей системы выполнения.

MoK также сильно зависит от аппаратного обеспечения. Он ориентирован на высокоскоростные NVLink-домены, такие как Blackwell и NVL72. Дистанционное чтение, коммуникация и тонкое чередование вычислений основаны на способности GPU низколатентно обращаться к памяти друг друга. При изменении таких параметров модели, как размер скрытого слоя, Top-k и количество экспертов, соответствующие размеры мини-пакетов и количество коммуникационных SM также меняются.

Это также самое важное место MoK. Раньше при обсуждении оптимизации MoE легко фокусироваться на двух цифрах: сколько TFLOPS в GEMM и сколько GB/s в All-to-All. В поколении GB300 одного лишь увеличения этих двух цифр уже недостаточно, чтобы объяснить всю производительность.

Когда придет токен, как расположить его в соответствии с требуемой схемой эксперта, сколько накопить для начала расчета, сколько SM получить для связи, когда освободить буфер — эти детали исполнения напрямую определяют скорость обучения.

Стойка с пропускной способностью NVLink 130 ТБ/с всё равно требует переписывания ядер GPU для MoE — именно здесь причина: соединения уже достаточно быстрые, теперь нужно экономить время, которое GPU тратит на получение данных.

Поведение Cursor при перезаписи ядер GPU знаменует переход конкуренции в эпоху AI 2.0 на новый этап «полномасштабного суверенитета».

Раньше мы верили в принцип «каждый должен заниматься своим делом»: если делаешь приложения — делай приложения (Cursor), если делаешь нижний уровень — делай нижний уровень (NVIDIA). Но сегодня конкуренция в области ИИ достигла новой стадии «обхода посредников»: Cursor не стал разрабатывать ядро потому, что «хотел», а потому, что «вынужден».

DeepSeek открыл новую эпоху инженерного извлечения, а Cursor разжёг этот огонь на уровне приложений. Эта тенденция «обхода посредников» перестраивает власть над ценообразованием ИИ: в будущем оценка компаний ИИ будет определяться не количеством токенов, которыми они владеют, а тем, насколько близко их код находится к видеопамяти и регистрам.

Компании ИИ, которые не могут проникнуть сквозь нижележащий черный ящик, в конечном итоге останутся в болоте «налога на посредственность».