Sobre MíServiciosProyectosContacto
Blog·06/06/2026

Del notebook a una API de inferencia que aguanta producción

Un modelo entrenado en un notebook no es un producto. Convertirlo en un servicio que valida su entrada, responde con latencia predecible y se puede monitorizar es el trabajo que separa una demo de un sistema.

Del notebook a una API de inferencia que aguanta producción

El modelo que funciona en el notebook y el modelo que funciona en producción son el mismo artefacto pero problemas distintos. En el notebook controlas la entrada, corres una celda y miras el resultado. En producción llega tráfico real, con datos malformados, en paralelo, y alguien necesita saber si el servicio está vivo y cuánto tarda.

Primero, un contrato de entrada. La mayoría de errores de un servicio de inferencia no son del modelo, son de la entrada: un campo que falta, un tipo que no cuadra, un array con la forma equivocada. Validar la petición antes de que llegue al modelo, con un esquema explícito, convierte un error 500 con traza incomprensible en un 400 con un mensaje claro. Pydantic con FastAPI te da esto casi gratis, y es la diferencia entre un servicio que se puede depurar y uno que no.

Health y readiness no son opcionales. Un endpoint de salud que confirme que el modelo está cargado permite a un orquestador saber cuándo enrutar tráfico y cuándo reiniciar. Sin él, un despliegue que falla al cargar el modelo recibe peticiones y las falla en silencio. Es una línea de código que evita una clase entera de incidentes.

Si no lo mides, no existe. Un servicio de inferencia sin métricas es una caja negra en el peor momento posible: cuando algo va mal y no sabes si es más lento, si falla más o si el volumen se disparó. Exponer un endpoint de métricas en formato Prometheus —contador de peticiones por resultado, throughput de predicciones, histograma de latencia— te da percentiles reales (la p95, no la media) y una base para alertar antes de que el problema sea visible para el usuario.

Empaquetar para que sea reproducible. El servicio tiene que arrancar igual en tu máquina, en CI y en el servidor. Un contenedor con las dependencias fijadas y un único comando de arranque elimina la clase de fallos de "en mi máquina funcionaba". No necesitas una plataforma de serving completa para esto; para muchos casos, un contenedor con un servidor HTTP y sus métricas es suficiente y se mantiene solo.

Reuní este mínimo —carga del modelo, `/predict` validado, `/health` y `/metrics` de Prometheus en un comando— en servectl. No sustituye a una plataforma de serving industrial, pero cubre el tramo que va de "tengo un modelo en disco" a "tengo un endpoint observable", que es justo donde muchos proyectos se quedan a medias.

Trabaja con JMWEB

Construyamos algo que llegue a producción.

Todo arranca con una conversación. Trae un dataset, un objetivo o un modelo que se atasca; del resto me ocupo yo.

Empezar un proyecto

Sigue leyendo:

hola@jmwebsoluciones.com