VRAM-Rechner

Die Geschwindigkeit ist eine bandbreitenabhängige Schätzung für Single-Stream-Decoding, kein Benchmark. Die Prompt-Verarbeitung ist rechenintensiv und verhält sich anders.

Wie man die dreiteilige Aufschlüsselung liest

Fast jede „passt es“-Diskussion im Internet ist eigentlich eine Diskussion darüber, welche von drei Zahlen jemand vergessen hat. Die Downloadgröße auf einer Modellkarte ist eine davon. Die anderen beiden existieren erst, wenn das Modell geladen ist und antwortet – genau dann, wenn Speichermangel zum Problem wird.

Nehmen wir Llama 3.1 8B mit Q4_K_M bei 8K Kontext, eine Anfrage nach der anderen, F16 Cache. Das ist das gewöhnlichste lokale Setup, das es gibt, und hier ist jedes Byte davon:

weights  = 8.03e9 params x 4.85 bits / 8      = 4.87e9 bytes = 4.53 GB
kv       = 2 x 32 layers x 8 kv-heads x 128 dim
           x 8192 tokens x 2 bytes             = 1.07e9 bytes = 1.00 GB
overhead = 0.65 + 0.08 x (4.53 + 1.00)                        = 1.09 GB
                                                                -------
total                                                            6.63 GB

Die Gewichte sind der einzige Teil, den man nachschlagen kann. Sie sind reine Arithmetik: Parameteranzahl mal Bit pro Gewicht, geteilt durch acht. Nichts an Ihrer Arbeitslast ändert diese. Wenn Sie die anderen beiden Zahlen ignorieren würden, kämen Sie zu dem Schluss, dass ein 8B-Modell mit 4 Bit 4,5 GB benötigt und bequem auf eine 6-GB-Karte passt. Das tut es nicht.

Der KV cache ist der Teil, der sich bewegt. Jedes Token im Kontext hat einen Key- und einen Value-Vektor, die für jeden Layer gespeichert sind, sodass das Modell auf die Vergangenheit zugreifen kann, ohne sie neu berechnen zu müssen. Das macht die Generierung schnell und ist der Grund, warum der Cache nicht optional ist. Er skaliert linear mit dem Kontext, linear mit gleichzeitigen Anfragen und wird durch das Attention-Layout bestimmt, nicht durch die Parameteranzahl. Hier kostet er genau 0,125 GB pro 1024 Token, was wenig ist, da Llama 3.1 acht Key-Value-Heads für zweiunddreißig Query-Heads verwendet.

Runtime overhead ist der Teil, den niemand einplant, auf den aber jeder stößt. Kompilierte Kernels, CUDA- oder Metal-Kontext, Aktivierungs- und Logit-Puffer, der Allocator, der Blöcke nicht perfekt packen kann, und das Working Set des Samplers. Dieser Rechner modelliert ihn als feste 0,65 GB plus 8 Prozent von allem anderen. Es ist eine bewusste Annäherung, aber die Form stimmt: Der Overhead verschwindet bei kleinen Modellen nicht und bleibt bei großen nicht konstant.

Ein Hinweis zur Einheit, da sie für echte Verwirrung sorgt. Jedes GB auf dieser Seite wird durch Division durch 1024 hoch 3 berechnet, es handelt sich also technisch gesehen um ein Gibibyte. Das ist dieselbe Einheit, die Ihr GPU-Treiber meldet, weshalb eine als 24 GB verkaufte Karte etwa 24564 MiB anzeigt. Modelldateien auf Hugging Face werden normalerweise in dezimalen Gigabyte angegeben, daher erscheint ein 5,0-GB-Download hier als etwa 4,65 GB. Die Lücke beträgt etwa 7 Prozent und ist zu Ihren Gunsten, nicht zu Ihrem Nachteil.

Wahl eines Quantisierungslevels

Quantisierung speichert jedes Gewicht in weniger Bits. Ein in BF16 veröffentlichtes Modell verbraucht zwei Bytes pro Parameter; eine 4-Bit-Quantisierung verbraucht etwas mehr als ein halbes Byte. Nichts anderes am Modell ändert sich, weshalb die Quantisierung der wichtigste Hebel ist, um zu entscheiden, ob etwas passt.

Hier ist ein Modell, Llama 3.3 70B, auf jedem Level, das dieser Rechner bietet. Gewichte sind die Datei auf der Festplatte; die anderen beiden Spalten sind der vollständige geladene Speicherbedarf inklusive Cache und Overhead bei einem einzelnen Stream mit einem F16 Cache.

