Hoe controleer je of een lokale LLM de juiste modelfiles en opslaglocatie gebruikt?

Lauren Pan

IceWhale author

Lauren Pan is de oprichter van ZimaSpace en de ontwerper achter de befaamde ZimaBoard-serie. Door industrieel ontwerp te combineren met embedded engineering, lanceerde Lauren ZimaSpace met een duidelijke missie: persoonlijke cloud computing democratiseren. Hij gelooft dat hardware zowel "hackbaar" als mooi moet zijn—de kloof tussen industriële servers en consumentengadgets overbruggend. Tegenwoordig leidt hij het engineeringteam dat tools ontwikkelt die makers volledige controle geven over hun digitale leven.

How to Check If a Local LLM Uses the Right Model Files and Storage Path - Zima Store Online

Een lokale LLM kan een prompt beantwoorden en toch het verkeerde modelpad gebruiken. De app-UI kan de modelnaam tonen die je verwacht, maar de runtime kan een oude cache lezen, een Docker-interne map, een standaard modelmap of een bestand dat ergens anders opnieuw is opgehaald.

De veiligste controle is niet één commando. Het is een korte bewijsketen: vergelijk de hostmap, de container-mount, de runtime-modellenlijst, de modelmetadata, de actieve geheugenstatus, de logs en de daadwerkelijke opslaggroei. Wanneer die lagen overeenkomen, kun je veel zekerder zijn dat de LLM de juiste modelbestanden en opslaglocatie gebruikt.

De map die je ziet is niet altijd het pad dat de runtime gebruikt

De eerste fout is te vroeg vertrouwen op het bestandbeheerderpad. Een NAS-map kan het model bevatten dat je hebt gedownload, maar dat bewijst niet dat de lokale LLM-runtime het kan zien of ervan laadt.

Docker voegt een extra laag toe. Een hostpad zoals /mnt/storage/ai/models kan worden gekoppeld aan een containerpad zoals /root/.ollama, en de modelrunner ziet alleen het containerpad. De documentatie over Docker bind mounts legt uit dat source het hostpad is en destination of target het pad binnen de container, dus deze moeten samen worden gecontroleerd via Docker bind mounts.

De praktische padvraag is eenvoudig: vraag niet alleen waar je het model hebt geplaatst. Vraag welk pad de runtime ziet en naar welke hostmap dat containerpad daadwerkelijk verwijst.

Begin met de modellenlijst van de runtime

Voordat je elke map controleert, vraag je de runtime-modellenlijst wat deze weet. Voor Ollama begin je met:

ollama list

Binnen een Docker-container gebruik je dezelfde runtime-check vanuit de servicegrens:

docker exec -it ollama ollama list

Deze runtime-register bevestigt dat de runtime een modeltag heeft geregistreerd, maar bewijst niet volledig dat het bestandspad, de kwantisatie of de opslaglocatie correct is. De CLI-referentie van Ollama vermeldt ollama ps voor het uitvoeren van modellen, terwijl de FAQ de modelopslagmap en de OLLAMA_MODELS omgevingsvariabele uitlegt in de modelopslagmap richtlijnen.

Gebruik deze stap als de eerste controlepunt, niet als het definitieve antwoord. Als het verwachte model hier niet verschijnt, kan de app naar een andere runtime verwijzen, is het model mogelijk niet geïmporteerd, of is de geconfigureerde modelmap niet de map die de service gebruikt.

Match het hostpad met het containerpad

Voor Docker-implementaties is de belangrijkste vraag of het hostpad en het containerpad daadwerkelijk overeenkomen. Voer uit:

docker inspect <container-naam>

Bekijk dan de Mounts-sectie. De Source moet wijzen naar de NAS-opslagmap die je wilde gebruiken, en de Destination moet wijzen naar de modelmap die binnen de container wordt gebruikt. De inspect-opdracht van Docker geeft laag-niveau objectinformatie terug, waardoor docker inspect Mounts een betrouwbaardere bron is dan geheugen of screenshots.

Een goede Docker-mountmapping moet de opslagrelatie duidelijk maken:

Laag	Voorbeeld	Wat het betekent
Hostbron	`/mnt/storage/ai/ollama`	De echte NAS-map die modelgegevens opslaat
Containerbestemming	`/root/.ollama`	Het pad dat de modelrunner binnen Docker ziet
Runtime-gedrag	Ollama leest `/root/.ollama`	Bestanden moeten groeien in de host-bronmap

Als het bronpad wijst naar de Docker-root, een tijdelijk pad, een oude map of een kleine systeemvolume, kan het model nog steeds werken terwijl het de verkeerde schijf vult.

Controleer de werkelijke modelbestanden, niet alleen de modelnaam

