CUDA Graphs, modelos de razonamiento y servicio desagregado

La infraestructura moderna de IA lleva el rendimiento a los límites físicos del silicio y los clústeres mediante la eliminación de la sobrecarga de la CPU, los bucles de razonamiento en tiempo de inferencia y el enrutamiento de clústeres de GPU especializado por fases. Estas tres técnicas impulsan los sistemas de IA en producción más rápidos e inteligentes de la actualidad.
1. CUDA Graphs y fusión de kernels: eliminando la sobrecarga de CPU y memoria
A medida que las GPU modernas (como la H100 y la B200) se han vuelto exponencialmente más rápidas, ejecutar un único kernel de GPU ligero puede tardar tan solo de 2 a 5 microsegundos. Sin embargo, la CPU suele tardar de 10 a 20 microsegundos solo en preparar, validar y lanzar ese kernel a través del driver PCIe, dejando la GPU de varios millones de dólares completamente inactiva esperando instrucciones de la CPU.
- Fusión de kernels (combinando operaciones para ahorrar memoria y lanzamientos).
- El cuello de botella sin fusión. Una capa Transformer estándar ejecuta decenas de operaciones diminutas secuencialmente (p. ej., LayerNorm → Linear → Add Residual → GeLU). Sin fusión, la GPU lanza kernels separados para cada paso, escribiendo los tensores intermedios en la lenta HBM (VRAM) y leyéndolos de vuelta inmediatamente para el siguiente paso.
- Ejecución fusionada. Compiladores como torch.compile (TorchInductor) y TensorRT-LLM fusionan múltiples operaciones elemento a elemento y de reducción en un único kernel CUDA/Triton personalizado. Los valores se cargan de la HBM una vez, se transforman dentro de los registros/SRAM ultrarrápidos en el chip y se escriben de vuelta en la HBM solo al final, reduciendo drásticamente tanto el tráfico de ancho de banda de memoria como el número de lanzamientos de kernels.
- CUDA Graphs (reproduciendo pipelines de ejecución completos de una sola vez).
- Grabar y reproducir. Incluso después de la fusión de kernels, una pasada hacia adelante de un LLM aún requiere cientos de lanzamientos de kernels por token generado. CUDA Graphs resuelve esto capturando una secuencia completa de operaciones de GPU (kernels, copias de memoria y dependencias) durante una ejecución de calentamiento y compilándolas en un grafo de ejecución estático almacenado directamente en la memoria de la GPU.
- Cero intervención de la CPU. Durante la inferencia en tiempo real, en lugar de que la CPU lance 300 kernels separados uno por uno, la CPU emite una única llamada a la API (cudaGraphLaunch) que dispara toda la pasada hacia adelante en la GPU de forma autónoma.
- Manejo de formas dinámicas. Como CUDA Graphs requiere direcciones de memoria y formas de tensores estáticas, los motores de inferencia rellenan los lotes entrantes a tamaños de cubeta fijos (p. ej., tamaños de lote 1, 2, 4, 8, 16) y actualizan los punteros de entrada in situ antes de reproducir el grafo previamente capturado.
2. Cómputo en tiempo de prueba y modelos de razonamiento (o1/o3 y DeepSeek-R1)
Históricamente, los laboratorios de IA escalaban la inteligencia estrictamente dedicando más cómputo al preentrenamiento (modelos más grandes entrenados con más texto de internet). Los modelos de razonamiento como o1/o3 de OpenAI y DeepSeek-R1 desbloquearon un segundo eje de escalado: el cómputo en tiempo de prueba (escalado en tiempo de inferencia), permitiendo que los modelos "piensen" más tiempo antes de responder.
- Aprendizaje por refuerzo para la cadena de pensamiento (CoT).
- En lugar de depender puramente de ejemplos escritos por humanos de razonamiento paso a paso, estos modelos se entrenan mediante aprendizaje por refuerzo (RL) a gran escala (como GRPO – Group Relative Policy Optimization en DeepSeek-R1) en dominios verificables como las matemáticas, la programación y la lógica formal.
- El modelo genera múltiples rutas de razonamiento candidatas, recibe recompensas objetivas solo cuando su respuesta final pasa pruebas unitarias o verificación matemática, y descubre de forma autónoma comportamientos cognitivos emergentes, incluida la autoverificación, el retroceso cuando se alcanza un callejón sin salida y la división de problemas complejos en subobjetivos.
- Cómo escala el cómputo de inferencia.
- Cuando recibe un prompt difícil, el modelo genera miles de "tokens de pensamiento" internos dentro de un bloc de notas oculto antes de emitir una respuesta final. La precisión mejora logarítmicamente a medida que el modelo gasta más tokens de inferencia explorando hipótesis.
- Cambio en el equilibrio de cómputo. En los LLM tradicionales, la inferencia es barata y rápida (generando ~50 tokens de salida). En los modelos de razonamiento, una única consulta puede generar de 10 000 a 50 000 tokens de pensamiento, convirtiendo la inferencia en una carga de trabajo masiva y sostenida de generación por lotes dominada por el crecimiento de la caché KV y la eficiencia de la atención de contexto largo.
3. Prefill y decode desagregados
Servir un LLM consiste en dos fases computacionales fundamentalmente opuestas. Ejecutar ambas fases en exactamente la misma GPU crea graves conflictos de planificación y una infrautilización del hardware.
| Fase | Naturaleza de la carga de trabajo | Cuello de botella de hardware | Métrica de latencia |
|---|---|---|---|
| Prefill (procesamiento del prompt) | Procesa todos los tokens del prompt (p. ej., 10 000 tokens) en paralelo en una única pasada hacia adelante. | Limitado por cómputo (satura los Tensor Cores de la GPU con multiplicaciones de matrices masivas). | TTFT (Time-To-First-Token) |
| Decode (generación de tokens) | Genera los tokens de salida uno a uno secuencialmente, leyendo toda la caché KV en cada paso. | Limitado por el ancho de banda de memoria (los Tensor Cores permanecen mayormente inactivos esperando las lecturas de VRAM). | TPOT (Time-Per-Output-Token) |
- El problema de interferencia por coubicación.
- En el servicio unificado tradicional, si un usuario envía un enorme documento de 32 000 tokens para el prefill mientras otros 50 usuarios están en medio del streaming de tokens de decode, las matemáticas matriciales masivas del prefill acaparan los Tensor Cores de la GPU, causando congelamientos notables y picos de latencia ("tartamudeo") para los 50 usuarios en streaming.
- Además, el prefill necesita altos FLOPs de cómputo, mientras que el decode necesita un ancho de banda y una capacidad de memoria HBM masivos para alojar grandes cachés KV por lotes.
- Dividir el clúster (arquitectura desagregada).
- Los sistemas modernos de inferencia a hiperescala (como Mooncake, DistServe y NVIDIA Dynamo) dividen el clúster de GPU en dos grupos dedicados:
- 1. Grupo de prefill: optimizado para el rendimiento de cómputo bruto (alta utilización de los Tensor Cores, menor paralelismo de tensores) para procesar prompts largos rápidamente y alcanzar objetivos agresivos de Time-To-First-Token (TTFT).
- 2. Grupo de decode: optimizado para un alto ancho de banda de memoria y una gran capacidad de caché KV (paralelismo de tensores/expertos más amplio, tamaños de lote grandes) para transmitir tokens con fluidez al máximo de tokens por segundo.
- Transferencia de caché KV de alta velocidad. Una vez que una GPU de prefill termina de procesar un prompt y construye su caché KV inicial, transmite esa caché KV directamente a través de interconexiones ultrarrápidas NVLink o InfiniBand RDMA a la VRAM de una GPU de decode, que inmediatamente se hace cargo de la generación de tokens sin ninguna interferencia.