Wie überprüft man, ob ein lokales LLM die richtigen Modell-Dateien und den richtigen Speicherpfad verwendet?

Lauren Pan

IceWhale author

Lauren Pan ist der Gründer von ZimaSpace und der Architekt hinter der renommierten ZimaBoard-Serie. Lauren verbindet Industriedesign mit Embedded Engineeringund gründete ZimaSpace mit einer klaren Mission: die Demokratisierung der persönlichen Cloud-Computing. Er ist überzeugt, dass Hardware sowohl "hackbar" als auch schön sein sollte— und so die Kluft zwischen industriellen Servern und Konsumgütern schließt. Heute leitet er das Engineering-Team, das Werkzeuge entwickelt, die Schöpfern volle Kontrolle über ihr digitales Leben.

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

Ein lokales LLM kann eine Eingabe beantworten und dennoch den falschen Modellpfad verwenden. Die App-Oberfläche zeigt möglicherweise den erwarteten Modellnamen an, aber die Laufzeit liest möglicherweise einen alten Cache, ein Docker-internes Verzeichnis, einen Standard-Modellordner oder eine Datei, die irgendwo anders erneut heruntergeladen wurde.

Die sicherste Überprüfung ist kein einzelner Befehl. Es ist eine kurze Beweiskette: Vergleichen Sie den Host-Ordner, das Container-Mount, die Runtime-Modellliste, die Modell-Metadaten, den aktiven Speicherzustand, die Protokolle und das tatsächliche Speicherwachstum. Wenn diese Ebenen übereinstimmen, können Sie viel sicherer sein, dass das LLM die richtigen Modell-Dateien und den richtigen Speicherpfad verwendet.

Der Ordner, den Sie sehen, ist nicht immer der Pfad, den die Laufzeit verwendet

Der erste Fehler ist, dem Dateimanager-Pfad zu früh zu vertrauen. Ein NAS-Ordner kann das heruntergeladene Modell enthalten, aber das beweist nicht, dass die lokale LLM-Laufzeit es sehen oder von dort laden kann.

Docker fügt eine weitere Ebene hinzu. Ein Host-Pfad wie /mnt/storage/ai/models kann auf einen Container-Pfad wie /root/.ollama abgebildet sein, und der Modell-Runner sieht nur den Container-Pfad. Die Docker-Dokumentation zu Bind-Mounts erklärt, dass source der Host-Pfad und destination oder target der Pfad im Container ist, daher müssen beide zusammen über Docker Bind-Mounts überprüft werden.

Die praktische Pfadfrage ist einfach: Fragen Sie nicht nur, wo Sie das Modell abgelegt haben. Fragen Sie, welchen Pfad die Laufzeit sieht und auf welchen Host-Ordner dieser Container-Pfad tatsächlich zeigt.

Beginnen Sie mit der Modellliste der Laufzeit

Bevor Sie jeden Ordner überprüfen, fragen Sie die Runtime-Modellliste, was sie weiß. Für Ollama beginnen Sie mit:

ollama list

Innerhalb eines Docker-Containers verwenden Sie denselben Runtime-Check innerhalb der Service-Grenze:

docker exec -it ollama ollama list

Dieses Runtime-Register bestätigt, dass die Laufzeit einen Modell-Tag registriert hat, beweist jedoch nicht vollständig, dass der Dateipfad, die Quantisierung oder der Speicherort korrekt sind. Die CLI-Referenz von Ollama listet ollama ps für laufende Modelle auf, während die FAQ das Modell-Speicherverzeichnis und die Umgebungsvariable OLLAMA_MODELS in ihrer Anleitung zum Modell-Speicherverzeichnis erklärt.

Nutzen Sie diesen Schritt als ersten Kontrollpunkt, nicht als endgültige Antwort. Wenn das erwartete Modell hier nicht erscheint, zeigt die App möglicherweise auf eine andere Laufzeit, das Modell wurde nicht importiert oder das konfigurierte Modellverzeichnis ist nicht das Verzeichnis, das der Dienst verwendet.

Vergleichen Sie den Host-Pfad mit dem Container-Pfad

Bei Docker-Deployments ist die wichtigste Frage, ob der Host-Pfad und der Container-Pfad tatsächlich übereinstimmen. Führen Sie aus:

