Trainingszeit und -kosten Rechner
Eingaben
| Trainings-FLOPs gesamt | 5,88e23 |
|---|---|
| Modell-FLOPs-Auslastung | 40 % |
| Zahl der GPUs | 1.024 |
| Spitzendurchsatz je GPU | 989 |
| GPU-Stundenpreis | 2,5 $ |
Trainingszeit und -kosten Rechner
Schätzt Dauer und Kosten eines LLM-Trainingslaufs aus den gesamten Trainings-FLOPs, der GPU-Anzahl, dem Spitzendurchsatz je GPU in TFLOP/s, der Modell-FLOPs-Auslastung und dem GPU-Stundenpreis.
Eingaben
Arbeitsumfang
Cluster
Ergebnisse
Geben Sie einen Wert ein, um die Ergebnisse zu sehen.
Trainingszeit und -kosten
Das Training eines großen Sprachmodells ist eine feste Menge an Rechenarbeit, verteilt auf einen Cluster von Beschleunigern. Dauer und Kosten lassen sich daher vorhersagen, sobald Arbeitsumfang und Hardware feststehen. Dieser Rechner schätzt die Realzeit und die GPU-Stunden-Kosten eines Laufs aus den gesamten Trainings-FLOPs, der GPU-Anzahl, dem Spitzendurchsatz je GPU, der Modell-FLOPs-Auslastung und dem Stundenpreis der Anmietung.
Was die Schätzung umfasst
Die gesamte Gleitkomma-Arbeit eines Trainingslaufs lässt sich gut durch eine einzige Größe annähern, oft geschrieben als sechs mal Parameterzahl mal Zahl der Trainings-Tokens. Steht dieser Gesamtwert fest, ändert nur noch die Geschwindigkeit des Clusters den Zeitplan. Die gehaltene Rate eines Clusters ist die Summe der Spitzenraten seiner Beschleuniger, herunterskaliert um den Anteil, den sie tatsächlich nutzen — die Modell-FLOPs-Auslastung. Die Division der Arbeit durch diese Rate ergibt die Zeit, und die Multiplikation der Zeit mit der GPU-Anzahl und dem Stundenpreis ergibt die Kosten.
Die Formel
Mit der Gesamtarbeit in FLOPs, Beschleunigern zu je TFLOP/s, einer Auslastung und einem Stundenpreis je GPU ergeben sich die Laufzeit und die Gesamtkosten als
tT=n⋅P⋅1012⋅UC=3600t⋅n⋅cDer Faktor wandelt TFLOP/s in FLOP/s um, sodass sich als Sekundenwert ergibt; die Division durch 3600 macht daraus GPU-Stunden vor der Preisbildung. Eine Verdopplung der GPU-Anzahl halbiert die Zeit, lässt aber die GPU-Stunden-Kosten unverändert, weil dieselbe Gesamtarbeit lediglich früher fertig wird.
Rechenbeispiel
Betrachtet sei ein Lauf von FLOPs auf 1.024 Beschleunigern zu je 989 TFLOP/s, bei einer gehaltenen Auslastung von 40 %, gemietet zu 2,50 € je GPU und Stunde:
tT=1024×989×1012×0.45.88×1023≈1.45×106 s≈16.8 Tage=36001.45×106×1024×2.50≈1032000Der Lauf dauert rund siebzehn Tage und kostet etwas über eine Million Euro an GPU-Miete. Eine Anhebung der Auslastung von 40 % auf 50 % würde Zeit und Kosten je um ein Fünftel senken, weshalb das Herausholen von mehr aus derselben Hardware die günstigste verfügbare Optimierung ist.
Grenzen
Die Schätzung setzt voraus, dass der Lauf rechengebunden ist und der Auslastungswert bereits über den ganzen Auftrag mittelt. Sie schließt Checkpoint-Schreibvorgänge, Stockungen beim Laden der Daten, Neustarts nach Hardwareausfällen, Validierungsdurchläufe und die Leerlaufzeit einer gehaltenen, aber nicht rechnenden Reservierung aus. Netzwerk, Speicher und der Unterschied zwischen Spot- und Reservierungspreisen verschieben den realen Gesamtwert ebenfalls. Das Ergebnis ist als Planungsgrundlage zu verstehen, der ein Aufschlag für Overhead hinzuzufügen ist. Die Gesamtarbeit, die in diese Berechnung eingeht, leitet der Trainings-FLOPs Rechner her, und die reine Mietseite der Rechnung der GPU-Cloud-Kosten-Rechner.
Häufig gestellte Fragen (FAQ)
Wie wird die Trainingszeit geschätzt?
Die gesamte Gleitkomma-Arbeit des Laufs wird durch die Rate geteilt, die der Cluster halten kann. Diese Rate ist die GPU-Anzahl mal den Spitzendurchsatz je GPU in TFLOP/s mal die Modell-FLOPs-Auslastung, umgerechnet in Operationen pro Sekunde. Die Division der Gesamtoperationen durch diese gehaltene Rate ergibt die Realzeit als Sekundenwert, den der Rechner in Tagen, Stunden oder Minuten ausgibt.
Die Schätzung setzt voraus, dass der Lauf rechengebunden ist und der Auslastungswert bereits die durchschnittliche Effizienz über den ganzen Auftrag erfasst.
Welcher Auslastungswert sollte verwendet werden?
Die Modell-FLOPs-Auslastung ist der Anteil des theoretischen Spitzendurchsatzes, den ein Lauf tatsächlich erreicht. Beim Training großer Modelle auf gut abgestimmten Systemen liegt sie häufig zwischen 35 % und 55 %, wobei 40 % ein sinnvoller Standardwert ist. Kleinere Modelle, kurze Sequenzen, viel Kommunikation oder nicht optimierte Kernel drücken sie nach unten.
Da die Zeit umgekehrt proportional zur Auslastung skaliert, verdoppelt eine Halbierung den geplanten Zeitraum, sodass ein gemessener Wert aus einem kurzen Profiling-Lauf eine weit bessere Schätzung liefert als eine Annahme.
Warum kann die reale Rechnung von dieser Schätzung abweichen?
Die Schätzung zählt nur die stationäre Rechenleistung bei der gewählten Auslastung. Reale Läufe enthalten zusätzlich Checkpoint-Schreibvorgänge, Stockungen beim Laden der Daten, Neustarts nach Ausfällen, Validierungsdurchläufe und Leerlaufzeit, während eine Reservierung gehalten, aber nicht gerechnet wird.
Spot- oder Reservierungspreise, Netzwerk- und Speichergebühren sowie eine über den Lauf schwankende Auslastung verändern den Gesamtwert ebenfalls. Die Zahl ist als Planungsgrundlage zu verstehen, der ein Aufschlag für Overhead hinzuzufügen ist, nicht als exakte Rechnung.
Haftungsausschluss
Diese Schätzung setzt einen rechengebundenen Lauf bei konstanter Modell-FLOPs-Auslastung voraus und schließt Checkpointing, Stockungen beim Laden der Daten, Neustarts, Netzwerk und Speicher aus. Tatsächliche Zeit und Kosten schwanken mit Hardware, Software-Stack und Preismodell; das Ergebnis ist als Planungsgrundlage zu verstehen.