Wenn das GPU‑Upgrade zur Glaubensfrage wird, helfen Emotionen wenig – präzise Zahlen entscheiden. Statt allein auf TFLOPS und VRAM zu starren, misst du gezielt die Komponenten, die echtes Trainingstempo bestimmen. Die folgenden Benchmarks sind praxisorientiert, kosten- und zeitbewusst und zeigen dir, ob neue Hardware wirklich bringt, was sie verspricht.
Grundregeln für valide Vergleiche
Bevor du loslegst: gleiche Softwareumgebung (z. B. Conda/venv), PyTorch 2.4+ mit passendem CUDA/ROCm, identische Treiber, gleiche Seeds. Führe jeden Test dreimal aus und nimm den Median. Protokolliere Wall‑Time, GPU‑Takt, Temperatur und Verbrauch auf derselben Zeitskala. Wärme die GPU vor, bis Takte stabil sind. Unterscheide klar zwischen Inferenz‑ und Trainingsläufen und sorge dafür, dass der DataLoader nicht an HDD‑I/O hängt.
Die acht Benchmarks, die Entscheiden
1) Tokens/s pro Euro (LoRA auf 7B)
LoRA‑Finetuning auf einem 7B‑Modell (bf16), Sequenzlänge 2048, globaler Batch bis VRAM‑Limit, AdamW. Metrik: Median Tokens/s geteilt durch Gesamtpreis der GPU. Interpretation: Ein höherer Wert zeigt besseren Preis‑Leistungs‑Durchsatz; steigt Tokens/s, aber VRAM bleibt gleich, ist das Upgrade nur bedingt nützlich.
2) Max‑Batch vor OOM (7B, bf16)
Konfiguriere Identisches Training und erhöhe den globalen Batch, bis ein OOM auftritt. Metrik: größter stabiler globaler Batch bei Seq 2048. Interpretation: Wenn das Upgrade die Batch‑Kapazität nicht erhöht, bleibt VRAM der limitierende Faktor – bessere Taktrate allein hilft nur begrenzt.
3) Images/s pro Watt (ViT‑B/16)
Synthetic oder CIFAR‑10, 224 px, bf16, gleiche Augmentations. Metrik: Median Bilder/s geteilt durch durchschnittliche GPU‑Leistung (Watt). Interpretation: Misst Energieeffizienz; ein GPU‑Upgrade, das nur mehr Verbrauch bringt, ist für länger laufende Trainings oft schlechter als ein effizienteres Modell.
4) PCIe Host→Device Bandbreite (Pinned Memory)
Transferrate mit gepinnter CPU‑Memory messen. Erwartungswerte: Gen3 x16 ~12 GB/s, Gen4 x16 ~25–28 GB/s, Gen5 x16 ~45–55 GB/s. Interpretation: Ein Gen‑Mismatch zwischen Mainboard/CPU und GPU kann Datenlieferungen ausbremsen; niedrige Raten erklären oft plötzlich langsameres Training trotz hoher GPU‑Auslastung.
5) Effektive Speicherbandbreite (memory‑bound kernel)
Führe einen speicherintensiven Kernel‑Test aus (z. B. LayerNorm + GELU auf großen Tensors) und messe GB/s. Metrik: gemessene GB/s im Vergleich zur Spezifikation. Interpretation: Ist die Bandbreite nahe der Spezifikation, ist Speicher kein primärer Engpass; deutlich niedrigere Werte deuten auf Architektur‑ oder Treiberlimits hin.
6) SM‑Auslastung und Takt‑Stabilität
Über ein 60‑Sekunden‑Fenster SM‑Auslastung, GPU‑Takt und Temperatur erfassen. Metrik: Auslastungs‑Median und Situationen mit Takt‑Drop. Interpretation: Hohe, stabile SM‑Auslastung (>90 %) zeigt gute Rechenfüllung; häufige Takt‑Drops deuten auf thermisches Throttling oder zu aggressive Power‑Limits hin.
7) H2D/Latenz für kleine Transfers und Kernel‑Synchronisation
Kurztransfers (z. B. viele kleine Tensorkopien) messen, zusätzlich Host‑Device‑Roundtrips. Metrik: Latenzverteilung und Anzahl blockierender Synchronisationen pro Sekunde. Interpretation: Modelle mit vielen kleinen Transfers (z. B. sharded checkpoints, häufige Einspeisungen) leiden stark unter hoher Latenz – hier hilft oft Software‑Änderung oder schnellere PCIe‑Verbindung mehr als neue GPU.
8) End‑to‑end Schrittzeit inklusive DataLoader/Storage
Miss die Gesamtdauer eines Trainingsschritts inklusive DataLoader‑Wartezeiten und I/O‑Warschaften. Metrik: Median Step Wall‑Time und Anteil der Zeit, in der GPU auf Daten wartet. Interpretation: Wenn GPU oft idle ist, ist I/O oder CPU‑Vorverarbeitung der Flaschenhals – eine schnellere GPU ändert nichts.
Wie du die Ergebnisse liest und Maßnahmen ableitest
Vergleiche die Benchmarks nicht isoliert. Ein typisches Muster:
- Hohe SM‑Auslastung + niedrige Speicherbandbreite → memory‑bound: bessere Speicherarchitektur oder GPU‑Modelle mit mehr Bandbreite helfen.
- Steigende Tokens/s, aber gleicher Max‑Batch → VRAM limitiert; Upgrade auf weniger VRAM kann sogar Rückschritte bringen durch Checkpointing‑Overhead.
- Niedrige PCIe‑Raten oder hohe H2D‑Latenzen → Mainboard/CPU/BIOS oder Kabel/Riser prüfen; oft lohnender als die GPU.
- Hoher DataLoader‑Wait‑Anteil → Faster SSD, mehr Worker‑Threads oder optimierte Pipeline nötig.
- Thermal Throttling (Takt‑Drops) → Gehäuse‑Airflow, Kühlung oder Power‑Limits anpassen.
Praxis‑Tipps zur Messung
- Nutze Tools wie nvidia‑smi für Basismetriken und Nsight/Profiling nur bei Bedarf.
- Automatisiere Logging (Wandb/MLflow oder einfache CSVs) für Vergleichbarkeit.
- Führe Tests unter realen Workloads aus – synthetische Benchmarks geben schnellen Eindruck, können aber echte Trainingsmuster verfehlen.
- Bewerte Upgrade‑Kosten immer relativ zum erwarteten Laufzeitgewinn (Tokens/s pro Euro und Energieeffizienz beachten).
Mit diesen Benchmarks hast du ein messbares Set, das die häufigsten Engpässe aufdeckt. Das vermeidet teure Fehlkäufe und zeigt oft, dass bessere Kühlung, ein schnellerer PCIe‑Pfad oder optimierte I/O‑Pipelines mehr Wirkung haben als die nächsthöhere GPU‑Generation.
Inhaltsverzeichnis