O MoK do Cursor alcança aumento de desempenho de 2,37x no NVIDIA GB300 NVL72

O Cursor lança o MoK de código aberto, integrando o agendamento de tokens, comunicação entre GPUs e cálculo especializado em um único kernel de GPU. A solução alcança ganhos de desempenho de até 2,37x na frente e 1,78x na retaguarda em MXFP8 no GB300 NVL72, aumentando a taxa de throughput de treinamento com 512 GPUs GB300 em 41% até 1070,2 tokens/s. A latência de sinalização cai de 103 μs para 18 μs. Análises indicam que, com a largura de banda NVLink já atingindo 130 TB/s hoje, o tempo de acesso aos dados na GPU tornou-se o novo gargalo de desempenho. Essa inovação marca a entrada da competição em IA na fase de “soberania completa da pilha”, onde empresas cujo código está mais próximo da memória e dos registradores da GPU terão maior poder de precificação.

Autor e fonte do artigo: LeiFeng.com

Em 21 de julho, a NVIDIA divulgou os últimos resultados do treinamento do DeepSeek-V3 com o GB300 NVL72: em 256 GPUs, o desempenho por unidade atingiu 1.648 TFLOPS.

Menos de duas semanas depois, o Cursor abriu o código do Mixture-of-Kittens, abreviado como MoK. Em vez de continuar otimizando multiplicações matriciais mais rápidas, ele reescreveu completamente a camada de execução MoE, integrando o agendamento de tokens, a comunicação entre GPUs e o cálculo dos especialistas em um único kernel de GPU.

Isso é um pouco contra-intuitivo. Como o GB300 NVL72 já colocou 72 GPUs no mesmo domínio NVLink, a largura de banda total NVLink do rack inteiro atingiu 130 TB/s. Pela especificação, a transferência de dados entre as GPUs já deveria ser suficientemente rápida.

No treinamento em larga escala de MoE, a comunicação ainda pode limitar o cálculo dos especialistas.

O problema está no fluxo de dados do MoE. A cada etapa, o roteador decide novamente para qual especialista o token será enviado, e os especialistas estão distribuídos em diferentes GPUs. O token precisa ser primeiro enviado entre os cartões, calculado e depois devolvido; antes do envio, é necessário organizar as posições, e após a chegada, é preciso aguardar a integridade dos dados. À medida que o MXFP8 e o Blackwell Tensor Core reduzem cada vez mais o tempo de cálculo dos especialistas, essas esperas, que antes podiam ser ocultadas atrás do cálculo, estão se tornando cada vez mais visíveis.

Cursor faz MoK começando por aqui. Ele não se concentra apenas em quão rápido uma única Dispatch pode ser transmitida, mas sim reorganiza como os tokens chegam aos especialistas, quando o cálculo começa e como a comunicação e o cálculo compartilham simultaneamente a GPU.

Hoje, com os recursos de hash power empurrados ao limite pelo Blackwell e NVLink, os desenvolvedores descobriram: mesmo que o hardware seja mais rápido, não consegue salvar uma orquestração de software ineficiente.

A abertura do código do MoK não é apenas uma vitória do núcleo; ela marca o início da era em que “a camada de aplicação define os operadores”: para extrair os últimos 30% de poder de processamento, startups de IA estão lançando uma guerra pela soberania da camada inferior.

No entanto, para entender por que esse design do Cursor é eficaz, primeiro é preciso identificar onde o MoE paga o “imposto de comunicação”.

01

O "imposto sobre comunicações" do MoE

Na FFN densa comum, os pesos que os tokens atravessam são basicamente fixos. Após a introdução do Router no MoE, cada token seleciona temporariamente alguns especialistas. Ao utilizar Expert Parallel, os especialistas são divididos entre muitos GPUs, resultando em pelo menos duas rodadas de comunicação entre dispositivos durante uma única passagem para frente.

A primeira rodada é chamada Dispatch, enviando o token para a GPU onde o especialista está; após o cálculo do especialista, os resultados são retornados à posição original do token por meio do Combine. O treinamento também inclui retropropagação, correspondendo a mais duas rodadas de comunicação na direção oposta.

