# Protokoll: ein Korpus wird akzeptiert, bevor die Kosten verglichen werden

Version 1 — 24. September 2026. Dieses Merkblatt schlägt ein auszufüllendes Protokoll vor; es enthält keine gemessenen Ergebnisse und keinen Datensatz. Das zugehörige Notebook verwendet ein kleines synthetisches MLP, um zu lernen, den Speicher zu erfassen. Es führt das untenstehende fachliche Protokoll nicht aus.

## 1. Die nützliche Arbeit vor den Versuchen definieren

Beispiel für eine Arbeit: ein Korpus von **1 000 Texten** klassifizieren. Stellen Sie selbst einen zulässigen Datensatz zusammen, der für Ihren Anwendungsfall repräsentativ ist, mit einer eindeutigen Kennung und einer geprüften Referenz pro Text. Legen Sie die Revision des Korpus, des Modells, des Tokenizers, des Codes und den Seed fest. Bewahren Sie die Liste der erwarteten IDs und die individuellen Ausgaben getrennt auf, um die Prüfung zu ermöglichen.

Definieren Sie vor jeder Messung: die Klassen, das Ausgabeformat, die Hauptmetrik (zum Beispiel Macro-F1), ihren Akzeptanzschwellenwert und die maximal zulässige Verschlechterung gegenüber einer Referenz. Wählen Sie eine für Ihre Anwendung relevante Toleranz; hier wird kein universeller Wert vorgegeben. Die Trainings-, Abstimmungs- und Evaluierungsdaten müssen getrennt bleiben.

Ein Korpus wird nur akzeptiert, wenn die 1 000 erwarteten IDs genau einmal vorhanden sind, keine zusätzliche Antwort in den Ausgaben enthalten ist, das Format gültig ist und die vorab festgelegte Qualitätsregel erfüllt ist. Zwei Dateien mit jeweils 1 000 Zeilen beweisen für sich genommen nicht die Gleichheit der IDs. Archivieren Sie die Prüfung der Mengen und der Duplikate.

## 2. Nur die angekündigte Variante ändern

Um den Batch zu untersuchen, bereiten Sie zum Beispiel die Varianten 1, 4 und 8 vor. Behalten Sie denselben Korpus, dieselbe Reihenfolge der Eingaben, dasselbe Modell, denselben Tokenizer, dieselbe Präzision und dasselbe Kontextlimit bei. Wenn Sie anschließend die Präzision untersuchen, erstellen Sie ein separates Experiment und führen Sie die Qualitätskontrolle erneut durch. Beschreiben Sie die Trunkierung: Das Kürzen der Texte verändert die geleistete Arbeit.

Erfassen Sie die tatsächliche GPU, die Anzahl der tatsächlich verwendeten GPUs, das Device, den Treiber, Python, PyTorch und die CUDA- oder ROCm-Runtime. Notieren Sie außerdem die Version Ihres Codes, etwaige Generierungsoptionen und jegliche Konkurrenz auf der Maschine in `notes`. Ein kommerzielles Paket mit zwei GPUs bedeutet nicht, dass das Programm beide verwendet.

## 3. Vergleichbare Durchläufe messen

Geben Sie an, was die Stoppuhr umfasst: nur die Verarbeitung oder die vollständige Kette mit Lesen, Tokenisierung und Schreiben. Trennen Sie das Laden, den ersten Durchlauf und die aufgewärmten Durchläufe. Das Speicher-Skript misst nur sein MLP und stoppt nicht eine vollständige Klassifizierungskette.

Führen Sie das angekündigte Aufwärmen durch, dann fünf gemessene Durchläufe pro Variante in abwechselnder oder im Voraus gezogener Reihenfolge. Bewahren Sie jede Rohdauer auf. Der Median und die Spanne min–max zeigen die Streuung; fünf Beobachtungen rechtfertigen keine robuste Schätzung des p95. Verwerfen Sie einen Fehler oder einen langsamen Durchlauf nicht stillschweigend: Behalten Sie seine Zeile und erklären Sie den Vorfall. Starten Sie in einem frischen Prozess neu, wenn Sie die ersten Durchläufe unter ähnlichen Bedingungen vergleichen möchten.

Synchronisieren Sie bei PyTorch-GPU-Messungen das gewählte Device vor der initialen Erfassung und nach der Operation. Erfassen Sie die Baselines `allocated` und `reserved`, setzen Sie die Peak-Statistiken zurück und behalten Sie dann die absoluten Peaks der Phase bei. `allocated` ist in `reserved` enthalten: Sie zu addieren würde einen Teil des Speichers doppelt zählen. Die beiden Maxima können zu unterschiedlichen Zeitpunkten erreicht werden: Ihre Differenz ist keine Messung des Caches zu einem gegebenen Zeitpunkt. Die Allokationen anderer Prozesse und diejenigen außerhalb des PyTorch-Allocators sind nicht abgedeckt.

