Model-updates lokaal bijhouden: van welke versie draai je

In het lokale AI-traject bevindt het bijhouden van model-updates zich in de fase van beheren en onderhouden, direct volgend op het kiezen, installeren en operationeel inrichten van de software. Wie begint met lokale taalmodellen, start vaak met de basisprincipes die worden uitgelegd in de gids over hardware voor lokale LLM's om te bepalen hoeveel rekenkracht nodig is. Vervolgens doorloop je een platforminstallatie zoals beschreven in de handleiding over Ollama installeren op macOS om de eerste prompts lokaal uit te voeren. Zodra deze basis staat en applicaties of scripts afhankelijk worden van de modeluitvoer, ontstaat een nieuw operationeel vraagstuk: hoe weet je exact welke modelgewichten er draaien en hoe voorkom je dat een automatische update je werkprocessen verstoort?

In tegenstelling tot commerciële clouddiensten waar leveranciers onaangekondigde modelwijzigingen doorvoeren achter een vaste API-eindpuntnaam, heb je lokaal de volledige controle over de binaire bestanden. Die controle brengt echter de verantwoordelijkheid met zich mee om zelf een strikt versiebeheer te hanteren. Een ogenschijnlijk eenvoudig commando zoals ollama pull llama3.1 kan op de achtergrond de binaire representatie van het model overschrijven, waardoor prompt-templates breken, kwantisatie-artefacten veranderen of gestructureerde JSON-uitvoer faalt.

De anatomie van een lokaal model: tags, digests en GGUF-bestanden

Om te begrijpen wat er gebeurt tijdens een update, moeten we kijken naar hoe lokale runtime-omgevingen modellen opslaan. Een lokaal model bestaat uit meer dan alleen ruwe parameters; het omvat een tensor-layout, tokeniser-vocabulaire, chat-templates en kwantisatiemetadata. Raadpleeg het overzicht over lokale modellen downloaden en beheren voor inzicht in hoe modelbestanden opgeslagen en georganiseerd worden op je schijf.

Binnen Ollama werkt het opslagsysteem met manifests en blobs, vergelijkbaar met Docker-images. Wanneer je een model downloadt onder een algemene tag zoals qwen2.5:7b of llama3.1:latest, wijst deze tag naar een specifiek manifestbestand. Dit manifest bevat SHA256-hashes (digests) voor de afzonderlijke lagen: de modelparameters, de template, de systeemparameters en het Modelfile. Als de makers van het model een revisie uitbrengen — bijvoorbeeld een bugfix in de chat-template of een alternatieve kwantisatielaag — wijzigt de maker het manifest in het centrale register. Voer je vervolgens opnieuw een pull-opdracht uit, dan overschrijft de lokale tagreferentie de oude digest zonder dat de tagnaam verandert.

Bij llama.cpp en LM Studio werk je doorgaans rechtstreeks met GGUF-bestanden. Hier is de bestandsnaam vaak misleidend. Een bestand genaamd mistral-7b-instruct-v0.3.Q4_K_M.gguf vertelt weliswaar welk kwantisatietype gebruikt is, maar niet welke specifieke git-commit van de brongewichten ten grondslag ligt aan de conversie. Wie de theoretische werking van modelcompressie wil begrijpen, leest de uitleg in het artikel over kwantisatie van LLM's, waarin de compressie van zwevendekommavariabelen naar 4- of 8-bit integers gedetailleerd wordt behandeld.

Waarom modelregressie optreedt na lokale updates

Bij traditionele software levert een patch release (van 1.2.1 naar 1.2.2) meestal bugfixes op zonder de API-contracten te verbreken. Bij neurale netwerken werkt dit fundamenteel anders. Een kleine herberekening van de weights of een minieme wijziging in de stop-tokens kan ingrijpende gevolgen hebben voor de betrouwbaarheid van je lokale pipeline:

• Verschuiving van prompt-gevoeligheid: Een instructietune die beter scoort op algemene benchmarks kan ineens minder strikt omgaan met vaste systeemprompts of markdown-opmaak.
• Gewijzigde chat-templates: Als de scheidingstekens tussen de gebruikersinvoer en het systeembericht veranderen (bijvoorbeeld van <|im_start|> naar [INST]), kan het model zijn rol vergeten of tekst hallucineren.
• Afwijkende tokenisatie: Wanneer speciale tokens voor regeleindes of codestructuren anders worden geïnterpreteerd, lopen parser-scripts vast die JSON-uitvoer valideren.
• Kwantisatie-verschillen: Een overstap van een traditionele Q4_K_M kwantisatie naar een optimalere iMatrix-kwantisatie verbetert over het algemeen de perplexiteit, maar kan op specifieke domeintaken afwijken van eerdere antwoorden.

Wie professioneel bouwt aan autonome AI-systemen leest in het diepgaande leertraject over AI agent engineer worden in 2026 waarom determinisme en versie-immutability onmisbaar zijn bij het ontwerpen van betrouwbare agent-lussen en tool-integraties. Zonder vastgepinde modelversies is het opsporen van fouten in complexe multi-step workflows vrijwel onmogelijk.

Inspecteren van de actieve modelversie in de praktijk

Om met zekerheid vast te stellen welke gewichten op dit moment worden uitgevoerd door je lokale server, volstaat het niet om af te gaan op de tagnaam. We moeten de onderliggende hash inspecteren.

Binnen Ollama kun je gedetailleerde layer-informatie opvragen met het commando ollama show. Dit toont niet alleen de parameters, maar ook het exacte Modelfile en de licentiedetails:

# Vraag de eigenschappen en template op van het actieve model
ollama show --modelfile llama3.1:8b

# Toon alle lokaal opgeslagen model-manifests inclusief unieke ID
ollama list

Onder water kun je het specifieke JSON-manifest inspecteren op je bestandssysteem. Op Linux en macOS staat dit standaard in de thuismap onder ~/.ollama/models/manifests/registry.ollama.ai/library/. Een manifest ziet er als volgt uit:

{
  "schemaVersion": 2,
  "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
  "config": {
    "mediaType": "application/vnd.docker.container.image.v1+json",
    "digest": "sha256:87048abc452f357f83693e507b98d28e7e17424b918f6",
    "size": 486
  },
  "layers": [
    {
      "mediaType": "application/vnd.ollama.image.model",
      "digest": "sha256:6a0746a1ec1a7e3e30ab81682f24b20a0680cb18a",
      "size": 4920743936
    },
    {
      "mediaType": "application/vnd.ollama.image.template",
      "digest": "sha256:0ba8f0e314b4f123456789abcdef0123456789ab",
      "size": 743
    }
  ]
}

De digest van de model-laag (sha256:6a0746a1...) is de cryptografische vingerafdruk van de GGUF-gewichten. Zolang deze hash ongewijzigd blijft, weet je 100% zeker dat de rekenkern van het model identiek is, ongeacht eventuele updates in de externe bibliotheek.

Versies vastzetten met custom Modelfiles

De veiligste manier om ongewenste overschrijvingen te voorkomen, is het loskoppelen van je productiemodellen van upstream tags. Dit doe je door een eigen modelnaam aan te maken op basis van een geëxpliceerde configuratie. Zie het artikel over de Ollama Modelfile aanpassen voor een complete handleiding over het instellen van parameters en templates.

Door het basismodel te kopiëren naar een expliciete release-tag (bijvoorbeeld met een datum of versienummer), voorkom je dat een algemene ollama pull het model overschrijft:

# 1. Maak een bevroren kopie aan onder een onveranderlijke tagnaam
ollama cp llama3.1:8b prod-llama-3.1-8b-20260815

# 2. Of bouw een expliciet Modelfile gebaseerd op een lokaal GGUF-bestand
cat << 'EOF' > Modelfile.production
FROM ./models/llama-3.1-8b-instruct-q4_k_m.gguf
PARAMETER temperature 0.2
PARAMETER top_p 0.9
PARAMETER stop "<|eot_id|>"
TEMPLATE """{{ if .System }}<|start_header_id|>system<|end_header_id|>

{{ .System }}<|eot_id|>{{ end }}{{ if .Prompt }}<|start_header_id|>user<|end_header_id|>

{{ .Prompt }}<|eot_id|>{{ end }}<|start_header_id|>assistant<|end_header_id|>

{{ .Response }}<|eot_id|>"""
EOF