Drei Dinge in dieser Tabelle sind beachtenswert. Erstens ist die nominelle Bit-Anzahl eine Lüge zu Ihren Gunsten und zu Ihren Ungunsten. Q4_K_M sind nicht 4 Bits pro Gewicht, sondern 4,85, da die K-Quant-Formate Attention- und Embedding-Tensoren mit höherer Präzision beibehalten, wo der Schaden am größten ist. Q2_K liegt aus demselben Grund bei durchschnittlich 3,35 Bits. Wenn Sie ein Modell als Parameter mal vier durch acht berechnen, unterschätzen Sie den Bedarf um etwa ein Fünftel.

Zweitens nehmen die Erträge bei niedrigeren Werten stark ab. Der Wechsel von BF16 zu Q8_0 halbiert das Modell, ohne messbare Einbußen. Der Wechsel von Q8_0 zu Q4_K_M halbiert es fast erneut, bei einem Qualitätsverlust, den die meisten im normalen Gebrauch nicht bemerken. Der Wechsel von Q4_K_M zu Q3_K_M spart 7,8 GB, führt jedoch zu schlechterer Befolgung von Anweisungen, schwächerem Code und mehr Rechenfehlern. Darunter tauschen Sie Leistungsfähigkeit gegen Kapazität auf eine Weise, die Sie bemerken werden.

Drittens ist der Schaden durch aggressive Quantisierung nicht gleichmäßig über die Modellgrößen verteilt. Ein 70B-Modell bei Q2_K ist immer noch nutzbar, da enorme Redundanz vorhanden ist. Ein 3B-Modell bei Q2_K erzeugt häufig fehlerhafte Ausgaben. Die Faustregel, die sich in der Praxis bewährt hat: Bevorzugen Sie ein größeres Modell bei niedrigerer Quantisierung bis etwa 4 Bits, und darunter ein kleineres Modell bei 4 Bits oder besser. Ein 70B bei Q4_K_M schlägt ein 32B bei Q8_0 bei den meisten Aufgaben; ein 70B bei IQ2_XXS meist nicht.

Ein Sonderfall, den man kennen sollte: Einige Modelle werden nativ in einem Low-Bit-Format veröffentlicht, statt nachträglich quantisiert zu werden. gpt-oss wird in MXFP4 mit 4,25 Bits pro Gewicht ausgeliefert. Da das Training darauf ausgelegt war, ist die Qualität nicht mit einer 4-Bit-Kompression eines BF16-Releases vergleichbar. Deshalb bietet der Rechner MXFP4 nur für Modelle an, die tatsächlich so ausgeliefert werden, und deshalb benötigt gpt-oss 120B 63,4 GB statt der 250 GB, die ein 117B-Modell bei voller Präzision bräuchte.

Warum die Kontextlänge eine Hardware-Entscheidung ist

Viele behandeln die Kontextlänge wie ein Feature-Flag: Die Modellkarte sagt 128K, also stellt man 128K ein. Es ist jedoch kein Feature-Flag, sondern eine Speicherallokation, und bei einigen Architekturen ist es der größte Einzelposten im Budget. Hier sind vier Modelle bei Q4_K_M, Single-Stream, F16-Cache, mit dem gesamten geladenen Speicherbedarf bei vier Kontextlängen.

Llama 3.1 8B vervierfacht seine Größe zwischen 2K und 128K, von 5,8 GB auf 22,8 GB – der Unterschied zwischen dem Betrieb auf fast jeder Hardware und dem Nicht-Passen auf eine 24-GB-Karte. Command R 35B ist der Extremfall: Es startet bei 2K kleiner als Qwen3 32B und endet bei 128K fast viermal so groß, da es volle Multi-Head-Attention mit 64 Key-Value-Heads nutzt und 1,25 GB Cache pro 1024 Tokens belegt. Gemma 3 27B verändert sich kaum, da fünf von sechs Layern nur ein 1024-Token-Fenster beachten und daher fast sofort aufhören zu wachsen.

Die praktische Konsequenz ist, dass die konfigurierte Kontextlänge der tatsächlich genutzten entsprechen sollte, nicht dem Maximum, das das Modell unterstützt. Wenn Ihre Prompts 3000 Tokens und Ihre Antworten 800 Tokens umfassen, verschwendet die Einstellung 32K Speicher, den Sie in eine bessere Quantisierung hätten investieren können. Llama 3.1 8B bei Q4_K_M auf einer 24-GB-Karte kann einen 64K-Kontext halten, aber keine 128K, da 128K 22,8 GB benötigen und die Karte nach Abzug von Display und Treiber nur etwa 22,3 GB bietet. Die Reduzierung des Caches auf Q8 löst das Problem. Nichts anderes muss geändert werden.

