Modo router de Llama-Server: conmutación dinámica de modelos sin reinicios

Durante mucho tiempo, llama.cpp tuvo una limitación flagrante:
solo se podía servir un modelo por proceso, y cambiar de modelo implicaba un reinicio.

Esa era ha terminado.

Las actualizaciones recientes introdujeron el modo router en llama-server, acercando el funcionamiento a lo que la gente espera de los runtime modernos para LLM locales:

• carga dinámica de modelos
• descarga bajo demanda
• cambio por solicitud
• sin reinicio del proceso

En otras palabras: comportamiento similar a Ollama, pero sin las rueditas de apoyo.

Si aún estás decidiendo entre runtime locales, APIs en la nube e infraestructura autoalojada, la visión general de alojamiento de LLM es un buen punto de partida.

Prerrequisitos

El modo router requiere una compilación reciente de llama-server, aproximadamente posterior a mediados de 2024. Las compilaciones antiguas no tienen las banderas --models-preset o --models-dir.

Para opciones de instalación (gestor de paquetes, binarios precompilados o compilación completa desde código fuente con CUDA), consulta la rápida iniciación de llama.cpp.

Una vez que tengas llama-server, confirma que tu compilación es compatible con el modo router:

llama-server --help | grep -i models

Si aparece --models-preset o --models-dir, estás bien. Si no están, actualiza a una compilación más nueva.

Mi salida actual de ayuda relacionada con modelos:

-cl,   --cache-list                     muestra la lista de modelos en caché
                                        Prefijo/Sufijo/Intermedio) ya que algunos modelos lo prefieren así. (predeterminado: deshabilitado)
                                        modelos con resolución dinámica (predeterminado: leer del modelo)
                                        modelos con resolución dinámica (predeterminado: leer del modelo)
                                        modelos de embedding (predeterminado: deshabilitado)
--models-dir PATH                       directorio que contiene modelos para el servidor router (predeterminado: deshabilitado)
                                        (env: LLAMA_ARG_MODELS_DIR)
--models-preset PATH                    ruta al archivo INI que contiene preajustes de modelos para el servidor router
                                        (env: LLAMA_ARG_MODELS_PRESET)
--models-max N                          para el servidor router, número máximo de modelos a cargar simultáneamente
                                        (env: LLAMA_ARG_MODELS_MAX)
--models-autoload, --no-models-autoload
                                        para el servidor router, si se deben cargar modelos automáticamente (predeterminado:
                                        (env: LLAMA_ARG_MODELS_AUTOLOAD)

Qué hace realmente el modo router

El modo router convierte llama-server en un despachador de modelos.

En lugar de unirse a un solo modelo mediante -m, el servidor:

• arranca sin ningún modelo cargado
• recibe una solicitud que nombra un modelo
• carga ese modelo si no está ya en memoria
• ejecuta la inferencia
• opcionalmente descarga el modelo después de la respuesta, o lo mantiene caliente para la siguiente solicitud

La idea clave

Ya no estás ejecutando:

./llama-server -m model.gguf

Estás ejecutando:

./llama-server --models-preset models.ini --port 8080

Y dejando que el servidor decida qué cargar y cuándo, basándose en lo que el cliente realmente solicita.

Esto es importante porque significa que un proceso persistente puede servir a una flota entera de modelos, con clientes seleccionando el adecuado para cada tarea: un modelo de codificación, un modelo de chat, un modelo de resumen — sin ningún sobrecoste de coordinación por tu parte.

Configuración: definiendo tus modelos

Aquí es donde las cosas aún son un poco crudas.

Aún no hay un formato oficial totalmente estable, pero las compilaciones actuales admiten definiciones de modelos estilo INI mediante un archivo de configuración.

Ejemplo models.ini

[llama3]
model = /opt/models/llama-3-8b-instruct.Q5_K_M.gguf
ctx-size = 8192
ngl = 35
threads = 8

[mistral]
model = /opt/models/mistral-7b-instruct-v0.3.Q4_K_M.gguf
ctx-size = 4096
ngl = 20
threads = 8

[qwen]
model = /opt/models/qwen2.5-coder-7b-instruct.Q5_K_M.gguf
ctx-size = 16384
ngl = 35
threads = 8

Cada nombre de sección se convierte en el identificador del modelo que los clientes usan en el campo "model" de sus solicitudes de API.

Parámetros clave de configuración

Elegir el valor adecuado de ngl depende de la VRAM disponible de tu GPU — para selección de GPU y economía de hardware, la guía de hardware de cómputo es una referencia útil. Para observar el consumo de VRAM en vivo mientras lo ajustas, consulta las herramientas de monitoreo de GPU para Linux.

Iniciar el servidor con configuración

./llama-server --models-preset /opt/llama.cpp/models.ini --port 8080

Confirma que el servidor arrancó correctamente:

curl http://localhost:8080/v1/models | jq '.data[].id'

Deberías ver cada nombre de sección de tu models.ini listado como un ID de modelo.

Una nota sobre estabilidad

La interfaz de configuración INI aún está evolucionando:

• las banderas pueden cambiar entre commits
• algunos parámetros solo son reconocidos por configuraciones de compilación específicas
• la documentación va por detrás de la implementación

Fija una versión específica de llama.cpp si necesitas reproducibilidad entre reinicios.

Uso de la API: cambiando modelos por solicitud

Una vez que el servidor está en ejecución, el cambio de modelos se realiza a través de la API compatible con OpenAI estándar. Simplemente configuras el campo "model".

Listar modelos registrados

curl http://localhost:8080/v1/models

Solicitud de completado — primer modelo

curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama3",
    "messages": [
      {"role": "user", "content": "Explain router mode in one paragraph"}
    ]
  }'

