Real-time Inference
La inferencia en tiempo real devuelve cada predicción antes de que llegue la siguiente entrada, por ejemplo, en menos de 33 ms por fotograma a 30 FPS. Incluye presupuestos de latencia y mejoras de velocidad.
La inferencia en tiempo real consiste en ejecutar un modelo entrenado con datos de entrada en directo y devolver cada predicción antes de que llegue la siguiente, para que el sistema pueda actuar mientras la información sigue siendo actual. Para una cámara que transmite a 30 fotogramas por segundo (FPS), hay 33.3 milisegundos por fotograma para todo el proceso, desde leer la imagen hasta producir el resultado final; a 60 FPS, el presupuesto se reduce a 16.7 ms. Cada aplicación tiene su propio plazo: un sistema de percepción de un coche, una cámara de inspección en una cinta transportadora y un filtro de fondo para videollamadas funcionan en tiempo real con presupuestos distintos.
El presupuesto de latencia#
El tiempo que realmente importa es la latencia de inferencia de extremo a extremo: capturar el fotograma, preprocesarlo redimensionándolo y normalizándolo, ejecutar la pasada hacia delante del modelo y aplicar el posprocesamiento, como la decodificación de cajas y la supresión no máxima (NMS). Cuando el tiempo total supera el intervalo entre fotogramas, los fotogramas sin procesar se acumulan y la salida se retrasa cada vez más respecto a la escena en directo, por eso los sistemas de procesamiento en directo suelen descartar los fotogramas obsoletos y trabajar siempre con el más reciente. La computación en tiempo real distingue entre los sistemas de tiempo real estricto, en los que incumplir un plazo supone un fallo, como ocurre en un controlador de airbag, y los sistemas de tiempo real flexible, que toleran algún incumplimiento puntual. La mayoría de las aplicaciones de visión artificial son de tiempo real flexible: un fotograma descartado reduce la calidad de la salida durante un instante y el siguiente la recupera.
Este fragmento procesa un vídeo grabado en streaming con un detector pequeño y compara el tiempo medio por fotograma con el presupuesto de 30 FPS:
from ultralytics import YOLO
model = YOLO("yolo26n.pt")
video = "https://github.com/ultralytics/assets/releases/download/v0.0.0/decelera_portrait_min.mov"
# stream=True yields each frame's result as soon as it is ready
frame_times = []
for result in model(video, stream=True):
# Preprocess, inference, and postprocess time for this frame, in milliseconds
frame_times.append(sum(result.speed.values()))
mean_ms = sum(frame_times) / len(frame_times)
print(f"{mean_ms:.1f} ms per frame ({1000 / mean_ms:.0f} FPS); a 30 FPS camera allows 33.3 ms")Una media inferior a 33.3 ms significa que el modelo puede seguir el ritmo de una cámara de 30 FPS en el hardware donde se ha ejecutado.
Inferencia en tiempo real frente a inferencia por lotes#
- Inferencia en tiempo real (en línea): Procesa cada entrada a medida que llega, normalmente una imagen cada vez, y se evalúa por la latencia de cada predicción. La asistencia a la conducción, el control de robots y el análisis de vídeo en directo dependen de ella.
- Inferencia por lotes (fuera de línea): Recopila muchas entradas y las procesa juntas; se evalúa por el rendimiento en entradas por segundo y por el coste. Reindexar de noche un archivo fotográfico o analizar las grabaciones del mes pasado son tareas por lotes, y los lotes más grandes mantienen la GPU más ocupada, aunque cada entrada tarde más en obtener su resultado.
Los servidores que gestionan muchas transmisiones de cámaras suelen situarse entre ambos enfoques: agrupan fotogramas de distintas cámaras en lotes pequeños para aumentar el rendimiento sin superar el presupuesto de fotogramas de cada transmisión.
Aplicaciones en el mundo real#
- Vehículos autónomos: A 100 km/h, un coche recorre 2.8 metros cada 100 ms, por lo que la latencia de percepción se suma directamente a la distancia de frenado.
- Inspección industrial: Las cámaras situadas sobre una cinta transportadora detectan defectos en cada pieza y deben activar el mecanismo de rechazo antes de que la pieza defectuosa lo rebase.
- Robótica: La detección de obstáculos y la estimación de pose se ejecutan dentro del bucle de control de un robot, y una percepción más lenta obliga a moverse más despacio.
- Efectos de vídeo y realidad aumentada: El desenfoque del fondo en las videollamadas y las superposiciones de realidad aumentada ejecutan segmentación o seguimiento en cada fotograma; cualquier retraso hace que la superposición quede por detrás de la persona en movimiento.
Cómo conseguir que un modelo sea lo bastante rápido#
- Modelo o tamaño de entrada más pequeños: Una variante más pequeña del modelo ejecuta menos operaciones por imagen y, como el cálculo de convoluciones crece aproximadamente con el número de píxeles, reducir a la mitad la anchura y la altura de la entrada lo reduce a aproximadamente una cuarta parte, a costa de cierta exactitud en objetos pequeños.
- Cuantización del modelo: Almacenar los pesos y las activaciones en FP16 o INT8 en lugar de FP32 reduce el tráfico de memoria y aprovecha unidades aritméticas más rápidas. INT8 suele necesitar un conjunto de imágenes de calibración para limitar la pérdida de exactitud.
- Motores de inferencia: Un entorno de ejecución diseñado para una familia de hardware fusiona capas y selecciona kernels optimizados para el dispositivo, como TensorRT para GPU NVIDIA o Core ML para dispositivos Apple.
- IA en el borde: Ejecutar el modelo en la cámara o en un módulo integrado evita el viaje de ida y vuelta a la nube, que con una conexión lenta puede superar todo el presupuesto de fotogramas.
El entorno de ejecución y el hardware pueden cambiar la latencia en más de un orden de magnitud: el modelo nano YOLO26 tarda 38,9 ms por imagen de 640 píxeles en una CPU con ONNX y 1,7 ms en una GPU NVIDIA T4 con TensorRT. El modo de exportación de Ultralytics convierte un modelo YOLO26 entrenado a TensorRT, OpenVINO, LiteRT y otros formatos, y su argumento quantize=16 o quantize=8 genera pesos FP16 o INT8 para el dispositivo de destino.