Es kommt auch auf die Runtime an. llama.cpp allokiert den Cache für die übergebene Kontextgröße und nicht mehr, sodass ein kleiner Kontext tatsächlich Speicher freigibt. vLLM hingegen beansprucht vorab einen Teil der Karte und verwaltet einen Paged-Pool darin, weshalb nvidia-smi die Karte fast voll anzeigt, egal was Sie einstellen. Der Wert, den dieser Rechner liefert, ist das benötigte Working-Set, das direkt dem Verhalten von llama.cpp und dem Pool entspricht, den vLLM allokieren können muss.

Der Cache wird durch die Architektur bestimmt, nicht durch die Größe

Die nützlichste Tatsache über den KV-Cache ist, dass die Parameteranzahl ihn kaum vorhersagt. Was ihn bestimmt, ist die Anzahl der Key-Value-Heads, deren Breite, die Anzahl der Layer und ob das Modell spezielle Techniken nutzt. Hier sind die Cache-Kosten pro 1024 Tokens für Modelle, die drei Größenordnungen bei der Parameteranzahl abdecken.

Betrachten Sie die oberste und unterste Zeile zusammen. Ein 671B-Modell hat einen kleineren Cache als ein 35B-Modell, und ein 3,8B-Modell hat einen viereinhalbmal größeren Cache als ein 27B-Modell. Phi-3.5 mini benötigt bei vollen 128K Kontext insgesamt 54,8 GB, wovon nur 2,2 GB auf die Gewichte entfallen. Das ist ein Modell, das als winzig beschrieben wird, aber mehr Speicher benötigt als ein 32B-Modell.

Vier Mechanismen erklären die gesamte Tabelle. Grouped-query attention teilt einen Key-Value-Head auf mehrere Query-Heads auf, was heute Industriestandard ist und den Cache typischerweise um das Vier- bis Achtfache reduziert. Sliding-window attention gibt den meisten Layern ein festes Fenster, sodass der Cache nicht weiter wächst – deshalb flachen Gemma 3 und gpt-oss ab. Multi-head latent attention, wie bei DeepSeek, komprimiert Keys und Values in einen einzelnen 576-Element-Vektor pro Token und Layer, statt sie vollständig zu speichern. Und einfache Multi-head attention, wie sie noch in älteren Releases wie Command R und Phi-3.5 verwendet wird, nutzt nichts davon und zahlt für jeden Head.

Wenn Sie die ausführliche Version dieser Argumentation mit den Herleitungen lesen möchten, finden Sie diese separat in warum die Parameteranzahl ein schlechter Indikator für VRAM ist.

Wann sich KV-Cache-Quantisierung lohnt

Der Cache kann wie die Gewichte quantisiert werden. F16 verbraucht 2 Bytes pro gespeichertem Element; die Q8-Option liegt bei durchschnittlich 1,06 Bytes und Q4 bei 0,56 Bytes, wobei der Overhead durch Skalierungen pro Block entsteht. Jede ernstzunehmende Runtime unterstützt dies: llama.cpp über cache-type-k und cache-type-v, vLLM über ein kv-cache-dtype-Flag.

Die Frage ist nie, ob es Speicher spart. Die Frage ist, ob die Ersparnis groß genug ist, um relevant zu sein, und das hängt vollständig davon ab, wie groß der Cache-Anteil an Ihrem gesamten Speicherbedarf ist. Bei einem 32K-Kontext mit Q4_K_M-Gewichten:

Command R gewinnt 20,3 GB durch ein einziges Flag – der Unterschied zwischen zwei 48-GB-Karten und einer einzigen. Llama 3.3 70B gewinnt 5,1 GB durch dasselbe Flag, da Grouped-query attention den Cache bereits klein hält. Das Muster gilt allgemein: KV-Quantisierung ist bei Multi-head-Modellen mit langem Kontext transformativ, bei Grouped-query-Modellen mit kurzem Kontext jedoch marginal. Prüfen Sie den KV-Cache-Abschnitt in der Aufschlüsselung oben, bevor Sie es nutzen. Wenn dieser Balken nur ein dünner Streifen ist, wird Ihnen das Flag nicht helfen.

