Lokales LLM aus dem VRAM gefallen? Gewichte vs. KV-Cache mit gputaskman sehen

Dein lokales Modell hat gestern noch einwandfrei geladen, heute stürzt es beim Laden ab oder kriecht nur noch dahin, und das Einzige, was du geändert hast, war die Kontextlänge. Ein häufiger Übeltäter ist der KV-Cache, und ein kostenloses Terminal-Tool namens gputaskman kann dir das zeigen, statt dich raten zu lassen.

Ein typischer GPU-Monitor sagt dir, wie voll der VRAM ist. Das ist das „Was“, nicht das „Warum“. Die README von gputaskman (geprüft am 5. November 2026) beschreibt sich selbst als „Ein htop für das, was in deiner GPU steckt, nicht nur dafür, wie voll sie ist.“ Es ist ein frühes, experimentelles Projekt unter MIT-Lizenz, also behandle es als praktische Linse, nicht als Urteil.

Was deinen VRAM tatsächlich füllt#

Stell dir den VRAM als Koffer vor. Drei Dinge kommen hinein:

• Gewichte: das Modell selbst. Feste Größe für ein gegebenes Modell und eine gegebene Quantisierung.
• KV-Cache: das Kurzzeitgedächtnis des Modells für deine Unterhaltung. Er wächst mit dem Kontext.
• Compute-Buffer: Arbeitsbereich, den die Runtime während der Arbeit braucht.

Wenn Leute sagen „das Modell passt nicht“, meinen sie oft, dass die Gewichte passen, aber der zusätzlich angeforderte Cache nicht mehr. Diese Unterscheidung entscheidet über die Lösung, und genau das verbirgt ein gewöhnlicher Monitor.

Installiere gputaskman und schau pro Prozess#

Die README nennt drei Wege hinein: ein portables Windows-ZIP, einen Clone, den du mit uv run --locked gputaskman ausführst, oder pip in einer virtuellen Python-3.11+-Umgebung. Die Plattformen, wie die README sie beschreibt:

• Windows 10/11 64-Bit mit einer NVIDIA- oder AMD-GPU (x64- und ARM64-ZIPs auf der Releases-Seite);
• Linux und WSL mit einer NVIDIA-GPU (glibc 2.35+; WSL kann Windows-Host-Counter lesen);
• macOS auf Apple Silicon nur aus einem Source-Clone, kein portables Build.

Die Windows-ZIPs sind unsigniert. Lade sie nur von der Releases-Seite des offiziellen Repositories herunter, github.com/shanselman/gputaskman. Kopiere exakte Befehle aus der README: Das Projekt ist jung und Optionen können sich ändern.

Sobald es läuft, sind zwei Ansichten für dieses Problem wichtig:

1. Geräteansicht: VRAM-Nutzung, GPU-Aktivität, PCIe, Temperatur, Leistung, Takte und Verlaufsdiagramme. Gut für „Ist etwas in die Höhe geschossen?“
2. Prozessansicht: lokaler GPU-Speicher pro Prozess, GPU-zugänglicher System-RAM, Engine-Aktivität und die erkannte Runtime (CUDA, HIP, Vulkan, Direct3D, ggml, ONNX Runtime).

Finde in der Prozessansicht deinen Modellserver (bei Ollama dessen mitgelieferten Runner). Prüfe dann den Rest der Liste. Wenn ein Browser oder ein Spiel ein paar Gigabyte belegt, hast du deine Antwort gefunden, ohne das Modell anzufassen.

Gewichte, KV-Cache, Buffer: woher die Zahlen kommen#

Der Modell-Inspektor zeigt Architektur, Quantisierung und Buffergrößen, wo verfügbar. Ein Vorbehalt ist wichtig: Laut README stammen Gewichte, KV-Cache und Compute-Buffer aus den Ladelogs der Runtime, wenn kompatibles Logging aktiviert ist. Bei llama.cpp starte deinen eigenen llama-server mit Logging (--log-file server.log -lv 4; laut README ist Level 4 für Buffergrößen nötig). Bei Ollama nutzt gputaskman Ollamas server.log, falls verfügbar. Andernfalls sind es Schätzungen aus GGUF-Metadaten und Kontextgröße, unter Annahme einer Platzierung im llama.cpp-Stil. Eine KV-Abrechnung pro Modell innerhalb eines einzelnen Prozesses wird noch nicht unterstützt.

Lies also eine geschätzte Aufteilung als „ungefähr“ und eine logbasierte Aufteilung als „was die Runtime gemeldet hat“. Bei Ollama sagt die README, dass mitgelieferte Runner erkannt werden, GGUF-Blobs aus Ollamas Manifesten benannt werden und server.log genutzt wird, falls verfügbar. Die LM-Studio-Unterstützung ist teilweise: Modelle werden aus ihrem Ordner benannt und über die lokale API abgefragt, aber das wurde mit Fixture-Antworten getestet, nicht Ende zu Ende.

