Article
Deep Learning Performance - Warum GPUs brrrr machen
Deep Learning Performance: Warum GPUs brrrr statt brumm machen
Viele Entwickler greifen bei Performanceproblemen zu einer Sammlung von Tricks aus Twitter-Threads. “Nutze In-Place-Operationen! Setze Gradients auf None! Installiere PyTorch 1.10.0, aber nicht 1.10.1!” Doch diese Ad-hoc-Herangehensweise führt oft zu suboptimalen Ergebnissen. Wer von First Principles ausgeht, kann systematisch die richtigen Optimierungen identifizieren.
Die Effizienz eines Deep-Learning-Systems lässt sich in drei Komponenten zerlegen:
1. Compute: Zeit für GPU-Floating-Point-Operationen (FLOPS)
2. Memory: Zeit für Tensor-Transfers innerhalb der GPU
3. Overhead: Alles andere
Das Verständnis des eigenen Regimes ist entscheidend. Wer in einem Memory-Bandwidth-bound Regime sitzt, profitiert nicht von mehr GPU-FLOPS. Wer in einem Compute-bound Regime arbeitet, spart keine Zeit durch C++-Rewrites des Model-Codes.
Besonders spannend ist das Verhältnis von Compute- zu Memory-Bandwidth-Wachstum. Die FLOPS-Verdopplungszeit der CPUs ist deutlich kürzer als die der Memory-Bandwidth. Die Analogie: Wenn unsere Fabrik (Compute) schneller wächst als wir sie mit Materialien versorgen können (Memory), wird es immer schwieriger, die theoretische Peak-Effizienz zu erreichen.
Dazu kommt, dass moderne GPUs und TPUs massiv auf Matrix-Multiplikation optimiert sind. Wer keine Matmul-Operationen ausführt, erreicht statt der beworbenen 312 TFLOPS nur 19.5 TFLOPS - ein Faktor von 16. Die gute Nachricht: In typischen Modellen wie BERT machen nicht-Matmul-Operationen nur etwa 0.2% der FLOPS aus.
Der Schlüssel liegt im Factory-Analogy: Die GPU ist unsere Fabrik. Wir schicken Anweisungen (Overhead), schicken Materialien (Memory-Bandwidth), alles um die Fabrik effizient zu nutzen (Compute). Wer versteht, wo der Engpass liegt, kann gezielt optimieren - statt blind Tipps aus dem Internet zu befolgen.