Llama-Server-routermodus: dynamisch wisselen van modellen zonder herstart

Lang had llama.cpp een opvallende beperking:
je kon slechts één model per proces bedienen, en om te wisselen moest je herstarten.

Die tijd is voorbij.

Recente updates brachten router-modus in llama-server, wat veel dichter komt bij wat mensen verwachten van moderne lokale LLM-runtime-omgevingen:

• dynamisch laden van modellen
• op vraag uitladen
• wisselen per verzoek
• geen procesherstart nodig

Met andere woorden: gedrag zoals Ollama, maar zonder de trainingswieltjes.

Als je nog steeds twijfelt tussen lokale runtime-omgevingen, cloud-API’s en zelfgehoste infrastructuur, is de
overzicht LLM-hosting een goed startpunt.

Vereisten

Router-modus vereist een recente llama-server-build – ongeveer na het midden van 2024. Oudere builds hebben de --models-vlag niet.

Voor installatie-opties (pakketbeheerder, vooraf gebouwde binaire bestanden of volledige broncode-build met CUDA), zie de
llama.cpp quickstart.

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

llama-server --help | grep -i models

Als de --models-vlag verschijnt, ben je klaar. Als deze ontbreekt, update dan naar een nieuwere build.

Mijn huidige output van help-berichten met betrekking tot 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 model-dispatcher.

In plaats van te binden aan één model via -m:

• start de server zonder geladen model
• ontvangt een verzoek dat een model noemt
• laadt dat model indien het nog niet in het geheugen zit
• voert inferentie uit
• laadt het model optioneel na het antwoord uit, of houdt het warm voor het volgende verzoek

Het kernidee

Je voert niet langer dit uit:

./llama-server -m model.gguf

Je voert dit uit:

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

En laat de server beslissen wat er geladen moet worden en wanneer, op basis van wat de client daadwerkelijk vraagt.

Dit is belangrijk omdat het betekent dat één persistent proces een volledig vloot van modellen kan bedienen, waarbij clients de juiste voor elke taak selecteren – een model voor coderen, een chatmodel, een samenvatmodel – zonder enige coördinatie-overhead aan jouw kant.

Configuratie: definieer je modellen

Hier zijn de dingen nog een beetje rauw.

Er is nog geen volledig stabiele officiële indeling, 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 model-identificator die clients gebruiken in het "model"-veld van hun API-verzoeken.

Belangrijke 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 gids voor compute-hardware een nuttige referentie. Om live VRAM-gebruik te bewaken terwijl je het instelt, zie de GPU-monitoring tools voor Linux.

De server starten met configuratie

./llama-server --models /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 moeten zien opgesomd als een model-ID.

Een opmerking over stabiliteit

De INI-configuratie-interface is nog in ontwikkeling:

• vlaggen kunnen veranderen tussen commits
• sommige parameters worden alleen herkend door specifieke build-configuraties
• documentatie loopt achter op de implementatie

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

API-gebruik: modellen wisselen per verzoek

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

Lijst met geregistreerde modellen

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": "Leg router-modus uit in één alinea"}
    ]
  }'

Wisselen naar een ander model – hetzelfde eindpunt, dezelfde poort

curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen",
    "messages": [
      {"role": "user", "content": "Schrijf een Python-functie die een CSV-bestand leest"}
    ]
  }'

De server behandelt de uitlaad-/laadcyclus transparant. Jouw 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")

# Gebruik het coderingsmodel
response = client.chat.completions.create(
    model="qwen",
    messages=[{"role": "user", "content": "Schrijf een Go HTTP-handler"}],
)
print(response.choices[0].message.content)

# Wissel naar het chatmodel – dezelfde client, andere modelnaam
response = client.chat.completions.create(
    model="llama3",
    messages=[{"role": "user", "content": "Wat is de hoofdstad van Australië?"}],
)
print(response.choices[0].message.content)

Wat er intern gebeurt

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

1. llama3 wordt uit VRAM geladen
2. qwen-gewichten worden van de schijf gelezen en in VRAM geladen
3. inferentie wordt uitgevoerd
4. het volgende verzoek bepaalt of qwen geladen blijft of weer gewisseld wordt

Dit beantwoordt direct een veelgestelde vraag:

Hoe kan een lokale LLM-server modellen wisselen zonder herstart?

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

Systemd-service: productie-klare configuratie

Maak een toegewijde 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 binaire bestand 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 /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 lijnen die aangeven dat de server luistert en dat het modelregister is geladen. Een snelle sanity check:

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

Nu heb je een persistent service met automatische herstart en gecentraliseerd modelwisselen – geen handmatig procesbeheer vereist. Als je hetzelfde patroon wilt toepassen op andere binaire bestanden, bespreekt elk uitvoerbaar bestand hosten als Linux-service de algemene aanpak.

