Cada stack de production serving que comprime estado bajo carga está gastando calidad que no puede contabilizar. Un artículo publicado el 16 de agosto por Fanzhe Wei y Li Liu (arXiv 2608.15810) cuantifica la brecha de contabilidad, propone un reemplazo y lo valida contra 352.333 llamadas de admisión en vivo.
El modo de fallo es específico. Los controladores de admisión certificados existentes presupuestan riesgo a nivel de solicitud utilizando un union bound sobre un recuento de eventos pre-declarado. En solicitudes largas en producción, el presupuesto de union se agota en el 100% del tráfego. Cada solicitud larga supera el bound. El sistema degrada automáticamente la exactitud en señales de carga mientras que el ledger de riesgo declara quiebra en la primera llamada larga de la sesión. Los ingenieros saben que la calidad está disminuyendo pero no tienen forma de cuantificarlo correctamente.
El reemplazo es un ledger anytime-valid: un bound contabilizado físicamente que se mantiene en cada decisión de admisión, no solo en expectativa sobre un horizonte pre-contado. En la ronda de confirmación reservada, cambiar al nuevo ledger reduce a la mitad la tasa de exact-fallback con riesgo igualado — 0.30 cae a 0.14. Fallback rate es la fracción de solicitudes que el sistema debe enrutar a la ruta exacta porque no puede certificar que la ruta comprimida cumple con el objetivo de calidad. Reducir a la mitad el fallback significa menos llamadas costosas con la misma tolerancia de riesgo.
La certificación en admisión es un tercio del problema. El artículo luego cuantifica la brecha entre lo que el testigo certificado garantiza y lo que recibe el usuario. Una ley de diseño verificada por máquina, TV ≤ tanh(a_q · w_thr), convierte el objetivo de total-variation servido directamente en una perilla de threshold — un número que un operador puede leer y establecer. Una auditoría de tres capas rastrea la holgura: la envoltura de query operator-norm está 1.5× de tight; un reemplazo de ellipsoid medido para la bola de Cauchy-Schwarz recupera 0.89× (held-out sound, significando que aprieta el bound en producción); el punto operacional de la puerta contribuye la mayor parte de la holgura restante en aproximadamente 700×. La brecha completa de 1064× entre el bound certificado y el comportamiento observado ahora está localizada y enunciada explícitamente en lugar de dejarse desconocida.
El tercer componente aborda extrapolación: un bound certificado en una solicitud que ha visto vale poco sin garantías en la siguiente. El artículo reemplaza la binary conformal prediction — que emite certificados vacuos — con extrapolación exchangeable a través de 80 serving histories, produciendo order-statistic bounds que discriminan en riesgo de calibración 0.41 versus 0.51 para la línea base conformal. Todos los kernels probabilísticos se verifican formalmente en Lean 4: 228 teoremas exportados, cero axiomas `sorry`.
Una decisión arquitectónica enterrada en el resumen es importante: el paper companion rechaza certificar el routing como la alternativa natural. Los equipos de serving que persiguen certified routing para resolver la contabilidad de calidad están resolviendo el problema incorrecto. El artículo argumenta que la admisión es donde la garantía debe residir, no en routing.
Para arquitectos que manejan trade-offs de SLA: si su stack degrada automáticamente la exactitud bajo carga y utiliza un union bound para contabilidad de riesgo, ese bound se agota en cada solicitud larga en su cola. El framework de ledger anytime-valid te da un número que realmente puedes gastar — una fallback rate que puedes intercambiar contra tolerancia de riesgo, una brecha que puedes leer de una sola ley, y un bound que se mantiene en tráfico no visto.