Se for apenas mover um grande bloco contínuo de dados de A para B, o NVLink já é suficientemente rápido. A complexidade do MoE reside no fato de que a distribuição de dados fornecida pelo Router a cada passo é diferente.

Um especialista pode receber muitos tokens nesta etapa e poucos na próxima. O sistema precisa primeiro contar quantos tokens cada especialista possui, depois determinar onde esses tokens devem ser colocados na GPU de destino, e agrupar os dados do mesmo especialista sempre que possível. O Grouped GEMM só consegue obter entradas organizadas e alimentar eficientemente os Tensor Cores.

Após o término da comunicação, ainda não é possível iniciar imediatamente o cálculo. A GPU de destino deve confirmar que todas as gravações remotas foram concluídas e que os dados estão realmente visíveis. A carga dos especialistas também não é totalmente uniforme; algumas GPUs podem terminar cedo, mas ainda assim precisam esperar até que o especialista mais ocupado termine.

Portanto, em uma fase de “comunicação”, misturam-se várias tarefas: transferência de dados, geração de layout, sincronização e desequilíbrio de carga. Os 130 TB/s descrevem a largura de banda pico que todo o rack pode fornecer, mas não significam que cada comunicação dinâmica e fragmentada do MoE consiga saturar simultaneamente todos esses links.

DeepEP já otimizou muito a transferência de dados. É uma biblioteca de comunicação de alto desempenho voltada para Expert Parallel, oferecendo kernels especializados de Dispatch e Combine, suporte a FP8 e permissão para controlar o número de SMs utilizados pela comunicação. A versão mais recente até consegue manter alta taxa de transferência de comunicação com significativamente menos SMs.

Uma única camada MoE ainda precisa realizar constantes transferências entre Dispatch, Grouped GEMM e Combine.

Nesse momento, surge uma contradição prática: se esperar que um número suficiente de tokens esteja disponível antes de calcular, a matriz será grande e os Tensor Cores funcionarão bem, mas o cálculo começará mais tarde; se calcular assim que os tokens chegarem, a comunicação e o cálculo poderão se sobrepor mais cedo, mas a matriz será muito pequena, deixando muitos SMs da GPU sem trabalho suficiente.

Vários streams CUDA permitem que comunicação e computação ocorram em paralelo, mas é difícil garantir sempre que ambos os lados obtenham os recursos de GPU ideais.

O design após o MoK basicamente lida com esse problema de "ritmo".

02

Uma das alterações mais interessantes do MoK foi mudar o Dispatch forward de Push para Pull.

O Push tradicional é intuitivo: quando o GPU de origem tem o token, ele o escreve ativamente no GPU de destino. O problema surge com o endereço de destino. Um único GPU pode receber simultaneamente tokens de muitos outros GPUs.

Cada remetente deve saber antecipadamente em qual seção deve escrever, para não sobrepor-se aos outros; os tokens do mesmo especialista devem ser agrupados continuamente, caso contrário, o GEMM posterior terá que ser reorganizado.

Com o aumento do número de GPUs envolvidas, esse processo de agendamento se torna cada vez mais pesado. O Pull adotou uma abordagem diferente: salva o GPU de destino dos especialistas, que passam a ler os tokens necessários por conta própria. Eles precisam apenas saber em qual GPU de origem o token está e em que posição dos dados de origem ele se encontra; a localização no armazenamento local é decidida por eles mesmos.

Isso elimina a necessidade de coordenação entre múltiplos remetentes para o endereço de destino. Os dados recebidos também podem ser organizados diretamente pelos especialistas locais.

Interessantemente, o Pull não transmite menos dados. No microbenchmark do Cursor, para o mesmo bloco de dados BF16 de 256×256, o Push move aproximadamente 159,6 KB pelo NVLink, enquanto o Pull alcança 172,0 KB, pois a leitura exige envio adicional de solicitações.

A vantagem do Pull está em outro aspecto: a comunicação do MoE é fragmentada e a carga é desequilibrada. Os dois sentidos do NVLink possuem canais independentes, permitindo que o Pull utilize simultaneamente ambos os caminhos: requisições e retorno de dados. Em testes com carga desequilibrada entre especialistas, o Cursor mediu um aumento de até 29% na utilização do NVLink.

