Uppdateringen bröt något? Backa Ollama och llama.cpp till förra versionen – och lås den tills du provat

Vår driftguide kräver att driftkortet har en rad för rollback: vad som sparas och kommandot tillbaka. Sajtens egna nyheter visar varför raden behövs. När llama.cpp 0.4.1 tog bort --mmap, --mlock och --direct-io vägrade servern starta med gamla startskript, och när Ollama slutade sätta repeat_penalty började vissa modeller upprepa sig utan att någon rört en inställning. Båda gångerna är det snabbaste sättet att få tillbaka en fungerande tjänst detsamma: sätt tillbaka den version som fungerade, lås den och prova i lugn och ro. Den här texten visar utförandet.

Läs av versionen som kör

Ollamas API-referens dokumenterar anropet GET /api/version med beskrivningen att det hämtar Ollamas version. Svaret är ett JSON-objekt med ett fält, version. Från kommandoraden svarar ollama -v med samma tal; flaggan står i ollama --help som -v, --version Show version information, men saknas i CLI-referensen på docs.ollama.com vid kontrollen 17 september 2026. Använd API-anropet när du vill vara säker på vad servern kör, eftersom det är den som svarar och inte klientbinären du råkar ha på sökvägen.

# Ollama: klienten och servern
ollama -v
curl http://localhost:11434/api/version
# exempelsvar: {"version":"0.34.1"}

# llama.cpp: verktyget och servern
llama-server --version
curl http://localhost:8080/props

llama.cpp saknar en enkel versionssträng i samma mening. Flaggan --version beskrivs i argumenttolken som show version and build info och skriver en rad på formen version: <version> (build <nummer>, commit <hash>), följd av vilken kompilator och vilket mål bygget gjordes för. Serverns GET /props svarar med fältet build_info på formen b<nummer>-<hash>. Byggnumret i parentesen är det tal du ska anteckna: det är det som motsvarar taggen bNNNNN på releasesidan.

Hitta den senast fungerande versionen

Ollamas utgåvor på GitHub är taggade vX.Y.Z. Varje utgåva som kontrollerades bär samma uppsättning filer som den senaste: OllamaSetup.exe, ollama-windows-amd64.zip, ollama-linux-amd64.tar.zst, install.sh och en sha256sum.txt. Vissa utgåvor är markerade som pre-release, till exempel den som ändrade repeat_penalty-förvalet. Läs releasenoteringen för varje version mellan din senast fungerande och den som kör; det är där du hittar vilken av dem som bytte beteende.

llama.cpp har två sorters utgåvor på samma releasesida. De versionerade, som v0.4.1, bär releasenoteringen och bara en liten fil, nightly-tag.txt, som pekar på det bygge versionen motsvarar. Byggena, taggade bNNNNN, är markerade som pre-release och är de som faktiskt bär binärarkiven. Vid kontrollen 17 september 2026 hade projektet publicerat flera sådana byggen bara under den dagen. Det är därför byggnumret, inte versionsnumret, är det du pinnar.

Backa Ollama på Linux

Linux-dokumentationen har ett eget avsnitt för att installera en bestämd version. Kommandot lyder, ordagrant med dokumentationens egen exempelversion:

curl -fsSL https://ollama.com/install.sh | OLLAMA_VERSION=0.5.7 sh

Byt 0.5.7 mot din senast fungerande version, utan v framför. Skriptet lägger talet som en frågeparameter på nedladdningsadressen, så det du får är exakt den utgåvans arkiv. Vill du hellre hämta arkivet själv beskriver samma sida den manuella vägen: curl -fsSL https://ollama.com/download/ollama-linux-amd64.tar.zst | sudo tar x -C /usr följt av ollama serve, och arkivet för en bestämd version ligger som fil på utgåvans releasesida.

Uppdatering på Linux beskrivs i dokumentationen som ett manuellt steg – att köra install-skriptet igen. Låsningen består alltså i att inte köra det. Kör du Ollama som systemd-tjänst: starta om med systemctl restart ollama, läs loggen med journalctl -e -u ollama och bekräfta med /api/version att servern nu svarar med det tal du beställde.

Backa Ollama på Windows

Det finns två vägar, och de skiljer sig just i frågan om låsning. Den första är installeraren OllamaSetup.exe från utgåvans releasesida. Den ger appen med ikonen i aktivitetsfältet, som enligt FAQ:n laddar ned uppdateringar automatiskt – se gränsen nedan. Den andra är den fristående ollama-windows-amd64.zip, som enligt Windows-dokumentationen innehåller enbart Ollama-CLI:t och GPU-biblioteksberoenden för Nvidia. Tilläggspaketen ollama-windows-amd64-rocm.zip (AMD) och ollama-windows-amd64-mlx.zip packas upp i samma katalog. Dokumentationen beskriver zip-varianten som avsedd för inbäddning i egna program eller för att köras som systemtjänst via ollama serve, med NSSM som exempel.

Katalogerna som Windows-sidan anger är värda att kunna utantill när du byter version:

Modellerna ligger i en annan katalog än binärerna, så ett byte av binär rör dem inte enligt katalogindelningen. Det är inte samma sak som en försäkran om att en äldre binär läser varje modellfil du hämtat med en nyare – det är ett av de fel provet nedan ska fånga. Och upgrade.log är stället där du i efterhand ser att en uppdatering faktiskt skett. Installationsplatsen kan flyttas med installerarens flagga /DIR="d:\some\location".

