Welche GPU kostet am wenigsten für dasselbe ML-Ergebnis?

Festlegen, was als akzeptiertes Ergebnis zählt

Schreiben Sie die Entscheidung vor den Tests auf: „Welche Konfiguration verarbeitet alle meine Dokumente, erfüllt meine Mindestqualität und endet vor meiner Frist, bei geringstem eingesetztem Budget?“ Legen Sie das Szenario fest: hier ein offline verarbeitetes Korpus. Eine interaktive Anwendung würde außerdem erfordern, den Eingang der Anfragen, ihre Nebenläufigkeit und die zulässige Latenz zu definieren; ihre Rangfolge lässt sich nicht allein aus diesem Test ableiten.

Bezeichnen Sie eine vollständige Menge von Ausgaben, die alle Ihre Kontrollen besteht, als validiertes Korpus. Eine erstellte Datei ist noch kein akzeptiertes Ergebnis. Prüfen Sie die Identifikatoren, das Format, die Abdeckung und eine für Ihren Anwendungsfall relevante Metrik. Tragen Sie den Schwellenwert und die Toleranz gegenüber einer Referenz ein, bevor Sie die Zeiten betrachten. So können zwei Konfigurationen für die Entscheidung gleichwertig sein, ohne bitidentische Zahlen zu liefern.

Diese Trennung zwischen Datensatz, Qualitätsziel und Szenario findet sich auch in den Prinzipien von MLPerf Inference. Das folgende Protokoll ist unsere Arbeitsmethode, die an Ihr Projekt anzupassen ist; es stellt weder eine Ausführung noch eine MLPerf-Zertifizierung dar.

Technische Quellen: MLCommons — Szenarien, Metriken und Qualitätsziele

Eingaben, Referenz und Manifest vorbereiten

Sie benötigen ein Korpus, das Sie verwenden dürfen, Referenzantworten oder ein Bewertungsverfahren, den Inferenzcode und eine Umgebung, die das gewählte Modell ausführen kann. Trennen Sie die Daten, die zum Einstellen der Konfiguration dienen, vom endgültigen Vergleichskorpus. Wenn Sie die Schwellenwerte anpassen, nachdem Sie Letzteres gesehen haben, bereiten Sie eine neue unabhängige Bewertung vor, um die Schlussfolgerung zu stützen.

Geben Sie jeder Eingabe eine stabile Kennung. Bewahren Sie einen Fingerabdruck des Korpus, die Reihenfolge des Durchlaufs, die Revision des Modells und des Tokenizers sowie die Versionen des Codes und der Abhängigkeiten auf. Das Manifest beschreibt außerdem die verwendeten GPUs, Präzision, Quantisierung, Kompilierung, Attention-Backend, Padding-Richtlinie und maximale Länge. Eine andere Kürzung würde die zu vergleichende Arbeit verändern.

Erfassen Sie den Treiber und das Backend, die tatsächlich vorhanden sind. Prüfen Sie für eine AMD-Variante die Kombination aus System, GPU, ROCm und Framework in der offiziellen Matrix. Eine konsultierte Dokumentation oder der Name einer Karte beweist nicht, dass diese Umgebung installiert ist. Wenn sich die Software-Stacks zwischen zwei Versuchen unterscheiden, bezieht sich die Schlussfolgerung auf die vollständigen getesteten Konfigurationen.

Technische Quellen: AMD — ROCm-Kompatibilitätsmatrix

Beispiel: dieselben 1.000 Texte klassifizieren

Hier ist ein Experiment, das Sie mit Ihren Daten aufbauen können, ohne angenommene Leistungsergebnisse. Sie möchten 1.000 Texte in die Kategorien Ihres Projekts einordnen. Reservieren Sie 600 kurze, 300 mittlere und 100 lange Einträge; definieren Sie die Grenzen mit dem gewählten Tokenizer und behalten Sie eine für die Klassen repräsentative Verteilung bei. Diese Aufteilung ist ein Beispielprotokoll, kein bereitgestelltes Korpus und keine allgemeingültige Empfehlung für die Anteile.

