Resumen Técnico: Dooly

Declaración del Problema

Desplegar sistemas de inferencia de Modelos de Lenguaje Grande (LLM) requiere navegar por un vasto espacio de configuración que abarca hardware, motores de servicio, backends de atención, arquitecturas de modelos y características de la carga de trabajo. Ninguna configuración única es óptima para todas las cargas de trabajo; las clasificaciones de rendimiento a menudo se invierten según la longitud de la secuencia o el tipo de modelo, lo que hace esencial la evaluación previa al despliegue.

Los simuladores basados en perfiles actuales, la herramienta estándar para esta evaluación, enfrentan dos limitaciones críticas que obstaculizan la exploración eficiente:

1. Dependencias de Configuración Estáticas: Los simuladores existentes codifican en el código fuente el conjunto de operaciones y argumentos de entrada para configuraciones específicas. Cualquier cambio en la pila de software (por ejemplo, un nuevo motor de servicio o backend de atención) o en la arquitectura del modelo requiere un trabajo manual para restaurar la cobertura.
2. Sobrecarga de Perfilado Elevada: Los simuladores no reconocen cuándo diferentes configuraciones invocan computaciones semánticamente idénticas. En consecuencia, vuelven a perfilar cada operación desde cero para cada nuevo modelo o backend. Por ejemplo, perfilar cuatro modelos de tamaño similar con un solo backend puede tomar casi 28 horas de reloj en una sola GPU A100, escalando linealmente con el número de modelos.

Estas limitaciones surgen de una falta de comprensión estructural de la inferencia de LLM: específicamente, que las dimensiones de entrada se derivan ya sea de configuraciones de modelo fijas o de características de solicitud variables, y que muchos valores de configuración del modelo (por ejemplo, tamaño de cabeza, número de capas) se repiten en diferentes modelos, lo que genera una redundancia significativa en el perfilado.

Metodología

Los autores proponen Dooly, un marco para perfilado agnóstico a la configuración y consciente de la redundancia. Dooly explota la recurrencia estructural de las operaciones entre configuraciones para eliminar ejecuciones de perfilado redundantes. El sistema opera a través de tres componentes principales:

1. Ejecutor Tainted (Anotación Semántica)

Para distinguir entre parámetros de modelo fijos e inputs de solicitud variables, Dooly emplea propagación de taint.

• Tainting de Origen: El sistema intercepta los puntos de entrada del motor de servicio (por ejemplo, ModelConfig y la lógica de procesamiento de solicitudes) para etiquetar valores. Los parámetros de configuración del modelo se marcan con MODEL_CONFIG, mientras que los valores dependientes de la solicitud (número de tokens, tamaños de lote) se marcan con NUM_TOKS y NUM_REQS.
• Propagación: A medida que se ejecuta el pase de inferencia, estos taints se propagan a través de operaciones aritméticas y de tensores. Se definen reglas sobre cómo se combinan los taints (por ejemplo, multiplicar un tamaño de lote por una dimensión de cabeza resulta en un taint compuesto MIX).
• Anotación de Trazas: La traza resultante anota cada dimensión de tensor con su origen, permitiendo al sistema identificar qué dimensiones son invariantes entre cargas de trabajo y cuáles son variables.

2. Buscador de Conjuntos de Operaciones (Resolución de Granularidad)

Este componente analiza la traza tainted en un grafo de llamadas jerárquico para determinar la granularidad más fina a la que las operaciones pueden perfilarse de forma aislada.

• Construcción de Jerarquía: La traza se poda para colapsar subárboles estructuralmente idénticos (por ejemplo, capas de transformadores repetidas) en representantes canónicos.
• Pruebas de Ejecutabilidad: El sistema intenta ejecutar operaciones hoja (kernels individuales) de forma aislada. Si una operación falla debido a un estado de tiempo de ejecución faltante (por ejemplo, memoria de caché KV o metadatos de atención), el sistema retrocede a su módulo padre.
• Resolución de Contexto: Para operaciones con estado que no pueden ejecutarse de forma independiente, Dooly reutiliza el propio código de inicialización del motor de servicio para reconstruir el contexto de tiempo de ejecución necesario, eliminando la necesidad de instrumentación manual.

3. Perfilador Consciente de Duplicación (Coincidencia de Firmas)

Este componente elimina el perfilado redundante identificando operaciones semánticamente equivalentes entre diferentes configuraciones.

