So speichern Sie lokale LLM-Modelle, ohne die SSD Ihres Workstations vollzuschreiben

Halten Sie ein kleines Hot-Set auf der NVMe der Workstation, legen Sie die größere Modellbibliothek auf gemeinsamem Speicher ab und geben Sie für jede Laufzeit explizite Pfade an.

Dieses Layout funktioniert, wenn Modellgewichte überwiegend beim Start gelesen werden, das Netzwerk akzeptable Ladezeiten ermöglicht und unersetzliche Fine-Tunes getrennt von herunterladbaren Dateien geschützt werden. Es versagt, wenn jeder Cache unbemerkt auf die Boot-SSD ausweicht oder wenn das Inferenzsystem bei einem nicht verfügbaren NAS Modelle erneut in ein neues lokales Verzeichnis herunterlädt.

Modelldateien nach Arbeitssatz und Wiederherstellungskosten einteilen

Beginnen Sie mit einer Bestandsaufnahme, statt ein einziges riesiges Cache-Verzeichnis zu verschieben. Basisgewichte und quantisierte Varianten lassen sich möglicherweise erneut herunterladen, aber Adapter, Fine-Tunes, Prompt-Vorlagen, Manifeste, Evaluierungsergebnisse und lokal konvertierte Dateien können einzigartig sein. Kennzeichnen Sie jedes Element als heiß, warm, kalt oder unersetzlich und halten Sie anschließend fest, welche Anwendung für den jeweiligen Pfad zuständig ist.

Das Hot-Set umfasst täglich verwendete Modelle und sollte in ein festgelegtes Workstation-Speicherbudget passen. Warme Modelle können auf dem NAS liegen und vor einem Projekt lokal kopiert werden. Kalte Experimente können ausschließlich in der gemeinsamen Bibliothek verbleiben. Unersetzliche Ergebnisse benötigen ein Backup mit Versionsverwaltung, selbst wenn sich das zugrunde liegende Modell erneut herunterladen lässt.

Diese Einteilung verhindert zwei häufige Fehler: Hunderte Gigabyte an Daten zu sichern, die sich leicht wiederherstellen lassen, und einen kleinen Adapter oder ein Manifest zu löschen, das sich nicht kostengünstig wiederherstellen lässt. Außerdem ergibt sich daraus die erste Kapazitätsangabe: Größe des Hot-Sets plus freier Speicherplatz für ein zusätzliches Modell, nicht die Größe aller Modelle, die Sie jemals testen könnten.

Rollen für lokale NVMe-, gemeinsamen Speicher und Archiv zuweisen

Bei einem lokalen KI-Cluster aus der Praxis lagen die Modelldateien auf einem NAS und wurden über 10GbE geladen. Das zeigte, dass dieses Muster funktioniert, wenn Netzwerk und Speicherpfad auf große Lesezugriffe ausgelegt sind. Die nützliche Erkenntnis aus diesem NAS-gestützten Workflow für die Modellbereitstellung ist die Trennung der Rollen: Die gemeinsame Bibliothek dient als Quelle, während Rechenleistung und Arbeitsspeicher auf dem Inferenzknoten verbleiben.

Verweisen Sie nicht alle Laufzeitumgebungen auf denselben beschreibbaren Netzwerkordner. Eine fehlgeschlagene Konvertierung, ein Bereinigungsjob oder eine Versionsänderung könnte Dateien verändern, die von einem anderen Tool verwendet werden. Halten Sie die zentrale Bibliothek überwiegend schreibgeschützt, nehmen Sie Änderungen zunächst in einem Arbeitsbereich vor, überprüfen Sie sie und übernehmen Sie fertige Artefakte gezielt.

Einen einheitlichen Modellpfad und eine Cache-Richtlinie einrichten

Legen Sie einen einheitlichen Bereitstellungspunkt fest, etwa /srv/models unter Linux oder einen festen Laufwerksbuchstaben unter Windows, und stellen Sie ihn bereit, bevor Ollama, vLLM, LM Studio oder Entwicklungscontainer gestartet werden. Legen Sie die Modell- und Cache-Einstellungen für jedes Tool explizit fest. Ein Symlink ist nur dann akzeptabel, wenn die Einbindung zuerst geprüft wird und sich das Ziel zwischen Neustarts nie ändert.

Community-Betreiber, die ein separates NAS in Betracht ziehen, nennen wiederholt die Ladezeit von Modellen als entscheidenden Faktor. In einer Diskussion über KI-Workstations und NAS empfahlen Teilnehmende, häufig verwendete Modelle auf einer lokalen NVMe zu speichern, da große Modelldateien über eine langsamere Verbindung mehrere Minuten benötigen können.

