¿Qué es la desagregación de prellenado y decodificación, y por qué cambia la prestación de servicios de los LLM?

La desagregación de prefilling y decodificación separa el procesamiento del prompt de la generación de tokens, para que cada fase de un LLM pueda utilizar distintos workers, planificaciones y planes de capacidad.

Un prompt RAG largo exige un gran pico de cómputo antes de generar su primer token, mientras que la decodificación realiza después muchas iteraciones más pequeñas y sensibles al ancho de banda de la memoria. Ejecutar ambas fases en una sola GPU es sencillo, pero permite que los prefilling largos interrumpan las conversaciones activas. La desagregación mueve la solicitud y su estado KV entre grupos de recursos, intercambiando coordinación y costes de transferencia adicionales por un control independiente de la latencia del primer token y de la latencia por token.

El prefilling y la decodificación tienen perfiles de recursos diferentes

El prefilling procesa en paralelo todos los tokens del prompt y crea la caché KV, generando un pico de cómputo cuya duración aumenta con la longitud del prompt. La decodificación lee repetidamente los pesos del modelo y el estado KV acumulado para generar uno o varios tokens nuevos.

DistServe identifica la interferencia entre prefilling y decodificación cuando ambas fases comparten GPU, y vincula el prefilling al tiempo hasta el primer token, mientras que la decodificación determina el tiempo por token de salida. Separarlas permite al planificador proteger cada objetivo de forma independiente. Esta distinción sigue siendo visible durante las pruebas domésticas posteriores.

La desagregación no es un paralelismo ordinario del modelo. El mismo modelo puede existir en ambos grupos, mientras que las solicitudes se mueven entre fases funcionales en lugar de entre capas de una única pasada hacia delante. El resultado intermedio debe seguir siendo inspeccionable antes de que la automatización continúe.

La transferencia de KV conecta los dos grupos de workers

Después del prefilling, el sistema debe hacer que la caché KV de la solicitud esté disponible para un worker de decodificación. Puede transferir tensores mediante PCIe o una red de interconexión, utilizar memoria compartida o ubicar los workers para minimizar el coste del movimiento.

Splitwise estudia el servicio específico por fase con máquinas y planificación específicas para cada fase, y muestra por qué la asignación de hardware puede adaptarse a las distintas características computacionales del trabajo con prompts y tokens. La gestión de colas y el movimiento del estado pasan a formar parte de la ruta de servicio. Ese límite debe medirse por separado en condiciones operativas realistas.

El grupo de decodificación no puede comenzar hasta disponer de un estado KV y unos metadatos de solicitud coherentes. Los contextos grandes aumentan los bytes transferidos, por lo que una separación de fases supuestamente más rápida puede perder frente a la ejecución conjunta en una red doméstica pequeña.

El escalado independiente cambia la planificación de capacidad

Los grupos separados pueden añadir capacidad de prefilling para picos de documentos largos sin ampliar proporcionalmente la capacidad de decodificación, o proteger la decodificación de voz mientras la generación de resúmenes en segundo plano consume workers de prompts. El control de admisión puede dirigirse a dos colas y dos presupuestos de latencia. La consecuencia práctica aparece cuando varias fuentes compiten por un contexto limitado.

Mooncake describe una coordinación de la caché KV que trata el movimiento y el almacenamiento de la caché KV como aspectos fundamentales del servicio. La arquitectura muestra que la desagregación desplaza el cuello de botella desde la planificación pura de la GPU hacia la transferencia del estado y la coordinación de la caché.

El límite de fallo es una escala o un ancho de banda insuficientes. Una o dos GPU domésticas pueden no tener ningún dispositivo libre para la especialización, y la duplicación de los pesos del modelo, junto con la transferencia de KV, puede consumir más memoria y latencia que la interferencia que se pretende eliminar.

-15% OFF

ZimaBoard 2 - Mini servidor doméstico para tu gran idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Compara los presupuestos de las fases con ejecución conjunta y desagregada

Mide los tokens del prompt por segundo, el tiempo hasta el primer token, el tiempo por token de salida, los bytes de KV transferidos, el tiempo de transferencia, la espera en cola, la duplicación de la memoria del modelo, la energía y la recuperación ante fallos para prompts cortos, largos y mixtos. Esta dependencia debe seguir siendo explícita en la interfaz final.

Utiliza el prefilling por fragmentos como alternativa con ejecución conjunta. Prueba el prefilling por fragmentos antes de añadir un segundo grupo y, después, compara trazas de llegada idénticas en ambas arquitecturas. Por tanto, el resultado debe comprobarse con la evidencia original.

Adopta la desagregación solo cuando se haya medido la interferencia entre fases y la ruta de transferencia preserve ambos objetivos de latencia. En un servidor pequeño, una planificación conjunta con fragmentos de prefilling acotados puede ofrecer el mismo resultado para el usuario con menos movimiento de estado.