llama.cpp acaba de superar las 100.000 estrellas en GitHub, un hito que su creador Georgi Gerganov celebró en X con una predicción que, aunque expresada con humor, resume bien la dirección del mercado: "90% of all AI agents will be running locally with llama.cpp". La IA local ha pasado de ser territorio de entusiastas a convertirse en infraestructura de equipo, y las herramientas están madurando rápidamente.
El ejemplo más claro de esa madurez es una funcionalidad que llevaba tiempo siendo la más solicitada por la comunidad: el modo router de llama-server. Con él, una sola instancia del servidor puede gestionar y alternar entre múltiples modelos bajo demanda, sin reinicios, sin herramientas intermedias y sin dependencia de la nube.
¿Qué es el modo router?
Hasta hace poco, llama-server tenía una limitación fundamental: un modelo por proceso. Si una empresa quería correr simultáneamente un asistente de código, un modelo de atención al cliente y un motor de traducción en el mismo servidor, necesitaba tres procesos separados o una capa de orquestación adicional —como Ollama— delante de ellos.
El modo router elimina esa restricción. Según informa Victor Mustar en X, las nuevas capacidades de llama.cpp incluyen:
"Auto-discover GGUFs from cache • Load on first request • Each model runs in its own process • Route by
model(OpenAI-compatible API) • LRU unload at--models-max"
En la práctica, llama-server actúa como un proxy inverso con conciencia de modelos. Cada modelo corre en su propio proceso hijo —si uno falla, los demás siguen funcionando—. Los modelos se cargan en el primer acceso y se descargan con política LRU (Least Recently Used) cuando se alcanza el límite definido en --models-max.
Configuración paso a paso
Activar el modo router requiere un único cambio: iniciar llama-server sin el parámetro --model. El servidor detecta la ausencia y entra automáticamente en modo router, descubriendo los archivos GGUF disponibles en el directorio de caché.
# Modo router: sin --model, con límite de modelos en caché
llama-server --port 8080 --models-max 3A partir de ese momento, cualquier cliente compatible con la API de OpenAI selecciona el modelo deseado mediante el campo model en el cuerpo de la solicitud:
{
"model": "qwen2.5-coder-7b-q4_k_m",
"messages": [{"role": "user", "content": "Resume este contrato:"}]
}Si el modelo solicitado no está cargado, el servidor lo carga desde el caché antes de responder. Si al cargarlo se superara el límite --models-max, el modelo menos utilizado recientemente se descarga primero. Según mediciones reportadas por la comunidad, el tiempo de cambio entre modelos oscila entre 3 y 10 segundos, dependiendo de la velocidad de lectura del disco y el ancho de banda de la VRAM.
Casos de uso para empresas
Caso 1: Equipo de desarrollo con servidor compartido
Un equipo de cinco desarrolladores ejecuta tres modelos en un Mac Studio M3 Ultra (192 GB de memoria unificada):
- DeepSeek-R1:32B (Q4) para razonamiento complejo y revisión de código
- Qwen2.5-Coder:7B (Q8) para completado rápido de código en el IDE
- Llama 3.3:70B (Q4) para documentación, commit messages y consultas generales
Cada herramienta —plugin del IDE, bot de Slack, pipeline de CI— especifica el modelo adecuado en cada solicitud API. Sin reinicios, sin gestión manual, sin coste por token.
Caso 2: Empresa con múltiples departamentos
Las organizaciones no técnicas se benefician igual de la gestión multi-modelo:
- Administración: un modelo pequeño Phi-4 (3,8B) para categorizar facturas y clasificar correos entrantes
- Atención al cliente: Llama 3.3 para redactar respuestas estructuradas y generar preguntas frecuentes
- Traducciones: Qwen 2.5 para español, alemán e inglés sin pasar por ningún servicio externo
Todos los departamentos comparten un único endpoint interno. Ningún dato sale de la red corporativa, lo que simplifica radicalmente el cumplimiento del RGPD y elimina los riesgos asociados a transferencias a terceros países.
Caso 3: Procesamiento nocturno por lotes
Por las noches, un modelo grande (70B) procesa análisis en bloque: clasificación de contratos, extracción de datos de facturas, generación de informes. Durante el horario de atención, modelos más pequeños y rápidos gestionan las consultas interactivas. El caché LRU gestiona la transición automáticamente.
Caso 4: Subvención Kit Digital
Para empresas españolas, la implantación de un stack de IA local como este puede enmarcarse dentro de la categoría "Inteligencia Artificial" de la ayuda Kit Digital. Un servidor con tres modelos especializados —atención al cliente, gestión documental y asistente interno— puede cubrir múltiples módulos de forma simultánea. Consulta los detalles en nuestra página sobre Kit Digital e IA local.
Modo router vs. Ollama: ¿cuándo usar cada uno?
Ollama sigue siendo una excelente opción de entrada, especialmente para equipos que valoran una interfaz visual y una configuración rápida. El modo router de llama.cpp ocupa un lugar diferente en la curva control-complejidad.
| Característica | llama.cpp Router | Ollama |
|---|---|---|
| Esfuerzo de configuración | Medio (CLI) | Bajo (GUI + CLI) |
| Velocidad de inferencia | Alta (sin capa de abstracción) | Buena |
| Aislamiento por proceso | Sí | No |
| Gestión multi-modelo | Sí (nativo) | Sí (nativo) |
| API OpenAI compatible | Sí | Sí |
| Profundidad de configuración | Muy alta | Moderada |
El modo router de llama.cpp gana en rendimiento bruto y garantías de aislamiento. Ollama gana en facilidad de uso. Para equipos técnicos que buscan máximo rendimiento de inferencia con control granular sobre los procesos, el modo router es la elección más sólida para producción.
Hardware y costes
El modo router no cambia los requisitos de hardware: la memoria unificada sigue siendo el factor determinante. Cuantos más modelos se quieran mantener activos de forma simultánea, más RAM se necesita.
| Hardware | RAM | Configuración práctica |
|---|---|---|
| Mac Mini M4 Pro | 64 GB | 1–2 modelos pequeños (3B–7B Q4) |
| Mac Studio M3 Max | 64–96 GB | 2–3 modelos medianos (7B–14B Q4/Q8) |
| Mac Studio M3 Ultra | 192 GB | 3–5 modelos, incluyendo 70B Q4 |
Las mediciones reportadas por la comunidad apuntan a 30–80 tokens por segundo para modelos de 7B en cuantización Q4 sobre Apple Silicon. Modelos más grandes (70B Q4) ofrecen 8–20 tok/s en el M3 Ultra, rendimiento suficiente para análisis documental y procesamiento por lotes.
En términos de coste, un Mac Studio M3 Max con un precio de 2.000–3.500 € sustituye un gasto en APIs que, con uso activo de equipo, puede alcanzar los 300–600 € mensuales. El punto de equilibrio se sitúa normalmente entre cuatro y ocho meses, tras los cuales la inferencia es prácticamente gratuita.
Soberanía del dato por diseño
La ventaja estructural de un stack local como este va más allá del rendimiento: ningún dato abandona el perímetro de la empresa. Sin claves de API que rotar, sin transferencias internacionales de datos bajo el RGPD, sin que ningún proveedor externo acceda al contenido de los prompts o las respuestas.
Para empresas que manejan información sensible —expedientes legales, historiales médicos, informes financieros, datos de RR.HH.— la inferencia local no es una preferencia, sino a menudo un requisito de cumplimiento normativo. Más información en nuestra sección sobre IA local para empresas.
Siguiente paso
El modo router representa un punto de madurez silencioso pero significativo para el ecosistema de IA local. Ya no hace falta una herramienta separada para gestionar múltiples modelos: llama.cpp lo hace de forma nativa, con rendimiento completo y aislamiento a nivel de proceso.
Si quieres desplegar un servidor multi-modelo de IA local para tu equipo sin tener que gestionar la infraestructura desde cero, inicia un proyecto piloto con nosotros — habitualmente tenemos un stack funcional listo en dos semanas.