• Generación de Firmas: Una operación se identifica de forma única por un hash de firma compuesto por:
  1. El nombre de la operación y sus dimensiones tainted con MODEL_CONFIG (fijadas por la arquitectura).
  2. El conjunto de símbolos de kernel de GPU despachados (capturando la selección de kernel específica del backend).
  3. Un resumen de atributos a nivel de módulo (por ejemplo, tamaño de ventana deslizante) para la ramificación en tiempo de ejecución.
     Nota: Las dimensiones dependientes de la carga de trabajo (NUM_TOKS, NUM_REQS) se excluyen de la firma, ya que parametrizan el barrido, no la identidad de la operación.
• Perfilado Selectivo: Antes de despachar una medición, el perfilador consulta la base de datos de latencia. Si una firma ya existe, la operación se omite. Solo se perfilan firmas únicas a través de rangos definidos por el usuario de longitudes de secuencia y tamaños de lote.
• Base de Datos de Latencia: Los resultados se almacenan en una base de datos SQLite indexada por hash de firma. Esta base de datos sirve como un backend listo para usar para simuladores existentes, que entrenan modelos de regresión por firma para predecir la latencia.

Contribuciones Clave

• Perfilado Agnóstico a la Configuración: Dooly extrae dinámicamente operaciones y las perfila sin codificar plantillas en el código fuente, lo que le permite admitir nuevos modelos, backends y motores de servicio sin trabajo manual.
• Eliminación de Redundancia: Al utilizar la propagación de taint para distinguir dimensiones derivadas del modelo de las derivadas de la solicitud, Dooly detecta operaciones equivalentes entre diferentes modelos y configuraciones, reduciendo el esfuerzo de perfilado.
• Aislamiento de Operaciones con Estado: Mediante la resolución jerárquica de contextos, Dooly aísla operaciones complejas dependientes del estado (como kernels de atención) reutilizando la lógica interna de inicialización del motor de servicio, evitando la necesidad de reconstrucción manual de contextos.
• Integración Lista para Usar: La base de datos de latencia resultante entrena modelos de regresión que los simuladores existentes pueden adoptar como backend para realizar simulaciones de extremo a extremo.

Resultados

Los autores evaluaron Dooly en dos plataformas de GPU (NVIDIA A100 y H100), tres backends de atención (FlashInfer, FlashAttention, TritonAttention) y 12 arquitecturas de modelo diversas (incluyendo familias densas, MoE y heterogéneas).

• Precisión de Simulación: Cuando se integra en un simulador (DoolySim), el sistema predice el Tiempo hasta el Primer Token (TTFT) con un Error Porcentual Absoluto Medio (MAPE) dentro del 5% y el Tiempo por Token de Salida (TPOT) dentro del 8% en comparación con las mediciones en vivo. También reproduce las decisiones de programación de lotes con un MAPE inferior al 0.5%.
• Reducción de Sobrecarga de Perfilado: En 12 modelos perfilados con tres backends de atención (36 configuraciones en total), Dooly redujo las horas totales de GPU de perfilado en un 56.4% en comparación con un enfoque ingenuo que no elimina duplicados.
  • Específicamente, perfilar Llama-3.1-8B y Command-R7B tomó 5.2 horas de GPU con Dooly frente a 8.1 horas de forma ingenua.
  • El sistema identificó solo 100 firmas únicas de 612 ocurrencias totales de operadores, siendo las firmas de atención responsables del 95% del tiempo ahorrado.
• Escalabilidad: Una vez que unos pocos modelos ejercitan las configuraciones de atención distintas en un corpus, los modelos subsiguientes añaden una sobrecarga insignificante (menos de 0.2 horas de GPU) ya que heredan firmas existentes.

Significancia y Afirmaciones

El artículo afirma que Dooly cambia fundamentalmente la economía de la simulación de inferencia de LLM al pasar de un enfoque de "perfilarlo todo" a un enfoque de "perfilar lo que es único". Al aprovechar la recurrencia estructural de las configuraciones de modelos, Dooly permite a investigadores y profesionales evaluar estrategias de servicio en una amplia gama de configuraciones con un costo significativamente reducido.

Los autores enfatizan que su enfoque es modesto en cuanto a impactos más amplios, afirmando que el trabajo no tiene un impacto ético o social significativo más allá de su utilidad técnica. Reconocen limitaciones, como la incapacidad de rastrear operaciones que eluden el despachador de PyTorch (aunque los módulos que las encierran permanecen cubiertos) y la asunción de enrutamiento de expertos aleatorio para modelos MoE, señalando que el modelado de enrutamiento dependiente de datos está fuera del alcance del artículo. La contribución principal es un marco práctico que hace viable y eficiente la exploración entre configuraciones sin requerir ingeniería manual para cada actualización de pila.