Resumen Técnico: Concordia: JIT-Compiled Persistent-Kernel Checkpointing para la Tolerancia a Fallos en la Inferencia de LLM

1. Declaración del Problema

Los agentes de Modelos de Lenguaje Extensos (LLM) de larga duración mantienen un estado sustancial en las GPUs, incluyendo cachés KV, programadores de peticiones, estados de comunicación y adaptadores en línea. A diferencia de la inferencia tradicional sin estado, estas cargas de trabajo acumulan minutos u horas de computación. Un fallo en un rango de GPU, comunicador o kernel de aplicación puede destruir este estado, haciendo que la sesión sea irrecuperable sin reiniciar todo el stack de servicio, recargar los pesos del modelo y reproducir las llamadas a herramientas, un proceso que a menudo es semánticamente imposible una vez que han ocurrido interacciones externas.

Los mecanismos de recuperación existentes enfrentan un compromiso fundamental:

• Registro específico de la aplicación: Requiere modificar cada kernel de atención, asignador y librería para registrar las actualizaciones de KV explícitamente. Esto es frágil en stacks modernos que involucran librerías fusionadas, kernels de proveedores y compiladores de grafos dinámicos.
• Checkpointing mediado por el Host: Depende de que la CPU lance kernels de checkpoint o escanee la memoria de la GPU. Esto introduce una alta latencia debido a las transferencias PCIe y las comparaciones de páginas en el lado de la CPU, y coloca al host en la ruta crítica durante la recuperación, impidiendo que la GPU ejecute mientras el host orquesta la recuperación.

El artículo argumenta que la tolerancia a fallos para estas cargas de trabajo requiere un contexto de ejecución residente en la GPU que pueda observar kernels binarios, realizar la detección de páginas sucias a un ancho de banda de HBM y ejecutar la lógica de recuperación sin intervención del host.

2. Metodología: El Runtime Concordia

Concordia es un sistema de tiempo de ejecución diseñado para interponerse en la carga de módulos de GPU y proporcionar un sustrato persistente residente en el dispositivo para la tolerancia a fallos. Su arquitectura consta de cuatro mecanismos principales:

2.1 Ejecutor de Kernel Persistente

La base de Concordia es un kernel persistente que se ejecuta durante la vida útil de una sesión de LLM.

• Operación: Monitorea continuamente un anillo libre de bloqueos (lock-free ring buffer) en memoria mapeada al host.
• Tareas: Ejecuta tareas de cómputo, checkpoint, comunicación y recuperación sin requerir nuevos lanzamientos de kernels CUDA desde el host.
• Huella de Recursos: Reserva un número mínimo de Multiprocesadores de Flujo (SMs) (por ejemplo, 1 bloque en RTX PRO 6000, ~0.53% de la huella de SM), dejando el resto de la GPU disponible para los kernels de la aplicación.
• Ruta de Control: Actúa como un bucle de control confiable. Si los kernels o comunicadores de la aplicación fallan, el trabajador persistente permanece vivo para orquestar la recuperación hasta que el dispositivo se declare perdido.

2.2 Instrumentación PTX/SASS y Compilación JIT

Concordia instrumenta los binarios de la GPU para exponer puntos de checkpoint seguros y generar manejadores especializados.

• Instrumentación: Intercepta las llamadas cuModuleLoad. Para módulos PTX, reescribe el código para insertar ganchos (hooks) de pausa cooperativa y checkpoint en la entrada, salida y sitios de barrera. Para kernels de solo binario (SASS), aplica un parcheo conservador para redirigir la ejecución a través de estuches de trampolín (trampoline stubs).
• Manejadores JIT-Compilados: Para cada región de memoria registrada (por ejemplo, bloques de PagedAttention KV, adaptadores LoRA, buffers opacos), Concordia compila mediante JIT un manejador de delta-checkpoint especializado.
  • Regiones KV: Los manejadores escanean tablas de bloques físicos y mapas de bits de suciedad proporcionados por el runtime de servicio.
  • Regiones de Adaptador/Operación: Los manejadores realizan escaneos de páginas densos o comparaciones de sombra contra copias residentes en la GPU.
• Intercambio en Caliente (Hot-Swapping): Estos manejadores se compilan vía NVRTC y se insertan en la tabla de operadores del kernel persistente, permitiendo actualizaciones dinámicas sin interrupción del servicio.

2.3 Delta Checkpointing en la GPU

En lugar de instantáneas completas, Concordia realiza delta checkpointing directamente en la GPU.

• Proceso: En los límites de los kernels o colectivos NCCL, el kernel persistente ejecuta el manejador JIT-compilado para identificar páginas sucias al ancho de banda de HBM (~1.8 TB/s).
• Registro: Solo las páginas sucias y los metadatos se anexan a un registro de Archivo de Solo Adición (AOF) almacenado en memoria CXL visible para la CPU o en la DRAM del host.
• Explotación de Estructura: El sistema explota la estructura del estado de los LLM: los pesos base son estáticos (inmutables), mientras que los cachés KV y los adaptadores cambian de forma dispersa. Esto permite al sistema evitar el registro de cada actualización y, en su lugar, detectar cambios eficientemente.

2.4 Recuperación y Tolerancia a Fallos