Backa llama.cpp till ett pinnat bygge

Gå till byggets releasesida, bNNNNN, och hämta arkivet för din plattform. Filerna heter llama-bNNNNN-bin-<plattform>.zip eller .tar.gz, till exempel …-bin-win-cuda-12.4-x64.zip eller …-bin-ubuntu-x64.tar.gz; CUDA-byggena på Windows har dessutom ett separat cudart-…-arkiv med körtidsbiblioteken. Packa upp i en egen katalog per bygge och låt startskriptet peka på katalogen, inte på ett generiskt namn som skrivs över vid nästa nedladdning. Bekräfta med --version att numret i parentesen är det du beställde.

Vilket nummer du ska välja säger den här texten inget om. Det är det nummer ditt eget startskript fungerade med senast, och det står i loggen från den senaste lyckade starten eller i ditt versionskort. Saknas anteckningen: ta byggnumret som versionssidan för din tidigare version pekar på i nightly-tag.txt, och verifiera med provet.

Samma prov före och efter

Ett byte av version utan prov är bara en till förändring. Provet har två delar. Den första är funktionsprovet för just det som gick sönder: startar servern med flaggan, upprepar utdatan sig eller inte. Den andra är mätprovet från vår artikel om kallstart, promptbearbetning och generering: samma prompt, samma seed, samma num_ctx och num_predict, kallt och varmt anrop, och fälten load_duration, prompt_eval_duration och eval_duration ur svaret. Den avsedda skillnaden mellan körningarna ska vara versionen och ingenting annat.

Tabellen är ett ifyllt exempel på hur resultatet antecknas. Talen är exempelvärden och inga mätresultat.

Först när båda delarna är körda på båda versionerna vet du om nedgraderingen löste problemet eller bara flyttade det. Sparar du provets utdata som filer med versionen i namnet har du också materialet för en felrapport till projektet.

Gränsen: appen på macOS och Windows uppdaterar sig själv

Ollamas FAQ anger att Ollama på macOS och Windows laddar ned uppdateringar automatiskt, och att man klickar på ikonen i aktivitetsfältet eller menyraden och väljer Restart to update för att tillämpa dem. Vid kontrollen 17 september 2026 hittades ingen dokumenterad inställning eller miljövariabel som stänger av nedladdningen, varken i FAQ:n eller på Windows- och Linux-sidorna. Windows-sidan säger tvärtom att installeraren hjälper dig att hålla dig uppdaterad.

Det betyder att en nedgradering av appen är ett tillfälligt läge som dokumentationen inte erbjuder något sätt att låsa. Den här texten ger inga knep runt det. Det som går att säga med stöd i dokumentationen är att Linux-installationen uppdateras genom ett steg du själv kör, och att Windows-zipen är beskriven som enbart CLI utan app. Huruvida zip-varianten någonsin kontrollerar uppdateringar på egen hand står inte i dokumentationen – behandla det som oprovat tills du sett det i din egen logg. Vill du ha ett läge som dokumenterat inte uppdaterar sig i bakgrunden är de två vägarna de som finns att välja på. Gränsen ska stå i versionskortet, med datum.

Versionskortet

Fem rader räcker för att en kollega ska kunna backa tjänsten utan att fråga. Kortet fyller i driftkortets rollbackrad; det ersätter inte driftkortet.

Exemplet nedan är ifyllt med versionerna från maskinen ovan och visar detaljnivån. Kopiera formen, inte värdena: dina tal är de din egen installation rapporterar.

VERSIONSKORT — <tjänstens namn>
Upprättat: <datum>    Senast ändrat: <datum>

Körande version .......... Ollama: /api/version → <x.y.z>, avläst <datum>
                           llama.cpp: build <nummer> enligt --version
Senast fungerande ........ Ollama <x.y.z> / llama.cpp b<nummer>, provad <datum>
Var den hämtas ........... releasesida / lokalt sparat arkiv: <sökväg>
Kommandot som backar ..... <exakt kommando eller steg>
Provet ................... funktionsprov: <vad> / mätprov: <fil med utdata>
Låsning .................. <hur uppdatering hålls tillbaka, eller "ingen dokumenterad", med datum>
Nästa kontroll ........... <datum då gränsen kontrolleras mot dokumentationen igen>

Källor och tekniskt underlag

• Ollama API-referens: GET /api/version och svarsfältet version
• Ollama Linux: OLLAMA_VERSION med install-skriptet, manuell installation, uppdatering och loggar
• Ollama Windows: den fristående ollama-windows-amd64.zip och installationskatalogerna
• Ollama FAQ: automatisk nedladdning av uppdateringar på macOS och Windows, uppdatering på Linux
• Ollama releases: taggar och filer per utgåva
• llama.cpp releases: versionerade utgåvor och bNNNNN-byggen med binärarkiv
• llama.cpp build-info: formatet för --version
• llama.cpp server README: GET /props och fältet build_info

Källorna kontrollerades 17 september 2026. Versionsnumren 0.34.1 och 0.33.3 är avläsningar från en och samma maskin och används som exempel; artikeln rekommenderar ingen version och inget byggnummer för llama.cpp. Kommandot med OLLAMA_VERSION är citerat ordagrant ur Ollamas Linux-dokumentation, inklusive dess exempelversion 0.5.7. Påståendet att ingen dokumenterad avstängning av automatiska uppdateringar finns gäller de sidor som lästes vid kontrolldatumet och ska kontrolleras på nytt innan det upprepas.