Llama-Server Router-modus - Dynamisch wisselen van modellen zonder herstart

Lang bestond er een opvallende beperking in llama.cpp: je kon slechts één model per proces hosten, en overschakelen betekende een herstart.

Die tijd is voorbij.

Recente updates hebben router-modus geïntroduceerd in llama-server, wat dicht bij komt in de buurt van wat mensen verwachten van moderne lokale LLM-runtime-omgevingen:

• dynamisch laden van modellen
• op verzoek ontladen
• per verzoek overschakelen
• geen herstart van het proces

Met andere woorden: Ollama-achtig gedrag, maar zonder de steuntjes.

Als je nog twijfelt tussen lokale runtimes, cloud-API’s en self-hosted infrastructuur, is het overzicht van LLM-hosting een goed startpunt.

Vereisten

Router-modus vereist een recente llama-server-build — ruwweg na medio 2024. Oudere builds hebben de vlaggen --models-preset of --models-dir niet.

Voor installatieopties (pakketbeheer, vooraf gecompileerde binaries of volledige broncode-build met CUDA), zie de llama.cpp quickstart.

Zodra je llama-server hebt, bevestig dan of je build router-modus ondersteunt:

llama-server --help | grep -i models

Als --models-preset of --models-dir verschijnt, ben je klaar. Als ze afwezig zijn, update dan naar een nieuwere build.

Mijn huidige output van help-berichten gerelateerd aan modellen:

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

Wat router-modus eigenlijk doet

Router-modus maakt van llama-server een modeldispatcher.

In plaats van te binden aan één model via -m, doet de server het volgende:

• start zonder geladen model
• ontvangt een verzoek waarin een model wordt benoemd
• laadt dat model als het nog niet in het geheugen staat
• voert inferentie uit
• laadt het model optioneel na de respons uit, of houdt het warm voor het volgende verzoek

Het kernidee

Je voert niet langer het volgende uit:

./llama-server -m model.gguf

Je voert dit uit:

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

En laat de server beslissen wat en wanneer te laden, op basis van wat de client daadwerkelijk vraagt.

Dit is belangrijk omdat het betekent dat één persistent proces een hele vloot van modellen kan hosten, waarbij clients het juiste model per taak selecteren — een coderingsmodel, een chatmodel, een samenvattingsmodel — zonder enige coördinatielast aan jouw kant.

Configuratie: je modellen definiëren

Hier zijn de dingen nog een beetje ruw.

Er is nog geen volledig stabiel officieel formaat, maar recente builds ondersteunen INI-stijl modeldefinities via een configuratiebestand.

Voorbeeld 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

Elke sectienaam wordt de modelidentificatie die clients gebruiken in het "model"-veld van hun API-verzoeken.

Belangrijkste configuratieparameters

Het kiezen van de juiste ngl-waarde hangt af van de beschikbare VRAM van je GPU — voor GPU-selectie en hardware-economie is de compute-hardwaregids een nuttige referentie. Om het live VRAM-verbruik te bekijken tijdens het afstellen, zie de GPU-monitoringtools voor Linux.

De server starten met configuratie

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

Bevestig dat de server correct is gestart:

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

Je zou elke sectienaam uit je models.ini als model-ID moeten zien.

Een opmerking over stabiliteit

De INI-configuratiesinterface is nog steeds in ontwikkeling:

• vlaggen kunnen tussen commits veranderen
• sommige parameters worden alleen herkend door specifieke buildconfiguraties
• documentatie hinkt achter de implementatie aan

Pin op een specifieke llama.cpp-commit als je reproduceerbaarheid nodig hebt over herstarts heen.

API-gebruik: modellen overschakelen op verzoek

Zodra de server draait, gebeurt het wisselen van modellen via de standaard OpenAI-compatibele API. Je stelt simpelweg het "model"-veld in.

Geregistreerde modellen weergeven

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

Voltooiingsverzoek — eerste model

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

