Lokale Sprachmodelle brauchen auch Speicher für die Unterhaltung

Ein lokaler Assistent soll ein langes Protokoll auswerten. Bei der Einrichtung liegt der Vergleich nahe: Wie groß ist die Modelldatei, wie viel Speicher ist frei? Für die eigentliche Aufgabe kommen jedoch Zustände der verarbeiteten Texte und Arbeitsbereiche hinzu. Eine größere Kontextlänge erhöht den Speicherbedarf.¹²³

Prüfen lässt sich die Konfiguration deshalb am vollständigen Auftrag: Protokoll einlesen, Fragen beantworten und die Antwort beenden. Dieser Artikel erklärt die Speicherposten anhand offizieller Dokumentation. Eigene Messungen bestimmter Rechner liegen ihm nicht zugrunde.

Am Fehlerzeitpunkt mit der Suche beginnen

Beobachtung	Zuerst untersuchen	Nächster Vergleich
Fehler beim Laden	Gewichte, Platzierung, Ladespitze3	Kleinere Datei bei gleichen Einstellungen
Fehler mit langen Texten	Kontextzuweisung und KV-Cache42	Kürzerer Kontext, gleiches Modell
Fehler bei überlappenden Anfragen	Parallele Speicherzuweisung5	Dieselben Aufgaben nacheinander
Hohe GPU-Belegung nach der Antwort	Aktive Tensoren und PyTorch-Reserve6	allocated und reserved gegenüberstellen
Lange Wartezeit nach Auslagerung	Transfers und Ausführung43	Nur die Platzierung verändern

Die Tabelle liefert Prüfideen, keine fertige Fehlerdiagnose. Die folgenden Abschnitte erläutern die Speicherposten hinter diesen Beobachtungen. Notiere Modell- und Programmversion, Kontext, Cache-Präzision, Platzierung und aktive Parallelität. Beobachte Laden, Eingabeverarbeitung und Ausgabe, denn dabei treten unterschiedliche Zuweisungen auf.¹³

Bewahre das Protokoll als Vergleichsaufgabe für spätere Änderungen auf. Eine passende Konfiguration beendet diesen Auftrag mit brauchbaren Antworten und einer Wartezeit, die zu deinem Arbeitsablauf passt.

Die Gewichte sind der erste Posten

Modellgewichte enthalten gelernte Parameter. Quantisierung speichert sie mit geringerer Präzision und soll dabei möglichst viel Genauigkeit erhalten. Die Parameterzahl allein lässt offen, welches Speicherformat und welche konkrete Datei verwendet werden.⁷

Als grobe Planung helfen getrennte Posten für residente Gewichte, KV-Cache, vorübergehende Rechenbereiche und Zuweisungen der Laufzeitumgebung. Andere Programme brauchen ebenfalls Platz. Diese Aufteilung ist eine Schätzhilfe; Verteilung und Ladeverfahren bestimmen, welcher Speicher belastet wird und wann der Höchststand entsteht.¹⁶³

Für Gewichte allein ergibt „Parameterzahl × Bits je Gewicht ÷ acht“ eine Schätzung in Bytes. Sie setzt gleichmäßige Präzision und dicht gepackte Speicherung voraus. Quantisierungskonstanten und Module mit anderer Präzision können hinzukommen. Die konkrete Datei und die Meldungen des Programms müssen diese Annahme korrigieren. Cache und Arbeitsbereiche fehlen in der Rechnung.⁷⁸

Beim Lesen entsteht ein eigener Cache

Ein autoregressiver Transformer erzeugt das nächste Token anhand des bisherigen Kontexts. Im Key-Value-Cache, kurz KV-Cache, liegen Schlüssel und Werte bereits verarbeiteter Tokens aus den Aufmerksamkeitsschichten. Das Modell kann diese Ergebnisse wiederverwenden. Sie gehören zum Zustand der Anfrage und sind von den Gewichten getrennt.¹

Ein dynamischer Cache wächst während der Ausgabe. Ein statischer Cache reserviert vorher eine maximale Größe; auch ein kurzer Text kann deshalb mit einer großen Reservierung einhergehen. Schichten mit gleitendem Aufmerksamkeitsfenster oder blockweiser Aufmerksamkeit haben andere Wachstumsgrenzen. Die Architektur muss zur Schätzung passen.⁴

Bei einem üblichen Cache für vollständige Aufmerksamkeit zählen gespeicherte Tokens, parallele Sequenzen, Schichten, KV-Köpfe, deren Dimensionen und die Cache-Präzision. Zwei Modelle mit ähnlicher Parameterzahl sind damit noch nicht hinsichtlich des Caches beschrieben. Vergleiche der Textlänge sollten Modell und Präzision konstant halten.¹⁴

Plane auch die Antwort ein. Die tatsächliche Eingabe umfasst die Anweisung und den relevanten Gesprächsverlauf. Wenn der Dokumenttext den vorgesehenen Kontext bereits ausschöpft, bleibt in diesem Fenster wenig Platz für die Fortsetzung. Für einen Vergleich eignet sich die mit dem Modell tokenisierte vollständige Anfrage.¹²

Reservierter Speicher ist kein zusätzlicher Verbrauchsposten

In PyTorch mit CUDA unterscheiden sich Speicher für aktive Tensoren und der gesamte vom Cache-Allocator verwaltete Bereich. Dafür gibt es memory_allocated() und memory_reserved() sowie entsprechende Spitzenwerte. Ungenutzte Reserven können in nvidia-smi weiterhin als belegt erscheinen.⁶