Die Kosten sind real, aber begrenzt. Q8-Cache ist qualitativ fast kostenlos und sollte bei Workloads mit langem Kontext standardmäßig aktiviert werden. Q4-Cache verschlechtert genau das, wofür langer Kontext gedacht ist: den präzisen Abruf spezifischer Fakten, die tief im Input vergraben sind. Zusammenfassungen und offene Chats vertragen dies gut; Retrieval über lange Dokumente, Needle-in-a-Haystack-Suchen und Code-Analysen über mehrere Dateien hinweg jedoch nicht. Es gibt auch eine Asymmetrie: Keys sind empfindlicher gegenüber Quantisierung als Values. Wenn Ihre Runtime eine getrennte Einstellung erlaubt, ist ein Q8-Key-Cache mit einem Q4-Value-Cache meist besser als Q4 für beides.

Eine Regel, mit der Sie nichts falsch machen: Quantisieren Sie zuerst die Gewichte, dann den Cache. Q4_K_M-Gewichte mit F16-Cache schlagen in fast jedem Fall Q6_K-Gewichte mit Q4-Cache bei gleicher Gesamtgröße, da die Gewichtsquantisierung weitaus gründlicher erforscht und optimiert wurde als die Cache-Quantisierung.

Zwei 24-GB-Karten sind nicht eine 48-GB-Karte

Das Aufteilen eines Modells auf mehrere GPUs funktioniert und ist bei großen Modellen der einzige bezahlbare Weg. Die Rechnung ist jedoch keine einfache Addition, und der Unterschied zeigt sich an zwei Stellen: nutzbare Kapazität und Dekodiergeschwindigkeit.

Bei der Kapazität verliert eine einzelne Karte einen Teil an den Treiber, die Bildschirmausgabe und die Fragmentierung des Allocators. Dieser Rechner geht von etwa 93 Prozent nutzbarem Speicher bei Consumer-Karten und 95 Prozent bei Workstation- oder Datacenter-Karten ohne angeschlossenen Monitor aus. Ein Multi-Card-Setup verliert mehr, etwa 90 Prozent, da jede Karte ihren eigenen Runtime-Kontext und eine eigene Kopie der Aktivierungs-Buffer benötigt und die Layer-Aufteilung fast nie gleichmäßig aufgeht. Zwei RTX 4090 bieten daher etwa 43,2 GB Arbeitsbereich, während eine einzelne RTX 6000 Ada mit nominell denselben 48 GB 45,6 GB bereitstellt.

Diese Lücke von 2,4 GB entscheidet über reale Anwendungsfälle. Llama 3.3 70B mit Q4_K_M und 8K-Kontext benötigt 46,4 GB und passt somit auf keines der beiden Setups. Die Umstellung des Cache auf Q8 reduziert den Bedarf auf 45,1 GB, was auf die einzelne 48-GB-Karte passt, aber immer noch nicht auf das Paar. Um es auf zwei 4090s zu bringen, muss man zusätzlich auf Q4_0-Weights wechseln, bei 42,5 GB. Gleicher nomineller Speicher, zwei zusätzliche Kompromisse.

Bei der Geschwindigkeit erwartet man üblicherweise, dass zwei Karten doppelt so schnell sind. Beim Single-Stream-Dekodieren sind sie das nicht, und oft sind sie langsamer als eine einzelne Karte, sofern das Modell darauf passt. Die Standardaufteilung in llama.cpp und den meisten Single-Node-Setups ist Pipeline-Parallelität: Layer 0 bis 39 liegen auf Karte eins, 40 bis 79 auf Karte zwei. Die Generierung eines Tokens durchläuft alle achtzig Layer nacheinander, sodass immer nur eine GPU arbeitet, während die andere wartet, zuzüglich eines Hidden-State-Transfers über PCIe an der Schnittstelle. Sie haben Kapazität gekauft, keinen Durchsatz. Dieser Rechner modelliert dies als Abfall der Bandbreiteneffizienz von 0,75 auf einer einzelnen Karte auf 0,6 bei einem Split. Das ergibt bei zwei RTX 4090 etwa 13 Token pro Sekunde bei einem 70B-Modell, während eine einzelne RTX 6000 Ada etwa 16 erreicht, obwohl das Paar eine höhere Rohbandbreite pro Karte besitzt.

Tensor-Parallelität, wie sie vLLM und TensorRT-LLM verwenden, ist die Alternative: Jeder Layer wird über alle Karten verteilt und sie arbeiten gleichzeitig. Das skaliert die Dekodiergeschwindigkeit tatsächlich, erfordert aber ein All-Reduce zwischen den Karten bei jedem Layer, weshalb NVLink oder zumindest volle x16 PCIe-Lanes pro Karte nötig sind. Auf einem Consumer-Mainboard, bei dem die zweite Karte nur mit x4 läuft, kann Tensor-Parallelität langsamer sein als Pipeline-Parallelität. Zudem muss die Anzahl der Attention-Heads durch die Anzahl der Karten teilbar sein, weshalb Setups mit drei Karten problematisch sind.

