Hanyuyuan6/remote-gpu-trainer

remote-gpu-trainer – der Lebenszyklus von DL-Experimenten

Überblick

Ein Skill für den gesamten Bogen eines DL-Experiments: AUSFÜHREN → VERIFIZIEREN → AUSLIEFERN.

• AUSFÜHREN — einen langen GPU-Job starten, überleben und beenden lassen, dann das Ergebnis vom Rechner holen. Auf einer eigenen Maschine gibt es keine Zähler; auf einem gemieteten Rechner ist die Kernaussage, dass Sie ein kurzzeitiger Mieter auf der Maschine eines anderen sind – die Aufgabe besteht also darin, die Arbeit zu entkoppeln, das Ergebnis die Instanz überleben zu lassen und den Zähler sicher zu stoppen, nicht darin, einen Cluster bereitzustellen. Plattformspezifisch an den Rändern (eine profiles/<platform>.md verwaltet jeden Pfad, Proxy, Abrechnungsbefehl und Spot-Regel), invariant im Kern.
• VERIFIZIEREN — ist diese Zahl ein Fehler, ein echter Effekt oder Rauschen? Ein überraschendes Ergebnis ist eine Hypothese, keine Tatsache, die berichtet werden muss. Plattformunabhängig.
• AUSLIEFERN — das Ergebnis so organisieren, dass jede ausgelieferte Zahl/Abbildung/Tabelle eine deterministische Funktion einer einzigen unveränderlichen Beweisschicht ist; Herkunft und dokumentenübergreifende Konsistenz werden durch Mechanismen gesichert, nicht dadurch, dass sich ein Mensch merkt, drei Dokumente zu aktualisieren. Plattformunabhängig.

Zwei Haltungen durchziehen VERIFIZIEREN und AUSLIEFERN: Benutzersouveränität (die Wissenschaft – Seed-Anzahl, welche Stichproben, ob ein aux-Kanal existiert – ist die Entscheidung des Benutzers; das Skill organisiert und legt einen Kompromiss einmal offen und hört dann auf zu nerven) und prüfen → offenlegen, nicht erzwingen (das Skill ist ein ehrlicher Prüfer, kein Torwächter – ein Integritätsproblem muss mit der Schlussfolgerung, die es betrifft, an die Oberfläche kommen, aber das Skill blockiert den Benutzer nie beim Ausliefern). Leitspruch: „Lege es offen, oder behaupte es nicht.“

Zuerst den Weg wählen

1. AUSFÜHREN – eigener Rechner oder gemietet?
   • Lokal (ein Arbeitsplatzrechner/Laptop, den Sie besitzen, kein Zähler) → references/run-local/ und profiles/local.md.
   • Gemietet / Remote (jeder abgerechnete oder gemeinsame Rechner, den Sie nicht besitzen) → references/run-remote/, und wählen Sie ZUERST Ihre profiles/<platform>.md (sie verwaltet jeden Pfad/Befehl/Proxy, an den die Phasen delegieren).
2. Dann IMMER → VERIFIZIEREN Sie das Ergebnis (references/verifying/) → LIEFERN Sie es aus (references/delivering/). Diese beiden sind plattformunabhängig; sie laufen gleich, egal ob der Job lokal oder auf einem gemieteten Rechner trainiert hat. Überspringen Sie hier nichts, nur weil die Ausführung erfolgreich war – eine grüne Ausführung ist keine echte Zahl, und eine echte Zahl ist noch kein sauberes auslieferbares Ergebnis.

Debuggen Sie bereits ein Modell, das nicht konvergiert / OOM wirft / hängt / NaNs produziert, unabhängig davon, wo es läuft? Springen Sie direkt zu references/training/ (die 8-Dateien-Debug-Schicht), dann kehren Sie zu VERIFIZIEREN zurück, bevor Sie berichten.

Betriebsprinzipien (das Rückgrat)

Die lasttragenden Invarianten. Jeweils eine Zeile; der vollständige plattformübergreifende Satz (10 Invarianten für den Remote-Lebenszyklus) befindet sich in references/run-remote/principles.md – lesen Sie ihn vor Phase 0 einer Remote-Ausführung.