Overschakelen naar een ander model — zelfde eindpunt, zelfde poort

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

De server behandelt de ontladen-/laadcyclus transparant. Je clientcode verandert niet — alleen het model-veld.

Python-voorbeeld

Als je de openai Python-client gebruikt:

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)

Wat er intern gebeurt

Wanneer een verzoek aankomt voor qwen en llama3 momenteel geladen is:

1. llama3 wordt uit de VRAM geladen
2. qwen-gewichtens worden van de schijf gelezen en in de VRAM geladen
3. inferentie wordt uitgevoerd
4. het volgende verzoek bepaalt of qwen geladen moet blijven of opnieuw gewisseld moet worden

Dit beantwoordt direct de veelgestelde vraag:

Hoe kan een lokale LLM-server van model wisselen zonder te herstarten?

Door modellen dynamisch per verzoek te laden, in plaats van bij het opstarten te binden.

Systemd-service: productieklare setup

Maak een dedicated gebruiker en mappen aan

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

Kopieer je binary en modelconfiguratie op de juiste plek:

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

Inschakelen en starten

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

Verifiëren en logs inspecteren

sudo systemctl status llama-server

journalctl -u llama-server -f

Bij een succesvolle start zie je regels die aangeven dat de server luistert en het modelregister is geladen. Een snelle gezondheidscheck:

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

Nu heb je een persistente service met automatische herstart en gecentraliseerd modelwisselen — geen handmatig procesbeheer meer nodig. Als je hetzelfde patroon wilt toepassen op andere binaries, gaat elk uitvoerbaar bestand als Linux-service hosten in op de algemene aanpak.

De llama-server --metrics-vlag exposeert een Prometheus-compatibel eindpunt. Voor llama.cpp-specifieke dashboards, PromQL-query’s en alertrules, zie de LLM-inferentiemonitoringgids. Voor de bredere observabiliteitsopstelling dekt de observabiliteitsgids de volledige stack.

Beperkingen die je moet begrijpen

Router-modus is echt nuttig, maar het brengt afwegingen met zich mee die je duidelijk moet hebben voordat je er in productie op vertrouwt.

Alleen één model in het geheugen op een moment

Hoewel er meerdere modellen in models.ini zijn gedefinieerd, is op elk moment slechts één resident in de VRAM per worker. Wisselen betekent een volledige ontladen- en herlaadcyclus.

• wisselen betekent herladen
• een latentiepiek is onvermijdelijk
• bij een typisch 7B-model op Q5 kan een herladen 3–10 seconden duren, afhankelijk van de schijfsnelheid en VRAM-bandbreedte

Dit beantwoordt nog een belangrijke vraag:

Ondersteunt llama.cpp het hosten van meerdere modellen tegelijk?

Niet echt. Het ondersteunt meerdere definities, niet gelijktijdige residentie. Als je twee modellen echt parallel geladen nodig hebt, heb je twee processen op twee aparte GPUs nodig.

Voor gemeten VRAM-verbruik en tokens-per-second over modelgroten heen, dekt de LLM-prestatiebenchmarks het volledige beeld. Voor nummers specifiek voor llama.cpp op een GPU van 16 GB — dense en MoE-modellen op meerdere contextgroten — zie de 16 GB VRAM llama.cpp-benchmarks.

Geen slimme caching

In tegenstelling tot Ollama, die een warme pool onderhoudt en modellen verwijdert op basis van recentheid:

• er is geen automatische modelverwijderingsstrategie
• geen achtergrondvoorspoeling
• geen prioriteitswachtrij voor veelgebruikte modellen

Als je afwisselend verzoeken stuurt voor llama3 en mistral, activeert elk enkel verzoek een herladen. Dit is de fundamentele kosten van dichter bij de metal zijn.

Latentie is onvoorspelbaar voor gemengde workloads