# 3. Compileer het model naar een strikt geïsoleerde tag
ollama create custom-llama3-frozen:v1 -f Modelfile.production

Door in je applicaties, scripts of lokale agents uitsluitend te communiceren met custom-llama3-frozen:v1, bescherm je de stabiliteit van je productie-omgeving. Zelfs als Ollama op de achtergrond wordt bijgewerkt naar een nieuwere applicatieversie, blijft de definitie van dit model intact.

Regressietesten: valideren vóór acceptatie

Voordat we een nieuwe modelversie toelaten tot onze dagelijkse workflow, moeten we objectief vaststellen of de nieuwe versie daadwerkelijk beter presteert en geen regressie vertoont op onze specifieke taken. Het blind vertrouwen op publieke leaderboards is riskant, omdat deze algemene kennis meten en geen rekening houden met specifieke Nederlandse zinsconstructies of aangepaste extractie-taken.

Voor diepere conceptuele achtergronden over gestructureerd testen verwijzen we naar het artikel over regressietesten voor prompts op het benchmark-subdomein, waarin testsuites voor modelmigraties worden ontworpen. Lokaal voeren we een compacte validatiesuite uit met een vast testbestand:

#!/usr/bin/env python3
"""
Eenvoudig lokaal regressietest-script voor modelvalidatie.
Draait een vaste set prompts tegen een lokaal endpoint en verifieert uitvoer.
"""
import urllib.request
import json
import time

ENDPOINT = "http://localhost:11434/api/generate"
CANDIDATE_MODEL = "llama3.1:8b"

TEST_CASES = [
    {
        "name": "JSON Structured Output Test",
        "prompt": "Geef de hoofdstad van Nederland en België in geldig JSON-formaat: {\"nl\": \"...\", \"be\": \"...\"}. Geef UITSLUITEND JSON.",
        "must_contain": ["Amsterdam", "Brussel", "nl", "be"]
    },
    {
        "name": "Nederlandse Grammatica & Instructie",
        "prompt": "Vertaal naar foutloos zakelijk Nederlands: 'The deployment failed due to an unhandled exception in the database layer.'",
        "must_contain": ["implementatie", "uitzondering", "databoselaag"] # flexibele verificatie
    }
]

def run_test(test):
    payload = json.dumps({
        "model": CANDIDATE_MODEL,
        "prompt": test["prompt"],
        "stream": False,
        "options": {"temperature": 0.0}
    }).encode("utf-8")
    
    req = urllib.request.Request(ENDPOINT, data=payload, headers={"Content-Type": "application/json"})
    t0 = time.time()
    try:
        with urllib.request.urlopen(req) as resp:
            data = json.loads(resp.read().decode("utf-8"))
            elapsed = time.time() - t0
            response_text = data.get("response", "")
            
            # Controleer inhoudelijke verwachtingen
            passed = all(item.lower() in response_text.lower() for item in test["must_contain"])
            return passed, elapsed, response_text
    except Exception as e:
        return False, 0.0, str(e)

print(f"Start validatietest voor kandidaat-model: {CANDIDATE_MODEL}\n" + "-"*60)
for t in TEST_CASES:
    success, duration, out = run_test(t)
    status = "GESLAAGD" if success else "GEFAALD"
    print(f"Test: {t['name']} -> [{status}] in {duration:.2f}s")
    if not success:
        print(f"  Foutieve uitvoer:\n{out[:200]}...")

Wanneer een model feitelijke onjuistheden genereert na een update, is het essentieel om kritisch te blijven evalueren; bekijk hiervoor het artikel over AI-antwoorden factchecken voor beproefde methoden om hallucinaties en feitelijke fouten systematisch te ontmaskeren.

Opslagbeheer en een veilige rollback-strategie

Lokale modellen vergen aanzienlijke schijfruimte. Een 7B-parameter model op Q4_K_M kwantisatie neemt circa 4,5 tot 5,0 GB in beslag, terwijl een 70B-model al snel 40 tot 45 GB aan snelle NVMe-opslag opeist. Wie onzorgvuldig updates downloadt, ziet de schijf binnen enkele weken vollopen met verouderde blobs die niet meer actief gebruikt worden.

