GPU-Speicherbedarf für selbst gehostete LLM-Inferenz abschätzen

Warum die Modellgröße allein den GPU-Speicherbedarf nicht bestimmt

Die Parameterzahl eines Modells liefert eine hilfreiche erste Schätzung, ergibt aber noch kein vollständiges GPU-Speicherbudget. Für die Inferenz wird außerdem Speicher für den Key-Value-Cache (KV-Cache) und Aktivierungen benötigt. Auch Laufzeitumgebung, Modellarchitektur und Serving-Konfiguration können den tatsächlichen Verbrauch beeinflussen. Eine Übersicht über diese Speicherkomponenten bietet der [LLM Inference Memory Estimation Tool](https://github.com/david-xinyuwei/llm-memory-estimator).

Ein Modell, das beim Laden in den Speicher passt, kann bei eingehenden Anfragen trotzdem den verfügbaren Speicher übersteigen. Längere Sequenzen und mehr gleichzeitig aktive Anfragen erhöhen den Speicherbedarf des KV-Caches. Auch andere GPU-Workloads und der Laufzeit-Overhead beanspruchen Speicher.

Betrachten Sie jede Berechnung als Planungswert und nicht als Garantie dafür, dass eine bestimmte Hardware ausreicht. Das Ergebnis hängt vom konkreten Modell, der Inferenz-Laufzeit und der Serving-Konfiguration ab.

• Schätzen Sie den Speicherbedarf für Gewichte und KV-Cache als separate Komponenten.
• Beschreiben Sie die Workload einschließlich Sequenzlängen und Gleichzeitigkeit, bevor Sie die Schätzwerte mit dem verfügbaren GPU-Speicher vergleichen.
• Prüfen Sie die geplante Konfiguration in der vorgesehenen Deployment-Umgebung, statt sich allein auf einen Modellnamen oder eine Parameterzahl zu verlassen.

Speicherbedarf für Modellgewichte einschließlich Quantisierung abschätzen

Für eine erste Schätzung multiplizieren Sie die Anzahl der Modellparameter mit der Anzahl der Bytes pro Parameter. Als grobe Zuordnung gelten häufig: FP32 mit 4 Byte, FP16 mit 2 Byte, INT8 mit 1 Byte und INT4 mit 0,5 Byte pro Parameter. Diese Näherung und die Zuordnung der Datentypen beschreibt der [LLM Inference Memory Estimation Tool](https://github.com/david-xinyuwei/llm-memory-estimator).

Ein veranschaulichendes Beispiel: Bei einem Modell mit 8 Milliarden Parametern läge der idealisierte Schätzwert für die Gewichte bei 16 GB mit 2 Byte pro Parameter, 8 GB mit 1 Byte oder 4 GB mit 0,5 Byte. Das sind dezimale Rechenwerte nur für die Gewichte; KV-Cache, Aktivierungen und Laufzeitbedarf sind darin nicht enthalten.

Durch Quantisierung lässt sich der Speicherbedarf für Gewichte senken, indem weniger Bits pro Parameter verwendet werden. Diese Schätzung beschreibt das bereitgestellte Modell jedoch nicht vollständig. Prüfen Sie das tatsächliche Modellformat und die Laufzeitumgebung und berücksichtigen Sie bei der Entscheidung für eine quantisierte Konfiguration mögliche Kompromisse bei der Präzision. Eine allgemeine Einführung in diesen Zielkonflikt bietet das [Khronos-Tutorial zu Hardware- und VRAM-Budgetierung](https://github.khronos.org/Vulkan-Site/tutorial/latest/AI_Assisted_Vulkan/03_model_selection_specialization/03_hardware_vram.html).

• Notieren Sie die Parameterzahl sowie das vorgesehene Präzisions- oder Quantisierungsformat.
• Berechnen Sie den Speicherbedarf für Gewichte mit: Parameterzahl × Byte pro Parameter.
• Achten Sie auf einheitliche Einheiten: Dezimale GB und binäre GiB sind unterschiedliche Einheiten, und GPU-Tools können Speicher unterschiedlich ausweisen.
• Behandeln Sie das Ergebnis nicht als gesamten Speicherbedarf für das Bereitstellen von Anfragen.

Kontextlänge und KV-Cache berücksichtigen

Während der Inferenz speichert der KV-Cache Schlüssel- und Wertdaten für Tokens in aktiven Sequenzen. Sein Speicherbedarf hängt von der Batchgröße, der Sequenzlänge, der Anzahl der Layer, der Anzahl der KV-Heads, der Head-Dimension und der Bytezahl pro Cache-Element ab.

Eine nützliche Schätzung lautet: KV-Cache in Byte = 2 × Batchgröße × Sequenzlänge × Anzahl der Layer × Anzahl der KV-Heads × Head-Dimension × Byte pro Cache-Element. Der Faktor 2 steht für Schlüssel und Werte. Diese Formel und ihre Variablen sind im [LLM Inference Memory Estimation Tool](https://github.com/david-xinyuwei/llm-memory-estimator) beschrieben.

Ein ausdrücklich hypothetisches Beispiel: Angenommen, eine Konfiguration hat 32 Layer, 8 KV-Heads, eine Head-Dimension von 128, 2 Byte pro Cache-Element, eine Sequenz mit 4.096 Tokens und eine Batchgröße von 1. Die Formel ergibt 536.870.912 Byte beziehungsweise etwa 0,5 GiB. Bei einer Batchgröße von 4 und unveränderten übrigen Annahmen beträgt der Schätzwert etwa 2 GiB. Diese Werte veranschaulichen lediglich die Berechnung und beschreiben kein bestimmtes Modell.

Verwenden Sie für die Planung die Sequenzlänge, die die Laufzeitumgebung gleichzeitig vorhalten kann. Dazu gehören sowohl Prompt-Tokens als auch generierte Tokens. Ein langes Kontextlimit bedeutet nicht, dass jede Anfrage das gesamte Limit ausschöpft. Anfragen mit maximaler Länge können jedoch den Spitzenbedarf des Caches bestimmen.

• Ermitteln Sie Layer-Anzahl, KV-Head-Anzahl und Head-Dimension des Modells anhand einer zuverlässigen Modelldokumentation oder Modellkonfiguration.
• Verwenden Sie den Cache-Datentyp und das Serving-Verhalten, die der vorgesehenen Laufzeitumgebung entsprechen.
• Schätzen Sie sowohl typische Sequenzlängen als auch die längsten Sequenzen ab, die Sie bereitstellen möchten.
• Verwendet das Modell Grouped-Query Attention, setzen Sie für die Berechnung die Anzahl der KV-Heads ein, statt die Anzahl der Query-Heads anzunehmen.

Gleichzeitige Anfragen, Batching und gemeinsam genutzte GPU-Workloads einbeziehen

Die Formel für den KV-Cache skaliert sowohl mit der Batchgröße als auch mit der Sequenzlänge. Deshalb können mehrere aktive Anfragen erheblich mehr Cache erfordern als eine einzelne Anfrage, insbesondere bei langen Kontexten.

Gleichzeitigkeit und Batchgröße hängen zusammen, sollten aber nicht ohne Prüfung der Serving-Konfiguration gleichgesetzt werden. Ein Server kann Anfragen zu Batches zusammenfassen oder aktive Sequenzen auf andere Weise verwalten. Richten Sie Ihre Schätzung nach dem erwarteten Verhalten der tatsächlichen Laufzeitumgebung aus.

Berücksichtigen Sie außerdem alle anderen Prozesse, die die GPU nutzen. Ein weiterer Prozess oder ein anderes Modell kann Speicher belegen, der der Inferenz sonst zur Verfügung stünde. Speicherfragmentierung und Entscheidungen zur Laufzeitumgebung können ebenfalls beeinflussen, ob eine Konfiguration, die auf dem Papier passt, in der Praxis funktioniert.

• Notieren Sie die erwartete durchschnittliche und maximale Zahl aktiver Anfragen, nicht nur das tägliche Anfragevolumen.
• Berücksichtigen Sie die Sequenzlängen dieser aktiven Anfragen.
• Prüfen Sie, ob Batching aktiviert ist und wie die Serving-Laufzeitumgebung Anfragen mit unterschiedlichen Sequenzlängen verarbeitet.
• Listen Sie weitere GPU-Prozesse und Workloads auf, die gleichzeitig mit der Inferenz laufen können.

Laufzeit- und Hardware-Overhead einbeziehen, ohne einen festen Zuschlag anzunehmen

Es gibt keinen universell verlässlichen festen Overhead, der zu jeder Schätzung addiert werden kann. Der tatsächliche Speicherverbrauch kann je nach Inferenz-Engine, Laufzeitoptimierungen, Batching-Strategie, Modellarchitektur und Speicherfragmentierung variieren. Auch Faktoren des Frameworks und des jeweiligen Modells spielen eine Rolle. Diese Abhängigkeiten werden im [llm-resource-planner](https://pypi.org/project/llm-resource-planner/) und im [LLM Inference Memory Estimation Tool](https://github.com/david-xinyuwei/llm-memory-estimator) als Einschränkungen der Schätzungen beschrieben.

Statt einen beliebigen Prozentsatz aufzuschlagen und das Ergebnis als endgültig zu betrachten, sollten Sie den Overhead als ausdrücklich noch zu messende Größe behandeln. Beginnen Sie mit den Berechnungen für Gewichte und Cache und vergleichen Sie diese anschließend mit dem beobachteten Verbrauch unter der vorgesehenen Laufzeitumgebung und Last.

Prüfen Sie den nutzbaren GPU-Speicher in der Umgebung, in der der Dienst laufen soll. Die nominelle Kapazität zeigt nicht, wie viel Speicher nach den Belegungen durch andere Workloads und die Laufzeitumgebung tatsächlich verfügbar bleibt.

• Dokumentieren Sie die für die Schätzung verwendete Inferenz-Engine, Modellkonfiguration und Serving-Einstellungen.
• Ermitteln Sie, welche GPU-Workloads das Gerät mitnutzen und ob sie gleichzeitig laufen.
• Stellen Sie eine nicht getestete Sicherheitsreserve nicht als allgemeingültige Anforderung dar.
• Legen Sie anhand von Testergebnissen eine für Ihre eigene Workload geeignete Betriebsreserve fest.

Vor der Wahl der Infrastruktur ein Workload-Profil erstellen

Eine sinnvolle Schätzung beginnt mit einer Beschreibung der Workload und nicht nur mit einem Modellnamen. Erfassen Sie die für die Cache-Berechnung benötigten Architekturdetails, die für die Gewichte verwendete Präzision sowie die Sequenzlängen und Gleichzeitigkeit, die Ihr Dienst bewältigen muss.

Unterscheiden Sie zwischen typischer und maximaler Nutzung. Wenn Ihr System unterschiedliche Anfragen verarbeitet, kann eine einzelne durchschnittliche Sequenzlänge den Speicherbedarf langer Prompts oder gleichzeitig laufender, langer Anfragen verschleiern. Testen Sie ein repräsentatives Muster und zusätzlich den größten plausiblen Fall, den Sie unterstützen müssen.

• Modell: Parameterzahl, für die KV-Cache-Formel erforderliche Architekturdetails sowie Präzision oder Quantisierung der Gewichte.
• Prompt: typische und maximale Prompt-Länge in Tokens.
• Ausgabe: erwartete und maximale Länge der generierten Tokens.
• Sequenz: Gesamtlänge aus Prompt und Ausgabe, die die Laufzeitumgebung möglicherweise vorhalten muss.
• Serving: erwartete typische und maximale Anzahl aktiver Anfragen, Batching-Verhalten und relevante Laufzeiteinstellungen.
• Umgebung: für den Prozess verfügbarer GPU-Speicher und alle weiteren Workloads, die die GPU mitnutzen.

Die Schätzung mit einem repräsentativen Test überprüfen

Führen Sie das tatsächliche Modell mit der vorgesehenen Inferenz-Laufzeitumgebung und Serving-Konfiguration aus, bevor Sie sich auf die Schätzung verlassen. Beginnen Sie mit einer normalen Workload und testen Sie anschließend die längeren Sequenzen und höhere Gleichzeitigkeit, die den erwarteten Spitzenbedarf abbilden.

Beobachten Sie den GPU-Speicher während des Modellladens und bei aktiven Anfragen. Dokumentieren Sie die Konfiguration zusammen mit den Messwerten, damit die Ergebnisse auch nach Änderungen am Modell, an Kontextlimits, Quantisierung, Laufzeitumgebung oder Batching hilfreich bleiben. Der [LLM Inference Memory Estimation Tool](https://github.com/david-xinyuwei/llm-memory-estimator) empfiehlt ebenfalls, tatsächliche Modelle zu testen und den Speicherverbrauch im Einsatz zu überwachen.

Eine einzelne erfolgreiche Anfrage belegt nicht, dass das System die Spitzenlast bewältigen kann. Wiederholen Sie den Test mit repräsentativen gleichzeitigen Anfragen und untersuchen Sie unerwarteten Speicherzuwachs oder Fehler, bevor Sie die Konfiguration als einsatzbereit betrachten.

• Testen Sie dasselbe Modellformat, dieselbe Präzision, Laufzeitumgebung und dieselben Einstellungen wie für das Deployment vorgesehen.
• Verwenden Sie realistische Prompt- und Ausgabelängen und testen Sie anschließend die vorgesehene maximale Gleichzeitigkeit.
• Überwachen Sie den tatsächlichen Speicherverbrauch während des Ladens und des Betriebs, nicht nur beim Start.
• Wiederholen Sie die Messungen nach wesentlichen Änderungen am Modell oder an der Serving-Konfiguration.

Wenn die Workload den verfügbaren GPU-Speicher übersteigt

Ermitteln Sie zuerst, welcher Teil der Workload den zusätzlichen Speicherbedarf verursacht. Sind lange Sequenzen der Grund, lässt sich der Bedarf des KV-Caches durch eine kürzere Kontextlänge oder durch Begrenzung ungewöhnlich langer Anfragen senken. Überwiegt der Speicherbedarf der Modellgewichte, kann Quantisierung den Gewichtsspeicher reduzieren. Dabei muss der Präzisionskompromiss für das Modell und die Aufgabe geprüft werden.

Weitere Möglichkeiten sind, die maximale Gleichzeitigkeit zu reduzieren oder die Serving-Konfiguration zu ändern. Jede dieser Entscheidungen beeinflusst das Verhalten des Dienstes. Prüfen Sie deshalb, ob die resultierenden Kontextlimits, die Verarbeitung von Anfragen und die Ausgabequalität den Anforderungen der Anwendung entsprechen.

Reichen diese Änderungen für die Anforderungen der Workload nicht aus, sollten Sie die GPU-Kapazität oder das Deployment-Design neu bewerten. Gehen Sie nicht ohne Tests davon aus, dass Auslagerung, eine bestimmte Laufzeiteinstellung oder eine bestimmte GPU das Problem lösen wird: Die hier angegebenen Schätzungen begründen keine allgemeingültige Hardwareempfehlung.

Wiederholen Sie nach jeder Änderung den repräsentativen Lasttest. Eine Konfiguration, die bei reduzierter Gleichzeitigkeit oder kürzerer Kontextlänge in den Speicher passt, muss weiterhin die tatsächlichen Anforderungen der Anwendung erfüllen.

• Reduzieren Sie die Kontextlänge, wenn die Workload kürzere Prompts oder Ausgaben zulässt.
• Prüfen Sie die Quantisierung der Gewichte und bewerten Sie den damit verbundenen Präzisionskompromiss für Ihren Anwendungsfall.
• Reduzieren Sie die maximale Zahl gleichzeitiger Anfragen oder passen Sie das Batching an und testen Sie die Auswirkungen auf den Dienst.
• Passt die erforderliche Workload weiterhin nicht in den Speicher, vergleichen Sie Deployment-Optionen anhand gemessener Ergebnisse statt anhand einer Schätzung nur für die Gewichte.