Servir modelos
Lote frente a en línea
- Por lotes: se predicen muchos casos de una vez, con retardo alto.
- En línea: una petición, una respuesta inmediata vía API.
- Elegir depende de si el consumidor espera al instante.
El endpoint de inferencia
Se expone una API (típicamente REST o gRPC) que recibe datos, invoca el modelo y devuelve la predicción. Es la fachada del modelo ante el mundo.
Empaquetar el modelo
El artefacto se serializa en un formato portable (ONNX, TorchScript u otro) y se mete en un contenedor con sus dependencias, para que corra igual en cualquier lado.
Latencia y rendimiento
- El tiempo por predicción importa para la experiencia de usuario.
- Optimizar: agrupar peticiones, cuantizar, usar GPU o lotes dinámicos.
- Latencia y coste van de la mano.
Escalado
La demanda fluctúa. Escalar horizontalmente añade réplicas; el autoescalado ajusta según carga, y las colas amortiguan picos sin reventar.
Versionado del servicio
- Servir varias versiones a la vez permite pruebas controladas.
- Publicación azul-verde o canario cambia el modelo sin caídas.
- Cada predicción debe poder trazarse a su versión.
Gestión de recursos
Los modelos son ávidos de memoria y GPU. Asignar recursos, reutilizar cargas y apagar réplicas ociosas controla el coste.
Validación de entrada
El servicio debe revisar que la entrada tenga el formato y rango esperados. Un dato malformado no debe tumbarlo, sino devolver un error claro.
Observabilidad
- Registrar peticiones, retardo y tasa de error.
- Monitorizar la salud del modelo en producción.
- Sin métricas, un fallo silencioso pasa desapercibido.
Caída degradada
Cuando el modelo falla o se satura, tener una respuesta de reserva (un modelo simple, una regla, una caché) evita un corte total.
Seguridad del endpoint
Un modelo expuesto es un blanco. Autenticar peticiones, limitar tasa y aislar el entorno protegen frente a abuso o extracción del modelo.
Errores frecuentes
- Publicar el modelo sin validar la entrada, de modo que un dato malformado tumbe el servicio.
- Dimensionar para el tráfico medio y verse desbordado en cuanto llega un pico real.
- Sustituir la versión en producción sin despliegue canario ni forma de revertir rápido.
Ejemplo resuelto: servir un clasificador con API
Un clasificador de texto se exporta a un formato portable y se mete en un contenedor con sus dependencias. Se publica tras un endpoint que revisa la entrada, agrupa peticiones para ganar rendimiento y arranca con un despliegue canario al cinco por ciento del tráfico antes de liberarlo al total.
- serializar el modelo a un formato portable como ONNX
- envolverlo en un contenedor con sus dependencias
- exponer un endpoint que valida la entrada y responde la predicción
- escalar réplicas y añadir una cola para absorber picos
- lanzar en canario, observar métricas y liberar al tráfico completo
¿Para qué sirve en la realidad?
Todo producto que consulta un modelo en vivo —motores de recomendación, detección de fraude, asistentes— depende de un endpoint que responde en milisegundos y aguanta la demanda sin derribar la aplicación que lo consume.
Una publicación canario de un modelo sirve para:
Servir un modelo en línea suele exigir mayor atención a la latencia por petición que la predicción por lotes.
Servicio
Ordena el camino de un modelo al servicio en producción:
Empaquetar
Contenerizar
Desplegar
Monitorizar
Acuerdo de nivel de servicio
Objetivos de disponibilidad y rendimiento de un servicio.
Une cada término de servicio con su definición:
Serving
# Servir modelos ## Modo ### lote ### en línea ### híbrido ## Empaquetado ### formato portable ### contenedor ### dependencias ## Rendimiento ### latencia ### agrupación ### escalado y colas ## Despliegue ### azul-verde ### canario ### observabilidad
Microservicios
Arquitectura que expone funcionalidad como servicios independientes y escalables.
Tu endpoint se cae cuando llegan peticiones masivas. ¿Escalar réplicas, añadir cola, o agrupar peticiones? Razona qué atacaría mejor el pico.