Hur mycket VRAM behöver en lokal dokumentassistent?

En lokal dokumentassistent behöver inget dedikerat VRAM när genereringen körs på distans eller på en separat inferensserver. För inferens på samma maskin är 8 GB en praktisk utgångspunkt för små kvantiserade modeller, medan större modeller, längre kontext och samtidig användning kan öka kravet långt över 16–24 GB. Dimensionera den exakta modellen och arbetskontexten innan du köper, eftersom själva RAG-applikationen inte avgör VRAM-behovet.

Avgör om assistenten faktiskt behöver ett lokalt grafikkort

En dokumentassistent har minst två lager: applikationen som lagrar filer, delar upp text, söker efter eller hämtar textavsnitt och presenterar svar; samt modellbackend som utför genereringen. Dessa lager behöver inte köras på samma hårdvara. En kompakt server kan vara värd för det privata dokumentbiblioteket och hämtningslagret, samtidigt som modellförfrågningar skickas till en annan lokal dator med grafikkort eller till en fjärrleverantör.

AnythingLLM:s dokumentation för egen drift gör denna uppdelning tydlig genom att tillåta applikationen att ansluta till modell- och embeddingtjänster på andra platser. Dess krav för egen drift är därför betydligt lägre än hårdvarukraven för en LLM på samma maskin.

Om kravet är ”dokumenten ska stanna på min server” snarare än ”varje modelltoken måste genereras på den här servern”, kan noll dedikerat VRAM vara ett giltigt köpval. Du behöver fortfarande kontrollera vilken text som lämnar maskinen, var embeddings skapas, hur fjärrmodellen hanterar förfrågningar och om integritetsgränsen passar användningsfallet.

Det första köpbeslutet är arkitektoniskt: fjärrinferens eller inferens på en separat maskin innebär att CPU, RAM och lagring dimensioneras för hämtning; inferens på samma maskin innebär att VRAM blir en central begränsning vid modellvalet.

Dimensionera modellvikterna innan du lägger till RAG-overhead

VRAM-planeringen börjar med den exakta modellen och precisionen. Vikter med full precision är mycket större än 8-bitars- eller 4-bitarsvarianter, vilket är anledningen till att två personer som säger ”jag kör en 7B-modell” kan ha mycket olika minneskrav. Kvantisering kan göra att en användbar mindre modell får plats på vanlig hårdvara, men den kan också förändra modellens beteende och bör utvärderas med dokumentuppgiften.

Hugging Face dokumenterar att kvantisering minskar minnes- och beräkningskostnaderna genom att representera vikter och aktiveringar med datatyper med lägre precision, och stöder vanliga 8-bitars- och 4-bitarsalternativ. Det gör precisionen till en faktor vid köp, inte bara en programvaruinställning som tillämpas efter att hårdvaran har valts.

Som en grov aktuell planeringsregel får 4-bitarsmodeller i 7–8B-klassen ofta plats inom 6–8 GB, modeller i 13–14B-klassen kräver vanligtvis omkring 10–12 GB och modeller i 27–32B-klassen behöver ofta ungefär den lägre delen av 20 GB-intervallet innan extra utrymme för kontext räknas in. Spherons VRAM-guide för dimensionering från 2026 anger liknande INT4-värden och lägger uttryckligen till körningsrelaterad overhead utöver viktuppskattningen.

Köp inte exakt efter den nedladdade modellfilens storlek. Lämna utrymme för körningen och kontexttillståndet och verifiera sedan den faktiska modellen i den avsedda inferensmotorn. En modell som laddas med en mycket kort testprompt kan ändå misslyckas eller flytta lager till annat minne när assistenten får en lång hämtad kontext.

Kontextlängden kan ändra VRAM-nivån efter att modellen får plats

En dokumentassistent behöver ofta mer kontext än en vanlig chattbot, eftersom hämtade textavsnitt, källhänvisningar, systeminstruktioner, samtalshistorik och användarfrågor sätts samman till en och samma förfrågan. Modellvikterna kan förbli oförändrade medan nyckel-värde-cachen och annat förfrågningsrelaterat tillstånd växer med kontextlängden.

