Llama-Server in modalità Router: commutazione dinamica dei modelli senza riavvii

Per molto tempo, llama.cpp ha avuto una limitazione evidente:
era possibile servire solo un modello per processo, e cambiare modello richiedeva un riavvio.

Quell’epoca è finita.

Le recenti introduzioni hanno portato la modalità router in llama-server, offrendo qualcosa di molto simile a ciò che ci si aspetta dai moderni runtime LLM locali:

• caricamento dinamico dei modelli
• scaricamento su richiesta
• cambio per singola richiesta
• nessun riavvio del processo

In altre parole: comportamento simile a Ollama, ma senza le rotelle.

Se state ancora decidendo tra runtime locali, API cloud e infrastruttura self-hosted, l' Panoramica sull’hosting LLM è un buon punto di partenza.

Prerequisiti

La modalità router richiede una build recente di llama-server — indicativamente successiva alla metà del 2024. Le build più vecchie non dispongono dei flag --models-preset o --models-dir.

Per le opzioni di installazione (package manager, binari precompilati o build completa da sorgenti con CUDA), consulta la Guida rapida a llama.cpp.

Una volta che hai llama-server, verifica che la tua build supporti la modalità router:

llama-server --help | grep -i models

Se --models-preset o --models-dir compaiono, sei a posto. Se sono assenti, passa a una build più recente.

Il mio output attuale per l’aiuto relativo ai modelli:

-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)

Cosa fa effettivamente la modalità router

La modalità router trasforma llama-server in un dispatcher di modelli.

Invece di legarsi a un singolo modello tramite -m, il server:

• parte senza alcun modello caricato
• riceve una richiesta che specifica un modello
• carica quel modello se non è già in memoria
• esegue l’inferenza
• opzionalmente scarica il modello dopo la risposta, oppure lo mantiene attivo per la richiesta successiva

L’idea chiave

Non stai più eseguendo:

./llama-server -m model.gguf

Stai eseguendo:

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

E lasci al server decidere cosa caricare e quando, in base a ciò che i clienti richiedono effettivamente.

Questo è importante perché significa che un singolo processo persistente può servire un’intera flotta di modelli, con i clienti che selezionano quello giusto per ogni compito — un modello per la programmazione, uno per la chat, uno per il riassunto — senza alcun overhead di coordinamento da parte tua.

Configurazione: definizione dei modelli

Qui le cose sono ancora un po’ grezze.

Non esiste ancora un formato ufficiale completamente stabile, ma le build attuali supportano definizioni di modelli in stile INI tramite un file di configurazione.

Esempio 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

Ogni nome di sezione diventa l’identificatore del modello che i clienti utilizzano nel campo "model" delle loro richieste API.

Parametri di configurazione chiave

La scelta del valore corretto per ngl dipende dalla VRAM disponibile della tua GPU — per la selezione della GPU e l’economia hardware, la guida all’hardware di calcolo è un utile riferimento. Per monitorare il consumo live di VRAM durante la configurazione, consulta gli strumenti di monitoraggio GPU per Linux.

Avvio del server con configurazione

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

Verifica che il server sia partito correttamente:

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

Dovresti vedere ogni nome di sezione del tuo models.ini elencato come ID modello.

Una nota sulla stabilità

L’interfaccia di configurazione INI è ancora in evoluzione:

• i flag potrebbero cambiare tra i commit
• alcuni parametri sono riconosciuti solo da specifiche configurazioni di build
• la documentazione è in ritardo rispetto all’implementazione

Fissa il commit specifico di llama.cpp se hai bisogno di riproducibilità tra i riavvii.

Uso dell’API: cambio modello su richiesta

Una volta che il server è in esecuzione, il cambio di modello avviene tramite l’API standard compatibile con OpenAI. Basta impostare il campo "model".

Elenca i modelli registrati

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

Richiesta di completamento — primo modello

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"}
    ]
  }'

Passa a un modello diverso — stesso endpoint, stessa porta

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"}
    ]
  }'

Il server gestisce il ciclo di scaricamento/caricamento in modo trasparente. Il codice del tuo client non cambia — solo il campo model.