• Checkpoint-to-durable + idempotenter Neustart ist das universelle Rückgrat. Datei-Checkpoint zum dauerhaften Speicherort + unbedingtes Laden-des-neuesten-beim-Start ist der eine Mechanismus, der einen SSH-Abbruch, eine Slurm-Walltime-Tötung, eine K8s-Neuplanung, eine Spot-Vorverdrängung, eine Colab-Trennung überlebt. Das Entkopplungs-Primitiv (tmux / sbatch / Job) ist der austauschbare Stecker; dies ist die Invariante.
• Vertrauen Sie dem geladenen Artefakt, nicht einer Protokollzeile, die Erfolg behauptet. „synchronisiert / gespeichert / erledigt“ lügt bei einem stillschweigend fehlgeschlagenen Schreibvorgang; der eigene Zustand eines Überwachers ist ebenfalls eine Behauptung – gleichen Sie ihn gegen den tatsächlichen Prozess / das Artefakt / die Pixel / Bytes ab.
• Günstige Prüfungen vor teurer Berechnung. Ein CPU-Rauchtest mit 1–2 Batches (Logger aus) tötet Import-/Konfigurations-/Form-/Skalierungsfehler für ~umsonst, bevor sie GPU-Stunden abrechnen.
• Kosten und zerstörerische Aktionen sind die Entscheidung des Benutzers. Niemals automatisch freigeben/beenden, niemals dauerhafte Dateien ohne Bestätigung löschen; wenn die Bereinigung keinen Speicherplatz freigeben kann, bitten Sie darum, die Festplatte zu erweitern, schrumpfen Sie nicht stillschweigend das Experiment.
• Prüfen → offenlegen, nicht erzwingen. Was obligatorisch ist, ist die Offenlegung, nicht die Behebung. Ein Integritätsbefund (keine disjunkte Validierung, Leckage, während der Selektion berührtes Testset, eine Zahl, die Sie nicht ableiten können) muss mit der Schlussfolgerung einhergehen – aber das Skill legt offen, es blockiert nicht.

AUSFÜHREN – lokal (ein eigener Rechner)

Kein Zähler, keine Abbau-Uhr – die Risiken verschieben sich von Geld zu Ressourcenkonkurrenz und Stabilität Ihrer Maschine. Die Disziplinen, die nicht nachlassen: Umgebungshygiene, Ressourcenbewusstsein, Sorgfalt bei Artefakten/Checkpoints und „den Seed angeben“. Starten Sie bei profiles/local.md, dann das passende Dokument:

• Umgebungshygiene – niemals in conda base auf einem dauerhaften Rechner trainieren/installieren; das 4-Schritte-Tor (auflisten → die Projektumgebung auswählen → sys.executable bestätigen → ausführen) → references/run-local/env-hygiene.md.
• Starten & Entkoppeln – nohup/tmux, Protokoll + Alive-Probe, nicht im Vordergrund blockieren → references/run-local/launch.md.
• Einzelknoten Multi-GPU – torchrun/accelerate DDP-Umgebungsvertrag, die Erstausführungs-Rang/Hänge-Grundlagen → references/run-local/multi-gpu.md (Multi-Knoten → references/run-remote/multinode.md).
• Lokaler OOM – die Reparaturleiter auf Hardware, die Sie nicht größer mieten können → references/run-local/local-oom.md.

AUSFÜHREN – Remote (ein gemieteter Rechner)

Wählen Sie ZUERST Ihr Profil – es bindet jeden konkreten Pfad/Proxy/Berechtigungsnachweis/Abrechnungsbefehl/Spot-Regel, an den die Phasen delegieren. Mentales Verbmodell (eine API plattformübergreifend; das Profil bindet jedes Verb an reale Befehle): up (mieten+erreichen) → push (Code/Daten drauf) → run (entkoppelt + mit Checkpoints) → watch (dauerhafte Überwachung) → pull (Ergebnisse runter + verifizieren) → down (Zähler stoppen).

