Der On-Prem-Server, dessen VRAM bereits im zweiten Monat ausgereizt war

Wie es präsentiert wird

Ein selbst gehostetes Modell wird auf Hardware bereitgestellt, die auf Basis einer einfachen Berechnung dimensioniert wurde: Parameteranzahl mal Bytes pro Parameter, mit noch etwas Reserve. Es funktioniert im Test. Zwei Monate später beginnt es unter Last Fehler zurückzugeben, fällt dann auf ein viel kleineres Modell zurück und bearbeitet schließlich nur noch eine Anfrage auf einmal.

Die Karte hat sich nicht geändert. Was sich geändert hat, ist alles andere, das um den gleichen Speicher konkurriert.

Was den Speicher tatsächlich belegt

Gewichte sind der Begriff, auf den jeder plant, und auf einem beschäftigten Server oft nicht der größte Verbraucher.

Der Schlüssel-Wert-Cache. Dieser wächst mit den gleichzeitigen Anfragen und mit der Kontextlänge und ist der Begriff, der ein festes Modell in eine variable Fußabdruckgröße verwandelt. Lange Gespräche und große abgerufene Kontexte multiplizieren ihn. Er ist der übliche Übeltäter und die übliche Auslassung.

Aktivierungsspeicher und Laufzeitoverhead. Framework-Allokationen, Graphoptimierungen und Speicherpool sind nicht kostenlos und variieren je nach Ausführungsmodus, Batch-Größe und Anzahl der gleichzeitigen Sequenzen im Flug.

Fragmentierung. Die Allokation und Freigabe variabel großer Blöcke über Wochen hinweg hinterlässt Lücken, die nicht wiederverwendet werden können. Ein Server, der am ersten Tag noch bequem lief, kann am sechzigsten Tag mit unverändertem Lastprofil nicht mehr eine identische Anfrage allokieren.

Alles andere auf dem Host. Ein Einbettungsmodell, ein Reranker, ein Vision-Encoder, ein Überwachungsagent, eine experimentelle Bereitstellung. Jedes ist isoliert gesehen klein und die Menge davon ist es nicht.

Ohne Überraschung dimensionieren

• Dimensionieren Sie für den Spitzenwert, den Sie tatsächlich rechtfertigen können, nicht für den Durchschnitt. Der Fehlermodus ist ein Spitzenwert, und Spitzenwerte sind es, die Benutzer merken.
• Begrenzen Sie die Kontextlänge auf dem Server und nicht durch Konvention. Ein unbeschränkter Kontext ist ein unbeschränkter Cache, und ein Client, der bei jedem Schritt die Historie neu sendet, wird die Grenze für Sie finden.
• Quantifizieren Sie absichtlich und nicht standardmäßig. Es ist ein echter Hebel auf Hardware, die Sie besitzen, aber messen Sie die Qualität auf Ihrem eigenen Bewertungssatz vor und nach der Quantifizierung — der Handel ist nicht einheitlich über Aufgaben hinweg.
• Reservieren Sie Überkopplung für die nicht-Modell-Workloads und schreiben Sie die Reservierung auf, damit der für das nächste Quartal geplante Reranker einen Platz zum Leben hat.
• Verfolgen Sie den Speicher über die Zeit hinweg, nicht nur beim Start. Ein langsamer Aufwärtstrend ist Fragmentierung oder ein Leck, und er wird durch einen Ausfall entdeckt, wenn niemand hinsieht.
• Definieren Sie einen abgespeckten Modus im Voraus — weniger gleichzeitige Anfragen, ein kürzerer Kontext, ein kleineres Modell — und binden Sie ihn an einen expliziten Schwellenwert anstelle von Improvisationen während eines Zwischenfalls.

Die Berechnung, die niemand aufschreibt

Das nützliche Artefakt ist nicht die anfängliche Dimensionierungstabelle, sondern die Aufzeichnung davon, wofür die Überkopplung ausgegeben wurde. Hardware, die mit Reserve bereitgestellt wurde, hat aufgehört, Reserve zu haben, und zwar Schritt für Schritt, und jede einzelne Entscheidung sieht vernünftig aus, wenn sie getroffen wird. Die Aufbewahrung der Reservierungsliste neben der Bereitstellung verwandelt eine Reihe von kleinen Genehmigungen in ein sichtbares Budget.