Das praktische Fazit: Fügen Sie Karten hinzu, um ein Modell auszuführen, das sonst nicht laufen würde, nicht um ein bereits lauffähiges Modell zu beschleunigen. Wenn Sie zwischen einer großen Karte und zwei kleinen zum gleichen Preis wählen, gewinnt die einzelne Karte bei Einfachheit, Stromverbrauch, nutzbarer Kapazität und Single-Stream-Latenz. Mehrere Karten sind im Vorteil, wenn Sie gleichzeitige Anfragen bedienen, da das Batching jede Karte auslastet.

Was passiert beim Offloading in den System-RAM

Wenn ein Modell nicht passt, behalten llama.cpp und Ollama einige Layer im System-RAM und führen diese auf der CPU aus. Es funktioniert. Das ist aber auch der Punkt, an dem Nutzer glauben, ihre Hardware sei defekt, da die Geschwindigkeit nicht sanft abfällt.

Der Grund ist, dass das Dekodieren durch die Speicherbandbreite begrenzt ist, nicht durch die Rechenleistung. Um ein Token zu erzeugen, liest die Runtime jedes aktive Weight und den gesamten Cache einmal. Bei Llama 3.3 70B mit Q4_K_M und 8K-Kontext sind das etwa 45,5 GB Lesezugriffe pro Token. Teilen Sie diesen Wert durch die Bandbreite des Speichers, in dem sich die Daten befinden, und Sie erhalten Ihr Limit, noch bevor eine Berechnung stattgefunden hat.

Eine RTX 4090 liest mit 1008 GB/s. Dual-Channel DDR5 in einem typischen Desktop erreicht etwa 90 GB/s. Das ist ein elffacher Unterschied, und das ist der ganze Punkt. Würde das 70B-Modell komplett in die 4090 passen, würde es mit etwa 17 Token pro Sekunde dekodieren. Es passt nicht: 22,3 GB der 46,4 GB sind resident, also kommen 52 Prozent jedes gelesenen Tokens aus dem System-RAM mit einem Neuntel der Geschwindigkeit. Das Ergebnis sind etwa 2,6 Token pro Sekunde. Sie haben 48 Prozent des Modells auf dem schnellen Gerät behalten und 84 Prozent der Geschwindigkeit verloren.

Dasselbe Muster gilt für alle Größen. Llama 3.1 8B liest 5,9 GB pro Token; auf einer 4090 sind das etwa 127 Token pro Sekunde, rein auf der CPU mit 90 GB/s RAM sind es etwa 11. Qwen3 32B mit Q4_K_M benötigt 22,8 GB, also bleiben auf einer 16 GB RTX 5080 etwa 65 Prozent resident, und die Schätzung fällt von etwa 33 Token pro Sekunde auf etwa 8.

Zwei Details machen die tatsächliche Erfahrung schlechter, als diese Zahlen vermuten lassen. Die Prompt-Verarbeitung auf CPU-Layern ist eher rechenintensiv als bandbreitenlimitiert, daher kann ein langer Prompt Minuten dauern, bis das erste Token erscheint, selbst wenn die Streaming-Rate danach akzeptabel aussieht. Und Offloading ist auch auf der GPU-Seite nicht kostenlos, da die Runtime weiterhin Arbeits-Buffer für die Layer benötigt, die sie tatsächlich hostet.

Wann Offloading die richtige Wahl ist: Batch-Jobs, auf die Sie nicht warten, Modelle, bei denen ein paar Token pro Sekunde ausreichen, und Fälle, in denen nur eine Handvoll Layer ausgelagert werden müssen. Zehn Prozent Offloading kosten Sie weit weniger als fünfzig Prozent. Wann es die falsche Wahl ist: bei allem Interaktiven. Ein kleineres Modell mit einer guten Quantisierung ist fast immer besser als ein größeres, das sich durch Ihre DIMMs quält. Wenn Sie die Fähigkeiten des größeren Modells benötigen, ist der Aufruf über eine API schneller und günstiger, als Ihren Desktop dazu zu zwingen.

Apple Silicon und Unified Memory

Apple Silicon hat keinen separaten VRAM. CPU und GPU teilen sich einen Pool aus LPDDR auf demselben Package, was bedeutet, dass ein Mac mit 128 GB Speicher ein Modell laden kann, das keine Consumer-GPU auf dem Markt halten kann. Das ist ein echter Vorteil und der Grund, warum Macs in lokalen Inference-Kreisen verbreitet sind. Es gibt jedoch zwei Einschränkungen, die Nutzer oft erst spät entdecken.

