Passt dieses Modell auf deine GPU? So schätzt du den VRAM-Bedarf vor der Hardwarewahl ein

Es geht nicht nur darum, wie viele Parameter das Modell hat

Die Parameterzahl eines Modells kann eine erste Orientierung bieten. Sie beantwortet aber nicht die praktische Frage, ob das Modell mit der gewünschten Konfiguration auf einer bestimmten GPU funktioniert. Dafür musst du das konkrete Modell, das Format seiner Gewichte, die Runtime, den zu verarbeitenden Kontext, die Zahl gleichzeitiger Anfragen und den Speicherbedarf des restlichen Systems berücksichtigen.

„Passt“ ist daher keine isolierte Eigenschaft des Modells. Es kann beim Laden zunächst ausreichend Speicher vorhanden sein, der bei längerem Kontext jedoch nicht mehr reicht. Eine Konfiguration kann für eine einzelne Anfrage funktionieren, aber bei mehreren parallelen Anfragen an ihre Grenzen stoßen. Oder das Modell startet, weil ein Teil der Arbeit im RAM ausgeführt wird, obwohl nicht das gesamte Modell auf der GPU liegt. Auch ein anderer Runtime oder andere Optionen können zu einem anderen Ergebnis führen.

Ziel dieses Leitfadens ist es, eine erste Schätzung zu erstellen und sie anschließend mit einem kontrollierten Test zu überprüfen. Die Schätzung hilft dabei, offensichtlich ungeeignete Konfigurationen auszuschließen und zu erkennen, was gemessen werden muss. Sie ersetzt keinen Test mit der tatsächlichen Hardware, dem vorgesehenen Runtime und der echten Arbeitslast. Aus einer VRAM-Schätzung lassen sich außerdem weder Geschwindigkeit noch Antwortqualität oder langfristige Stabilität ableiten.

Welche Speicherbereiche während der Ausführung belegt werden

Eine brauchbare Schätzung betrachtet mindestens vier Komponenten getrennt: die Modellgewichte, den KV-Cache, temporäre Rechenpuffer sowie den Platz, den Runtime, Betriebssystem und andere Prozesse benötigen. Diese Einteilung ist konzeptionell. Je nach Runtime, Optionen und Hardware können Speicherzuweisungen unterschiedlich erfasst werden. In einem Überwachungswerkzeug erscheinen die Komponenten nicht zwingend als getrennte Kategorien.

Die Gewichte sind die Modelldaten, die der Runtime für die Inferenz lädt. Die Dateigröße kann einen Hinweis auf ihren Umfang geben, entspricht aber nicht automatisch dem gesamten Speicherbedarf. Format und Quantisierung beeinflussen die Größe der Gewichte; zugleich kann das Laden zusätzlichen Arbeitsspeicher und Strukturen des Runtime erfordern. Die Dateigröße sollte deshalb nicht ohne Messung der gewählten Konfiguration in einen verfügbaren VRAM-Wert umgerechnet werden.

Der KV-Cache speichert Informationen zu bereits verarbeiteten Tokens, die für die weitere Generierung benötigt werden. Sein Speicherbedarf hängt von der gerade ausgeführten Arbeitslast und Eigenschaften des Modells ab – nicht nur von dessen Namen oder Parameterzahl. Vor der Schätzung müssen daher der geplante Kontext und die Zahl paralleler Anfragen feststehen. Auch die Architektur und der konfigurierte Cache-Typ können das Ergebnis beeinflussen.

Rechenpuffer sind temporäre Speicherbereiche, die der Runtime während bestimmter Operationen zur Verfügung stehen. Ihr Umfang kann von der Implementierung und den aktiven Optionen abhängen. Runtime und System benötigen außerdem eigenen Spielraum. Eine GPU kann zudem Speicher für die Anzeige oder andere Prozesse verwenden. Behandle den nominellen Speicher der Karte daher nicht so, als stünde er vollständig dem Modell zur Verfügung.

Erhebe die Daten, bevor du rechnest

