Zum Hauptinhalt springen
Jedes lokale Modell benötigt ausreichend Speicher, um seine Gewichte, seinen KV-Cache und einige Arbeitsreserven zu halten – und wenn es nicht vollständig in die VRAM passt, entscheidet die Auslagerung (Offloading), was schnell auf der GPU und was langsam auf der CPU ausgeführt wird. Diese Seite behandelt die Auslegungstheorie und die Mechanik der Auslagerung; für fertige VRAM-Tabellen nach GPU und Modellgröße siehe den GPU-Modell-Passungsleitfaden – diese Seite wiederholt diese Tabellen nicht.

​
Die Auslegungsformel

Modellgewichte benötigen eine feste Anzahl von Bytes pro Parameter, die durch die Genauigkeit festgelegt ist: GGUF Q4_K_M ist eine gemischte Genauigkeit und ergibt im Durchschnitt etwa 0.5–0.56 Bytes pro Parameter statt einem festen 0.5, da K-Quants verschiedenen Tensoren unterschiedliche Bitbreiten zuweisen – siehe Quantisierung, um diese Namen zu lesen. Multiplizieren Sie die Parameteranzahl mit den Bytes pro Parameter, um die reine Gewichtsgröße zu erhalten, und addieren Sie dann etwa 20% für den KV-Cache, Aktivierungen und Framework-Overhead bei einer moderaten Kontextlänge:
Hugging Face hat dieses Muster direkt an einem 15B+-Modell gemessen: etwa 29 GB bei bf16, ~15 GB bei 8-Bit und ~9.5 GB bei 4-Bit – siehe den Hugging Face-Leitfaden zur Optimierung von LLMs. Längere Kontexte fügen zusätzlich zu dieser 1.2×-Basis mehr KV-Cache hinzu; siehe KV-Cache und Kontext, warum sich das so skaliert.
Diese Formel ist eine Planungsschätzung für die Gewichtsgröße, nicht der genaue Ist-Wert. Die reale Zahl ist die tatsächliche GGUF-Dateigröße für die exakte Quantisierung, die Sie ausführen möchten, plus der KV-Cache für Ihre Zielkontextlänge. Siehe den GPU-Modell-Passungsleitfaden für durchgerechnete Beispiele und einen interaktiven Schätzer.

​
Was tatsächlich um Speicher konkurriert

Drei Dinge teilen sich denselben Pool an VRAM (oder Unified Memory):
  • Modellgewichte – fest, sobald das Modell geladen ist, unabhängig von der Prompt-Länge.
  • KV-Cache – wächst mit der Kontextlänge und der Batch-Größe; siehe KV-Cache und Kontext.
  • Aktivierungen und Framework-Overhead – kleinerer Arbeitsspeicher, der während jedes Forward-Passes benötigt wird, ungefähr das, was der 1.2×-Faktor in der obigen Formel berücksichtigt.
Gewichte sind die größten und vorhersehbarsten Kosten. Der KV-Cache ist der Teil, der Sie überraschen kann, da er unsichtbar bleibt, bis Ihr Kontext wächst.

​
Auslagerung: Wenn ein Modell nicht vollständig passt

Wenn die Gewichte eines Modells nicht vollständig in den VRAM Ihrer GPU passen, ermöglichen Backends wie llama.cpp, das Modell zwischen GPU und CPU aufzuteilen, anstatt komplett zu scheitern. Dies wird mit der --n-gpu-layers-Flag (Kurzform -ngl) gesteuert: Sie legt fest, wie viele der Schichten des Modells auf die GPU geladen werden, während der Rest im System-RAM verbleibt.
  • Vollständige Auslagerung (-ngl hoch genug gesetzt, um jede Schicht abzudecken): Das gesamte Modell läuft auf der GPU mit voller GPU-Geschwindigkeit.
  • Partielle Auslagerung: Einige Schichten laufen auf der GPU, der Rest auf der CPU unter Verwendung des System-RAM. Dies ermöglicht es, dass ein Modell, das größer als Ihr VRAM ist, tatsächlich geladen und ausgeführt wird, jedoch zu einem Preis.
  • Keine Auslagerung (-ngl 0): Das gesamte Modell läuft nur auf der CPU.