Die erste ist, dass Ihnen nicht der gesamte Speicher zur Verfügung steht. macOS reserviert Speicher für alle anderen Aufgaben des Systems und begrenzt, was die GPU fest belegen darf; dieser Rechner geht von etwa 75 Prozent Verfügbarkeit für ein Modell aus. Aus 128 GB Unified Memory werden also etwa 96 GB Budget, und aus einem 16 GB Mac mini etwa 12 GB. Das Limit kann über die iogpu wired limit-Einstellung erhöht werden, aber es nahe an das physische Maximum zu treiben, riskiert, dass das System swappt – und ein Modell zu swappen ist schlimmer, als es gar nicht zu laden.

Die zweite ist die Bandbreite. Unified Memory ist breit, aber nicht so breit wie GDDR. Ein M4 Max liest mit etwa 546 GB/s gegenüber 1008 GB/s bei einer RTX 4090 und 1792 GB/s bei einer RTX 5090. Der Basis-M4 im Mac mini liest mit etwa 120 GB/s – ein Drittel dessen, was eine fünf Jahre alte RTX 3060 schafft. Bei Llama 3.1 8B mit Q4_K_M ergibt das etwa 60 Token pro Sekunde auf einem M4 Max, etwa 13 auf einem Basis-M4 Mac mini und etwa 45 auf der RTX 3060. Kapazität und Geschwindigkeit sind getrennte Käufe, und Apple verkauft viel von ersterem pro Dollar und relativ wenig von letzterem.

Die Prompt-Verarbeitung ist der kritischere Punkt. Dekodieren ist bandbreitenlimitiert, wo Apple nur leicht zurückliegt; Prefill ist rechenintensiv, wo die Lücke zu einer modernen NVIDIA-Karte mit dedizierten Tensor-Cores viel größer ist. Ein 30.000-Token-Dokument, das in einen Chat auf einem Mac eingefügt wird, kann eine spürbare Zeit lang hängen, bevor das Streaming beginnt, auch wenn das Streaming selbst danach gut aussieht. Wenn Ihr Workload aus langen Prompts und kurzen Antworten besteht, ist das der Wert, den Sie vor dem Kauf testen sollten.

Wo ein Mac klar gewinnt, ist der mittlere Bereich, den diskrete Karten zu keinem vernünftigen Preis erreichen können. Llama 3.3 70B mit Q4_K_M passt bequem in einen 128 GB M4 Max mit etwa 8 Token pro Sekunde, und ein 192 GB M2 Ultra lässt es mit etwa 11 laufen, während er auch Modelle halten kann, die weit über 100 GB benötigen. Das mit NVIDIA-Hardware zu erreichen, bedeutet mehrere Karten, ein Mainboard mit den nötigen Lanes und ein entsprechendes Netzteil. Verwenden Sie nach Möglichkeit MLX anstelle eines generischen Backends, da es für dieses Speichermodell geschrieben wurde und auf derselben Maschine die Alternativen durchweg schlägt.

Mehrere Personen gleichzeitig bedienen

Alles oben Genannte geht von einer Anfrage zur Zeit aus. Sobald Sie das Modell hinter einem Endpoint platzieren, den andere nutzen, bleiben die Weights geteilt, aber jede gleichzeitige Anfrage trägt ihren eigenen KV-Cache. Das macht den Cache von einem Nebeneffekt zum dominierenden Kostenfaktor. Llama 3.1 8B mit Q4_K_M und 8K-Kontext bei steigender Parallelität:

Bei sechzehn gleichzeitigen Nutzern ist der Cache größer als das Modell. Bei zweiunddreißig benötigt ein 8B-Modell mehr Speicher als ein 70B-Modell für einen einzelnen Nutzer. Das ist die Zahl, die Teams überrascht, die auf einem Laptop prototypisiert haben und sich dann wunderten, warum der Server bei acht Personen zusammenbrach.

Der Vorteil ist, dass GPUs bei Parallelität nicht mehr verschwendet werden. Single-Stream-Dekodierung lässt die meiste Rechenleistung brachliegen, weil sie auf den Speicher wartet; Batching amortisiert einen Weight-Read über viele Sequenzen, sodass der Gesamtdurchsatz viel schneller steigt als die Speichernutzung. Das ist auch der Fall, in dem sich ein Paged-Cache bezahlt macht, da vLLM den Cache in Blöcken zuweist, während die Sequenzen wachsen, anstatt den Worst-Case für jeden Slot zu reservieren. Wenn Sie einen Server dimensionieren, planen Sie den Cache für Ihre tatsächliche Parallelität und Ihre mittlere Prompt-Länge, nicht für den maximalen Kontext multipliziert mit der maximalen Nutzerzahl.

