152 — Serving online, batch y streaming

← Clase anterior · Índice de la parte · Clase siguiente →

Parte: 12 — Ingeniería de IA, MLOps, LLMOps y AgentOps
Nivel: experto · Horas estimadas: 6
Laboratorio: observability · Estado: EXECUTABLE_CORE

🎯 Propósito

Comprender serving online, batch y streaming dentro de la evolución de la inteligencia artificial, implementar un experimento mínimo verificable y distinguir qué parte constituye evidencia frente a una afirmación todavía no comprobada.

📚 Resultados de aprendizaje

Al finalizar podrás:

1. Explicar serving online, batch y streaming usando los conceptos serving, batch, streaming, API.
2. Ejecutar el laboratorio con una semilla explícita y revisar su contrato JSON.
3. Identificar al menos un supuesto, una limitación y un riesgo de aplicación.
4. Comparar el enfoque con la etapa anterior de la ruta de aprendizaje.
5. Producir una evidencia reproducible y una conclusión que no exceda los datos.

🧩 Conceptos centrales

serving, batch, streaming, API

🗺️ Ubicación en el mapa de la IA

Un modelo registrado y probado (clases 150-151) todavía no sirve a nadie: falta decidir cómo llega la predicción al consumidor. Online, batch y streaming son los tres patrones de serving que gobiernan latencia, costo y frescura, y condicionan todo lo que sigue: qué se puede observar (153), qué deriva se detecta y cuándo (154) y cuánto cuesta operar (157). Elegir mal aquí es caro de revertir: cambia la arquitectura completa.

📖 Fundamentos

⚡ Online (síncrono, por petición)

El consumidor llama a un endpoint (REST/gRPC) y espera la respuesta.

• Optimiza latencia: el presupuesto se mide en percentiles (p50/p95/p99), no en promedio — el promedio esconde la cola, y la cola es lo que ve el usuario que espera (Dean & Barroso, The Tail at Scale).
• Exige features disponibles en milisegundos (feature store online, cachés).
• Escala con réplicas + balanceador; el costo corre aunque no haya tráfico (capacidad reservada) o paga arranques en frío (serverless).
• Para LLMs se añade una métrica propia: TTFT (time to first token) con streaming de tokens, que mejora la latencia percibida sin cambiar el throughput.

📦 Batch (asíncrono, por lote)

Un job periódico puntúa un conjunto grande y materializa los resultados (tabla, fichero) que el consumidor lee después.

• Optimiza throughput y costo por predicción: sin restricción de latencia por ítem, se usan lotes grandes, hardware spot y horarios valle.
• La frescura queda acotada por la periodicidad: un score diario tiene hasta 24 h de edad. Si la decisión tolera esa edad, batch es casi siempre lo más barato y simple.
• Fallo benigno: el job se relanza; nadie espera en línea.

🌊 Streaming (asíncrono, por evento)

El modelo consume un flujo de eventos (Kafka/PubSub) y emite predicciones o features al paso de los datos.

• Optimiza frescura sin petición: reacciona a eventos (fraude en la transacción, features "últimos 10 minutos") con latencias de sub-segundo a segundos.
• Coste de complejidad alto: exactly-once vs. at-least-once, ventanas, reprocesamiento, estado distribuido.
• Patrón híbrido común: features en streaming + inferencia online (el endpoint lee features frescas precalculadas).

📐 Latencia vs. throughput

Son objetivos en tensión: agrupar peticiones en lotes (batching dinámico) sube el throughput de la GPU pero añade espera a cada petición individual. La relación de Little (concurrencia = tasa × latencia) da el esqueleto del cálculo de capacidad:

throughput_max ≈ (réplicas × lote) / latencia_por_lote
p. ej. 4 réplicas, lote 8, 100 ms/lote → ≈ 320 peticiones/s

La decisión de patrón se reduce a tres preguntas: ¿quién espera? (usuario en línea → online), ¿qué edad de predicción tolera la decisión? (horas → batch), ¿la señal es un evento que debe reaccionar solo? (→ streaming).

🧮 Ejemplo trabajado

Sistema de recomendaciones de un e-commerce con 2 M de usuarios, de los cuales ~80 000 visitan al día. Comparamos servir el top-N con batch diario vs. online:

batch diario (todos los usuarios):
  2 000 000 usuarios × 1 scoring = 2.0 M predicciones/día
  utilidad: solo 80 000 se usan → 4 % de las predicciones se consumen
  frescura: hasta 24 h de edad; no reacciona a la sesión actual

online (solo visitantes):
  80 000 visitas × ~5 páginas = 400 000 predicciones/día  (5× menos cómputo útil total)
  pico: 80 000×5 / (8 h × 3600 s) ≈ 14 rps promedio; pico ~10× ≈ 140 rps
  con p95 requerido de 80 ms y ~50 rps por réplica → 3 réplicas + margen
  frescura: usa el carrito y los clics de la sesión actual

Decisión razonable: híbrido — candidatos pesados precalculados en batch (embeddings, top-500 por usuario, donde el 96 % de desperdicio es aceptable porque el costo unitario es bajo) y re-ranking online ligero con la señal de sesión. El ejemplo muestra el criterio general: batch para lo costoso y tolerante a edad, online para lo barato y sensible al contexto inmediato.

📊 Propiedades y comparación

