Nyhet · llama.cpp · drift

llama.cpp 0.4.1 tar bort --mmap, --mlock och --direct-io – byt till --load-mode innan servern vägrar starta

Tre laddningsflaggor som länge bara varnade är nu borta ur argumenttolken. Ett startskript som fortfarande bär dem stoppar llama-server med error: invalid argument. Översättningen är entydig, men bevisa att bytet inte ändrade laddtid eller minne.

Av C. Leijon · Publicerad · Senast granskad · 8 min läsning

En svart, platt apparatlåda står på en mörk bänkskiva framför suddiga gardiner och en soffa; på frontplattan sitter ett runt metallvred med grön ljusring bredvid fyra små skåror, och till vänster ligger en lös svart plåt med tre små vippbrytare.
Tre separata brytare byts mot ett enda lägesvred: så kan du tänka på övergången från --mmap, --mlock och --direct-io till --load-mode.

llama.cpp v0.4.1 publicerades på GitHub den 14 september 2026 med raden ”Removed deprecated --mmap/--mlock/--direct-io args in favor of --load-mode” under Core changes. Ändringen kommer från pull request #28334, som mergades den 9 september 2026 och tar bort flaggorna helt ur den gemensamma argumenttolken. Det betyder att llama-server, llama-cli och llama-completion inte längre känner igen dem, och att llama-bench förlorar sina egna varianter -mmp och -dio.

Det du ska bevisa

Varje startskript, systemd-enhet, Docker-compose-fil och miljöfil som styr en llama.cpp-process bär antingen --load-mode eller LLAMA_ARG_LOAD_MODE med exakt det värde den gamla flaggan satte. Laddtid till /health och processens minne är mätta före och efter bytet med samma modellfil på samma maskin, och skillnaden är dokumenterad.

Flaggorna varnade redan – nu stoppar de starten

PR-diffen visar vad som togs bort. De tre flaggorna hade hjälptexten ”DEPRECATED in favor of --load-mode” och skrev en varning i loggen varje gång de användes, med hänvisning till vilket --load-mode-värde du skulle byta till. Så länge det bara var en varning fungerade gamla skript. Efter v0.4.1 finns flaggorna inte i tabellen över kända argument, och argumenttolken i common/arg.cpp svarar då med error: invalid argument: --mlock (eller vilken flagga det nu var) i stället för att starta.

Det är en drift-nyhet snarare än en modell-nyhet. Serverns kod, modellen och kvantiseringen är oförändrade; det som gått sönder är kontraktet mellan din konfiguration och binären. Just den sortens fel upptäcks helst innan en uppdatering rullas ut, vilket är hela poängen med att frysa det fungerande läget och uppdatera som en kontrollerad ändring.

Översättningen: vad de gamla flaggorna faktiskt satte

Byt inte till det värde som låter mest likt. Byt till det värde den borttagna handlaren satte, som står svart på vitt i PR-diffen. Tabellen är fullständig för de fem flaggor som togs bort ur common/arg.cpp.

Gammal flaggaSatte interntSkriv nu
--mlockLLAMA_LOAD_MODE_MLOCK--load-mode mlock
--mmapLLAMA_LOAD_MODE_MMAP--load-mode mmap
--no-mmapLLAMA_LOAD_MODE_NONE--load-mode none
--direct-io / -dioLLAMA_LOAD_MODE_DIRECT_IO--load-mode dio
--no-direct-io / -ndioLLAMA_LOAD_MODE_NONE--load-mode none

Två detaljer i tabellen är lätta att missa. För det första satte --mlock läget mlock, inte mmap+mlock. Vill du ha kombinationen är det ett nytt val, inte en översättning, och det ska mätas som ett nytt val. För det andra: hade ett skript både --mmap och --mlock var det inte ett kombinerat läge. Varje borttagen handlare skrev över samma fält, och varningen som togs bort i samma PR sade uttryckligen att bara den sista flaggan på kommandoraden gällde när --load-mode blandades med de gamla. Översätt alltså den flagga som stod sist, inte alla.

Hjälptexten för -lm, --load-mode MODE i arg.cpp anger standardvärdet auto och sex tillåtna värden. Citerade rakt av: auto är ”mmap, unless a device does not support it”, none är ”no special loading mode”, mmap är ”memory-map model (if mmap disabled, slower load but may reduce pageouts if not using mlock)”, mlock är ”force system to keep model in RAM rather than swapping or compressing”, mmap+mlock kombinerar de två och dio är ”use DirectIO if available”. Något annat värde avvisas med ”invalid value”. Orden ”if available” i dio betyder att läget kan falla tillbaka utan att du märker det i kommandoraden. Vad det faktiskt gör på din disk och ditt filsystem säger hjälptexten inget om, och det gör inte den här artikeln heller.

Sök igenom alla startytor, inte bara den du minns

Flaggorna kan ligga på fler ställen än i det skript du senast redigerade: en ExecStart-rad, en command:-lista i Docker-compose, ett alias, ett CI-jobb som kör llama-bench, eller en miljöfil. PR-diffen tar även bort README-raderna för de gamla miljövariablerna LLAMA_ARG_MMAP, LLAMA_ARG_MLOCK och LLAMA_ARG_DIO, så sök på dem också.

