💻 computer science

TEMPO: Makespan-Aware Expert-Parallel Load Balancing Across Memory- and Compute-Bound Regimes

TEMPO introduce un despachador de equilibrio de carga de experto-paralelo consciente del makespan que modela los tiempos de ejecución de expertos no lineales a través de regímenes limitados por memoria y por cómputo para optimizar dinámicamente la distribución de tokens, logrando hasta un 15.5% de ganancias en el rendimiento y reducciones significativas en la latencia en escenarios de régimen mixto donde los métodos tradicionales basados en recuento lineal fallan.

Autores originales: Jie Li, Chenxin Jia, Jinliang Shen, Cunzhuang Liu, Ruiyi Ding, Jianwen Xian, Kang He, Chengru Song

Publicado 2026-08-14

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Jie Li, Chenxin Jia, Jinliang Shen, Cunzhuang Liu, Ruiyi Ding, Jianwen Xian, Kang He, Chengru Song

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que diriges un servicio de entrega de pizzas masivo y de alta velocidad para una ciudad que nunca duerme. Tienes una flota de repartidores idénticos (las GPUs) y una cocina central con cientos de chefs especializados diferentes (los "expertos" en un modelo de IA). Cada vez que un cliente pide una pizza, el sistema tiene que decidir qué chefs trabajarán en ella y qué repartidor llevará la pizza terminada. En el mundo de la Inteligencia Artificial, específicamente con un tipo de modelo llamado "Mezcla de Expertos" (MoE), esto es exactamente lo que sucede. Estos modelos son como cerebros gigantes compuestos por miles de sub-cerebros más pequeños y especializados. Cuando la IA piensa, no utiliza todo su cerebro a la vez; elige a unos pocos expertos específicos para manejar el trabajo.

El gran desafío es mantener a todo el equipo moviéndose a la misma velocidad. Si un repartidor se queda atrapado con un pedido enorme y complicado mientras todos los demás están ociosos, toda la entrega se retrasa. El tiempo que toma completar un lote de pedidos está determinado por la persona más lenta del grupo. Durante años, la regla estándar para equilibrar esta carga de trabajo fue simple: "Simplemente divide el número de pedidos equitativamente". Si tienes 100 pedidos, dale 10 a cada uno de tus 10 repartidores. Esto parecía lógico, como repartir una pila de manzanas de forma igualitaria. Pero, ¿qué pasa si algunas manzanas son rocas pesadas y otras son plumas ligeras? ¿O si la cocina tiene una regla donde elegir a un nuevo chef toma un tiempo fijo, sin importar cuántas pizzas prepare? Las viejas reglas asumían que el tiempo siempre estaba directamente vinculado al número de pedidos. Esta investigación pregunta: ¿qué pasa si esa suposición es errónea?

Los investigadores detrás de este artículo, trabajando en KlingAI, descubrieron que la vieja regla de "contar los pedidos" es en realidad una trampa. Encontraron que en el hardware de IA moderno, el tiempo que toma procesar un experto no depende solo de cuántos tokens (palabras o fragmentos de datos) ve. Es una bestia de dos caras. A veces, el tiempo está dominado por el esfuerzo puro de cargar la "receta" del experto (pesos) desde el banco de memoria, lo cual toma un tiempo fijo independientemente de qué tan pequeño sea el pedido. Otras veces, una vez que la receta se ha cargado, el tiempo crece linealmente con el número de pedidos. Los métodos antiguos, que solo miraban el número de pedidos, estaban ignorando el costo oculto de cargar la receta. Estaban intentando equilibrar una pila de plumas y rocas contando las piezas, no pesándolas.