Bestimme zuerst das konkrete Modellartefakt. Der kommerzielle Name allein reicht nicht: Wichtig sind auch die Datei oder das Format, das du laden willst, und die zugehörige Konfiguration. Aus einer Modellkonfiguration können Architekturmerkmale hervorgehen, die der Name nicht verrät – beispielsweise die Zahl der Layer sowie bestimmte Dimensionen und Attention-Heads. Solche Angaben helfen, die Architektur zu beschreiben, reichen für sich genommen aber nicht aus, um den endgültigen Speicherbedarf zu berechnen. Entscheidend ist auch, wie der Runtime Cache und Puffer darstellt und zuweist.

Lege danach den Runtime und seine Optionen fest. Halte die getestete Version oder Konfiguration, den angeforderten Kontext, die geplante Parallelität und die Wahl des Cache-Typs beziehungsweise seines Speicherorts fest. Wenn der Runtime es erlaubt, einzelne Layer auf der GPU auszuführen, Teile auf die CPU auszulagern oder die Arbeit auf mehrere Karten zu verteilen, notiere auch diese Entscheidungen. Eine Schätzung ohne diese Bedingungen vermischt unterschiedliche Szenarien.

Notiere schließlich den Ausgangszustand des Systems: den gesamten und den verfügbaren GPU-Speicher, Prozesse, die ihn bereits belegen, und ob die Karte ausschließlich für Inferenz oder auch für andere Aufgaben verwendet wird. GPU-Verwaltungswerkzeuge können gesamten, reservierten, belegten und freien Speicher anzeigen. Das sind Beobachtungen des Gerätezustands, aber keine vollständige Erklärung dafür, welche Modellkomponente welchen Speicherbereich belegt.

So erstellst du eine erste Schätzung

Als erste Näherung kannst du den erforderlichen VRAM als Summe aus den auf der GPU befindlichen Gewichten, dem dort untergebrachten KV-Cache, den Puffern und dem Speicherbedarf des Runtime betrachten. Hinzu kommt ein Puffer für Schwankungen der Arbeitslast und andere Nutzungen der Karte. Das ist keine exakte Formel und keine Zahl, die sich mit allgemeinen Angaben zuverlässig ausfüllen lässt: Kategorien und Umfang hängen von Implementierung und Konfiguration ab.

Trenne bekannte Werte von Näherungen. Die Dateigröße ist beobachtbar, beweist aber weder, welcher Anteil davon tatsächlich auf der GPU resident ist, noch wie hoch der maximale Speicherbedarf sein wird. Kontext und gewünschte Parallelität sind Anforderungen, die du selbst festlegen musst. Informationen zu Architektur und Cache-Strategie erfordern Angaben zum Modell und zum Runtime. Puffer und benötigte Reserve müssen oft auf dem System gemessen werden, auf dem das Modell laufen soll.

Wenn eine wichtige Variable unbekannt ist, solltest du diese Unsicherheit nicht hinter einer einzigen Zahl verstecken. Erstelle stattdessen Szenarien: zum Beispiel eine Konfiguration mit moderatem Kontext und eine anspruchsvollere, jeweils mit der Parallelität, die der Dienst benötigt. Diese Bezeichnungen garantieren keinen bestimmten Speicherbedarf. Sie sorgen dafür, dass der Test die vorgesehenen Einsatzbedingungen abdeckt und nicht nur den einfachsten Fall.

Die Dokumentation eines Runtime kann erklären, welche Optionen er anbietet und welche Grenzen er angibt. Eine ausgewiesene Kapazität oder ein Konfigurationswert beweist jedoch nicht, dass das konkrete Gerät die Arbeitslast im Betrieb bewältigt. Nutze die Dokumentation, um den Test zu planen, und überprüfe die Konfiguration anhand der gemessenen Nutzung.

Der KV-Cache verändert sich mit Kontext und Arbeitslast

Der KV-Cache verdient besondere Aufmerksamkeit, weil sein Umfang mit der aktiven Arbeit zusammenhängt. Bei einem längeren Kontext kann mehr Information gespeichert werden müssen, um die Generierung fortzusetzen. Mehrere gleichzeitige Anfragen können mehrere aktive Sequenzen aufrechterhalten. Eine genaue Zahl lässt sich nicht allein aus dem Modellnamen oder der Parameterzahl ableiten.

