Cline exprime 11 840 tokens/s de una sola estación NVIDIA DGX Station

El equipo de Cline ha llevado la velocidad total de generación de un modelo abierto en una sola GPU hasta 11 840 tokens de salida por segundo. El récord se registró el 15 de octubre en una estación de NVIDIA a la que los ingenieros tuvieron acceso gracias a su colaboración con NVIDIA. El punto de partida ya era alto: vLLM 0.32.0rc1 sin modificar daba 6 058 tokens/s en una prueba con 512 tokens de entrada y 512 de salida con 256 hilos simultáneos. El resultado final es aproximadamente 1,95 veces superior.

El modelo se concibió como un caballo de batalla local y rápido para tareas diversas: análisis de documentos, programación y contabilidad financiera. En una sola máquina dispone de un presupuesto de memoria de GPU de 252 GB. En la demostración de Cline, con el vídeo sin acelerar, 32 instancias paralelas de Cline funcionan sobre Nemotron 3.5 Super VL en una estación de este tipo.

Cinco pasos de 6 058 a 11 840

Cline no describe un único hallazgo, sino una serie de experimentos, de los cuales cinco funcionaron:

• Cabeza MTP integrada. La predicción multitoken (multi-token prediction) venía incluida con el modelo. Los ingenieros empezaron con MTP3, es decir, con tres tokens borrador por paso, y fijaron OMP1: un solo hilo de CPU resulta más conveniente, porque varios hilos añaden sobrecarga de coordinación.
• Planificación asíncrona. Con mucha concurrencia, la GPU está ocupada con los núcleos de cómputo y la CPU con la planificación. El modo asíncrono permite que el planificador no tenga que esperar a que la GPU termine su trabajo.
• Núcleo de Mamba en FlashInfer. El modelo es híbrido: las capas de attention usan KV-cache, mientras que las capas Mamba guardan un estado recurrente y un breve historial de convolución. Volver al núcleo de FlashInfer supuso un salto notable. Los autores no llegaron a entender del todo por qué ocurre así, y en otro hardware el efecto puede no repetirse.
• MTP1 en lugar de MTP3. Un paso contraintuitivo que volvió a elevar el rendimiento.
• Estado de Mamba en FP16 en lugar de FP32, con redondeo estocástico. Esto reduce la precisión y, potencialmente, las métricas en benchmarks, pero para el objetivo de «máximo de tokens por segundo» el coste resultó aceptable.

Por qué menos tokens borrador resultaron más rápidos

La decodificación especulativa parece un bonus gratuito: cuantos más tokens borrador se predicen, mayor es la probabilidad de aceptar varios de golpe. Pero cada borrador hay que verificarlo. Si la verificación falla, el tiempo del modelo se ha desperdiciado. Con 256 hilos paralelos, la GPU ya está llena de trabajo útil y la verificación adicional no compensa. Por eso MTP1 superó a MTP3.

El beneficio de MTP con poca carga y con alta concurrencia puede ser justo el contrario. La misma receta podría perjudicar con otro perfil de tráfico. Cline lo dice sin rodeos: la ingeniería de inferencia depende mucho del contexto, y el escalado depende de la forma del tráfico.

Economía: un 66% menos que el precio de la API

La principal conclusión práctica la calcula Cline en una servilleta. Si se compara el pago por API con una GPU a plena carga, resulta un descuento del 66% en la inferencia. La condición es estricta: la GPU debe estar ocupada casi todo el tiempo. Entonces sale más barato adoptar la receta de Cline y pagar por el hardware que pasar por un router de modelos y pagar por cada llamada.

De ahí se derivan dos pronósticos del equipo. El primero: el autoalojamiento de decenas de agentes locales en paralelo se convertirá en una práctica habitual, y los 32 Cline en una sola estación ya lo demuestran. El segundo: el autoescalado de la inferencia pasará a ser agéntico. Un agente con acceso a las métricas de Grafana podrá ejecutar pruebas de carga en una GPU dedicada que no afecte al tráfico en producción. Elegirá la mejor configuración para la forma real de las solicitudes y después trasladará el tráfico a la nueva configuración con cuidado. Un sistema «autorreparable» de este tipo ajustará el consumo de GPU a la hora del día y a la carga.

Qué comprobar antes de repetir la receta

La receta no se debe copiar a ciegas. Primero hay que fijar el perfil propio: longitud de los prompts y de las respuestas, número de hilos simultáneos y latencia admisible. Después conviene probar los mismos cinco ajustes uno por uno. Para una concurrencia alta merece la pena comparar MTP1 y MTP3, mientras que con pocos hilos el efecto puede ser el contrario. Cambiar FP32 por FP16 en el estado de Mamba exige repetir las evaluaciones, porque aquí la velocidad se ha comprado a costa de la precisión. Y, por último, el cálculo del ahorro del 66% solo es válido con una alta utilización de la GPU: si la estación pasa tiempo ociosa, la API vuelve a salir más rentable.