Model Serving
Exponer inferencia para callers
Model Serving es la práctica de operar una capacidad que carga un artefacto de modelo y expone inferencia para callers bajo condiciones de disponibilidad, rendimiento y evolución controladas. Su responsabilidad es convertir un modelo o runtime en una capacidad invocable. No equivale al cálculo abstracto de inferencia, a una organización proveedora ni a un AI Gateway.
El serving puede ser un endpoint de red, un proceso local, un job batch o una capacidad administrada por un proveedor. La forma de exposición cambia, pero la pregunta permanece: ¿cómo se obtiene una inferencia desde un artefacto elegido y cómo se opera esa capacidad para consumidores reales? Un modelo en un archivo no es todavía un servicio; un endpoint de proveedor puede servir un modelo sin que el equipo de la aplicación opere el runtime.
La arquitectura MLOps de Google Cloud y la documentación de serving de modelos de Google Cloud ilustran componentes de una plataforma administrada. Son ejemplos de arquitectura, no requisitos universales ni una prescripción de proveedor.
Serving, inferencia y proveedor
Inference es la computación que aplica un modelo a entradas para producir una salida. Puede ocurrir dentro de un proceso, en un dispositivo, en batch o detrás de una API. Serving es la operación que hace disponible esa inferencia para un consumidor, gestionando carga, requests, recursos y ciclo de vida.
Un model provider es una organización o servicio que entrega modelos, APIs o capacidad de ejecución. Puede operar el serving para una aplicación, pero Provider y Model Serving no son sinónimos. Un equipo puede servir un modelo propio; un proveedor puede ofrecer serving de muchos modelos; una aplicación puede llamar a un proveedor sin operar el servidor.
Serving y AI Gateway
AI Gateway media y gobierna el acceso a uno o más endpoints de serving o proveedores. Puede seleccionar una ruta, aplicar credenciales, límites, fallback y telemetría. Model Serving ejecuta o coordina la inferencia. Las dos capas pueden vivir en el mismo producto o despliegue, pero resuelven responsabilidades diferentes.
Un gateway que reenvía una solicitud no está sirviendo el modelo por ese hecho. Un servidor que expone inferencia no decide necesariamente qué proveedor está permitido para cada tenant. Separar las capas permite cambiar routing o política sin confundirlo con cargar y ejecutar el artefacto.
Artefacto y runtime
El serving necesita identificar qué se carga y bajo qué runtime. Según el caso pueden importar:
- pesos, checkpoint o artefacto compilado;
- arquitectura y tokenizer;
- configuración de inferencia;
- dependencias y runtime;
- hardware, memoria y aceleradores;
- versión de código de serving;
- límites de entrada y salida;
- políticas de disponibilidad y aislamiento.
Un nombre de modelo no basta para reproducir qué se sirvió. El artefacto puede cambiar detrás de una etiqueta, y una misma versión puede comportarse diferente con otro tokenizer, runtime o hardware. La identidad operacional necesita correlacionar el modelo con su configuración y entorno sin prometer reproducibilidad perfecta.
Online y batch
Online serving atiende solicitudes individuales o pequeños lotes con una expectativa de respuesta acotada. Batch inference procesa un conjunto de entradas, normalmente con otra relación entre throughput, costo y latencia. Ambos son serving cuando exponen una capacidad operacional de inferencia; no requieren canonicals separados.
La elección modifica los requisitos. Online necesita admisión, timeouts, streaming o respuesta parcial cuando corresponda. Batch necesita particionado, reanudación, idempotencia, progreso y tratamiento de resultados parciales. Un pipeline batch no debe evaluarse con el mismo SLO que un endpoint interactivo.
Request handling
Un servidor debe interpretar requests, validar inputs, seleccionar una versión, ejecutar inferencia y producir resultados o errores observables. Puede necesitar colas, batching dinámico, backpressure, límites de concurrencia y cancelación. Esas tácticas no garantizan calidad del modelo ni autorizan cualquier input.
La entrada puede exceder contexto, memoria o formato soportado. Rechazarla de forma explícita suele ser más correcto que truncarla sin declarar el cambio. El resultado debe conservar su estado: completado, parcial, fallido, cancelado o no ejecutado. Un status de transporte no describe por sí solo si la inferencia produjo una respuesta útil.
Recursos y escalado
Serving administra recursos de CPU, memoria, GPU, aceleradores, almacenamiento y conexiones. Puede escalar réplicas, compartir batch o mantener modelos calientes. El escalado modifica capacidad y latencia, no convierte un modelo en más correcto. La utilización debe observarse junto con colas, errores, latencia y calidad de servicio.
Los modelos grandes pueden requerir carga lenta, particionado o distintos niveles de precisión. El runtime puede introducir diferencias numéricas o límites que no aparecen en un benchmark. Declarar una capacidad de hardware no equivale a declarar el comportamiento completo del sistema.
Disponibilidad y fallos
El serving debe definir qué sucede cuando el modelo no carga, el runtime se queda sin memoria, el hardware falla, una cola se llena o una request se cancela. Puede rechazar, reintentar, cambiar de réplica, degradar o derivar a otra capacidad. Fallback entre proveedores es una responsabilidad posible del gateway; el servidor debe exponer estados suficientes para que esa decisión no oculte un fallo real.
Una respuesta vacía, truncada o de un modelo alternativo no debería parecer una respuesta normal. La observabilidad puede correlacionar versión, réplica, modelo y error; la evaluación puede juzgar la calidad de la salida. Serving conserva la responsabilidad de hacer explícito el estado operacional.
Rollout y evolución
Actualizar un artefacto puede requerir cargar una nueva versión, probar compatibilidad, enviar tráfico gradualmente, mantener una versión anterior y revertir si las señales empeoran. Deployment conserva el concepto general de poner una capacidad en un entorno; aquí interesa cómo ese despliegue afecta la inferencia expuesta. MLOps / LLMOps Operations conecta ese cambio con versionado, monitoring, evaluación en producción y drift.
Canary, shadow o blue-green son estrategias posibles, no garantías. Una nueva versión puede tener menor latencia y peor calidad, o funcionar en tests y fallar con distribución real. Correlacionar el tráfico con artefacto, configuración y entorno permite distinguir una regresión de un fallo de infraestructura.
Seguridad y límites
Serving puede manejar inputs sensibles, modelos propietarios y resultados con impacto. Necesita autenticación, autorización, aislamiento y límites adecuados, pero este canonical no materializa AI Security. Un endpoint accesible no implica que cualquier caller esté autorizado ni que el modelo pueda ejecutar efectos externos.
El servidor tampoco decide por sí solo si una salida cumple una política de producto. Guardrails, evaluación, permisos y revisión pueden vivir en otras capas. La exposición de una función de inferencia no debe confundirse con autorización para usar el resultado.
Relación con evaluación y operaciones
AI Evaluation Fundamentals puede comparar versiones de un modelo o serving bajo casos y criterios. Regression Testing puede conservar casos que detecten degradación después de un rollout. Ninguna de las dos prácticas sustituye operar la capacidad; servir sin evaluación deja ciega la calidad, evaluar sin serving no describe disponibilidad real.
AI / LLM Observability puede aportar señales sobre latencia, proveedor, modelo, streaming, errores y recursos. Las señales operativas no son automáticamente un juicio de calidad. La separación permite investigar una falla de runtime sin afirmar que toda salida lenta es incorrecta o que toda salida rápida es buena.
Límites
Model Serving no es:
- Inference, aunque exponga esa computación;
- Model Provider, aunque un proveedor pueda operarlo;
- AI Gateway, aunque reciba requests desde uno;
- Deployment general, aunque requiera desplegarlo;
- Evaluation o Regression Testing, aunque sus resultados informen rollouts.
Su unidad es la capacidad de inferencia operada para callers, con identidad de artefacto, runtime, recursos, disponibilidad y evolución suficientemente explícitos.