Una segunda oportunidad consume recursos reales
Una aplicación pide analizar un documento a IA. La respuesta tarda, el cliente agota plazo y reintenta; también lo hacen servicio intermedio y biblioteca. ¿Cuántas ejecuciones llegan al componente caro? ¿Una espera aleatoria resuelve el problema? Tres experimentos verificables separan fiabilidad teórica, multiplicación y distribución temporal. Identificamos garantías y verificaciones pendientes en servicio real.
Resumen. Para fallos independientes de probabilidad q y máximo N intentos totales derivamos coste esperado y éxito. Sin independencia, tres niveles que agotan tres intentos producen 27 llamadas finales por petición. Presupuesto de 20 reintentos para 100 solicitudes limita intentos a 120 sin recarga. Cien clientes con semilla declarada reparten una oleada en 100 milisegundos: pico por intervalos de 10 baja de 100 a 14, total permanece 100. Son conteos ejecutados, no benchmarks de servidor o EL-AI.
Contar primero: intento no es reintento
Intento es llamada efectiva; reintento es posterior al primero. N=3 significa uno inicial y hasta dos reintentos. Solicitud original es objetivo del usuario y puede generar varias llamadas. Así evitamos errores entre niveles. Coste significa conteo, no dinero, tokens ni segundos GPU, sin suponer facturación.
La guía técnica AWS de Marc Brooker de 2019 distingue plazos, esperas crecientes, aleatorización y límites, incluida amplificación entre niveles. Documenta experiencia operativa, no experimento reproducido aquí en AWS. Nuestros modelos aíslan efectos con hipótesis explícitas sin universalizar ajustes de SDK. Comportamiento depende de errores, cancelación y recursos.
Caso favorable: fallos independientes
Supongamos fallos independientes con probabilidad constante q y parada al tener éxito. Llegar al segundo exige fallo primero, probabilidad q; al tercero dos fallos, q². El número esperado suma probabilidades de alcanzar cada intento porque cada uno aporta unidad solo al realizarse. Esa es la pregunta de la fórmula.
A es conteo sin unidades, N máximo total y q entre 0 y 1. Con q=.5,N=3:1+.5+.25=1.75 intentos esperados y éxito.875. No son 1.75 llamadas reales de una solicitud, sino media teórica. Con q=.9:2.71 intentos y éxito.271. Más intentos ante fallo casi seguro compran poco éxito y mucha carga. Si reintentos modifican q por carga, fórmulas dejan de describir sistema; no predicen una caída real.
| q | N | Intentos esperados | Probabilidad de éxito |
|---|---|---|---|
| 0.1 | 3 | 1.11 | 0.999 |
| 0.5 | 3 | 1.75 | 0.875 |
| 0.9 | 3 | 2.71 | 0.271 |
Tres niveles: cuando tres se convierte en veintisiete
Ahora caso determinista: todas llamadas finales fallan; cada nivel conoce fallo cuando el inferior agota intentos, sin cancelación. Exterior prueba tres veces, cada una invoca tres intermedias y cada intermedia tres finales:3 × 3 × 3=27. La función recursiva enumera árbol sin fallos aleatorios ni q del modelo anterior.
D cuenta niveles que reintentan, no todos pasos software. Un solo nivel reintentando da 3. No prueba optimalidad de hacerlo siempre arriba: repetir flujo entero rehace trabajo ya exitoso; reintento local puede recuperar paso barato. La política debe considerar recorrido entero. Trabajo persistente tras timeout puede solaparse y no se mide en árbol secuencial.
Presupuesto limita cantidad, no promete éxito
Tomamos 100 solicitudes iniciales, máximo 3 intentos cada una y 20 tokens compartidos solo para reintentos. Sin recarga; consumo atómico por retry; primeros intentos no consumen. Máximo 100+min(20,100 × 2)=120, frente 300 si todo falla sin presupuesto. Código ejecuta 100 fallos iniciales y 20 segundas llamadas fallidas;80 solicitudes no reciben primer reintento y ninguna tercero.
El límite 120 es propiedad de admisión, no capacidad del servidor; todo puede fallar. Diez contadores locales de 20 admiten hasta 200 reintentos, no 20 globales. Sistemas reales deben definir alcance, recarga, concurrencia y fallo del contador. Modelo sin recarga no simula token bucket completo. El orden tampoco garantiza equidad: límites de carga y prioridades son problemas distintos.
Jitter: repartir multitud sin reducirla
En experimento 3 cien clientes hacen exactamente un retry. Espera fija 100 ms sincroniza; full jitter sortea uniformemente entre 0 y 100 ms. Python 3.14.0 random.Random usa semilla 20261017 y guarda retrasos. Conteos por 10 ms:9,7,9,12,14,14,7,11,6,11; pico 14. Espera fija concentra 100 llegadas en intervalo que empieza 100 ms. Ambas suman 100 reintentos.
La fórmula extiende a oleadas: k empieza 0 en primer retry; B₀ y techo B_max en milisegundos. Ejecutamos solo una oleada B₀=100, no recuperación exponencial. Media uniforme 50 ms, no 100: comparar picos oculta diferencia de espera. No simulamos cola, servicio, fallos por carga ni latencia del modelo. Catorce llegadas no son catorce ejecuciones simultáneas ni mejora garantizada del percentil 99.
El plazo pertenece a la tarea entera
Timeout por llamada no es plazo de tarea. Tres intentos de hasta 200 ms con esperas 50 y 100 suman 750 ms peor caso, sin otros costes. Plazo 600 deja 50 tras dos fallos y ambas esperas que consumen 550. Tercer intento debe ajustarse o rechazarse. Es límite del modelo, no latencia medida. Temporizador que excluye DNS, conexión o cuerpo no es automáticamente tiempo integral.
Cancelación importa: dejar de esperar no prueba que GPU haya dejado de generar; retry duplica trabajo activo. En mutaciones o acciones, timeout tampoco prueba ausencia de efecto. Corrección requiere idempotencia o reconciliación, no implementadas aquí. Limitar protege recursos pero no vuelve segura mutación duplicada; esperar tampoco repara credenciales o esquema.
Una semilla no es garantía: probabilidad de pico
El 14 observado pertenece a secuencia guardada, no es máximo garantizado. ¿Qué probabilidad ideal hay de al menos 25 llegadas en cualquier intervalo? Cada cliente elige independientemente uno con probabilidad.1. Conteo X de un intervalo es binomial de 100 pruebas y probabilidad.1. Los diez conteos no se suponen independientes: suman 100. Así evitamos multiplicar probabilidades injustificadamente.
Coeficiente binomial cuenta qué j clientes eligen intervalo; factores siguientes dan probabilidades de entrar y no entrar. Suma 25…100 da.0000130728 para uno. Cota de unión suma diez riesgos: máximo.000130728, alrededor.0131%, de alcanzar 25 en cualquiera. No es probabilidad de caída: capacidad desconocida. Requiere sorteos uniformes independientes y ventanas fijadas; secuencias compartidas, temporizadores gruesos o más retries cambian modelo.
Hay tres niveles de evidencia: pico 14 es observación reproducible; media 10 y cota proceden de hipótesis de distribución; evitar sobrecarga real sigue siendo empírico porque tiempos y recursos no se modelan. Distinguir evita convertir simulación ordenada en promesa. Ancho de intervalo cambia pico: comparaciones deben conservar definición de métrica.
Qué falta verificar en servicio real
Experimentos separados: no conectamos q independiente a cola ni convertimos pico 14 en éxito. Comparación operativa requiere llegadas originales, duración, costes, cancelación, errores y políticas reales. Test futuro distinguiría solicitudes completadas de intentos, trabajo útil de duplicado, media de percentiles y recuperación de sobrecarga. Son requisitos propuestos, no resultados EL-AI o proveedor.
Reintentar ayuda si recuperación es plausible y coste cabe en recursos y plazo. Jitter reparte llegadas, presupuesto limita cantidad y coordinación evita multiplicación inadvertida; no se sustituyen. Conteos controlados sostienen separación. Menos picos puede seguir implicando trabajo excesivo; con presupuesto puede no completarse ninguna solicitud.
from experiment import expected, nested
print(expected(.5,3), nested(3,3))Código, datos e instrucciones · JSON. Cálculos didácticos ejecutados con Python 3.14.0; figuras con Matplotlib 3.11.2. Análisis asistido por IA, sin afirmar revisión por pares ni humana. Portada original ImageGen ilustrativa: no documenta personas, sedes ni instalaciones de EL-AI. Fuentes consultadas el 17 de octubre de 2026.