Vergleichen Sie Batches von 1, 4 und 8 mit demselben Modell, derselben Präzision, derselben Reihenfolge und derselben Padding-Regel. Die einzige Variable dieser ersten Reihe ist der Batch. Eine zweite Reihe kann die Präzision oder die Hardware ändern, wobei die übrigen Entscheidungen ausdrücklich festgehalten werden. Eine Gruppierung nach Länge ist eine neue Variante, die deklariert werden muss, da sie die Arbeitsorganisation verändert.

Exportieren Sie für jeden Durchlauf die 1.000 Vorhersagen mit ihren Identifikatoren. Die Kontrolle muss genau die erwarteten Identifikatoren wiederfinden, ohne Duplikat oder Auslassung. Behalten Sie die fehlerhaften Vorhersagen: Sie dienen der Qualitätsberechnung. Das Entfernen schwieriger Beispiele würde den Score künstlich verbessern und das tatsächlich verarbeitete Korpus verkleinern.

Start, Aufwärmphase und gemessenen Durchlauf trennen

Erfassen Sie das erforderliche Herunterladen, die Installation, das Laden und die Kompilierung getrennt von der stabilisierten Verarbeitung. Sie können vom Zeitmesser eines Durchlaufs ausgeschlossen werden, während sie einen Teil der Miete belegen. Legen Sie eine identische Aufwärmregel für alle Varianten fest: abgedeckte Eingaben, Anzahl der Durchläufe und Behandlung von Neukompilierungen. Passen Sie diese Regel nicht an, nachdem Sie gesehen haben, welche Variante davon profitiert.

Definieren Sie die Grenzen der Hauptzeit. Messen Sie für dieses Offline-Beispiel das Lesen des Korpus, die Tokenisierung, die Transfers, die Inferenz und die Materialisierung der Vorhersagen auf dem Host. Messen Sie anschließend die Bewertung und das Schreiben der Ergebnisse separat, um die vollständige Kampagne zu erfassen. Eine auf die GPU-Berechnung begrenzte Dauer lässt sich nicht direkt mit dieser Verarbeitungszeit vergleichen.

CUDA-Operationen sind asynchron: Ein Host-Zeitmesser muss vor seinem Start auf das Ende der vorherigen Operationen warten und vor seinem Stopp auf das Ende der gemessenen Arbeit. CUDA-Events eignen sich für einen korrekt definierten GPU-Bereich. Für eine isolierte Operation übernimmt torch.utils.benchmark.Timer das Aufwärmen und die Synchronisierung. Behalten Sie zwischen den Varianten dieselben Messgrenzen.

Technische Quellen: PyTorch 2.14 — asynchrone CUDA-Ausführung · PyTorch — Messen mit torch.utils.benchmark

Wiederholen und Fehlschläge beibehalten

Planen Sie fünf vollständige Durchläufe pro Variante für diesen ersten Vergleich. Wechseln Sie ihre Reihenfolge ab, zum Beispiel 1–4–8, dann 4–8–1, dann 8–1–4, damit nicht immer dieselbe Variante zuerst kommt. Behalten Sie die Politik für Prozesse, Caches und Aufwärmen bei. Diese fünf Durchläufe beschreiben Ihre kleine Reihe; sie beweisen für sich genommen nicht die Stabilität über einen längeren Zeitraum.

Eine Zeile der Rohdatentabelle steht für einen versuchten Durchlauf, einschließlich eines Abbruchs. Sie verbindet die Variante und das Korpus mit den Parametern, der Dauer und dem Qualitätsurteil. Die Felder expected_ids und observed_ids halten die Anzahl der Einträge fest; ids_match bestätigt die Gleichheit der Mengen, die in den separat aufbewahrten Vorhersagedateien geprüft wird. corpus_accepted enthält das Urteil des Durchlaufs. Tragen Sie die Fehler und den Pfad der Ausgaben in notes ein. Fehlt eine Messung, lassen Sie ihre Zelle leer und geben Sie den Grund an. Ein Ausbleiben der GPU ist keine Messung von null Sekunden oder null Bytes.

Wenn Batch 8 bei langen Eingaben den Speicher überschreitet, behalten Sie die Fehlerzeile und die Anzahl der abgeschlossenen Einträge. Ersetzen Sie diesen Durchlauf nicht stillschweigend durch ein kleineres Batch. Die Wiederaufnahme-Einstellung wird zu einer eigenen Variante; ihre Zeit und ihre Versuche gehören zur Bilanz. Eine Unterbrechung oder ein Formatfehler ist niemals ein wirtschaftlicher Erfolg, nur weil er schnell war.

