Hur man kontrollerar om en lokal LLM använder rätt modelfiler och lagringsväg

Lauren Pan

IceWhale author

Lauren Pan är grundaren av ZimaSpace och arkitekten bakom den hyllade ZimaBoard-serien . Genom att kombineraindustriell design med inbyggd teknik startade Lauren ZimaSpace med ett tydligt uppdrag: attdemokratisera personlig molndatabehandling . Han arbetar utifrån tron att hårdvara ska vara både"hackbar" och vacker —och därmed överbrygga klyftan mellan industriklassade servrar och konsumentprylar. Idag leder han ingenjörsteamet som bygger verktyg som ger skaparefull kontroll över sina digitala liv full control over their digital lives.

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

En lokal LLM kan svara på en prompt och ändå använda fel modellväg. Appens UI kan visa modellnamnet du förväntar dig, men runtimen kan läsa en gammal cache, en Docker-intern katalog, en standardmodellmapp eller en fil som hämtats igen någon annanstans.

Den säkraste kontrollen är inte ett kommando. Det är en kort beviskedja: jämför värdmappen, containermounten, runtime modellistan, modellmetadata, det aktiva minnestillståndet, loggarna och den faktiska lagringstillväxten. När dessa lager stämmer överens kan du vara mycket mer säker på att LLM använder rätt modelfiler och lagringsväg.

Mappen du ser är inte alltid den väg som runtimen använder

Det första misstaget är att lita på filhanterarens väg för tidigt. En NAS-mapp kan innehålla modellen du laddade ner, men det bevisar inte att den lokala LLM-runtimen kan se den eller laddar från den.

Docker lägger till ett lager till. En värdväg som /mnt/storage/ai/models kan mappas till en containerväg som /root/.ollama, och modellköraren ser bara containervägen. Dockers bind-mount-dokumentation förklarar att source är värdsidan och destination eller target är vägen inuti containern, så de två måste kontrolleras tillsammans via Docker bind mounts.

Den praktiska vägfrågan är enkel: fråga inte bara var du lade modellen. Fråga vilken väg runtime ser och vilken värdmapp den container-vägen faktiskt pekar på.

Börja med Runtimens Modellista

Innan du kontrollerar varje mapp, fråga runtime modellista vad den vet. För Ollama, börja med:

ollama list

Inuti en Docker-container, använd samma runtime-kontroll från insidan av tjänstens gräns:

docker exec -it ollama ollama list

Denna runtime-registry bekräftar att runtime har registrerat en modelletikett, men det bevisar inte fullt ut att filvägen, kvantiseringen eller lagringsplatsen är korrekt. Ollamas CLI-referens listar ollama ps för att köra modeller, medan FAQ förklarar modellens lagringskatalog och OLLAMA_MODELS-miljövariabeln i sin modellens lagringskatalog-guide.

Använd detta steg som den första kontrollpunkten, inte det slutgiltiga svaret. Om den förväntade modellen inte visas här kan appen peka på en annan runtime, modellen kan ha saknats vid import, eller den konfigurerade modellkatalogen kanske inte är den katalog som tjänsten använder.

Matcha värdvägen med containervägen

För Docker-distributioner är den viktigaste frågan om värdvägen och container-vägen faktiskt matchar. Kör:

docker inspect <container-namn>

Titta sedan på Mounts-sektionen. Source bör peka på den NAS-lagringsmapp du avsåg att använda, och Destination bör peka på modellkatalogen som används inuti containern. Dockers inspect-kommando returnerar låg-nivå objektinformation, vilket gör docker inspect Mounts till en bättre sanningskälla än minne eller skärmdumpar.

En bra Docker mount-mappning bör göra lagringsrelationen tydlig:

Lager	Exempel	Vad det betyder
Värdkälla	`/mnt/storage/ai/ollama`	Den verkliga NAS-mappen som lagrar modelldata
Containerdestination	`/root/.ollama`	Sökvägen som modellköraren ser inuti Docker
Runtime-beteende	Ollama läser `/root/.ollama`	Filerna bör växa i värddatorns källmapp

Om Källvägen pekar på Docker-root, en temporär sökväg, en gammal mapp eller en liten systemvolym kan modellen fortfarande fungera men fylla fel enhet.

Kontrollera de faktiska modelfilerna, inte bara modellnamnet

