Megakernel da Cursor Melhora Throughput de Treinamento de GPU em 1.41x em Racks Blackwell

Em 4 de agosto de 2026, Cursor abriu o código-fonte do Mixture-of-Kittens (MoK), um megakernel que elevou o throughput de treinamento end-to-end em 1.41x em 512 GPUs GB300, enquanto o Latent Space Inference Engineering Masterclass publicou argumentos sobre por que megakernels estão obsoletos. A colisão esclareceu uma tensão real: se megakernels estão mortos depende do seu hardware e da sua carga de trabalho.

O caso contra: megakernels eliminam overhead de lançamento de kernel e latência de sincronização entre kernels, mas escrever um é difícil. Empresas que os constroem geralmente não os executam em produção—otimização por kernel mais sobreposição de agendador supera um kernel fundido monolítico, já que cada componente pode ser otimizado e canalizado independentemente em paralelo. O paralelismo de tensor impõe um limite: quando metade de uma matriz vive na GPU 1 e metade na GPU 2, operações como softmax exigem um all-reduce antes de prosseguir. Fusão não pode eliminar essa barreira de comunicação. NVIDIA também está resolvendo sincronização em hardware. Kyle Kranen anunciou que Rubin introduz gatilhos de dependência no nível de tile, permitindo que o kernel N+1 lance CTAs para um tile no momento em que o kernel N o termina, sem esperar por atrasados. Isso é o que megakernels faziam anteriormente em código CUDA.

A liberação da Cursor argumentou o oposto para camadas MoE em racks NVL72. MoE consome mais de metade do tempo de treinamento end-to-end. Um GB300 NVL72 é 72 GPUs em um único domínio NVLink—a topologia de comunicação difere qualitativamente de um cluster DGX. CPUs Grace integradas são lentas em relação às GPUs: fluxos de GPU esperavam regularmente por trabalho de CPU (logging, métricas), deixando a GPU ociosa. Apenas um megakernel pode eliminar sincronização entre CPU e GPU inteiramente; kernels individuais não podem.

Números de MoK: MXFP8 forward executa 2.37x mais rápido que a baseline pública mais rápida (DeepEP+TransformerEngine, HybridEP+Megatron) em grau EP 64 com 2.048 tokens por GPU. BF16 é 1.92x. End-to-end, tokens por segundo por GPU aumentaram de 760,9 para 1.070,2—um ganho de 1.41x. Dispatch baseado em pull em vez do design baseado em push da DeepEP responde por parte da diferença: pull deixa as lanes NVLink reversas principalmente ociosas; pull consegue 29% maior utilização de largura de banda NVLink sob desequilíbrio de expert. Overhead de sinalização cai de 103 µs para 18 µs. Um buffer de token em anel chamado macrobatch passa por um buffer de tamanho fixo em granularidade de minibatch sem travar a GPU ou descartar tokens.

MoK requer NVIDIA Blackwell SM100 ou SM103—ou seja, racks GB200 NVL72 ou GB300 NVL72 especificamente. Precisa de CUDA 13.0+, PyTorch 2.10+, Python 3.12+. Buffers inter-GPU usam memória simétrica PyTorch, que é apenas Blackwell. Execuções em nós DGX H100 ou B200 não serão compiladas. O projeto é licenciado Apache-2.0 e já alimenta o treinamento do modelo Composer da Cursor em dezenas de milhares de GPUs.

Em clusters de commodities e hardware Rubin, divisão de kernel mais CTA scheduling no nível de hardware é cada vez mais viável com muito menor burden de manutenção—sem pass forward fundido manualmente de 67.000 linhas para debugar. Em racks NVL72, onde gargalo de CPU Grace e topologia NVLink criam restrições distintas, fusão ainda vence por uma margem que justifica o custo de engenharia. Se throughput MoE é seu gargalo de treinamento e você possui capacidade NVL72, avalie MoK contra sua stack DeepEP atual antes de Rubin ser lançado.