Speicher- und Rechenlast von Transformer-Schichten in produktiven großen Sprachmodellen

Stellen Sie sich vor, Sie haben ein großes Sprachmodell wie Llama 3.1 70B auf einem Server laufen. Es antwortet auf Ihre Fragen, schreibt Texte, analysiert Dokumente - alles fast in Echtzeit. Doch hinter dieser scheinbaren Leichtigkeit verbirgt sich eine riesige Last: Speicher und Rechenleistung. Jede einzelne Transformer-Schicht in diesem Modell frisst Gigabyte an RAM und teraflops an Rechenkapazität. Und wenn Sie das nicht verstehen, scheitert Ihre Implementierung - nicht an der Technik, sondern an der Planung.

Was genau frisst den Speicher in einem Transformer?

In einem großen Sprachmodell gibt es zwei Hauptverbraucher von Speicher: die Modellgewichte und der Key-Value (KV)-Cache. Die Gewichte sind die gelernten Parameter des Modells - die Zahlen, die sagen, wie sich Eingaben durch die Schichten bewegen. Ein 7 Milliarden Parameter starkes Modell wie Llama 2 7B in 16-Bit-Precision (FP16) benötigt etwa 14 GB Speicher. Das klingt viel, ist aber nur die halbe Wahrheit.

Der echte Überraschungskandidat ist der KV-Cache. Er speichert die Schlüssel- und Wert-Vektoren, die bei jeder vorherigen Token-Berechnung entstanden sind. Bei einer Sequenzlänge von 4.096 Tokens und einem 7B-Modell mit 32 Schichten, 8 KV-Köpfen und einem Kopf-Dimension von 128 verbraucht dieser Cache allein etwa 2 GB. Klingt überschaubar? Doch bei 32.000 Tokens - typisch für lange Dokumente oder Chatverläufe - steigt dieser Wert auf über 16 GB. Bei einem 70B-Modell wird der KV-Cache sogar größer als die Gewichte selbst. Das ist kein theoretisches Problem. In der Praxis sehen Unternehmen, dass sie nicht genug GPU-Speicher haben, weil der Cache die gesamte Bandbreite verschlingt.

Rechenlast: Warum Ihre GPU nur 30 % auslastet

Die Rechenlast folgt einer einfachen, aber brutalen Regel: O(dn²/c). Dabei steht n für die Sequenzlänge, d für die Embedding-Dimension und c für die Anzahl der parallelen Kerne. Das bedeutet: Wenn Sie die Länge des Textes verdoppeln, vervierfacht sich der Rechenaufwand. Bei 128.000 Tokens - wie sie heute in manchen Anwendungen verwendet werden - ist die Rechenlast astronomisch hoch.

Aber hier liegt der Haken: GPUs sind dafür ausgelegt, viele Berechnungen gleichzeitig durchzuführen. Bei kleinen Batch-Größen - wie sie typisch für interaktive Chatbots sind - bleibt die GPU fast die ganze Zeit untätig. Sie wartet auf Daten aus dem Speicher, während die Recheneinheiten leer stehen. NVIDIA hat gemessen, dass bei Transformer-Attention-Schichten nur 30 bis 35 % der theoretischen Rechenleistung genutzt werden. Der Rest ist Wartezeit. Das ist kein Fehler Ihrer Hardware - das ist die Architektur der Transformer.

Memory-bound vs. compute-bound: Die entscheidende Frage

Jede erfolgreiche Optimierung beginnt mit einer einfachen Frage: Ist mein System speicherbegrenzt oder rechenbegrenzt? Das ist kein akademischer Unterschied - es bestimmt, wohin Sie Ihre Ressourcen stecken.

Wenn Sie lange Kontexte verarbeiten - etwa 16.000+ Tokens - ist Ihr System fast immer speicherbegrenzt. Der KV-Cache wächst linear mit der Sequenzlänge und der Batch-Größe. Hier bringt es nichts, mehr Rechenleistung zu kaufen. Sie brauchen einen kleineren Cache. Techniken wie FlashAttention-2 reduzieren den Speicherbedarf von quadratisch auf linear, indem sie die Berechnungen in kleine Blöcke aufteilen. So können Sie mit einem 80 GB A100 128.000 Tokens verarbeiten - ohne FlashAttention wäre das unmöglich.

Aber wenn Sie kurze Prompts mit komplexen Antworten verarbeiten - etwa Code-Generierung oder logisches Denken - dann ist Ihr System rechenbegrenzt. Die Zeit wird nicht durch den Speicher verbraucht, sondern durch die Berechnung der Attention-Matrix. Hier hilft kein KV-Cache-Compression. Hier brauchen Sie schnellere Berechnungen. Snowflake hat gezeigt: Eine 50 %ige Reduktion der Prefill-Rechenlast bringt eine 52 %ige Steigerung der Durchsatzrate - bei einem 70B-Modell. Das ist kein kleiner Gewinn. Das ist der Unterschied zwischen einem nutzbaren System und einem, das ständig wartet.

Optimierungstechniken: Was wirklich funktioniert

Es gibt viele Versprechen - aber nur wenige Techniken, die in der Praxis standhalten.

