Beschreiben, was im Speicher bleibt
Während einer autoregressiven Generierung können die Schlüssel und Werte bereits verarbeiteter Tokens für die folgenden Schritte aufbewahrt werden. Dieser Cache gehört zu den Attention-Schichten. Sein Volumen hängt daher vom Modell und vom aufbewahrten Verlauf ab, nicht nur von der Anzahl der Parameter. Der Kontext einer Unterhaltung umfasst auch die Anweisungen, die vorherigen Nachrichten und die von der Anwendung hinzugefügten Dokumente.
Ihre erste Entscheidung ist operativer Natur: Wie viele Sequenzen müssen aktiv bleiben, bis zu welcher Länge? Eine Warteschlange von zwanzig Anfragen, von denen zwei gleichzeitig ausgeführt werden, bedeutet nicht zwangsläufig zwanzig residente Caches. Erfassen Sie die tatsächliche Annahme der Anfragen und die gegebenenfalls durch die Generierung erzeugten zusätzlichen Sequenzen.
Erstellen Sie ein Datenblatt mit der Revision des Modells, den Attention-Schichten, den KV-Köpfen, der Dimension der Schlüssel und Werte, ihrem dtype und der Cache-Strategie. Zählen Sie die Tokens nach dem Tokenizer und dem Unterhaltungs-Template. Ein Zeichenlimit beschreibt diese Allokation nicht.
Technische Quellen: Hugging Face — Funktionsweise und Form der Caches pro Schicht
Die KV-Köpfe verwenden, insbesondere mit GQA
Die Anzahl der Query-Köpfe Q und die der KV-Köpfe können sich unterscheiden. Bei klassischer Multi-Head-Attention stimmen sie überein. Bei MQA wird ein einziger KV-Kopf geteilt; GQA gruppiert mehrere Q-Köpfe um einen KV-Kopf. Lesen Sie num_key_value_heads in der Konfiguration, wenn dieses Feld existiert, und prüfen Sie seine Bedeutung für die Architektur.
Beispielsweise bilden vierzig Q-Heads und acht KV-Heads fünf Q-Heads pro KV-Gruppe. Die Formel für den gespeicherten Cache verwendet acht, nicht vierzig. Dieses Verhältnis beschreibt nicht den gesamten Speicher der Attention: Operationen oder Konvertierungen können Temporaries erzeugen.
Ändern Sie diese Zahl nicht einfach, um den Speicherbedarf eines bereits trainierten Modells zu senken. Das Attention-Schema ist Teil seiner Architektur. Zwei Modelle mit unterschiedlichen Head-Anzahlen werden durch eine Kapazitätsrechnung nicht zu äquivalenten Varianten; ihre Qualität muss separat bewertet werden.
Technische Quellen: Hugging Face — LlamaConfig-Felder und Unterscheidung von MHA, MQA, GQA · PyTorch — Q/K/V-Dimensionen und Einschränkungen der GQA-Attention
Die Formel und ihre Einheiten aufstellen
Im einheitlichen Fall ist L die Anzahl der Layer, Hkv die Anzahl der KV-Heads, D ihre Dimension, T die Anzahl der pro Sequenz gespeicherten Positionen, B die Anzahl der Sequenzen und q die Anzahl der Bytes pro Wert. Der Faktor zwei zählt K und V. Diese Näherung setzt Keys und Values mit gleicher Dimension und gleichem Format voraus, ohne Kompression oder Prefix-Sharing.
Rechnen Sie nur das Endergebnis um: ein GiB entspricht 1 073 741 824 Bytes; ein dezimales GB entspricht 1 000 000 000 Bytes. Behalten Sie die Bytes in Ihrer Aufstellung bei, damit eine Rundung oder ein Einheitenwechsel keinen Unterschied verdeckt.
Ersetzen Sie bei unterschiedlichen Längen ohne Padding B × T durch die Summe der tatsächlich gespeicherten Positionen. Bilden Sie bei heterogenen Layern eine Summe Layer für Layer. Ein dichtes Speicherschema mit Padding, eine Block-Allokation oder eine statische Reservierung erfordert, die zugewiesenen Plätze zu zählen, die die nutzbaren Tokens übersteigen können.
Technische Quellen: Hugging Face — Dimensionen der Cache-Tensoren · NIST — dezimale Einheiten und binäre Präfixe
Durchgerechnetes Beispiel: sechs Sequenzen, ohne GPU-Messung
Nehmen wir eine fiktive Architektur mit vierzig Layern, acht KV-Heads und einer Dimension von 128 an. Angenommen wird ein einheitlicher Cache mit zwei Bytes pro Wert. Jede Sequenz erhält höchstens 3 072 Eingabe-Tokens plus eine Reservierung für 1 024 zusätzliche Tokens, also eine Obergrenze von 4 096 Positionen. Dies sind didaktische Annahmen, nicht die belegte Konfiguration eines Modells.
Die berechneten Kosten pro Position und Sequenz betragen 2 × 40 × 8 × 128 × 2 = 163 840 Bytes. Eine Sequenz mit 4 096 Positionen entspricht dann 671 088 640 Bytes, also 0,625 GiB. Sechs Sequenzen ergeben 4 026 531 840 Bytes, also 3,75 GiB allein für den Cache.
Eine Verdopplung der gespeicherten Länge verdoppelt diesen Posten in dieser Formel. Ersetzt man acht KV-Heads durch vierzig, vervielfacht er sich bei sonst unveränderten Annahmen um den Faktor fünf. Diese Verhältnisse sagen keine Beschleunigung, keinen Qualitätsverlust und keine Kompatibilität eines realen Modells voraus.
| Sequenzen B | Positionen T | KV-Heads | Berechnete Bytes | GiB |
|---|---|---|---|---|
| 1 | 4 096 | 8 | 671 088 640 | 0,625 |
| 6 | 4 096 | 8 | 4 026 531 840 | 3,75 |
| 6 | 8 192 | 8 | 8 053 063 680 | 7,5 |
| 6 | 4 096 | 40 | 20 132 659 200 | 18,75 |
Das Budget an die Cache-Strategie anpassen
Ein dynamischer Cache wächst mit den gespeicherten Positionen. Ein statischer Cache reserviert eine maximale Kapazität: dimensionieren Sie diese Reservierung, nicht nur die kurze Anfrage, die beim Start beobachtet wird. Bei Sliding-Window-Attention können einige Layer ihren Verlauf begrenzen; Layer mit vollständiger Attention erfordern eine separate Berechnung.
Die Quantisierung des Caches und seine Auslagerung auf die CPU sind weitere Strategien, die vom Modell und der Software abhängen. Sie verändern die Anforderungen an Speicher, Transfer oder Berechnung. Die Quantisierung der Gewichte beweist nicht, dass der Cache dasselbe Format hat.
Notieren Sie die Cache-Klasse und ihre expliziten Parameter. Prüfen Sie außerdem die Freigabe der Plätze nach dem Ende oder dem Abbruch einer Anfrage. Bei einer Last, die kurze und lange Sequenzen mischt, kann eine einheitliche maximale Reservierung stärker ins Gewicht fallen als die Summe der nutzbaren Inhalte allein.
Technische Quellen: Hugging Face — dynamische, statische, quantisierte und ausgelagerte Caches
Eine repräsentative Last schrittweise überprüfen
Erstellen Sie drei Fälle: übliche Eingabe, erwartete lange Eingabe und maximal zulässige Anzahl gleichzeitiger Anfragen. Legen Sie Modell, Tokenizer, Template, Generierungsgrenze und Endregel fest. Variieren Sie jeweils nur eine Dimension; eine verkürzte Antwort oder ein abgeschnittenes Dokument verändert die erbrachte Arbeit.
Messen Sie Laden, erste Verarbeitung der Eingabe und Generierung getrennt. Synchronisieren Sie das Device um die gemessenen Phasen herum, behalten Sie die anfänglichen Speicherstände und die Spitzenwerte bei. Die Speichermethode erklärt, warum allocated und reserved sich nicht addieren und warum die Differenz ihrer Maxima nicht den Cache isoliert.
Ihre Prüfung muss zu einer getesteten Obergrenze und akzeptablen Ausgaben führen: IDs der abgeschlossenen Anfragen, Fehler, erzeugte Länge und Qualitätskriterium. Ein Lauf, der mit einer kurzen Eingabe durchläuft, bestätigt nicht die maximale Nebenläufigkeit. Ein Speicherfehler vor dem Ende stellt keine Messung des Bedarfs eines vollständigen Laufs dar.
Technische Quellen: PyTorch — Synchronisierung der Arbeit auf dem gewählten Device · PyTorch — Umfang der Speicherzähler
Fehler ausschließen, die die Wahl verfälschen
Verwandeln Sie den berechneten Cache nicht in die gesamte GPU-Kapazität. Ergänzen Sie eine Analyse der Gewichte, der temporären Aktivierungen, der aufbewahrten Ausgaben und der Software. Teilen Sie dieses Volumen auch nicht automatisch durch die Anzahl der Karten: Die Platzierung der Schichten oder Köpfe muss tatsächlich konfiguriert und auf jedem Device überprüft werden.
Das Notebook IteraGPU Lab ist eine Instrumentierungsübung auf einem kleinen dichten Netzwerk ohne Attention. Es hilft, Speicherphasen zu lesen; sein Parameter context bestätigt diese KV-Berechnung nicht. Verwenden Sie das Lastdatenblatt und den Inferenzordner, um den Test Ihres eigenen Modells vorzubereiten.
Vergleichen Sie die Kapazitäten der Angebote erst, nachdem Sie das arithmetische Volumen, das tatsächlich beobachtete Maximum und die noch nicht getesteten Fälle unterschieden haben. Das Mietpaket organisiert Ihr Arbeitsfenster; es garantiert weder eine Kontextlänge noch eine Generierungsrate.
- Q-Köpfe und KV-Köpfe verwechseln: die Konfiguration der Architektur heranziehen.
- Nur den Prompt budgetieren: die Generierung und die tatsächliche Reservierung einbeziehen.
- „4-Bit-Gewichte“ als „4-Bit-Cache“ lesen: beide Formate erfassen.
- Die Nebenläufigkeit vergessen: die tatsächlich residenten Sequenzen zählen.
- Einen gemeinsamen Speicher zwischen Karten versprechen: die tatsächliche Platzierung überprüfen.
Praktische Fragen
Kann ich den KV-Cache allein aus der Anzahl der Parameter ableiten?
Nein. Es braucht außerdem die Architektur der Attention-Schichten, die KV-Köpfe, ihre Dimensionen, das Cache-Format, die beibehaltenen Positionen und die residenten Sequenzen. Zwei Modelle ähnlicher Größe können unterschiedliche KV-Budgets erfordern.
Verbraucht ein statischer Cache nur die Länge meiner Anfrage?
Seine reservierte Kapazität muss dimensioniert werden. Eine kurze Anfrage erlaubt es nicht, diese maximale Zuweisung abzuleiten. Erfassen Sie die Cache-Parameter und messen Sie die tatsächlich erstellte Konfiguration.
Reicht das Ergebnis der Formel aus, um eine Karte zu wählen?
Es schätzt ausschließlich den Cache anhand angegebener Annahmen. Die Wahl muss auch die übrigen Speicherposten, die Software-Kompatibilität und einen vollständigen Test mit repräsentativem Kontext, repräsentativer Nebenläufigkeit und repräsentativer Qualität berücksichtigen.