Der Windows-Task-Manager sagt Ihnen, dass 15 GB Grafikspeicher belegt sind. Er sagt Ihnen nicht, wovon. Genau an dieser Stelle setzt gputaskman an, ein kleines Terminal-Programm, das Scott Hanselman Anfang November 2026 auf GitHub veröffentlicht hat. Es schlüsselt auf, welcher Prozess wie viel GPU-Speicher hält, und geht bei lokalen Sprachmodellen noch eine Ebene tiefer: Wie viel davon sind Modellgewichte, wie viel KV-Cache, wie viel Rechenpuffer?
Ich habe mir das Repository, die Commit-Historie und die Dokumentation genauer angesehen. In diesem Artikel erfahren Sie, was gputaskman misst und was es nur schätzt, wer hinter dem Projekt steckt, auf welchen Systemen es läuft und für wen sich der Einsatz lohnt. Und wo man besser die Finger davon lässt.
Wer hinter gputaskman steckt
Scott Hanselman ist in der Microsoft-Welt eine bekannte Figur. Auf seiner eigenen Website beschreibt er sich als VP und Member of Technical Staff bei Microsoft CoreAI und GitHub, viele Entwickler kennen ihn aus Podcasts, Konferenz-Keynotes und seinem seit über 20 Jahren laufenden Blog. Wichtig für die Einordnung: gputaskman liegt in seinem persönlichen GitHub-Konto, die MIT-Lizenz nennt ihn als Rechteinhaber, nicht Microsoft. Es ist also ein privates Open-Source-Projekt eines Microsoft-Managers, kein Microsoft-Produkt mit Support-Zusage.
Das Projekt ist jung. Der erste Commit stammt vom 2. November 2026, Version 0.3.0 wurde laut Git-Historie bereits am 3. November getaggt. Dazwischen kamen Beiträge von außen: Sameh Khamis hat die Unterstützung für Linux, WSL und macOS beigesteuert, ein weiterer Mitwirkender die AMD-Unterstützung, getestet nach eigener Commit-Nachricht auf einer Radeon 9060 XT. Auffällig ist ein Detail in der Historie: Mehrere Commits heißen sinngemäß „Review-Befunde von Claude und Codex behoben“, und das Repository enthält eine eigene Anleitung für KI-Agenten. Das Tool ist also mit KI-Unterstützung entstanden und wurde mit ihr geprüft. Das ist kein Makel, erklärt aber das Tempo.
Was gputaskman anzeigt: GPU-Speicher pro Prozess
Hanselman nennt sein Tool im README ein „htop“ für das Innere der Grafikkarte. Die Oberfläche läuft im Terminal und besteht aus drei Ebenen.
Die Geräteansicht zeigt den Zustand der Karte: VRAM-Belegung, GPU- und Speicheraktivität, PCIe-Verkehr, Temperatur, Leistungsaufnahme, Taktraten, Encoder- und Decoder-Last. Acht Verlaufsdiagramme laufen standardmäßig nebeneinander. Das kennen Sie im Prinzip aus dem Task-Manager oder aus GPU-Z.
Interessant wird die Prozessansicht. Sie listet pro Prozess den lokalen Grafikspeicher, den von der GPU genutzten Arbeitsspeicher (im Tool „Spill“ genannt), eine Schätzung für ausgelagerten Speicher („Paged“) und die Aktivität der einzelnen GPU-Engines. Dazu erkennt gputaskman, welche Laufzeitumgebung ein Prozess geladen hat: CUDA, HIP, Vulkan, Direct3D, ggml oder ONNX Runtime.
Die dritte Ebene ist der Modell-Inspektor. Er versucht herauszufinden, welches KI-Modell ein Prozess gerade hält, welche Architektur und Quantisierung es hat, wie viele Schichten, wie groß die Gewichte sind und was der KV-Cache kosten dürfte. Der KV-Cache ist der Zwischenspeicher, in dem ein Sprachmodell den bisherigen Gesprächskontext ablegt. Er wächst mit der eingestellten Kontextlänge und ist oft der Grund, warum ein Modell, das „eigentlich passt“, plötzlich nicht mehr in den VRAM passt.
Alles lässt sich auch ohne Oberfläche abrufen: --once liefert einen Text-Schnappschuss, --json eine maschinenlesbare Ausgabe. Mit gputaskman diff vergleichen Sie zwei JSON-Schnappschüsse, etwa vor und nach dem Laden eines Modells.
Der Screenshot aus dem Repository zeigt alle drei Ebenen auf einen Blick. Der ausgewählte Prozess llama-server.exe hält ein Qwen3-0.6B-Modell, und der Inspektor unten rechnet vor, dass bei 4.096 Token Kontext 448 MB auf den KV-Cache entfallen, bei 32.000 Token wären es laut Tool 3,5 GB.
Lokale LLMs überwachen: Ollama, llama.cpp und LM Studio
Der eigentliche Zweck des Tools sind lokal laufende KI-Modelle. Für llama.cpp und Ollama wurde die Erkennung laut README live erprobt. gputaskman liest dafür die Kopfdaten von GGUF-Dateien, dem gängigen Dateiformat für quantisierte Modelle, wertet Ladeprotokolle aus und fragt die lokalen Schnittstellen der Laufzeitumgebungen ab. Ollama-Modelle erscheinen dann mit ihrem gewohnten Namen, zum Beispiel qwen3:14b. LM Studio ist nur mit Testdaten geprüft, nicht im echten Betrieb.
Jede Modellzeile trägt eine Angabe, woher das Wissen stammt: Die lokale API meldet das Modell als geladen, Windows zeigt die Datei als in den Prozess eingeblendet, die Datei stand in der Befehlszeile, oder sie liegt nur im Installationsordner herum. Erst zwei Belege, darunter API oder Einblendung, gelten als bestätigt. Diese Ehrlichkeit zieht sich durch das gesamte Projekt, und ich halte sie für den eigentlichen Wert.
Ein Beispiel aus der Dokumentation zeigt, warum. Hanselman hat bei einem kleinen Gemma-Modell die Kontextlänge von 4096 auf 32768 erhöht. Die Rechnung aus den GGUF-Metadaten ergab 504 MB zusätzlichen KV-Cache, gemessen wurden nur 83 MB mehr. Gemma 3 nutzt eine Technik namens Sliding-Window-Attention, die Schätzung ist dort also nur eine Obergrenze. Das Tool verschweigt die Lücke nicht, es zeigt sie an. Umgekehrt stimmte bei Qwen3-0.6B die Schätzung für die Gewichte mit 604,15 MiB exakt mit dem Ladeprotokoll von llama.cpp überein.
Warum nicht einfach nvidia-smi?
Wer mit NVIDIA-Karten arbeitet, greift reflexartig zu nvidia-smi. Unter Windows hat das einen Haken, den das README offen benennt: Bei GeForce-Karten verwaltet Windows über das Treibermodell WDDM den Grafikspeicher, und die NVIDIA-Schnittstelle meldet den Speicher pro Prozess dann oft nur als „N/A“. Unter WSL listet nvidia-smi gar keine Prozesse. gputaskman nutzt deshalb die WDDM-GPU-Zähler von Windows für die Zuordnung zu Prozessen und NVML, die NVIDIA-Verwaltungsbibliothek, nur für die Werte der gesamten Karte.
Das hat einen Nebeneffekt, den viele unterschätzen. Der Desktop-Compositor dwm.exe erscheint im Task-Manager gern als großer Speicherfresser. Windows rechnet gemeinsam genutzte Oberflächen aber mehreren Prozessen gleichzeitig zu, wer die Zeilen addiert, zählt doppelt. In einer Messung aus der Dokumentation stand DWM nach dem alten Zähler bei rund 15,3 GiB, nach dem genaueren Zähler „Local Usage“ bei rund 1,4 GiB. Wer sich schon einmal über einen angeblich speicherhungrigen Desktop gewundert hat, findet hier die Erklärung.
Wählen Sie dwm.exe in der Liste aus, erklärt der Inspektor diesen Zusammenhang direkt im Programm. Das ist typisch für gputaskman: Neben jeder Zahl steht, wie belastbar sie ist.
Systemanforderungen und Plattformen
Die Plattformunterstützung ist innerhalb von zwei Tagen gewachsen, ältere Berichte sind deshalb schon überholt. Stand Version 0.3.0 gilt laut README:
- Windows 10 und 11 (64 Bit) mit NVIDIA- oder AMD-Grafikkarte und aktuellem WDDM-Treiber, als portable ZIP-Datei für x64 und ARM64 oder aus dem Quellcode
- Linux und WSL mit NVIDIA-Treiber, glibc 2.35 oder neuer, als portables Archiv
- macOS auf Apple Silicon, bisher nur aus dem Quellcode und mit eingeschränkten Werten, weil sich CPU und GPU dort den Speicher teilen
Intel-Grafik wird nicht als unterstützt genannt. Administratorrechte, CUDA Toolkit oder Visual Studio sind nicht nötig. Systeme mit mehreren Grafikkarten sind ausdrücklich noch nicht verlässlich abgedeckt. WinFuture verweist zudem auf einen Test von Neowin, bei dem Werte wie die GPU-Temperatur gelegentlich einfroren, statt sich zu aktualisieren. Den Neowin-Artikel selbst konnte ich nicht abrufen.
Für wen sich gputaskman lohnt
Klar im Vorteil sind Sie, wenn Sie lokal Sprachmodelle betreiben, etwa mit Ollama oder llama.cpp, und wissen wollen, warum ein Modell nicht vollständig auf die Grafikkarte passt oder plötzlich langsam wird. Die Spalte „Spill“ zeigt, wie viel GPU-Speicher in den normalen Arbeitsspeicher ausweicht. Das README warnt allerdings, dass ein hoher Wert noch kein Beweis für einen Überlauf ist. Zusammen mit einer fast vollen Karte ist er aber ein deutlicher Hinweis.
Ebenso nützlich ist das Tool für Entwickler, die PyTorch-Jobs, Bild- oder Spracherkennung auf eigener Hardware laufen lassen, und für alle, die in Containern oder unter WSL arbeiten. Gerade dort fehlen sonst brauchbare Werte pro Prozess. Wer ein Unternehmen oder eine Behörde berät, die aus Datenschutzgründen ein Sprachmodell auf eigener Hardware statt in der Cloud betreiben will, bekommt mit gputaskman ein schnelles Werkzeug zur Größenplanung: Was belegt das Modell bei welcher Kontextlänge tatsächlich?
Für Gamer, die nur wissen wollen, wie heiß die Karte wird, bringt gputaskman wenig, was GPU-Z oder der Task-Manager nicht auch zeigen. Texturen oder Shader eines Spiels zerlegt es ausdrücklich nicht, dafür verweist das README auf PIX oder Nsight.
Was Sie vor dem Einsatz wissen sollten
Fairerweise: Hanselman selbst nennt das Projekt frühe, experimentelle Software. Die Gerätezähler sind Messungen, die Modellzuordnungen und Aufschlüsselungen sind Schätzungen. Die portablen Windows-Builds sind nicht signiert, es gibt lediglich eine SHA-256-Prüfsumme. In Umgebungen mit Anwendungssteuerung wie AppLocker oder WDAC braucht es je nach Regelwerk eine eigene Freigabe, und das ist auch gut so.
Zwei weitere Punkte gehören in jede Bewertung. Erstens sendet gputaskman GET-Anfragen an lokal offene Ports, um Ollama, llama-server oder LM Studio zu finden. Das bleibt auf dem eigenen Rechner, kann aber in einer Umgebung mit Endpoint-Überwachung auffallen. Zweitens enthalten die Inspektor- und JSON-Ausgaben Pfade, Befehlszeilen, Modellnamen und Ports. Das README rät selbst, diese vor dem Weitergeben zu prüfen. Wer einen Schnappschuss in ein öffentliches Issue kopiert, sollte vorher hinschauen.
Fazit
gputaskman beantwortet eine Frage, an der der Task-Manager scheitert: Wer belegt den Grafikspeicher, und bei KI-Modellen: womit genau? Das Tool ist jung, teilweise geschätzt und auf einige Kombinationen aus Grafikkarte und Laufzeitumgebung beschränkt. Es sagt das aber an jeder Stelle selbst, und genau diese Trennung zwischen Messung und Vermutung fehlt vielen Monitoring-Tools.
Wenn Sie lokale Modelle betreiben, laden Sie die portable Version von der Release-Seite, prüfen Sie die Prüfsumme und machen Sie einen --json-Schnappschuss vor und nach dem Laden Ihres Modells. Danach wissen Sie mehr über Ihre Grafikkarte als nach einem Jahr Task-Manager.
Quellen:
- Scott Hanselman: gputaskman – README, Lizenz und Commit-Historie (GitHub, Stand 6. November 2026)
- Scott Hanselman: gputaskman – Releases (GitHub, v0.3.0 vom 3. November 2026)
- Scott Hanselman: About / Kontakt (hanselman.com, abgerufen 6. November 2026)
- WinFuture: Bericht zu gputaskman (6. November 2026)