Du kannst außerdem zwei Snapshots als JSON speichern und sie mit dem Befehl diff vergleichen. Das ist ein sauberer Weg, um „Was hat sich geändert, als ich von 4K auf 16K Kontext gegangen bin?“ zu beantworten: einen Snapshot machen, die Einstellung ändern, neu laden, einen weiteren Snapshot machen.

Welchen Hebel du drehen solltest#

Die Aufteilung zu lesen gibt dir eine Entscheidung, nicht nur ein Bild.

Die Gewichte sind der große Anteil. Wechsle zu einer kleineren Quantisierung oder einem kleineren Modell. Das ist der einzige Hebel, der die Gewichte verkleinert. Wenn du die Speicherrechnung dahinter willst, siehe Kann ein 125B-Modell auf einer 16-GB-GPU laufen?

Der KV-Cache ist der große Anteil. Kürze den Kontext. In Ollama kannst du es direkt in der Sitzung versuchen:

ollama run <your-model>
>>> /set parameter num_ctx 8192

8192 ist nur ein Beispielwert; wähle, was deine Aufgabe wirklich braucht (Befehl laut Ollama-Dokumentation, geprüft am 5. November 2026).

Wenn du später bei der Prompt-Verarbeitung mit einem quantisierten Cache in llama.cpp seltsame Langsamkeit siehst, ist dieser Fix für den q5_1-KV-Cache der nächste Halt. Was ein Kontextfenster überhaupt fasst, liest du in Was ist ein Kontextfenster?

Ein anderer Prozess ist der große Anteil. Schließe ihn, oder lass ihn auf der integrierten GPU laufen. Am Modell muss sich nichts ändern.

Wenn es nicht funktioniert#

• Die Aufteilung sieht falsch aus. Prüfe, ob es eine Schätzung ist (keine kompatiblen Ladelogs). Bei llama.cpp starte deinen llama-server mit --log-file server.log -lv 4 und lade das Modell neu. Bei Ollama nutzt gputaskman server.log, falls vorhanden; ein Schätzungs-Label ist dort normal.
• LM Studio zeigt weniger Details. Die Unterstützung ist teilweise, wie oben beschrieben.
• Keine NVIDIA- oder AMD-GPU. Das Tool deckt nur lokale GPU-Workloads ab; reine CPU-, reine NPU- und Cloud-Workloads liegen außerhalb des Umfangs.
• macOS. Führe es aus einem Source-Clone aus; es gibt kein portables Build.

Wenn ein gehostetes Modell die einfachere Lösung ist#

Angenommen, du brauchst für eine Aufgabe einen langen Kontext, etwa zum Zusammenfassen eines großen Dokuments, und deine GPU fasst das Modell nur mit einem kurzen. Du kannst weiter tunen oder den VRAM aus dem Spiel nehmen. Für solche Aufgaben bietet CheapTokens DeepSeek-V4-Flash: 380K Kontext, bis zu 32.768 Ausgabe-Tokens pro Antwort, ein Preis zu jeder Tageszeit, über eine OpenAI-kompatible API. GLM-5.3-Flash hat einen 390K-Kontext und bis zu 8.192 Ausgabe-Tokens.

Der Aufruf ist das übliche OpenAI-Format (lege deinen Schlüssel in eine Umgebungsvariable):

curl https://api.cheaptokens.dev/v1/chat/completions \
  -H "Authorization: Bearer $CHEAPTOKENS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "deepseek-ai/DeepSeek-V4-Flash-0731", "messages": [{"role": "user", "content": "Summarize this document: ..."}]}'

Einrichtungsdetails stehen in der Dokumentation. Eine Faustregel zur Entscheidung: Wenn eine Aufgabe immer mehr Kontext oder ein größeres Modell braucht, als deine Karte fasst, und die Prozessansicht zeigt, dass dein VRAM bereits gut ausgelastet ist, schicke diese Aufgabe an die API und behalte die kleinen, schnellen Jobs lokal. DeepSeek lokal ausführen oder eine API nutzen? geht tiefer auf die Abwägung ein.

Angenommen, du fasst 100 große Dokumente zusammen, jedes mit 60.000 Eingabe-Tokens und 1.000 Ausgabe-Tokens (gut innerhalb des 380K-Fensters). Hier ist, was es heute kostet:

Mit diesen Zahlen sind $0.001 pro Dokument der aktuelle Preis für einen solchen Aufruf, und insgesamt, mit Eingabe und Ausgabe zusammengerechnet, liegt es unter OpenRouter.