Dauern lesen, ohne fünf Versuche zu überinterpretieren

Stellen Sie die fünf Rohdauern, ihren Median, ihr Minimum und ihr Maximum vor, zusammen mit der Anzahl der Erfolge und Fehlschläge. Der Median beschreibt die Mitte dieser Beobachtungen; er beseitigt die Zwischenfälle nicht. Wenn ein Durchlauf aus einem dokumentierten äußeren Grund ausgeschlossen wird, behalten Sie seine Spur und wenden Sie dieselbe Ausschlussregel auf alle Varianten an.

Stellen Sie ein auf fünf Durchläufen berechnetes p95 nicht als robuste Schätzung der langsamen Fälle dar. Um die Latenz von Anfragen zu untersuchen, sammeln Sie eine geeignete Menge einzelner Zeiten mit dem Ankunftsszenario und der Nebenläufigkeit. Die fünf Korpus-Dauern und die Latenzen von 1.000 Anfragen sind nicht dieselbe Population.

Wenn die beobachtete Streuung mit dem Abstand zwischen den Medianen vergleichbar ist, entscheidet die Reihe noch nicht zwischen den Optionen. Fügen Sie Wiederholungen in einem gemeinsamen Protokoll hinzu oder untersuchen Sie eine konkrete Ursache: Laden, Eingabeformen, Kompilierung, nebenläufige Aktivität. Vermeiden Sie es, nur den besten Durchlauf jeder Karte zu berücksichtigen.

Qualität nach einem Wechsel der Präzision prüfen

Um FP32, BF16 oder eine Quantisierung zu vergleichen, gehen Sie von denselben Eingaben und derselben Referenz aus. Bewerten Sie das Format, die Hauptmetrik und die vorgesehenen Untergruppen. Eine Variante, die Ihre Toleranz überschreitet, kann für ein anderes Ziel interessant sein; sie gelangt nicht in den Vergleich bei gleichwertiger Qualität, indem Sie die Schwelle im Nachhinein senken.

Halten Sie die verwendeten Seeds und deterministischen Optionen fest. PyTorch garantiert keine vollständige Reproduzierbarkeit zwischen Versionen, Plattformen oder CPU- und GPU-Ausführungen, selbst mit demselben Seed. Geben Sie daher an, was Sie reproduzieren möchten: identische Ausgaben, begrenzte numerische Abweichung oder akzeptable fachliche Qualität. Für ein stochastisches Protokoll sehen Sie mehrere gemeinsame Seeds vor und bewahren ihre Ergebnisse getrennt auf.

Technische Quellen: PyTorch 2.14 — Umfang und Grenzen der Reproduzierbarkeit

Speicher als Machbarkeitskriterium nutzen

Eine Option muss das Korpus mit seinen langen Eingaben abschließen, bevor ihre Kosten verglichen werden. Erfassen Sie den Speicherspitzenwert pro Gerät und den Umfang des Zählers. Bei PyTorch folgt memory_allocated den Tensoren und memory_reserved dem vom Allocator verwalteten Speicher: Diese Werte lassen sich nicht addieren. Die entsprechenden Spitzenwerte können zu unterschiedlichen Zeitpunkten auftreten.

Das Notebook im Ordner zum Speicher hilft, Schätzung und Beobachtung zu unterscheiden. Seine Übung ersetzt nicht die Messung Ihres Modells: Laden Sie Ihre Umgebung, behalten Sie die Parameter bei und führen Sie Ihre Last erneut aus. Eine pro Karte angegebene Kapazität und ein Los-Preis erlauben es nicht, einen Durchsatz, eine Interkonnektion oder eine automatische Verteilung des Modells über mehrere GPUs abzuleiten.

Technische Quellen: PyTorch 2.14 — Speicherzähler und Allocator

Die Dauer mit dem vollständigen Zeitplan wählen

