Einen reproduzierbaren PyTorch-Lauf planen

Einen vollständigen Schritt nachweisen, bevor skaliert wird

Fixieren Sie die Modell- und Datensatz-Revisionen, Abhängigkeitsversionen, die Trainingskonfiguration, Zufalls-Seeds und den Container-Digest. Führen Sie Modellladen, einen vollständigen Trainingsschritt, Evaluierung, Checkpoint-Speichern und Checkpoint-Wiederherstellen auf einem Beschleuniger aus.

Verwenden Sie dieselbe Sequenzlänge und dieselben Micro-Batch-Einstellungen, die für den längeren Lauf vorgesehen sind. Ein winziger Pilot, der den Optimiererzustand weglässt oder kürzere Sequenzen verwendet, kann das Speicherproblem verbergen, das Sie messen möchten.

Einen repräsentativen Optimierungsschritt messen

Umgeben Sie in Ihrem bestehenden Trainingsprogramm einen repräsentativen Schritt mit einer Spitzenspeichermessung. Das Beispiel setzt voraus, dass Modell, Batch und Optimierer bereits auf der GPU initialisiert wurden. Beziehen Sie den Optimierungsschritt ein, da mancher Zustand verzögert erstellt wird.

torch.cuda.reset_peak_memory_stats()
optimizer.zero_grad(set_to_none=True)
loss = model(**batch).loss
loss.backward()
optimizer.step()
torch.cuda.synchronize()
peak_gib = torch.cuda.max_memory_allocated() / 2**30
print(f"Peak tensor memory: {peak_gib:.2f} GiB")

Dies meldet die Spitzenzuweisung von Tensoren, nicht den vollständigen Geräte-Fußabdruck. Prüfen Sie außerdem reservierten Speicher, Laufzeit-Overhead und den Gerätespeicherbericht des Systems.

Wählen Sie DDP oder Sharding aus dem richtigen Grund

DistributedDataParallel hält auf jedem Prozess eine Modellreplik und synchronisiert Gradienten. Es ist nützlich, wenn der vollständige Trainingszustand auf jede GPU passt und Sie mehr Daten parallel verarbeiten möchten; es führt VRAM nicht zu einem zusammenhängenden Pool zusammen.

Fully Sharded Data Parallel kann Parameter, Gradienten und Optimiererzustand verteilen. Verwenden Sie es, wenn der Speicherdruck die Aufteilung rechtfertigt, und berücksichtigen Sie zusätzliche Kommunikations- und verteilte Checkpoint-Komplexität.

Mixed Precision und Activation Checkpointing sind getrennte Entscheidungen. Validieren Sie das numerische Verhalten bei niedrigerer Präzision; messen Sie die Rechenkosten der Neuberechnung von Aktivierungen, wenn Checkpointing Speicher spart.

Einzelknoten-Pilotprojekt starten

Das Trainingsskript muss die verteilte Ausführung initialisieren und jedem GPU mithilfe der Local-Rank-Informationen einen Prozess zuweisen. Passen Sie die Prozessanzahl an die sichtbaren GPUs an. Das Folgende ist ein Startbeispiel für ein verteilungsfähiges Skript, keine vollständige Trainingsimplementierung.

torchrun --standalone --nproc-per-node=4 \
  train.py --config configs/pilot.yaml

Führen Sie dies nur auf einem bereitgestellten Node aus. Die lokale AnchorGPU-Demo führt kein Training aus und weist keine entfernten GPUs zu.

Hardware anhand des Pilotergebnisses auswählen

Verwenden Sie A100 als günstigere 80 GB CUDA-Basis und testen Sie H100, wenn die Workload einen nützlichen Hopper-spezifischen Pfad hat. H200 bietet eine größere CUDA-Speicherkonfiguration. MI300X bietet in diesem Katalog mehr Kapazität pro Beschleuniger, sofern die gesamte Anwendung auf ROCm qualifiziert ist.

Prüfen Sie für AMD benutzerdefinierte Erweiterungen, Kernel, Paketversionen und das mit ROCm getestete PyTorch-Image als vollständigen Satz. Die Kompatibilität auf Framework-Ebene validiert nicht jede optionale Operation.

Wiederherstellung testen, nicht nur speichern

Erfassen Sie Modell, Optimierer, Scheduler, Trainingsschritt, Konfiguration und den Zustand des Mixed-Precision-Scalers, sofern relevant. Speichern Sie einen Checkpoint, beenden Sie den Prozess und stellen Sie ihn dann wieder her und setzen Sie ihn fort, bevor Sie sich auf den langen Lauf festlegen.

Verwenden Sie eine Checkpoint-Methode, die für verteilten Zustand geeignet ist. Testen Sie, dass die gespeicherten Artefakte unabhängig vom ursprünglichen Prozess gelesen werden können und dass die Evaluierungsausgabe innerhalb der erwarteten Toleranz bleibt.

Budget für die gesamte Pipeline

Beziehen Sie Downloads, Vorverarbeitung, Datenladen, Validierung, Checkpointing, Export und das Kopieren von Ausgaben vom Knoten ein. Messen Sie den Durchsatz zusammen mit Speicher, Datenladestaus, Kommunikationszeit, Checkpoint-Dauer und Validierungsqualität.

Eine Laufzeit von 7 Tagen ist nützlich für einen begrenzten Kompatibilitäts- und Profiling-Durchlauf. Wählen Sie eine 30-Tage-Reservierung erst, nachdem Sie die nutzbare Arbeit und den betrieblichen Puffer abschätzen können. Mehr GPUs helfen nur, wenn zusätzliche Berechnung die Kommunikations- und Eingabepipeline-Grenzen überwiegt.