Auch die Architektur spielt eine Rolle. Für eine fundiertere Schätzung brauchst du Attribute aus der Modellkonfiguration und Angaben dazu, wie der Runtime Attention und Cache behandelt. Selbst wenn diese Informationen vorliegen, kann der gemessene Wert vom gewählten Cache-Typ, der Speicherzuweisung und den Runtime-Optionen abhängen. Eine allgemeine Faustregel ohne diese Angaben kann höchstens qualitativ orientieren; sie garantiert nicht, dass eine bestimmte Konfiguration passt.

Runtimes können unterschiedliche Strategien anbieten, etwa dynamische, statische, quantisierte oder auf die CPU ausgelagerte Caches. Ein Wechsel der Strategie kann die Speicherverteilung und die Ausführungsbedingungen verändern. Vergleiche zwei Schätzungen deshalb nicht so, als wären sie gleichwertig, wenn sie unterschiedliche Strategien, Runtimes oder Optionen verwenden.

Eine GPU, Auslagerung in den RAM oder mehrere Karten

Eine Ausführung kann das Modell vollständig auf einer GPU verwenden, nur einen Teil seiner Layer dort platzieren, einen Teil des Cache auf die CPU auslagern oder das Modell auf mehrere GPUs verteilen. Solche Optionen können Konfigurationen ermöglichen, die nicht vollständig auf eine einzelne Karte passen. Sie beweisen aber nicht, dass das ganze Modell im VRAM liegt. Ebenso lässt sich daraus allein nicht ableiten, welche Leistung die Ausführung erreichen wird.

Prüfe den Ausführungsmodus in den Runtime-Optionen und den dazugehörigen Protokollen. Wenn sich die Zahl der GPU-Layer oder die Aufteilung auf mehrere Karten festlegen lässt, notiere die tatsächlich verwendeten Werte. Ist eine Auslagerung auf die CPU oder eine Cache-Strategie im CPU-Speicher aktiv, bildet der GPU-Speicher allein nicht mehr den gesamten Speicherbedarf der Ausführung ab. Unterscheide zwischen „die Anwendung ist gestartet“ und „die Ausführung erfüllt die festgelegten Anforderungen an Speicherort und Arbeitslast“.

Bei mehreren GPUs reicht auch die Summe ihrer nominellen Speicherkapazitäten nicht aus, um zu wissen, wie das Modell verteilt wird. Die Aufteilung hängt von den Fähigkeiten des Runtime und der gewählten Konfiguration ab. Prüfe jedes Gerät und die tatsächliche Zuweisung. Gehe nicht davon aus, dass der gesamte zusammengerechnete Speicher für jede beliebige Verteilung zur Verfügung steht.

Überprüfe die Schätzung mit einem kontrollierten Test

Der Test sollte das Szenario nachbilden, das du tatsächlich einsetzen willst. Lege Modell, Format, Runtime, Kontext, Parallelität sowie Cache- und Auslagerungsoptionen fest. Protokolliere den anfänglichen Speicherzustand und alle anderen Prozesse, die sich die GPU teilen. Wenn du mehrere Optionen gleichzeitig änderst, lässt sich später nur schwer feststellen, welche Änderung das Ergebnis verursacht hat.

Lade das Modell und erfasse den belegten und freien Speicher. Führe anschließend eine Anfrage mit der vorgesehenen Konfiguration aus. Erhöhe Kontext oder Parallelität schrittweise und jeweils nur eine Variable. Notiere, wann ein Fehler auftritt, eine Auslagerung aktiviert wird oder die beobachtete Belegung nahe an die Grenze kommt. Behandle einen einzelnen Messwert nicht als verlässlichen Maximalwert: Beobachte den Speicher während der Ausführung, denn der Bedarf kann sich beim Laden von dem während der Inferenz unterscheiden.

