8, 12, 16 oder 24 GB Grafikspeicher: Die Zahl hilft bei der Vorauswahl. Ob ein lokales Sprachmodell damit im Arbeitsalltag sinnvoll läuft, entscheiden zusätzlich Modellfassung, Kontext und gleichzeitige Nutzung. Ein kleiner Speichervergleich verhindert Fehlkäufe.
Was den Grafikspeicher tatsächlich belegt
Für die Planung zählen drei Bereiche: die geladenen Modellgewichte, der Kontextspeicher einschließlich KV-Cache und die Laufzeitpuffer des verwendeten Backends. Zusätzlich muss Platz für andere GPU-Anwendungen und eine betriebliche Reserve bleiben. Der Hauptspeicher des Rechners und der Grafikspeicher sind bei einer üblichen separaten Grafikkarte unterschiedliche Ressourcen.
Bei Systemen mit gemeinsamem Speicher gilt ein anderes Budget: Betriebssystem, Anwendungen und Modell teilen sich denselben Vorrat. Auch dort sollte der Pilot den tatsächlich verfügbaren Speicher und die reale Aufgabe messen. Die nominelle Kapazität allein genügt für beide Bauarten nicht.
4 Bit: eine nützliche Rechnung mit klaren Grenzen
Das „B“ in 7B oder 70B steht für Milliarden Parameter. Für eine grobe Gewichtsrechnung bei einheitlich 4 Bit gilt: Parameterzahl × 4 ÷ 8 = Byte. Quantisierung speichert Gewichte mit geringerer Genauigkeit. Wie sich das auf die Antwortqualität auswirkt, muss zur jeweiligen Aufgabe geprüft werden.
| Modellklasse | Theoretisch bei 4 Bit | Was daraus folgt |
|---|---|---|
| 7–8B | 3,5–4,0 GB ≈ 3,26–3,73 GiB | Kompakter Ausgangspunkt für einen ersten Test; die konkrete Datei und der Kontext kommen hinzu. |
| 14B | 7,0 GB ≈ 6,52 GiB | Die Rechnung allein belegt keine vollständige Ausführung auf einer 8-GB-Karte. |
| 32B | 16,0 GB ≈ 14,90 GiB | Selbst ein nominell passendes Gewichtsbudget lässt noch keinen Platz für den übrigen Betrieb. |
| 70B | 35,0 GB ≈ 32,60 GiB | Bei dieser vereinfachten Rechnung liegen bereits die Gewichte über einer einzelnen 24-GB-Karte. |
Ein konkretes GGUF ist größer oder anders zusammengesetzt als diese Rechnung. Bei Verfahren wie Q4_K_M werden nicht alle Bestandteile schlicht als vier Bit je Parameter abgelegt. Deshalb sollte die genaue Modelldatei samt Quantisierungsvariante in der Planung stehen.
Ein nachprüfbares Beispiel aus den offiziellen Qwen-Dateiverzeichnissen: Die jeweils zusammengezählten Q4_K_M-Dateiteile von Qwen2.5-Instruct belegen bei 7B rund 4,68 GB / 4,36 GiB, bei 14B 8,99 GB / 8,37 GiB und bei 32B 19,85 GB / 18,49 GiB. Das sind Dateigrößen, keine gemessenen VRAM-Verbräuche. Sie zeigen aber, weshalb „32B in 4 Bit passen auf 16 GB“ für diese konkrete Fassung keine tragfähige Zusage ist.
8, 12, 16 oder 24 GB einordnen
| Kapazitätsklasse | Sinnvoller Prüfbereich | Besonders beachten |
|---|---|---|
| 8 GB | Kompakte 7–8B-Fassung und begrenzter Kontext als Ausgangspunkt. | Andere GPU-Nutzung und längere Eingaben können das Budget rasch verengen. |
| 12 GB | Mehr Spielraum für kompakte Modelle; eine konkrete 14B-Quantisierung gezielt testen. | Gewichte, KV-Cache und Laufzeitpuffer müssen gemeinsam in den freien Speicher passen. |
| 16 GB | Zusätzliche Reserve für passende kleinere und mittlere Modellfassungen. | Das genannte Qwen2.5-32B-Q4_K_M passt bereits als gesamte Datei nicht in diese Klasse. |
| 24 GB | Eine passende 32B-Quantisierung kann in die engere Auswahl kommen. | Langer Kontext und parallele Anfragen müssen zusätzlich getestet werden. 70B folgt daraus nicht. |
Prüfen Sie die Einheit des Messwerkzeugs und den freien Speicher. Zwei Karten mit derselben Kapazität können sich bei Speicherbandbreite, Rechenleistung, Treiberunterstützung und Leistungsaufnahme deutlich unterscheiden. Eine größere Zahl GB ist daher weder eine Modellfreigabe noch ein Benchmark.
Kontext und gleichzeitige Anfragen gehören in den Test
Der KV-Cache hält für die Verarbeitung benötigte Zwischenwerte vor. Sein Bedarf hängt unter anderem von Modellarchitektur, Kontextlänge und Speicherformat ab. Lange Dokumente, Chatverläufe und eingefügte Wissensauszüge beanspruchen zusätzlichen Platz. Das maximale Kontextfenster aus dem Modellprospekt ist deshalb kein kostenlos nutzbarer Speicherumfang.
Auch ein bestandener Einzeltest sagt wenig über mehrere gleichzeitige Anfragen aus. Bei Ollama steigt die Speicherbelegung für die parallele Kontextverarbeitung; die konkrete Konfiguration ist mitzuprotokollieren. Testen Sie neben einer kurzen Anfrage einen längeren realistischen Kontext und die erwartbare Gleichzeitigkeit. Antwortqualität, Zeit bis zum ersten Token, Gesamtdauer, Fehler und Spitzenbelegung gehören gemeinsam in das Ergebnis.
Ein kleineres oder quantisiertes KV-Format kann je nach Laufzeit und Backend Speicher sparen. Es kann zugleich Genauigkeit und Verhalten beeinflussen. Modellgewichts-Quantisierung und KV-Quantisierung sind zwei getrennte Einstellungen; beide sollten mit denselben fachlichen Prüffällen verglichen werden.
Auslagern in CPU und RAM: möglich, aber mit anderem Verhalten
Laufzeiten wie llama.cpp unterstützen eine Aufteilung zwischen CPU und GPU. Dadurch kann ein Modell nutzbar werden, dessen vollständiger Speicherbedarf den Grafikspeicher übersteigt. Dafür werden ausreichend Hauptspeicher und ein passender Datenweg benötigt. Eine SSD macht aus fehlendem VRAM keinen gleich schnellen Grafikspeicher.
Die Auslagerung verändert den Ausführungsweg und häufig die Antwortzeit; das Ausmaß ist ohne Messung nicht seriös zu beziffern. In Ollama hilft ollama ps, die aktuelle CPU-/GPU-Aufteilung zu kontrollieren. Mehrere GPUs ergeben ebenfalls kein automatisch gleichwertiges großes Einzelgerät: Unterstützung, Verteilung und Übertragung zwischen den Karten gehören in die Architekturprüfung.
Vor dem Kauf: eine konkrete Konfiguration abnehmen
- Modell festlegen: genaue Fassung, Quantisierung, Lizenz und gewünschte Antwortqualität.
- Last festlegen: Kontextbudget, Eingabe-/Ausgabelänge und gleichzeitige Anfragen.
- Umgebung prüfen: konkrete GPU, Backend, Treiber, Betriebssystem, Hauptspeicher, Kühlung und Stromversorgung.
- Messen: freie Kapazität, Spitzenverbrauch, Antwortzeiten und fachliche Fehler im repräsentativen Pilot.
- Entscheiden: vorhandene Hardware weiterverwenden, gezielt erweitern oder einen lokalen, externen beziehungsweise hybriden Dienst wählen.
DAXS ordnet die Modell- und Hardwarewahl in Ihre vorhandene IT und den vereinbarten Betrieb ein. Den Rahmen beschreibt die Fachseite Lokale LLM & Infrastruktur. Der Beitrag zum Lastpilot für lokale KI zeigt die Bewertung unter realistischen Aufgaben; Kosten & Modellwahl betrachtet die wirtschaftliche Seite.
Modell- und Hardwareauswahl besprechen
Quellen: Ollama: Kontextlänge (externer Link) · Ollama: Speicher, Parallelität und Offloading (externer Link) · llama.cpp: Ausführungswege (externer Link) · Hugging Face: GGUF (externer Link) · offizielle Qwen-Dateiverzeichnisse 7B (externer Link), 14B (externer Link), 32B (externer Link). Orientierung zur Inferenz; kein Trainingstest, kein Hardwareangebot und keine behauptete Kundenmessung.