Llama-Server Router-läge – Dynamisk modellbyte utan omstart

I en längre tid hade llama.cpp en påtaglig begränsning:
du kunde bara servera en modell per process, och att byta krävde en omstart.

Den eran är över.

Senaste uppdateringarna introducerade router-läge i llama-server, vilket ger något som är mycket närmare det man förväntar sig från moderna lokala LLM-runtime-miljöer:

• dynamisk modellladdning
• avlastning vid behov
• byte per begäran
• ingen processomstart

Med andra ord: Ollama-liknande beteende, men utan barnstenarna.

Om du fortfarande funderar på vilken lokal runtime-miljö, moln-API eller egenhostad infrastruktur du ska välja, är översikten över LLM-hosting en bra startpunkt.

Förutsättningar

Router-läget kräver en nyare build av llama-server — ungefär efter mitten av 2024. Äldre builds har inte flaggorna --models-preset eller --models-dir.

För installationsalternativ (pakethanterare, förkompilera binärer eller full källkodsbuild med CUDA), se llama.cpp snabbstart.

När du har llama-server kontrollerar du att din build stödjer router-läge:

llama-server --help | grep -i models

Om --models-preset eller --models-dir visas är allt bra. Om de saknas, uppdatera till en nyare build.

Min nuvarande output för hjälp relaterad till modeller:

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

Vad router-läge egentligen gör

Router-läget gör llama-server till en modellomdirigerare.

Istället för att binda till en enda modell via -m, gör servern följande:

• startar utan någon laddad modell
• mottar en begäran som anger en modell
• laddar den modellen om den inte redan finns i minnet
• kör inferens
• laddar valfritt ur modellen efter svaret, eller behåller den varm för nästa begäran

Huvudidén

Du kör inte längre:

./llama-server -m model.gguf

Du kör:

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

Och låter servern bestämma vad som ska laddas och när, baserat på vad klienten faktiskt begär.

Detta är viktigt eftersom det innebär att en enda persistent process kan servera en hel flotta av modeller, där klienter väljer rätt modell per uppgift — en kodningsmodell, en chattmodell, en sammanfattningsmodell — utan någon koordinationsoverhead på din sida.

Konfiguration: definiera dina modeller

Här är saker och ting fortfarande lite råa.

Det finns inget helt stabilt officiellt format ännu, men aktuella builds stödjer INI-stil modelldefinitioner via en konfigurationsfil.

Exempel 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

Varje sektionsnamn blir modellidentifikatorn som klienter använder i fältet "model" i sina API-begäran.

Viktiga konfigurationsparametrar

Valet av rätt ngl-värde beror på din GPU:s tillgängliga VRAM — för GPU-val och hårdvaruekonomi är guiden för beräkningshårdvara en användbar referens. För att övervaka live-VRAM-användning medan du justerar, se verktyg för GPU-övervakning för Linux.

Starta servern med konfiguration

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

Bekräfta att servern startade korrekt:

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

Du bör se varje sektionsnamn från din models.ini listad som en modell-ID.

En notering om stabilitet

INI-konfigurationsgränssnittet är fortfarande under utveckling:

• flaggor kan ändras mellan commits
• vissa parametrar erkänns bara av specifika buildkonfigurationer
• dokumentationen hänger efter implementeringen

Lås till en specifik llama.cpp-commit om du behöver reproducerbarhet över omstarter.

API-användning: byt modeller vid begäran

När servern körs sker modellbyte via det standardiserade OpenAI-kompatibla API:t. Du ställer helt enkelt in fältet "model".

Lista registrerade modeller

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

Kompletteringsbegäran — första modellen

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

Byt till en annan modell — samma endpoint, samma port

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

Servern hanterar cykeln av avlastning/laddning transparent. Din klientkod ändras inte — endast model-fältet.

Python-exempel

Om du använder openai-klienten för Python:

from openai import OpenAI

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

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

# Byt till chattmodellen — samma klient, annat modellnamn
response = client.chat.completions.create(
    model="llama3",
    messages=[{"role": "user", "content": "What is the capital of Australia?"}],
)
print(response.choices[0].message.content)

Vad som händer internt

När en begäran kommer in för qwen och llama3 för närvarande är laddad:

1. llama3 laddas ur från VRAM
2. qwen-viktarna läses från disken och laddas in i VRAM
3. inferens körs
4. nästa begäran avgör om qwen ska behållas laddad eller bytas igen

Detta svarar direkt på den vanliga frågan:

Hur kan en lokal LLM-server byta modeller utan omstart?

Genom dynamiskt att ladda modeller per begäran, inte genom att binda vid start.

Systemd-tjänst: produktionsredo uppsättning

Skapa en dedikerad användare och kataloger

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

Kopiera din binär och modellkonfiguration på plats:

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

Aktivera och starta

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

Verifiera och inspektera loggar

sudo systemctl status llama-server

journalctl -u llama-server -f

Vid en lyckad start kommer du att se rader som indikerar att servern lyssnar och att modellregistret har laddats. En snabb sanity check:

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

Nu har du en persistent tjänst med automatisk omstart och centraliserat modellbyte — ingen manuell processhantering krävs. Om du vill tillämpa samma mönster på andra binärer, går guiden för att hosta valfri exekverbar fil som en Linux-tjänst igenom den generella metoden.

Flaggan --metrics för llama-server exponerar en Prometheus-kompatibel endpoint. För llama.cpp-specifika dashboard, PromQL-frågor och alarmeringsregler, se guiden för övervakning av LLM-inferens. För den bredare observability-uppsättningen täcker observability-guiden hela stacken.