Verwenden Sie für den lokalen Hot-Cache eine Zulassungsliste, statt das gesamte NAS zu spiegeln. Überprüfen Sie nach einem erfolgreichen Laden oder Kopieren die Dateigröße oder Prüfsumme und aktualisieren Sie anschließend einen atomaren Alias wie current/model-name. Entfernen Sie nur Modelle, die weder ausgeführt noch fixiert sind. Halten Sie mindestens den größeren der beiden folgenden Werte an Speicherplatz frei: 15 Prozent oder ein maximal erwarteter Modelldownload. So kann ein Update das Bootvolume nicht mitten im Vorgang füllen.

Featured

ZimaCube 2 persönliche Cloud-NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Manifeste und Fine-Tunes schützen, nicht jeden Download

Sichern Sie die Informationen, die zum Wiederherstellen der Bibliothek erforderlich sind: Quell-URL oder Repository-ID, genaue Revision, Dateiname, Quantisierung, Prüfsumme, Lizenzhinweise, Laufzeitkonfiguration und der in der Produktion verwendete Pfad. Dieses Manifest ist klein, durchsuchbar und bei der Wiederherstellung nützlicher als ein Verzeichnis voller Dateien mit mehrdeutigen Namen.

Sichern Sie einzigartige Adapter, zusammengeführte Modelle, Kalibrierungsdaten und Evaluationsergebnisse mit der üblichen versionierten Aufbewahrung. Entscheiden Sie bei öffentlichen Basisgewichten, ob die Wiederherstellungszeit eine zusätzliche Kopie rechtfertigt. Eine langsame Internetverbindung oder ein Modell, das möglicherweise nicht mehr verfügbar sein wird, kann es sinnvoll machen, ausgewählte Gewichte zu sichern; sämtliche Experimente zu spiegeln, verschwendet jedoch meist Backup-Kapazität.

Wenn noch unklar ist, wie der übergreifende KI-Dateilayer aussehen soll, ist der ZimaSpace-Vergleich von persönlicher Cloud und lokalem PC-Speicher für KI-Dateien der nächste Planungsschritt. Er trennt dauerhafte Quelldaten und Indizes von der Maschine, auf der die Inferenz ausgeführt wird.

Ladezeit, Offline-Verhalten und Auslöser für eine Erweiterung überprüfen

Testen Sie bei gestopptem Modelldienst drei Szenarien: das Laden eines lokal verfügbaren Modells, das Laden eines Modells vom NAS und einen NAS-Ausfall. Halten Sie die Zeit bis zur ersten nutzbaren Antwort, den maximalen Netzwerkdurchsatz, den freien Speicherplatz auf der Workstation vor und nach dem Test sowie fest, ob ein Tool ein Ausweichverzeichnis auf dem Startlaufwerk erstellt. Wiederholen Sie den Test nach einem Neustart, um die Einbindungsreihenfolge zu prüfen, statt sie vorauszusetzen.

Die Einrichtung ist einsatzbereit, wenn täglich verwendete Modelle innerhalb der erwarteten Zeit lokal geladen werden, Modelle für den gelegentlichen Bedarf ohne manuelle Pfadänderungen bereitgestellt werden können, einzigartige Artefakte aus einem Backup wiederhergestellt werden können und ein fehlendes NAS einen eindeutigen Fehler statt eines unbemerkten erneuten Downloads verursacht. Fügen Sie schnelleres Netzwerk oder eine größere lokale Speicherebene nur hinzu, wenn eine gemessene Verzögerung beim Kaltladen die Arbeit unterbricht; erweitern Sie die NAS-Kapazität, wenn sich die kanonische Bibliothek der festgelegten Mindestreserve an freiem Speicherplatz nähert.

Verwenden Sie keine direkten Netzwerkzugriffe mehr für Workloads, die wiederholt auf verschiedene Modell-Shards zugreifen, eine vorhersehbar kurze Startzeit erfordern oder auch bei offline befindlichem NAS funktionieren müssen. Bewahren Sie in diesem Fall das NAS als Bibliothek auf und kopieren Sie vor dem Start vollständige Modelle auf eine größere, dedizierte lokale SSD.

Regel für die endgültige Einrichtung

Bewahren Sie die kanonische Modellbibliothek auf gemeinsam genutztem Speicher auf, halten Sie den täglich benötigten Modellsatz auf der lokalen NVMe bereit, isolieren Sie entbehrliche Caches und sichern Sie nur Artefakte und Manifeste, die sich nicht wiederherstellen lassen. Erweitern Sie erst, wenn die gemessene Ladezeit oder Kapazität einen schriftlich festgelegten Schwellenwert überschreitet.