Nutze die Runtime-Protokolle, um die Verteilung zwischen GPU und CPU sowie die tatsächlich angewendeten Optionen zu überprüfen. Vergleiche die Beobachtung mit einem GPU-Werkzeug, das gesamten, belegten, reservierten und freien Speicher ausweist. Diese Messung beschreibt den Zustand des Geräts; sie trennt Gewichte, Cache und Puffer nicht unbedingt voneinander. Wiederhole den Test, um Schwankungen auf demselben System zu erkennen, und notiere die genauen Bedingungen.

Lege vorher fest, was als bestandener Test gilt: Der vorgesehene Kontext muss abgeschlossen, die erforderliche Parallelität unterstützt und eine nicht eingeplante Auslagerung vermieden werden. Wenn das System Speicher für andere Prozesse freihalten muss, gehört diese Reserve ebenfalls zu den Anforderungen. Ein fehlerfreier Test kann für den vorgesehenen Einsatz dennoch unzureichend sein, wenn danach nicht genug Spielraum bleibt.

Häufige Fehler und Grenzen der Schätzung

Ein häufiger Fehler ist, die Dateigröße mit dem gesamten Speicherbedarf gleichzusetzen. Sie enthält nicht zwangsläufig den Bedarf für Cache und Puffer, den Runtime oder den Speicher, den das System bereits belegt. Ein weiterer Fehler besteht darin, die nominelle GPU-Kapazität als verfügbaren Speicher anzunehmen, ohne den freien Platz im tatsächlichen Betriebszustand des Computers zu messen.

Ebenso leicht ist es, nur den Start zu testen und daraus abzuleiten, dass auch ein großer Kontext oder mehrere Anfragen funktionieren. Der anfängliche Ladevorgang und die anhaltende Arbeitslast sind unterschiedliche Testphasen. Sobald du Kontext, Parallelität, Cache-Typ, Runtime oder Aufteilung zwischen GPU und CPU veränderst, prüfst du eine andere Konfiguration.

Übertrage außerdem Messwerte nicht unkritisch von einem Runtime auf einen anderen. Werkzeuge können Speicher unterschiedlich verwalten und ihre Messwerte verschieden darstellen. Beobachtete Werte beschreiben die getestete Hardware und die verwendeten Optionen. Sie garantieren weder dasselbe Ergebnis auf einem anderen System noch einen dauerhaft stabilen Betrieb. Der Test sagt auch nichts über die Antwortqualität oder darüber aus, ob die Geschwindigkeit für einen bestimmten Anwendungsfall ausreicht.

Abschließende Kriterien für die Hardwarewahl oder Wiederverwendung

Bevor du eine GPU kaufst, solltest du eine repräsentative Arbeitslast bestimmen und prüfen, ob der verfügbare Speicher die Komponenten aufnehmen kann, die du darauf behalten willst – einschließlich des Spielraums, den das System benötigt. Übersteigt die Schätzung die nutzbare Kapazität bereits deutlich, musst du keine Scheingenauigkeit erzeugen: Diese Kombination erfordert geänderte Anforderungen, eine andere Verteilung oder andere Hardware. Liegt sie nahe an der Grenze, ist ein Test auf dem konkreten Gerät besonders wichtig.

Wenn du eine vorhandene GPU weiterverwenden möchtest, miss ihren tatsächlichen Zustand und prüfe, wer den Speicher mitnutzt. Behandle die Gesamtkapazität nicht als freien Speicher. Wenn du eine teilweise Ausführung im RAM oder eine Verteilung auf mehrere Karten akzeptierst, halte diese Entscheidung als Teil der Konfiguration fest, statt sie als unsichtbares Detail zu behandeln. Vergleiche Hardwareoptionen anhand derselben Arbeitslast und derselben Kriterien.

Weitere Orientierung zu lokalen Modellen findest du im Leitfaden zu lokalen Modellen, im Modellvergleich und im Entdecken-Bereich. Auch beim Prüfen einer Option gilt: Bestimme die genaue Konfiguration und überprüfe die Bedingungen, die für deinen Anwendungsfall wichtig sind. Das nützliche Ergebnis ist keine universelle VRAM-Zahl, sondern ein reproduzierbarer Befund für ein bestimmtes Modell, einen bestimmten Runtime, eine bestimmte Hardware und eine klar definierte Arbeitslast.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.