• INT8-Quantisierung: Reduziert den Speicherbedarf der Gewichte um die Hälfte. Ein 70B-Modell fällt von 140 GB auf 70 GB. Aber Vorsicht: Bei INT4 sinkt die Genauigkeit auf dem MMLU-Benchmark um 8,7 %. Für rechtliche oder medizinische Anwendungen ist das oft unzulässig.
• Tensor-Parallelismus: Teilt die Attention-Köpfe auf mehrere GPUs auf. Perfekt für rechenbegrenzte Workloads. Aber es bringt 15-25 % Overhead durch Kommunikation - wenn Sie es falsch konfigurieren, verlieren Sie mehr, als Sie gewinnen.
• Pipeline-Parallelismus: Teilt die Schichten auf. Gut für speicherbegrenzte Systeme. Aber bei 70B-Modellen kann der Overhead bis zu 22 % betragen - wie ein Nutzer auf Reddit berichtet, der 45 Minuten brauchte, um den KV-Cache auf 8 A100s unterzubringen.
• FlashAttention-2 und -3: Die einzige Technik, die die Speicheranforderungen der Attention von O(n²) auf O(n) senkt. FlashAttention-3 (September 2024) bringt weitere 28 % Einsparungen durch Kernel-Fusion. Wenn Sie längere Kontexte brauchen, ist das Ihr Schlüssel.
• SwiftKV: Eine neue Methode, die die Prefill-Rechenlast halbiert, indem sie KV-Vektoren zwischen verschiedenen Eingaben wiederverwendet. 50 % weniger Rechenzeit - das ist ein Game-Changer für Code-Generierung und Analyse.

Was schiefgeht - und warum

Die meisten Projekte scheitern nicht an der Technik. Sie scheitern an falschen Annahmen.

Ein Team optimiert den KV-Cache, weil sie glauben, Speicher sei das Problem. Doch ihre Anwendung verarbeitet nur 512-Tokens-Prompts - und braucht 3 Sekunden, um eine Antwort zu generieren. Der echte Engpass ist die Prefill-Rechenlast. Sie haben 10.000 Dollar in Cache-Kompression investiert - und nichts gewonnen.

Ein anderes Unternehmen setzt INT4-Quantisierung ein, um Kosten zu senken. Doch ihr Modell verarbeitet juristische Dokumente. Die Genauigkeit sinkt um 6 %. Die Kunden reklamieren. Die Compliance-Abteilung stoppt den Einsatz.

Die häufigsten Fehler:

• Unterschätzen, wie schnell der KV-Cache wächst - besonders bei großen Modellen und hohen Batch-Größen.
• Ignorieren, dass die Rechenlast bei kurzen Prompts nicht vom Speicher, sondern von der Attention-Berechnung dominiert wird.
• Verwenden von Optimierungen ohne Profiling. Sie wissen nicht, wo der Engpass ist - also optimieren Sie zufällig.
• Übersehen, dass einige Techniken (wie KV-Cache-Compression) kleine Genauigkeitsverluste verursachen - die in sensiblen Anwendungen untragbar sind.

Wie Sie anfangen - Schritt für Schritt

Sie brauchen kein PhD, um das zu meistern. Aber Sie brauchen eine klare Strategie.

1. Profiling: Nutzen Sie NVIDIA Nsight Systems. Messen Sie, wie viel Zeit die GPU mit Warten verbringt - und wie viel mit Rechnen. Wenn das Verhältnis 1:3 ist, sind Sie rechenbegrenzt. Wenn das Speicherlimit erreicht ist, bevor Sie rechnen können, sind Sie speicherbegrenzt.
2. Wählen Sie die richtige Optimierung: Bei langen Kontexten → FlashAttention + INT8. Bei kurzen, komplexen Prompts → SwiftKV + Tensorparallelismus.
3. Testen Sie mit echten Daten: Nutzen Sie Ihre eigenen Prompts. Nicht die Beispieltexte aus der Dokumentation. Ein Modell, das bei „Was ist die Hauptstadt von Frankreich?“ gut funktioniert, kann bei einem 10.000-Wörter-Vertrag versagen.
4. Überwachen Sie die Genauigkeit: Führen Sie regelmäßig Benchmarks auf MMLU, HumanEval oder Ihrem spezifischen Datensatz durch. Ein 5 %iger Genauigkeitsverlust klingt klein - aber in der Praxis ist das ein verlorener Kunde.

Was kommt als Nächstes?

Die Hardware entwickelt sich. NVIDIA hat mit dem Blackwell B200 eine GPU mit 192 GB HBM3e-Speicher vorgestellt - speziell für KV-Cache-Lasten. Samsung arbeitet an Hybrid-Speichern mit GDDR7. Und Meta plant Llama 4 mit speziell optimierten Attention-Mustern für diese Chips.

Aber die größte Veränderung kommt nicht von der Hardware. Sie kommt von der Architektur. Die Forschung zeigt: Die Zukunft liegt in Modellen, die nicht mit quadratischer Komplexität arbeiten. In Modellen, die den KV-Cache nicht speichern, sondern neu berechnen - oder ganz eliminieren.

Bis dahin: Verstehen Sie Ihren Engpass. Messen Sie, bevor Sie optimieren. Und vergessen Sie nicht: Die größte Gefahr ist nicht, zu wenig Speicher zu haben. Sondern zu viel Zeit in die falsche Optimierung zu stecken.