Modo Router de Llama-Server: Cambio dinámico de modelos sin reinicios

Durante mucho tiempo, llama.cpp tenía una limitación evidente:
solo podías servir un modelo por proceso, y cambiar implicaba un reinicio.

Esa era ha terminado.

Las actualizaciones recientes introdujeron el modo enrutador (router mode) en llama-server, acercándose mucho más a lo que la gente espera de los entornos de ejecución locales modernos de LLM:

• 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 ruedas de entrenamiento.

Si aún estás decidiendo entre entornos de ejecución locales, APIs en la nube e infraestructura autoadministrada, el resumen de alojamiento de LLM es un buen punto de partida.

Requisitos previos

El modo enrutador requiere una compilación reciente de llama-server —aproximadamente posterior a mediados de 2024. Las compilaciones antiguas no tienen la bandera --models.

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

Una vez que tengas llama-server, confirma que tu compilación admite el modo enrutador:

llama-server --help | grep -i models

Si aparece la bandera --models, estás listo. Si no está presente, actualiza a una compilación más nueva.

Mi salida actual de ayuda relacionada con modelos:

-cl,   --cache-list                     show list of models in cache
                                        Prefix/Suffix/Middle) as some models prefer this. (default: disabled)
                                        models with dynamic resolution (default: read from model)
                                        models with dynamic resolution (default: read from model)
                                        embedding models (default: disabled)
--models-dir PATH                       directory containing models for the router server (default: disabled)
                                        (env: LLAMA_ARG_MODELS_DIR)
--models-preset PATH                    path to INI file containing model presets for the router server
                                        (env: LLAMA_ARG_MODELS_PRESET)
--models-max N                          for router server, maximum number of models to load simultaneously
                                        (env: LLAMA_ARG_MODELS_MAX)
--models-autoload, --no-models-autoload
                                        for router server, whether to automatically load models (default:
                                        (env: LLAMA_ARG_MODELS_AUTOLOAD)

Qué hace realmente el modo enrutador

El modo enrutador convierte llama-server en un distribuidor de modelos.

En lugar de vincularse a un único modelo mediante -m, el servidor:

• inicia 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 models.ini --port 8080

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

Esto importa porque significa que un proceso persistente puede servir a toda una flota de modelos, con clientes seleccionando el adecuado por tarea —un modelo de codificación, un modelo de chat, un modelo de resumen— sin ningún sobrecosto de coordinación de tu parte.

Configuración: definiendo tus modelos

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

Aún no hay un formato oficial completamente 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 correcto de ngl depende de la VRAM disponible de tu GPU —para la selección de GPU y economía del hardware, la guía de hardware de cómputo es una referencia útil. Para monitorear el consumo de VRAM en vivo mientras ajustas, consulta las herramientas de monitoreo de GPU para Linux.

Iniciar el servidor con configuración

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

Confirma que el servidor se inició 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 sigue evolucionando:

• las banderas pueden cambiar entre commits
• algunos parámetros solo son reconocidos por configuraciones de compilación específicas
• la documentación se retrasa respecto a la implementación

Fija un commit específico 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 ocurre a través de la API compatible con OpenAI. Simplemente estableces 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 cliente no cambia —solo el campo model.

Ejemplo en Python

Si usas el cliente de Python openai:

from openai import OpenAI

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

# Usar el modelo de codificación
response = client.chat.completions.create(
    model="qwen",
    messages=[{"role": "user", "content": "Write a Go HTTP handler"}],
)
print(response.choices[0].message.content)

# Cambiar al modelo de chat — mismo cliente, diferente nombre de modelo
response = client.chat.completions.create(
    model="llama3",
    messages=[{"role": "user", "content": "What is the capital of Australia?"}],
)
print(response.choices[0].message.content)

Qué ocurre internamente

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

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 cambiar de nuevo

Esto responde directamente a la pregunta común:

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

Cargando modelos dinámicamente por solicitud, no vinculando al inicio.

Servicio 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 la configuración del modelo 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 /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 que indican que el servidor está escuchando y que el registro de modelos se ha cargado. Una comprobación rápida de sentido común:

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

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

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

Limitaciones que necesitas entender

El modo enrutador es genuinamente útil, pero conlleva compensaciones sobre las que debes estar claro antes de confiar en él en producción.

Solo un modelo en memoria a la vez

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

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

Esto responde otra pregunta clave:

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

No realmente. Admite 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 modelo, los benchmarks de rendimiento de LLM 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 en 16 GB VRAM.

Sin caché inteligente

A diferencia de Ollama, que mantiene un grupo caliente y expulsa modelos basándose en la recencia:

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

Si envías solicitudes alternadas para llama3 y mistral, cada sola solicitud 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 consistentemente será rápida. Una carga de trabajo que entrelaza múltiples modelos será lenta. Planifica tu lógica de enrutamiento de cliente en consecuencia —agrupa solicitudes por modelo siempre que 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á completamente 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: comparación honesta

Opinión personal

Elige el modo enrutador de llama.cpp cuando quieras:

• control máximo sobre parámetros de tiempo de ejecución por modelo
• sobrecosto de proceso mínimo
• acceso directo a las banderas de llama.cpp sin capas de abstracción
• una base modificable para herramientas personalizadas

Elige Ollama cuando quieras:

• una experiencia estable y pulida
• descarga automática de modelos y versionado
• mantenimiento de conexión y expulsión inteligente sin configuración
• todo incluido desde el primer día

Ninguno es incorrecto. La elección depende de cuánto quieras gestionar tú mismo.

Si eliges Ollama, la hoja de trucos de la CLI de Ollama cubre los comandos diarios. Para una comparación más amplia que también incluye vLLM, LM Studio y LocalAI, consulta cómo se comparan diferentes entornos de ejecución locales en 2026.

Llama.cpp vs llama-swap

llama-swap es un orquestador externo que se sitúa frente a 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 tiempo de espera configurable
• proxya la solicitud una vez que el modelo está listo

Para una configuración práctica, consulta el Inicio rápido 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 los demás. 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 tiempos de espera inactivos configurables
• latencia más predecible (cada modelo tiene un proceso caliente después de la primera carga)
• estabilidad de producción hoy, no eventualmente

Cuándo el modo enrutador nativo es suficiente

Usa el enrutador integrado si quieres:

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

Reflexiones finales

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

Responde a la demanda de larga data:

¿Qué es el modo enrutador 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 todo un catálogo de modelos.

Pero no está terminado.

Hoy es:

• lo suficientemente potente para cargas de trabajo reales
• prometedor como base para un 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 enrutador funciona bien hoy. Si necesitas fiabilidad de grado de producción y aislamiento por modelo, usa llama-swap mientras la implementación nativa madura.

De cualquier manera, obtienes comportamiento tipo Ollama, sin ocultar la maquinaria.