Para solucionar esto, el equipo construyó un despachador nuevo llamado TEMPO (Optimización de Paralelismo de Expertos Modelada por Tiempo). En lugar de solo contar tokens, TEMPO actúa como un inteligente controlador de tráfico que entiende la física de la cocina. Utiliza un "modelo de costo" especial que mide exactamente cuánto tiempo toma cargar la receta de un chef y cuánto tiempo toma cocinar la pizza. Se da cuenta de que si tienes un experto "frío" (uno que no ha sido usado en un tiempo), dividir su pequeño pedido entre dos repartidores es un desastre porque tienes que pagar la "tarifa de carga" dos veces. Pero si tienes un experto "caliente" con una montaña de pedidos, dividirlo está bien.

El artículo muestra que TEMPO no solo adivina; calcula el equilibrio perfecto para cada lote de solicitudes en milisegundos. Lo probaron en modelos de IA reales y encontraron que los métodos antiguos eran a menudo un 15% más lentos o causaban retrasos significativos para los últimos clientes en una fila. TEMPO, sin embargo, mantiene la línea moviéndose suavemente. Es como cambiar una regla que dice "todos reciben el mismo número de manzanas" por una que dice "todos reciben la misma cantidad de trabajo", teniendo en cuenta que algunas manzanas son pesadas y algunos chefs tardan en despertar.

Los investigadores fueron muy cuidadosos en mostrar exactamente dónde trabaja este nuevo método y dónde no. Demostraron que si los expertos "calientes" son tan numerosos que el sistema simplemente está abrumado por el volumen total de datos (el régimen "limitado por cómputo"), el método antiguo de contar tokens es en realidad adecuado. Pero en el mundo real, donde algunos expertos están ocupados y otros están descansando, y donde la "tarifa de carga" es alta, TEMPO brilla. Incluso mapearon un "diagrama de fases", que es como un mapa meteorológico para el tráfico de IA, prediciendo exactamente cuándo el nuevo método ahorrará tiempo y cuándo el método antiguo es lo suficientemente bueno.

Al final, este artículo no es solo sobre un algoritmo más rápido; es sobre cambiar la forma en que pensamos sobre el equilibrio del trabajo en la IA. Nos enseña que en el complejo y de alta velocidad mundo de la IA moderna, no puedes simplemente contar cosas. Tienes que entender los costos ocultos de mover datos y la forma específica del trabajo. Al medir el tiempo real que toma hacer el trabajo en lugar de solo contar los artículos, TEMPO hace que los modelos de IA sean más rápidos, más eficientes y estén listos para manejar las demandas masivas del futuro. Convierte una cocina caótica en una máquina bien aceitada, asegurando que ningún repartidor se quede esperando mientras la pizza reposa bajo la lámpara de calor.

Resumen Técnico: TEMPO – Equilibrio de Carga Consciente del Makespan para Experto-Paralelismo

1. Definición del Problema

En el servicio de Mezcla de Expertos (MoE), la latencia de una capa está determinada por el makespan (el tiempo máximo dedicado a cualquier GPU individual) debido a los puntos de sincronización al final de cada capa. Los despachadores de producción actuales (por ejemplo, EPLB, LPLB, UltraEP, METRO) intentan equilibrar la carga optimizando proxies: ya sea el número de tokens por GPU o el número de expertos activados por GPU. Estos proxies dependen de supuestos de linealidad implícitos—que el tiempo de ejecución del experto es linealmente proporcional al recuento de tokens o al recuento de expertos, respectivamente.

Sin embargo, las mediciones en GPUs de centros de datos (específicamente utilizando kernels de GEMM agrupados DeepGEMM fp8) revelan que el tiempo de ejecución del experto es no lineal y sigue una estructura de dos regímenes:

Régimen de Memoria-Limitado (Plano): Por debajo de un umbral de $n^* \approx 156\text{--}168$ tokens por experto, el costo está dominado por la transmisión de los pesos del experto desde la memoria de alto ancho de banda (HBM). En este régimen, el tiempo es constante por cada réplica de experto activada, independientemente del recuento de tokens.
Régimen de Cómputo-Limitado (Lineal): Por encima de $n^*$ , el costo se vuelve lineal con el recuento de tokens. Sin embargo, debido a que las implementaciones de GEMM agrupado redondean los tokens hacia arriba a M-tiles de 128 tokens, la división de un experto entre múltiples réplicas introduce "cómputo con relleno" (padded compute), lo que hace que el costo sea no lineal de una manera que el simple recuento de tokens pasa por alto.