Cambiar a un modelo diferente — mismo endpoint, mismo puerto

curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen",
    "messages": [
      {"role": "user", "content": "Write a Python function that reads a CSV file"}
    ]
  }'

El servidor maneja el ciclo de descarga/carga de forma transparente. Tu código de cliente no cambia — solo el campo model.

Ejemplo en Python

Si estás usando el cliente openai de Python:

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8080/v1", api_key="not-needed")

# Use the coding model
response = client.chat.completions.create(
    model="qwen",
    messages=[{"role": "user", "content": "Write a Go HTTP handler"}],
)
print(response.choices[0].message.content)

# Switch to the chat model — same client, different model name
response = client.chat.completions.create(
    model="llama3",
    messages=[{"role": "user", "content": "What is the capital of Australia?"}],
)
print(response.choices[0].message.content)

Qué pasa internamente

Cuando llega una solicitud para qwen y llama3 está actualmente cargado:

1. llama3 se descarga de la VRAM
2. los pesos de qwen se leen del disco y se cargan en la VRAM
3. se ejecuta la inferencia
4. la siguiente solicitud determina si mantener qwen cargado o intercambiar de nuevo

Esto responde directamente a la pregunta común:

¿Cómo puede un servidor local de LLM cambiar de modelos sin reiniciarse?

Cargando modelos dinámicamente por solicitud, no uniéndose al inicio.

Servicio de Systemd: configuración lista para producción

Crear un usuario dedicado y directorios

sudo useradd --system --shell /usr/sbin/nologin --home-dir /opt/llama.cpp llm
sudo mkdir -p /opt/llama.cpp/models
sudo chown -R llm:llm /opt/llama.cpp

Copia tu binario y configuración de modelos en su lugar:

sudo cp build/bin/llama-server /opt/llama.cpp/
sudo cp models.ini /opt/llama.cpp/

/etc/systemd/system/llama-server.service

[Unit]
Description=Llama.cpp Router Server
After=network.target

[Service]
Type=simple
User=llm
WorkingDirectory=/opt/llama.cpp
ExecStart=/opt/llama.cpp/llama-server --models-preset /opt/llama.cpp/models.ini --port 8080
Restart=always
RestartSec=5

Environment=LLAMA_LOG_LEVEL=info

[Install]
WantedBy=multi-user.target

Habilitar e iniciar

sudo systemctl daemon-reload
sudo systemctl enable llama-server
sudo systemctl start llama-server

Verificar e inspeccionar registros

sudo systemctl status llama-server

journalctl -u llama-server -f

En un inicio exitoso verás líneas indicando que el servidor está escuchando y que el registro de modelos ha sido cargado. Una comprobación rápida de sanidad:

curl -s http://localhost:8080/v1/models | jq '.data[].id'

Ahora tienes un servicio persistente con reinicio automático y cambio centralizado de modelos — no se requiere gestión manual de procesos. Si quieres aplicar el mismo patrón a otros binarios, alojar cualquier ejecutable como servicio de Linux explica el enfoque general.

La bandera --metrics de llama-server expone un endpoint compatible con Prometheus. Para tableros específicos de llama.cpp, consultas PromQL y reglas de alertas, consulta la guía de monitoreo de inferencia LLM. Para la configuración de observabilidad más amplia, la guía de observabilidad cubre la pila completa.

Limitaciones que necesitas entender

El modo router es genuinamente útil, pero viene con compensaciones que debes tener claras antes de depender de él en producción.

Solo un modelo en memoria a la vez

Aunque se definan múltiples modelos en models.ini, solo uno reside en la VRAM por trabajador en cualquier momento dado. Cambiar significa un ciclo completo de descarga y recarga.

• cambiar significa recargar
• el pico de latencia es ineludible
• en un modelo 7B típico en Q5, una recarga puede tardar de 3 a 10 segundos dependiendo de la velocidad del disco y el ancho de banda de la VRAM

Esto responde a otra pregunta clave:

¿Soporta llama.cpp servir múltiples modelos a la vez?

No exactamente. Soporta múltiples definiciones, no residencia simultánea. Si necesitas dos modelos genuinamente cargados en paralelo, necesitas dos procesos en dos GPUs separadas.

