¿Por qué el procesamiento de indicaciones puede superar la generación local de tokens?

Eva Wong es la Redactora técnica y manitas residente en ZimaSpace. Una geek de toda la vida con pasión por los homelabs y el software de código abierto, se especializa en traducir conceptos técnicos complejos en guías accesibles y prácticas. Eva cree que el autoalojamiento debe ser divertido, no intimidante. A través de sus tutoriales, empodera a la comunidad para desmitificar las configuraciones de hardware, desde construir su primer NAS hasta dominar los contenedores Docker.

El procesamiento del prompt puede superar la generación de tokens porque un acelerador evalúa muchos tokens de entrada en paralelo, pero debe decodificar los tokens de salida secuencialmente.

Un panel de IA doméstica puede mostrar cientos o miles de tokens del prompt por segundo, mientras que la salida transmitida llega a una velocidad mucho menor. Esas cifras describen distintas fases de ejecución, no mediciones contradictorias. El prellenado procesa el contexto proporcionado como un bloque y crea el estado de atención, mientras que la decodificación ejecuta repetidamente el modelo para aceptar un token nuevo cada vez. La diferencia depende de la longitud del prompt, el tamaño del modelo, el ancho de banda de memoria, el procesamiento por lotes, la disposición de la caché y de si otras solicitudes en segundo plano comparten el mismo acelerador.

El prellenado y la decodificación resuelven problemas computacionales distintos

El procesamiento del prompt, a menudo llamado prellenado, evalúa la secuencia de entrada y crea el estado KV necesario para la generación posterior. La decodificación comienza solo después de que existe ese estado inicial y extiende la secuencia token a token.

La investigación sobre la ejecución de LLM describe el prellenado limitado por el cómputo y la decodificación limitada por el ancho de banda de memoria como fases distintas, con comportamientos de hardware diferentes.

Por lo tanto, el mismo modelo puede alcanzar una cifra alta de rendimiento de prellenado y una cifra mucho menor de tokens de salida sin que exista ningún fallo. Cada métrica cuenta los tokens que atraviesan una ruta de ejecución diferente.

Los tokens del prompt pueden evaluarse en grandes matrices paralelas

Durante el prellenado, hay muchas posiciones de consulta disponibles a la vez. Las multiplicaciones de matrices pueden combinar el trabajo de la secuencia, el lote, las cabezas y las dimensiones ocultas, lo que proporciona al acelerador suficientes operaciones paralelas para mantenerse ocupado.

FlashAttention reduce la sobrecarga de atención mediante un cálculo de atención por bloques que evita materializar repetidamente la matriz de atención completa en la lenta memoria del dispositivo.

Los prompts más largos aumentan el trabajo total de prellenado, pero también pueden mejorar el aprovechamiento aritmético hasta que la capacidad de memoria, los límites del kernel o la complejidad de la atención se convierten en el factor dominante.

Esto es rendimiento a través del bloque de entrada, no una indicación de que el servidor pudiera emitir la misma cantidad de tokens de salida independientes por segundo.

La decodificación no puede finalizar el siguiente token antes que el actual

La generación autorregresiva muestrea o selecciona un token, lo añade a la secuencia y luego ejecuta otro paso del modelo condicionado por ese resultado aceptado. El siguiente token aceptado no se conoce de antemano.

DistServe separa ambas fases porque las iteraciones de decodificación acceden repetidamente a los pesos del modelo y al estado KV activo, mientras producen solo una pequeña cantidad de salida nueva por secuencia.

Procesar por lotes varios usuarios puede paralelizar múltiples secuencias de decodificación, pero una conversación sigue avanzando mediante una cadena de decisiones de tokens dependientes entre sí.

La decodificación especulativa puede verificar varios candidatos propuestos a la vez, pero la decodificación normal sigue siendo serial cuando no se aceptan candidatos por adelantado.

Un alto rendimiento del prompt aún puede producir una larga espera hasta el primer token

Los tokens por segundo dividen el trabajo de procesamiento del prompt completado entre el tamaño del prompt. Un contexto muy largo puede ofrecer un rendimiento impresionante y, aun así, tardar varios segundos antes de que aparezca el primer token generado.

ZimaSpace separa la carga, la evaluación del prompt y la generación en su explicación de las fases de latencia de la IA. Un modelo en memoria elimina el retraso de recarga, pero no elimina el coste de evaluar un prompt grande.

Por tanto, el tiempo hasta el primer token es la mejor medida interactiva del prellenado. Los tokens del prompt por segundo son útiles para comparar la eficiencia con la que el entorno de ejecución procesa entradas de distintas longitudes.

Los prellenados largos pueden ralentizar a los usuarios que ya están en fase de decodificación

Un prompt documental con un uso intensivo del cómputo puede entrar en el mismo acelerador mientras otro usuario recibe tokens transmitidos. Si el entorno de ejecución combina ambas cargas sin control, el prellenado grande puede alargar las iteraciones de decodificación.

DistServe informa de una fuerte interferencia entre prellenado y decodificación cuando ambas fases se ejecutan conjuntamente y se programan de forma coordinada.

El servidor puede seguir mostrando una alta utilización agregada, pero el chat activo experimenta intervalos mayores entre tokens. El rendimiento y la fluidez percibida por el usuario pueden avanzar en direcciones opuestas.

Los trabajadores separados, la programación consciente de las fases o las oportunidades de decodificación reservadas pueden proteger la salida interactiva cuando el hardware y el entorno de ejecución lo permiten.

La fragmentación intercambia parte de la eficiencia del prellenado por una mejor capacidad de respuesta

Un entorno de ejecución puede dividir un prompt largo en fragmentos más pequeños e intercalar esos fragmentos con el trabajo de decodificación. El prompt requiere más turnos de programación, pero ningún prellenado monopoliza una única iteración muy larga.

Sarathi-Serve utiliza prellenados fragmentados para reducir la interferencia y mantener oportunidades útiles de procesamiento por lotes.

El tamaño de fragmento óptimo depende de las longitudes de los prompts, la arquitectura del modelo, la capacidad del acelerador y el objetivo de latencia de las conversaciones activas.

Mide por separado el tiempo de procesamiento del prompt, el tiempo hasta el primer token, el tiempo entre tokens y los tokens de salida por segundo. La fase con el menor rendimiento nominal no es automáticamente la que provoca la espera más larga para el usuario.

Centro de Tecnología e IA

Más para leer

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.