Esempio in Python

Se stai usando il client Python openai:

from openai import OpenAI

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

# Usa il modello per la programmazione
response = client.chat.completions.create(
    model="qwen",
    messages=[{"role": "user", "content": "Write a Go HTTP handler"}],
)
print(response.choices[0].message.content)

# Passa al modello per la chat — stesso client, diverso nome modello
response = client.chat.completions.create(
    model="llama3",
    messages=[{"role": "user", "content": "What is the capital of Australia?"}],
)
print(response.choices[0].message.content)

Cosa succede internamente

Quando arriva una richiesta per qwen e llama3 è attualmente caricato:

1. llama3 viene scaricato dalla VRAM
2. i pesi di qwen vengono letti dal disco e caricati nella VRAM
3. viene eseguita l’inferenza
4. la richiesta successiva determina se mantenere qwen caricato o effettuare un altro scambio

Questo risponde direttamente alla domanda comune:

Come può un server LLM locale cambiare modello senza riavviarsi

Caricando dinamicamente i modelli per ogni richiesta, senza fissare il vincolo al momento dell’avvio.

Servizio Systemd: configurazione pronta per la produzione

Crea un utente dedicato e i directory

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 il tuo binario e la configurazione dei modelli nella posizione giusta:

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

Abilita e avvia

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

Verifica e ispeziona i log

sudo systemctl status llama-server

journalctl -u llama-server -f

In caso di avvio riuscito vedrai righe che indicano che il server è in ascolto e che il registro dei modelli è stato caricato. Un rapido controllo di sanity:

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

Ora hai un servizio persistente con riavvio automatico e cambio di modello centralizzato — non è necessaria la gestione manuale dei processi. Se vuoi applicare lo stesso pattern ad altri binari, Come ospitare qualsiasi eseguibile come servizio Linux illustra l’approccio generale.

Il flag --metrics di llama-server espone un endpoint compatibile con Prometheus. Per dashboard specifiche per llama.cpp, query PromQL e regole di allerta, consulta la guida al monitoraggio dell’inferenza LLM. Per la configurazione di osservabilità più ampia, la guida all’osservabilità copre lo stack completo.

Limitazioni da comprendere

La modalità router è genuinamente utile, ma comporta compromessi di cui dovresti essere chiaro prima di affidarsi ad essa in produzione.

Solo un modello in memoria alla volta

Anche se più modelli sono definiti in models.ini, solo uno è residente nella VRAM per worker in un dato momento. Il cambio implica un ciclo completo di scaricamento e ricaricamento.

• il cambio implica un ricaricamento
• il picco di latenza è inevitabile
• su un tipico modello 7B in Q5, un ricaricamento può richiedere 3–10 secondi a seconda della velocità del disco e della banda della VRAM

Questo risponde a un’altra domanda chiave:

llama.cpp supporta il servizio di più modelli contemporaneamente?

Non proprio. Supporta multiple definizioni, non residenza simultanea. Se hai bisogno di due modelli genuinamente caricati in parallelo, ti servono due processi su due GPU separate.

Per il consumo misurato di VRAM e i token al secondo su diverse dimensioni di modello, i benchmark sulle prestazioni LLM coprono l’intero quadro. Per i numeri specifici di llama.cpp su una GPU da 16 GB — modelli densi e MoE a diverse dimensioni di contesto — consulta i benchmark llama.cpp su 16 GB VRAM.

Nessuna cache intelligente

A differenza di Ollama, che mantiene un pool caldo ed espelle i modelli in base alla recentezza:

• non c’è una strategia automatica di espulsione dei modelli
• nessun pre-riscaldamento in background
• nessuna coda di priorità per i modelli usati frequentemente

Se invii richieste alternate per llama3 e mistral, ogni singola richiesta scatena un ricaricamento. Questo è il costo fondamentale dell’essere più vicini al ferro.

La latenza è imprevedibile per carichi misti

Un carico ben comportato che usa un modello in modo consistente sarà veloce. Un carico che interpola più modelli sarà lento. Pianifica la tua logica di routing client di conseguenza — raggruppa le richieste per modello dove possibile.

