Ollama modellnamn och digest: jämför rätt modell

Du har sparat modellnamnet i mätprotokollet. Efter en ändring verkar modellen snabbare, men jämför du samma installerade modellunderlag? Börja med en inventering före och efter. Här sparar du hela digest tillsammans med namnet och kvantiseringsfältet, så att jämförelsen kan få ett tydligt förbehåll när underlaget skiljer sig.

Det här kompletterar driftguidens modellrad. Om själva programversionen behöver hanteras finns en separat artikel om att backa Ollama eller llama.cpp. Inventeringen nedan ändrar ingen modell och installerar ingen serverversion. Den läser API-svar och skriver egna protokollfiler i den katalog där du kör den.

Namn och tagg är början på protokollet

Ollamas API-dokumentation i projektets källträd beskriver namnformen som model:tag, med ett möjligt namnrymdsprefix. Utelämnad tagg blir latest. Det hjälper dig att förstå ett anropsnamn som llama3:70b, men använd inte namnet ensamt som bevis för att två inventeringar gäller samma underlag. Här gör vi därför en separat jämförelse av digest.

Tänk på inventeringen som ett kvitto vid en bestämd tidpunkt. Spara vad servern faktiskt svarade, även när du känner igen namnet. Om en kollega senare bara får raden ”samma modell som tidigare” går det inte att kontrollera vilken identitet som avlästes. Ett fullständigt värde i en fil gör den kontrollen möjlig utan att någon måste återskapa minnet av uppdateringen.

Hämta listan utan att ändra installationen

GET /api/tags visar bland annat modellnamn, digest och details.quantization_level. För en snabb överblick dokumenterar CLI-referensen även ollama ls. I protokollet använder vi API-svaret för att spara fälten utan att förlita oss på hur en terminaltabell visas.

Öppna Windows PowerShell 5.1 i en egen arbetskatalog med skrivrättighet. Ollama-servern behöver redan vara igång. Koden utgår från adressen i dokumentationens lokala exempel; ändra $baseUri om din server använder en annan adress. Kör inte samtidigt ett modellbyte. Då blir det oklart om listan och detaljsvaret fångar samma läge.

function Save-ModelInventory {
    param([string]$Phase)
    $baseUri = 'http://localhost:11434'
    $tags = Invoke-RestMethod -Method Get -Uri "$baseUri/api/tags" -ErrorAction Stop
    $version = Invoke-RestMethod -Method Get -Uri "$baseUri/api/version" -ErrorAction Stop
    $inventory = [pscustomobject]@{
        captured_at = (Get-Date).ToUniversalTime().ToString('o')
        server_uri = $baseUri
        server_version = $version.version
        models = @($tags.models | ForEach-Object {
            [pscustomobject]@{
                name = $_.name
                digest = $_.digest
                quantization_level = $_.details.quantization_level
            }
        })
    }
    $inventory | ConvertTo-Json -Depth 10 |
        Set-Content -LiteralPath "models-$Phase.json" -Encoding UTF8
}
Save-ModelInventory -Phase 'before'

Filen models-before.json är din referens. Öppna den och kontrollera att modellen finns med och att digest inte är tomt. En tom modellista är ingen lyckad identifiering av modellen du tänkte jämföra. Avbryt då jämförelsen och kontrollera vilken server du frågar, i stället för att hämta en modell för att få provet att fortsätta.

Exemplet sparar också serverns versionsfält från GET /api/version. Det är en egen rad: lägg inte programversionen i digestkolumnen. Spara referensfilen under ett nytt namn om du gör flera försök, eftersom en ny körning med samma fas skriver över just den protokollfilen.

Jämför hela värdet efter ändringen

När den ändring du själv planerat är färdig kör du samma funktion i samma PowerShell-session, med fasen after. Har du stängt fönstret klistrar du först in funktionsdefinitionen igen. Jämför sedan de sparade filerna. Metoden nedan använder namn som nyckel och behandlar namnbyten som borttagning plus tillägg; den försöker inte gissa att två olika namn borde höra ihop.