Sie sind auf…	Profil	Befehl zum Stoppen des Zählers (die Falle)
AutoDL (am tiefsten, kampferprobt)	profiles/autodl.md	关机 stoppt den Zähler, behält die Festplatte (die AutoDL-Ausnahme)
RunPod	profiles/runpod.md	terminate (stop rechnet immer noch 2× ab; zerstört die Volume-Festplatte)
vast.ai	profiles/vastai.md	destroy (stop rechnet die Festplatte für immer ab)
Lambda	profiles/lambda.md	terminate (kein Stop-Zustand)
Paperspace	profiles/paperspace.md	destroy + IP freigeben + Speicher löschen
恒源云 / 矩池云 / Featurize / 揽睿星舟	profiles/china.md	pro Plattform (Datenfestplatte rechnet oft im gestoppten Zustand ab)
Bare SSH / Slurm / K8s / Colab	profiles/generic-ssh.md	manuell (ein vergessener Rechner rechnet 24/7 ab)

Der 6-Phasen-Lebenszyklus (vollständige plattformspezifische Checkliste → references/run-remote/lifecycle_checklist.md): 0 Umgebungsaudit (df -i nicht nur df -h, cgroup memory.max, Checkpoint-Festplattenbudget) · 1 SSH + Berechtigungsnachweise (das vorgefertigte Image ist die Umgebung – führen Sie auf einem Mietrechner kein conda create aus; Geheimnisse über stdin) · 2 Wrapper + CPU-Rauchtest vor dem Mieten · 3 entkoppelter Start (proben, dann zurückgeben – niemals ein blockierendes sleep) · 4 dauerhafte Überwachung (die vierschichtige Architektur → references/run-remote/monitoring_patterns.md; ein sitzungsgebundener Überwacher stirbt mit der Sitzung) · 5 aggregieren + verifizieren + abbauen.

Eisernes Gesetz – Abbau-Tor: KEINE release / terminate / destroy / Dateilöschung, bis Checkpoints lokal abgeholt UND durch Laden verifiziert wurden (scripts/verify_local.py), und der Benutzer die kostenwirksame Aktion explizit genehmigt hat. „Es sah im Protokoll fertig aus“ ist kein Beweis. Auf den meisten Plattformen ist die Aktion zum Stoppen des Zählers irreversibel (löscht die Festplatte) – Bestätigung ist wichtiger, nicht weniger.

Andere Remote-Referenzen: ssh_transport.md (rsync/scp fortsetzbar, Geheimnisse-über-stdin, CRLF) · spot-resilience.md (Vorverdrängungsfrist, Young/Daly-Kadenz, atomares-Schreiben-Fortsetzung) · china-network.md (Mirrors + HF_ENDPOINT + die no_proxy-Falle) · parallel_ablation.md (Fan-Out-Unabhängigkeit + Abgleich) · multinode.md (NCCL/fabric, fortgeschritten) · gotchas_universal.md (der vollständige U1–U43-Katalog mit einem grep-Index).

Wenn das Training selbst bricht (das Modell, nicht die Plattform)

Sobald der Rechner läuft, bricht das Training auf seine eigene Weise – lokal oder remote, dieselbe Debug-Schicht (references/training/, 8 Dateien; jeder Eintrag Symptom → Ursache → Lösung mit zitierten Dokumenten). Nach Symptom navigieren:

• OOM / passt nicht (CUDA-VRAM oder Host-RAM, OOM-bei-einem-Schritt, die Reparaturleiter) → oom-memory.md.
• Multi-GPU-Start / HÄNGT (torchrun/accelerate/deepspeed-Umgebungsvertrag, DDP/FSDP/ZeRO) → distributed-launch.md.
• NaN / Inf / Verlustspitzen (fp16/bf16/tf32, AMP/GradScaler, LLM-Divergenz) → precision-stability.md.
• Zu langsam (GPU- vs. daten- vs. kommunikationsgebunden, Dataloader-Knöpfe, torch.compile-Fallstricke) → throughput-profiling.md.
• Fortsetzungsfehler (Vollzustands- + sharded Save/Resume; Epochen-Neustart, Neumischung, Scalers/EMAs verworfen) → checkpoint-resume.md.
• Domänenspezifische Fallstricke (LLM, Vision det/seg, Diffusion, RL, multimodal/VLM) → by-domain.md.
• Läuft, lernt aber nicht (einen Batch überanpassen, Parameter-aktualisieren-nicht, LR/Plan, Verlustfunktions-Fallen, Einfrieren) → convergence-debugging.md.
• Dataloader-Korrektheit (Worker-RNG-Augmentierungsduplikate, IterableDataset-Sharding, RGB-vs-BGR / ÷255 / set_epoch) → data-pipeline.md.

VERIFIZIEREN – ist die Zahl echt?

Bevor Sie irgendeiner Metrik, Ablationsdifferenz oder „es funktioniert jetzt“ vertrauen oder sie berichten: klassifizieren Sie sie als Fehler / Effekt / Rauschen, halten Sie einen Vergleich mit genau einer geänderten Variable fest, und untersuchen Sie Lecks / fairen Vergleich / Varianz / Metrikrichtung. Eine Zahl, die Sie nicht aus dem gespeicherten Artefakt ableiten können, ist noch kein Ergebnis. Haltung: prüfen → offenlegen – ein Integritätsproblem mit der Schlussfolgerung an die Oberfläche bringen, niemals stillschweigend durchlassen oder hart blockieren.

• Vollständige Methodik (die 14-Abschnitte-Sondenleiter + die 6 Invarianten) → references/verifying/methodology.md.
• Konstante / entartete Ausgabe, real == shuffle, Modell-ignoriert-Eingabe → references/verifying/representation-collapse.md.
• Ein grüner Rauchtest, der Untertraining vs. einen echten Fehler verbirgt; Verlust-niedrig-aber-Stichproben-schlecht → references/verifying/smoke-hidden-failures.md.

Geben Sie beim Vergleichen die Richtung der Metrik an (PSNR/SSIM/mAP ↑ besser; LPIPS/NMSE/Verlust ↓ besser) – niemals annehmen. Tracker-Forensik / Bereinigen doppelter Ausführungen → scripts/wandb_forensics.py.

AUSLIEFERN – organisieren → Einzelquelle → Abbildungen

Machen Sie das auslieferbare Ergebnis zu einer deterministischen Funktion einer einzigen unveränderlichen, versionierten Beweisschicht; sichern Sie Herkunft und dokumentenübergreifende Konsistenz durch einen Mechanismus, nicht von Hand. Acht Prinzipien, gestaffelt (references/delivering/principles.md):

• KERN (ab der ersten echten Zahl verdrahten) – P1 Beweis-/Präsentationsschichten sauber getrennt (null handgetippte Zahlen in der Präsentationsschicht) · P2 Zahlen aus results.json generiert, nicht transkribiert (sodass eine veraltete Zahl physikalisch unmöglich ist) · P3 inhaltsadressierte + append-only unveränderliche Ausführungen (erneute Ausführung erzeugt eine neue <run-id>, überschreibt niemals) · P7 Abbildungsketten-Rückverfolgbarkeit (results.json → source_data.csv → figure + .provenance-Sidecar) + das Pixel-erneut-öffnen-Tor (eine Abbildung, die gespeichert wurde, ist keine Abbildung, die korrekt ist) · P8 Auslieferung = ein Offenlegungs-Tor, kein blockierendes.
• Fortgeschritten (nahe der Einreichung einschalten – YAGNI gilt auch für die Herkunft) – P4 Daten/Split versioniert + Hash-gepinnt (Leckage wird maschinenprüfbar) · P5 Ein-Befehl-Reproduktion aus einem sauberen Klon (scripts/repro.sh.template).

