Ollama sätter inte längre repeat_penalty åt dig – mät om modellen börjar upprepa sig

Ollama 0.32.10, publicerad 12 augusti 2026, ändrade ett förval som ingen dialogruta berättar om. Releasenoteringen formulerar det så här: modeller som inte sätter ett eget repeat_penalty får numera 1.0, alltså avstängt straff, i stället för 1.1. Utgivaren anger också motivet — att matcha andra motorer och att snabba upp spekulativ avkodning — och skriver att den som har en äldre modell som upprepar sig kan sätta parametern per modell. Ingen varning visas när det händer i din burk. Skillnaden dyker i stället upp som en text som börjar mala, en punktlista som återkommer till samma formulering eller ett svar som fortsätter tills tokenbudgeten tar slut.

Vad noteringen säger, och hur långt den räcker

Punkten gäller ett förval, inte en tvingande inställning. En modell vars egen Modelfile innehåller en repeat_penalty-rad påverkas inte: den kör vidare på sitt värde. Det är därför två personer kan uppgradera samma dag och bara den ena märker något. Har du hämtat en äldre modell som förlitade sig på Ollamas tidigare 1.1 är du i den grupp där utdatan kan ändra karaktär utan att du rört en inställning.

Vid kontrollen 31 augusti 2026 pekar dokumentationen åt samma håll som releasenoteringen. Modelfile-referensens parametertabell anger repeat_penalty med förvalet 1.0 och ordet disabled, och beskriver parametern som hur starkt upprepningar bestraffas: ett högre värde straffar hårdare, ett lägre är mildare. Samma tabell anger repeat_last_n med förvalet 64, alltså hur långt bakåt modellen tittar. Står straffet på 1.0 spelar det fönstret ingen roll i praktiken, eftersom ingenting dras av.

Två detaljer förtjänar egen uppmärksamhet. Den första: utgåvan 0.32.10 är på GitHub märkt som pre-release, medan de följande utgåvorna inte är det. Det ändrar inte vad punkten säger, men det är ett skäl att kontrollera vilken version din maskin faktiskt kör i stället för att anta att just den utgåvan passerade förbi. Den andra: i releaselistan mellan 0.32.11 och 0.33.2 nämner ingen notering repeat_penalty eller ett återställt samplingsförval. Senaste utgåvan vid kontrollen, 0.33.2 från 27 augusti 2026, handlar om mörkt läge, en dubbelstartad app på macOS och en proxy som avbröt pågående anrop. Frånvaron av omnämnanden är svagare bevis än ett uttryckligt löfte, så kontrollen bör göras om vid nästa uppgradering.

Kontrollera version och vad modellen själv sätter

Börja i din egen installation, inte i changeloggen. Läs versionen med ollama --version och läs sedan modellens egen Modelfile. Modelfile-referensen anger kommandot för det: ollama show --modelfile följt av modellnamnet skriver ut den Modelfile som gäller för modellen. Leta efter en rad som börjar med PARAMETER repeat_penalty.

ollama --version
ollama show --modelfile DIN-MODELL:DIN-TAGG

Finns raden där sätter modellen sitt eget värde och det ändrade förvalet passerar den obemärkt. Saknas raden körs modellen sedan uppgraderingen utan repetitionsstraff, och då är provet nedan meningsfullt. Anteckna samtidigt det som avgör om ditt resultat går att jämföra med ett senare, eller med någon annans.

Frys provet innan du rör parametern

Skriv en prompt som beställer det du vill mäta: en sammanhängande text på minst 400 ord i ett ämne du kan bedöma, utan formatkrav som i sig tvingar fram upprepade rader. Ett exempel är: ”Beskriv i löpande text hur en säkerhetskopia av en lokal modellkatalog planeras, genomförs och provas. Minst 400 ord, ingen punktlista, upprepa inte formuleringar.” Då mäter du senare samma sak som du beställde.

Frys därefter modellnamn, tagg, kontextlängd, temperatur, tokenbudget och seed. Kör tre gånger per läge med tre bestämda seeds — till exempel 42, 43 och 44 — och använd samma tre i båda lägena. En enskild körning kan skilja sig av slumpskäl; tre körningar visar om skillnaden är större än spridningen inom samma läge. Dokumentationen anger förvalen 0 för seed, 0.8 för temperature och obegränsad generering för num_predict, så sätt alla tre uttryckligen i stället för att förlita dig på vad som råkar gälla.

Två anrop som skiljer sig på en rad

Skicka samma nyttolast till generate-endpointen två gånger. Den andra körningen skiljer sig på precis en rad, så att skillnaden i utdatan går att härleda till parametern och ingenting annat.

# Körning A: förvalet efter 0.32.10, inget straff satt
curl http://localhost:11434/api/generate -d '{
  "model": "DIN-MODELL:DIN-TAGG",
  "prompt": "DIN FRYSTA PROMPT",
  "stream": false,
  "options": {
    "seed": 42,
    "temperature": 0.8,
    "num_ctx": 4096,
    "num_predict": 700
  }
}'

# Körning B: samma anrop med det tidigare förvalets straff
curl http://localhost:11434/api/generate -d '{
  "model": "DIN-MODELL:DIN-TAGG",
  "prompt": "DIN FRYSTA PROMPT",
  "stream": false,
  "options": {
    "seed": 42,
    "temperature": 0.8,
    "num_ctx": 4096,
    "num_predict": 700,
    "repeat_penalty": 1.1
  }
}'

