Speicher und Bandbreite
Die Rechnung, die vor jedem Hardwarekauf steht: wie viel Speicher ein Modell braucht, was der KV-Cache kostet und wo die tatsächliche Grenze liegt.
Die Idee
Ein Modell muss vollständig in den Speicher der Grafikkarte passen. Passt es nicht, wird ausgelagert, und der Zugriff über den Systembus ist rund fünfzigmal langsamer. Die praktische Folge ist nicht „etwas langsamer", sondern „unbenutzbar".
Die Faustformel
| Format | Bytes je Parameter | 7 Mrd. | 13 Mrd. | 70 Mrd. |
|---|---|---|---|---|
| float32 | 4 | 28 GB | 52 GB | 280 GB |
| float16 | 2 | 14 GB | 26 GB | 140 GB |
| int8 | 1 | 7 GB | 13 GB | 70 GB |
| int4 | 0,5 | 3,5 GB | 6,5 GB | 35 GB |
Auf diese Werte kommen 10 bis 20 Prozent Zuschlag für die Laufzeitumgebung und der Kontextspeicher.
Der KV-Cache
Er ist der Posten, der in Planungen regelmäßig fehlt.
Durchgerechnet für ein Modell mit 32 Schichten, h_kv = 4096, float16:
| Kontext | 1 Anfrage | 8 Anfragen | 32 Anfragen |
|---|---|---|---|
| 4.096 Token | 2,1 GB | 17,2 GB | 68,7 GB |
| 32.768 Token | 17,2 GB | 137 GB | 550 GB |
Bei 32.000 Token Kontext ist der Cache bereits größer als das 7-Milliarden-Modell
selbst. Genau deshalb setzen moderne Architekturen auf gruppierte Abfragen: Wenn
sich acht Abfrageköpfe einen Schlüssel-Wert-Kopf teilen, sinkt h_kv um den
Faktor acht und der Cache entsprechend.
- Speicher für das Modell, den Cache und einen Sicherheitspuffer getrennt rechnen.
- Die maximale Kontextlänge im Betrieb begrenzen, sonst bestimmt ein einzelner Nutzer die Kapazität.
- Bei knappem Speicher zuerst den Cache quantisieren, das kostet weniger Qualität als Gewichte in int4.
Das Roofline-Modell
Für eine Karte mit P_max = 1.000 TFLOP/s und B = 3.000 GB/s liegt der
Knickpunkt bei I = 333 FLOPs je Byte. Typische Werte:
| Operation | Arithmetische Intensität | Begrenzt durch |
|---|---|---|
| Token einzeln erzeugen | ~2 | Bandbreite |
| Erzeugung mit Batch 64 | ~128 | Bandbreite |
| Erzeugung mit Batch 512 | ~1.000 | Rechenleistung |
| Prompt verarbeiten (prefill) | ~500 | Rechenleistung |
| Training | ~2.000 | Rechenleistung |
Die Tabelle erklärt eine oft überraschende Beobachtung: Das Verarbeiten eines langen Prompts läuft mit voller Rechenleistung, während die anschließende Erzeugung Token für Token die Karte kaum auslastet. Beide Phasen haben unterschiedliche Engpässe und werden in modernen Systemen deshalb getrennt eingeplant.
Vollständige Rechnung für eine Auslegung
Vorgabe: Modell mit 13 Milliarden Parametern, 8.000 Token Kontext, 16
gleichzeitige Anfragen, float16 für Gewichte und Cache.
| Posten | Rechnung | Speicher |
|---|---|---|
| Gewichte | 13e9 × 2 B | 26,0 GB |
| KV-Cache | 2 × 40 × 8.000 × 5.120 × 2 B × 16 | 104,9 GB |
| Aktivierungen und Puffer | ~10 % | 13,1 GB |
| Summe | 144,0 GB |
Das passt nicht auf eine Karte mit 80 GB. Drei Auswege, nach Wirkung geordnet:
- Gruppierte Abfragen im Modell, Faktor 8 auf den Cache: von 104,9 auf 13,1 GB.
- Cache in int8, Faktor 2: nochmals halbiert.
- Kontext auf 4.000 Token begrenzen, Faktor 2 auf den Cache.
- Gewichte in int8, Faktor 2: von 26,0 auf 13,0 GB.
Mit den ersten beiden Maßnahmen liegt die Summe bei rund 46 GB und passt komfortabel. Diese Reihenfolge ist typisch: der Cache ist fast immer der größere Hebel als die Gewichte.
Passende Kurse und Quellen
FlashAttention
Aufmerksamkeit berechnen, ohne die quadratische Matrix je vollständig abzulegen. Die Voraussetzung für lange Kontexte.
Für alle, die lange Kontexte betreiben und wissen müssen, woran der Speicher hängt.
vLLM
Server für hohen Durchsatz mit fortlaufender Stapelverarbeitung und Seitenspeicher für den Zwischenspeicher. Der Grund, warum Eigenbetrieb bei Volumen wirtschaftlich wird.
Für den Eigenbetrieb bei Volumen; der Grund, warum er sich überhaupt rechnen kann.