Save-ModelInventory -Phase 'after'
$before = Get-Content -LiteralPath 'models-before.json' -Raw | ConvertFrom-Json
$after = Get-Content -LiteralPath 'models-after.json' -Raw | ConvertFrom-Json
$names = @(@($before.models.name) + @($after.models.name) | Sort-Object -Unique)
$comparison = foreach ($name in $names) {
    $old = @($before.models | Where-Object { $_.name -ceq $name })
    $new = @($after.models | Where-Object { $_.name -ceq $name })
    $status = 'saknas efter'
    if ($old.Count -eq 0) { $status = 'tillkommen' }
    elseif ($new.Count -gt 0) {
        $status = 'oforandrad identitetsrad'
        if ([string]::IsNullOrWhiteSpace($old[0].digest) -or
            [string]::IsNullOrWhiteSpace($new[0].digest)) {
            $status = 'digest saknas - kan inte bedomas'
        }
        elseif ($old[0].digest -cne $new[0].digest) { $status = 'andrad digest' }
        elseif ($old[0].quantization_level -cne $new[0].quantization_level) {
            $status = 'samma digest men avvikande kvantiseringsfalt'
        }
    }
    [pscustomobject]@{ name = $name; status = $status }
}
@($comparison) | ConvertTo-Json -Depth 5 |
    Set-Content -LiteralPath 'models-comparison.json' -Encoding UTF8
$comparison | Format-Table -AutoSize

En kort digest på en skärmbild räcker inte som underlag för den här metoden. Jämförelsen görs mot hela strängen från respektive JSON-fil. Resultatfilen visar bedömningen, medan originalfilerna behåller värdena som bedömningen bygger på. Behåll alla tre tillsammans med mätprotokollet. Om serveradressen skiljer sig mellan filerna behöver du först avgöra om du råkat jämföra två installationer.

Tre resultat som kräver olika beslut

Tabellen är vår bedömningsmetod, inte ett uppmätt resultat. Även ett oförändrat kvantiseringsfält är för svagt som enda identitetskontroll: två rader kan ha samma etikett i den kolumnen utan att hela digest matchar. Om digest matchar men kvantiseringsfältet skiljer sig ska avvikelsen utredas och råfilerna behållas. Förklara den inte med en påhittad modelluppdatering.

Spara modellens parametrar som ett eget underlag

Välj ett exakt namn ur din sparade lista och använd det med POST /api/show. Dokumentationen beskriver bland annat parameters som parameterinställningar i textform och details som modellens övergripande detaljer. Digest i den här arbetsgången kommer från listan, inte från detaljanropet.

$selectedName = Read-Host 'Klistra in exakt namn ur modellistan'
$payload = @{ model = $selectedName } | ConvertTo-Json
$details = Invoke-RestMethod -Method Post `
    -Uri "$($before.server_uri)/api/show" `
    -ContentType 'application/json' -Body $payload -ErrorAction Stop
$details | ConvertTo-Json -Depth 20 |
    Set-Content -LiteralPath 'model-details-before.json' -Encoding UTF8

Gör motsvarande läsning efter ändringen och byt bara filnamnets slut till after. Detaljfilerna kompletterar identitetsraderna. Spara dessutom den verkliga begäran från ditt mätprov: genererings-API:t har egna anropsfält för exempelvis prompt, systemtext och körningsalternativ. Modellens sparade parametrar beskriver därför inte ensamma vad ditt program skickade.

Samma digest garanterar inte samma svar. Slutsatsen här är smalare: identitetsraden visar ingen upptäckt skillnad i just de avlästa fälten. Fortsätt med artikeln om temperatur och seed när frågan gäller svarsvariation. Behåll serverversion, anrop, tidpunkt och modellinventering som separata delar i protokollet; då går det att se vilken del som faktiskt kontrollerades.

Källor och metod

• Ollama: List models
• Ollama: Show model details
• Ollama: CLI Reference
• Ollamas källträd: namn och taggar
• Ollama: Version
• Ollama: Generate a response

Dokumentationen kontrollerades 29 oktober 2026. Jämförelsereglerna och protokollet är redaktionella förslag. Kodens jämförelse kontrollerades med syntetiska inventeringsfiler i Windows PowerShell 5.1; ingen lokal Ollama-installation eller modelluppdatering provades. Protokollfiler är inventeringsunderlag och utgör ingen säkerhetskopia av modellen.