Ollamas aktuella kontextdokumentation synliggör denna avvägning: standardkontextlängden ökar med tillgängligt VRAM, från 4K under 24 GiB till 32K vid 24–48 GiB och betydligt högre vid 48 GiB eller mer. De exakta standardvärdena är körningsval, men lärdomen vid köp är att arbete med lång kontext förbrukar minne utöver modellvikterna.

Lös inte detta genom att maximera kontexten utan urskiljning. Hämtningen bör välja den minsta uppsättningen textavsnitt som besvarar frågan, och segmentering eller omrangering bör ta bort irrelevant text före genereringen. En dokumentassistent som kräver att alla dokument stoppas in i en enda prompt använder VRAM för att kompensera för en svag design av hämtningen.

Gå upp till nästa VRAM-nivå när den testade modellen är tillräckligt träffsäker men riktiga dokumentprompter leder till avlastning, slut på minne eller oacceptabel fördröjning vid den kontextlängd du faktiskt behöver. Om hämtningens kvalitet är dålig innan kontexten når modellen bör du först förbättra indexet och rangordningen.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Budgetera separat för embeddings, omrangering, OCR och samtidig användning

Den lokala LLM:en är inte den enda komponenten som kan använda grafikminne. Vissa dokumentassistenter accelererar även embeddings, omrangering, OCR, taltranskribering eller synmodeller på samma grafikkort. Om dessa modeller körs samtidigt kan det tillgängliga VRAM-minnet för generatorn minska, även om varje komponent får plats när den testas separat.

ZimaSpaces artikel om hela modellens minnesavtryck förklarar varför körningsbuffertar och förfrågningsrelaterat tillstånd måste beaktas tillsammans med kontrollpunktens storlek. För en dokumentassistent skapar hämtad kontext och parallella tjänster ytterligare belastning på det delade minnet.

Samtidig användning förändrar också svaret. Två aktiva användare kan behöva separata KV-cache-tillstånd även när de delar på en modell som redan finns i minnet. En batchorienterad server kan förbättra acceleratorutnyttjandet, men den får inte minnet per förfrågan att försvinna. Mät den längsta normala dokumentfrågan med det förväntade antalet samtidiga användare.

Om generatorn är den enda GPU-arbetsbelastningen kan du dimensionera närmare dess testade arbetsmängd. Om OCR, embeddings, omrangering och generering måste överlappa bör du antingen köpa mer VRAM, sekvensera de tunga stegen eller fördela tjänsterna mellan CPU- och GPU-resurser. Det billigaste valet är det som bevarar den nödvändiga svarstiden utan att du betalar för outnyttad acceleration.

Använd VRAM-nivåer för att kortlista modeller och testa sedan kvaliteten

En användbar kortlista kan organiseras efter vad dokumentassistenten måste kunna utföra, snarare än efter den största modellen som får plats. Med omkring 6–8 GB VRAM kan du börja med små 7–8B-modeller i 4-bitarsformat och begränsad hämtning. Med omkring 12–16 GB får du utrymme för större modeller, högre precision eller mer kontext. Vid omkring 24 GB blir många kvantiserade modeller i 27–32B-klassen praktiska med större arbetsmarginal. Ungefär 40–48 GB och uppåt är nivån där 70B-modeller i 4-bitarsformat börjar bli realistiska utan omfattande avlastning.

SitePoints lokala LLM-guide från 2026 noterar att en 7B Q4_K_M-modell bekvämt kan få plats i omkring 6 GB VRAM. Andra aktuella dimensioneringsguider placerar kvantiserade modeller i 14B- och 32B-klassen högre, vilket förstärker regeln att nivån avgörs av den exakta kontrollpunkten, inte av en generell etikett som ”AI-dator”.

Skapa en utvärderingsuppsättning från dina egna dokument innan du köper nästa nivå. Ta med frågor som kräver exakt extraktion, syntes från flera textavsnitt, vägran när källan saknas samt tabeller eller strukturerad text om det är relevant, liksom den längsta kontext du förväntar dig. Jämför svarskvalitet, källhänvisningar, fördröjning till första token, genereringshastighet och högsta VRAM-användning.

