Hardware-Rechner - passt dieses Modell auf meinen Rechner?

Direkte Antwort

Die Downloadgröße eines Modells sagt dir nicht, ob es auf deinem Rechner läuft. Ein 8B-Modell liegt als 4,7-GB-Datei auf der Platte, belegt im Betrieb mit 32.768 Tokens Kontext aber knapp 10 GB. Der Unterschied ist der KV-Cache — und der wird beim Planen fast immer vergessen.

Trag unten deinen Arbeitsspeicher und die gewünschte Kontextlänge ein:

Passt das auf meine Hardware?

Arbeitsspeicher und Kontextlänge eingeben. Der Rechner zieht 4 GB für Betriebssystem und übrige Programme ab.

Arbeitsspeicher GB — auf Apple Silicon der gesamte Unified Memory Kontextlänge 2.048 Tokens4.096 Tokens8.192 Tokens16.384 Tokens32.768 Tokens131.072 Tokens Mehr Kontext = mehr Speicher Quantisierung Q4_K_M (Standard)Q5_K_MQ6_KQ8_0FP16 (unquantisiert) Q4 ist der Standard-Download

Modell	Gewichte	KV-Cache	Gesamt	Ergebnis
Llama 3.2 3B	2,0 GB	0,9 GB	3,2 GB	läuft
Mistral 7B	4,1 GB	1,0 GB	5,6 GB	läuft
Llama 3.1 8B / Hermes 3 8B	4,7 GB	1,0 GB	6,3 GB	läuft
Qwen 2.5 14B	9,0 GB	1,5 GB	11,6 GB	wird knapp
Llama 3.3 70B	40,0 GB	2,5 GB	46,8 GB	passt nicht

Näherung. KV-Cache = 2 × Layer × KV-Heads × head_dim × 2 Byte pro Token, Architekturwerte aus der jeweiligen config.json. Gewichte skaliert von den gemessenen Q4-Downloads. Plus 10 % für Aktivierungen und Puffer. Ein quantisierter KV-Cache halbiert dessen Anteil.

Was der Rechner rechnet

Zwei Posten bestimmen den Bedarf.

Die Gewichte. Sie sind fest pro Modell und Quantisierungsstufe. Q4_K_M ist das, was Ollama und LM Studio standardmäßig herunterladen; höhere Stufen sind genauer und größer, niedrigere schneller und ungenauer.

Der KV-Cache. Er hält Schlüssel- und Wert-Vektoren aller bisher verarbeiteten Tokens, damit das Modell sie nicht bei jedem neuen Token neu berechnen muss. Seine Größe folgt einer einfachen Formel:

KV pro Token = 2 (K und V) × Layer × KV-Heads × head_dim × 2 Byte (fp16)

Für Llama 3.1 8B mit 32 Layern, 8 KV-Heads und head_dim 128:

2 × 32 × 8 × 128 × 2 Byte = 131.072 Byte = 128 KiB pro Token

Bei 8.192 Tokens sind das 1 GB. Bei 32.768 Tokens 4 GB. Der Posten wächst linear mit dem Kontext, und genau deshalb kippt ein Setup, das gestern noch lief, sobald jemand das Kontextfenster hochdreht.

Wie sehr das die Verhältnisse verschiebt, zeigt der Rechner selbst: Stell die Kontextlänge auf 32.768 und sieh dir die Zeile für Llama 3.2 3B an. Die Gewichte belegen 2,0 GB — der KV-Cache 3,5 GB. Der Zwischenspeicher ist größer als das Modell. Wer nur auf Downloadgrößen schaut, plant an dieser Stelle um den Faktor drei daneben.

Dazu kommen im Rechner 10 Prozent Aufschlag für Aktivierungen und Puffer sowie 4 GB Reserve für Betriebssystem und übrige Programme.

Die Zahlen, auf denen das beruht

Alle Architekturwerte stammen aus der jeweiligen config.json der Modelle, nicht aus Schätzungen:

Modell	Layer	KV-Heads	head_dim	KV pro Token
Llama 3.2 3B	28	8	128	112 KiB
Mistral 7B	32	8	128	128 KiB
Llama 3.1 8B	32	8	128	128 KiB
Qwen 2.5 14B	48	8	128	192 KiB
Llama 3.3 70B	80	8	128	320 KiB

Auffällig ist die Spalte KV-Heads: überall 8, obwohl die Modelle 24 bis 64 Attention-Heads haben. Das ist Grouped Query Attention — mehrere Attention-Heads teilen sich einen Satz Schlüssel- und Wert-Vektoren. Ohne diese Technik wäre der KV-Cache bei Llama 3.3 70B achtmal so groß, also rund 2,5 GB pro 1.000 Tokens statt 320 KiB pro Token. Lokale 70B-Modelle mit langem Kontext gäbe es dann schlicht nicht.

Die Q4-Größen sind gemessene Downloads aus der Ollama-Library. Andere Quantisierungsstufen werden daran skaliert.

Wo der Rechner danebenliegen kann

Ehrlichkeit gehört zu einem Werkzeug, das Kaufentscheidungen beeinflusst. Vier Punkte, an denen die Realität abweicht:

Quantisierter KV-Cache. Viele Inferenz-Tools können den Cache selbst quantisieren, meist auf 8 Bit. Das halbiert diesen Posten. Wenn dein Setup das nutzt, sind die Werte hier zu pessimistisch.

Die konkrete Quantisierungsvariante. „Q4” ist keine einzelne Zahl. Q4_K_M, Q4_K_S und Q4_0 unterscheiden sich in der Größe. Der Rechner nimmt Q4_K_M als Anker.

Speicherbandbreite. Der Rechner sagt, ob ein Modell passt — nicht, wie schnell es läuft. Ein Modell kann problemlos in den Speicher passen und trotzdem zäh antworten, weil die Bandbreite limitiert. Diese Seite deckt der Hardware-Guide mit konkreten Tokens-pro-Sekunde-Werten ab.

Hybrid-Betrieb. Passt ein Modell nicht vollständig in den VRAM, lagern manche Tools Teile in den System-RAM aus. Es läuft dann — nur um Faktor 5 bis 10 langsamer. Der Rechner zeigt in dem Fall „passt nicht”, und das ist als Aussage über brauchbare Geschwindigkeit gemeint, nicht über technische Unmöglichkeit.

Wie du damit eine Kaufentscheidung triffst

Nicht vom Modell rückwärts rechnen, sondern von der Aufgabe.

1. Kontextlänge zuerst festlegen. Wer Dokumente verarbeitet, braucht 16K oder mehr. Wer kurze Fragen stellt, kommt mit 4K aus — und spart mehr Speicher, als eine Quantisierungsstufe bringt.
2. Kleinstes Modell wählen, das die Aufgabe löst. Teste mit 3B, geh auf 8B, wenn es nicht reicht. Die wenigsten Aufgaben brauchen 70B.
3. Dann erst auf den Rechner schauen. Jetzt kennst du die Zeile, die zählt.
4. Beim Kauf aufrunden. Wenn 32 GB knapp passen, nimm 48 oder 64. Arbeitsspeicher lässt sich bei Apple Silicon nachträglich nicht erweitern, und die Modelle werden nicht kleiner.

Die Faustregel dahinter ist dieselbe wie überall auf dieser Seite: RAM vor SSD, Kontextlänge vor Modellgröße, eigene Tests vor Benchmark-Tabellen.

Nächster Schritt

Wenn du weißt, welches Modell passt, geht es beim Ollama Tutorial an die Installation. Wer wissen will, wie schnell es dann tatsächlich läuft, findet die Tokens-pro-Sekunde-Werte im Hardware-Guide. Und wenn die Antwort lautet, dass die vorhandene Hardware nicht reicht, steht die ehrliche Abwägung unter Cloud vs. Lokal.