docker inspect <container-name>

Schauen Sie dann in den Mounts-Bereich. Die Source sollte auf den NAS-Speicherordner zeigen, den Sie verwenden wollten, und die Destination sollte auf das Modellverzeichnis im Container zeigen. Der inspect-Befehl von Docker liefert niedrigstufige Objektinformationen, weshalb docker inspect Mounts eine verlässlichere Quelle als Speicher oder Screenshots ist.

Eine gute Docker-Mount-Zuordnung sollte die Speicherbeziehung deutlich machen:

Ebene	Beispiel	Was es bedeutet
Host-Quelle	`/mnt/storage/ai/ollama`	Der echte NAS-Ordner, der die Modelldaten speichert
Container-Ziel	`/root/.ollama`	Der Pfad, den der Modell-Runner innerhalb von Docker sieht
Laufzeitverhalten	Ollama liest `/root/.ollama`	Dateien sollten im Quellordner des Hosts wachsen

Wenn der Quellpfad auf das Docker-Root, einen temporären Pfad, einen alten Ordner oder ein kleines Systemvolume zeigt, kann das Modell zwar funktionieren, aber den falschen Datenträger füllen.

Überprüfen Sie die tatsächlichen Modell-Dateien, nicht nur den Modellnamen

Ein Modellname ist nicht dasselbe wie eine verifizierte Modell-Datei. Derselbe Name kann je nach Laufzeit auf unterschiedliche Tags, Formate, Quantisierungsstufen, Adapter oder zwischengespeicherte Blobs verweisen.

Für Ollama prüfen Sie die Modell-Metadaten mit:

ollama show <model-name> --modelfile

Führen Sie innerhalb von Docker denselben Modelfile-Check über den Container aus:

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

Ollama Modelfile-Metadaten sind hier wichtig. Ollamas Modelfile-Dokumentation erklärt, dass ollama show --modelfile die Konfiguration des Modells anzeigen kann, einschließlich der FROM-Quelle hinter dem Modell. Für manuell heruntergeladene .gguf-Dateien zeigt die Quantisierungsdokumentation von llama.cpp GGUF und Formate wie Q4_K_M, sodass GGUF-Modell-Datei-Metadaten Teil der Verifizierung sind, nicht nur der Leistungsoptimierung.

Logs zeigen Ihnen, welcher Pfad tatsächlich geladen wurde

Wenn UI und Dateipfade nicht übereinstimmen, sind Logs oft der klarste Beweis. Sie können Startpfade, fehlgeschlagene Lesevorgänge, Berechtigungsfehler, fehlende Dateien, Modell-Downloads und Fallback-Verhalten zeigen.

Für Docker verwenden Sie diese Container-Log-Prüfung:

docker logs <container-name>

Die Docker-Logging-Dokumentation erklärt, dass Container-Logs normalerweise die Container-Prozessausgabe von STDOUT und STDERR zeigen, während Ollamas Troubleshooting-Seite anmerkt, dass containerisierte Ollama-Logs mit docker logs eingesehen werden können.

Achten Sie auf Pfad-Hinweise wie OLLAMA_MODELS, Modell-Download-Meldungen, Ladefehler, Berechtigungsfehler oder Verzeichnisse, die nicht mit Ihrem beabsichtigten Speicherordner übereinstimmen. Wenn Logs ein anderes Verzeichnis als das gemappte nennen, vertrauen Sie den Logs und korrigieren Sie den Pfad.

Bestätigen, dass das Modell im Speicher aktiv ist

Der nächste Check ist der aktive Modellzustand. Ein Modell kann installiert oder registriert, aber nicht aktuell geladen sein. Nach dem Senden einer kurzen Eingabeaufforderung sofort ausführen:

ollama ps

Führen Sie innerhalb von Docker denselben Check des aktiven Modells im Container aus:

docker exec -it ollama ollama ps

Was `ollama ps` Kann beweisen

ollama ps zeigt, welche Modelle aktuell geladen sind. Ollamas FAQ erklärt, dass die Processor-Spalte anzeigen kann, ob ein Modell auf CPU, GPU oder aufgeteilt auf CPU und GPU geladen ist, was hilft, den aktiven Laufzeitstatus zu bestätigen und nicht nur die Modellbibliothek.