En avgränsning värd att känna till: schemat för options i Ollamas publicerade API-spec räknar upp seed, temperature, top_k, top_p, min_p, stop, num_ctx och num_predict, och tillåter därutöver ytterligare fält. repeat_penalty står inte i den uppräkningen. Får du inget utslag alls mellan A och B är nästa steg därför att jämföra två byggda modeller i stället, med parametern satt i en Modelfile enligt avsnittet längre ned. Den vägen är dokumenterad för just den här parametern.

Poängsätt samma sak som prompten beställer

Spara hela JSON-svaret från varje körning, inte bara texten. Tre fält bär mätningen: eval_count som anger antalet genererade token, eval_duration som anger genereringstiden i nanosekunder och done_reason som anger varför genereringen stannade. Ett svar som slutar därför att tokenbudgeten tog slut, i stället för att modellen avslutade själv, är ett av de tydligaste tecknen på att texten gick i cirklar.

Poängsätt sedan upprepningen mekaniskt, så att bedömningen inte blir en känsla. Två mått räcker långt: andelen ordtrigram som förekommer mer än en gång, och den längsta ordföljd som återkommer i texten. Kör samma räknare på båda svaren.

import json, sys
from collections import Counter

text = json.load(open(sys.argv[1], encoding="utf-8"))["response"]
words = text.split()
tri = Counter(tuple(words[i:i+3]) for i in range(len(words) - 2))
upprepade = sum(n for n in tri.values() if n > 1)
print("ord:", len(words))
print("andel upprepade trigram:", round(upprepade / max(1, sum(tri.values())), 3))
print("mest upprepade:", tri.most_common(3))

Läs också texten. Ett avstängt straff kan ge en text som återanvänder samma inledningsfras i varje stycke; ett påslaget straff kan i stället skjuta undan ord som hör hemma i texten, som en term eller ett kommandonamn som behöver återkomma. Den bedömningen kan ingen räknare göra åt dig, och den hör hemma i protokollet.

Fyll tabellen innan du bestämmer dig

Jämför medianen för A med medianen för B, och ställ skillnaden mot spridningen mellan de tre seeds inom samma läge. Är avståndet mellan lägena mindre än spridningen inom ett läge har du inte visat något; då är förvalsändringen sannolikt betydelselös för just din modell och din prompttyp. Är avståndet tydligt större har du ett mätt skäl att sätta parametern — för den här modellen, i den här kvantiseringen, på den här maskinen.

Sätt värdet per modell i en Modelfile

Bestämmer du dig för ett straff hör det hemma i en byggd modell, inte i varje anrop. Modelfile-referensen beskriver PARAMETER som instruktionen för att sätta en parameter, och bygget görs med ollama create mot filen.

FROM DIN-MODELL:DIN-TAGG
PARAMETER repeat_penalty 1.1

# bygg och kontrollera
ollama create din-modell-rp -f ./Modelfile
ollama show --modelfile din-modell-rp

Kontrollen på sista raden är poängen: du ser att raden verkligen följde med in i den byggda modellen. Vill du också justera hur långt bakåt straffet verkar sätter du repeat_last_n i samma fil; förvalet är 64 token, och 0 stänger av fönstret medan -1 sträcker det över hela kontexten. Kommer modellen från en egen GGUF-fil är byggsteget detsamma, och flödet dit beskrivs i guiden till import med Modelfile. Byter du samtidigt kvantisering har du ändrat två saker på en gång; artikeln om Q4, Q5 och Q8 hör till ett eget prov med eget grundläge.

Vad provet kan och inte kan slå fast

Resultatet gäller den modellvariant, den kvantisering, den hårdvara och den prompttyp du provade. Det överförs inte automatiskt till nästa modell i katalogen, och en siffra från någon annans maskin säger lite om din. Därför publicerar den här sajten inga egna värden här: provet är beskrivet så att du kan köra det, och tabellen är din.

Håll också isär vad som ändrats. Ett svar som dröjer eller en modell som laddas om mellan anrop är en annan fråga än upprepning i texten; hur länge modellen ligger kvar i minnet behandlas i artikeln om keep-alive. Byter du modell, tagg eller kontextlängd mitt i jämförelsen är det ett nytt experiment med ett nytt grundläge, och den maskin du kör på sätter ramarna enligt hårdvaruguidens minnesräkning.

Spara till sist protokollet: version, modell, tagg, kvantisering, hårdvara, de sex råsvaren och den ifyllda tabellen. Nästa gång ett förval ändras i en punktutgåva har du ett före att jämföra mot, och behöver inte lita på minnet av hur modellen brukade skriva.

Källor

• Ollama – release v0.32.10, 12 augusti 2026: det ändrade förvalet för repeat_penalty, motivet och rådet att sätta parametern per modell
• Ollama – releaselistan: versionerna mellan 0.32.11 och 0.33.2 och vad de innehåller
• Ollama – Modelfile-referensen: PARAMETER, repeat_penalty med förvalet 1.0, repeat_last_n, seed, temperature, num_predict samt ollama create och ollama show --modelfile
• Ollama – API-referensen för generate: options-schemat och svarsfälten eval_count, eval_duration och done_reason
• Ollama – release v0.33.2, 27 augusti 2026: den senaste utgåvan vid kontrollen och dess tre punkter

Källorna kontrollerades 31 augusti 2026. Ingen egen installation, körning eller mätning ligger bakom artikeln, och inga siffror för upprepning, hastighet eller kvalitet presenteras som uppmätta resultat. Dokumentationen på docs.ollama.com versioneras inte publikt och kan ändras utan notis; läs om parametertabellen vid nästa uppgradering.