Cursor's MoK logra un aumento del 2.37x en el rendimiento en NVIDIA GB300 NVL72

Cursor abre el código de MoK, integrando la programación de tokens, la comunicación entre GPUs y el cálculo de expertos en un mismo núcleo de GPU. Esta solución logra un aumento de rendimiento de hasta 2.37 veces en la forward y 1.78 veces en la backward en MXFP8 en GB300 NVL72, con un aumento del 41% en el rendimiento de entrenamiento hasta 1070.2 tokens/s utilizando 512 GPUs GB300. La latencia de señalización se reduce de 103 μs a 18 μs. El análisis indica que, con el ancho de banda NVLink ya alcanzando los 130 TB/s, el tiempo de acceso a los datos en la GPU se ha convertido en el nuevo cuello de botella de rendimiento; este avance marca el ingreso a la fase de “soberanía completa de la pila”, donde las empresas que acercan más el código a la memoria de la GPU y a los registros tendrán mayor poder de fijación de precios.

Autor del artículo, fuente: LeFeng.com

El 21 de julio, NVIDIA anunció los últimos resultados del entrenamiento de DeepSeek-V3 con GB300 NVL72: en 256 GPU, el rendimiento por tarjeta alcanzó 1.648 TFLOPS.

Menos de dos semanas después, Cursor abrió el código de Mixture-of-Kittens, conocido como MoK. En lugar de seguir optimizando la multiplicación de matrices más rápida, reescribió directamente una capa de la ejecución de MoE, integrando la programación de tokens, la comunicación entre GPUs y el cálculo de expertos en un mismo kernel de GPU.

Esto es un poco contraintuitivo. Ya que GB300 NVL72 ha colocado 72 GPU dentro del mismo dominio NVLink, el ancho de banda total NVLink del rack completo alcanza los 130 TB/s. Según esta especificación, la transferencia de datos entre las GPU debería ser lo suficientemente rápida.

En el entrenamiento a gran escala de MoE, la comunicación aún puede ralentizar el cálculo de los expertos.

El problema está en el flujo de datos del MoE. Cada paso, el router vuelve a decidir a qué experto envía cada token, y los expertos están distribuidos en diferentes GPU. El token primero debe enviarse entre tarjetas, calcularse y luego devolverse; antes de enviarlo, se debe organizar su ubicación, y al llegar, se debe esperar a que los datos estén completos. A medida que MXFP8 y los Blackwell Tensor Core reducen cada vez más el tiempo de cálculo de los expertos, estas esperas que antes se ocultaban detrás del cálculo se vuelven cada vez más evidentes.

Cursor hace MoK, y es por aquí desde donde se debe actuar. No solo se enfoca en cuán rápido se puede enviar un solo Dispatch, sino que reorganiza cómo llegan los tokens a los expertos, cuándo comienza el cálculo y cómo la comunicación y el cálculo comparten simultáneamente la GPU.

Hoy, cuando los recursos de hash se han llevado al límite con Blackwell y NVLink, los desarrolladores han descubierto: aunque el hardware funcione más rápido, no puede salvar una programación de software ineficiente.

La apertura de MoK no es solo una victoria del núcleo; marca el comienzo de la era en la que "la capa de aplicaciones define los operadores": para extraer los últimos el 30% de la capacidad de cómputo, las startups de IA están librando una guerra por la soberanía subyacente.

Sin embargo, para entender por qué funciona este diseño de Cursor, primero hay que identificar en qué punto el MoE paga el "impuesto de comunicación".

01

El "impuesto de comunicación" de MoE

En una FFN densa normal, los pesos que atraviesa cada token son基本mente fijos. Tras la incorporación del Router en MoE, cada token selecciona temporalmente varios expertos. Al utilizar Expert Parallel, los expertos se dividen en múltiples GPU, por lo que una sola propagación hacia adelante requiere al menos dos rondas de comunicación entre tarjetas.

La primera ronda se llama Dispatch, que envía el token a la GPU donde se encuentra el experto; una vez que el experto completa el cálculo, Combine envía el resultado de vuelta a la posición original del token. El entrenamiento también incluye la propagación hacia atrás, lo que implica ejecutar dos rondas adicionales de comunicación en dirección opuesta.