flowchart TD
  A{¿Alguien espera la respuesta en línea?} -->|sí| B[Online: endpoint + réplicas + p95]
  A -->|no| C{¿La decisión tolera horas de edad?}
  C -->|sí| D[Batch: job periódico + tabla materializada]
  C -->|no| E{¿Llega como flujo de eventos?}
  E -->|sí| F[Streaming: consumidor + ventanas]
  E -->|no| G[Revisar el requisito: suele ser online con caché]
  B -.híbrido común.- D

⚠️ Errores conceptuales frecuentes

1. «Optimizar la latencia promedio.» El usuario del p99 existe y suele ser el que más peticiones hace; los SLO se definen sobre percentiles, y las colas se amplifican cuando una página hace N llamadas (la probabilidad de tocar el p99 crece con N).
2. «Online es siempre mejor porque es más fresco.» Si la decisión tolera horas de edad, online solo añade costo fijo, complejidad y modos de fallo nuevos.
3. «Streaming = batch más rápido.» Cambia el modelo de fallos completo: estado, reprocesamiento, garantías de entrega. No es un parámetro de velocidad, es otra arquitectura.
4. «El throughput de la GPU es mi throughput.» Sin batching dinámico, una GPU sirve peticiones de a una; el throughput real depende del tamaño de lote alcanzable dentro del presupuesto de latencia.
5. «Puedo precalcular todo.» Las señales de sesión (carrito actual, query actual) no existen antes de la visita; lo sensible al contexto inmediato es irreductiblemente online.

🚀 Del aprendizaje a la operación

El laboratorio contrasta los patrones con números deterministas; producción añade autoscaling con métricas de cola, feature stores con paridad offline/online, batching dinámico en el servidor de inferencia (Triton, vLLM para LLMs), colas de reintento y degradación elegante (responder con el resultado batch si el online expira). El error de diseño más común no es técnico: es no haber escrito el requisito de frescura y el presupuesto de latencia antes de elegir el patrón.

🧪 Laboratorio

python lab.py

El laboratorio llama a ai_evolution.labs.run_lab("observability"). Esta decisión evita 183 implementaciones divergentes: cada clase tiene un entrypoint propio, pero los motores didácticos se prueban como una biblioteca común.

🔍 Evidencia esperada

• tipo de laboratorio y semilla;
• entradas o decisiones observables;
• resultado estructurado;
• lista evidence con hechos que pueden inspeccionarse;
• lista limitations que impide presentar la demo como producción.

📓 Notebooks

• 📓 notebook.ipynb: recorrido guiado con la materia resumida.
• ✍️ notebook_student.ipynb: ejercicios para resolver.
• ✅ notebook_solution.ipynb: solución de referencia explicada.

📝 Evaluación

Consulta assessment.md para preguntas y criterio de aceptación.

⚠️ Errores comunes

❓ Preguntas frecuentes

¿Debo usar una API comercial?
No. El núcleo funciona localmente. Las extensiones LIVE se documentan por separado.

¿El laboratorio representa una implementación industrial?
No por sí solo. Enseña el contrato y el patrón; producción exige integración, seguridad, observabilidad, pruebas y operación.

¿Dónde profundizo?
Revisa las especializaciones enlazadas en el README raíz y la ruta siguiente.

🔗 Referencias

• Dean & Barroso (2013), "The Tail at Scale", CACM — uso: referencia consultada en su fuente original
• Huyen, Designing Machine Learning Systems — cap. de serving y feature stores — uso: referencia consultada en su fuente original
• Kleppmann, Designing Data-Intensive Applications — batch y stream processing — uso: referencia consultada en su fuente original
• Google Cloud, "MLOps: Continuous delivery and automation pipelines in machine learning" — uso: referencia consultada en su fuente original
• Apache Kafka Documentation — uso: referencia consultada en su fuente original

📜 Papers que fundamentan esta clase

Bloque generado por python scripts/link_papers_to_classes.py. La fuente es papers/catalog/papers.json.

Cada ficha explica el problema anterior, la matemática mínima, los límites y los errores de atribución más frecuentes. Para leerlas con método: cómo leer un paper de IA · anexos matemáticos.

📚 Bibliografía de apoyo

Bloque generado por python scripts/link_sources_to_classes.py. Cada obra lleva su localizador verificado en sources/bibliography.json.

Los papers dicen de dónde salió el mecanismo. Estas obras lo desarrollan con el espacio que una clase no tiene: teoría completa, demostraciones y ejercicios.

⬅️ Clase anterior

151 — CI/CD y pruebas para sistemas de IA

➡️ Siguiente clase

153 — Observabilidad: logs, métricas y trazas

📝 Evaluación completa

❓ Preguntas

1. Define serving online, batch y streaming sin usar una marca o framework como definición.
2. Explica la relación entre serving, batch, streaming, API.
3. Ejecuta lab.py dos veces con la misma semilla. ¿Qué debe conservarse?
4. Identifica una afirmación permitida y una afirmación exagerada sobre el resultado.
5. Propón una prueba negativa o un caso límite.

🏆 Reto verificable

Amplía el resultado del laboratorio con una clave student_extension que incluya:

• el supuesto que estás probando;
• una medición o comprobación;
• la conclusión;
• una limitación.

✅ Criterio de aceptación

• [ ] lab.py termina con código 0.
• [ ] El resultado contiene kind, seed, evidence y limitations.
• [ ] La extensión no modifica el comportamiento de otras clases.
• [ ] La interpretación referencia datos impresos por el laboratorio.
• [ ] Se declara al menos un riesgo o condición de no uso.