llama-server läser nu temperatur och top-p ur miljövariabler – sätt förvalen i tjänstefilen i stället för kommandoraden

Bygget b11078 av llama.cpp publicerades den 21 september 2026 klockan 18:47 UTC med commit-titeln ”args: add env vars for temperature, top-p, min-p and penalties (#27380)”. Beskrivningen är kort och precis: ändringen låter --temp, --top-p, --min-p, --repeat-penalty, --presence-penalty och --frequency-penalty konfigureras via LLAMA_ARG_* ”so llama-server can be fully controlled from an EnvironmentFile (e.g. systemd on Debian)”. För den som kör servern som tjänst betyder det att samplingförvalen kan flytta från en lång ExecStart-rad till en fil som går att läsa, versionera och ändra utan att röra enheten.

De sex flaggorna, deras variabelnamn och serverns förval

Namnen och förvalen nedan står i serverns README på master, avläst 22 september 2026. README har inget eget versionsnummer, så jämförelsepunkten är commit e0dff58 från 21 september 2026 – samma ändring som i b11078. Tabellen omfattar de sex flaggor commit-texten räknar upp, i den ordning den räknar upp dem.

Två observationer som inte står i rubriken. README:s flaggtabell visar vid samma avläsning även LLAMA_ARG_TOP_K intill --top-k med förvalet 40; den flaggan nämns inte i commit-texten för #27380, så räkna den som tillgänglig vid kontrolldatumet snarare än som ny i den här utgåvan. Och siffrorna är serverns förval, inte ett råd. Skillnaden mot en annan körningsmiljö kan vara stor: den här ändringen rör llama.cpp:s egen server, och säger ingenting om vilka variabler Ollama eller LM Studio läser.

Företrädet är dokumenterat på en nivå och tyst på nästa

README har en rak mening om förhållandet mellan de två startvägarna: ”If both command line argument and environment variable are both set for the same param, the argument will take precedence over env var.” Sätter du LLAMA_ARG_TEMPERATURE=0.2 i miljöfilen och har kvar --temp 0.8 i ExecStart kör servern alltså på 0.8, utan felmeddelande. Det är samma fallgrop som vid flaggbytet till --load-mode: den tysta vinnaren är den du glömde ta bort.

Nivån därunder är en annan sak. Den kontrollerade README-sidan säger inte uttryckligen vad som gäller när ett anrop mot /completion skickar med "temperature" samtidigt som servern startats med ett förval. Här stannar den här artikeln: dokumentationen är tyst, och en regel som inte står i källan ska inte skrivas som om den gjorde det. Det du kan göra är att mäta det på din egen server, och serverns svar är byggt för precis det.

Läs av vad servern faktiskt kör med

Två avläsningar räcker. GET /props returnerar default_generation_settings, som README beskriver som förvalen för /completion med samma fält som svarets generation_settings. Endpointen är läsbar som förval; att ändra egenskaper med POST kräver att servern startats med --props, vilket du inte behöver för den här kontrollen. Svarets generation_settings beskrivs i sin tur som de angivna alternativen utom prompt, men inklusive n_ctx och model.

# 1. Vad gav tjänstefilen servern?
curl -s http://localhost:8080/props | jq '.default_generation_settings | {temperature, top_p, min_p, repeat_penalty, presence_penalty, frequency_penalty}'

# 2. Vad kördes det här anropet med?
curl -s http://localhost:8080/completion \
  -H 'Content-Type: application/json' \
  -d '{"prompt":"Sammanfatta en mening.","n_predict":40,"temperature":0.2}' \
  | jq '.generation_settings | {temperature, top_p, min_p}'

Kör paret två gånger: en gång utan temperature i kroppen och en gång med. Står 0.80 i båda avläsningarna i första körningen vet du att miljöfilen slog igenom. Visar andra körningen 0.2 i generation_settings medan /props står kvar på 0.80 har du ditt svar för din version, uppmätt i stället för antaget. Anteckna byggnumret från llama-server --version intill resultatet, för det är det som gör avläsningen jämförbar med nästa uppgradering.

Flytta förvalen utan att ändra något annat

Gör bytet så att placeringen är skillnaden och ingenting annat ändras: samma sex värden före och efter, samma modellfil, samma port.

# Före: sex värden i ExecStart
[Service]
ExecStart=/opt/llama.cpp/build/bin/llama-server -m /srv/models/modell.gguf --port 8080 \
  --temp 0.40 --top-p 0.90 --min-p 0.05 \
  --repeat-penalty 1.10 --presence-penalty 0.00 --frequency-penalty 0.00

# Efter: sex värden i miljöfilen
[Service]
EnvironmentFile=/etc/llama-server.env
ExecStart=/opt/llama.cpp/build/bin/llama-server -m /srv/models/modell.gguf --port 8080

# /etc/llama-server.env
LLAMA_ARG_TEMPERATURE=0.40
LLAMA_ARG_TOP_P=0.90
LLAMA_ARG_MIN_P=0.05
LLAMA_ARG_REPEAT_PENALTY=1.10
LLAMA_ARG_PRESENCE_PENALTY=0.00
LLAMA_ARG_FREQUENCY_PENALTY=0.00

Efter systemctl daemon-reload och en omstart är det /props som avgör om flytten lyckades, inte att enheten startade. En felstavad variabel ger ingen varning; den ignoreras, och servern kör vidare på sitt eget förval. Det är också skälet att jämföra alla sex fälten och inte bara det du råkade ändra. Hur en sådan här ändring rullas ut som en kontrollerad uppdatering i stället för en spontan redigering hör hemma i driftguiden.

Vilka värden ska stå i filen?

Den här nyheten handlar om var värdena bor, inte om vad de ska vara. Det senare avgörs av ett prov: kör samma fråga tio gånger vid tre inställningar, räkna unika svar och svar som skiljer sig i sak, och sätt sedan förvalet efter vad din modell faktiskt gör på din maskin. Det provet finns beskrivet steg för steg i artikeln om samma fråga tio gånger, och det är dess resultat som hör hemma i /etc/llama-server.env. Ett förval som hamnar i en tjänstefil utan mätning blir bara svårare att ifrågasätta, eftersom det nu ser officiellt ut.

Gäller frågan upprepningar inne i ett svar snarare än variation mellan svar är det LLAMA_ARG_REPEAT_PENALTY som är fältet att röra, och då är genomgången av repetitionsstraffet rätt utgångspunkt för vad parametern gör innan du fryser ett värde.

Två parametrar som inte flyttar med

Vid avläsningen 22 september 2026 saknar -s, --seed och --samplers env-namn i README:s flaggtabell. Seed står med förvalet -1, och --samplers med ordningen penalties;dry;top_n_sigma;top_k;typ_p;top_p;min_p;xtc;temperature. Två följder för en tjänst: en låst seed får fortsatt sättas i anropet eller på kommandoraden, och samplarordningen betyder att temperaturen verkar sist, efter att top_k, top_p och min_p redan skurit bort kandidater. Ett lågt LLAMA_ARG_MIN_P och ett lågt LLAMA_ARG_TEMPERATURE är därför inte två oberoende rattar i filen, utan två steg i samma kedja.

Källor och tekniskt underlag

• llama.cpp b11078 på GitHub Releases: publiceringstidpunkten 21 september 2026 18:47 UTC, commit-titeln om env vars för temperature, top-p, min-p och penalties samt beskrivningen om LLAMA_ARG och EnvironmentFile
• tools/server/README.md på master: flaggtabellen med LLAMA_ARG-namnen och förvalen, meningen om att kommandoradsargumentet går före miljövariabeln, beskrivningen av generation_settings samt /props med default_generation_settings
• Commitlistan för serverns README: commit e0dff58 från 21 september 2026, som daterar den version av README artikeln bygger på

Källorna kontrollerades 22 september 2026 mot råfilen på master och mot utgåvans releasesida. Flaggnamn, variabelnamn och förval återges som de stod den dagen; README följer master utan eget versionsnummer, så bekräfta dem mot llama-server --help på ditt eget bygge. Artikeln innehåller inga egna mätvärden och påstår inte vad som gäller när ett anrop skickar egna samplingfält – den kontrollerade dokumentationen säger inget om det, och avsnittet ovan beskriver i stället hur du läser av det på din server. Ollama och LM Studio omfattas inte av ändringen.