Artikeln skrevs mot förhandsversionen v0.33.3-rc0. Ändringen ingår i den skarpa utgåvan Ollama v0.33.3 (utgåvepunkten ”Honor GGUF model defined default parameters”) och gäller därmed även v0.34.0–v0.34.2. Rc-taggarna är inte längre publicerade releaser hos Ollama. Provet nedan är oförändrat: det gäller varje uppdatering som kan ändra vilka förval som vinner.
Ollama 0.33.3-rc0, förhandsversionen inför v0.33.3, innehöll en liten rad med stor testeffekt: programmet respekterar nu standardparametrar som modellen själv definierar i GGUF. Före ändringen kunde samma värden ignoreras och Ollamas allmänna förval användas i stället, så länge varken ditt API-anrop eller din Modelfile satte parametern. Det betyder inte att varje GGUF eller varje svar förändras. Det betyder att ett gammalt grundläge utan uttryckliga parametrar inte längre är säkert jämförbart efter uppdateringen.
Prova inte uppdateringen direkt på din vardagsmodell. Spara version, GGUF-kontrollsumma, Modelfile, nyttolast och råsvar; kör sedan ett ärvt och ett uttryckligen låst kontrolläge före och efter uppdateringen.
Fyra nivåer avgör vilket värde som vinner
Den sammanslagna ändringen bakom releasepunkten beskriver den nya ordningen. Ett värde i API-anropet har högst prioritet. Därefter kommer en PARAMETER-rad i Modelfile, sedan modellens egna värden i GGUF-metadata och sist Ollamas allmänna förval. För GGUF-användaren är den tredje nivån ny i praktiken: metadata som tidigare inte påverkade körningen kan nu göra det när de två högre nivåerna är tomma.
| Prioritet | Källa | Vad den innebär i provet |
|---|---|---|
| 1 | API-parametrar | Sätt inte parametern här när du vill se GGUF-arvet; då maskerar API:t allt under. |
| 2 | Modelfile PARAMETER | Det låsta kontrolläget får sina avsiktliga värden här. |
| 3 | GGUF-standardvärden | Det är nivån som 0.33.3-rc0 börjar respektera. |
| 4 | Ollamas allmänna förval | De användes tidigare när högre nivåer saknades. |
Releasenoteringen publicerar ingen fullständig lista över vilka GGUF-fält som omfattas. Utgå därför inte från att en viss parameter berörs bara för att den finns i Modelfile-referensens tabell. Leta i stället efter de genereringsvärden som följer med just din fil eller som du redan har dokumenterat i ditt arbetsflöde. Har du inget dokumenterat värde finns det inget hederligt sätt att återskapa det gamla läget genom gissning.
Frys grundläget innan du byter version
Börja medan din nuvarande Ollama-version fortfarande körs. Använd en kopia av en lokal GGUF som du kan kasta efteråt, inte modellnamnet som andra klienter anropar. Spara först versionsraden och en SHA-256-kontrollsumma för filen. Exemplet nedan är PowerShell; på macOS eller Linux kan samma kontroll göras med systemets SHA-256-verktyg.
ollama --version | Tee-Object -FilePath .\fore-version.txt
Get-FileHash .\testmodell.gguf -Algorithm SHA256 |
Format-List | Out-File .\gguf-sha256.txt
Spara därefter den Modelfile och den klientnyttolast du faktiskt använder. Har modellen redan byggts i Ollama ger ollama show --modelfile DIN-MODELL:DIN-TAGG en kopia att arkivera. Den kontrollen visar Modelfile-lagret; behandla den inte som en fullständig utskrift av alla interna GGUF-nycklar.
ollama show --modelfile DIN-MODELL:DIN-TAGG |
Out-File -Encoding utf8 .\fore-Modelfile.txt
Skriv sedan ett litet driftkort med modellfilens sökväg, kontrollsumman, Ollama-versionen, datorn, prompten, de tre seeds du ska använda och de parametrar du uttryckligen har beslutat om. För ett bredare sätt att spara runtime och konfiguration finns AI-burkens driftguide. Här är poängen smalare: exakt samma underlag ska överleva versionsbytet.
Bygg ett arvsläge och ett låst kontrolläge
Den första Modelfile-filen ska vara så tunn som möjligt. Den innehåller bara samma GGUF-källa och låter därmed modellmetadata eller Ollamas förval bestämma genereringen. Spara den som Modelfile.arv.
FROM ./testmodell.gguf
Den andra filen, Modelfile.last, ska ha samma FROM-rad och de värden du redan har beslutat att hålla fasta. Kopiera dem från ditt sparade grundläge. Raderna nedan är platshållare, inte rekommenderade tal och inte en påstådd fullständig lista över vad releasen ärver.
FROM ./testmodell.gguf
PARAMETER DIN_PARAMETER DITT_VÄRDE
PARAMETER DIN_ANDRA_PARAMETER DITT_ANDRA_VÄRDE
Ollamas dokumentation beskriver PARAMETER som instruktionen som sätter hur modellen körs och ollama create som byggsteget. Bygg två expendabla namn och spara sedan båda visningarna. Den befintliga guiden till GGUF-import med Modelfile äger hela importflödet; här används samma mekanik bara för kontrollen.
ollama create gguf-arv-test -f .\Modelfile.arv
ollama create gguf-last-test -f .\Modelfile.last
ollama show --modelfile gguf-arv-test > .\arv-fore.txt
ollama show --modelfile gguf-last-test > .\last-fore.txt
Om du inte kan fylla de låsta raderna med avsiktliga, spårbara värden ska du inte hitta på dem för att slutföra tabellen. Kör arvslägets observationsprov och vänta med uppdateringen av det verkliga arbetsflödet tills du har valt ett nytt, dokumenterat parameterkort.
Kör samma tre seeds i båda lägena
Prompten och poängkriteriet måste mäta samma sak. Använd exempelvis en fryst text och be modellen skriva exakt fyra numrerade slutsatser, där varje slutsats innehåller högst 18 ord och bara bygger på texten. Godkänn ett svar endast när alla tre krav är uppfyllda: fyra punkter, högst 18 ord per punkt och inget påstående utanför underlaget.
Nyttolasten ska inte innehålla de samplerparametrar som du försöker jämföra. Ett API-värde ligger över både Modelfile och GGUF och skulle därför göra provet blint. Du kan däremot byta modellnamn och seed mellan körningarna. Kör seeds 42, 43 och 44 i båda modellnamnen och spara hela JSON-svaren.
{
"model": "gguf-arv-test",
"prompt": "Läs den frysta texten och skriv exakt fyra numrerade slutsatser. Varje slutsats får innehålla högst 18 ord och måste stödjas av texten. TEXT: DIN FRYSTA TESTTEXT",
"stream": false,
"options": {
"seed": 42,
"num_predict": 160
}
}
{
"model": "gguf-last-test",
"prompt": "Läs den frysta texten och skriv exakt fyra numrerade slutsatser. Varje slutsats får innehålla högst 18 ord och måste stödjas av texten. TEXT: DIN FRYSTA TESTTEXT",
"stream": false,
"options": {
"seed": 42,
"num_predict": 160
}
}
De två nyttolasterna har samma omslutning, prompt, seed och tokenbudget; modellnamnet skiljer dem åt. Upprepa med seed 43 och 44. Spara filerna med namn som visar version, läge och seed, till exempel fore-arv-42.json och fore-last-42.json. Anteckna även om varje svar klarar de tre uttryckliga kraven.
Upprepa först när återställningsvägen är klar
Installera inte den nya versionen bara för att tabellen ska bli komplett. Kontrollera först att du kan gå tillbaka till din sparade version och att inga andra klienter behöver den testade Ollama-instansen. När 0.33.3-rc0 körs sparar du den nya versionsraden, kontrollerar GGUF-filens SHA-256 igen och bygger om båda testmodellerna från exakt samma två Modelfile-filer.
Kör därefter samma sex anrop igen. Ändra inte prompten när ett svar ser oväntat ut, och lägg inte till en parameter i API:t för att ”hjälpa” den nya versionen. Då försvinner jämförelsen. Ett oväntat svar sparas som rådata och bedöms med samma tre kriterier som före uppdateringen.
Fyll fyra fält innan du drar slutsatsen
| Version och läge | Seed 42 | Seed 43 | Seed 44 | Godkända svar | Tolkning |
|---|---|---|---|---|---|
| Före · arv | ___ | ___ | ___ | ___ av 3 | Gammalt ärvt grundläge |
| Före · låst | ___ | ___ | ___ | ___ av 3 | Kontroll före |
| 0.33.3-rc0 · arv | ___ | ___ | ___ | ___ av 3 | Nytt GGUF-arv kan verka här |
| 0.33.3-rc0 · låst | ___ | ___ | ___ | ___ av 3 | Kontroll efter |
Om arvsläget ändras medan det låsta läget förblir stabilt har du ett praktiskt tecken på att uttryckliga parametrar skyddar reproducerbarheten. Om både arv och låst läge ändras ska du inte skylla allt på GGUF-arvet: samma release uppdaterar också MLX, MLX-C och llama.cpp. Om inget läge ändras kan filen sakna relevanta standardvärden, högre inställningar kan redan styra eller just den frysta prompten kan vara okänslig.
Ett förändrat enskilt seed är inte heller ett universellt kvalitetsomdöme. Jämför alla tre seeds och rapportera antalet godkända svar. Vill du undersöka upprepning specifikt finns den separata metoden för repeat_penalty; den här nyheten ska inte användas för att gissa vilket enskilt parameterfält som orsakade skillnaden.
Lås, vänta eller acceptera det nya arvet
Det finns tre rimliga beslut. Behöver ett arbetsflöde ge jämförbara svar över tid låser du de avsiktliga värdena i dess Modelfile och arkiverar filen tillsammans med modellens kontrollsumma. Vill du följa modellskaparens standarder accepterar du GGUF-arvet, men behandlar uppdateringen som ett nytt grundläge och sparar de nya råsvaren. Saknar du återställningsväg eller dokumenterade parametrar väntar du på en stabil version.
Låsningen är per modell och arbetsflöde, inte en global rekommendation. En parameteruppsättning som passar en kort klassificeringsprompt behöver inte passa en lång kreativ text. Byter du samtidigt GGUF-fil, kvantisering eller prompt har du inte längre ett rent versionsprov. Kontrollera filvalet separat enligt jämförelsen av Q4, Q5 och Q8.
Spara slutligen de tolv råsvaren, de fyra Modelfile-utskrifterna, två versionsrader, kontrollsumman och den ifyllda tabellen i en gemensam katalog. Nästa gång Ollama ändrar ett förval kan du jämföra mot en faktisk körning i stället för minnet av hur modellen brukade svara.
Källor
- Ollama – release v0.33.3, 2 september 2026: GGUF-modellens standardparametrar respekteras samt MLX-, MLX-C- och llama.cpp-uppdatering (ursprungligen i förhandsversionen v0.33.3-rc0, som inte längre är en publicerad release)
- Ollama – PR #16471: tidigare beteende och prioriteten API, Modelfile, GGUF/MLX-konfiguration, Ollamas allmänna förval
- Ollama – Modelfile reference: lokal GGUF med FROM, PARAMETER, ollama create och ollama show --modelfile
Källorna kontrollerades 2 september 2026. Ingen egen installation eller benchmark ligger bakom artikeln och inga provutfall presenteras som uppmätta. Releasenoteringen publicerar ingen fullständig lista över vilka GGUF-parametrar som ärvs; texten avgränsar därför rådet till parametrar som användaren själv kan dokumentera och låsa. Kontrollerat igen 19 september 2026: ändringen (#16471) ingår i den skarpa v0.33.3 och i v0.34.0–v0.34.2; rc-taggarna är inte längre publicerade releaser hos Ollama, så källänken pekar på v0.33.3.