grep -rnE -- '--(no-)?mmap|--mlock|--(no-)?direct-io|(^|[^a-z])-n?dio([^a-z]|$)|-mmp([^a-z]|$)' \
  /etc/systemd/system /etc/default /opt/llama.cpp ~/.bashrc ~/bin ./docker-compose*.yml

grep -rnE 'LLAMA_ARG_(MMAP|MLOCK|DIO)\b' /etc/systemd/system /etc/default ./docker-compose*.yml ./.env*

Anpassa sökvägarna till din maskin. Målet är en lista över varje träff med filnamn och rad, inte en känsla av att ”det borde bara vara en”.

Byt i systemd och Docker-compose utan att ändra något annat

Gör bytet så att flaggan är den enda skillnaden. Exemplet är en systemd-enhet som körde med --mlock; allt utom laddningsflaggan är identiskt före och efter.

# Före (stoppar i v0.4.1)
[Service]
ExecStart=/opt/llama.cpp/build/bin/llama-server -m /srv/models/modell.gguf --mlock --port 8080

# Efter
[Service]
ExecStart=/opt/llama.cpp/build/bin/llama-server -m /srv/models/modell.gguf --load-mode mlock --port 8080

Föredrar du miljövariabler, till exempel i en EnvironmentFile eller i compose-filens environment:, heter variabeln LLAMA_ARG_LOAD_MODE och tar samma sex värden.

# Före (stoppar i v0.4.1)
services:
  llama:
    command: ["llama-server", "-m", "/models/modell.gguf", "--no-mmap", "--port", "8080"]

# Efter
services:
  llama:
    command: ["llama-server", "-m", "/models/modell.gguf", "--port", "8080"]
    environment:
      LLAMA_ARG_LOAD_MODE: "none"

Blanda inte de två vägarna för samma parameter. Serverns README säger att om både kommandoradsargumentet och miljövariabeln är satta så vinner argumentet. En kvarglömd --load-mode auto i ExecStart trumfar alltså tyst det mlock du satte i miljöfilen, och du får ett annat läge än du tror utan något felmeddelande.

Kontrollera version och hjälptext på maskinen som kör

Innan du mäter något: bekräfta vilken binär som faktiskt startar. llama-server --version skriver version och bygginformation, och llama-server --help listar de argument just den binären känner till. Om --load-mode saknas i hjälpen är binären äldre än refaktoreringen och då gäller inte den här artikeln ännu.

llama-server --version
llama-server --help | grep -A7 -- '--load-mode'

Kör du flera byggen parallellt, exempelvis ett självbyggt och ett från en paketkälla, ska kontrollen göras per bygge. Samma princip som när du kontrollerade ditt llama-server-bygge mot sårbarhetsaviseringen: det som räknas är den binär som ligger i ExecStart, inte den som ligger först i din egen PATH.

Mät laddtid och minne före och efter bytet

Översättningen i tabellen ovan är hämtad ur koden, men det är fortfarande din maskin, din modellfil och ditt filsystem som avgör om ”samma läge” också ger samma laddtid och samma minnesbild. Därför är mätprovet AI-burkens tillägg: två körningar, samma modellfil, samma maskin, samma övriga flaggor, och bara laddningsflaggan översatt.

  1. Starta servern med den gamla flaggan på den gamla binären. Ta tid från start tills GET /health går från HTTP 503 (”Loading model”) till HTTP 200 ({"status":"ok"}). Anteckna sekunder.
  2. Läs processens residenta minne i kB, till exempel med ps -o rss= -p <pid>, direkt efter att /health gav 200 och igen efter en kort testfråga.
  3. Uppgradera till v0.4.1, byt flaggan enligt tabellen och upprepa steg 1 och 2 utan andra ändringar.
  4. Kör paret minst tre gånger vardera och jämför medianen, inte den första körningen. Den första laddningen efter en omstart går mot kall sidcache och är en annan mätning.

Skiljer sig laddtiden i sekunder eller minnet i kB tydligt mellan körningarna har du antingen översatt fel värde, en avvikande övrig flagga, eller ett verkligt beteende i det nya läget som du vill veta om. Alla tre är skäl att stanna innan du rullar ut på fler maskiner. Metoden att hålla laddning, prompt och generering isär är samma som i mätprovet för kallstart; det som mäts här är enbart laddningsfasen.

Tre andra rader i 0.4.1 som rör drift

Släppet innehåller mer än flaggborttagningen, och tre punkter är värda att läsa innan du uppdaterar en server som fler använder. Releasenoten anger att strukturerad JSONL-loggning finns via --log-jsonl och LOG_JSON, att ett LRU-hang vid flera förfrågningar mot samma modell är rättat, och att --reasoning-preserve nu är på som standard. Den sista är en ändrad standardinställning, vilket betyder att en server som inte satte flaggan alls kan svara annorlunda efter uppgraderingen. Vad den gör i dina svar avgör du genom att läsa serverns README och prova, inte genom att anta.

Källor och tekniskt underlag

Källorna kontrollerades 14 september 2026 via GitHubs API och råfilerna på master. Artikeln innehåller inga egna mätvärden och påstår inte hur mmap, mlock eller DirectIO beter sig på en viss plattform utöver hjälptextens ordalydelse. Ollama och LM Studio omfattas inte av ändringen som den beskrivs här.

Nästa steg

Kör de två sökningarna ovan, skriv ner varje träff, och mät laddtid och minne på den gamla binären innan du uppgraderar – efteråt finns inget ”före” att jämföra med.

Läs driftguiden