Een goedgedragde workload die consistent één model gebruikt, zal snel zijn. Een workload die meerdere modellen afwisselt, zal traag zijn. Plan je clientrouterlogica dienovereenkomstig — groepeer verzoeken per model waar mogelijk.

Configuratie is niet stabiel

De INI-ondersteuning bestaat en werkt in de meest recente builds, maar het is niet volledig gestandaardiseerd. Vlaggen en parameternamen zijn tussen versies veranderd. Als je llama-server upgradet, test dan je models.ini tegen de nieuwe build voordat je deployt.

Llama.cpp vs Ollama: eerlijke vergelijking

Een mening

Kies voor llama.cpp router-modus als je wilt:

• maximale controle over runtime-parameters per model
• minimale procesoverhead
• directe toegang tot llama.cpp-vlaggen zonder abstractielaag
• een hackbare basis voor aangepaste tooling

Kies voor Ollama als je wilt:

• een stabiele, gepolijste ervaring
• automatisch downloaden en versioneren van modellen
• slimme keep-alive en verwijdering zonder configuratie
• alles-inbegrepen vanaf dag één

Geen van beide is fout. De keuze hangt af van hoeveel je zelf wilt beheren.

Als je voor Ollama kiest, dekt de Ollama CLI-cheatsheet de dagelijkse commando’s. Voor een bredere vergelijking die ook vLLM, LM Studio en LocalAI omvat, zie hoe verschillende lokale runtimes in 2026 met elkaar vergelijken.

Llama.cpp vs llama-swap

llama-swap is een externe orchestrator die voor één of meer llama-server-instanties staat:

• het onderschept verzoeken en inspecteert het model-veld
• het start het passende llama-server-proces voor dat model
• het stopt inactieve instanties na een configureerbare timeout
• het proxyt het verzoek door zodra het model klaar is

Voor een praktische setup, zie de llama-swap quickstart.

Belangrijkste verschil

Wanneer je llama-swap moet gebruiken

llama-swap geeft je procesniveau-isolatie per model, wat betekent dat een crash in één modelinstantie de anderen niet beïnvloedt. Het laat ook elk model draaien met volledig onafhankelijke llama-server-vlaggen.

Gebruik het als je nodig hebt:

• betere levenscycluscontrole en isolatie
• slimmere wissellogica met configureerbare idle-timeouts
• voorspelbaardere latentie (elk model heeft een warm proces na eerste laden)
• productiestabiliteit vandaag, niet uiteindelijk

Wanneer native router-modus voldoende is

Gebruik de ingebouwde router als je wilt:

• zero externe afhankelijkheden
• één proces te beheren
• eenvoudigere deploy (één binary, één configbestand)
• minimale stack voor dev of single-user setups

Slotgedachten

Router-modus is een zinvolle stap vooruit voor llama-server.

Het beantwoordt de lang bestaande vraag:

Wat is router-modus in de llama.cpp-server?

Het is de ontbrekende laag die van een statische binary een dynamische inferentieservice maakt — één proces dat verzoeken voor een heel catalogus van modellen kan afhandelen.

Maar het is niet af.

Vandaag is het:

• krachtig genoeg voor echte workloads
• belovend als fundament voor meer geavanceerde routing
• iets ruw aan de randen van configuratie en stabiliteit

Als je workload voorspelbaar is en je verzoeken per model kunt groeperen, werkt router-modus vandaag goed. Als je productiekwaliteit betrouwbaarheid en isolatie per model nodig hebt, ga dan voor llama-swap terwijl de native implementatie rijpt.

Als je VRAM vrij wilt maken zonder te herstarten — voor een benchmarkrun, een onderhoudsvenster of een schone ontwikkelingsreset — is de scriptbare aanpak om geladen modellen te lijsten en het unload-eindpunt voor elk aan te roepen. Het volledige curl-en-jq-patroon wordt behandeld in Alle llama.cpp-routermodellen ontladen zonder herstart.

In ieder geval krijg je Ollama-achtig gedrag, zonder de werking te verbergen.