Dies ist nützlich, wenn Sie wissen müssen, ob das erwartete Modell gerade aktiv ist, ob es im Speicher bleibt und ob es den erwarteten Prozessorpfad verwendet. Besonders hilfreich nach Modellwechsel, Tag-Änderungen oder Tests des GPU-/CPU-Verhaltens.

Was es nicht beweisen kann

ollama ps beweist nicht allein die Host-Ordner-Zuordnung. Es kann zeigen, dass ein Modell aktiv ist, aber Sie benötigen weiterhin docker inspect, Modell-Metadaten, Logs und Speicherwachstumsprüfungen, um zu bestätigen, dass es vom beabsichtigten Pfad stammt.

Es beweist auch nicht, dass eine benutzerdefinierte Modell-Datei genau die erwartete Quantisierung oder Quelle hat. Verwenden Sie dafür Metadatenprüfungen, Modelfile-Inspektion und Dateiebene-Verifikation.

Warnzeichen, dass der Modellpfad falsch ist

Ein falscher Modellpfad zeigt meist Symptome, bevor er offensichtlich wird. Das häufigste Anzeichen ist unerklärliches Wachstum der Festplatte auf dem Boot-Laufwerk, Docker-Root oder einem App-Daten-Volume, das Sie nicht verwenden wollten.

Achten Sie auf diese Pfadabweichungssignale:

Die App zeigt das Modell an, aber Ihr vorgesehener Modellordner wächst nicht.
docker inspect zeigt einen Quellpfad, der sich von Ihrem NAS-Speicherordner unterscheidet.
Das Modell wird erneut heruntergeladen, obwohl Sie dachten, es sei bereits vorhanden.
Protokolle erwähnen ein Standardmodellverzeichnis anstelle Ihres benutzerdefinierten Pfads.
ollama list zeigt ein anderes Tag oder eine andere Größe als erwartet.
ollama show --modelfile weist auf eine andere Basis oder Blob als erwartet hin.
ollama ps zeigt nach einer Eingabeaufforderung ein unerwartetes aktives Modell.
Das Bootlaufwerk verliert nach jedem Modell-Download Speicherplatz.

Wenn zwei Überprüfungsebenen nicht übereinstimmen, vereinfachen Sie den Test. Stoppen Sie den Container, überprüfen Sie den Mount, starten Sie den Dienst neu, laden Sie ein kleines bekanntes Modell herunter und prüfen Sie, welches Verzeichnis wächst.

Eine sauberere Überprüfungsreihenfolge für lokalen LLM-Speicher

Verwenden Sie eine feste Überprüfungsreihenfolge anstatt zufällige Ordner zu prüfen. So vermeiden Sie Verwirrung zwischen Host-Pfaden, Container-Pfaden, App-Pfaden und Laufzeit-Pfaden.

Bestätigen Sie den vorgesehenen Host-Speicherordner.
Überprüfen Sie den freien Speicherplatz auf dem Systemlaufwerk und dem Modelllaufwerk.
Ausführen docker inspect <container-name> und verifizieren Sie Quelle / Ziel.
Überprüfen Sie die Laufzeit-Modellliste mit ollama list.
Laden oder importieren Sie ein kleines bekanntes Modell.
Ausführen du -sh <model-ordner> vor und nach dem Herunterladen.
Untersuchen Sie die Metadaten mit ollama show <model-name> --modelfile.
Senden Sie eine kurze Eingabeaufforderung.
Ausführen ollama ps um das aktive Modell zu bestätigen.
Lesen Sie Container- oder Dienstprotokolle nach Hinweisen zu Pfad, Download oder Berechtigungen.

Eine saubere Speicherüberprüfung sollte damit enden, dass alle Ebenen auf denselben Ort verweisen: Der Modellordner wächst auf dem erwarteten Laufwerk, der Container-Mount zeigt auf diesen Ordner, die Laufzeit listet das Modell auf, die Metadaten stimmen mit der erwarteten Datei überein, Protokolle zeigen keine Pfadfehler und das aktive Modell ist das, das Sie gerade getestet haben.

Was die ZimaOS KI-Suche über sichtbare Modellpfade zeigt