Diese Werte überlappen sich. Wer sie addiert, zählt einen Teil doppelt. empty_cache() gibt ungenutzte Cache-Blöcke frei, während aktive Tensoren erhalten bleiben. Der Aufruf beseitigt also weder verwendete Modellgewichte noch den aktiven KV-Cache.⁶

Die genannten Funktionen gehören zu PyTorch. Für llama.cpp sind dessen Berichte zuständig. Beobachte den Spielraum bei Initialisierung und Berechnung, statt für jede Laufzeitumgebung pauschal denselben Aufschlag anzunehmen.⁹³

CPU-Auslagerung braucht eine eigene Zeitmessung

llama.cpp kann die Zahl der in VRAM gespeicherten Schichten begrenzen. Transformers bietet daneben Cache-Auslagerung an: Die meisten Schicht-Caches liegen dann auf dem CPU-Speicher und werden bei Bedarf übertragen. Halte fest, ob du Gewichte oder Cache verlagert hast.⁴⁹

System-RAM und dedizierter Grafikspeicher benötigen getrennte Budgets. Die Dokumentation nennt mögliche Einbußen beim Generierungsdurchsatz durch Cache-Transfers. Ein allgemeiner Verlangsamungsfaktor lässt sich daraus nicht ableiten. Entscheidend bleibt, wie lange deine vollständige Aufgabe braucht.⁴³

Quantisierung von Gewichten und Cache getrennt entscheiden

Der Dateiname quantisierter Gewichte bestimmt die Cache-Präzision nicht. llama.cpp bietet eigene Optionen für Schlüssel- und Werte-Cache. Ollama dokumentiert ebenfalls eine Einstellung zur Cache-Quantisierung. Welche Kombination funktioniert, ist am verwendeten Backend zu prüfen.⁵⁹

Ollama weist darauf hin, dass die Wirkung auf die Antwortqualität vom Modell und der Aufgabe abhängt. Verwende daher Texte, deren Details du überprüfen kannst. Vergleiche etwa das Auffinden einer konkreten Angabe und die Einhaltung eines Ausgabeformats. Behalte die Anweisungen bei und ändere jeweils nur eine Präzisionseinstellung.⁵

Weniger Speicher bedeutet auch keine feste Geschwindigkeitszusage. Laut Transformers kann ein quantisierter Cache bei kurzen Kontexten die Latenz verschlechtern, wenn bereits genügend GPU-Speicher vorhanden ist. Eine solche Option sollte eine beobachtete Grenze adressieren; danach muss dieselbe Aufgabe erneut laufen.⁴

Lange Kontexte und parallele Anfragen gemeinsam prüfen

Ollama beschreibt zusätzlichen Speicherbedarf durch längere Kontexte und durch parallele Verarbeitung desselben Modells. Gemeinsam geladene Gewichte ersetzen den Zustand der einzelnen aktiven Anfragen nicht. Auch „Dateigröße mal Nutzerzahl“ bildet diese Aufteilung nicht sinnvoll ab.⁵²

Führe die Anfragen für deinen persönlichen Assistenten zunächst nacheinander aus. Prüfe dabei, ob eine lange Aufgabe vollständig abgeschlossen wird. Soll der Dienst geteilt werden, folgt ein Versuch mit überlappenden langen Anfragen. Ollama unterscheidet aktive Parallelverarbeitung und Warteschlange und stellt dafür unterschiedliche Einstellungen bereit.⁵

Mit ollama ps lassen sich der zugewiesene Kontext und die CPU/GPU-Verteilung kontrollieren. Gib die Kontextlänge beim Vergleich ausdrücklich vor. FAQ und Kontextanleitung beschreiben derzeit unterschiedliche Standardwerte. Die beobachtete Einstellung ist deshalb die bessere Grundlage für eine wiederholbare Prüfung.⁵²

Quellen

Footnotes

1. Hugging Face Transformers — Englische Erklärung des KV-Caches und seiner Dimensionen: https://huggingface.co/docs/transformers/en/cache_explanation ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

2. Ollama — Kontextlänge, Speicherbedarf und Kontrolle der Zuweisung; englisches Original: https://docs.ollama.com/context-length ↩ ↩² ↩³ ↩⁴ ↩⁵

3. Hugging Face Accelerate — Laden, Verteilung und Laufzeitbedarf; englisches Original: https://huggingface.co/docs/accelerate/en/concept_guides/big_model_inference ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

4. Hugging Face Transformers — Cache-Arten, Reservierung, Quantisierung und Auslagerung; englisches Original: https://huggingface.co/docs/transformers/en/kv_cache ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

5. Ollama FAQ — Parallelität, Warteschlange, Platzierung und Cache-Quantisierung; englisches Original: https://docs.ollama.com/faq ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

6. PyTorch CUDA — Aktive und reservierte Bereiche sowie Cache-Freigabe; englische Dokumentation: https://docs.pytorch.org/docs/2.14/notes/cuda.html ↩ ↩² ↩³ ↩⁴

7. Hugging Face Transformers — Englische Originaldokumentation zu Quantisierung und Genauigkeit: https://huggingface.co/docs/transformers/en/quantization/overview ↩ ↩²

8. Hugging Face bitsandbytes — Quantisierungskonstanten und Modulpräzision; englisches Original: https://huggingface.co/docs/transformers/en/quantization/bitsandbytes ↩

9. llama.cpp server — Offizielle Optionen für GPU-Schichten und K/V-Cache-Typen: https://github.com/ggml-org/llama.cpp/blob/master/tools/server/README.md ↩ ↩² ↩³