Consecuentemente, los batches de decodificación del mundo real a menudo contienen un régimen mixto: expertos "calientes" con muchos tokens (régimen lineal) y expertos "fríos" con pocos tokens (régimen plano) coexisten. Los proxies existentes fallan porque las estrategias de equilibrio de tokens fragmentan a los expertos fríos (pagando pisos de activación ocultos), mientras que las estrategias de equilibrio de activación sobrecargan las réplicas calientes. Ningún proxy fijo único es óptimo en todos los puntos operativos.

2. Metodología

Modelado de Costos

Los autores formalizan el tiempo de ejecución por experto $t$ como una función max-afín:
$t = \max(a + bG, c + \beta N)$
Donde $G$ es el número de réplicas de expertos activadas y $N$ es el recuento de tokens.

$b$ (Piso de Activación): El costo de transmitir pesos para una réplica adicional (limitado por memoria).
$\beta$ (Pendiente de Tokens): El costo por token en el régimen limitado por cómputo.
Conciencia de Tile: Para prefill o batches grandes, un parámetro secundario captura el efecto de "escalera" de la teselación de 128 tokens, refinando el modelo a $t = \max(a+bG+b_2(T-G), c+\beta N)$ .

Este modelo se calibra mediante un microbenchmark de caja negra de diez minutos en el kernel desplegado, midiendo los tiempos de pared (wall-clock times) a través de rejillas de $(G, N)$ .

Formulación del Problema

El problema de despacho se formaliza como un problema de minimización de makespan con cargo fijo, el cual los autores demuestran que es NP-duro incluso con dos GPUs y replicación completa, ya que requiere equilibrar dos restricciones competitivas (recuento de activación vs. recuento de tokens) simultáneamente. Sin embargo, el problema es polinomial en límites degenerados (equilibrio puro de tokens o equilibrio puro de activación).

El Algoritmo TEMPO

TEMPO (Optimización de Experto-Paralelo Modelada por Tiempo) es un despachador que resuelve este problema de makespan en milisegundos, operando fuera de la ruta crítica. Su solver, tempo fast, emplea cuatro etapas:

Semilla Codiciosa Consciente del Costo: Coloca expertos completos en réplicas con el costo marginal más bajo, evitando la fragmentación de expertos fríos.
Reequilibrio de Activación: Utiliza cadenas de aumento para reequilibrar los recuentos de expertos en el régimen plano (donde los movimientos de tokens son ineficaces).
Búsqueda Local de Cuello de Botella: Realiza migraciones parciales de tokens para reducir el makesmana en el régimen lineal.
Ensamble con Tolerancia de Cambio: Evalúa la solución actual contra una línea base de Token-LP (Programación Lineal) y un heurístico de Round-Robin. Solo cambia si la nueva solución es >1% mejor, asegurando la estabilidad y heredando las garantías teóricas de los algoritmos más simples.

Integración del Sistema

TEMPO se integra en SGLang con un enfoque de overhead cero en la ruta crítica:

In-Graph: Un único kernel CUDA fusionado maneja el despacho probabilístico y la recolección de conteos, eliminando los colectivos por capa requeridos por los solvers de LP previos.
Fuera de Proceso: El solver se ejecuta en un proceso separado, evitando la contención del GIL y asegurando que la decisión de despacho no bloquee el grafo de inferencia.
Conciencia de Topología: Para configuraciones multi-nodo, una división de dos etapas asegura que los tokens se dirijan primero a las réplicas en el mismo nodo, minimizando el tráfico inter-nodo sin alterar el núcleo del solver.

3. Resultados Clave

Teóricos y de Simulación