Köp mer VRAM när den mindre modellen misslyckas eftersom modellens kapacitet eller kontextkapacitet faktiskt är otillräcklig. Uppgradera inte bara för att det finns en större kontrollpunkt. Hämtning kan göra en mindre och snabbare modell mer användbar för en avgränsad privat kunskapsbas än en långsammare modell med svag förankring i källorna.

Håll lagrings- och hämtningsvärden separerade från VRAM-beslutet

En dokumentassistent behöver också beständig lagring för originalfiler, extraherad text, index, applikationsdatabaser, loggar och säkerhetskopior. Dessa tillgångar förbrukar vanligtvis systemminne och diskkapacitet snarare än GPU-minne. Om alla resurser slås ihop till ett enda ”AI-minnesvärde” leder det till dåliga hårdvarubeslut.

ZimaSpaces översikt över en privat AI-assistent på en NAS beskriver den lokala filhanteringens roll som grund för hämtning. Den arkitekturen gör att lagringssystemet kan förbli stabilt även när inferenshårdvaran byts ut senare.

ZimaBoard 2 1664 passar när den kompakta serverns uppgift är dokumentlagring, indexering, applikationer och orkestrering, medan LLM:en körs på distans eller på en separat dator med grafikkort. Dess integrerade Intel-grafik ska inte betraktas som dedikerat LLM-VRAM.

Välj lagringsvärden utifrån dokumentmängd, säkerhetskopiering, applikationernas minnesbehov och nätverkskrav. Välj accelerator utifrån den exakta modellen, kvantiseringen, kontexten och den samtidiga användningen. Genom att hålla besluten separerade kan du uppgradera grafikkortet utan att bygga om det auktoritativa dokumentarkivet.

Verifiera alla GPU-konfigurationer i samma system före köp

Om du vill ha lagring, hämtning och lokal generering i samma chassi är den slutliga kontrollen den exakta mängden grafikminne som är tillgänglig för körningen. Produktnamn som ”AI”, ”Creator” eller ”RTX” anger inte om den valda lokala modellen får plats. VRAM, drivrutinsstöd, containeråtkomst, strömförsörjning, kylning och fysisk utbyggnad måste alla verifieras.

Det aktuella ZimaCube 2 Creator Pack är Zima-alternativet att utvärdera när köparen vill ha lagring med flera diskplatser och ett dedikerat NVIDIA-grafikkort i samma system. Den aktuella produktsidan anger GPU-familjen men publicerar ingen VRAM-mängd i den huvudsakliga specifikationstexten. Koppla därför inte produkten till en modellnivå på 8 GB, 16 GB, 24 GB eller 48 GB innan den exakta installerade grafikminnesmängden har bekräftats.

Innan du slutför köpet bör du, när det är möjligt, köra eller begära ett representativt modelltest. Anteckna högsta VRAM-användning med den normala kvantiseringen och kontexten och upprepa sedan testet med assistentens embeddings, omrangering, OCR eller andra aktiva GPU-tjänster. Bekräfta att körningen faktiskt använder det avsedda grafikkortet i stället för att i tysthet avlasta lager till systemminnet.

Den slutliga regeln är att köpa VRAM för den validerade arbetsmängden, inte för marknadsföringskategorin. Använd noll dedikerat VRAM när inferensen kan köras någon annanstans; börja omkring 6–8 GB för små kvantiserade lokala modeller; gå mot 12–16 GB för större modeller eller större marginaler; och överväg 24 GB eller mer först när det testade dokumentarbetsflödet visar att modellstorlek, kontext eller samtidig användning kräver det.

Vanliga frågor

Minskar RAG mängden VRAM jag behöver?

RAG kan göra att en mindre modell svarar utifrån hämtade belägg i stället för att förlita sig på en större modells interna kunskap, vilket kan minska modellnivån du behöver. Hämtade textavsnitt förbrukar fortfarande kontextminne, så dålig hämtning som skickar överdrivet mycket text kan öka belastningen på VRAM.

Kräver embeddingmodeller samma mängd VRAM som chattmodellen?

Nej. Embeddingmodeller har ett eget avtryck i CPU, RAM eller GPU och kan köras på CPU eller som en separat tjänst. Om embeddings och generering delar på ett grafikkort bör du mäta deras sammanlagda toppbelastning i stället för att summera modellfilernas storlek på papper.