8, 12, 16 eller 24 GB grafikhukommelse hjælper med den første udvælgelse. Om en lokal sprogmodel fungerer i hverdagen, afhænger også af modelversion, kontekst og samtidig brug. En kort sammenligning kan forebygge fejlkøb.
Hvad optager faktisk grafikhukommelsen?
Planlægningen omfatter tre områder: de indlæste modelvægte, konteksthukommelsen inklusive KV-cache og kørselsbufferne i den anvendte backend. Der skal desuden være plads til andre GPU-programmer og en driftsreserve. Med et almindeligt separat grafikkort er systemets RAM og grafikhukommelsen forskellige ressourcer.
Systemer med delt hukommelse har et andet budget: operativsystem, programmer og model bruger samme pulje. Også her skal piloten måle den reelt tilgængelige hukommelse og den konkrete opgave. Nominel kapacitet er ikke nok for nogen af konstruktionerne.
4 bit: en nyttig beregning med klare grænser
“B” i 7B eller 70B betyder milliarder parametre. En grov vægtberegning med ensartede 4 bit er: antal parametre × 4 ÷ 8 = byte. Kvantisering lagrer vægte med lavere præcision. Betydningen for svarkvaliteten skal undersøges for den konkrete opgave.
| Modelklasse | Teoretisk ved 4 bit | Hvad det betyder |
|---|---|---|
| 7–8B | 3,5–4,0 GB ≈ 3,26–3,73 GiB | Et kompakt udgangspunkt for første test; den konkrete fil og konteksten kommer oveni. |
| 14B | 7,0 GB ≈ 6,52 GiB | Beregningen alene dokumenterer ikke fuld kørsel på et kort med 8 GB. |
| 32B | 16,0 GB ≈ 14,90 GiB | Selv et nominelt passende vægtbudget efterlader ikke plads til den øvrige kørsel. |
| 70B | 35,0 GB ≈ 32,60 GiB | I denne forenklede beregning overstiger vægtene allerede ét kort med 24 GB. |
En konkret GGUF er større eller anderledes sammensat end beregningen. Metoder som Q4_K_M lagrer ikke blot alle bestanddele som fire bit pr. parameter. Planlægningen skal derfor angive den præcise modelfil med kvantiseringsvariant , der skal anvendes.
Et kontrollerbart eksempel fra Qwens officielle filoversigter: de sammenlagte Q4_K_M-fildele for Qwen2.5-Instruct fylder ved 7B omkring 4,68 GB / 4,36 GiB, ved 14B 8,99 GB / 8,37 GiB og ved 32B 19,85 GB / 18,49 GiB. Det er filstørrelser, ikke målt VRAM-forbrug. De viser dog, hvorfor “32B i 4 bit passer i 16 GB” ikke er et holdbart løfte for denne version.
Vurdering af 8, 12, 16 eller 24 GB
| Kapacitetsklasse | Relevant testområde | Vigtige hensyn |
|---|---|---|
| 8 GB | En kompakt 7–8B-version og begrænset kontekst som udgangspunkt. | Anden GPU-brug og længere input kan hurtigt mindske budgettet. |
| 12 GB | Mere råderum til kompakte modeller; test en konkret 14B-kvantisering målrettet. | Vægte, KV-cache og kørselsbuffere skal samlet passe i den ledige hukommelse. |
| 16 GB | Ekstra reserve til passende mindre og mellemstore modelversioner. | Den nævnte Qwen2.5-32B-Q4_K_M overstiger allerede denne klasse som samlet fil. |
| 24 GB | En passende 32B-kvantisering kan komme med i udvælgelsen. | Lang kontekst og parallelle forespørgsler skal også testes. Det indebærer ikke understøttelse af 70B. |
Kontrollér måleværktøjets enhed og den ledige hukommelse. To kort med samme kapacitet kan være meget forskellige i båndbredde, regnekraft, driverunderstøttelse og strømforbrug. Flere GB er derfor hverken modelgodkendelse eller benchmark.
Kontekst og samtidige forespørgsler hører med i testen
KV-cachen opbevarer mellemresultater til behandlingen. Behovet afhænger blandt andet af modelarkitektur, kontekstlængde og lagringsformat. Lange dokumenter, chathistorik og indsatte vidensuddrag kræver ekstra plads. Modellens annoncerede maksimale kontekstvindue er derfor ikke gratis tilgængelig hukommelse.
En vellykket enkelttest siger heller ikke meget om samtidige forespørgsler. I Ollama øger parallel kontekstbehandling hukommelsesforbruget; registrér den præcise konfiguration. Test både en kort forespørgsel, en længere realistisk kontekst og forventet samtidighed. Vurder kvalitet, tid til første token, samlet varighed, fejl og spidsforbrug samlet.
Et mindre eller kvantiseret KV-format kan spare hukommelse afhængigt af runtime og backend. Det kan også påvirke præcision og adfærd. Kvantisering af modelvægte og KV er separate indstillinger; sammenlign dem med de samme faglige testtilfælde.
Aflastning til CPU og RAM: muligt, men med anden adfærd
Runtimes som llama.cpp understøtter en opdeling mellem CPU og GPU. Det kan gøre en model anvendelig, selv om dens fulde behov overstiger grafikhukommelsen. Det kræver nok RAM og en egnet datavej. En SSD gør ikke manglende VRAM til lige så hurtig grafikhukommelse.
Offloading ændrer kørselsvejen og ofte svartiden; omfanget kan ikke angives ansvarligt uden måling. I Ollama hjælper ollama psmed at kontrollere den aktuelle CPU/GPU-fordeling. Flere GPU’er svarer heller ikke automatisk til én stor enhed: understøttelse, fordeling og overførsel mellem kortene skal vurderes i arkitekturen.
Før købet: godkend en konkret konfiguration
- Fastlæg modellen: præcis version, kvantisering, licens og ønsket svarkvalitet.
- Fastlæg belastningen: kontekstbudget, input-/outputlængde og samtidige forespørgsler.
- Kontrollér miljøet: konkret GPU, backend, drivere, operativsystem, RAM, køling og strømforsyning.
- Mål: ledig kapacitet, spidsforbrug, svartider og faglige fejl i en repræsentativ pilot.
- Beslut: genbrug hardware, udvid målrettet eller vælg en lokal, ekstern eller hybrid tjeneste.
DAXS tilpasser model- og hardwarevalget til jeres eksisterende IT og aftalte drift. Fagsiden Lokale LLM’er og infrastrukturbeskriver rammen. Artiklen om en belastningspilot til lokal AI viser vurdering med realistiske opgaver; Omkostninger og modelvalg belyser økonomien.
Kilder: Ollama: kontekstlængde (eksternt link) · Ollama: hukommelse, samtidighed og offloading (eksternt link) · llama.cpp: kørselsveje (eksternt link) · Hugging Face: GGUF (eksternt link) · officielle Qwen-filoversigter 7B (eksternt link), 14B (eksternt link), 32B (eksternt link). Vejledning til inferens; ingen træningstest, hardwaretilbud eller påstået kundemåling.