Häufige Fehler bei der GPU-Dimensionierung

Fragen, die Leute tatsächlich stellen

Wie viel VRAM brauche ich, um ein 7B- oder 8B-Modell auszuführen?

Etwa 6,6 GB bei Q4_K_M mit einem 8K-Kontext, was auf eine 8-GB-Karte mit etwas Spielraum passt. Bei BF16 benötigt dasselbe Modell 17,9 GB und verlangt eine 24-GB-Karte. Bei vollem 128K-Kontext steigt der Bedarf auf 22,8 GB, daher ist der Kontext hier genauso wichtig wie die Genauigkeit.

Warum weigert sich mein 8-GB-Modell, auf einer 8-GB-Karte zu laden?

Drei Gründe summieren sich. Der Treiber und der Desktop haben bereits etwa 7 Prozent der Karte belegt, der KV-Cache wird zusätzlich zu den Gewichten alloziert, und die Laufzeitumgebung benötigt vor der Arbeit etwa 0,65 GB für Kontext und Kernel-Speicher. Die Dateigröße ist die einzige Zahl, die nichts davon enthält.

Kann eine 24-GB-Karte ein 70B-Modell ausführen?

Nicht allein im VRAM. Llama 3.3 70B benötigt 46,4 GB bei Q4_K_M und 8K, und selbst bei IQ2_XXS mit 2K-Kontext sind es noch 22,5 GB gegenüber etwa 22,3 GB verfügbarem Speicher. Du kannst auf den Systemspeicher auslagern und erhältst etwa zwei Tokens pro Sekunde oder führst stattdessen ein 32B aus und bekommst etwa dreißig.

Ist Q4_K_M tatsächlich gut genug?

Für fast alles ja, und es ist aus gutem Grund die Standardeinstellung. Es speichert 4,85 Bits pro Gewicht statt pauschal 4, wobei Attention- und Embedding-Tensoren mit höherer Genauigkeit erhalten bleiben. Die messbare Lücke zu Q8_0 ist gering und die Speicherersparnis beträgt fast die Hälfte. Unterschreite es nur, wenn die Alternative ist, das Modell gar nicht auszuführen.

Ist ein größeres Modell mit niedriger Genauigkeit besser als ein kleineres mit hoher Genauigkeit?

Bis etwa 4 Bits ja. Ein 70B auf Q4_K_M übertrifft einen 32B auf Q8_0 bei den meisten Aufgaben mit ähnlichem Footprint. Unter 3 Bits kehrt sich die Reihenfolge für kleine und mittelgroße Modelle um, da weniger Redundanz aufgegeben werden kann. Sehr große Modelle tolerieren 2-Bit-Formate deutlich besser als kleine.

Warum ist der KV-Cache bei einem 3,8B-Modell größer als bei einem 27B-Modell?

Weil Phi-3.5 mini volle Multi-Head-Attention mit 32 Key-Value-Heads verwendet, bei 0,375 GB pro 1024 Tokens, während Gemma 3 27B fünf von sechs Schichten ein 1024-Token-Fenster mit gleitendem Fenster gibt. Bei 128K sind das 48 GB gegenüber 10,4 GB. Die Cache-Größe folgt dem Attention-Layout, nicht der Parameteranzahl.

Sollte ich den KV-Cache quantisieren?

Aktiviere Q8, sobald dein Kontext lang ist; es ist fast kostenlos. Nutze Q4 nur, wenn der Cache einen großen Teil deines Footprints ausmacht und deine Arbeitslast nicht stark auf Abruf angewiesen ist. Bei Command R 35B auf 32K spart Q8 20,3 GB. Bei Llama 3.3 70B im gleichen Kontext spart es 5,1 GB, da Grouped-Query-Attention bereits die Arbeit erledigt hat.

Ersetzen zwei 24-GB-Karten eine 48-GB-Karte?

Nein. Du erhältst etwa 43,2 GB nutzbaren Speicher statt 45,6 GB, da jede Karte ihren eigenen Laufzeitkontext trägt und die Schichtaufteilung ungleichmäßig ist. Auch die Single-Stream-Geschwindigkeit verbessert sich nicht, da Pipeline-Parallelität bedeutet, dass eine Karte rechnet, während die andere wartet. Zwei Karten bieten Kapazität und bei Parallelität Durchsatz.

Wie schnell läuft es tatsächlich?

