Prefill frente a decodificación: por qué la inferencia de LLM tiene dos fases
Traducción automática
Este artículo se tradujo automáticamente a partir de la versión original en inglés.
El prefill procesa un prompt y crea su caché de atención. La decodificación utiliza esa caché para generar los tokens siguientes. Un prefill largo o agrupado en lotes puede aprovechar las operaciones matriciales grandes; la decodificación con lotes pequeños suele dedicar más tiempo a leer los pesos y las claves y valores almacenados en caché.
Esta distinción ayuda a los ingenieros a diagnosticar por separado la lentitud del primer token y la de la generación posterior.
Identifica qué fase es lenta
El prefill autorregresivo convencional produce los logits utilizados para muestrear el primer token de salida. Los pasos de decodificación posteriores añaden un token cada vez. El tiempo hasta el primer token también incluye la espera en cola, la tokenización, la planificación y la entrega por la red, por lo que un TTFT elevado no demuestra que el propio prefill sea lento.
| Síntoma | Qué medir antes de cambiar el servidor |
|---|---|
| El primer token tarda más con prompts más largos | Tiempo en cola y duración del prefill según la longitud de entrada |
| Los tokens posteriores se ralentizan con historiales más largos | Tiempo de decodificación y tráfico de la KV cache |
| Un prompt nuevo largo pausa otros flujos | Iteraciones del planificador e intervalos entre tokens |
| Los servidores separados dedican tiempo a transferir el estado | Bytes transferidos de KV, ancho de banda y espera en cola |
El prefill reutiliza los pesos entre los tokens del prompt. Aun así, la implementación puede cargar los bloques de las matrices más de una vez; no garantiza una única lectura literal de cada peso desde HBM. Splitwise describe cómo estas fases utilizan distintos recursos de hardware.
Qué cambia con el prefill por bloques
El prefill por bloques procesa un prompt largo durante varias iteraciones del planificador. El planificador documentado de vLLM da prioridad a las solicitudes de decodificación en curso y utiliza el presupuesto de tokens restante de la iteración para el prefill. El tamaño real del bloque depende del presupuesto disponible.
Esto puede reducir las interrupciones de los flujos existentes y aumentar a la vez el TTFT de la nueva solicitud. Los bloques más pequeños también añaden trabajo de planificación y vuelven a leer el estado anterior de la caché. Sarathi-Serve evalúa este compromiso; su incremento aproximado del 25% en el tiempo de prefill con bloques de 512 tokens se midió para Yi-34B con un grado de paralelismo tensorial de dos.
El serving desagregado, en cambio, coloca el prefill y la decodificación en grupos de GPU separados. Permite ajustar cada fase de forma independiente, pero debe transferir la KV cache de la solicitud. Comprueba el coste de transferencia y la utilización de los grupos antes de adoptar ese diseño. Dividir en bloques modifica el planificador; la desagregación también modifica el despliegue y la comunicación.
Guía de ingeniería: prefill frente a decodificación incluye cronogramas de ambos enfoques.