KAPITEL 4.3 · VERTEILTE ATTENTION & RING TOPOLOGY

Ring Topology für Distributed Attention

Wie Ring Attention große Sequenzen über mehrere Geräte verarbeitet, ohne dass die Kommunikation zum Engpass wird – Overlap von Compute und Communication

Ring Attention löst das Problem der Sequenz-Länge auf Hardware-Ebene: Statt eine GPU mit 1M Tokens zu überlasten, wird die Sequenz auf 8-16 GPUs verteilt. Der Trick: Während eine GPU rechnet, schickt sie gleichzeitig KV-Daten zur nächsten – kein Warten auf Kommunikation.

📖 Lern-Kontext ▼
🎯

Lernziele

  • Das Ring-Kommunikationsmuster für verteilte Attention verstehen
  • Nachvollziehen, wie Compute und Communication überlappen
  • Erkennen, warum Ring Attention fast linearen Speedup ermöglicht
🗺️

Kontext: Wo sind wir?

Schritt 4/6 Optimizations & Memory

Ring Attention erweitert Sliding Window auf Multi-GPU-Settings. Zusammen ermöglichen sie Kontextfenster von 1M+ Tokens – weit über das, was eine einzelne GPU verarbeiten kann.

💡

Warum wichtig

Gemini's 1M-Kontext und Claude's 200K nutzen verteilte Attention. Ohne Ring-Topologie wäre die Kommunikation zwischen GPUs der Flaschenhals – jede GPU müsste auf alle anderen warten.

📌

Key Takeaways

  • Sequence Parallelism: Jede GPU hält nur 1/N der Sequenz, aber alle KV rotieren im Ring
  • Overlap: GPU i rechnet mit KV von GPU i-1, während i-1 bereits an i+1 sendet
  • Skalierung: 8 GPUs = 8x mehr Kontext bei fast 8x Speedup
Devices
4
Sequence Length Total
256K
Block/Device
64K
Communication Vol
128 GB
Compute-Comm Overlap
92%
Effective Context
256K Tokens
Fig. 1 | Ring Topology mit 4-16 GPUs. Jede GPU berechnet Attention über seinen KV-Block, während KV-Blöcke zirkulieren. Farben: Grün=Compute Phase, Orange=Kommunikation Phase. Die Überlappung verhindert, dass Kommunikation den Critical Path blockiert.
Metrik 4 GPUs 8 GPUs 16 GPUs Trend
Sequence Length/GPU 64K 32K 16K Linear mit Devices
Total Sequence 256K 256K 256K Konstant (skalierbar)
Local Attention Ops O(64K²) O(32K²) O(16K²) Quadratisch pro GPU
Communication Volume 512 GB (je Phase) 512 GB (je Phase) 512 GB (je Phase) Konstant (gut!)
Phases 4 8 16 N = # Devices
Comm Latency ~80ms (NVLink) ~80ms ~80ms Konstant (Ring)
Compute Time/Phase ~200ms ~50ms ~12ms Quadratisch↓
Overlap % 88% 92% 96% Besser mit mehr GPUs
Effective Speedup 3.8× 7.2× 14.1× Nahe linear!
🔄
Ring Topology skaliert linear
Sequenzlänge pro Device sinkt mit 1/N, aber Total skaliert linear. N GPUs können 256K Token mit nahe 14× Speedup bei 16 Geräten verarbeiten. Schlüssel: Kommunikation konstant, Computation skaliert.
⚡
Compute-Communication Overlap ist kritisch
GPU i berechnet KV₁ Attention (Compute) während GPU i-1 KV₁ sendet (Comm). Zirkulation erfolgt parallel zur Berechnung. Ohne Overlap: nur 50% GPU-Auslastung. Mit Overlap: 92-96% möglich.
📊
Phasen-Struktur: N Phase je Zirkulation
Bei 4 GPUs: 4 Phasen bis alle K-V Blöcke zirkuliert sind. Phase i: GPU j rechnet mit KV₍ⱼ₊ᵢ₎ mod N. Nach Phase N sind alle Attention-Scores berechnet. Deterministisch und synchronisierbar.
🚀
Communication Volume bleibt konstant
Pro Phase: ~512 GB (KV-Blöcke zirkulieren). Egal ob 4 oder 16 GPUs. Das ist anders als Tree-Reduction (würde logarithmisch). Ring-Topologie ist ideal für Attention-Workloads.
💡
Praktisch limitiert durch NVLink-Bandbreite
H100 NVLink: 141 GB/s. 512 GB transfer braucht ~3.6s. Mit guter Overlap Compute/Comm dauert Phase ~200ms bei 4 GPUs. Skaliert mit mehr GPUs als Compute-Zeit sinkt schneller als Comm-Zeit.
🎯
8-16 GPUs sind sweet spot
4 GPUs: 88% Overlap, 3.8× Speedup. 16 GPUs: 96% Overlap, 14.1× Speedup. Über 16 GPUs: Network-Switching nötig (statt NVLink), Latenz steigt. Intra-node: Ring optimal.