La desagregación es un problema de mil GPU

Todos los principales marcos de inferencia enviaron desglose de decodificación previa este año. NVIDIA lo incorporó a Dynamo. SGLang lo convirtió en el predeterminado para implementaciones a gran escala. vLLM agregó una API de conector KV para admitirlo de forma nativa. El consenso se está formando rápidamente: divida su precarga y decodificación en grupos de GPU separados y el rendimiento mejorará.

El consenso es erróneo para la mayoría de los equipos.

El análisis de Doubleword muestra que una implementación desagregada equilibrada coincide con el rendimiento colocado, pero en recuentos de GPU pequeños las pérdidas por redondeo dominan: no se pueden asignar GPU fraccionarias, por lo que las ganancias de especialización se ven devoradas por la utilización incompleta de los trabajadores. El beneficio práctico a esa escala es el ajuste SLO independiente, no el rendimiento.

Un estudio de junio de 2025 que evaluó cientos de miles de puntos de diseño encontró que la desagregación es más efectiva para patrones de tráfico pesado previo al llenado y modelos más grandes. Para las cargas de trabajo de tráfico mixto que la mayoría de los equipos ejecutan, las colas y la transferencia de caché KV entre nodos dominaron la latencia de un extremo a otro. Los equipos que se desagregaron movieron el cuello de botella. No lo quitaron.

Me encontré con esto en una carga de trabajo de inferencia que sirve a un modelo de clasificación de tamaño mediano. TPOT se disparó con el tráfico intenso y el primer instinto fue separar el prellenado de la decodificación. En cambio, habilité el precarga fragmentado en el mismo grupo de GPU. TPOT estabilizado. El problema era la interferencia de programación y el prellenado fragmentado lo resolvió sin agregar un salto de red.

Lo que resuelve la desagregación: el problema de la interferencia

El precarga y la decodificación tienen perfiles de hardware opuestos. El prellenado está vinculado a la computación: multiplicaciones de matrices paralelas en toda la secuencia de entrada, utilización de computación de GPU del 80 al 95 por ciento. La decodificación está limitada al ancho de banda de la memoria: lecturas secuenciales de caché KV que generan un token a la vez, utilización de cómputo por debajo del 5 por ciento en un H100.

Cuando ambos comparten GPU, se pelean por los mismos recursos. Una única solicitud de llenado previo grande que llega a mitad de la decodificación aumenta el tiempo por token de salida de 2 a 30 veces en cargas de trabajo en ráfagas. El lote de decodificación se detiene mientras el precarga satura las unidades de cómputo.

DistServe demostró que la solución funciona a escala: separar el precarga y la decodificación en grupos dedicados atendió 7,4 veces más solicitudes dentro de las mismas limitaciones de latencia. En la escala comparada por DistServe, la desagregación es sin lugar a dudas la decisión correcta.

El siguiente diagrama muestra dónde se encuentra el cuello de botella en cada enfoque: precarga colocada, desagregada y fragmentada.

Pero existe una solución más simple que maneja la mayor parte de la interferencia sin cambiar la arquitectura.

Precarga fragmentada: la solución que la mayoría de los equipos realmente necesitan

El precarga fragmentado divide las solicitudes de precarga largas en partes más pequeñas y las intercala con lotes de decodificación en la misma GPU. No hay grupos de nodos separados. Sin transferencia de caché KV a través de la red. No hay relación P:D para sintonizar.

TNG Technology Consulting midió un aumento del 50 por ciento en el rendimiento total de tokens utilizando vLLM estándar con precarga fragmentada habilitada. Los lotes de decodificación aún se ejecutaban entre fragmentos de precarga en el mismo hardware, pero la interferencia de programación cayó a un nivel que la mayoría de las cargas de trabajo de producción pueden tolerar.

Piense en ello como una plaza de peaje en una autopista: en lugar de cerrar todos los carriles para un solo camión de gran tamaño, el precarga fragmentado permite que el camión pase por un carril a la vez mientras el tráfico regular sigue avanzando por los demás.

El precarga fragmentado no elimina la interferencia por completo. Lo limita. Cada fragmento de precarga ocupa las unidades de cómputo durante un período limitado y luego cede para la decodificación. Para cargas de trabajo inferiores a aproximadamente 50 solicitudes por segundo con longitudes de aviso moderadas, ese límite es bastante estricto.

Tres costos de la desagregación: lo que los explicadores omiten

Los artículos explicativos cubren los beneficios de la desagregación. Se saltan lo que cuesta.

El impuesto de transferencia KV. Cada solicitud que finaliza el llenado previo debe enviar su caché KV a un nodo de decodificación a través de la red. Para un modelo de 70B de parámetros, eso es aproximadamente 2,6 GB por solicitud.

Cuando el prellenado y la decodificación comparten un nodo, la caché KV permanece en la memoria de la GPU. Una vez que se desagrega entre nodos, esa transferencia llega a la interconexión de la red y el ancho de banda disponible disminuye en órdenes de magnitud dependiendo de su topología.

Es como dividir la línea de montaje de una fábrica en dos edificios: la especialización por edificio mejora, pero ahora se transportan piezas a medio terminar entre ellos. Sin InfiniBand o NVLink en el mismo rack, el costo del transporte domina. No se puede desagregar para salir de una red lenta.

