Presupuesto de TTFT: prefill, agrupación por lotes, cuantización y enrutamiento para productos de LLM en streaming
Trata el TTFT como un costo de prefill: define un presupuesto de tokens de prompt y luego elige agrupación por lotes, cuantización y enrutamiento que compren la latencia del primer token sin arruinar el throughput ni el gasto.
El equilibrio: la latencia del primer token es un impuesto de prefill
El equilibrio es simple: la latencia del primer token se compra con capacidad de prefill, y cada ajuste que la reduce puede aumentar el gasto o reducir el throughput. Un presupuesto útil es TTFT ~= prompt_tokens / prefill_tokens_per_s + queue_wait + network. El tiempo hasta el primer token mide el retraso desde el envío del prompt hasta el primer token de salida. En productos de LLM en streaming, ese retraso es lo primero que sienten los usuarios, por lo que debe tratarse como una línea de costo, no como un misterio.
La latencia del primer token está impulsada en gran medida por la fase de prefill, donde el modelo procesa el prompt completo antes de generar el primer token. Eso significa que un prompt de sistema largo, un contexto recuperado, el historial de conversación o la salida de una herramienta no son solo una entrada de calidad; son una entrada de latencia. Si el prompt crece, el término de prefill crece. Si el nodo de servicio está ocupado, el término de cola crece. Si la solicitud atraviesa una ruta de red lenta, el término de red crece. La opinión llega después de la aritmética: no persigas un TTFT más bajo agregando capacidad que no puedes permitirte, y no ocultes un problema de tamaño del prompt detrás de una GPU más grande.
En producción, el TTFT importa porque moldea la responsividad percibida. Un usuario que no ve el primer token rápidamente puede asumir que el producto está roto, incluso si el resto del flujo es rápido. La latencia entre tokens es la otra mitad de la experiencia, pero no rescata un inicio lento. Si el primer token llega tarde, el flujo parece muerto antes de comenzar.
Define un presupuesto de TTFT antes de ajustar
Empieza con un presupuesto, no con una referencia. Define los rangos de tokens de prompt que atiendes: chat corto, contexto largo, trazas de agentes, respuestas con mucho RAG y flujos con mucho prompt de sistema. Para cada rango, define objetivos de TTFT p50 y p95 que puedas defender. Luego escríbelo como una ecuación que puedas inspeccionar:
- Término de prefill: tokens de prompt divididos por los tokens de prefill por segundo que tu ruta de servicio puede sostener.
- Término de cola: tiempo de espera para que un worker, un slot o un lote acepte la solicitud.
- Término de red: de cliente a gateway, de gateway a worker, y cualquier sobrecarga de arranque en frío o enrutamiento.
El presupuesto debe dividirse por responsabilidad. El equipo de modelo es responsable de la eficiencia de tokens de prompt y de la elección del modelo. El equipo de servicio es responsable de la agrupación por lotes, la reutilización de caché y la ubicación de workers. El equipo de producto es responsable de la arquitectura del prompt y de la tolerancia al retraso visible para el usuario. Si se incumple el objetivo p95, la primera pregunta es qué término creció, no qué equipo tiene la culpa.
Compra latencia sin pagar dos veces
La primera palanca es el presupuesto de tokens de prompt. Recorta lo que no necesita estar en el prompt. Comprime el historial, resume los turnos anteriores, recupera solo el contexto que cambia la respuesta y mueve las instrucciones estables a un prefijo en caché cuando tu stack lo soporte. Este es el control de latencia más barato porque reduce directamente el término de prefill. También reduce el gasto por solicitud, lo que hace más fácil defender el resto del stack.
La segunda palanca es la agrupación por lotes. Esta puede mejorar el throughput y a veces la latencia, pero los lotes más grandes pueden sacrificar throughput a cambio de latencia por solicitud. Ese equilibrio es por lo que un tamaño máximo de lote fijo no es un detalle; es una decisión de producto. Un lote pequeño puede proteger el TTFT pero dejar capacidad de GPU ociosa. Un lote grande puede aumentar los tokens por segundo y reducir el costo por token, pero puede hacer esperar al primer token. La configuración correcta depende de la distribución de tokens de prompt y del objetivo p95, no de un máximo genérico.
La tercera palanca es la elección de modelo y precisión. Los modelos cuantizados o más pequeños pueden reducir la memoria y la computación por token, lo que puede reducir el TTFT y la latencia de extremo a extremo. Esta es una decisión de calidad frente a latencia, no una ganancia gratuita. Mide el delta de cuantización en las tareas que importan: seguimiento de instrucciones, uso de herramientas, recuperación de contexto largo y seguridad. Si el modelo más pequeño o cuantizado mantiene el producto útil, puede ser la forma más rápida de comprar la latencia del primer token. Si no lo hace, los ahorros de latencia no son reales, porque pagarás en carga de soporte, reintentos o abandono de usuarios.
La cuarta palanca es el enrutamiento. El enrutamiento consciente de la caché puede evitar volver a ejecutar prefill enrutando solicitudes a nodos que ya mantienen una caché KV relevante, por lo que las guías de producción lo recomiendan sobre round-robin para inferencia con múltiples réplicas. Una solicitud que llega a un worker frío repite trabajo que otro worker ya hizo. El enrutamiento consciente de la caché es más dependiente del estado y más difícil de depurar, pero puede convertir prompts repetidos en una ruta más barata y más rápida.
Cada palanca debe evaluarse en función de $/1k tokens, no solo de la latencia. Una configuración que reduce el TTFT gastando más en capacidad ociosa puede ser peor que una configuración que acepta un primer token ligeramente más lento y mantiene la economía unitaria sana. El objetivo no es el primer token más rápido posible; es el primer token que encaja en el presupuesto de latencia y el presupuesto de costo del producto.
Qué registrar y cómo decidir
Registra las métricas de inferencia que te permiten reconstruir el presupuesto. Registra TTFT, latencia entre tokens, tokens por segundo, tokens de prompt, tokens de salida, modelo, tamaño de lote, acierto o fallo de caché y $/1k tokens. Si no puedes separar el tiempo de prefill del tiempo de cola, no puedes saber si un primer token lento es un problema de modelo, programación o enrutamiento.
- Define un presupuesto de tokens de prompt para cada superficie de producto y aplícalo en la ruta de solicitud.
- Define objetivos de TTFT p50 y p95 que coincidan con la experiencia de usuario, no con la página de marketing.
- Elige un tamaño máximo de lote que proteja el objetivo p95 mientras mantiene un throughput lo suficientemente alto para controlar el costo.
- Prueba modelos cuantizados o más pequeños en tareas reales de producto antes de tratarlos como una solución de latencia.
- Usa enrutamiento consciente de la caché cuando el contexto repetido sea común y mide los ahorros de prefill que produce.
- Revisa el costo por 1k tokens junto con la latencia, porque un primer token más rápido que duplica el gasto no es una ganancia.
La regla práctica es tratar el TTFT como un costo de la fase de prefill. Si el prompt es demasiado largo, corrige el prompt. Si la cola es demasiado profunda, corrige la programación. Si el modelo es demasiado pesado, corrige el modelo. Si la caché está fría, corrige el enrutamiento. Cuando el presupuesto es explícito, las decisiones dejan de ser intuiciones y se convierten en aritmética.