El equipo de SGLang y el equipo Ling Infra de Ant Group publicaron el 21 de agosto un informe conjunto de optimización: al ejecutar Ling-3.0-flash en cuatro GPU Blackwell, redujeron el tiempo por token de salida (TPOT) con concurrencia 1 de 3,33 milisegundos a 1,53 milisegundos, una caída del 54%, mientras el rendimiento subió de 288 a 606 tokens por segundo. Al incorporar su propio modelo borrador DSpark, el TPOT promedio bajó aún más, a 0,78 milisegundos, el rendimiento llegó a 1120 tokens por segundo, y en promedio se aceptaron 9,95 tokens borrador por ronda.
Ling-3.0-flash es un modelo MoE de atención lineal híbrida: de sus 42 capas, 35 usan atención lineal KDA y 7 usan atención completa MLA, con 512 expertos de enrutamiento, un ancho de capa oculta de 2560 y un vocabulario de unos 157.000 tokens. En bf16, cada tarjeta necesita cargar unos 63 GB de pesos. Para la prueba se dividió en 4 partes mediante paralelismo de tensores, también en bf16.
La que en realidad está inactiva es la GPU
Esta optimización se centra en el escenario donde el tamaño de lote es igual a 1. La mayoría de los resultados públicos de optimización de inferencia se enfocan en maximizar el rendimiento total con alta concurrencia, porque así es como facturan los proveedores de nube. Otro tipo de carga se siente de forma más directa: concurrencia igual a 1 —ejecutar modelos localmente, autocompletado de código, un agente que ejecuta en serie una cadena larga—; solo hay una solicitud corriendo a la vez y el usuario mira la pantalla esperando que aparezcan las palabras.
Cuando baja la concurrencia, la GPU queda inactiva. La carga computacional de cada paso de decodificación es tan pequeña que resulta insignificante; la GPU termina su trabajo y espera el siguiente lote de instrucciones, que provienen de la CPU. En cuanto el lado del host necesita leer de vuelta un valor de la memoria de la GPU para decidir el siguiente paso, toda la canalización debe detenerse a esperar esa sincronización.
"at batch 1, look for blocking reads of device values on the host path before anything else, because each one converts the entire host loop from hidden work into a GPU bubble."
Con concurrencia 1, lo primero es buscar las lecturas bloqueantes de valores del dispositivo en la ruta del host, porque cada una convierte ese trabajo oculto del host en una burbuja en la GPU.
Eliminar las esperas una por una
La primera categoría es el tiempo muerto del host. La solución consiste en eliminar los puntos de sincronización de la GPU en cada paso: en el backend de atención KDA se establece que no es necesario leer de vuelta la longitud de secuencia hacia la CPU, de modo que los índices relacionados permanezcan siempre en la memoria de la GPU. Así, las instrucciones del paso k+1 pueden enviarse incluso sin saber todavía cuántos tokens borrador se aceptaron en el paso k, y el host ya no tiene que esperar el resultado.
La segunda categoría acorta el trabajo en la ruta crítica de la GPU. Con el lanzamiento dependiente programático (PDL) se adelanta la carga de pesos que no depende de la salida del kernel anterior; el enrutamiento y el MoE se fusionan de dos lanzamientos de kernel a uno solo, y con una escala de 512 expertos, el simple costo de lanzamiento ya es considerable; la precisión de cálculo de la puerta de enrutamiento y de lm_head pasó de fp32 a bf16, lo que por sí solo aportó cerca de un 10% de mejora. El estado cíclico de KDA bajo decodificación especulativa ahora se actualiza por etapas y solo se confirma tras pasar la verificación.
Todos estos cambios se integraron en SGLang: la captura de metadatos junto con los grafos, un kernel de verificación KDA fusionado, un plan de FlashInfer emitido directamente por el host (que evita las lecturas bloqueantes de la memoria de la GPU) y un orden de programación que fusiona los pasos de borrador, verificación y expansión.
Traducido a tiempo perceptible para las personas
Un cálculo aproximado para una respuesta larga de 5000 tokens: a 3,33 milisegundos por token, terminar de escribir tarda 16,6 segundos; a 1,53 milisegundos son 7,7 segundos; a 0,78 milisegundos, 3,9 segundos. La misma máquina, el mismo modelo, la misma persona esperando: la diferencia pasa de 'volver con una taza de té' a 'terminar antes de acabar la frase'. Esa diferencia no viene de cambiar de GPU, sino de eliminar por completo la espera del lado del host.
El número clave de DSpark es la longitud de aceptación promedio de 9,95. La lógica de la decodificación especulativa es que el modelo pequeño adivine primero una secuencia y el modelo grande la verifique de una sola vez: cuanto más acierte, más pasos se ahorran gratis. Una longitud de aceptación cercana a 10 significa que cada verificación del modelo grande equivale a casi diez pasos de decodificación normal. Esta cifra está directamente relacionada con la forma de entrenar el modelo borrador: el modelo borrador de DSpark se destiló a partir de la distribución de salida de Ling-3.0-flash después de su post-entrenamiento, y su función de pérdida incluye un término de optimización específico para la longitud de aceptación. Acertar tanto es el resultado del entrenamiento, no de la suerte.
Una colaboración aguas arriba
Detrás de este informe hay tres firmantes: RadixArk por parte de SGLang, el equipo Ling Infra de Ant y inclusionAI de Ant. Los pesos del modelo y los comandos de reproducción se publicaron junto con la variante DSpark.
Que los modelos de código abierto chinos aparezcan en las clasificaciones ya no sorprende a nadie en los últimos años; lo que sí sorprende es su peso en la capa de la pila de inferencia. Esta optimización no se quedó esperando a que el framework upstream se adaptara: se llevó su propia cuenta de hardware y su carga de trabajo real para modificar el código upstream, y luego integró los cambios de vuelta. Para quienes despliegan con el mismo framework, estos interruptores ya están listos para usarse, sin importar de quién sea el modelo.
Fuentes: blog técnico oficial de SGLang, CocoLoop, ficha de modelo pública de Ant inclusionAI; el TPOT, el rendimiento y la longitud de aceptación se verificaron con los comandos de reproducción y los resultados de referencia publicados en el blog, todos medidos con concurrencia 1, paralelismo de tensores en 4 tarjetas y bf16.