dentro de su propia empresa y casi cualquier fracaso es barato: lo vuelve a intentar, retrocede o incluso lo ignora. Coloque ese mismo flujo de trabajo detrás del servidor API o MCP de un cliente y la gracia desaparecerá. Ahora sólo importa una cosa: ¿obtuvo el cliente un resultado correcto y utilizable? Su proceso depende de que el tuyo entregue uno. Ellos, no usted, ahora deciden qué se considera entregado. En Databook procesamos miles de millones de tokens para las empresas más grandes del mundo; Este artículo se basa en datos reales de flujos de producción a escala. Espero que te ofrezca algunas ideas útiles.
Lograr ese resultado es más difícil de lo que parece, porque los LLM son notoriamente poco confiables. Fallan con frecuencia, en cuatro tipos: una respuesta no válida (vacía, no analizable o simplemente incorrecta), un error grave, ninguna respuesta o ninguna respuesta a tiempo. Y toda la carrera sólo tiene éxito si cada paso lo hace, por lo que cuanto más encadenes, más posibilidades habrá de que uno de ellos falle. Un flujo de trabajo de pasos individualmente excelentes aún puede resultar en un lanzamiento de moneda.
Dentro de tu propia empresa puedes absorber cada uno de estos, porque tienes holgura en todos los ejes: vuelve a intentar el paso fallido, espera a que pase el paso lento, gasta un poco más, relaja la barra si es necesario. Coloque el mismo flujo de trabajo detrás de la API de un cliente y la holgura desaparecerá, porque la ejecución ahora tiene que borrar tres presupuestos de recursos al mismo tiempo, ninguno de los cuales usted establece:
Tiempo: una ventana que se cierra independientemente de que haya terminado o no: un tiempo de espera estricto de la puerta de enlace (de uno a tres minutos, a veces cinco) que corta la conexión a mitad de ejecución, o algo más suave: un SLA, una persona que llama bloqueada en el resultado, un proceso que solo puede esperar un tiempo. Y no se reanuda: cuando se cierra la ventana, el cliente simplemente vuelve a intentarlo, comenzando todo el proceso desde cero. Costo: ahora un margen, no un fondo común. Cada ejecución conlleva un precio que el cliente ya pagó, por lo que tiene que resultar rentable, no simplemente asequible. Y el cliente, no usted, decide con qué frecuencia se ejecuta. Tokens y tarifa: un presupuesto de token por minuto (TPM) que compartes con todos los clientes a la vez y que tienden a llamar en las mismas ráfagas. Llegas al techo exactamente cuando la carga es más pesada, que es exactamente cuando la latencia es peor.
Debajo de los tres se encuentra un piso duro por debajo del cual nunca se negocia: la calidad. La respuesta tiene que ser correcta para contar. Una respuesta rápida, barata y puntual que sea incorrecta sigue siendo un fracaso. La calidad no es un presupuesto que se gasta.
Cualquiera de estos podrías gestionarlo por sí solo. El problema es que se aplican juntos y se tiran entre sí, por lo que la solución obvia para uno pasa por el otro. Espera un paso lento y arruinarás la ventana de tiempo. Compite con una segunda copia para ganarle al reloj y quemas costos y cuotas. Si buscas un modelo más fuerte para despejar el piso de calidad, serás más lento. Ninguno de los presupuestos es suyo para que lo afloje, por lo que el único movimiento que queda es negociar deliberadamente entre todos ellos a la vez, sin caer nunca por debajo del mínimo.
Eso es lo que hace que un flujo de trabajo orientado al cliente sea algo realmente diferente de construir y, a veces, obliga a seguir un manual que, desde dentro, mira totalmente hacia atrás:
Cancelar una llamada que no ha fallado Disparar un duplicado de una llamada por la que ya estás pagando Pasar a un modelo más débil a propósito
Dentro de tus propios muros nunca te molestarías. Simplemente dejarías que terminara el paso lento. Y el presupuesto que más silenciosamente te castiga es el tiempo: si lo pierdes, nada parecerá roto de tu lado. Una respuesta perfecta que llega unos segundos tarde todavía se lee como un éxito en sus paneles y como un fracaso para el cliente, y es el único límite que nada en la pila impone para usted.
Aquí está la tesis, desde el principio, porque todo lo demás sirve: una vez que la calidad supera el listón, la entrega confiable es una cuestión de variación, no de velocidad. Un tiempo de finalización predecible supera a uno rápido con una cola larga, porque sus clientes no pueden ejecutar su infraestructura en el mejor de los casos; Tienen que construir para lo peor.
Qué es y qué no es esto: flujos de trabajo, no agentes de razonamiento libres
Una distinción desde el principio, porque lo cambia todo. Se trata de un flujo de trabajo agente: un flujo de proceso conocido con pasos impulsados por LLM en su interior, dirigido por un orquestador determinista. No es un agente razonador que decide su próximo movimiento en tiempo de ejecución. Para la misma tarea, un flujo de trabajo es simplemente más rápido: ya conoce el plan, se salta la deliberación y ejecuta cada paso independiente en paralelo, por lo que llega a la misma respuesta en una fracción del tiempo y del costo que tomaría un agente de razonamiento. Ambos tienen su lugar (los agentes racionales son mucho más flexibles), pero fallan de manera diferente y los arreglas de manera diferente. El problema de un agente razonador es decidir qué hacer; El problema de un flujo de trabajo (el que sienten los clientes) es entregar lo que ya sabe hacer, con calidad y en tiempo. Este artículo trata sobre este último.
Cómo está construido nuestro sistema
Los hallazgos a continuación provienen de nuestra arquitectura y deberían generalizarse. Estas son llamadas API directas y ordinarias. Aún así, es útil conocer la configuración para poder compararla con la suya.
Ejecutamos un orquestador personalizado a través de API administradas de terceros (no hay modelos autohospedados en este conjunto de datos) y ejecutamos modelos emblemáticos directamente a través de sus proveedores (OpenAI, Anthropic,…) y a través de plataformas administradas (Bedrock, Databricks,…), por lo que los mejores modelos tienen más de 1 proveedor. Eso nos permite comparar rutas de servicio y mover el trabajo entre ellas.
Nuestras cargas de trabajo son una combinación: llamadas simples a agentes, razonamiento profundo, extracciones, JSON y salidas de texto libre. Para una gran fracción de llamadas, sintetizamos una gran base de hechos en una respuesta, es decir, entradas grandes y salidas pequeñas a medianas. Los análisis de este artículo mantienen constante el tamaño de entrada y salida dentro de los depósitos (consulte el apéndice).
Las colas lentas que encontramos son en gran medida transitorias. Tenga en cuenta que si su arquitectura es autohospedada o tiene capacidad dedicada, la cola puede comportarse de manera diferente y justificará otro enfoque. En segundo lugar, tener varios proveedores es lo que hace que sea práctico enrutar una cobertura a un presupuesto separado. Con un solo proveedor, hay menos movimientos disponibles.
El reclamo y los recibos.
Así que aquí está el movimiento que suena al revés: cortamos un paso en 20-30 segundos incluso cuando sabemos que podría haber respondido perfectamente un poco más tarde, y eso hace que el sistema sea más confiable, no menos.
Eso no es una corazonada. Es cierto en el papel (las matemáticas de los reintentos de cola pesada son inequívocas) y es cierto en los datos: un análisis de más de un millón de llamadas recientes de LLM de producción en nuestras cargas de trabajo empresariales: tráfico real de clientes. Lo primero que el tráfico te dice es lo extraño que es realmente el momento en que se realiza una sola llamada. Una llamada típica de mayor duración regresa en aproximadamente una docena de segundos. Pero uno de cada cien tarda treinta segundos, a veces un minuto completo o más, sin ningún motivo relacionado con la cantidad de trabajo que estaba realizando.
Esa brecha entre la llamada típica y la lenta subyace en gran parte de este artículo. El resto del artículo analiza qué hacer al respecto.
¿Por qué el reloj no perdona?
Un flujo de trabajo no se juzga por su promedio. Se juzga según una fecha límite. En promedio nuestros flujos terminan cómodamente; sin embargo, las ejecuciones atípicas en colas largas no lo hacen. Esas colas no están rotas. Un poco más tarde devolverían una respuesta perfecta y, en una ejecución interna, contarían como éxitos. Por parte del cliente, cada uno de ellos es un fracaso. Toda la cola de su distribución de latencia, por correcta que sea, se convierte en una adición a su tasa de fallas.
Es por eso que el número que importa aquí no es la latencia promedio, sino la variación. Una mediana rápida no te compra nada si tu cola es larga.
La segunda presión es el costo hundido. Cuanto más profundo esté en un flujo de trabajo, más habrá gastado: tiempo, dólares y su cuota de TPM. Un fracaso en el paso nueve es mucho más caro que el mismo fracaso en el paso dos. Tiras a la basura todo lo que el flujo de trabajo creó y te queda menos tiempo para cambiar de marcha. Nunca reiniciamos todo el flujo de trabajo nosotros mismos, pero el cliente sí lo hará. Si fallamos, es casi seguro que lo volverán a intentar, iniciando el flujo completo nuevamente desde el principio. Eso agrava el problema de nuestro lado. Quema más costos, más presupuesto de tokens y el presupuesto de errores en el SLA. Y debido a que las condiciones que hicieron que la ejecución fallara generalmente no han cambiado, el reintento tiene una probabilidad similar de fallar. Peor aún, tiende a ocurrir durante una ventana de alto TPM. El peor momento posible para acumular carga adicional en un sistema que ya está bajo presión, y exactamente cuando las probabilidades de volver a fallar son mayores.
Hay un segundo multiplicador y es fácil pasarlo por alto. El primero es el de la apertura: la confiabilidad se complica, por lo que una cadena de pasos individualmente excelentes aún puede surgir al lanzar una moneda1. Pero ese fracaso siempre se cuenta como una historia sobre lo correcto: obtener una respuesta incorrecta.
Esto es lo que casi nunca escuchas: exactamente la misma combinación ocurre en el reloj. Cada paso añade su pequeña posibilidad de aterrizar en la cola lenta, y esas posibilidades se acumulan. Entonces, cuantos más pasos encadene, más probable será que al menos uno de ellos supere la fecha límite, incluso cuando cada paso sea individualmente rápido. Ése es el multiplicador del que trata este artículo y es el que la literatura omite. Así que miremos los números.
Cómo se ve realmente el tiempo de respuesta de un LLM
Los tiempos típicos en el gráfico anterior se ubican en una banda bastante ajustada: cada modelo finaliza una llamada típica entre ocho y veinte segundos. Las colas no están nada apretadas. La llamada del percentil 99 de un modelo se produce en alrededor de 30 segundos, la de otro después de 80. Mediana similar, peor de los casos tremendamente diferente. Prométale a un cliente su mediana y estará mintiendo a las llamadas 1 de cada 20 y 1 de cada 100 en la cola, y un flujo de trabajo de varios pasos los afecta constantemente. Un tiempo típico rápido no es predecible.
La objeción obvia es que las llamadas lentas simplemente hacen más trabajo: indicaciones más grandes, respuestas más largas. No lo son. Fije tanto el tamaño de la sugerencia como la longitud de la respuesta y la cola apenas se mueve: dentro de un cubo de un solo tamaño (el trabajo se mantiene fijo), p99 todavía corre de dos a siete veces la mediana (Figura 4). La lentitud no se trata de cuánto tiene que hacer la llamada: en nuestro tráfico es en gran medida transitorio (colas, programación, contención a mitad de camino, un problema con el proveedor), que es exactamente lo que hace que valga la pena interrumpirla.
Un paso lento hunde toda la carrera
Se podría pensar que un flujo de trabajo no cumple con su fecha límite porque muchos de los pasos fueron un poco lentos. Casi nunca sucede así. Cuando una cadena gasta su presupuesto, generalmente es un paso el que se mete en la cola mientras todo lo demás se comporta bien. Matemáticamente, el avance de una cadena está dominado por su peor paso, no por la acumulación de pasos levemente lentos. El total se comporta como su máximo, no como su suma.2
Esas son buenas noticias. No necesitas cada paso rápido. Debes evitar que cualquier paso se escape. Cuál es el límite.
Barra lateral: Las matemáticas, brevemente (salte a menos que le gusten las matemáticas)
Tres resultados se esconden detrás del argumento:
Compuesto. Solo la aritmética de pasos independientes: n pasos, cada uno de los cuales tiene éxito con probabilidad p, da pⁿ de un extremo a otro. En p = 0,95, diez pasos ≈ 60% y veinte ≈ 36%: multiplicación, sin modelado. La misma combinación llega al reloj: cada paso añadido es otro empate independiente contra la cola de latencia (el 2-7× p99/p50 que medimos por llamada), por lo que las probabilidades de que al menos un paso acabe con su presupuesto sólo aumentan con la duración. La independencia es la simplificación (la capacidad compartida se correlaciona con pasos reales), pero es el caso conservador e ilustrativo. El único gran salto. La latencia LLM es de cola pesada (lognormal-ish) y el lognormal es subexponencial. Para pasos subexponenciales independientes, la cola de la suma es solo la suma de las colas: `P(ΣX_i > t) ≈ Σ P(X_i > t) ≈ P(maxᵢ X_i > t)` a medida que t crece. En palabras: una cadena se adelanta porque un paso golpeó su cola, no porque muchos fueran levemente lentos.2 Cobertura y por qué funciona ante cualquier falla. Realice n intentos independientes y tome el primero bueno: si un solo intento falla con probabilidad q, todos los n fallan con probabilidad qⁿ. A esa aritmética no le importa lo que significa "fallar": una fecha límite incumplida, un error grave o una respuesta incorrecta se compran de la misma manera, razón por la cual el mismo movimiento de reintento/carrera/retroceso sirve para todos los gustos. Específicamente para el sabor de tiempo, también reduce la dispersión: dado que las variaciones de los pasos independientes se suman, `Var(ΣX_i) = Σ Var(X_i)`, limitar la cola de cada paso reduce la de toda la cadena. Todo esto se basa en que los intentos sean independientes (nuevos sorteos, nueva cola), que es exactamente por qué un nuevo sorteo paralelo colapsa una cola transitoria (o una mala respuesta desafortunada) y no hace nada por una determinista.3
El movimiento: cortar temprano y luego competir
Si un paso se ha topado con su cola, esperar es lo peor que puede hacer: está gastando su recurso más escaso en la recompensa menos probable. Así que te rindes temprano y vuelves a intentarlo en paralelo: realiza un nuevo intento y toma lo que regrese primero. Un nuevo intento rara vez cae en el mismo bache, por lo que dos de ellos caben dentro del tiempo que una llamada atascada habría consumido, y las probabilidades de que ambos sean lentos son pequeñas (si uno es lento con probabilidad q, dos son ambos lentos con probabilidad q²).3
La mediana apenas se mueve: unos 10 segundos en lugar de 12. La cola hace lo contrario: el percentil 99 cae de aproximadamente 60 segundos a 25, y la diferencia entre carreras se reduce a más de la mitad. Compras previsibilidad por el precio de algunos tokens adicionales.
Ese precio es real y retrocede. Las carreras duplican la factura de tokens en ese paso, y los tokens son un presupuesto limitado y compartido. Por lo tanto, el costo es una verdadera fuerza descendente sobre la libertad con la que vuelves a intentarlo y compites. Pero ejecuta la aritmética y está desequilibrada. Duplicar un paso te cuesta las fichas de ese paso, una vez. Incumplir la fecha límite desecha todo lo que ya pagó, y el cliente casi siempre vuelve a intentarlo, volviendo a ejecutar los N pasos del flujo de trabajo, al menos una vez, a veces más. Cuanto más profundo esté en el flujo, más unilateral será el intercambio: un intento redundante en el paso nueve es barato en comparación con descartar los pasos del uno al nueve y verlos ejecutarse nuevamente. Así que te proteges de todos modos. Simplemente no se protege indiscriminadamente, porque ese presupuesto simbólico compartido afecta con más fuerza exactamente cuando más se quiere gastar (más sobre esa presión en breve).
Un matiz que decide qué recurso recurrir: la dirección tiene que coincidir con el motivo por el que el paso está fallando.
Lento por razones transitorias → volver a dibujar, idealmente en paralelo. Un nuevo intento se escapa del puesto. (Un simple reintento en serie es más débil aquí en un paso más largo; pagaría el tiempo de generación larga dos veces). Lento porque el trabajo es realmente grande → no vuelva a ejecutar la misma llamada. Opte por un modelo más rápido o por un camino alternativo que alcance el mismo resultado de forma más económica. Mal, no lento → caer en un modelo más capaz. La velocidad no solucionará una mala respuesta; capacidad podría. (Este es el mínimo de calidad anterior, aplicado en tiempo de ejecución).
Cortar en la señal correcta
Un tiempo de respuesta consta en realidad de dos fases.4 La espera por el primer token consiste principalmente en hacer cola y programar; la generación que sigue, pieza por pieza, es el resto. La fase que lleva la cola decide en qué pones el límite. Y eso depende de cuánto escribe el paso.
Para los pasos más largos de los que trata este artículo (los que presionan contra una fecha límite), la cola vive en la generación, no en la espera del primer token. Una cola lenta es una pequeña porción de una llamada de cuarenta segundos; el margen que arruina el presupuesto está en las fichas. Por lo tanto, redúzcalos en el tiempo total transcurrido, o en los tokens emitidos hasta ahora, en función del tiempo que le queda, no en el tiempo hasta el primer token. (Para pasos cortos, el equilibrio se invierte: con poco que generar, la espera del primer token es la mayor parte de la llamada, y el tiempo hasta el primer token se convierte en el corte más limpio. Mida sus propios pasos para ver de qué lado está).
Vale la pena cablear dos señales independientemente:
¿No hay ninguna primera ficha después del límite? Eso está atascado, no lento. Ríndete y ponte a cubierto. Se programa un nuevo intento paralelo y casi siempre gana. ¿Las fichas fluyen pero arruinarán el presupuesto? No lo vuelvas a ejecutar. Simplemente regenerarías la misma longitud a la misma velocidad. Caiga a un modelo más rápido.
Y un fallo que ningún reloj puede detectar: un paso que regresa a tiempo pero devuelve basura (por ejemplo, está vacío, truncado o no se puede analizar). Un corte de latencia lo pasa por alto; sólo un control de calidad posterior lo logrará. Para cualquier paso que se supone debe devolver una forma específica, la verificación más barata es una validación estricta inmediatamente después de la llamada. Analice el resultado con el esquema u objeto esperado y trate un error de validación exactamente como cualquier otro: corte y retroceda (vuelva a dibujar o recurra a un modelo más capaz). Detecta una porción significativa de malas respuestas antes de que lleguen al siguiente paso. Recortar temprano le otorga previsibilidad, no corrección. Mantenga esos dos trabajos separados.
El truco: la cobertura gasta el presupuesto con el que tienes menos dinero
Las carreras tienen una propiedad incómoda. La cola es peor cuando el sistema está ocupado. Y "ocupado" es exactamente cuando a su presupuesto de tokens por minuto le queda menos espacio. Entonces, el único movimiento que arregla la cola quiere gastar fichas en el momento preciso en que son más difíciles de conseguir. Hágalo a ciegas y obtendrá una acumulación: las llamadas lentas desencadenan coberturas, las coberturas agregan carga, la carga hace que todo sea más lento, más llamadas cruzan su límite. Un problema de latencia se convierte en un problema de límite de velocidad.
Dos hechos hacen que esto sea menos indulgente de lo que parece a primera vista. El costo se compromete en el instante en que realiza la segunda llamada. Cancelar al perdedor libera su conexión, pero el proveedor sigue generando y facturando el intento abandonado. No hay recuperación, por lo que todo el control tiene que vivir en la decisión de protegerse, no después. Y normalmente no se puede ver cuánto presupuesto queda. Estimarlo es posible pero complicado, por lo que cualquier plan que “se relaje a medida que se llena la cuota” es difícil de ejecutar en la práctica.
Lo que funciona en la práctica es más crudo y estructural:
Envíe la cobertura a algún lugar con su propio presupuesto. Los límites de tokens son por modelo y por proveedor, y la mayoría de nosotros ejecutamos más de uno (como se indica en Cómo está construido nuestro sistema). Al enrutar el reintento a un modelo o proveedor diferente se obtiene una cuota separada y un sorteo independiente. La misma medida que escapa al estancamiento también evita gastar dos veces el escaso presupuesto. Mantenga los setos poco comunes durante la construcción. Esto es lo que los límites precalculados ya le ofrecen: con el umbral establecido en el p95 medido de cada paso, una cobertura se activa sólo en la minoría lenta, por lo que el gasto adicional sigue siendo pequeño sin ninguna contabilidad del tiempo de ejecución. (Los mismos límites que en la siguiente sección, sin maquinaria nueva). Reaccione a las señales que realmente reciba. Probablemente no puedas leer el espacio libre, pero puedes leer 429 y la latencia creciente. Trátelos como una señal para cubrir menos y cortar más tarde, no más. En caso de saturación real, deje de cubrirse. Una vez que el proveedor ya está devolviendo errores de límite de velocidad, más intentos sólo profundizan el agujero. Cambie a un modelo más pequeño y económico o, en su lugar, deshágase del trabajo.
Una palanca que no hemos construido y que ofrecemos sólo como dirección: un límite global explícito que mantiene las llamadas cubiertas en una pequeña fracción del tráfico total, independientemente de las decisiones por paso. Es el respaldo de principios al que apunta el trabajo de cola a escala;3 en su lugar, establecimos límites conservadores y no los hemos necesitado, pero con tasas de cobertura más altas, ahí es donde iríamos a continuación.
Barra lateral: los movimientos baratos que haces primero
Los cortes y las coberturas son seguros. Compra menos si el flujo de trabajo está bien diseñado para empezar. Los valores predeterminados que se activan en cada solicitud, antes de cualquier truco reactivo:
Paralelismo por diseño. Diseñe el flujo como un gráfico de dependencia y ejecute cada paso en el momento en que existan sus entradas. Luego vaya más allá: diseñe las dependencias. Menos dependencias significa que más pasos son hojas, y una hoja puede fallar a bajo costo sin eliminar el resto del gráfico. No llames al modelo en absoluto cuando no sea necesario. La decisión más confiable es la que no toma: use código, búsquedas y validadores siempre que el trabajo no necesite un modelo. Mezcle modelos por paso, no por flujo de trabajo. Rápido y barato donde sea suficiente; capaz donde no lo es. Almacene en caché las partes deterministas. No pague dos veces a un LLM por una respuesta que no puede cambiar.
El punto aquí: gaste su presupuesto de confiabilidad en la estructura primero, para que el reloj tenga menos que arreglar.
¿Cuándo aprietas realmente el gatillo?
El límite es un botón, no una constante. La dificultad con la que lo hagas se reduce a tres preguntas sencillas sobre cada paso:
¿Cuánto necesita la respuesta este paso? Es bueno tenerlo: déjalo ir. Imprescindible: protegerlo. ¿Cuánto está esperando? Si nada depende de ello, déjelo correr hasta la fecha límite. Si la mitad del flujo de trabajo está en cola detrás de él, termínelo antes y asegúrese de que sea correcto, porque una respuesta incorrecta aquí envenena todo lo posterior. ¿Cuanto tiempo queda? Mucho: vuelve a intentarlo con calma. Casi fuera: corta rápido y retrocede.
Cuanto más imprescindible sea un paso, más pesado y corto de tiempo, más temprano activará la copia de seguridad y más gastará para protegerla. Un primer paso opcional y terminal no consigue nada de eso. (“Al principio o al final del flujo” nunca fue el eje real. Fue una aproximación de cuánto depende todavía de este paso).
Y no adivinas el número. Ejecuta el flujo de trabajo muchas veces, mide la curva de latencia de cada paso (P95) y establece el límite de esa curva. Debajo del peor caso del paso, ponderado por las tres preguntas. Un paso que normalmente responde en 20 segundos se corta en 30, aunque podría haber tenido éxito en 60.
¿Por qué casi nadie hace esto?
Esto no es difícil. Tiene matices y la mayoría de los equipos no tienen el motor para ello.
Las populares herramientas de flujo de trabajo, Airflows y Temporals, se crearon para hacer que las canalizaciones sean duraderas: reintentar, reanudar, no perder estado, y son muy buenas en eso. Su consejo de tiempo de espera se deriva de ese objetivo: establezca un tiempo de espera por paso más largo que el de la ejecución más lenta y vuelva a intentarlo hasta que tenga éxito.5 Ese es el instinto correcto cuando el trabajo está por completarse de forma duradera, y es exactamente el consejo equivocado cuando el trabajo debe terminar a tiempo. Su motor de flujo de trabajo volverá a intentar un paso muchas veces; no tiene noción del tiempo típico medido de un paso ni de sus implicaciones posteriores, por lo que no puede cortar temprano y cambiar de modelo. Eso no es un defecto. Es por diseño.
Los fundamentos de los sistemas distribuidos ya están de nuestro lado: trabajar con un presupuesto de fecha límite, hacer coincidir cada tiempo de espera con la latencia medida.6 No estamos contradiciendo eso. Lo estamos aplicando a un caso que esas herramientas no asumen: un presupuesto corto y no reanudable donde el movimiento correcto en el límite es una alternativa más rápida, no volver a hacer la misma llamada. Mismo principio, dirección invertida.
Llevar
Una cosa, si no te quedas con nada más: un tiempo de finalización predecible supera a uno rápido con una cola larga. La baja variación supera a la baja latencia. No se puede prometer a un cliente una mediana, sólo un límite. Todo aquí sirve para ese propósito. Cortar temprano, cubrir, competir, diseñar dependencias: cada uno intercambia un poco de velocidad promedio por mucha menos variación. Renuncias a la cola derecha para comprar la izquierda.
En un flujo de trabajo de agencia de cara al cliente, la confiabilidad es el producto. El oficio no consiste en poseer una bolsa de reintentos y retrocesos, eso es algo que está en juego. Se trata de decidir, por paso, si protegerse y cuándo darse por vencido, a partir de las limitaciones y el comportamiento medido de su propio sistema.
APÉNDICE
Sobre el autor
Frank Wittkampf es jefe de ingeniería de IA aplicada en Databook. Su equipo diseña, construye y opera una pila de IA totalmente personalizada que incluye razonamiento profundo, un motor de flujo de trabajo agente, generación de activos de IA, arneses agentes, base de conocimiento y gráfico de contexto, preprocesamiento de IA, gestión de configuración de IA multiinquilino, etc. Esta infraestructura de IA impulsa los equipos GTM de las principales empresas empresariales como Microsoft, Salesforce, Amazon, Databricks y muchas otras.
Una nota sobre los datos
Las cifras de latencia aquí provienen del tráfico de producción anónimo reciente (junio de 2026) en cargas de trabajo de clientes empresariales: aproximadamente 1,2 millones de llamadas de LLM en un período de 30 días, no puntos de referencia sintéticos ni un seguimiento público. Como se describe en Cómo está construido nuestro sistema, estas son llamadas directas a API administradas de terceros, lo cual es parte del motivo por el cual la cola lenta es en gran medida transitoria. Los números en el texto describen las llamadas más largas (producción ≥ 600 tokens), ya que esas son las que realmente presionan contra una fecha límite; Las llamadas más cortas son más rápidas y menos variables. En todo momento, una “relación de cola” (p99/p50) mantiene el tamaño de la llamada fijo dentro de un segmento a menos que se indique lo contrario. Los modelos están etiquetados únicamente por familia y ruta de publicación; la previsibilidad depende de la ruta de servicio (por ejemplo, una API administrada versus una directa), no solo del modelo, por lo que deliberadamente no son una clasificación de modelos. Las duraciones se agruparon en intervalos de un segundo; un límite estricto de 90 segundos trunca solo el último ~0,2% de las llamadas más largas, por lo que la cola que ves es real, no un artefacto del límite.
¿No son la cola solo las llamadas más grandes?
La objeción justa a la Figura 4: cada fila es un depósito de tokens, no un recuento de tokens fijo, por lo que tal vez las llamadas lentas dentro de una celda sean simplemente las más grandes (más para precompletar, más para generar) y la cola es solo tamaño, no nada transitorio.
No lo es, y la propia forma de los datos muestra por qué. Si el tamaño impulsara la cola dentro de la celda, se seguirían dos cosas: la proporción de la cola crecería con la cantidad de trabajo, y las células más estrechamente delimitadas casi no tendrían cola. Ninguno de los dos se sostiene.
Dos cosas para leer. En primer lugar, la relación de cola es plana, aproximadamente entre 2 y 4 veces en cada columna de tamaño de salida; no aumenta a medida que crece el trabajo, por lo que la cola no escala con el trabajo. En segundo lugar, y de manera decisiva, mire la columna más a la izquierda: esas llamadas emiten como máximo 50 tokens de salida, por lo que el tiempo de generación físicamente no puede variar en más de aproximadamente un segundo; sin embargo, la cola todavía es ~3,5×. No existe una variable de tamaño lo suficientemente grande como para producir eso. La propagación residual es transitoria (colas, programación, un problema momentáneo con el proveedor), que es exactamente de lo que se escapa un nuevo intento.
Por qué estos números parecen más pequeños que el 2–7× citado anteriormente: las cifras de las columnas aquí son promedios ponderados por volumen en muchas celdas, lo que suaviza la dispersión, mientras que el 2–7× en el cuerpo es la envolvente por llamada: el rango que realmente abarcan las celdas individuales. Mismos datos, dos cortes diferentes: los promedios muestran que la cola no escala con el trabajo; el sobre muestra qué tan ancho se vuelve en una llamada determinada.
Notas y notas a pie de página
Nota: Todas las imágenes creadas por el autor.
1: Diez pasos al 95 % cada uno ≈ 60 % de un extremo a otro; veinte ≈ 36% (suponiendo independencia).
2: Lo lognormal se encuentra en la clase subexponencial, donde la cola de una suma de términos independientes es asintóticamente la suma de las colas individuales: `P(S_n > t) ∼ Σ_i P(X_i > t) ∼ P(max_i X_i > t)` como t → ∞ — el principio del “gran salto único” (Foss, Korshunov & Zachary, An Introduction to Distribuciones subexponenciales y de cola pesada, Springer, 2ª ed. 2013, ecuaciones 1.3 y 1.6). Es una declaración asintótica y supone independencia, así que trátela como la intuición de por qué domina un paso lento, no como una fórmula complementaria.
3: Si cada intento independiente es lento con probabilidad q, dos intentos paralelos son ambos lentos con probabilidad q²; n intentos, qⁿ. El resultado clásico de la solicitud cubierta (Dean & Barroso, “The Tail at Scale”, CACM 2013); en un entorno de agente, Winston et al. (arXiv:2605.21470, ICML 2026) elija entre ejecución en serie, paralela y cubierta a partir de curvas de latencia medidas. Según nuestros datos de producción, correr dos intentos redujo p99 en pasos más largos a más de la mitad (≈60s→25s), mientras que el rediseño secuencial en el tiempo total no lo hizo.
4: La división es estándar en el trabajo de inferencia: “tiempo hasta el primer token” (cola + precarga) versus generación por token. Véase, por ejemplo, Agrawal et al., Taming the Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve (arXiv:2403.02310, 2024). En nuestro tráfico de producción, la cola de las llamadas más largas se encuentra en la fase de generación, no en la espera del primer token, razón por la cual reducimos los pasos largos en el tiempo total transcurrido en lugar del tiempo hasta el primer token.
5: Los tiempos de espera de actividad de Temporal están diseñados para finalizar eventualmente, incluidos los reintentos; por lo tanto, Start-To-Close se establece encima de la cola lenta.
6: Google SRE, los plazos de gRPC y Spanner recomiendan propagar un presupuesto total y descartar el trabajo que ya no puede ayudar a la persona que llama. Extendemos el mismo principio a un presupuesto de cliente sincronizado y no reanudable.