Objetivos de aprendizaje
- Elegir entre Ollama, llama.cpp, vLLM, LiteLLM y Ray Serve según el caso.
- Distinguir demo local, servicio interno y producción real.
- Diseñar una arquitectura mínima con gateway, observabilidad y evals.
En cristiano: serving. Es poner el modelo detrás de una API para que otras aplicaciones lo usen de forma estable, medible y controlada.
Regla rápida
- Ollama: prototipos locales, enseñanza, apps personales y equipos pequeños.
- llama.cpp server: GGUF ligero, CPU/GPU modesta, control fino y servidor local simple.
- vLLM: GPUs, alto rendimiento, batching, API compatible OpenAI y modelos grandes.
- LiteLLM: gateway para unificar proveedores, claves, presupuestos, caché y fallbacks.
- Ray Serve: escalar varias réplicas, multi-modelo, autoscaling y patrones de producción.
Idea clave. La API compatible con OpenAI se ha convertido en un puente práctico: puedes cambiar backend sin reescribir toda la aplicación.
Arquitectura mínima
app web -> API propia /api/chat -> gateway LiteLLM -> backend local: llama.cpp | vLLM | Ollama -> observabilidad: Langfuse / OpenTelemetry -> evals: promptfoo o tests propios -> logs: request_id, modelo, latencia, coste, resultado
Cuidado. No expongas directamente el servidor del modelo a internet. Pon una API delante con autenticación, límites, logs y validación.
Comprueba que funciona. Decide para tu caso: si tienes una GPU potente y varios usuarios, mira vLLM; si quieres portátil o mini PC, empieza por llama.cpp/Ollama; si hay varios proveedores, pon LiteLLM delante.
Guardar y reabrir el proyecto.
MLOps para IA no empieza con Kubernetes. Empieza con una API medible, límites claros y capacidad de cambiar modelo sin romper el producto.
Siguiente misión recomendada
Si has guardado la evidencia de esta lección, continúa con «llama.cpp server». Si no, repite la comprobación antes de avanzar.