La superficie operativa. La desagregación duplica la gestión de su infraestructura. Ahora puede ejecutar grupos de nodos de precarga y decodificación independientes, cada uno con su propia política de escalado. La relación P:D depende de su combinación de carga de trabajo: LMSYS evaluó de forma independiente 4 nodos de precarga y 9 nodos de decodificación para DeepSeek-R1, y esos números cambian en el momento en que cambia la relación de longitud de mensaje a salida.

No hay un retroceso elegante. Si un nodo de precarga deja de funcionar, los nodos de decodificación no pueden completarse. Las funciones se asignan en el lanzamiento.

El acantilado del fracaso silencioso. Con baja simultaneidad, la publicación desagregada funciona bien. En la producción simultánea, se interrumpe de manera que no produce errores. El número 9266 de SGLang documenta fallas sistemáticas en la transferencia de caché de KV en 64 o más solicitudes simultáneas, devolviendo HTTP 400 a los clientes.

El problema n.° 30233 describe una falla peor: cuando la entrada excede la longitud máxima de la solicitud, el lado de prellenado se cancela pero aún transfiere un caché KV de un solo token. El lado de decodificación se genera a partir de memoria no inicializada. No aparece ningún error para la persona que llama.

La matemática de la decisión: tres condiciones que deben cumplirse

El manual de inferencia de Modular informa una caída del rendimiento del 20 al 30 por ciento debido a la desagregación en cargas de trabajo pequeñas o no ajustadas. Los gastos generales son reales y se anticipan: usted paga el costo de transferencia KV en cada solicitud, independientemente de si se materializa la ganancia de rendimiento.

La desagregación se amortiza por sí sola sólo cuando se cumplen tres condiciones simultáneamente:

Suficientes GPU para una asignación limpia. DeepSeek necesitaba miles de GPU antes de que la relación P:D produjera recuentos de nodos enteros que coincidieran con su combinación de tráfico. Con 8 a 16 GPU, sus opciones de relación son 1:7 o 2:6, ninguna de las cuales se adapta a su carga de trabajo.

Ancho de banda de red que sostiene la tasa de producción de KV. Si su grupo de precarga genera cachés KV más rápido de lo que la interconexión puede entregarlos, los nodos de decodificación están inactivos esperando datos. El cuello de botella migra de la interferencia informática a la transferencia de red.

Escalado automático dinámico para mezclas de tráfico cambiantes. Una carga de trabajo de chat (indicaciones breves, decodificación larga) necesita una relación P:D diferente a la de una canalización RAG (indicaciones largas, decodificación corta). Si su combinación de tráfico cambia durante el día y sus grupos de nodos están estáticos, estará sobreaprovisionado por un lado y hambriento por el otro.

Si alguna de estas condiciones no se cumple, el relleno previo fragmentado es la mejor opción predeterminada. El siguiente diagrama de flujo de decisiones asigna estas tres condiciones a una elección de ruta concreta.

Precarga fragmentada frente a servicio desagregado: rendimiento, costo operativo y características de falla.

Qué medir antes de decidir

No divida su infraestructura en función de diagramas de arquitectura. Mida primero.

TPOT en p95, no en p50. La mediana oculta los picos de interferencia a los que apunta la desagregación. Si su token de tiempo por salida p95 está dentro del SLO en precarga fragmentada, no tiene el problema que resuelve la desagregación.

Fracción de prellenado de TTFT. Perfile sus solicitudes reales. Si la ejecución previa al llenado es una pequeña fracción del tiempo hasta el primer token, el cuello de botella está en otra parte: colas, programación o red. La desagregación no los solucionará.

Fiabilidad de transferencia KV en concurrencia. Antes de comprometerse con la desagregación a escala, ejecútela en niveles de simultaneidad de producción, no solo en QPS bajos. Los modos de error documentados en el rastreador de problemas de SGLang no aparecen hasta que se cruza un umbral de concurrencia.

Conclusión: comience con precarga fragmentada

Por defecto, precarga fragmentada. Resuelve el problema de interferencia de programación que realmente tienen la mayoría de los equipos, sin sobrecarga de red y sin expansión de la superficie operativa. Compare su p95 TPOT. Si se mantiene, deténgase allí.

La desagregación es la arquitectura adecuada por encima de aproximadamente mil GPU, con una interconexión rápida y con la capacidad de ingeniería para gestionar el ajuste de la relación P:D y la confiabilidad de la transferencia KV. Esas condiciones describen a los hiperescaladores y a los grandes proveedores de inferencias. No describen la mayoría de los equipos de producción que enviarán funciones LLM en 2026.

Lectura adicional

DistServe: precarga y decodificación desagregadas para la prestación de servicios de LLM optimizada para Goodput (OSDI 2024, el documento fundacional sobre ganancias de desagregación)

Cuándo desagregar (análisis de Doubleword de las condiciones requeridas para que la desagregación dé sus frutos)

Beyond the Buzz: A Pragmatic Take on Inference Disaggregation (junio de 2025, evaluación sistemática de la desagregación en cientos de miles de puntos de diseño)

Precarga fragmentada en H100 (medición de rendimiento de +50 % de TNG)

Manual de inferencia de Modular LLM (criterios de decisión y advertencia de caída del 20-30% de Modular)

The Inference Unbundling (análisis de Wing VC de la división de cómputo/ancho de banda)

···

Gracias por leer. Soy Mostafa Ibrahim, fundador de Codecontent, una agencia de contenido técnico centrada en los desarrolladores. Escribo sobre sistemas agentes, RAG e IA de producción. Si desea mantenerse en contacto o discutir las ideas de este artículo, puede encontrarme en LinkedIn aquí.