Mechaniken: die On-Disk-Struktur → references/delivering/data-architecture.md; die zwei Manifest-Schemata → references/delivering/evidence-manifest-schema.md; die ein-Ordner-pro-Abbildung-Konvention + Pixel-Tor → references/delivering/figures.md; die pro-Zahl-Offenlegungs-Checkliste → references/delivering/delivery-gate.md.

EVIDENCE.json ist die projektebene zentrale Quelle der Wahrheit – eine maschinenlesbare Behauptungen↔Beweise-Zuordnung (jede Behauptung ← die unterstützende Exp-ID / Metrik / Abbildung + ein Papieranker + die Repo file:line). scripts/reconcile.py durchsucht das gesamte Repo nach seinen autoritativen Werten, um dokumentenübergreifende Abweichungen zu erkennen; scripts/manifest_scaffold.py stempelt die Struktur.

Begleitende Skills (alle OPTIONAL – dieses Skill ist eigenständig)

Empfohlene separate Installationen, die AUSFÜHREN / VERIFIZIEREN / AUSLIEFERN vertiefen; das Skill benötigt keines davon und funktioniert vollständig eigenständig. Ein-zeile-pro-Liste, was jedes hinzufügt, und der Fallback ohne Begleiter → references/companions.md. Kurz gesagt: Abbildungszeichnung (nature-figure / publication-chart / scipilot-figure), Experimentverifizierung (der experiment-verifier-Agent), parallele Ablation (superpowers:dispatching-parallel-agents), HF-Transport + gehostete Tracker (huggingface-skills:hf-cli / huggingface-trackio).

Mit der Zeit besser werden

Das Skill ist statisch, aber jede Ausführung kann ihm einen Fallstrick beibringen – ohne es zu beschädigen. Protokoll → references/self-improvement.md: sedimentieren Sie nur einen ursachengeklärten, reproduzierten, verallgemeinerbaren Fallstrick (ein einmaliger Ausfall ist eine Hypothese, kein Fallstrick); leiten Sie benutzer-/projektspezifische Fakten an den Speicher des Hosts und verallgemeinerbare an einen vorgeschlagenen Katalog-Editor weiter; überschreiben Sie niemals stillschweigend eine Skill-Datei – entwerfen Sie das Symptom → Ursache → Lösung und lassen Sie den Benutzer zustimmen. Plattformfakten tragen einen verified <month>-Stempel – überprüfen Sie alle Abbau-/Abrechnungsfakten anhand der aktuellen Dokumente erneut, bevor Sie Geld oder Daten wetten (scripts/check_staleness.py).

Mitgelieferte Ressourcen

Laden Sie nur das, was die aktuelle Phase benötigt (die Hauptabschnitte oben nennen die einzelnen Dateien).

• references/run-local/ – eigenen-Rechner: umgebungs-hygiene · start · multi-gpu · lokaler-oom.
• references/run-remote/ – gemieteten-Rechner: prinzipien · lebenszyklus_checkliste · monitoring_muster · ssh_transport · spot-resilienz · china-netzwerk · parallele_ablation · multinode · universelle_fallstricke (U1–U43).
• references/training/ – die DL-Training-Debug-Schicht (8 Dateien; lokal/remote-agnostisch) – oben geführt.
• references/verifying/ – ist-die-zahl-echt: methodik · repräsentationskollaps · rauchtest-verborgene-fehlschläge.
• references/delivering/ – auslieferbar: prinzipien · datenarchitektur (+EVIDENCE.json) · bewusstseinsmanifest-schema · abbildungen · auslieferungstor.
• references/companions.md (optionale Skills + Fallbacks) · references/self-improvement.md (Fallstrick-erfassungs-Schleife).
• profiles/<platform>.md – pro-Plattform-Untergrund (7 Mietprofile + local.md; _schema.md = die Felder).
• scripts/ – Wrapper (run_one.py, verify_local.py, check_staleness.py, reconcile.py, manifest_scaffold.py, wandb_forensics.py, repro.sh.template).

Die volle Referenzdokumentation (nicht auf die Repo-Ansicht angewiesen) → docs/ (architecture.md, glossary.md, quickstart.md, faq.md – in Arbeit).