Så lagrar du lokala LLM-modeller utan att fylla arbetsstationens SSD
Ha en liten aktiv mängd på arbetsstationens NVMe-lagring, placera det större modellbiblioteket på delad lagring och se till att varje runtime använder uttryckliga sökvägar.
Den här lagringslayouten fungerar när modellvikter huvudsakligen läses in vid start, nätverket kan ge acceptabla inläsningstider och oersättliga finjusteringar skyddas separat från filer som går att ladda ner. Den fungerar inte när varje cache i tysthet faller tillbaka på start-SSD:n eller när en otillgänglig NAS får inferenstjänsten att ladda ner modeller på nytt till en ny lokal mapp.
Klassificera modellfiler efter aktiv datamängd och återskapandekostnad
Börja med en inventering i stället för att flytta en enda enorm cachemapp. Grundvikter och kvantiserade varianter går kanske att ladda ner igen, men adaptrar, finjusteringar, promptmallar, manifestfiler, utvärderingsresultat och lokalt konverterade filer kan vara unika. Märk varje objekt som ofta använt, ibland använt, sällan använt eller oersättligt, och anteckna sedan vilken app som äger sökvägen.
Den aktiva datamängden omfattar modeller som används dagligen och bör rymmas inom en fastställd budget för arbetsstationen. Modeller som används ibland kan ligga på NAS:en och kopieras lokalt inför ett projekt. Experimentmodeller kan bara finnas i det delade biblioteket. Oersättliga resultat behöver versionshanterad säkerhetskopiering, även om den tillhörande modellen går att ladda ner igen.
Den här klassificeringen förebygger två vanliga misstag: att säkerhetskopiera hundratals gigabyte som är lätta att återskapa och att radera en liten adapter eller manifestfil som inte går att återskapa utan stora kostnader. Den ger också den första kapacitetssiffran: storleken på den aktiva datamängden plus ledigt utrymme för en inkommande modell, inte storleken på alla modeller du kanske någonsin testar.
Tilldela roller för lokal NVMe, delad lagring och arkiv
Ett lokalt AI-kluster i verklig drift lagrade modellfiler på en NAS och läste in dem via 10GbE, vilket visade att lösningen fungerar när nätverket och lagringsvägen är utformade för stora läsningar. Den viktigaste lärdomen från det här NAS-baserade arbetsflödet för modellservering är att separera rollerna: det delade biblioteket är källan, medan beräkning och minne finns kvar på inferensnoden.
| Lagringsroll | Rekommenderat innehåll | Beteende vid fel | Styrning |
|---|---|---|---|
| Workstationens NVMe-lagring för ofta använda data | Aktuella modeller, tokenizerfiler, aktiv runtime-cache | Inferensen fortsätter om NAS:en inte är tillgänglig | Hård storlekskvot och rensning efter längst tid sedan användning |
| NAS-modellbibliotek | Godkända viktfiler, kvantiseringar, delade revisioner | Nya inläsningar pausas; den aktiva modellen i minnet kan fortsätta köras | Delad lagring med främst läsåtkomst och kontrollsummor |
| Skyddad projektlagring | Finjusterade modeller, adaptrar, manifest, utvärderingsresultat | Återskapandet är beroende av säkerhetskopian | Ögonblicksbilder plus oberoende säkerhetskopia |
| Arbetsutrymme | Ofullständiga nedladdningar, konverteringar, tillfälliga delar | Säker att ta bort | Separat sökväg med automatisk tidsgräns |
Låt inte varje runtime använda samma skrivbara nätverksmapp. En misslyckad konvertering, ett rensningsjobb eller en versionsändring kan påverka filer som används av ett annat verktyg. Låt det kanoniska biblioteket vara i huvudsak skrivskyddat, gör ändringar i ett arbetsutrymme, verifiera dem och publicera färdiga artefakter medvetet.
Skapa en förutsägbar modellsökväg och cachepolicy
Välj en kanonisk monteringspunkt, till exempel /srv/models på Linux eller en fast enhetsbeteckning i Windows, och gör den tillgänglig innan Ollama, vLLM, LM Studio eller utvecklingscontainrar startar. Ange uttryckligen inställningarna för varje verktygs modell- och cachelagring. En symbolisk länk fungerar, men bara om monteringskontrollen körs först och målet aldrig ändras mellan omstarter.
Användare i communityn som överväger en separat NAS pekar upprepade gånger ut modellens inläsningstid som gränsdragningen. I en diskussion om AI-arbetsstationer och NAS rekommenderade deltagare att lagra modeller som används ofta på lokal NVMe, eftersom det kan ta flera minuter att överföra stora viktfiler via en långsammare anslutning.
Använd en tillåtelselista för den lokala snabbcachen i stället för att spegla hela NAS:en. Kontrollera filstorlek eller kontrollsumma efter en lyckad inläsning eller kopiering och uppdatera sedan ett atomiskt alias, till exempel current/model-name. Rensa bara bort modeller som varken körs eller är fästa. Behåll minst det större av 15 procent ledigt utrymme eller en maximal förväntad modellnedladdning, så att en uppdatering inte fyller startvolymen halvvägs.
Skydda manifest och finjusterade modeller, inte varje nedladdning
Säkerhetskopiera informationen som behövs för att återskapa biblioteket: käll-URL eller arkiv-ID, exakt revision, filnamn, kvantisering, kontrollsumma, licensanteckningar, runtime-konfiguration och sökvägen som används i produktion. Det manifestet är litet, sökbart och mer användbart vid återställning än en katalog full av filer med tvetydiga namn.
Säkerhetskopiera unika adaptrar, sammanslagna modeller, kalibreringsdata och utvärderingsresultat med normal versionshantering och lagringstid. För offentliga basvikter bör du avgöra om återställningstiden motiverar ytterligare en kopia. En långsam internetanslutning eller en modell som kan försvinna kan göra det värt att skydda utvalda vikter, men att spegla varje experiment brukar slösa med säkerhetskopieringskapaciteten.
Om den övergripande lösningen för AI-fillagring ännu inte är bestämd är ZimaSpaces jämförelse av personligt moln och lokal PC-lagring för AI-filer nästa steg i planeringen. Den skiljer beständiga källdata och index från maskinen som utför inferensen.
Validera laddningstid, offlinebeteende och utlösare för utökning
Testa tre scenarier med modelltjänsten stoppad: en varm lokal inläsning, en kall inläsning från NAS-enheten och ett NAS-avbrott. Registrera tiden tills det första användbara svaret, nätverkets högsta genomströmning, ledigt utrymme på arbetsstationen före och efter samt om något verktyg skapar en reservkatalog på startdisken. Upprepa efter en omstart så att monteringsordningen testas i stället för att tas för given.
Konfigurationen är godkänd när dagliga modeller läses in lokalt inom förväntad tid, kalla modeller kan mellanlagras utan manuella sökvägsändringar, unika artefakter kan återställas från säkerhetskopior och en saknad NAS-enhet ger ett tydligt fel i stället för en tyst nedladdning på nytt. Lägg till snabbare nätverk eller en större lokal lagringsnivå först när uppmätt fördröjning vid kall inläsning stör arbetet. Utöka NAS-kapaciteten när det kanoniska biblioteket närmar sig den fastställda lägsta lediga kapaciteten.
Sluta använda direkta nätverksläsningar för arbetsbelastningar som upprepade gånger söker igenom modellfragment, kräver förutsägbart låg startfördröjning eller måste fungera när NAS-enheten är offline. Behåll i så fall NAS-enheten som bibliotek och kopiera hela modeller till en större, dedikerad lokal SSD före start.
Slutlig regel för konfigurationen
Förvara det kanoniska modellbiblioteket på delad lagring, fäst den dagliga arbetsuppsättningen på lokal NVMe, isolera tillfälliga cachefiler och skydda endast de artefakter och manifest som inte kan återskapas. Utöka först när uppmätt laddningstid eller kapacitet överskrider en skriftligt fastställd tröskel.
Rekommenderade produkter
Installation av NAS och server
Mer att läsa
Kan en server i studentrummet vara tillräckligt tyst för sömn, studier och videosamtal?
Ja - en server i studentrummet kan vara diskret om hårdvaran har låg strömförbrukning, vibrationer från lagringsenheterna dämpas, tunga jobb schemaläggs och ljudnivån testas...
Ett studenthomelabb som kan flytta från studentrummet till den första lägenheten
Gör studentens hemlabb portabelt genom att skilja tjänsterna från nätverket i det enskilda rummet, minimera hårdvaran, säkerhetskopiera data och öva på en smidig flytt.
Så delar du en hemmaserver med rumskamrater utan att dela konton eller privata filer
Ge varje rumskamrat en namngiven identitet, privat lagring och endast de delade roller som hen behöver; håll administration, säkerhetskopiering och avslut av åtkomst åtskilda.
