SGLang-TorchTPU casi duplica la velocidad de generación de tokens de Muse Spark Open

Un agente de programación ha leído el repositorio, ha ejecutado una herramienta y se detiene antes de dar su siguiente respuesta. Es fácil atribuir esa pausa al tamaño del modelo. Pero el servidor puede estar dedicando tiempo a cargar los pesos, intercambiar datos entre aceleradores y volver a procesar un contexto que ya conoce. Para el equipo de producto, el problema es muy concreto: el usuario espera mientras la infraestructura por la que se paga realiza tareas preparatorias.

El equipo de SGLang-TorchTPU describió cómo ejecutó Muse Spark Open, de 816.000 millones de parámetros, en un único host con cuatro TPU v7. El principal resultado con una sola solicitud: el tiempo por token de salida bajó de 3,78 a 1,95 ms. Las mediciones y los detalles de la implementación se publicaron en el blog de PyTorch.

El acelerador necesita recibir los datos a tiempo

Imagine una cocina donde el cocinero se detiene antes de cada tarea para esperar la siguiente cesta de ingredientes. Comprar unos fogones más potentes no eliminará la espera. Otra opción es organizar las entregas para que la siguiente cesta llegue mientras se prepara el plato actual.

Aquí se aplicó una idea similar: se fusionó la ejecución de 62 capas en un solo programa y se solaparon las transferencias de datos con los cálculos. Esto permite preparar de antemano lo que necesitará la siguiente etapa del trabajo.

La aplicación práctica de este enfoque empieza por analizar el perfil de ejecución. Supongamos que ofrece un asistente interno a un equipo pequeño. Normalmente lo utilizan varias personas a la vez, y a todas les importa que la respuesta se genere con fluidez. En ese escenario conviene examinar cuánto tarda cada paso de generación y qué parte de ese tiempo se dedica a esperar datos.

Un servicio con muchos usuarios tiene otro reto: atender la cola sin que la latencia se dispare. Por eso, una cifra de velocidad llamativa no basta para saber cuántos usuarios puede soportar el sistema. Hace falta una serie de mediciones con distintas cargas y las mismas condiciones.

Una pausa del agente es un motivo para conservar el contexto

El segundo resultado tiene que ver con la memoria. Una caché adicional en la RAM del host aumentó el rendimiento en cargas de trabajo de agentes hasta un 77%.

Pensemos en un asistente que busca un error en un proyecto. Lee archivos, ejecuta pruebas, recibe los resultados y retoma el razonamiento. Gran parte de la conversación permanece igual entre estas acciones. Si el servidor ha conservado los datos del contexto ya procesados, el siguiente turno puede empezar con menos trabajo repetido.

Esto plantea una pregunta útil para el equipo de producto: ¿qué ocurre con el estado de la sesión mientras el usuario o la herramienta guardan silencio? Una pausa, por sí sola, no significa que la conversación haya terminado. Sobre todo si el agente espera una compilación, una búsqueda externa o el resultado de un comando que tarda en ejecutarse.

Una forma práctica de comprobarlo es preparar un escenario específico. Proporcione al agente un documento grande, realice varios turnos breves con pausas y compare cuánto tarda en empezar la respuesta. Después repita el experimento con la memoria llena. Así quedará más claro hasta qué punto el comportamiento del servicio depende de conservar el contexto y qué sucede cuando se expulsan de la caché las sesiones antiguas.

Qué aplicar en su propio servicio

Una aceleración de casi el doble no se traduce automáticamente en ahorro de presupuesto. La ventaja del programa fusionado disminuye a medida que aumenta el número de solicitudes simultáneas. Además, los autores aún tienen previsto incorporar parte del trabajo a la rama principal del proyecto.

Los desarrolladores deberían empezar con tres mediciones: el tiempo hasta el primer token, los intervalos entre los siguientes tokens y el número de solicitudes completadas con una latencia determinada. Los responsables de producto deberían añadir un recorrido de usuario realista, con herramientas y pausas. Los fundadores deberían calcular el coste de una tarea completada con éxito y con un tiempo de respuesta aceptable.

También hay un escenario específico para comprobar la cola: un usuario envía un documento enorme y otro hace una pregunta breve. Observe cuánto espera el segundo. Este experimento revela rápidamente si la distribución de recursos cumple la calidad de servicio prometida.

El valor de la publicación está en su conjunto de soluciones de ingeniería que se pueden poner a prueba. Antes de cambiar el hardware, conviene averiguar exactamente dónde queda inactivo el servidor, qué trabajo repite y a qué solicitudes permite ocupar la cola durante demasiado tiempo.