Begränsningar du behöver förstå

Router-läget är genuint användbart, men det medför avvägningar som du bör vara medveten om innan du förlitar dig på det i produktion.

Endast en modell i minnet på en gång

Även om flera modeller definieras i models.ini, finns endast en i VRAM per worker vid varje given stund. Byte innebär en fullständig cykel av avlastning och omladdning.

• byte innebär omladdning
• en latensökning är oundviklig
• för en typisk 7B-modell vid Q5 kan en omladdning ta 3–10 sekunder beroende på hastighet för disk och VRAM-bandbredd

Detta svarar på en annan nyckelfråga:

Stödjer llama.cpp servering av flera modeller samtidigt?

Inte riktigt. Det stödjer flera definitioner, inte samtidig närvaro i minnet. Om du behöver två modeller genuint laddade parallellt behöver du två processer på två separata GPU:er.

För mätt VRAM-användning och tokens-per-sekund över olika modellstorlekar täcker LLM-prestandabenchmarkar det fulla spektrat. För siffror specifika för llama.cpp på en 16 GB GPU — täta och MoE-modeller vid flera kontextstorlekar — se llama.cpp-benchmarkar för 16 GB VRAM.

Ingen smart cachning

I motsats till Ollama, som underhåller en varm pool och evjerter modeller baserat på nylighet:

• det finns ingen automatisk strategi för modellavlastning
• ingen bakgrundsförvärmning
• ingen prioriteringskö för ofta använda modeller

Om du skickar växlande begäran för llama3 och mistral, utlöser varje enskild begäran en omladdning. Detta är den fundamentala kostnaden med att vara närmare hårdvaran.

Latens är oförutsägbar för blandade arbetsbelastningar

En väluppfostrad arbetsbelastning som använder en modell konsekvent kommer att vara snabb. En arbetsbelastning som väver samman flera modeller kommer att vara långsam. Planera din klientroutningslogik därefter — gruppera begäran per modell där möjligt.

Konfigurationen är inte stabil

INI-stödet finns och fungerar i de allra senaste builds, men det är inte helt standardiserat. Flaggor och parameternamn har ändrats över versioner. Om du uppgraderar llama-server, testa din models.ini mot den nya builden innan du distribuerar.

Llama.cpp vs Ollama: ärlig jämförelse

Tydligt ställd åsikt

Välj llama.cpp router-läge när du vill ha:

• maximal kontroll över runtime-parametrar per modell
• minimal processoverhead
• direkt åtkomst till llama.cpp-flaggor utan abstraktionslager
• en hackbar bas för anpassad verktygsmiljö

Välj Ollama när du vill ha:

• en stabil, polerad upplevelse
• automatisk modellnedladdning och versionering
• smart keep-alive och avlastning utan konfiguration
• allt ingått från dag ett

Varken är fel. Valet beror på hur mycket du vill hantera själv.

Om du väljer Ollama täcker Ollama CLI-snabbguide dagliga kommandon. För en bredare jämförelse som också inkluderar vLLM, LM Studio och LocalAI, se hur olika lokala runtime-miljöer jämförs 2026.

Llama.cpp vs llama-swap

llama-swap är en extern orkestrator som placeras framför en eller flera llama-server-instanser:

• den avlyssnar begäran och granskar model-fältet
• den startar lämplig llama-server-process för den modellen
• den stänger ner idle-instanser efter en konfigurerbar timeout
• den proxyar begäran igenom när modellen är redo

För en hands-on-uppsättning, se llama-swap snabbstart.

Nyckelskillnad

När man ska använda llama-swap

llama-swap ger dig processnivåisolation per modell, vilket innebär att en krasch i en modellinstans inte påverkar andra. Det låter också varje modell köras med helt oberoende llama-server-flaggor.

Använd det om du behöver:

• bättre livscykelkontroll och isolation
• smartare bytelogik med konfigurerbara idle-timeouts
• mer förutsägbar latens (varje modell har en varm process efter första laddningen)
• produktionsstabilitet idag, inte i framtiden

När inbyggt router-läge räcker

Använd den inbyggda routern om du vill ha:

• noll externa beroenden
• en enda process att hantera
• enklare distribution (en binär, en konfigurationsfil)
• minimal stack för utveckling eller enskilda användaruppställningar

Avslutande tankar

Router-läget är ett meningsfullt steg framåt för llama-server.

Det svarar på den långvariga efterfrågan:

Vad är router-läge i llama.cpp-servern?

Det är det saknade lagret som transformerar en statisk binär till en dynamisk inferenstjänst — en process som kan hantera begäran för en hel katalog av modeller.

Men det är inte färdigt.

Idag är det:

• kraftfullt nog för verkliga arbetsbelastningar
• lovande som grund för mer sofistikerad ruttning
• lite rått vid kanterna för konfiguration och stabilitet

Om din arbetsbelastning är förutsägbar och du kan gruppera begäran per modell, fungerar router-läget bra idag. Om du behöver produktionsgrad pålitlighet och per-modell isolation, vända dig till llama-swap medan den inbyggda implementeringen mognar.

När du behöver frigöra VRAM utan omstart — för en benchmarkkörning, ett underhållsfönster eller en ren utvecklingsåterställning — är det scriptbara tillvägassättet att lista laddade modeller och anropa avlastningsendpointen för var och en. Det fullständiga curl-och-jq-mönstret täcks i Avlasta alla llama.cpp router-modeller utan omstart.

På vilket sätt som helst får du Ollama-liknande beteende, utan att dölja mekanismerna.