Een modelnaam is niet hetzelfde als een geverifieerd modelbestand. Dezelfde naam kan verwijzen naar verschillende tags, formaten, quantisatieniveaus, adapters of gecachte blobs afhankelijk van de runtime.

Inspecteer voor Ollama de modelmetadata met:

ollama show <model-naam> --modelfile

Voer binnen Docker dezelfde Modelfile-controle uit via de container:

docker exec -it ollama ollama show <model-naam> --modelfile

Ollama Modelfile-metadata is hier belangrijk. De Modelfile-documentatie van Ollama legt uit dat ollama show --modelfile de configuratie van het model kan tonen, inclusief de FROM-bron achter het model. Voor handmatig gedownloade .gguf-bestanden toont de quantisatiedocumentatie van llama.cpp GGUF en formaten zoals Q4_K_M, dus GGUF-modelbestand-metadata is onderdeel van verificatie, niet alleen prestatieafstemming.

Logs vertellen je welk pad echt geladen is

Wanneer de UI en bestandsroutes het niet eens zijn, zijn logs vaak het duidelijkste bewijs. Ze kunnen opstartpaden, mislukte leespogingen, machtigingsfouten, ontbrekende bestanden, modeldownloads en fallback-gedrag tonen.

Gebruik voor Docker deze containerlog-controle:

docker logs <container-naam>

De Docker logging documentatie legt uit dat containerlogs meestal de uitvoer van het containerproces van STDOUT en STDERR blootleggen, terwijl de probleemoplossingspagina van Ollama opmerkt dat containerized Ollama-logs kunnen worden bekeken met docker logs.

Let op pad aanwijzingen zoals OLLAMA_MODELS, model downloadberichten, mislukte laadfouten, machtigingsfouten of mappen die niet overeenkomen met je bedoelde opslagmap. Als logs een andere map noemen dan degene die je hebt gekoppeld, vertrouw dan op de logs en corrigeer het pad.

Bevestig dat het model actief is in het geheugen

De volgende controle is de actieve modelstatus. Een model kan geïnstalleerd of geregistreerd zijn maar niet momenteel geladen. Na het verzenden van een korte prompt, voer onmiddellijk uit:

ollama ps

Voer binnen Docker dezelfde controle van actief model uit binnen de container:

docker exec -it ollama ollama ps

Wat `ollama ps` Kan bewijzen

ollama ps toont welke modellen momenteel geladen zijn. De FAQ van Ollama legt uit dat de Processor-kolom kan laten zien of een model op CPU, GPU of verdeeld over CPU en GPU is geladen, wat helpt de actieve runtime-status te bevestigen in plaats van alleen de modellibrary.

Dit is nuttig wanneer je wilt weten of het verwachte model nu actief is, of het in het geheugen blijft en of het het verwachte processorpad gebruikt. Het is vooral handig na het wisselen van modellen, het wijzigen van tags of het testen van GPU / CPU-gedrag.

Wat het niet kan bewijzen

ollama ps bewijst op zichzelf niet de host map-mapping. Het kan laten zien dat een model actief is, maar je hebt nog steeds docker inspect, modelmetadata, logs en opslaggroeicontroles nodig om te bewijzen dat het van het bedoelde pad komt.

Het bewijst ook niet dat een aangepast modelfile precies de kwantisatie of bron heeft die je verwachtte. Gebruik daarvoor metadata-controles, inspectie van het modelfile en verificatie op bestandsniveau.

Waarschuwingssignalen dat het modelpad verkeerd is

Een verkeerde modelpad veroorzaakt meestal eerst symptomen voordat het duidelijk wordt. Het meest voorkomende teken is onverklaarbare schijfgroei op de opstartschijf, Docker root, of een app-gegevensvolume dat je niet van plan was te gebruiken.

Let op deze pad-mismatch signalen:

De app toont het model, maar de bedoelde modelfolder groeit niet.
docker inspect toont een Bron-pad anders dan jouw NAS-opslagmap.
Het model wordt opnieuw gedownload terwijl je dacht dat het al aanwezig was.
Logs vermelden een standaard modelmap in plaats van jouw aangepaste pad.
ollama list toont een andere tag of grootte dan verwacht.
ollama show --modelfile wijst naar een andere basis of blob dan verwacht.
ollama ps toont een onverwacht actief model na een prompt.
De opstartschijf verliest ruimte na elke modeldownload.

Als twee verificatielagen het oneens zijn, vereenvoudig de test. Stop de container, verifieer de mount, herstart de service, download een klein bekend model en controleer welke map groeit.

Een schonere verificatievolgorde voor lokale LLM-opslag