Ett modellnamn är inte samma sak som en verifierad modelfil. Samma namn kan peka på olika taggar, format, kvantiseringsnivåer, adaptrar eller cachade blobbar beroende på runtime.

För Ollama, inspektera modellmetadata med:

ollama show <model-namn> --modelfile

Inuti Docker, kör samma Modelfile-kontroll genom containern:

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

Ollama Modelfile metadata är viktigt här. Ollamas Modelfile-dokumentation förklarar att ollama show --modelfile kan visa modellens konfiguration, inklusive FROM-källan bakom modellen. För manuellt nedladdade .gguf-filer visar llama.cpp:s kvantiseringsdokumentation GGUF och format som Q4_K_M, så GGUF modelfilsmetadata är en del av verifieringen, inte bara prestandaoptimering.

Loggar berättar vilken sökväg som verkligen laddades

När användargränssnittet och filsökvägarna inte stämmer överens är loggar ofta det tydligaste beviset. De kan visa startvägar, misslyckade läsningar, behörighetsfel, saknade filer, modellnedladdningar och reservbeteende.

För Docker, använd denna kontroll av containerlogg:

docker logs <container-namn>

Dokumentationen för Docker-loggning förklarar att containerloggar vanligtvis visar containerprocessens utdata från STDOUT och STDERR, medan Ollamas felsökningssida noterar att containeriserade Ollama-loggar kan ses med docker logs.

Titta efter sökvägsledtrådar som OLLAMA_MODELS, meddelanden om modellnedladdning, misslyckade laddningsfel, behörighetsfel eller kataloger som inte matchar din avsedda lagringsmapp. Om loggar nämner en annan katalog än den du mappade, lita på loggarna och rätta sökvägen.

Bekräfta att modellen är aktiv i minnet

Nästa kontroll är aktiv modellstatus. En modell kan vara installerad eller registrerad men inte för närvarande laddad. Efter att ha skickat en kort prompt, kör omedelbart:

ollama ps

Inuti Docker, kör samma kontroll av aktiv modell inuti containern:

docker exec -it ollama ollama ps

Vad `ollama ps` Kan bevisa

ollama ps visar vilka modeller som för närvarande är laddade. Ollamas FAQ förklarar att Processor-kolumnen kan visa om en modell är laddad på CPU, GPU eller delad mellan CPU och GPU, vilket hjälper till att bekräfta den aktiva körningstillståndet snarare än bara modellbiblioteket.

Detta är användbart när du behöver veta om den förväntade modellen är aktiv nu, om den stannar i minnet och om den använder den förväntade processorvägen. Det är särskilt hjälpsamt efter att ha bytt modeller, ändrat taggar eller testat GPU-/CPU-beteende.

Vad det inte kan bevisa

ollama ps bevisar inte värdmappningen av mappen i sig. Det kan visa att en modell är aktiv, men du behöver fortfarande docker inspect, modellmetadata, loggar och kontroller av lagringstillväxt för att bevisa att den kom från den avsedda sökvägen.

Det bevisar inte heller att en anpassad modellfil har exakt den kvantisering eller källa du förväntade dig. För det, använd metadata-kontroller, inspektion av Modelfile och filnivåverifiering.

Varningssignaler att modellvägen är fel

En felaktig modellväg visar vanligtvis symtom innan det blir uppenbart. Det vanligaste tecknet är oförklarlig tillväxt av disken på startdisken, Docker-rooten eller en appdatavolym som du inte avsåg att använda.

Var uppmärksam på dessa signal för vägfel:

Appen visar modellen, men din avsedda modellmapp växer inte.
docker inspect visar en källväg som skiljer sig från din NAS-lagringsmapp.
Modellen laddas ner igen efter att du trodde att den redan fanns.
Loggar nämner en standardmodellkatalog istället för din anpassade väg.
ollama list visar en annan tagg eller storlek än du förväntade dig.
ollama show --modelfile pekar på en annan bas eller blob än förväntat.
ollama ps visar en oväntad aktiv modell efter en prompt.
Startenheten förlorar utrymme efter varje modellhämtning.

Om två verifieringslager inte stämmer överens, förenkla testet. Stoppa containern, verifiera monteringen, starta om tjänsten, hämta en liten känd modell och kontrollera vilken katalog som växer.

En renare verifieringsordning för lokal LLM-lagring

