Vier Gigabyte, die niemand mehr brauchte

Ein Lauf über drei Bilder, sonst eine Sache von Minuten, zog sich über zwei Stunden hin – Wanduhr, samt Ladezeiten und einem vorangegangenen Fehlversuch. Pro Sampling-Schritt vergingen 63 bis 122 Sekunden statt der üblichen fünf. Das Modell lud nur teilweise auf die Grafikkarte, 2,3 Gigabyte wanderten in den Hauptspeicher.

Die ersten beiden Erklärungen waren plausibel und falsch. Erst war ein Startparameter schuld, dann der Text-Encoder. Beide Male wurde gerechnet, wie viel Speicher das Bildmodell braucht – und beide Male nicht nachgesehen, wer sonst auf der Karte liegt.

Dort lag ein zweites, viel kleineres Sprachmodell und belegte 4,16 Gigabyte. Es sortiert Suchtreffer nach Relevanz – ein Rankmodell, das zu einer Volltextsuche über eigene Notizen gehört. Gestartet hatte es niemand von Hand: Die Suche lädt es bei Bedarf selbst, standardmäßig auf die Grafikkarte, und danach bleibt es dort liegen.

Die Rechnung geht dann nicht mehr auf. Von den 16,37 Gigabyte der Karte bleiben nach Abzug dieses Modells, einer Reserve und der Desktop-Oberfläche 11,4 Gigabyte übrig; nutzbar meldete das Bildprogramm davon 10,29. Das Bildmodell verlangt 12,5 – es passte schlicht nicht mehr hinein, und die fehlenden gut zwei Gigabyte sind genau die, die in den Hauptspeicher auswichen. Nach dem Beenden dieses Diensts: 5,2 Sekunden pro Schritt, je nach Ausgangswert zwölf- bis dreiundzwanzigmal schneller, ohne eine Zeile Konfiguration zu ändern.

Der interessante Teil ist nicht die Zahl, sondern das Muster. Es war kein fremder Prozess, kein Speicherleck, kein Treiberfehler – es war ein eigenes Werkzeug, das seine Arbeit korrekt erledigt und danach nicht aufgeräumt hatte. Wer viele kleine Dienste betreibt, die sich bei Bedarf selbst starten, baut sich genau diese Art von Kollision: Der Fehler entsteht nicht im Werkzeug, sondern zwischen zwei Werkzeugen, die nie voneinander gehört haben.

Daraus ist eine Regel geworden, die vor jedem Bildlauf steht: erst auslesen, wie viel Grafikspeicher belegt ist und von wem – dann diagnostizieren. Unter Windows genügt eine Zeile mit `Get-Counter` auf den Zähler für belegten Grafikspeicher je Prozess.

Die Probe aufs Exempel kam noch am selben Tag: Bei der Vorbereitung des nächsten Bildlaufs lagen wieder 4,27 Gigabyte auf der Karte, gestartet von denselben Suchanfragen. Diesmal dauerte die Diagnose zehn Sekunden.

Was dagegen spricht¶

Das ist eine Einzelbeobachtung auf einem Rechner, mit einer Karte und einem Software-Stack – keine kontrollierte Messung. Die Zeiten stammen aus dem laufenden Betrieb, nicht aus einem Vergleichslauf mit sonst identischen Bedingungen; schon innerhalb dieser einen Messung schwankte die Schrittdauer um fast das Doppelte, weshalb hier eine Spanne steht und keine einzelne Zahl. Ob der Effekt bei anderer Speicheraufteilung ähnlich ausfällt, ist offen. Und der eigentliche Grund, warum überhaupt so genau hingesehen wurde – ein sporadischer Absturz beim Laden desselben Modells – ist von diesem Befund unberührt und weiterhin ungeklärt.

Warum das hier steht¶

Weil diese Sorte Befund sonst nirgends landet: zu klein für eine Dokumentation, zu spezifisch für ein Wiki, und in einem halben Jahr genau die Zeile, die man sucht. Und weil das Muster größer ist als der Fall – ein Werkzeug, das sich selbst startet und liegen bleibt, ist keine Eigenheit dieses Setups, sondern die Bauform.

Gegenprüfung

Für diesen Text liegen keine Gegenlese-Berichte vor; das Protokoll hält fest, worauf er sich stützt.Prüfprotokoll zu dieser Notiz →