Die benötigte Dauer ist nicht nur die Summe der GPU-Kernel. Bauen Sie ein Zugriffsfenster von der Vorbereitung auf der Miete bis zur Abholung der Ergebnisse: Installation, Kontrollen, Aufwärmen, Vergleiche, geplante Wiederaufnahmen, Bewertung und Export. Fügen Sie die Wartezeiten hinzu, in denen Sie die Miete noch behalten müssen. Wenn sich Aufgaben überschneiden, argumentieren Sie auf Basis des tatsächlichen Zeitplans, statt ihre Dauern zweimal zu addieren.

Beispiel eines Zeitplans, ohne Annahme zur Geschwindigkeit: Sie möchten den Zugang von Montag 9 Uhr bis Freitag 9 Uhr behalten, in derselben Zeitzone und ohne Zeitumstellung. Dieses Fenster umfasst 96 Stunden. Es überschreitet die 72 Stunden eines 3-Tage-Pakets und passt in die 168 Stunden eines 7-Tage-Pakets. Das beweist nicht, dass Ihre Verarbeitungen rechtzeitig fertig werden: ihre Laufzeiten müssen noch gemessen werden.

Der Rechner ermöglicht es, Ihr Gesamtfenster einzugeben, und zeigt die Pakete für 3, 7 und 30 Tage an. Ein Paket, das den Zeitplan abdeckt, wird zum Kandidaten. Wenn die Kampagne den gewählten Zeitraum überschreitet, ändern Sie das Programm oder kalkulieren Sie die zusätzlich nötigen Zeiträume ausdrücklich; gehen Sie nicht von einer automatischen Verlängerung aus.

Die gebundenen Kosten mit unseren Paketen berechnen

Das Budget einer Miete ist der Preis des Pakets für ein Los, multipliziert mit der Anzahl der Lose. Die Kosten pro validiertem Korpus ergeben sich dann, indem dieser Gesamtbetrag durch die tatsächlich akzeptierten nutzbaren Korpora im angekündigten Umfang geteilt wird. Wenn kein Korpus akzeptiert wird, ist das Verhältnis nicht definiert. Die gebundene Ausgabe bleibt jedoch in der Bilanz.

Die untenstehenden Preise stammen aus unserem Katalog, Version vom 24. September 2026. Sie veranschaulichen die Berechnungsregel, ohne festzulegen, welche GPU Ihre Last am schnellsten abschließt. Ein B200-Los umfasst bereits zwei Karten: seinen Preis ein zweites Mal mit zwei zu multiplizieren würde diese Karten doppelt zählen. Zwei Lose RTX 4090 für 7 Tage kosten somit 220 USD; ein Los mit zwei B200 für 7 Tage kostet 2.071 USD.

Ein kurzer Durchlauf verwandelt das Paket nicht in eine stundenweise Abrechnung. Der Rechner verwendet den Gesamtbetrag des Pakets, auch wenn ein Teil des Zeitraums ungenutzt bleibt. Für ein größeres Projektbudget erfassen Sie die anderen tatsächlich anwendbaren Ausgaben und ihre Begründung separat. Vermischen Sie keine bei einer der Varianten gemessenen Kosten mit Posten, die bei der anderen vergessen wurden.

Technische Quellen: IteraGPU — Pakete aus dem Katalog

Nutzbare Ergebnisse zählen, nicht Wiederholungen von Messungen

Die fünf Wiederholungen eines gleichen Benchmarks dienen dazu, die Streuung zu beobachten. Sie werden nicht allein deshalb zu fünf nutzbaren Produktionskorpora, weil fünf Dateien geschrieben wurden. Definieren Sie die erwarteten Ergebnisse vor der Kampagne und zählen Sie jedes akzeptierte Ergebnis nur einmal. Wenn die tatsächliche Arbeit mehrere Korpora betrifft, muss jede Konfiguration dieselben Korpora verarbeiten und dieselbe Qualitätsregel anwenden.

Lassen Sie im Rechner die Anzahl der Korpora leer, solange die nutzbaren Ergebnisse nicht tatsächlich abgeschlossen und validiert sind. Das Qualitätskontrollkästchen bestätigt Ihre eigene Prüfung; das Tool liest weder Ihre Vorhersagen noch Ihre Metriken. Geben Sie ausschließlich die festgestellte Menge an. Das Kampagnenfenster kann eine Planungsannahme sein, aber eine Kapazitätsprognose ersetzt keine akzeptierten Ergebnisse.

