Gelernter Speicherbedarf vergisst sich selbst
- Matt
Whipyard lässt sich den Speicherbedarf eines Modells nicht angeben, sondern misst ihn: Es merkt sich die höchsten Werte der letzten zehn Ladungen, schlägt zehn Prozent drauf und plant damit. Damit eine geänderte Konfiguration nicht mit alten Werten rechnet, hängen die Messungen an einem Hash der gesamten Konfiguration.
Genau das ging schief. Ich hatte beim Musikserver acestep.cpp nur eine Kleinigkeit an der Protokollbeschreibung geändert, nichts, was den Speicher betrifft. Der Hash war trotzdem neu, die Messungen weg. Und acestep.cpp lädt seine Modelle erst bei Bedarf: Der erste Schritt braucht 3,4 GB, die eigentliche Synthese 8,2 GB. Die ersten neuen Messungen sahen nur den ersten Schritt, also plante Whipyard mit 3,4 GB, lud etwas anderes daneben, und die Synthese stürzte mit Out of Memory ab. Zweimal. Ein abgestürzter Lauf liefert keine Messung, der zu niedrige Wert korrigierte sich also nicht von selbst.
Jetzt bleibt ein konfigurierter Wert die Untergrenze, bis zehn neue Messungen vorliegen. Für solche Kandidaten lässt er sich auch dauerhaft festnageln.
Der Haken am Messen: Es sieht nur, was bisher passiert ist. Ein Backend, dessen Speicherbedarf von der Art der Anfrage abhängt, braucht eigentlich Messungen pro Route. Das steht noch aus. Den Hintergrund zu Whipyard gibt es im Beitrag zum Türsteher für die Grafikkarte. Gemessen wird der Grafikspeicher pro Prozess über nvidia-smi.