Mapa de serving: Ollama, llama.cpp, vLLM
Ejecutar un modelo en tu máquina es el primer paso. Servirlo bien significa API estable, límites, logs, métricas, colas, caché y una forma clara de cambiar de modelo sin romper la app.
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
Terminal
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.