Gebruik een vaste verificatievolgorde in plaats van willekeurige mappen te controleren. Dit voorkomt verwarring tussen hostpaden, containerpaden, app-paden en runtime-paden.

Bevestig de bedoelde host-opslagmap.
Controleer vrije ruimte op de systeemschijf en de modelschijf.
Uitvoeren docker inspect <container-naam> en verifieer Bron / Bestemming.
Controleer de runtime-modellenlijst met ollama list.
Download of importeer een klein bekend model.
Uitvoeren du -sh <model-folder> voor en na het downloaden.
Inspecteer metadata met ollama show <model-naam> --modelfile.
Stuur een korte prompt.
Uitvoeren ollama ps om het actieve model te bevestigen.
Lees container- of servicelogs voor aanwijzingen over paden, downloads of permissies.

Een duidelijke opslagverificatie moet eindigen met alle lagen die naar dezelfde plek wijzen: de modelfolder groeit op de verwachte schijf, de container mount wijst naar die folder, de runtime toont het model, metadata komt overeen met het verwachte bestand, logs tonen geen padfouten en het actieve model is degene die je net hebt getest.

Wat ZimaOS AI Search laat zien over zichtbare modelpaden

Een gecontroleerde lokale AI-functie moet zijn modelpad, downloadstatus, resourcegebruik en logs voldoende zichtbaar maken om te verifiëren. Anders blijven gebruikers raden of de AI-service daadwerkelijk de verwachte modelbestanden gebruikt.

ZimaOS-AI is een nuttig voorbeeld. De ZimaSpace-gids voor AI-zoekfunctie legt uit dat de AI-module een lokale LLM gebruikt om kenmerken uit afbeeldingen, audio en video te halen voor ZimaOS-zoekopdrachten. In dezelfde korte notitie staat dat modelbestanden worden opgeslagen in /media/ZimaOS-HD/AppData/.models, en als AppData is gemigreerd, volgt het daadwerkelijke opslaggebruik de gemigreerde AppData-locatie.

De gids beschrijft ook bedrijfscontroles zoals automatische modeldownloads, intervallen voor feature-extractie, Call-History, netwerkverkeerscontroles en journalctl -xef -u zimaos-ai voor probleemoplossing. Dit zijn precies de signalen die een lokale AI-werklast nodig heeft: zichtbaar pad, zichtbaar downloadgedrag, zichtbare logs en zichtbare runtime-status.

Voor een privécloudopstelling zoals ZimaCube 2 is dit de belangrijkste les: lokale AI mag geen blackbox zijn. Of de werklast nu zoeken, chatten, embeddings of media-analyse is, het modelpad en de runtime-status moeten eenvoudig te verifiëren zijn.

FAQ

Hoe weet ik waar Ollama modelbestanden opslaat?

Controleer Ollama’s standaard modelmap voor je besturingssysteem en kijk of OLLAMA_MODELS dit heeft gewijzigd. Controleer bij Docker ook de container-mount zodat je weet welke hostmap naar de runtime-modelmap wordt gemapt.

Hoe controleer ik of Docker de juiste modelmap gebruikt?

Voer docker inspect <container-naam> uit en bekijk de sectie Mounts. De Source moet het NAS-opslagpad zijn dat je bedoelde, en de Destination moet de modelmap zijn die binnen de container wordt gebruikt.

Wat zijn `manifests` en `blobs` in een Ollama-modelmap?

In een Ollama-stijl modelmap beschrijven manifests modelmetadata en verwijzingen, terwijl blobs de grotere modelpayloadbestanden bevatten. Als de blobs-map groeit na het ophalen van een model, is dat een sterk teken dat deze map wordt gebruikt voor modelopslag.

Hoe kan ik zien welk model momenteel geladen is?

Stuur een korte prompt en voer dan ollama ps uit. Dit toont het momenteel geladen model en de processorstatus, wat helpt bevestigen of het verwachte model actief is op CPU, GPU of een CPU/GPU-splitsing.

Waarom toont de app het model, maar lijkt het bestandspad toch verkeerd?

De app kan een runtime-register, een gecached model, een intern Docker-pad of een andere modelmap lezen dan degene die je controleert in de bestandsbeheerder. Controleer de runtime-lijst, Docker-mount, metadata, logs en daadwerkelijke opslaggroei voordat je de gebruikersinterface vertrouwt.

Een lokale LLM-padcontrole is pas voltooid wanneer het hostopslagpad, de containerbestemming, de runtime-modellenlijst, modelmetadata, actieve geheugenstatus, logs en schijfgroei allemaal overeenkomen. Als één laag ergens anders naar wijst, corrigeer dan het pad voordat je meer modellen downloadt of meer apps verbindt.