• Modelo de Parada por Fallo (Fail-Stop): Concordia asume que los kernels de la aplicación o los comunicadores pueden fallar, pero el trabajador persistente es confiable. Si el latido (heartbeat) del trabajador se detiene, la GPU se considera perdida.
• Flujo de Recuperación: Tras un fallo, una GPU de reemplazo (o el mismo dispositivo tras un reinicio) carga la última instantánea base confirmada y reproduce el registro AOF desde CXL/DRAM.
• Integración con NCCL: Un wrapper mejorado de NCCL intercepta las operaciones colectivas para identificar límites seguros. En caso de fallo, cambia a un anillo de respaldo precomputado o activa un dispositivo de reemplazo, reconstruyendo el DAG del comunicador sin una reinicialización completa de NCCL.
• Transversalidad de Arquitectura (Opcional): Para la recuperación entre diferentes arquitecturas de GPU, Concordia puede normalizar el código instrumentado en una representación intermedia portátil (CTX) y derivarlo al ISA de destino, aunque esto es una extensión opcional.

3. Principales Contribuciones

1. Sustrato de Kernel Persistente: El artículo identifica la necesidad de un ejecutor vivo en el dispositivo para permitir una tolerancia a fallos transparente, evitando la latencia y las dependencias de la ruta crítica del host en el checkpointing.
2. Contrato de Recuperación Unificado: Concordia combina instrumentación PTX/SASS, un ejecutor persistente libre de bloqueos, manejadores delta JIT-compilados en la GPU y registro de solo adición en CXL/DRAM en un solo sistema.
3. Delta Checkpointing Consciente de la Estructura: El sistema aprovecha la estructura de la inferencia de LLM (pesos estáticos, actualizaciones dispersas de KV) para realizar la detección de páginas sucias enteramente en la GPU al ancho de banda de HBM, eliminando la necesidad de registro de KV específico de la aplicación.
4. Evaluación de Desempeño: El sistema se evalúa en GPUs Blackwell y objetivos heterogéneos, demostrando aceleraciones significativas en el checkpointing y tiempos de recuperación de sub-segundo.

4. Resultados Experimentales

La evaluación se realizó en GPUs NVIDIA RTX PRO 6000 (Blackwell) y RTX 5090, utilizando PyTorch 2.10.0 y NCCL 2.27.5.

• Velocidad de Checkpointing: El delta checkpointing en la GPU es de 85× a 219× más rápido que el escaneo de páginas transparente en la CPU.
  • Para una región de 256 MB con una página sucia, la diferenciación en la CPU tomó ~111 ms (dominada por el escaneo de la CPU), mientras que en la GPU tomó ~0.56 ms (dominada por el ancho de banda de HBM).
  • La aceleración escala con el tamaño de la región porque la diferenciación de CPU escala con el tamaño total de la región, mientras que la de la GPU escala con el tamaño de los datos sucios.
• Latencia de Disparo (Trigger Latency): El envío de una tarea de checkpoint a través del anillo persistente toma <0.1 µs, comparado con los 7.6 µs de un cudaLaunchKernel sincrónico. Esto elimina la sobrecarga de lanzamiento del host en cada límite de checkpoint.
• Sobrecarga de Recursos: El kernel persistente ocupa solo el 0.53% de los SMs (1 bloque de 188), significativamente menor que otros enfoques de hilos persistentes como CLC (5–10%) o Green Contexts (3–8%).
• Throughput de Inferencia: En la inferencia de Qwen3-0.6B, la sobrecarga de checkpoint fue de 18.9 ms por límite (menos del 4% del tiempo de generación), manteniendo el sistema 108.2 tokens/seg.
• Recuperación de Fallos: Un prototipo de recuperación de fallo de dos GPUs restauró el servicio en ~1.5 segundos (10 ms de detección + 300 ms de aislamiento + 800 ms de restauración de estado + 400 ms de reintegración). Esto contrasta con los 47+ segundos requeridos para un reinicio estándar de NCCL y la recarga del modelo.
• Ajuste Fino de LoRA (LoRA Fine-Tuning): El sistema manejó eficazmente la adaptación en línea, detectando solo las páginas mutables del adaptador (1.75% del total de páginas) y logrando una aceleración de 299× sobre el delta checkpointing de CPU para el modelo completo.

5. Significancia y Reivindicaciones

El artículo afirma que Concordia proporciona un sustrato necesario para la inferencia de LLM de larga duración tolerante a fallos al desplazar el bucle de control de recuperación del host al dispositivo.

• Reivindicaciones Modestas sobre Desempeño Estático: Los autores declaran explícitamente que para benchmarks de decodificación estática de un solo modelo, los CUDA Graphs cuidadosamente diseñados aún podrían superar la ejecución eager. Concordia no se presenta como un reemplazo de CUDA Graphs, sino como una capa complementaria que opera por debajo de los límites del framework para manejar cargas de trabajo dinámicas y tolerancia a fallos.
• Transparencia: El sistema apunta a binarios de GPU no modificados o parcialmente modificados, cubriendo kernels generados por frameworks y librerías de proveedores donde el registro a nivel de aplicación es inviable.
• Modelo de Recuperación: La significancia radica en permitir un modelo de reproducción de AOF tipo Redis para LLMs, separando la durabilidad de la capacidad escasa de HBM y permitiendo la recuperación sin reconstruir comunicadores o recargar pesos.
• Limitaciones: El sistema asume que el trabajador persistente no falla de forma independiente (no se manejan fallos bizantinos) y requiere checkpointing cooperativo en los puntos de barrera para la migración entre arquitecturas. También señala que las regiones mutables opacas aún requieren copias de sombra residentes en la GPU, lo que consume HBM.

En resumen, Concordia demuestra que, al mantener un contexto de ejecución persistente e instrumentado en la GPU, es posible lograr una tolerancia a fallos transparente y de alto rendimiento para la inferencia de LLM, reduciendo los tiempos de recuperación de minutos a segundos y eliminando a la CPU del host de la ruta crítica del checkpointing.