La configurazione non è stabile

Il supporto INI esiste e funziona nella maggior parte delle build recenti, ma non è completamente standardizzato. I flag e i nomi dei parametri sono cambiati tra le versioni. Se aggiorni llama-server, testa il tuo models.ini contro la nuova build prima del dispiegamento.

Llama.cpp vs Ollama

La modalità router riduce la vecchia differenza di ciclo di vita con Ollama — il caricamento dinamico e il cambio per richiesta esistono ora nativamente in llama-server — ma non la chiude. La gestione della memoria rimane di base (nessuna politica di espulsione, nessun pool caldo), la stabilità della configurazione è ancora sperimentale, e il passaggio tra due modelli diversi paga sempre un ciclo completo di scaricamento e ricaricamento rispetto al keep-alive basato su TTL di Ollama. In breve: la modalità router ti dà il massimo controllo e una base modificabile; Ollama ti dà un’esperienza più rifinita e opinata con meno da configurare.

Per la scomposizione a coppie completa — installazione, gestione dei modelli, posizionamento GPU, controllo della cache KV, API, prestazioni, modi di fallimento e trigger concreti per sceglierne uno o migrare tra di loro — consulta llama.cpp vs Ollama nel 2026, che è il confronto canonico tra i due runtime su questo sito.

Se scegli Ollama, la scheda rapida del CLI Ollama copre i comandi quotidiani. Per un confronto più ampio che include anche vLLM, LM Studio e LocalAI, consulta come si confrontano i diversi runtime locali nel 2026.

Llama.cpp vs llama-swap

llama-swap è un orchestratore esterno che si posiziona davanti a una o più istanze di llama-server:

• intercetta le richieste e ispeziona il campo model
• avvia il processo llama-server appropriato per quel modello
• spegne le istanze inattive dopo un timeout configurabile
• proxy la richiesta attraverso una volta che il modello è pronto

Per una configurazione pratica, consulta la guida rapida a llama-swap.

Differenza chiave

Quando usare llama-swap

llama-swap ti dà isolamento a livello di processo per modello, il che significa che un crash in un’istanza di un modello non influisce sugli altri. Permette anche a ciascun modello di funzionare con flag llama-server completamente indipendenti.

Usalo se hai bisogno di:

• migliore controllo del ciclo di vita e isolamento
• logica di switching più intelligente con timeout di inattività configurabili
• latenza più prevedibile (ogni modello ha un processo caldo dopo il primo caricamento)
• stabilità in produzione oggi, non in futuro

Quando la modalità router nativa è sufficiente

Usa il router integrato se vuoi:

• zero dipendenze esterne
• un singolo processo da gestire
• dispiegamento più semplice (un binario, un file di configurazione)
• stack minimale per sviluppi o configurazioni single-user

Considerazioni finali

La modalità router è un passo avanti significativo per llama-server.

Risponde alla richiesta di lunga data:

Cos’è la modalità router nel server llama.cpp

È lo strato mancante che trasforma un binario statico in un servizio di inferenza dinamico — un singolo processo in grado di gestire richieste per un intero catalogo di modelli.

Ma non è finita.

Oggi è:

• abbastanza potente per carichi reali
• promettente come base per routing più sofisticati
• leggermente grezzo ai bordi della configurazione e della stabilità

Se il tuo carico è prevedibile e puoi raggruppare le richieste per modello, la modalità router funziona bene oggi. Se hai bisogno di affidabilità di livello produzione e isolamento per modello, rivolgiti a llama-swap mentre l’implementazione nativa matura.

Quando hai bisogno di liberare VRAM senza riavviare — per una sessione di benchmark, una finestra di manutenzione o un reset pulito dello sviluppo — l’approccio scriptabile è elencare i modelli caricati e chiamare l’endpoint di scaricamento per ciascuno. Il pattern completo con curl e jq è coperto in Scarica tutti i modelli router llama.cpp senza riavviare.

In ogni caso, ottieni comportamento simile a Ollama, senza nascondere la meccanica.