Model Serving

El servicio de modelos consiste en alojar un modelo de aprendizaje automático entrenado tras un endpoint de red, normalmente HTTP o gRPC, para que las aplicaciones puedan enviar entradas y recibir predicciones. Un sistema de servicio carga los pesos una vez, los mantiene en memoria en CPU o GPU, acepta muchas solicitudes simultáneas, las agrupa en lotes, añade o elimina réplicas según cambie el tráfico, sustituye versiones del modelo e informa de su estado. Google publicó TensorFlow Serving como código abierto en febrero de 2016 para ejecutar modelos de TensorFlow en producción; hoy, el servicio de modelos es la parte de ejecución de las operaciones de aprendizaje automático (MLOps), entre el empaquetado del modelo y la monitorización de sus predicciones.

Cómo gestiona las solicitudes un sistema de servicio#

Cada solicitud pasa por la validación, el preprocesamiento —por ejemplo, la descodificación y el redimensionamiento de una imagen—, una cola, el propio modelo y el posprocesamiento para generar una respuesta en un formato como JSON. La mayoría de las decisiones sobre el servicio se toman en la cola. El procesamiento dinámico por lotes retiene las solicitudes durante unos milisegundos para que el acelerador procese varias entradas en una sola pasada hacia delante, lo que aumenta el rendimiento con un pequeño coste en latencia de inferencia. Cuando la cola está llena, el servidor rechaza las nuevas solicitudes con HTTP 429 para que los clientes reduzcan la frecuencia de envío.

Los equipos de servicio registran percentiles de latencia como p95 y p99, el rendimiento en solicitudes por segundo, la utilización del acelerador, la tasa de errores y el tiempo de arranque en frío, es decir, el retraso antes de que una réplica escalada desde cero pueda responder. Las versiones se despliegan gradualmente: una versión canario envía una pequeña parte del tráfico al nuevo modelo, y un despliegue en sombra le envía copias de las solicitudes reales sin devolver sus respuestas.

Esta aplicación de FastAPI carga YOLO26 una vez al iniciarse y devuelve las detecciones como JSON. TestClient de FastAPI envía una solicitud a través de toda la pila HTTP en el mismo proceso, así que el ejemplo se ejecuta sin iniciar un servidor:

from fastapi import FastAPI
from fastapi.testclient import TestClient
from ultralytics import YOLO

app = FastAPI()
model = YOLO("yolo26n.pt")  # carga los pesos una vez, cuando se inicia el servidor


@app.get("/predict")
async def predict(url: str):
    """Detect objects in the image at `url` and return them as JSON."""
    results = model(url)
    return results[0].summary()


client = TestClient(app)
response = client.get("/predict", params={"url": "https://ultralytics.com/images/bus.jpg"})
print(response.status_code, response.json()[0])

El resultado muestra el estado 200 y la primera detección como un diccionario con el nombre de su clase, el nivel de confianza y las coordenadas de la caja, la estructura que summary() genera para cada objeto detectado. Como el controlador es async def, FastAPI lo ejecuta en un único bucle de eventos, así que el modelo compartido nunca gestiona dos solicitudes a la vez. Los servidores que necesitan paralelismo ejecutan varios procesos de trabajo, cada uno con su propia copia del modelo.

Patrones de servicio y software#

La forma de servir un modelo depende de cuándo se necesitan sus respuestas: desde la inferencia en tiempo real sobre flujos de cámara hasta los trabajos nocturnos:

• Servicio en línea: Cada solicitud recibe una respuesta mientras quien la envía espera, a través de REST o gRPC, como ocurre en las aplicaciones para usuarios y los flujos de cámara en directo.
• Servicio por lotes: Un trabajo programado puntúa un conjunto de datos grande sin conexión —por ejemplo, imágenes de todo un día durante la noche— y prioriza el rendimiento frente a la latencia.
• Flujo continuo: Los resultados se envían de forma continua a medida que llegan fotogramas de vídeo o lecturas de sensores.
• IA perimetral: El modelo se ejecuta en el propio dispositivo, a menudo tras exportarse a un formato optimizado, sin necesidad de enviar datos de ida y vuelta por la red.

Entre los programas de servicio de propósito general se encuentran NVIDIA Dynamo-Triton, anteriormente Triton Inference Server, además de TensorFlow Serving, Ray Serve, BentoML y KServe en Kubernetes. TorchServe de PyTorch está en mantenimiento limitado y no se prevén nuevas actualizaciones. Los servidores de LLM, como vLLM, SGLang y TensorRT-LLM, incorporan procesamiento continuo por lotes y gestión paginada de la caché KV para generar tokens uno a uno. La mayoría de estos sistemas se ejecutan en contenedores, de modo que el modelo, el entorno de ejecución y las dependencias se distribuyen como una sola imagen.

Servicio de modelos, implementación y motores de inferencia#

El servicio de modelos está estrechamente relacionado con varios términos. La implementación de modelos es el proceso más amplio de poner un modelo en producción e incluye el empaquetado, la infraestructura y el despliegue; el servicio es la parte que responde a las solicitudes una vez que el modelo está activo. Un motor de inferencia, como TensorRT, ONNX Runtime u OpenVINO, ejecuta los cálculos del modelo, y un sistema de servicio envuelve uno o varios motores con funciones de red, gestión de colas y escalado.

Ultralytics Platform sirve modelos YOLO mediante endpoints específicos, cada uno de los cuales es un servicio de un solo inquilino en una de 42 regiones, con rutas /predict, /health y /docs generadas automáticamente. El tamaño predeterminado se reduce a cero cuando está inactivo y puede tardar alrededor de un minuto en iniciarse; al sustituir el modelo, la URL del endpoint se mantiene y el modelo anterior sigue prestando servicio hasta que el nuevo está listo.