Diagrama de Fases: Un diagrama de fases calibrado demuestra que la política fija óptima oscila entre el equilibrio de activación (limitado por memoria) y el equilibrio de tokens (limitado por cómputo) basándose en el tamaño del batch y el sesgo de los expertos. TEMPO rastrea la política óptima a través de todo este mapa.
Garantía de Aproximación: Bajo replicación completa, TEMPO proporciona una garantía de aproximación aditiva de $OPT + \max(b, \beta n_{max})$ .
Ganancias de Simulación: En entornos simulados, TEMPO logra una mejora de hasta el 15.5% sobre la mejor línea base fija en escenarios de régimen mixto (específicamente para extrapolaciones EP32–64).

Evaluación Empírica (Testbed A y B)

Microbenchmarks: En un Testbed A de 8 GPUs, TEMPO se mantiene dentro del 1% de la mejor línea base fija en cada punto de la rejilla evaluada y gana hasta un 15.5% donde los regímenes se mezclan.
Servicio End-to-End (Qwen3-235B):
- En tráfico de contexto largo y pesado en decodificación, TEMPO mejora el rendimiento (throughput) en un 4–6% y reduce la latencia inter-token p99 en aproximadamente 15.6%.
- En una configuración EP16 de 2 nodos con división consciente de la topología, las ganancias alcanzan un 4–7%.
- Crucialmente, el documento señala que gran parte de la brecha entre el LPLB enviado de SGLang y TEMPO es arquitectónica (eliminación de colectivos in-graph); cuando LPLB se porta a la misma arquitectura, la ganancia residual de TEMPO es principalmente la estabilidad en puntos de cómputo.
Servicio End-to-End (DeepSeek-V3): En un modelo donde la comunicación domina y los expertos son más pequeños por GPU (fuera de la "región de victoria"), TEMPO devuelve solo los costos de mecanismo, rindiendo a la par con la colocación estática. Esto confirma la afirmación del documento de que los beneficios son condicionales.
Obsolescencia (Staleness) y Colocación: El sistema es robusto a la obsolescencia de la colocación (hasta 200ms de deriva). Sin embargo, si la capa de colocación es significativamente obsoleta (expertos calientes movidos a réplicas frías), el despacho por sí solo no puede recuperar el rendimiento; solo la capa de colocación puede arreglar la media, mientras que el despacho repara la cola de latencia.

4. Significado y Reivindicaciones

La reivindicación principal del documento no es una victoria de rendimiento universal, sino un diagrama de fases que predice cuándo es beneficioso el despacho basado en tiempo.

La "Región de Victoria": El despacho adaptativo genera ganancias significativas solo cuando:
1. El modelo tiene expertos grandes (alto piso de activación $b$ ).
2. Los batches están en un régimen mixto (que contiene tanto expertos calientes como fríos).
3. La colocación es lo suficientemente obsoleta como para causar desequilibrio, pero no tanto como para que solo la migración de pesos pueda arreglarlo.
4. El cómputo de los expertos constituye una parte significativa del tiempo del paso (no dominado por la comunicación).
Cambio Metodológico: El documento argumenta que "equilibrar el tiempo, no los tokens" es el enfoque principista para el servicio de MoE. Demuestra que los proxies de recuento de tokens son sistemáticamente erróneos en regímenes limitados por memoria y que es necesario un modelo de costo calibrado para navegar la interacción entre los cuellos de botella de memoria y cómputo.
Practicidad: El trabajo proporciona una solución desplegable (TEMPO) que se integra perfectamente en los stacks de servicio existentes (SGLang) con un overhead insignificante, demostrando que la optimización compleja del makespan puede realizarse en milisegundos sin bloquear la inferencia.

Los autores declaran explícitamente que para formas de expertos pequeñas o modelos dominados por la comunicación, el despacho adaptativo no ofrece ventaja sobre la colocación estática, y el sistema se degrada correctamente a la par en lugar de incurrir en una penalización. La contribución es el mapeo de estas condiciones y el algoritmo para navegar entre ellas.