En lokal modell väljer varje nytt token ur en sannolikhetsfördelning, och parametrarna temperature, top_k, top_p och seed styr hur det valet går till. Ollamas dokumentation beskriver dem i en parametertabell, llama.cpp-servern i sin README och LM Studio i API-referensen, men ingen av dem säger hur mycket just din modell varierar på just din maskin. Det här provet mäter det: samma prompt tio gånger vid tre inställningar, en tabell över hur många svar som är unika och hur många som skiljer sig i sak. Resultatet ger dig en regel för när svaren ska låsas och när variation är det du vill ha.
Mät variationen innan du ändrar något. Ett facit, ett JSON-schema eller ett testfall ska köras låst, en idélista ska inte, och en låst seed gör ett felaktigt svar exakt lika felaktigt tio gånger i rad.
Vad parametrarna gör, enligt dokumentationen
Vid kontrollen 21 september 2026 beskriver Ollamas Modelfile-referens parametrarna så här. temperature är modellens temperatur; ett högre värde ger mer kreativa svar, förvalet är 0.8. top_k begränsar valet till de K mest sannolika token, med förvalet 40. top_p arbetar tillsammans med top_k, där ett högre värde ger mer varierad text och ett lägre mer fokuserad, med förvalet 0.9. seed sätter slumptalsfröet, och tabellen skriver att ett specifikt värde får modellen att generera samma text för samma prompt, med förvalet 0. Samma fält står i API-referensens options-schema, där seed beskrivs som ett slumpfrö för reproducerbara utdata.
llama.cpp-servern anger i sin README på master andra förval för /completion: temperature 0.8, top_k 40, top_p 0.95, min_p 0.05 och seed -1, där -1 betyder ett slumpmässigt frö. Serverns flagga --samplers visar också att samplarna tillämpas i en ordning, som förval penalties, dry, top_n_sigma, top_k, typ_p, top_p, min_p, xtc och sist temperature. Temperaturen verkar alltså inte ensam; den kommer efter att top_k och top_p redan skurit bort kandidater. Förvalet beror dessutom på endpoint: samma README anger temperature 1.0 och top_p 1.0 för den Anthropic-kompatibla /v1/messages.
LM Studio är ordknappare. Det OpenAI-kompatibla chat completions-API:t listar temperature, top_p, top_k, repeat_penalty och seed bland stödda nyttolastparametrar och hänvisar till OpenAI:s dokumentation för semantiken. Det egna REST-API:t för chat beskriver temperature med intervallet 0 till 1 och skriver att 0 är deterministiskt, men listar ingen seed. Inga numeriska förval för temperature, top_p eller top_k står på de sidor som kontrollerades; det värde som gäller läser du av i appens sidopanel Advanced Configuration, som enligt sidan om Presets är den plats där inställningarna sparas.
| Parameter | Ollama (Modelfile-tabellen) | llama.cpp-server (/completion) | LM Studio (dokumentationen) |
|---|---|---|---|
temperature | 0.8 | 0.8 | inget förval angivet, intervall 0–1 |
top_k | 40 | 40 | inget förval angivet |
top_p | 0.9 | 0.95 | inget förval angivet |
min_p | 0.0 | 0.05 | inget förval angivet |
seed | 0 | -1, slumpmässigt | tas emot i OpenAI-kompatibla API:t; saknas i REST-chat och SDK-konfigurationen |
Tabellen är avläst 21 september 2026 och gäller de dokumentationssidor som anges i källistan. Ingen av dem versioneras med ett tydligt nummer; llama.cpp-servern följer master, commit 6f41ac59 vid avläsningen. Skriv därför ut alla fyra fälten i varje anrop i stället för att förlita dig på ett förval som kan skilja sig mellan verktyg, endpoint och version.
Vad seed låser, och vad dokumentationen är tyst om
Ollamas formulering är att ett specifikt seed-värde får modellen att generera samma text för samma prompt. Det är hela löftet. Tabellen säger inte vad förvalet 0 betyder, inte om samma seed ger samma text på en annan maskin, med en annan Ollama-version, en annan kvantisering eller när två anrop körs samtidigt. LM Studios dokumentation beskriver inte alls vad seed låser, bara att parametern tas emot i det OpenAI-kompatibla API:t.
Av de tre är det bara llama.cpp-serverns README som, på de kontrollerade sidorna, varnar uttryckligen. Beskrivningen av cache_prompt, som är påslaget som förval, säger att logits beroende på backend inte garanteras vara bit för bit identiska mellan olika batchstorlekar, och att alternativet därför kan ge icke-deterministiska resultat. Det är serverns egen varning för sin egen cache, och den säger inget om Ollama eller LM Studio. Men den visar att en låst seed låser slumptalsgeneratorn, inte hela beräkningen. Om det spelar roll på din maskin är precis det provet nedan visar.
Frys provet: en prompt som går att rätta
Provet mäter variation mellan svar, inte kvalitet. Prompten ska därför beställa något med ett sakinnehåll du kan jämföra svar mot svar, och vara kort nog att läsa tio gånger. Ett exempel: ”Förklara på högst fem meningar varför en kvantiserad modell tar mindre minne än originalet, och nämn två nackdelar med kvantisering.” Två svar skiljer sig i sak om de anger olika mekanism eller olika nackdelar; de skiljer sig bara i ordval om samma sakuppgifter står där med annan formulering. Det är den distinktionen tabellen längre ned bygger på.
Anteckna sedan det som avgör om resultatet går att jämföra med ett senare: Ollama-version från ollama --version, modellnamn, exakt tagg och digest från ollama show, kvantisering, hårdvara och kontextlängd. Kör provet ensam på maskinen. Ollamas FAQ anger förvalet 1 för OLLAMA_NUM_PARALLEL, men om du ändrat det, eller om en annan klient anropar samtidigt, mäter du mer än samplingen; artikeln om två samtidiga frågor visar vad som händer då. Håll också modellen laddad genom hela provet, så att inte en omladdning mellan två körningar smyger in något annat i mätningen, se kallstartsartikeln.
Tre inställningar, tio körningar var
Provet har tre lägen. A är utgångsläget med Ollamas dokumenterade förval utskrivna och utan seed. B sätter temperature till 0 och rör inget annat. C är A med en fast seed, samma i alla tio körningar. Lägg vart och ett i en egen fil så att ingenting annat än den avsedda raden skiljer filerna åt. Sätt num_predict till en budget som räcker för fem meningar; förvalet är enligt Modelfile-tabellen -1, obegränsad generering.
# prov-a.json — förvalen utskrivna, ingen seed
{
"model": "DIN-MODELL:DIN-TAGG",
"prompt": "Förklara på högst fem meningar varför en kvantiserad modell tar mindre minne än originalet, och nämn två nackdelar med kvantisering.",
"stream": false,
"keep_alive": -1,
"options": { "num_ctx": 4096, "num_predict": 200, "temperature": 0.8, "top_k": 40, "top_p": 0.9 }
}# prov-b.json — samma fil, en ändrad rad
"options": { "num_ctx": 4096, "num_predict": 200, "temperature": 0, "top_k": 40, "top_p": 0.9 }
# prov-c.json — samma fil som A, ett tillagt fält
"options": { "num_ctx": 4096, "num_predict": 200, "temperature": 0.8, "top_k": 40, "top_p": 0.9, "seed": 42 }Kör sedan varje fil tio gånger och spara hela JSON-svaret, inte bara texten. I PowerShell på Windows heter programmet curl.exe; på macOS och Linux räcker curl och en motsvarande loop i skalet.
foreach ($lage in "a", "b", "c") {
1..10 | ForEach-Object {
curl.exe -s http://localhost:11434/api/generate -H "Content-Type: application/json" -d "@prov-$lage.json" -o ("{0}-{1:D2}.json" -f $lage, $_)
}
}Trettio filer är resultatet. Vad ett utelämnat seed-fält i A och B faktiskt betyder står inte i dokumentationen, mer än att förvalet är 0; låt fältet vara borta där och läs resultatet som det ser ut i stället för att anta att 0 är ”slumpmässigt”.
Räkna unika svar, sedan svar som skiljer sig i sak
Det första måttet är mekaniskt: hur många av de tio svaren är identiska, tecken för tecken, och hur många är det efter att skiftläge och blanksteg normaliserats. Räknaren läser också eval_count, antalet genererade token, och done_reason, som anger varför genereringen stannade. Tio körningar som avslutas av olika skäl är inte jämförbara.
import glob, json, sys
from collections import Counter
svar = []
for fil in sorted(glob.glob(sys.argv[1] + "-*.json")):
d = json.load(open(fil, encoding="utf-8"))
svar.append((d["response"].strip(), d["eval_count"], d["done_reason"]))
exakt = Counter(s for s, _, _ in svar)
norm = Counter(" ".join(s.lower().split()) for s, _, _ in svar)
print("körningar:", len(svar))
print("unika svar, exakt:", len(exakt))
print("unika svar, normaliserade:", len(norm))
print("eval_count min-max:", min(e for _, e, _ in svar), max(e for _, e, _ in svar))
print("done_reason:", dict(Counter(r for _, _, r in svar)))
for text, antal in exakt.most_common(3):
print(antal, "x", text[:90])Kör den som python rakna.py a, python rakna.py b och python rakna.py c. Det andra måttet kan ingen räknare göra åt dig: läs de unika svaren i varje läge och gruppera dem efter sakinnehåll. Nämner alla samma mekanism, färre bitar per vikt, och samma två nackdelar? Då är variationen ordval. Anger tre av tio en annan nackdel, eller ett fel, är det variation i sak, och det är den du behöver bestämma dig om.
Fyll tabellen innan du bestämmer dig
| Läge | Inställning | Unika svar, exakt | Unika svar, normaliserade | Svar som skiljer sig i sak | eval_count min–max | done_reason |
|---|---|---|---|---|---|---|
| A | temperature 0.8, ingen seed | ___ av 10 | ___ av 10 | ___ av 10 | ___–___ | ___ |
| B | temperature 0, ingen seed | ___ av 10 | ___ av 10 | ___ av 10 | ___–___ | ___ |
| C | temperature 0.8, seed 42 | ___ av 10 | ___ av 10 | ___ av 10 | ___–___ | ___ |
Tabellen är din och siffrorna gäller din modell, din kvantisering, din version och din maskin. Den här sajten publicerar inga egna värden här, och en siffra från någon annans burk säger lite om din. Tre läsningar är ändå värda att göra av vilket resultat du än får.
C ger tio identiska svar. Då låser seed på din maskin, i den versionen, den dagen. Det är precis vad Ollamas tabell lovar, och inte mer: kör om C efter nästa uppgradering innan du litar på det i ett skript. C ger fler än ett unikt svar. Då låser seed inte hela beräkningen i din uppsättning. llama.cpp-serverns cache-varning är en möjlig förklaring i den servern, men dra ingen slutsats om orsaken i Ollama utifrån den; anteckna i stället spridningen och betrakta seed som ett sätt att minska variationen, inte ta bort den. B varierar lika mycket som A. Då gör temperature 0 inte det du trodde i den här uppsättningen, och det är bättre att veta det före testfallet än efter.
Regeln: lås när det finns ett facit, släpp när du vill ha spridning
När svaret ska jämföras mot något bestämt, ett facit i ett kvalitetsprov, ett JSON-schema som en kod ska läsa eller ett testfall som ska ge samma utfall varje natt, ska provet köras med de inställningar som gav lägst variation i din tabell, och seed ska stå uttryckligen i anropet. Artikeln om strukturerad JSON mäter hur ofta formatet håller; den mätningen blir meningslös om varje körning också varierar i sak. När du i stället vill ha tio olika förslag på en rubrik är variationen själva syftet, och då är A eller ett högre temperature-värde rätt läge, med samma räknare för att se att förslagen faktiskt skiljer sig.
Två fallgropar följer med regeln. Den första: en låst seed låser inte kvaliteten. Är svaret fel i C är det fel tio gånger, och provet visar bara att det är stabilt fel. Den andra: ett svar som börjar upprepa sig inom texten är en annan fråga än variation mellan svar; den styrs av repeat_penalty och mäts i artikeln om repetitionsstraffet. Blanda inte de två parametrarna i samma prov.
Samma prov i LM Studio och llama.cpp-servern
I LM Studio ligger temperature, top_p och top_k i sidopanelen Advanced Configuration i chatten, och kan sparas som en Preset; per-modell-förvalen under My Models gäller enligt dokumentationen laddningsinställningar som GPU-offload och kontextlängd, inte samplingen. Vill du köra samma trettio anrop mot LM Studio går det via det OpenAI-kompatibla API:t på http://localhost:1234/v1/chat/completions, som tar emot temperature, top_p, top_k och seed i nyttolasten. Läs av vilka värden som gäller innan du skriver ut dem, eftersom dokumentationen inte anger förvalen.
Mot llama.cpp-servern skickar du samma fält till /completion, men med serverns förval i åtanke: top_p 0.95 och min_p 0.05 i stället för Ollamas 0.9 och 0.0. Skriv ut alla fyra fälten där också, och läs svarets generation_settings, som enligt README innehåller de inställningar som faktiskt användes. Vill du isolera cache-varningen kör du C en gång till med "cache_prompt": false och jämför antalet unika svar. Väljer du verktyg efter resultatet hör den avvägningen hemma i jämförelsen mellan Ollama och LM Studio.
Vad provet kan och inte kan slå fast
Provet visar hur mycket din modell varierar vid tre inställningar på din maskin den dag du kör det, och om seed låser svaret i din uppsättning. Det visar inte varför, och det säger inget om en annan modell, en annan kvantisering eller en annan version. Byter du något av det har du ett nytt prov med ett nytt grundläge, och den gamla tabellen ska stå kvar bredvid den nya.
Spara därför protokollet: version, modell, tagg, digest, kvantisering, hårdvara, de tre JSON-filerna, de trettio råsvaren och den ifyllda tabellen. Nästa gång någon säger att modellen ”blivit annorlunda” har du något att jämföra mot, och nästa gång ett förval ändras i en punktutgåva ser du det i tabellen i stället för i magkänslan.
Källor och metod
- Ollama – Modelfile-referensen: parametertabellen med temperature 0.8, top_k 40, top_p 0.9, min_p 0.0, seed 0 och num_predict -1, samt formuleringen om vad seed gör
- Ollama – API-referensen för generate: options-schemat med seed, temperature, top_k och top_p, exemplet med options och svarsfälten eval_count och done_reason
- Ollama – API-introduktionen: den lokala serverns adress http://localhost:11434/api
- Ollama – FAQ: OLLAMA_NUM_PARALLEL med förvalet 1
- llama.cpp – serverns README på master: flaggorna --seed, --temp, --top-k, --top-p, --min-p och --samplers, /completion-parametrarna, cache_prompt-varningen, generation_settings och förvalen för /v1/messages
- LM Studio – OpenAI-kompatibla chat completions: listan över stödda nyttolastparametrar, inklusive seed
- LM Studio – REST-API:t för chat: temperature, top_p, top_k, min_p och repeat_penalty utan seed, och formuleringen om temperature 0
- LM Studio – LLMPredictionConfigInput: fälten temperature, topKSampling, topPSampling, minPSampling och repeatPenalty utan seed-fält
- LM Studio – Config Presets: sidopanelen Advanced Configuration och var inställningarna sparas
- LM Studio – Per-model Defaults: per-modell-förvalen gäller laddningsinställningar
Källorna kontrollerades 21 september 2026. Ingen egen installation, körning eller mätning ligger bakom artikeln, och inga värden för variation, unika svar eller tokenantal presenteras som uppmätta. Förvalen gäller de dokumentationssidor som anges, den dag de lästes; Ollamas dokumentation versioneras inte publikt, llama.cpp-serverns README följer master och LM Studios dokumentation anger inga numeriska förval för samplingen. Vad seed låser återges som utgivarnas egna formuleringar, och där dokumentationen är tyst sägs det.
Kör läge C tio gånger på den modell du använder mest. Får du fler än ett unikt svar vet du att seed inte räcker som lås i din uppsättning, och det är värt att veta innan JSON-provet.