Si solo se trata de mover un gran bloque de datos continuos de A a B, NVLink ya es lo suficientemente rápido. La complejidad de MoE radica en que la distribución de datos proporcionada por el Router varía en cada paso.

Un experto podría recibir muchos tokens en este paso y muy pocos en el siguiente. El sistema debe primero contar cuántos tokens tiene cada experto, luego determinar dónde colocar esos tokens en la GPU objetivo, y agrupar los datos del mismo experto siempre que sea posible. Solo así, el GEMM agrupado podrá recibir entradas organizadas y alimentar eficientemente los Tensor Cores.

Después de finalizar la comunicación, no se puede iniciar inmediatamente el cálculo. La GPU objetivo debe confirmar que todas las escrituras remotas se han completado y que los datos son efectivamente visibles. La carga de los expertos tampoco es completamente uniforme; algunas GPU podrían terminar antes, pero aún así deben esperar a que el experto más ocupado finalice.

Entonces, en una fase de "comunicación", se mezclan varias tareas: transferencia de datos, generación de diseño, sincronización y desequilibrio de carga. Los 130 TB/s describen el ancho de banda pico que puede proporcionar todo el bastidor, pero no significa que cada comunicación dinámica y fragmentada de MoE pueda llenar simultáneamente todos estos enlaces.

DeepEP ya ha optimizado muy rápidamente la transferencia de datos. Es una biblioteca de comunicación de alto rendimiento orientada a Expert Parallel, que ofrece kernels especializados de Dispatch y Combine, admite FP8 y permite controlar la cantidad de SM utilizados para la comunicación. La versión más reciente incluso puede mantener un alto rendimiento de comunicación con una cantidad significativamente menor de SM.

Una sola capa MoE aún debe realizar constantes intercambios entre Dispatch, Grouped GEMM y Combine.

En este momento se presenta una contradicción práctica: si se espera a que llegue suficiente cantidad de tokens antes de calcular, la matriz es grande y los Tensor Core funcionan eficientemente, pero el cálculo se inicia tarde; si se calcula a medida que llegan los tokens, la comunicación y el cálculo pueden superponerse antes, pero la matriz es demasiado pequeña y muchos SM de la GPU no tienen suficiente trabajo.

Múltiples CUDA Stream permiten que la comunicación y el cálculo se realicen en paralelo, pero es difícil garantizar siempre que ambos lados obtengan los recursos de GPU adecuados.

El diseño detrás de MoK trata básicamente este problema de "ritmo".

02

Uno de los cambios más interesantes en MoK fue cambiar el Dispatch hacia adelante de Push a Pull.

El Push tradicional es intuitivo: si la GPU fuente tiene el token, lo escribe activamente en la GPU de destino. El problema surge con la dirección de destino. Una GPU recibe simultáneamente muchos tokens provenientes de otras GPUs.

Cada remitente debe saber de antemano en qué sección debe escribir, para evitar superposiciones; los tokens del mismo experto deben estar agrupados de forma continua, de lo contrario, la GEMM posterior tendrá que reorganizarse nuevamente.

A medida que participan más GPU, este proceso de programación se vuelve cada vez más pesado. Pull cambió el enfoque: guarda el GPU objetivo del experto para que él mismo lea los tokens necesarios. Solo necesita saber en qué GPU de origen se encuentra el token y en qué posición dentro de los datos de origen; la ubicación local de almacenamiento la decide él mismo.

Esto elimina la necesidad de coordinar entre múltiples remitentes para la dirección de destino. Los datos recibidos también pueden organizarse directamente según los expertos locales.

Es interesante que Pull no transfirió menos datos. En la microprueba de Cursor, para el mismo bloque de datos BF16 de 256×256, Push movió aproximadamente 159,6 KB a través de NVLink, mientras que Pull alcanzó 172,0 KB, ya que la lectura requiere enviar solicitudes adicionales.

Pull gana en otro aspecto: la comunicación en MoE es fragmentada y la carga no está equilibrada. Los dos direcciones de NVLink tienen canales independientes, lo que permite a Pull aprovechar simultáneamente las solicitudes y la devolución de datos. En pruebas con carga desequilibrada de expertos, Cursor midió un aumento del 29% en la utilización de NVLink.

