Avladda alla llama.cpp-routermodeller utan att starta om

Routerläge för llama.cpp är en av de mest användbara förändringarna i llama-server på flera år. Det ger slutligen lokala aktörer av LLM (Large Language Models) något som liknar modellhanteringsupplevelsen som man förväntar sig från Ollama, samtidigt som det behåller den råa prestanda och den lågnivåkontroll som gör llama.cpp värd att använda i första hand.

Men det finns en vass kant: att avlasta allt är inte en enda magisk knapp i HTTP-API:t.

Routern kan lista modeller. Den kan ladda en modell. Den kan avlasta en modell. Den kan kasta ut den minst nyligen använda modellen när --models-max nås. Det som inte dokumenteras som en förstahandsändpunkt just nu är ett universellt anrop för avlasta alla modeller nu.

Det är inte ett verkligt hinder. Det korrekta mönstret är enkelt, explicit och skriptbart:

1. Fråga routern vilka modeller som finns.
2. Filtrera modellerna vars status är loaded (laddad).
3. Anropa /models/unload en gång per laddad modell.

Detta är den metod jag rekommenderar för seriösa [lokala LLM-arbetsflöden](https://www.glukhov.org/sv/llm-hosting/ “Komplett guide till LLM-hostning 2026. Jämför Ollama, vLLM, Docker Model Runner, LocalAI och molnleverantörer. Lär dig om kostnader, prestanda och infrastrukturkompromisser.). Det är tråkigt, synligt och enkelt att felsöka. Det är exakt vad du vill ha när ditt mål är att frigöra VRAM utan att starta om hela inferenstjänsten.

Vad routerläge i llama.cpp egentligen gör

I klassisk användning av llama-server startar du en server med en modell:

llama-server \
  --model ./models/qwen3-8b.gguf \
  --port 8080

Routerläget ändrar detta. Istället för att binda servern till en GGUF-fil, blir routern en koordinator för flera modeller. Den kan upptäcka modeller från en cache eller från en modellkatalog, ladda dem efter behov, routa förfrågningar till korrekt modell och avlasta modeller när det behövs.

En typisk start i routerläge ser ut så här:

llama-server \
  --models-dir ./models \
  --models-max 4 \
  --port 8080

Den viktiga parametern här är --models-max. Den styr hur många modeller som får vara laddade samtidigt. Om gränsen nås kan llama.cpp kasta ut den minst nyligen använda modellen. Det är användbart, men det är inte ett substitut för en medveten avlastningsoperation. LRU-kastning (Least Recently Used) är reaktiv. Ett avlastningsskript är operativ kontroll.

Min personliga åsikt: om du kör lokala modeller för riktigt arbete, bör du behandla routerläge som en inferensprocesshanterare, inte som en leksakschattserver. Explicita livscykeloperationer är viktiga.

De modellhanteringsändpunkter du behöver

Den huvudsakliga ändpunkten för upptäckt är:

curl -s http://localhost:8080/models | jq

Den ändpunkten returnerar modellerna som routern känner till och deras nuvarande livscykelstatus. Den exakta JSON-strukturen kan variera lite mellan byggen, så inspektera ditt eget svar innan du skriver automation.

En vanlig svarstruktur ser ut så här:

{
  "data": [
    {
      "id": "qwen3-8b",
      "status": "loaded"
    },
    {
      "id": "llama-3.2-3b",
      "status": "unloaded"
    }
  ]
}

För att avlasta en modell, anropa:

curl -s -X POST http://localhost:8080/models/unload \
  -H "Content-Type: application/json" \
  -d '{"model":"qwen3-8b"}' \
  | jq

Det är den primitiva operationen. Allt annat i denna artikel bygger på det.

Det finns ingen dokumenterad “avlasta alla”-ändpunkt

Detta är det som får folk att snubbla.

Du kanske förväntar dig något i stil med:

curl -X POST http://localhost:8080/models/unload-all

Bygg inte kring den antagningen. Den dokumenterade operationen är per modell. Du skickar en modellidentifierare till /models/unload, och llama.cpp avlastar den modellen.

Detta är inte nödvändvisvis dålig API-design. En per-modell-operation är säkrare. Den får anroparen att avgöra vad som ska avlastas. Den undviker också överraskande produktionsbeteende där en admin-förfrågan accidentally dödar varje varm modell som används av andra klienter.

För en arbetsstation skulle en “avlasta alla”-genväg vara bekväm. För en inferensbox med flera användare är explicita looper bättre.

Avlasta en modell först

Innan du automatiserar något, testa den exakta modellidentifieraren din router förväntar sig.

Lista först modellerna:

curl -s http://localhost:8080/models | jq

Välj en laddad modell från utmatningen, avlasta den sedan:

curl -s -X POST http://localhost:8080/models/unload \
  -H "Content-Type: application/json" \
  -d '{"model":"qwen3-8b"}' \
  | jq

Kontrollera modellistan igen:

curl -s http://localhost:8080/models | jq

Om modellstatusen ändras till unloaded (avlastad), är din ändpunkt, port och modellidentifierare korrekta.

Om det inte fungerar, gissa inte. Inspektera JSON-filen. Router-alias, GGUF-filnamn och modell-ID:n är ofta inte samma sträng.

Avlasta alla laddade modeller med curl och jq

När avlastningen av en enskild modell fungerar, är mönstret för “avlasta alla” bara ett skalloop.

Använd detta när ditt svar från /models har .data[].id och .data[].status:

curl -s http://localhost:8080/models \
| jq -r '.data[] | select(.status == "loaded") | .id' \
| while IFS= read -r model; do
    echo "Unloading: $model"
    curl -s -X POST http://localhost:8080/models/unload \
      -H "Content-Type: application/json" \
      -d "{\"model\":\"$model\"}" \
      | jq
  done

Detta är hela trickot. Det är inte glamouröst, men det har rätt form för en admin-operation:

• Den avlastar endast modeller som faktiskt är laddade.
• Den skriver ut vad den gör.
• Den misslyckas modell för modell istället för att dölja allt bakom en opak action.
• Den fungerar från cron, systemd-hooks, SSH eller CI-jobb.

Ett återanvändbart skript för produktionsbruk

För något du kör mer än två gånger, sluta kopiera och klistra in one-liners. Spara ett skript.

Skapa llama-router-unload-all.sh:

#!/usr/bin/env bash
set -euo pipefail

LLAMA_SERVER_URL="${LLAMA_SERVER_URL:-http://localhost:8080}"

models_json="$(curl -fsS "$LLAMA_SERVER_URL/models")"

loaded_models="$(printf '%s' "$models_json" \
  | jq -r '.data[] | select(.status == "loaded") | .id')"

if [ -z "$loaded_models" ]; then
  echo "No loaded models found."
  exit 0
fi

printf '%s\n' "$loaded_models" | while IFS= read -r model; do
  [ -z "$model" ] && continue

  echo "Unloading: $model"

  curl -fsS -X POST "$LLAMA_SERVER_URL/models/unload" \
    -H "Content-Type: application/json" \
    -d "{\"model\":\"$model\"}" \
    | jq

done

echo "Done. Current model state:"
curl -fsS "$LLAMA_SERVER_URL/models" | jq

Gör den körbar:

chmod +x llama-router-unload-all.sh

Kör den mot standardlokalservern:

./llama-router-unload-all.sh

Kör den mot en annan värd:

LLAMA_SERVER_URL=http://192.168.1.50:8080 ./llama-router-unload-all.sh

Detta är versionen jag faktiskt skulle behålla i en verktykatalog. Den använder curl -f så att HTTP-fel får skriptet att misslyckas, och den låter dig åsidosätta server-URL:n utan att redigera filen.

Anpassa skriptet till din JSON-struktur

Gå inte ut ifrån att varje llama.cpp-bygge returnerar exakt samma fält för evigt. Routerläge utvecklas fortfarande, och ditt bygge kan exponera en något annan JSON-struktur.

Börja med att inspektera svaret:

curl -s http://localhost:8080/models | jq

Skriptet använder detta filter:

jq -r '.data[] | select(.status == "loaded") | .id'

Om din modellidentifierare är i .name, ändra den till:

jq -r '.data[] | select(.status == "loaded") | .name'

Om din statusfält använder ett annat värde, justera filtret därefter. Principen är vad som betyder: välj laddade modeller, extrahera identifieraren som accepteras av /models/unload, och anropa sedan avlastning för var och en.

Varför modeller kan laddas igen efter att du avlastat dem

Detta är den vanligaste källan till förvirring.

Routerläget stödjer laddning efter behov. Om en klient skickar en chatkompletteringsförfrågan för en modell som för närvarande är avlastad, kan routern ladda den automatiskt igen.

Det innebär att denna sekvens är möjlig:

1. Du avlastar varje modell.
2. Open WebUI, ett testskript eller en agent skickar en förfrågan.
3. llama.cpp laddar den begärda modellen igen.
4. Du tror att avlastningen misslyckades, men det gjorde den inte.

Lösningen är operativ, inte teknisk. Stoppa klienttrafik först om ditt mål är att hålla VRAM fri.

Till exempel:

• Stoppa benchmarkskript.
• Pausa agenter och cron-jobb.
• Stäng eller koppla från Open WebUI-sessioner.
• Inaktivera hälsokontroller som accidental utför riktiga modellförfrågningar.

Avlastning är ingen brandvägg. Om klienter fortsätter att be om modeller, gör routerläge sitt jobb genom att servera dem.

Open WebUI och Eject-knappen

Open WebUI kan integreras med llama.cpp:s modellavlastningsstöd. När leverantören är konfigurerad som llama.cpp, kan Open WebUI visa laddad modellstatus och exponera en “Eject”-åtgärd för administratörer.

Under huven anropar den åtgärden Open WebUI:s egen avlastnings-API, som sedan anropar llama.cpp:s /models/unload-ändpunkt på den konfigurerade anslutningen.

Det är fint för manuell operation, men jag skulle fortfarande behålla skalskriptet. En UI-knapp är bekväm. Ett skript är granskbart, upprepbar och användbart på en headless-box kl. 02:00.

När man ska använda “avlasta alla”

Att avlasta varje laddad modell är användbart när du vill:

• Frigöra GPU-minne innan du startar en större modell.
• Återställa en utvecklingsbox utan att starta om llama-server.
• Förbereda för ett benchmark-löp med ett rent minnesläge.
• Dränera lokala inferensarbetsbelastningar före underhåll.
• Återhämta dig från en rörig session där för många modeller var “värmda”.

Det är inte rätt verktyg när aktiva användare är beroende av varma modeller. I det fallet, finjustera --models-max, använd medveten ruttning och låt LRU-kastning göra en del av jobbet. Om du behöver smartare timeout-baserad avlastning med livscykelkontroll per modell, är llama-swap en syftesbyggd proxy som lagar exakt det ovanpå varje llama-server-uppsättning.

Min regel är enkel: använd LRU för normalt tryck, använd explicit avlastning för operatörens avsikt.

Felsökning

Modellen ändpunkt returnerar 404

Du kanske inte kör en router-kapabel build, eller så anropar du fel port.

Kontrollera serverprocessen och tillgängliga alternativ:

llama-server --help | grep -i models

Testa sedan båda ändpunkterna:

curl -s http://localhost:8080/models | jq
curl -s http://localhost:8080/v1/models | jq

/v1/models-ändpunkten är den OpenAI-kompatibla modellistan. /models-ändpunkten är routermodellhanteringsändpunkten. De är relaterade, men de är inte samma sak.

jq är inte installerad

Installera den innan du skriptar JSON-parsning.

På Ubuntu eller Debian:

sudo apt-get update
sudo apt-get install jq

På macOS med Homebrew:

brew install jq

Avlastningsanropet returnerar ett fel

De flesta fel beror på att du skickar fel modellidentifierare. Använd den exakta identifieraren som returneras av /models, inte filnamnet du tror borde fungera.

Kontrollera också om ditt modellnamn innehåller citationstecken, snedstreck eller mellanslag. Skriptet ovan hanterar normala strängar bra, men ovanliga namn kan kräva noggrannare JSON-konstruktion.

För maximal säkerhet kan du bygga POST-kroppen med jq:

jq -n --arg model "$model" '{model: $model}'

En mer defensiv avlastningsloop skulle använda den kroppen istället för hand-escaped JSON.

VRAM frigörs inte omedelbart

Bekräfta först att modellstatusen ändrades. Kontrollera sedan om en annan förfrågan laddade den igen. Kom också ihåg att GPU-minnesverktyg kan ligga efter eller rapportera allokatorbeteende snarare än omedelbar applikationsnivåavsikt.

Den praktiska testen är enkel: stoppa trafik, avlasta modeller, lista modellstatus och inspektera sedan GPU-minnet. För mätt VRAM-användning över modellstorlekar och kontextfönster i llama.cpp, ger 16 GB VRAM llama.cpp benchmarkar konkreta siffror att sanity-checka mot.

En säkrare JSON-kroppversion

Om dina modellidentifierare innehåller ovanliga tecken, använd jq för att generera JSON-förfrågningskroppen:

curl -s http://localhost:8080/models \
| jq -r '.data[] | select(.status == "loaded") | .id' \
| while IFS= read -r model; do
    echo "Unloading: $model"
    body="$(jq -n --arg model "$model" '{model: $model}')"
    curl -s -X POST http://localhost:8080/models/unload \
      -H "Content-Type: application/json" \
      -d "$body" \
      | jq
  done

Detta är versionen att använda om dina modeller är namngivna med repository-stil identifierare, anpassade alias eller sökvägar.

Slutlig tanke

llama.cpp routerläge är ett stort steg framåt för lokala LLM-operationer. Det ger dig dynamisk laddning, modellväxling och minnesmedveten kastning utan att uppge llama-server direkt.

Men vänta inte på en perfekt “avlasta alla”-ändpunkt. Den rena lösningen finns redan: lista laddade modeller och avlasta dem en efter en.

Det mönstret är explicit. Det är skriptbart. Det fungerar över SSH. Det spelar fint med Open WebUI. Och viktigast av allt, det frigör VRAM utan att starta om routern.

För lokal AI-infrastruktur, det är exakt den typ av tråkig kontrollerbar yta du vill ha.