Teile die Speicherbandbreite durch die pro Token gelesenen Bytes. Llama 3.1 8B auf Q4_K_M liest 5,9 GB pro Token, sodass eine RTX 4090 mit 1008 GB/s nach Effizienzverlusten etwa 127 Tokens pro Sekunde erreicht. Diese Schätzung gilt nur für das Decodieren. Die Prompt-Verarbeitung ist compute-gebunden und folgt einer anderen Kurve.

Was passiert tatsächlich, wenn ich auf den Systemspeicher auslagere?

Die Geschwindigkeit bricht ein, statt allmählich zu sinken. Llama 3.3 70B mit 48 Prozent seiner Schichten auf einer RTX 4090 und dem Rest in DDR5 decodiert mit etwa 2,6 Tokens pro Sekunde statt der 17, die es vollständig resident schaffen würde. Ein kleiner Überlauf ist verkraftbar; die Hälfte des Modells nicht.

Ist ein Mac eine gute Maschine für lokale Inferenz?

Für Kapazität pro Euro ja: Ein 128-GB-M4-Max bietet etwa 96 GB nutzbaren Speicher und führt ein 70B-Modell mit etwa 8 Tokens pro Sekunde aus. Für reine Geschwindigkeit nein: 546 GB/s Bandbreite gegenüber 1792 GB/s bei einer RTX 5090, und die Prompt-Verarbeitung hinkt noch weiter hinterher. Kaufe einen Mac für große Modelle und leisen Betrieb, nicht für niedrige Latenz.

Sparen Mixture-of-Experts-Modelle Speicher?

Sie sparen Zeit, nicht Speicher. Qwen3 30B-A3B benötigt weiterhin 20,1 GB, da jeder Experte resident sein muss, liest aber nur etwa 3,3B Parameter pro Token und decodiert daher mehrere Male schneller als ein dichtes 32B mit gleichem Footprint. Beurteile ein MoE-Modell nach seinem Gesamtbedarf für die Ausführung und nach seinen aktiven Parametern für die Geschwindigkeit.

Reduziert Flash Attention den VRAM?

Es entfernt die große Zwischenmatrix der Attention, was während des Prefills bei langen Prompts eine echte Ersparnis darstellt und die Prompt-Verarbeitung beschleunigt. Es verkleinert nicht den KV-Cache, der mit dem Kontext wächst. Aktiviere es trotzdem; erwarte nur nicht, dass sich die Gesamtwerte auf dieser Seite ändern.

Warum zeigt nvidia-smi die Karte als voll an, wenn ich einen kleinen Kontext einstelle?

Du führst wahrscheinlich vLLM aus, das beim Start einen festen Anteil der Karte belegt und einen gepagten Cache-Pool darin verwaltet. llama.cpp alloziert nur das, was der von dir angefragte Kontext benötigt. Die hier angezeigten Werte beschreiben den Arbeitsspeicher, den vLLM allozieren können muss, und den llama.cpp direkt meldet.

Wie viel VRAM brauche ich, um ein Modell fein abzustimmen statt es nur auszuführen?

Viel mehr, und dieser Rechner bildet es nicht ab. Eine vollständige Feinabstimmung hält Gewichte, Gradienten und Optimierer-Status mit etwa 16 Bytes pro Parameter, sodass ein 8B-Modell vor Aktivierungen bei etwa 130 GB landet. QLoRA auf einer 4-Bit-Basis liegt viel näher am Inferenz-Footprint plus Aktivierungs-Speicher, weshalb es die einzige realistische Option auf einer einzelnen Consumer-Karte ist.

Ändern Bildmodelle die Berechnung?

Der Vision-Encoder ist in der Parameteranzahl der hier aufgeführten multimodalen Modelle enthalten, sodass die Gewichtsangabe korrekt ist. Was die Gesamtwerte nicht erfassen, ist, dass Bilder vor dem Erreichen des Sprachmodells in eine große Anzahl von Tokens expandiert werden, sodass wenige hochauflösende Bilder mehr Kontext und damit mehr Cache verbrauchen können als eine Textseite.

Was, wenn nichts passt?

Reduziere zuerst den Kontext, da dies meist der günstigste Kompromiss ist, quantisiere dann den Cache auf Q8 und gehe eine Stufe bei den Gewichten herunter. Falls du immer noch knapp bist, schlägt ein kleineres Modell mit sinnvoller Quantisierung ein größeres, das aus dem Systemspeicher ausgelagert wird. Oder rufe dieselben Open-Weight-Modelle über die kostenlose API auf und überlass die Hardware jemand anderem.