El promedio que nunca pasó
Corrimos YOLO26n setenta y dos minutos sin parar en una Raspberry Pi 5: media hora con un proceso que usa los cuatro núcleos, diez minutos de enfriamiento y media hora con cuatro procesos a la vez, de un núcleo cada uno. Si se juntan las 25,898 inferencias y se saca el promedio, da 347 ms. Ninguna inferencia tardó eso. Ninguna tardó siquiera entre 268 y 397 ms: el promedio cae en un hueco vacío. Describe algo que nunca pasó.
Durante mucho tiempo nos acostumbramos a preguntar cuánto tarda un sistema en responder. De eso trata esta nota: por qué esa pregunta, contestada con un solo número, no alcanza.
Las cifras de esta nota no son ilustrativas: salen de las corridas sostenidas que publicamos con licencia CC BY 4.0, y cualquiera puede recalcularlas.
Importa por razones distintas
En los sistemas que hemos construido, la latencia importa de maneras diferentes. En una recarga electrónica hay una transacción financiera y un cliente esperando: una respuesta tardía genera incertidumbre, porque no siempre sabes de inmediato si la operación se rechazó, se procesó o simplemente no respondió a tiempo. En telemetría GPS, la información tiene que llegar a tiempo para que las alertas tengan valor operativo. En analítica de video, si procesar tarda más de lo que permite el flujo de imágenes, se acumulan cuadros o se pierden oportunidades de detección.
Históricamente, buena parte del seguimiento se ha centrado en encontrar transacciones lentas, errores y timeouts. Hoy me parece insuficiente reportar sólo un promedio. Me interesa la distribución completa, sobre todo el p95, el p99 y los extremos.
Cada condición por separado
El p50, o mediana, es el tiempo debajo del cual queda la mitad de las mediciones; el p95, el 95 %; el p99, el 99 %. En milisegundos:
| Equipo y condición | Media | p50 | p95 | p99 | Máximo |
|---|---|---|---|---|---|
| Pi 5, un proceso | 130.2 | 129.7 | 135.2 | 137.7 | 267.9 |
| Pi 5, cuatro procesos | 595.6 | 595.4 | 608.3 | 615.4 | 702.3 |
| Pi 5, mezcladas | 347.4 | 134.7 | 605.3 | 611.8 | 702.3 |
| N100, un proceso | 56.7 | 56.2 | 57.5 | 63.6 | 159.5 |
| N100, cuatro procesos | 218.3 | 217.9 | 224.5 | 231.4 | 297.7 |
| N100, mezcladas | 139.0 | 209.1 | 223.1 | 227.3 | 297.7 |
Con un proceso, la mediana de la Pi se mantuvo entre 128 y 131 ms; con cuatro, entre 593 y 597. Las dos condiciones ocupan el procesador entero; lo que cambia es cómo se reparte. Son dos comportamientos distintos, y cada uno, por su lado, bastante predecible. Mezclados, el promedio cae entre los dos, donde no hay nada. La mediana mezclada tampoco describe la fase con cuatro procesos: depende de cuál de las dos fases tuvo más inferencias.
En el N100 pasa al revés: el promedio mezclado, 139 ms, queda debajo de la mediana, 209. El promedio puede engañar hacia los dos lados.
No tengo documentado un incidente de producción en el que un promedio bueno haya ocultado una falla. No hace falta inventarlo: aquí está, medido, cómo una métrica agregada borra la diferencia entre dos condiciones de operación.
La cola dentro de una misma condición
Separar las fases no termina el trabajo. Con un proceso, la Pi tuvo un p99 de 137.7 ms, pero su máximo fue 267.9: casi el doble. Sólo 51 de 13,813 inferencias pasaron de 150 ms. En el N100, el p99 fue 63.6 ms y el máximo, 159.5.
Luego está la primera inferencia. En la Round 1 descartamos veinte inferencias de calentamiento; en la prueba sostenida registramos todas desde la primera, sin descartar ninguna. Se nota: la primera tardó 148 ms en la Pi, contra unos 125 de las siguientes, y 155 en el N100, contra unos 56. Conservarla permite ver el arranque y su diferencia con el régimen estable. Pero son dos metodologías distintas, y no se deben presentar como si fueran la misma.
Latencia no es capacidad
Con cuatro procesos, cada inferencia de la Pi tardó 4.6 veces más, porque corre en un núcleo en vez de cuatro. El equipo, sin embargo, pasó de 7.7 a 6.7 inferencias por segundo, porque corrían cuatro a la vez. En el N100, cada inferencia tardó 3.9 veces más y la capacidad subió de 17.6 a 18.3 por segundo.
Si sólo miras la latencia, cuatro procesos parecen un desastre. Si sólo miras la capacidad, cuestan poco: 13 % menos en la Pi y 4 % más en el N100. Son dos preguntas distintas, y una arquitectura necesita las dos respuestas.
Lo que una prueba corta no ve
La tercera dimensión es el tiempo. En la Pi con un proceso, la mediana de cada ventana de cinco minutos subió de 128 a 131 ms mientras la temperatura máxima de cada ventana pasaba de 77 a 85 °C. En el N100 con cuatro procesos, de 213 a 222 ms, con máximas de 92 a 102 °C. Lo que hizo el reloj del procesador mientras tanto está en la nota del freno.
Una prueba corta se equivoca hacia los dos lados. Las primeras 100 inferencias de la Pi con cuatro procesos dan una mediana de 577 ms; la corrida entera, 595. Las primeras 100 con un proceso dan un p99 de 148.5 ms, contra 137.7 de la corrida entera: al arranque hubo varias inferencias lentas, la primera entre ellas, y con 100 mediciones el p99 descansa en una o dos.
Una arquitectura no debe evaluarse sólo por su mejor resultado, sino por el comportamiento que puede sostener.
¿Cuánto confiar en un p99?
Con 100 mediciones, arriba del p99 queda una sola: el p99 depende de una medición. Sin suponer nada sobre la forma de la distribución, y con 95 % de confianza, con 100 muestras se le puede poner piso al p99, pero no techo; para eso hacen falta al menos 368. Con las 13,813 de la Pi con un proceso, el p99 quedaría entre 137.4 y 137.9 ms, si las mediciones fueran independientes y de las mismas condiciones. No lo son del todo: el p99 de cada ventana de cinco minutos fue de 135.0 a 138.3, más que todo ese intervalo.
Pero el tamaño de la muestra no sustituye la representatividad. Diez mil mediciones con el equipo frío, sin otra carga y durante cinco minutos dicen mucho de esas condiciones y poco de las de la operación.
El timeout que mejora el p99
Hay una decisión aparentemente pequeña que cambia la interpretación: qué hacer con las operaciones que pasan del timeout. Si una operación termina por timeout, su latencia real es desconocida. No se le puede asignar el valor del timeout para calcular percentiles: es una observación censurada, y cuenta como incumplimiento.
Toma la Pi con cuatro procesos, un objetivo de 600 ms y un timeout de 605. No terminarían 1,407 de 12,085 inferencias, el 11.6 %. Contándolas como incumplimiento, el cumplimiento real del objetivo es 69.6 %, y el p95 y el p99 no tienen valor: sólo se sabe que pasan de 605 ms. Si se descartan, la muestra se queda con las que sí terminaron: el cumplimiento sube a 78.7 % y el p99 sale en 604.7 ms, debajo del timeout por construcción.
Con las fases mezcladas y un timeout de 300 ms es peor. No termina el 46.7 %, y descartándolas, el p99 queda en 137.7 ms y el cumplimiento de un objetivo de 150 ms, en 99.6 %. Contándolas, ese cumplimiento es 53.1 %. Descartar los timeouts hace que la fase con cuatro procesos desaparezca de la medición.
Inferencia no es el sistema
Todo lo anterior es latencia de inferencia, con entrada aleatoria. Un sistema de video tiene captura, preproceso, inferencia, posproceso y la generación del evento. Una cámara a 30 cuadros por segundo produce uno cada 33.3 ms. Eso no obliga a inferir cada cuadro, pero sí a definir qué frecuencia exige la aplicación: para detectar un vehículo o una persona puede bastar una selección de cuadros, según la velocidad del movimiento y el objetivo. Lo que no se puede es dejar que los cuadros se acumulen sin límite.
Estas pruebas miden la inferencia en condiciones controladas. No son evidencia de placas o cuadros perdidos en producción: para eso hay que medir la cadena completa.
Lo que haría hoy
Separar las condiciones. No mezclar las mediciones del equipo en una condición con las del mismo equipo en otra, como un proceso y cuatro procesos, ni la latencia de inferencia con la del sistema completo.
Pedir la distribución, no un número. A un proveedor le pediría, como mínimo, p50, p95, p99, máximo observado y el porcentaje de operaciones que excede el tiempo objetivo. Y las condiciones de la medición: solicitudes simultáneas, duración de la prueba, hardware y volumen de operaciones.
Escribir el objetivo con percentil y ventana. En un contrato, un objetivo de latencia ligado a un percentil y a una ventana de evaluación, con requisitos aparte de disponibilidad y tasa de errores. Por ejemplo, que el 99 % de las operaciones cumpla cierto tiempo, contando los errores y los timeouts como incumplimientos para que no desaparezcan de la medición. El umbral depende de la aplicación: no usaría el mismo para una recarga, una API administrativa y una detección en tiempo real.
No confundir el timeout con el tiempo de respuesta. En integraciones de recargas hemos configurado timeouts de hasta 60 segundos. Eso no dice cuánto tarda normalmente una recarga, ni es necesariamente un compromiso contractual.
Medir tres cosas a la vez. Latencia: cuánto tarda cada operación y cómo se distribuyen sus tiempos. Capacidad: cuántas operaciones completa el sistema por segundo bajo distintas cargas. Estabilidad: cómo evolucionan las dos después de operar de forma continua, con temperatura, frecuencia del procesador y freno.
Guardar cada medición. En edge AI conservamos cada inferencia y la telemetría del equipo. Eso permite reconstruir el comportamiento de una corrida y recalcular cualquier percentil, en vez de depender de un resumen.
Para verlo con estos datos o con los tuyos está la herramienta de latencias: abre las 90,604 inferencias fase por fase, dice cuánto confiar en cada percentil y compara contar y descartar los timeouts. Corre en el navegador, y si abres tu CSV, no se envía a ningún lado.
Durante mucho tiempo nos acostumbramos a preguntar cuánto tarda un sistema en responder. Hoy me parece más importante preguntar cuánto tarda bajo distintas condiciones, qué tan predecible es ese tiempo y durante cuánto tiempo puede sostenerlo. Porque una latencia promedio aceptable no significa necesariamente que tengamos un sistema capaz de responder a tiempo cuando de verdad lo necesitamos.
Los datos completos, cada inferencia con su tiempo, están en crtdrops.mx/datos, bajo licencia CC BY 4.0.
Israel Negrete Lepe es ingeniero en electrónica. Veinticinco años haciendo que sistemas distintos funcionen juntos en condiciones reales: del sensor, el vehículo o la transacción al backend, los datos, la seguridad y la operación. Hoy, cada vez más, IA en el borde.