Die abschließende Bilanz vereint für jede zulässige Konfiguration die Qualitätsurteile, die Bruttolaufzeiten, das Kampagnenfenster, das gebundene Paket und die Anzahl der akzeptierten Ergebnisse. Eine schnelle Option kann für eine knappe Frist nützlich sein, ohne die günstigste zu sein. Zwei Optionen, die in denselben Zeitplan passen, können durch ihre gebundenen Kosten, ihre Fehlschläge oder die verbleibende Unsicherheit unterschieden werden.

Das Protokoll herunterladen und einen wiederverwendbaren Nachweis behalten

Der Ordner IteraGPU Lab v1 bündelt die Materialien dieses Vergleichs und der Speichermessung. Beginnen Sie mit dem README und dem Qualitätsprotokoll und ergänzen Sie dann die Rohtabelle mit Ihren Durchläufen. Die Leistungszellen bleiben vor einer Ausführung leer; die Tarife sind Katalogdaten, getrennt von den Messungen.

Um zwei Lose RTX 4090 für 7 Tage zu beziffern, legen Sie calcul_forfaits.py und tarifs-forfaits.csv in denselben Ordner, öffnen Sie ein Terminal in diesem Ordner und führen Sie den untenstehenden Befehl mit Python 3.10 oder neuer aus. Er zeigt ein Pauschalangebot von 220,00 USD für zwei GPUs an. Die optionale Option --accepted-results erhält Ihre ganzzahlige Anzahl tatsächlich abgeschlossener und validierter, eigenständiger nutzbarer Korpora. Lassen Sie sie weg, solange diese Feststellung nicht vorliegt: Das Skript berechnet dann nur das Pauschalangebot, ohne Kosten pro Ergebnis zu erfinden.

Bewahren Sie das Manifest, die Eingabe-Fingerabdrücke, die Vorhersagen, die Urteile und die Tabelle der Versuche zusammen auf. Die Entscheidungsnotiz gibt die gewählte Einstellung, die abgedeckte Last und den Grund der Wahl an. Sie können sie später mit Ihrer Miete im IteraGPU-Kassenbuch abgleichen und die experimentelle Frage bei einem Modell- oder Versionswechsel exakt erneut aufwerfen.

Dieses Offline-Protokoll qualifiziert für sich genommen weder einen interaktiven Dienst noch ein Training bis zur Konvergenz oder einen anderen Datensatz. Für diese Anwendungen definieren Sie die nutzbare Einheit und die Kontrollen neu, bevor Sie vergleichen. Die bereitgestellten Dateien dienen dazu, Ihre Versuche vorzubereiten und festzuhalten; dieser Ordner enthält keinen gemessenen Vergleich zwischen den Konfigurationen des Katalogs und keine beobachtete Ersparnis.

python calcul_forfaits.py --gpu rtx-4090 --days 7 --lots 2

• IteraGPU Lab v1 — vollständiger Ordner ↓

  Archiv der Skripte, des Notebooks, der Tabellen und der Anleitungen.

• Qualitätsprotokoll ↓

  Eingaben, Akzeptanzkriterien und Vergleichsregeln, die vor den Versuchen festzulegen sind.

• Tabelle der Rohdaten ↓

  Leeres Blatt zum Festhalten von Parametern, Messungen, Urteilen und Fehlschlägen.

• Berechnung der Pauschalangebote ↓

  Budgetberechnung mit Preis pro Los, Laufzeiten von 3, 7 und 30 Tagen und validierten Korpora.

• Tarife der Pauschalangebote ↓

  Momentaufnahme der Preise unseres Katalogs, die von der mitgelieferten Berechnung verwendet werden.

• Notebook zur Speichermessung ↓

  Berechnungen und Messübung, die mit dem Speicher-Ordner zu interpretieren sind.

• Skript zur Speichermessung ↓

  Python-Version der Übung, mit Überprüfung der Umgebung.

• Anleitungen und Voraussetzungen ↓

  Umfang der Werkzeuge und Verfahren zu deren Ausführung und Aufbewahrung der Ausgaben.

• Lizenz der Ressourcen ↓

  Bedingungen für die Wiederverwendung der originalen Ressourcen des Ordners.