Cursor abre código do Mixture-of-Kittens: kernel MoE que acelera treinamento em GPUs Blackwell em até 2,37×

O que é o Mixture-of-Kittens (MoK)

A Cursor Research acaba de abrir o código do Mixture-of-Kittens (MoK), o megakernel de treinamento Mixture-of-Experts (MoE) que alimenta seus modelos Composer. O MoK funde toda a comunicação e computação de camadas MoE em um único kernel determinístico, projetado especificamente para racks NVIDIA GB300 NVL72 com GPUs Blackwell.

O resultado: até 2,37× mais velocidade que o baseline público mais rápido em forward MXFP8, e 1,41× de ganho end-to-end em testes com 512 GPUs distribuídas em múltiplos racks GB300 NVL72. O código está no GitHub sob licença Apache 2.0.

Por que a camada MoE virou o gargalo

Em produção, a camada MoE pode consumir mais da metade do tempo total de treinamento. Com a transição para racks NVL72 — 72 GPUs dentro de um único domínio NVLink — o problema muda de figura. A largura de banda NVLink permite sobreposição fina entre comunicação e computação, mas as CPUs Grace integradas são lentas em relação às GPUs. A sincronização CPU-GPU precisa ser minimizada agressivamente.

A Cursor já tinha desenvolvido kernels próprios para MXFP8 e NVFP4, além de um caminho de inferência MoE com “warp decode”. Mas todos assumiam que a comunicação entre GPUs era tratada separadamente — e era exatamente ali que o tempo estava sendo perdido.

As três decisões de design que fazem a diferença

1. Direção de comunicação escolhida por operação. Abordagens existentes como DeepEP usam transferências push. A Cursor mostrou que dispatch baseado em pull entrega até 29% mais utilização de banda NVLink sob desbalanceamento de experts. O sinal de conclusão cross-GPU cai de 103 µs (push) para 18 µs (pull) — uma redução de 5,8×. O MoK usa pull para forward dispatch, push para forward combine, e espelha no backward.

2. Granularidade de sobreposição no ponto ideal. Nem tão fino quanto o Comet, nem tão grosso quanto o DeepEP. A heurística da Cursor garante pelo menos duas ondas SM completas por GEMM agrupada por expert. Para o modelo base do Composer 2.5 (Kim 2.5), o piso é 2.368 tokens — e a latência medida confirma a estimativa.

3. Buffer em anel elimina a CPU do loop. As alternativas são descartar tokens ou pedir à CPU para dimensionar buffers. O MoK usa um buffer em anel fixo de algumas centenas de megabytes, ciclando em granularidade de minibatch e intercalando dispatch e combine nos limites de macrobatch. O anel é percorrido em ordem reversa para minimizar replay de ativação no backward.

O que isso significa na prática

O MoK já está em produção treinando modelos Composer em dezenas de milhares de GPUs. Os benchmarks mostram que, em uma única rack NVL72 com 64 GPUs em paralelo (EP degree 64), cada GPU processando 2.048 tokens antes do roteamento, o MoK supera consistentemente NCCL+PyTorch, DeepEP+PyTorch, DeepEP+TransformerEngine e HybridEP+Megatron — cobrindo shapes de modelos como Kimi K2.7 Code, GLM-5.2, Qwen3.5-397B e DeepSeek-V4-Pro.

Mas o piso de hardware é alto. MoK exige GPUs Blackwell SM100 ou SM103, racks GB200 ou GB300 NVL72, Python 3.12+, PyTorch 2.10+ e CUDA toolkit 13.0+. Isso limita os adotantes realistas a laboratórios de fronteira, startups de modelos financiadas, neoclouds de GPU e centros de computação nacionais. Times com 8 GPUs não entram nessa.

Por que isso importa

O MoK representa uma tendência mais ampla: a verticalização do software de infraestrutura de IA. Não basta mais ter acesso a GPUs — é preciso escrever kernels especializados para extrair performance delas. A Cursor está seguindo o caminho de empresas como DeepSeek, que também desenvolveram kernels MoE próprios. A diferença é que a Cursor está abrindo o código.

Para o ecossistema open-source de IA, isso significa que treinar modelos MoE grandes em hardware de ponta acaba de ficar mais eficiente — para quem tem acesso a esses racks.