Der Preis der partiellen Auslagerung ist Geschwindigkeit, nicht Korrektheit – die Ausgabe ist auf beide Weise gleich. CPU-seitige Schichten und System-RAM haben eine viel geringere Speicherbandbreite als GPU-VRAM, und wie aus Wie Inferenz funktioniert bekannt ist, ist die Dekodierung speicherbandbreitenbegrenzt: Jedes generierte Token muss die relevanten Schichten lesen, sodass jede Schicht, die sich in langsamerem Speicher befindet, bei jedem einzelnen Schritt zum Flaschenhals wird. Je mehr Schichten Sie von der GPU verlagern, desto langsamer wird die Generierung – manchmal dramatisch, sobald das Modell vom RAM auf die Festplatte überläuft.
Wenn ein Modell auf die Festplatte (Swap) überläuft, anstatt im RAM zu bleiben, erwarten Sie einen schweren Geschwindigkeitsverlust – die Festplattenbandbreite ist um Größenordnungen langsamer als RAM, geschweige denn VRAM. Behandeln Sie das Überlaufen auf die Festplatte als Zeichen, ein kleineres Modell oder eine aggressivere Quantisierung zu wählen, anstatt es einfach durchlaufen zu lassen.
Finden Sie den exakten Flag-Namen und das Verhalten für Ihr Backend im llama.cpp-Repository; andere Backends (LM Studio, Ollama) stellen dieselbe Idee über ihre eigenen Einstellungen bereit, die meist auf llama.cpp basieren.

​
Wie Unified Memory das Bild verändert

Auf Systemen mit Unified Memory – Apple Silicon und AMDs Strix Halo-Plattform – teilen sich CPU und GPU einen einzigen Speicherpool, anstatt dass die GPU ihren eigenen separaten, kleineren VRAM hat. Dies verändert die Auslagerungsrechnung:
  • Kapazität: Ein Unified-Memory-System kann ein viel größeres Modell laden als eine diskrete GPU mit festem VRAM, da der “VRAM”-Pool so groß sein kann wie der gesamte RAM des Geräts (bis zum für die Grafikkarte zugewiesenen Anteil).
  • Bandbreite: Derselbe Pool läuft mit einer geringeren Bandbreite als dedizierter GDDR-Speicher auf einer diskreten GPU. Ein Modell, das vollständig in Unified Memory passt, dekodiert immer noch langsamer als dasselbe Modell, das vollständig in den VRAM einer diskreten GPU passt, da die Dekodiergeschwindigkeit der Bandbreite folgt, nicht nur der Kapazität.
In der Praxis verschiebt Unified Memory den Kompromiss von “passt es überhaupt” zu “wie schnell läuft es, sobald es passt” – es löst das Kapazitätsproblem, das die Auslagerung überhaupt erzwingt, gibt Ihnen aber nicht im Gegenzug GDDR-Klassen-Bandbreite. Siehe den GPU-Modell-Passungsleitfaden, wie sich spezifische Unified-Memory-Systeme im Vergleich zu diskreten GPUs verhalten.

​
Tiefer einsteigen

Wie Inferenz funktioniert

Warum die Dekodierung überhaupt speicherbandbreitenbegrenzt ist.

KV-Cache und Kontext

Der Teil der Speichernutzung, der mit Ihrer Konversation wächst, nicht nur mit Ihrem Modell.

Quantisierung

Reduzieren Sie die Bytes pro Parameter, um den größten Eingabewert der Auslegungsformel zu ändern.

GPU-Modell-Passungsleitfaden

VRAM-Tabellen, ein interaktiver Schätzer und was auf gängiger Hardware passt.

​
Sobald es passt und läuft

Auslegung und Auslagerung bringen ein Modell auf Ihrer Hardware zum Laufen, sei es vollständig auf der GPU oder aufgeteilt mit der CPU. Sobald es Anfragen auf localhost beantwortet, ist der nächste Schritt, von überall darauf zuzugreifen.

Geben Sie ihm einen stabilen Endpunkt

Tokios wählt, hostet oder feinabstimmt das Modell nicht – sobald es lokal läuft, verwandelt Tokios es in einen stabilen, authentifizierten Endpunkt, den Sie von überall aus aufrufen können.