A discrepância de sincronização é mais evidente. Após a escrita do Push, a GPU de destino precisa aguardar o sinal de conclusão das outras GPUs; em escalas grandes de Expert Parallel, um rank pode envolver até 71 pares. O Pull é iniciado localmente pela GPU, e assim que os dados retornam, já podem ser utilizados diretamente.

No microbenchmark de múltiplos nós do Cursor, essa latência de sinalização caiu de cerca de 103 microssegundos no Push para 18 microssegundos no Pull.

MoK também não usa Pull em todos os lugares. Para a frente, usa-se Pull Dispatch e Push Combine; para trás, usa-se Pull Reverse-Combine e Push Reverse-Dispatch. Na fase de Dispatch, é necessário reorganizar tokens de muitas fontes em entradas de especialistas; o Pull economiza coordenação. Durante o Combine, já está claro para qual token cada resultado deve retornar, então é mais simples enviar diretamente com Push.

Após alterar a direção da comunicação, o MoK ainda incorporou a comunicação e o cálculo especializado no mesmo Megakernel.

Ele divide os SM da GPU em duas partes. Uma parte é responsável por dispatch, combine e gerenciamento de estado, enquanto a outra executa exclusivamente o Expert FFN. Após receber um lote completo de tokens, a parte de comunicação notifica a parte de cálculo por meio de um contador local da GPU; após o cálculo ser concluído, ela notifica novamente a parte de comunicação para enviar os resultados de volta.

Isso permite decidir diretamente quantos SM usar para comunicação e quantos usar para cálculo, sem deixar totalmente a cargo de múltiplos CUDA Streams competirem entre si. O parâmetro mais crítico aqui é o minibatch, ou seja, quantos tokens são enviados de uma vez para os especialistas calcularem.

Não pode ser muito grande. Ser muito grande significa que os primeiros cálculos demorarão muito para serem concluídos. Também não pode ser muito pequeno. O GEMM especializado acabará por dividir os cálculos em muitas tarefas atribuídas aos SM; se houver muito poucos tokens, o número de tarefas será insuficiente, e muitos SM ficarão ociosos.

O Cursor usa ondas para determinar esse limite. Uma onda completa pode ser simplesmente entendida como todos os cálculos SM tendo recebido tarefas. O MoK deseja que pelo menos dois ciclos completos sejam formados em um único minibatch, para garantir que os Tensor Cores tenham tarefas suficientes para execução contínua.

Os resultados reais são muito esclarecedores. Na arquitetura Kimi 2.5 com Hidden Size de 7168 e dimensão intermediária de especialistas de 2048, o Cursor estima que um minibatch exigirá pelo menos cerca de 2368 tokens. Com 512 tokens, o tempo de forward do MoK é de 5,981 ms; ao aumentar para 2560 tokens, diminui para 3,425 ms. Ao continuar aumentando, a velocidade já não apresenta melhora significativa.

Em outras palavras, dividir a comunicação em partes menores não sempre a torna mais rápida. Uma sobreposição realmente eficiente exige que os dados sejam entregues o mais cedo possível, sem dividir o GEMM em partes excessivamente pequenas.

Mas o MoE ainda tem outro problema: antes que o Router termine, não se sabe exatamente quantos tokens cada GPU receberá por fim.

Se preparar um buffer para o pior cenário, muita memória VRAM será desperdiçada. Se primeiro deixar a GPU contar os tokens e depois notificar a CPU para alocar o espaço correspondente, a GPU terá que parar e esperar pela CPU.

O MoK utiliza um buffer de token de anel de tamanho fixo. Um espaço é primeiro preenchido com tokens enviados para despacho; após os especialistas concluírem os cálculos e o Combine transmitir os resultados, esse espaço é imediatamente reutilizado para o próximo lote de tokens. O Combine do macrobatch anterior pode ocorrer simultaneamente com o despacho do próximo macrobatch.