De llama-server --metrics-vlag exposeert een Prometheus-compatibel eindpunt. Voor llama.cpp-specifieke dashboards, PromQL-query’s en alerting-regels, zie de LLM-inferentie monitoring gids. Voor de bredere observability-opstelling dekt de observability gids de volledige stack.

Beperkingen die je moet begrijpen

Router-modus is echt nuttig, maar het brengt afwegingen met zich mee waarvan je je bewust moet zijn voordat je er in productie op vertrouwt.

Alleen één model in het geheugen tegelijk

Ook al zijn er meerdere modellen gedefinieerd in models.ini, er is slechts één model resident in VRAM per worker op elk moment. Wisselen betekent een volledige uitlaad- en laadcyclus.

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

Dit beantwoordt nog een belangrijke vraag:

Ondersteunt llama.cpp het bedienen 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 GPU’s nodig.

Voor gemeten VRAM-gebruik en tokens-per-seconde over modelgroottes, dekt de LLM-prestatie benchmarks het volledige beeld. Voor cijfers specifiek voor llama.cpp op een GPU met 16 GB VRAM – dense en MoE-modellen op meerdere contextgroottes – zie de llama.cpp benchmarks voor 16 GB VRAM.

Geen slimme cache

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

• er is geen automatische modelverwijderingsstrategie
• geen voorverwarming op de achtergrond
• geen prioriteitswachtrij voor veelgebruikte modellen

Als je afwisselende verzoeken voor llama3 en mistral stuurt, activeert elk enkel verzoek een herlaad. Dit is de fundamentele prijs van dichter bij de metalen te zijn.

Latentie is onvoorspelbaar voor gemengde werklasten

Een goed gedragende werklast die consequent één model gebruikt, zal snel zijn. Een werklast die meerdere modellen afwisselt, zal traag zijn. Plan je client-routeringslogica dienovereenkomstig – groepeer verzoeken per model waar mogelijk.

Configuratie is niet stabiel

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

Llama.cpp vs Ollama: eerlijke vergelijking

Opinionated mening

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

• maximale controle over runtime-parameters per model
• minimaal procesoverhead
• directe toegang tot llama.cpp-vlaggen zonder abstractielagen
• een hackbare basis voor aangepaste hulpmiddelen

Kies voor Ollama als je wilt:

• een stabiele, gepolijste ervaring
• automatisch downloaden en versioneren van modellen
• slim keep-alive en verwijdering zonder configuratie
• batterijen inclusief vanaf dag één

Beide zijn niet verkeerd. De keuze hangt af van hoeveel je zelf wilt beheren.

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

Llama.cpp vs llama-swap

llama-swap is een externe orchestrator die voor één of meerdere llama-server-instanties zit:

• het onderschept verzoeken en inspecteert het model-veld
• het start het juiste llama-server-proces voor dat model
• het schakelt inactieve instanties uit na een configureerbare time-out
• het proxyt het verzoek door zodra het model klaar is

Voor een hands-on opstelling, zie de llama-swap quickstart.

Belangrijk verschil

Wanneer je llama-swap moet gebruiken

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

Gebruik het als je nodig hebt:

• betere levenscycluscontrole en isolatie
• slimmer wissellogica met configureerbare idle-time-outs
• voorspelbaarder latentie (elk model heeft een warm proces na de eerste laadbeurt)
• productiestabiliteit vandaag, niet later

Wanneer de ingebouwde router-modus voldoende is

Gebruik de ingebouwde router als je wilt:

• geen externe afhankelijkheden
• één proces te beheren
• eenvoudiger deploy (één binaire bestand, één configuratiebestand)
• minimale stack voor dev- of single-user-opstellingen

Eindgedachten

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

Het beantwoordt de langdurige vraag:

Wat is router-modus in llama.cpp server?

Het is de ontbrekende laag die van een statisch binaire bestand een dynamische inferentieservice maakt – één proces dat verzoeken voor een heel catalogus van modellen kan afhandelen.

Maar het is niet afgewerkt.

Vandaag is het:

• krachtig genoeg voor echte werklasten
• belovend als basis voor geavanceerdere routering
• iets ruw aan de randen van configuratie en stabiliteit

Als je werklast voorspelbaar is en je verzoeken per model kunt groeperen, werkt router-modus goed vandaag. Als je productie-gegradeerde betrouwbaarheid en per-model-isolatie nodig hebt, grijp dan naar llama-swap terwijl de native implementatie rijpt.

Op beide manieren krijg je gedrag zoals Ollama, zonder de machinerie te verbergen.