La discrepancia en la sincronización es más evidente. Después de que se completa la operación Push, la GPU objetivo debe esperar la señal de finalización de las otras GPUs; cuando se utiliza Expert Parallel con un tamaño grande, un rank puede involucrar hasta 71 pares adicionales. Pull es iniciado localmente por la GPU, y una vez que los datos regresan, pueden utilizarse directamente.

En el microbenchmark de múltiples nodos de Cursor, esta latencia de señalización disminuyó de aproximadamente 103 microsegundos en Push a 18 microsegundos en Pull.

MoK tampoco usa Pull en todos los lugares. En la dirección directa se utiliza Pull Dispatch y Push Combine; en la dirección inversa se emplean Pull Reverse-Combine y Push Reverse-Dispatch. En la fase de Dispatch, es necesario reorganizar los tokens de múltiples fuentes en entradas para expertos; Pull requiere menos coordinación. Durante Combine, ya está claro a qué token debe regresar cada resultado, por lo que es más sencillo devolverlo directamente mediante Push.

Después de cambiar la dirección de la comunicación, MoK aún incorpora la comunicación y el cálculo experto en el mismo Megakernel.

Divide el SM de la GPU en dos partes. Una parte se encarga de la asignación, combinación y gestión de estado, mientras que la otra se dedica exclusivamente a ejecutar el Expert FFN. Una vez que el lado de comunicación recibe un lote de tokens completos, notifica al lado de cálculo mediante un contador local de la GPU; una vez completado el cálculo, notifica al lado de comunicación para que envíe los resultados de regreso.

Esto permite decidir directamente cuántos SM usar para comunicación y cuántos para cálculo, sin dejarlo completamente a la competencia de múltiples CUDA Streams. El parámetro más clave aquí se llama minibatch, es decir, cuántos tokens se entregan a la vez a los expertos para su cálculo.

No puede ser demasiado grande. Ser demasiado grande significa que los primeros cálculos tardarán mucho en completarse. Tampoco puede ser demasiado pequeño. La GEMM experta finalmente debe dividirse en una gran cantidad de tareas de cálculo para asignarlas a los SM; si hay demasiados tokens, el número de tareas no será suficiente y muchos SM quedarán inactivos.

Cursor utiliza una wave para determinar este límite. Una wave completa se puede entender simplemente como que todos los cálculos SM han recibido tareas. MoK desea que al menos un minibatch forme dos waves completas, para que los Tensor Core tengan suficientes tareas para ejecutar de forma continua.

Los resultados reales son muy reveladores. En la forma de Kimi 2.5 con Hidden Size de 7168 y dimensión intermedia de expertos de 2048, Cursor estima que el minibatch requiere al menos unos 2368 tokens. Con 512 tokens, el tiempo de forward de MoK es de 5.981 ms; al aumentar a 2560 tokens, disminuye a 3.425 ms. Al seguir aumentando, la velocidad ya no mejora significativamente.

En otras palabras, dividir la comunicación en partes más pequeñas no siempre la hace más rápida. Una superposición realmente eficiente requiere que la comunicación entregue los datos lo antes posible, sin dividir demasiado el GEMM.

Pero el MoE tiene otro problema: antes de que el Router termine, no se sabe cuántos tokens recibirá finalmente cada GPU.

Si se prepara un buffer según el peor caso, se desperdiciará mucha memoria VRAM. Si primero se deja que la GPU cuente los tokens y luego se notifique a la CPU para asignar el espacio correspondiente, la GPU tendrá que detenerse y esperar a la CPU.

MoK utiliza un búfer de tokens Ring de tamaño fijo. Un espacio de memoria primero almacena los tokens enviados por Dispatch; después de que los expertos terminen el cálculo y Combine transfiera los resultados, ese espacio se reutiliza inmediatamente para el siguiente lote de tokens. La operación Combine del macrobatch anterior puede realizarse simultáneamente con la operación Dispatch del siguiente macrobatch.

El Ring Buffer aquí funciona como una capa de buffer: si la comunicación avanza temporalmente más rápido, los datos se acumulan dentro; si el cálculo consume más rápido, se espera la próxima serie de tokens. Todo el proceso avanza mediante el estado en la GPU, sin necesidad de que la CPU intervenga en cada ciclo para decidir el siguiente paso.