Använd en fast verifieringsordning istället för att kontrollera slumpmässiga mappar. Detta förhindrar förväxling av värdvägar, containervägar, appvägar och runtime-vägar.

Bekräfta den avsedda värdlager-mappen.
Kontrollera ledigt utrymme på system- och modell-enheten.
Kör docker inspect <container-namn> och verifiera Källa / Destination.
Kontrollera runtime-modellistan med ollama list.
Hämta eller importera en liten känd modell.
Kör du -sh <modell-mapp> före och efter nedladdningen.
Inspektera metadata med ollama show <model-namn> --modelfile.
Skicka en kort prompt.
Kör ollama ps för att bekräfta den aktiva modellen.
Läs container- eller tjänsteloggar för ledtrådar om väg, nedladdning eller behörigheter.

En ren lagringsverifiering bör sluta med att alla lager pekar på samma plats: modellmappen växer på den förväntade enheten, containermonteringen pekar på den mappen, runtime listar modellen, metadata matchar den förväntade filen, loggar visar inga vägfel och den aktiva modellen är den du just testade.

Vad ZimaOS AI-sökning visar om synliga modellvägar

En kontrollerad lokal AI-funktion bör göra sin modellväg, nedladdningsstatus, resursanvändning och loggar tillräckligt synliga för att verifiera. Annars lämnas användarna att gissa om AI-tjänsten faktiskt använder de förväntade modelfilerna.

ZimaOS-AI är ett användbart exempel. ZimaSpace-guiden för AI-sökning förklarar att AI-modulen använder en lokal LLM för att extrahera funktioner från bilder, ljud och video för ZimaOS-sökning. Samma korta anteckning nämner att modelfiler lagras i /media/ZimaOS-HD/AppData/.models, och om AppData har migrerats följer den faktiska lagringsanvändningen den migrerade AppData-platsen.

Guiden beskriver också driftskontroller som automatiska modellnedladdningar, intervall för funktionsutvinning, samtalshistorik, nätverkstrafikkontroller och journalctl -xef -u zimaos-ai för felsökning. Det är precis de signaler som en lokal AI-arbetsbelastning behöver: synlig sökväg, synligt nedladdningsbeteende, synliga loggar och synligt körningstillstånd.

För en privat molnlösning som ZimaCube 2 är detta den större lärdomen: lokal AI bör inte vara en svart låda. Oavsett om arbetsbelastningen är sökning, chatt, inbäddningar eller medieanalys, bör modellvägen och körningstillståndet vara lätta att verifiera.

Vanliga frågor

Hur vet jag var Ollama lagrar modellfiler?

Kontrollera Ollamas standard modellkatalog för ditt operativsystem och se sedan om OLLAMA_MODELS har ändrat den. På Docker, inspektera även containerns montering så att du vet vilken värdmapp som kopplas till körningens modellkatalog.

Hur kontrollerar jag om Docker använder rätt modellmapp?

Kör docker inspect <container-namn> och granska avsnittet Mounts. Källan bör vara den NAS-lagringsväg du avsåg, och destinationen bör vara modellkatalogen som används inuti containern.

Vad är `manifester` och `blobs` i en Ollama-modellkatalog?

I en Ollama-stil modellkatalog beskriver manifester modellmetadata och referenser, medan blobs innehåller de större modellfilerna. Om blobs-mappen växer efter att en modell hämtats är det ett starkt tecken på att denna katalog används för modelllagring.

Hur kan jag se vilken modell som är laddad just nu?

Skicka en kort prompt och kör sedan ollama ps. Den visar den för närvarande laddade modellen och processorstatusen, vilket hjälper till att bekräfta om den förväntade modellen är aktiv i CPU, GPU eller en CPU/GPU-fördelning.

Varför visar appen modellen men filvägen verkar ändå fel?

Appen kan läsa en körregistret, en cachelagrad modell, en Docker-intern sökväg eller en annan modellkatalog än den du kontrollerar i filhanteraren. Verifiera körlistan, Docker-monteringen, metadata, loggar och faktisk lagringstillväxt innan du litar på användargränssnittet.

En lokal LLM-sökvägskontroll är klar först när värdlagringsvägen, containerdestinationen, listan över körmodeller, modellmetadata, aktivt minnestillstånd, loggar och diskens tillväxt alla stämmer överens. Om ett lager pekar någon annanstans, rätta sökvägen innan du laddar ner fler modeller eller ansluter fler appar.