Cline acelera un modelo abierto hasta 11.840 tokens por segundo en una sola GPU

Un punto de partida sólido

El 15 de octubre, el equipo de Cline publicó un informe sobre cómo logró acelerar un modelo de lenguaje abierto hasta alcanzar 11.840 tokens por segundo combinados en una sola GPU. Se trata de un modelo compacto diseñado específicamente para ejecutarse de forma local: no aspira a ser el más inteligente, pero necesita funcionar de manera rápida y estable en varias tareas a la vez: análisis de documentos, programación, cálculos financieros. Precisamente esa velocidad y eficiencia es lo que hace interesantes a modelos de este tipo: se pueden reentrenar para las necesidades concretas de una empresa y mantener en infraestructura propia, en lugar de pagar por cada solicitud a una API ajena.

El experimento fue posible gracias a una colaboración con NVIDIA, que le dio a Cline acceso a un servidor potente equipado con una sola GPU y 252 GB de memoria de vídeo. El objetivo era sencillo: extraer el máximo número de tokens por segundo de esa configuración bajo una carga paralela elevada.

Desde el inicio, con la versión del motor vLLM 0.32.0rc1.dev190+g3f1bcfd82 y la configuración de fábrica, el modelo alcanzó 6.058 tokens por segundo en una prueba con 512 tokens de entrada y 512 de salida sobre 256 flujos de solicitudes simultáneos. Para Cline, esto resultó una sorpresa: la configuración predeterminada del modelo ya estaba bastante optimizada para cargas elevadas, y el equipo consideró esa cifra un punto de partida sólido, no un fracaso que había que corregir heroicamente.

Cinco pasos que casi duplicaron la velocidad

A partir de ahí, los ingenieros realizaron una serie de experimentos, cambiando un parámetro a la vez:

• Predicción multitoken (MTP3). El modelo viene con una cabeza capaz de predecir varios tokens siguientes a la vez. Activar el modo MTP3 con ejecución de un solo hilo (OMP1) —para evitar la sobrecarga de coordinación entre hilos— dio la primera mejora de velocidad.
• Planificador asíncrono. Con una gran cantidad de solicitudes paralelas, la GPU está ocupada con los cálculos mientras la CPU se encarga de la planificación de tareas. Pasar el planificador a modo asíncrono eliminó los tiempos muertos de la GPU esperando a la CPU.
• Sustitución del bloque Mamba por FlashInfer. El modelo utiliza dos tipos de capas: las capas de atención convencionales con caché KV, y las capas Mamba, que almacenan el estado de otra manera, mediante memoria recurrente y una convolución corta sobre el historial. Cambiar el motor de cómputo de las capas Mamba a FlashInfer produjo inesperadamente un salto notable de rendimiento. El equipo reconoce con honestidad que no entiende del todo por qué funcionó: es posible que el efecto esté ligado a esta configuración concreta de GPU y no se repita en otro hardware.
• Reducción de MTP de 3 a 1. Cabría pensar que cuantos más tokens prediga el modelo por adelantado, más rápida será la generación. En la práctica ocurre lo contrario: cada predicción hay que verificarla, y si la verificación falla, se pierde tiempo. Con 256 flujos paralelos, la GPU ya estaba ocupada con trabajo útil, así que las apuestas de predicción adicionales solo estorbaban. Reducir la profundidad de predicción a MTP1 aportó otro aumento de velocidad.
• Estado de Mamba en FP16. El último paso consistió en pasar el estado interno de las capas Mamba de precisión de 32 bits a 16 bits con redondeo estocástico. Esto reduce la precisión de los cálculos y podría empeorar ligeramente la calidad de las respuestas del modelo, pero para el objetivo del experimento —la máxima velocidad— el equipo consideró justificado el compromiso.

En conjunto, estos cinco ajustes elevaron la velocidad agregada de 6.058 a 11.840 tokens por segundo, casi el doble, sin cambiar el hardware.

Qué implica esto para los ingenieros

La principal conclusión del equipo de Cline no suena a receta, sino a advertencia: la ingeniería de inferencia depende enormemente del contexto. Los trucos que funcionaron aquí —MTP1 en lugar de MTP3, FlashInfer en lugar del kernel estándar de Mamba— podrían, con otra forma de tráfico (otra proporción de tokens de entrada/salida, otro número de solicitudes paralelas), reducir la velocidad en lugar de aumentarla. Por eso en Cline recomiendan no copiar a ciegas la configuración de otros, sino primero entender la forma del propio tráfico y ajustar la inferencia en función de ella.

El equipo también compartió tres previsiones para el futuro. En primer lugar, ejecutar localmente decenas de flujos de agentes en paralelo se volverá algo habitual; como ejemplo citan una demostración con 32 sesiones simultáneas de Cline sobre el modelo Nemotron 3.5 Super VL en una sola estación NVIDIA DGX, grabada sin aceleración de vídeo.

En segundo lugar, con una GPU a plena carga, autoalojar los modelos puede resultar más barato que pagar por una API: según los cálculos de Cline, en su caso el ahorro fue de alrededor del 66%. En tercer lugar, los autores creen que, con el tiempo, encontrar la configuración óptima de inferencia se convertirá en una tarea para agentes de IA: un agente con acceso a las métricas de Grafana podrá ejecutar pruebas de carga en una GPU de reserva, encontrar la mejor configuración para un tráfico concreto y cambiar la producción a ella de forma segura, es decir, el autoescalado de la inferencia pasará a ser una tarea agéntica.