¿Cómo afecta el tamaño del lote a la latencia del primer token y de cada token?

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.

Los lotes más grandes suelen mejorar el rendimiento total de tokens, pero pueden aumentar la demora hasta el primer token y la latencia por token debido a la espera en cola, las iteraciones más pesadas y la presión sobre la memoria.

Un modelo local con un lote de uno puede infrautilizar su acelerador porque cada paso de decodificación mueve los pesos del modelo para realizar muy poco trabajo. Combinar solicitudes amortiza ese movimiento y aumenta el rendimiento. Sin embargo, las solicitudes pueden esperar a ser admitidas, los prefills largos pueden bloquear las decodificaciones y cada secuencia activa añade caché KV y trabajo de tokens, por lo que el mejor lote depende de si el objetivo es el rendimiento, la capacidad de respuesta o un buen rendimiento útil dentro de un objetivo de latencia.

El batching amortiza el trabajo del modelo entre solicitudes

Una operación matricial por lotes procesa tokens de varias secuencias conjuntamente, mejora la ocupación del hardware y distribuye los costes fijos de lanzamiento o transferencia de pesos entre una mayor cantidad de trabajo útil. Las mejoras son mayores antes de que se saturen el cómputo, el ancho de banda de memoria, la capacidad de la caché o la sobrecarga de planificación.

La programación a nivel de iteración de Orca permite que las secuencias completadas salgan y que se incorpore nuevo trabajo entre iteraciones de decodificación. Esto evita obligar a cada solicitud a esperar al miembro más largo de un lote estático.

El tamaño del lote puede referirse al máximo configurado, a las secuencias admitidas o a los tokens procesados en una iteración. Esos valores difieren con el batching continuo, por lo que los informes de rendimiento deben indicar qué cantidad se controló y observó. Esta distinción sigue siendo visible durante las pruebas posteriores en el hogar.

La latencia hasta el primer token incluye la espera en cola y el prefill

El tiempo hasta el primer token comienza cuando llega una solicitud e incluye la espera del planificador, el prefill del prompt y el primer paso de decodificación. Una política que espera para formar un lote puede aumentar el tiempo en cola, mientras que admitir un prompt grande puede ocupar una iteración y retrasar las solicitudes interactivas existentes.

Una comparación actual sobre el batching continuo explica cómo este admite y elimina solicitudes dinámicamente y cómo una programación agresiva intercambia rendimiento por TTFT. Aclara por qué el tamaño del lote por sí solo no puede predecir la capacidad de respuesta hasta el primer token. El resultado intermedio debe seguir siendo inspeccionable antes de que la automatización continúe.

El prefill fragmentado puede intercalar prompts largos con trabajo de decodificación, pero el tamaño de los fragmentos se convierte en otra variable de compromiso. Los fragmentos pequeños protegen los tokens interactivos, pero añaden sobrecarga de planificación; los fragmentos grandes mejoran la eficiencia del prefill y, al mismo tiempo, crean intervalos de bloqueo más largos. Ese límite debe medirse por separado en condiciones operativas realistas.

La latencia por token depende de la iteración activa

Durante la decodificación, cada paso generalmente produce un token por secuencia activa. Un mayor número de secuencias amplía el lote y puede aumentar la duración de cada iteración, incluso mientras crece el agregado de tokens por segundo. Los contextos desiguales, la presión sobre la caché, la expulsión preventiva y la sincronización distribuida añaden variabilidad.

DistServe separa el prefill y la decodificación porque tienen características computacionales y objetivos de servicio distintos. El diseño ilustra por qué optimizar el rendimiento agregado puede entrar en conflicto tanto con el TTFT como con el tiempo por token de salida. La consecuencia práctica aparece cuando varias fuentes compiten por un contexto limitado.

El límite de fallo consiste en seleccionar el lote más grande a partir de un gráfico de rendimiento sin conexión para un asistente doméstico interactivo. Si la espera en cola o las brechas entre tokens incumplen el objetivo de cara al usuario, el rendimiento nominal no constituye un buen rendimiento útil, independientemente de la utilización del acelerador.

Traza la frontera de buen rendimiento útil de los lotes

Reproduce chats cortos, prompts RAG largos y trabajos en segundo plano con tasas de llegada controladas. Varía el número máximo de secuencias y los límites de tokens procesados por lote mientras mides los percentiles de TTFT, la latencia entre tokens, la latencia de extremo a extremo, el rendimiento de prompts y salidas, la profundidad de la cola, el uso de la caché, la expulsión preventiva y las solicitudes rechazadas.

Utiliza el comportamiento del batching continuo descrito en el comportamiento del batching continuo para distinguir los límites configurados del lote activo que observa cada iteración. Mantén fijas las distribuciones de prompts y salidas, e informa del porcentaje de solicitudes que cumplen simultáneamente los objetivos del primer token y de la brecha entre tokens.

Elige la configuración que maximice el trabajo completado dentro de esos objetivos, en lugar de los tokens brutos por segundo. Aísla o rebaja la prioridad de los lotes en segundo plano cuando reduzcan el rendimiento útil interactivo y vuelve a realizar las pruebas después de cambiar el modelo, la cuantización, la mezcla de contextos o el planificador.

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.