Eine kontrollierte lokale KI-Funktion sollte ihren Modellpfad, Download-Status, Ressourcennutzung und Protokolle ausreichend sichtbar machen, um dies zu überprüfen. Andernfalls bleiben Benutzer im Unklaren, ob der KI-Dienst tatsächlich die erwarteten Modell-Dateien verwendet.

ZimaOS-AI ist ein nützliches Beispiel. Der ZimaSpace-Leitfaden für KI-Suche erklärt, dass das KI-Modul ein lokales LLM verwendet, um Merkmale aus Bildern, Audio und Video für die ZimaOS-Suche zu extrahieren. Dieselbe kurze Notiz weist darauf hin, dass Modell-Dateien im Verzeichnis /media/ZimaOS-HD/AppData/.models gespeichert werden und wenn AppData migriert wurde, folgt die tatsächliche Speichernutzung dem migrierten AppData-Standort.

Der Leitfaden beschreibt auch Betriebsprüfungen wie automatische Modell-Downloads, Intervalle der Merkmalsextraktion, Anrufverlauf, Netzwerkverkehrsprüfungen und journalctl -xef -u zimaos-ai zur Fehlerbehebung. Das sind genau die Signale, die eine lokale KI-Arbeitslast braucht: sichtbarer Pfad, sichtbares Download-Verhalten, sichtbare Protokolle und sichtbarer Laufzeitstatus.

Für eine private Cloud-Lösung wie ZimaCube 2 ist die wichtigste Erkenntnis: lokale KI sollte keine Blackbox sein. Egal ob die Arbeitslast Suche, Chat, Einbettungen oder Medienanalyse ist, der Modellpfad und der Laufzeitstatus sollten leicht überprüfbar sein.

FAQ

Wie weiß ich, wo Ollama Modelldateien speichert?

Überprüfen Sie Ollamas Standard-Modelverzeichnis für Ihr Betriebssystem und prüfen Sie, ob OLLAMA_MODELS es geändert hat. Überprüfen Sie bei Docker auch den Container-Mount, damit Sie wissen, welcher Host-Ordner auf das Laufzeit-Modelverzeichnis abgebildet wird.

Wie überprüfe ich, ob Docker den richtigen Modellordner verwendet?

Führen Sie docker inspect <container-name> aus und überprüfen Sie den Abschnitt Mounts. Die Quelle sollte der NAS-Speicherpfad sein, den Sie vorgesehen haben, und das Ziel sollte das im Container verwendete Modelverzeichnis sein.

Was sind `Manifeste` und `Blobs` in einem Ollama-Modellverzeichnis?

In einem Ollama-ähnlichen Modelverzeichnis beschreiben Manifeste die Modelldaten und Referenzen, während Blobs die größeren Modelldateien enthalten. Wenn der Blobs-Ordner nach dem Herunterladen eines Modells wächst, ist das ein starkes Zeichen dafür, dass dieses Verzeichnis für die Modellspeicherung verwendet wird.

Wie kann ich erkennen, welches Modell gerade geladen ist?

Senden Sie eine kurze Eingabeaufforderung und führen Sie dann ollama ps aus. Es zeigt das aktuell geladene Modell und den Prozessorstatus an, was hilft zu bestätigen, ob das erwartete Modell auf CPU, GPU oder einer CPU/GPU-Aufteilung aktiv ist.

Warum zeigt die App das Modell an, aber der Dateipfad scheint trotzdem falsch zu sein?

Die App liest möglicherweise ein Laufzeit-Register, ein zwischengespeichertes Modell, einen Docker-internen Pfad oder ein anderes Modelverzeichnis als das, das Sie im Dateimanager überprüfen. Überprüfen Sie die Laufzeitliste, den Docker-Mount, die Metadaten, die Protokolle und das tatsächliche Speicherwachstum, bevor Sie der Benutzeroberfläche vertrauen.

Eine lokale LLM-Pfadprüfung ist nur dann abgeschlossen, wenn der Speicherpfad des Hosts, das Ziel im Container, die Laufzeit-Modellliste, die Modelldaten, der aktive Speicherstatus, die Protokolle und das Wachstum der Festplatte alle übereinstimmen. Wenn eine Ebene auf einen anderen Ort zeigt, korrigieren Sie den Pfad, bevor Sie weitere Modelle herunterladen oder weitere Apps verbinden.