O Ring Buffer aqui funciona como uma camada de buffer: quando a comunicação ocorre mais rapidamente, os dados se acumulam dentro dele; quando o cálculo consome mais rápido, aguarda o próximo lote de tokens. Todo o processo é impulsionado pelo estado no GPU, sem necessidade de o CPU entrar a cada rodada para decidir o próximo passo.

O Cursor também incorporou a quantização da ativação MXFP8 nos caminhos de dados do Dispatch, Grouped GEMM e SwiGLU, eliminando o kernel de quantização independente e uma leitura e gravação intermediárias na HBM.

Após reunir Pull, minibatch, SM partition e Ring Buffer, o MoK se tornou verdadeiramente uma pipeline MoE contínua.

03

O benchmark do Cursor mede a camada MoE completa, incluindo Schedule, Dispatch, Expert FFN, Combine e a fusão ponderada final, comparando-se com NCCL + PyTorch, DeepEP, TransformerEngine e HybridEP + Megatron.

No GB300 NVL72, em comparação com as melhores linhas de base públicas para cada cenário, o MoK alcança um aumento máximo de 2,37 vezes na forward MXFP8 e 1,78 vezes na backward MXFP8; na forward BF16 e backward BF16, os aumentos máximos são de 1,92 vezes e 1,58 vezes, respectivamente.

Mais importante é o treinamento end-to-end. A solução de produção original do Cursor já utilizava o DeepEP. Ao substituir por MoK em 512 GPUs GB300, o throughput por cartão aumentou de 760,9 tokens por segundo para 1070,2, uma melhoria de aproximadamente 41%.

Também é importante entender os limites deste conjunto de resultados. O Cursor não divulgou o ablate detalhado completo, portanto não é possível determinar com precisão quanto da melhoria de 2,37x vem do Pull, quanto do Megakernel e quanto do Ring Buffer.

Pode-se confirmar individualmente a melhoria do Pull na utilização do NVLink e na latência de sinalização; os demais benefícios decorrem principalmente da combinação de todo o conjunto de abordagens executadas.

MoK também depende fortemente de hardware. Ele é voltado para domínios NVLink de alta velocidade, como Blackwell e NVL72. A leitura remota, a comunicação e a intercalação fina de cálculo são todas baseadas na capacidade das GPUs de acessar a memória de vídeo umas das outras com baixa latência. Ao alterar o tamanho oculto do modelo, Top-k ou a escala dos especialistas, o minibatch adequado e o número de SMs de comunicação também mudam.

Este também é o ponto mais interessante do MoK. No passado, ao discutir otimizações de MoE, era fácil focar apenas em dois números: quantos TFLOPS o GEMM possui e quantos GB/s o All-to-All alcança. Com a geração GB300, simplesmente continuar aumentando esses dois números já não explica mais todo o desempenho.

Quando o token chega, como organizar o layout conforme exigido pelos especialistas, quantos acumular antes de começar a calcular, quantos SM obter na comunicação e quando liberar o buffer — esses detalhes de execução começam a determinar diretamente a velocidade de treinamento.

Um rack com 130 TB/s de largura de banda NVLink ainda exige a reescrita dos kernels da GPU para MoE, justamente porque os links já são rápidos; o que agora precisa ser economizado é o tempo que a GPU gasta aguardando os dados.

O Cursor reescreve o comportamento dos kernels da GPU, marcando a entrada da competição na era da IA 2.0 em uma nova fase de "soberania completa da pilha".

Antes, acreditávamos firmemente que “cada um tem sua especialidade”: quem faz aplicações deveria focar em aplicações (Cursor), e quem faz a camada inferior deveria focar nela (NVIDIA). Mas a atual competição em IA chegou a uma nova fase de “desintermediação”: o Cursor não fez o núcleo porque “quis”, mas porque “teve que fazer”.

DeepSeek abriu uma nova era de extração de engenharia, enquanto o Cursor levou esse fogo até a camada de aplicação. Essa tendência de "desintermediação" está redefinindo o poder de precificação da IA: no futuro, o que determinará a avaliação das empresas de IA não será mais quantos tokens elas possuem, mas quão perto seu código está da memória de vídeo e dos registradores.

As empresas de IA que não conseguem penetrar a caixa preta subjacente acabarão presas no lamaçal do "imposto da mediocridade".