Cursor también integró la cuantización de MXFP8 en las rutas de datos de Dispatch, Grouped GEMM y SwiGLU, eliminando el kernel de cuantización independiente y una lectura/escritura adicional del resultado intermedio en la HBM.

Después de combinar Pull, minibatch, SM partition y Ring Buffer, MoK se convierte realmente en una tubería MoE continua.

03

El benchmark de Cursor mide la capa MoE completa, incluyendo Schedule, Dispatch, Expert FFN, Combine y la fusión ponderada final, comparándola con NCCL + PyTorch, DeepEP, TransformerEngine y HybridEP + Megatron.

En GB300 NVL72, MoK logra un aumento máximo de 2.37 veces en la forward y de 1.78 veces en la backward en comparación con las mejores líneas de base públicas por escenario; para BF16, los aumentos máximos son de 1.92 veces en la forward y 1.58 veces en la backward.

Más importante aún es el entrenamiento de extremo a extremo. La solución de producción original de Cursor ya utilizaba DeepEP. Al reemplazarlo por MoK en 512 GPU GB300, el rendimiento por tarjeta aumentó de 760.9 tokens por segundo a 1070.2, lo que representa un aumento de aproximadamente un 41%.

También debe tener en cuenta los límites de estos resultados. Como Cursor no ha publicado el ablate detallado completo, no se puede determinar con precisión cuánto de la mejora de 2.37 veces proviene de Pull, cuánto de Megakernel y cuánto de Ring Buffer.

Lo que se puede confirmar por separado es la mejora de Pull en la utilización de NVLink y la latencia de señalización; el resto de los beneficios provienen principalmente de la combinación de todo el conjunto de métodos de ejecución.

MoK también depende fuertemente del hardware. Está orientado a dominios NVLink de alta velocidad como Blackwell y NVL72. Las lecturas remotas de Pull, la comunicación y la intercalación fina de cálculo se basan en la capacidad de las GPU para acceder con baja latencia a la memoria de las demás. Al cambiar el tamaño oculto del modelo, Top-k o la escala de expertos, también cambian el minibatch adecuado y la cantidad de SM de comunicación.

Este es también el aspecto más interesante de MoK. Anteriormente, al discutir la optimización de MoE, era fácil centrarse únicamente en dos números: cuántos TFLOPS tiene el GEMM y cuántos GB/s tiene el All-to-All. Con la generación GB300, simplemente seguir aumentando estos dos números ya no explica todo el rendimiento.

Cuándo llega el token, cómo organizarlo en el formato requerido por los expertos, cuánto acumular antes de comenzar el cálculo, cuánto SM tomar para la comunicación, cuándo liberar el buffer: estos detalles de ejecución determinan directamente la velocidad de entrenamiento.

Un rack con un ancho de banda NVLink de 130 TB/s aún requiere reescribir los kernels de GPU para MoE, y la razón es esta: los enlaces ya son lo suficientemente rápidos; ahora lo que se debe ahorrar es el tiempo que la GPU espera los datos.

El comportamiento de reescritura de kernels de GPU por Cursor marca que la competencia en la era de la IA 2.0 ha entrado en una nueva fase de "soberanía de toda la pila".

Antes, creíamos firmemente en la especialización: si hacías aplicaciones, debías hacer aplicaciones (Cursor); si hacías capas subyacentes, debías hacer capas subyacentes (NVIDIA). Pero ahora, la competencia en IA ha llegado a una nueva etapa de “desintermediación”: Cursor no hizo su núcleo porque “quería”, sino porque “tenía que”.

DeepSeek ha iniciado una nueva era de extracción de ingeniería, mientras que Cursor ha llevado este fuego hasta la capa de aplicación. Esta tendencia de "desintermediación" está redefiniendo el poder de fijación de precios en la IA: en el futuro, lo que determine la valoración de las empresas de IA ya no será cuántos tokens poseen, sino qué tan cerca está su código de la memoria de video y los registros.

Las empresas de IA que no puedan penetrar la caja negra subyacente quedarán atrapadas en el fango del "impuesto a la mediocridad".