## 4. resultats-bruts.csv ausfüllen

Die verteilte CSV enthält nur die Kopfzeilen. Schreiben Sie eine Zeile pro Durchlauf, mit einem Dezimalpunkt und Sekunden für die Zeiten, Bytes für den Speicher und US-Dollar-Cent für das Paket. Eine leere Zelle bedeutet „nicht erfasst“; null bedeutet tatsächlich null. In einer Notiz enthaltene Kommas müssen nach den üblichen CSV-Regeln geschützt werden.

| Felder | Bedeutung und Eingabe |
| --- | --- |
| `experiment_id`, `variant_id` | Stabile Identifikatoren des Experiments und der Variante. |
| `corpus_revision`, `model_revision`, `tokenizer_revision`, `seed` | Unveränderliche Versionen oder Prüfsummen sowie der angekündigte Seed. |
| `gpu_model`, `gpu_count`, `device`, `driver_version`, `python_version`, `torch_version`, `runtime_version` | Tatsächlich verwendete Hardware und beobachtete Umgebung; nicht ein Versprechen aus einem Angebot übernehmen. |
| `precision`, `batch`, `context` | Tatsächlich angewandte Konfiguration. |
| `phase`, `run_index`, `warmup_iterations` | Getrennte Phase (`cold` oder `warm` zum Beispiel), Nummer des Durchlaufs, Anzahl der Aufwärmläufe. Mischen Sie die Dauern nicht. |
| `expected_ids`, `observed_ids` | Anzahl der erwarteten und der beobachteten IDs; die detaillierten Listen werden mit den Ausgaben aufbewahrt. |
| `ids_match`, `format_valid` | `true`/`false` nach tatsächlicher Prüfung, einschließlich Duplikaten und zusätzlichen Antworten. |
| `quality_metric`, `quality_threshold`, `quality_tolerance`, `quality_value` | Vorab festgelegter Name, Schwellenwert und Toleranz, dann der gemessene Wert. Geben Sie in `notes` die Richtung der Toleranz und die Referenz an. |
| `corpus_accepted` | `true` nur, wenn alle Validierungsbedingungen erfüllt sind; andernfalls `false`. |
| `elapsed_seconds` | Rohe Dauer des angekündigten Umfangs, niemals ein erwarteter Wert. |
| `baseline_allocated_bytes`, `baseline_reserved_bytes`, `peak_allocated_bytes`, `peak_reserved_bytes` | Getrennte Messwerte für das allein gemessene Device. Leer lassen, wenn nicht gemessen. |
| `duration_days`, `lots`, `package_total_usd_minor` | Gewähltes Vollpaket, abgerechnete Lose und Gesamtpreis in US-Cent; eine einzelne Ausgabe darf nicht fünfmal addiert werden. |
| `accepted_unique_corpora` | Anzahl der für die wirtschaftliche Analyse akzeptierten, verschiedenen nutzbaren Korpora; dieses Feld ist nicht zwischen Wiederholungen zu summieren. |
| `notes` | Umfang, Vorfälle, Qualitätsentscheidungen, Code-Revision und Referenzen der aufbewahrten Belege. |

## 5. Rechnen, ohne eine Produktion zu erfinden

Der zu vergleichende Preis ist das vollständige Paket von 3, 7 oder 30 Tagen multipliziert mit den Losen. Bei B200 enthält ein Los zwei GPUs, und der Tarif deckt dieses Los bereits ab. `calcul_forfaits.py` wendet diese Regel auf die bereitgestellten Tarife an.

Wenn die gewählte nutzbare Arbeit ein vollständig akzeptiertes Korpus ist, muss `--accepted-results` die Anzahl der im Zeitraum tatsächlich validierten, verschiedenen Korpora erhalten. Die fünf Wiederholungen desselben Korpus dienen dazu, die Variabilität zu messen: Sie erzeugen nicht fünf nutzbare Ergebnisse. Legen Sie die Einheit vor dem Vergleich fest und behalten Sie sie für alle Varianten bei. Ohne gemessene und akzeptierte Menge lassen Sie diesen Parameter weg: Dann werden nur die Kosten des Pakets berechnet. Projizieren Sie nicht automatisch eine Rate auf 3, 7 oder 30 Tage.

Bewahren Sie das ausgefüllte Protokoll, die einzelnen Ausgaben, die Qualitätskontrollen, die Roh-CSV und die wirtschaftliche Berechnung zusammen auf. Eine schnellere, aber nicht akzeptierte Konfiguration erfüllt nicht dasselbe Ziel. Eine Konfiguration, die den Speicher überschreitet, bleibt eine Fehlerbeobachtung und keine durch null zu ersetzende Zeit.