Para consumo de VRAM medido y tokens por segundo a través de tamaños de modelos, los [benchmarks de rendimiento de LLM](https://www.glukhov.org/es/llm-performance/ “Ingeniería práctica de rendimiento de LLM: throughput vs latencia, límites de VRAM, solicitudes en paralelo, asignación de memoria y benchmarks a través de runtime y hardware.”} cubren el panorama completo. Para números específicos de llama.cpp en una GPU de 16 GB — modelos densos y MoE en múltiples tamaños de contexto — consulta los benchmarks de llama.cpp con 16 GB de VRAM.

Sin caché inteligente

A diferencia de Ollama, que mantiene un pool cálido y expulsa modelos basándose en la recienteidad:

• no hay estrategia automática de expulsión de modelos
• no hay precalentamiento en segundo plano
• no hay cola de prioridad para modelos usados frecuentemente

Si envías solicitudes alternadas para llama3 y mistral, cada solicitud individual desencadena una recarga. Este es el costo fundamental de estar más cerca del metal.

La latencia es impredecible para cargas de trabajo mixtas

Una carga de trabajo bien comportada que usa un modelo de forma consistente será rápida. Una carga de trabajo que intercala múltiples modelos será lenta. Planifica tu lógica de enrutamiento de cliente en consecuencia: agrupa las solicitudes por modelo cuando sea posible.

La configuración no es estable

El soporte INI existe y funciona en la mayoría de las compilaciones recientes, pero no está totalmente estandarizado. Las banderas y nombres de parámetros han cambiado entre versiones. Si actualizas llama-server, prueba tu models.ini contra la nueva compilación antes de desplegar.

Llama.cpp vs Ollama

El modo router reduce la antigua brecha de ciclo de vida con Ollama — la carga dinámica y el cambio por solicitud ahora existen nativamente en llama-server — pero no la cierra. La gestión de memoria se mantiene básica (sin política de expulsión, sin pool cálido), la estabilidad de la configuración sigue siendo experimental, y el cambio entre dos modelos diferentes siempre paga una descarga y recarga completa en lugar del keep-alive basado en TTL de Ollama. En resumen: el modo router te da control máximo y una base modificable; Ollama te da una experiencia más pulida y opinada con menos cosas por configurar.

Para el desglose por pares completo — instalación, gestión de modelos, colocación de GPU, control de caché KV, APIs, rendimiento, modos de fallo y detonantes concretos para elegir uno o migrar entre ellos — consulta llama.cpp vs Ollama en 2026, que es la comparación canónica entre los dos runtime en este sitio.

Si optas por Ollama, la [hoja de referencia de CLI de Ollama](https://www.glukhov.org/es/llm-hosting/ollama/ollama-cheatsheet/ “Hoja de referencia de CLI de Ollama: comando ollama serve, ejemplos de comando ollama run, ollama ps y gestión de modelos.”} cubre los comandos de uso diario. Para una comparación más amplia que también incluye vLLM, LM Studio y LocalAI, consulta cómo se comparan los diferentes runtime locales en 2026.

Llama.cpp vs llama-swap

llama-swap es un orquestador externo que se sitúa delante de una o más instancias de llama-server:

• intercepta solicitudes e inspecciona el campo model
• inicia el proceso de llama-server apropiado para ese modelo
• apaga las instancias inactivas después de un timeout configurable
• proxy la solicitud una vez que el modelo está listo

Para una configuración práctica, consulta la rápida iniciación de llama-swap.

Diferencia clave

Cuándo usar llama-swap

llama-swap te da aislamiento a nivel de proceso por modelo, lo que significa que un fallo en una instancia de modelo no afecta a las otras. También permite que cada modelo se ejecute con banderas de llama-server completamente independientes.

Úsalo si necesitas:

• mejor control de ciclo de vida y aislamiento
• lógica de cambio más inteligente con timeouts de inactividad configurables
• latencia más predecible (cada modelo tiene un proceso cálido después de la primera carga)
• estabilidad de producción hoy, no en el futuro

Cuándo el modo router nativo es suficiente

Usa el router integrado si quieres:

• cero dependencias externas
• un solo proceso para gestionar
• despliegue más simple (un binario, un archivo de configuración)
• stack mínimo para desarrollo o configuraciones de usuario único

Pensamientos finales

El modo router es un paso significativo hacia adelante para llama-server.

Responde a la demanda de larga data:

¿Qué es el modo router en el servidor llama.cpp?

Es la capa faltante que convierte un binario estático en un servicio de inferencia dinámico — un proceso que puede atender solicitudes para un catálogo entero de modelos.

Pero no está terminado.

Hoy es:

• lo suficientemente poderoso para cargas de trabajo reales
• prometedor como base para enrutamiento más sofisticado
• ligeramente áspero en los bordes de configuración y estabilidad

Si tu carga de trabajo es predecible y puedes agrupar solicitudes por modelo, el modo router funciona bien hoy. Si necesitas fiabilidad de grado de producción y aislamiento por modelo, acude a llama-swap mientras la implementación nativa madura.

Cuando necesites liberar VRAM sin reiniciar — para una ejecución de benchmark, una ventana de mantenimiento o un reinicio limpio de desarrollo — el enfoque scriptable es listar los modelos cargados y llamar al endpoint de descarga para cada uno. El patrón completo de curl y jq está cubierto en Descargar Todos los Modelos Router de llama.cpp Sin Reiniciar.

De cualquier manera, obtienes comportamiento similar a Ollama, sin ocultar los mecanismos.