Een doordacht opslag- en herstelbeleid is noodzakelijk. Lees in de handleiding over backup-strategieën voor lokale modellen hoe je modelgewichten, vector-indexen en configuratiebestanden efficiënt scheidt en archiveert zonder overtollige schijfvervuiling.

Bij het opschonen van niet-gekoppelde lagen binnen Ollama gebruik je het prune-mechanisme. Let op: verwijder nooit handmatig bestanden uit de blob-directory, omdat dit de interne manifest-index corrupt maakt.

# Verwijder een specifieke verouderde model-tag
ollama rm llama3:8b-instruct-q4-old

# Controleer de schijfruimte op Linux/macOS
du -sh ~/.ollama/models/

Voor een voorspelbare rollback-strategie hanteren we het N-1 principe: houd altijd minimaal één geverifieerde, oudere generatie van het model bewaard onder een unieke tagnaam. Mocht het nieuwste model in productie onverwachte fouten vertonen bij token-limits of latency, dan volstaat het aanpassen van de configuratie-omgevingsvariabele naar de N-1 tag om binnen enkele seconden zonder downtime terug te schakelen.

Privacy, netwerkverkeer en telemetrie bij het updaten

Het fundament onder het lokaal draaien van taalmodellen is data-soevereiniteit en privacy. Zodra je echter een update-commando start, maakt de runtime contact met externe registers (zoals de Ollama Registry, Hugging Face Hub of GitHub Releases). Raadpleeg het document over privacyvriendelijk AI gebruiken voor een overzicht van netwerkisolatie en dataveiligheid op lokale machines.

Tijdens een pull verzendt je machine metadata zoals het IP-adres, de client-versie en de opgevraagde modeltag naar het centrale register. In zakelijke of privacygevoelige omgevingen verdient het aanbeveling om updates uitsluitend uit te voeren via een afgeschermde staging-server, de binaire GGUF-bestanden lokaal te scannen op integriteit via SHA256-checksums, en deze vervolgens via een lokaal netwerkpad of interne Docker Registry te distribueren naar de productiemachines.

Ook in een huishoudelijke setting is zorgvuldig beheer van belang. In het overzicht over AI veilig thuis gebruiken wordt uitgelegd hoe gezinnen en thuisgebruikers lokale modellen kunnen inzetten zonder dat privégegevens of surfgedrag worden gedeeld met externe cloudplatforms.

Wie op de hoogte wil blijven van bredere wijzigingen in het open-source ecosysteem raadpleegt de overzichtspagina over modelupdates en deprecaties bijhouden op het hub-subdomein, waar release-cycli van toonaangevende open architecturen structureel worden geanalyseerd.

Checklist voor gecontroleerd model-updatebeheer

Voordat je een update doorvoert op een lokaal systeem, helpt het doorlopen van een vaste controlelijst om verrassingen te voorkomen:

1. Identificeer de huidige status: Noteer de actieve digest-hash via ollama show of bereken de SHA256-hash van je GGUF-bestand met sha256sum model.gguf.
2. Isoleer de download: Haal de nieuwe versie binnen onder een expliciete kandidaat-tag (bijvoorbeeld kandidaat-model:v2) in plaats van de productietag te overschrijven.
3. Controleer de hardware-eisen: Verifieer of de contextlengte en parameters niet zijn gewijzigd; een modelupdate kan door een andere contextstructuur ongemerkt meer VRAM vereisen waardoor offloading naar CPU-geheugen plaatsvindt.
4. Voer de regressietest uit: Draai een geautomatiseerde testsuite met vaste prompts op nul-temperatuur om deterministische antwoorden te vergelijken.
5. Bevries de definitie: Maak een lokaal Modelfile aan met vaste parameters en wijs de productietag pas toe nadat alle tests succesvol zijn afgerond.
6. Behoud de N-1 backup: Verwijder de voorgaande modelversie pas nadat de nieuwe versie zich minimaal twee weken probleemloos heeft bewezen in je actieve werkprocessen.

Door deze systematische aanpak te hanteren, profiteer je direct van de snelle ontwikkelingen in open-source AI zonder in te leveren op de stabiliteit en voorspelbaarheid van je lokale infrastructuur.