Llama-Server-routarläge – dynamisk modellbytte utan omstarter

En lång tid hade llama.cpp en uppenbar begränsning:
du kunde bara servera en modell per process, och byte innebar ett omstart.

Den eran är över.

Nyligen uppdateringar introducerade router-läge i llama-server, vilket tar oss mycket närmare det folk förväntar sig från moderna lokala LLM-körare:

• dynamisk modellladdning
• urladdning vid behov
• byte per förfrågan
• ingen processomstart

Med andra ord: Ollama-likt beteende, men utan träningshjulen.

Om du fortfarande bestämmer dig mellan lokala körare, moln-API:er och självhostad infrastruktur, är översikten över LLM-hosting en bra startpunkt.

Förutsättningar

Router-läge kräver en nyare llama-server-build – ungefär efter mitten av 2024. Äldre builds har inte --models-flaggan.

För installationsalternativ (paketmanager, förkompileringar eller full källkodskompilering med CUDA), se llama.cpp snabbstart.

När du har llama-server, bekräfta att din build stöder router-läge:

llama-server --help | grep -i models

Om --models-flaggan syns, är du redo. Om den saknas, uppdatera till en nyare build.

Min nuvarande utdata för modeller-relaterad hjälp:

-cl,   --cache-list                     visa lista över modeller i cachen
                                        Prefix/Suffix/Middle) som vissa modeller föredrar detta. (standard: inaktiverat)
                                        modeller med dynamisk lösning (standard: läs från modell)
                                        modeller med dynamisk lösning (standard: läs från modell)
                                        inbäddningsmodeller (standard: inaktiverat)
--models-dir PATH                       katalog som innehåller modeller för router-servern (standard: inaktiverat)
                                        (env: LLAMA_ARG_MODELS_DIR)
--models-preset PATH                    sökväg till INI-fil som innehåller modellförinställningar för router-servern
                                        (env: LLAMA_ARG_MODELS_PRESET)
--models-max N                          för router-servern, maximalt antal modeller att ladda samtidigt
                                        (env: LLAMA_ARG_MODELS_MAX)
--models-autoload, --no-models-autoload
                                        för router-servern, om modeller ska laddas automatiskt (standard:
                                        (env: LLAMA_ARG_MODELS_AUTOLOAD)

Vad router-läge egentligen gör

Router-läge gör llama-server till en modell-dispatcher.

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

• startar utan laddad modell
• mottar en förfrågan som namnger en modell
• laddar den modellen om den inte redan finns i minnet
• kör inferens
• valfritt urladdar modellen efter svaret eller håller den varm för nästa förfrågan

Nyckelideen

Du kör inte längre:

./llama-server -m model.gguf

Du kör:

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

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

Detta är viktigt eftersom det innebär att en enda bestående 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 samordningsoverhead på din sida.

Konfiguration: definiera dina modeller

Här är sakerna fortfarande lite råa.

Det finns ingen helt stabil officiell format ännu, men nuvarande builds stöder 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 sektionens namn blir modell-identifikatorn som klienter använder i "model"-fältet i sina API-förfrågningar.

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 guide för beräkningshårdvara en användbar referens. För att övervaka live VRAM-förbrukning medan du justerar, se GPU-övervakningsverktyg för Linux.

Starta servern med konfiguration

./llama-server --models /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 sektionens namn från din models.ini listad som en modell-ID.

En notering om stabilitet

INI-konfigurationsgränssnittet är fortfarande i utveckling:

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

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

API-användning: byt modeller vid förfrågan

När servern är igång, sker modellbyte genom det standardiserade OpenAI-kompatibla API:t. Du sätter helt enkelt "model"-fältet.

Lista registrerade modeller

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

Fullständig förfrågan – första modellen

curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama3",
    "messages": [
      {"role": "user", "content": "Förklara router-läge i en paragraf"}
    ]
  }'

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": "Skriv en Python-funktion som läser en CSV-fil"}
    ]
  }'

Servern hanterar urladdnings/laddningscykeln transparent. Din klientkod ändras inte – bara model-fältet.

Python-exempel

Om du använder openai Python-klienten:

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": "Skriv en Go HTTP-hanterare"}],
)
print(response.choices[0].message.content)

# Byt till chattmodellen – samma klient, annat modellnamn
response = client.chat.completions.create(
    model="llama3",
    messages=[{"role": "user", "content": "Vad är huvudstaden i Australien?"}],
)
print(response.choices[0].message.content)

Vad som händer internt

När en förfrågan kommer för qwen och llama3 är laddad just nu:

1. llama3 urladdas från VRAM
2. qwen-vikt läses från disk och laddas in i VRAM
3. inferens körs
4. nästa förfrågan bestämmer om qwen ska hållas laddad eller bytas igen

Detta svarar direkt på den vanliga frågan:

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

Genom dynamisk modellladdning per förfrågan, inte bindning 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 /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 ser du raderna som indikerar att servern lyssnar och modellregistret har laddats. En snabb hälsokontroll:

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

Nu har du en bestående tjänst med automatisk omstart och centraliserad modellbyte – ingen manuell processhantering krävs. Om du vill applicera samma mönster på andra binärer, hosta vilken exekverbar som en Linux-tjänst går igenom den generella metoden.

llama-server --metrics-flaggan exponerar en Prometheus-kompatibel endpoint. För llama.cpp-specifika instrumentpaneler, PromQL-frågor och larmregler, se guide för LLM-inferensövervakning. För den bredare observabilitetsuppsättningen, täcker observabilitetsguiden hela stacken.

Begränsningar du behöver förstå

Router-läge är genuint användbart, men det medför avvägningar du bör vara tydlig med innan du förlitar dig på det i produktion.

Endast en modell i minnet åt gången

Även om flera modeller är definierade i models.ini, är bara en bosatt i VRAM per worker vid varje tidpunkt. Byte innebär en full urladdning-och-laddningscykel.

• byte innebär omladdning
• latensspets är oundviklig
• på en typisk 7B-modell vid Q5 kan en omladdning ta 3–10 sekunder beroende på diskhastighet och VRAM-bandbredd

Detta svarar på en annan nyckelfråga:

Stöder llama.cpp att servera flera modeller samtidigt?

Inte riktigt. Det stöder flera definitioner, inte samtidig bosättning. Om du behöver två modeller genuint laddade parallellt, behöver du två processer på två separata GPU:er.

För mätt VRAM-förbrukning och token-per-sekund över modellstorlekar, täcker LLM-prestandabenchmarks hela bilden. För siffror specifika för llama.cpp på en 16 GB GPU – täta och MoE-modeller vid flera kontextstorlekar – se 16 GB VRAM llama.cpp benchmarks.

Ingen smart cache

Till skillnad från Ollama, som underhåller en varm pool och utvisar modeller baserat på nyhet:

• det finns ingen automatisk modellutvisningsstrategi
• ingen bakgrunds-förvarmning
• ingen prioriteringskö för ofta använda modeller

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

Latens är opålitlig för blandade arbetsbelastningar

En väluppfostrad arbetsbelastning som använder en modell konsekvent kommer vara snabb. En arbetsbelastning som väv flera modeller kommer vara långsam. Planera din klientroutningslogik därefter – gruppera förfrågningar per modell där möjligt.

Konfiguration är inte stabil

INI-stödet finns och fungerar i de flesta 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

Åsiktsbildad syn

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

• maximal kontroll över körparametrar per modell
• minimal processöverhead
• direkt tillgång till llama.cpp-flaggor utan abstraktionslager
• en hackbar bas för skräddarsydd verktyg

Välj Ollama när du vill ha:

• en stabil, polerad upplevelse
• automatisk modelldownloading och versionering
• smart keep-alive och utvisning utan konfiguration
• batterier inkluderade från dag ett

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

Om du går med Ollama, täcker Ollama CLI-cheklista dagliga kommandon. För en bredare jämförelse som också inkluderar vLLM, LM Studio och LocalAI, se hur olika lokala körare jämförs 2026.

Llama.cpp vs llama-swap

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

• det intercepterar förfrågningar och inspekterar model-fältet
• det startar lämplig llama-server-process för den modellen
• det stänger av inaktiva instanser efter en konfigurerbar timeout
• det proxyar förfrågan igenom när modellen är redo

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

Nyckelskillnad

När ska du 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öra med helt oberoende llama-server-flaggor.

Använd det om du behöver:

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

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ändaruppsättningar

Sista tankar

Router-läge ä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 den saknade lagret som gör en statisk binär till en dynamisk inferensservice – en enda process som kan hantera förfrågningar för en hel katalog av modeller.

Men det är inte färdigt.

Idag är det:

• tillräckligt kraftfullt för verkliga arbetsbelastningar
• lovande som en grund för mer sofistikerad routing
• lite råa vid kanterna för konfiguration och stabilitet

Om din arbetsbelastning är förutsägbar och du kan gruppera förfrågningar per modell, fungerar router-läge bra idag. Om du behöver produktionsklass pålitlighet och per-modell-isolation, använd llama-swap medan den inbyggda implementeringen mognar.

Oavsett vilket, får du Ollama-likt beteende, utan att gömma maskineriet.