Optimierung von AutoResearch auf der RTX 5090: Was scheiterte und was funktionierte

✍️ OpenClawRadar📅 Veröffentlicht: 20. März 2026🔗 Source
Optimierung von AutoResearch auf der RTX 5090: Was scheiterte und was funktionierte
Ad

Anfängliche Probleme und funktionierender Weg

Das anfängliche Setup für den Betrieb von AutoResearch auf einem RTX 5090/Blackwell-System war "schlecht kaputt" mit extrem schlechter Leistung – nur wenige tausend Tokens pro Sekunde und im Wesentlichen nutzlose MFU (Model FLOPs Utilization), obwohl der Code technisch lief.

Der funktionierende Konfigurationsweg beinhaltete:

  • Vermeiden des kaputten Full-Model-Compile-Pfads auf diesem Setup
  • Beibehalten der guten Fused-Optimizer-Compile-Verbesserungen, wo sie tatsächlich halfen
  • Verwenden des stabilen SDPA/CuDNN-Attention-Pfads
  • Empirisches Anpassen von Gesamtbatch und Zeitbudget statt Raten
  • Automatisieren der Benchmark/Extract/Strategize/Rerun-Schleife

Was fehlschlug

Mehrere Fehlermodi waren irreführend:

  • Ein Pfad, der technisch korrekt, aber katastrophal langsam war
  • Irreführende MFU-Interpretation, bis der Nenner für den 5090-Kontext korrigiert wurde
  • Höhere Batch-Einstellungen pro Gerät, die so aussahen, als sollten sie helfen, aber tatsächlich alles viel schlimmer machten
  • Automatisierungsfehler bezüglich Lock-Cleanup/Completion-Hooks/Dispatch-Reihenfolge

Wie der Entwickler feststellte: "Es gab mehrere Möglichkeiten, einen Lauf zu erhalten, der lebendig aussah, während er etwas Dummes tat."

Was half

Echte Verbesserungen kamen von:

  • Wiederaktivieren des Fused-Optimizer-Compile-Pfads
  • Reduzieren des Gesamtbatches von der ursprünglich größeren Einstellung
  • Validieren von 2**17 als die bessere Gesamtbatch-Region
  • Erhöhen des Zeitbudgets, sobald das stabile Batch-Regime gefunden wurde
  • Behandeln der Automatisierung als Teil des Benchmark-Systems, nicht als nachträglichen Gedanken
Ad

Leistungsfortschritt

Der Fortschritt der nützlichen Läufe zeigte klare Verbesserungen:

  • Baseline gesunder Lauf: val_bpb: 1.165452, mfu: 40.49%
  • Fused-Optimizer-Compile-Verbesserung: val_bpb: 1.155400, mfu: 42.88%
  • TOTAL_BATCH_SIZE = 2**18: val_bpb: 1.108381, mfu: 43.18%
  • TOTAL_BATCH_SIZE = 2**17 Validierung: val_bpb: 1.089424, mfu: 43.03%
  • Bester aktueller Auto-Loop-Ergebnis: TOTAL_BATCH_SIZE = 2**17, TIME_BUDGET = 1200, LR multiplier = 1.0, val_bpb: 0.999445, mfu: 42.56%, total_tokens_M: 387.8, num_steps: 2959

Aktuelle beste Konfiguration

Das bisher gefundene beste Ergebnis:

  • TOTAL_BATCH_SIZE = 2**17
  • TIME_BUDGET = 1200
  • LR multiplier = 1.0

Diese Kombination übertraf größere Batch-Varianten, kleinere 2**16-Varianten, einen Test mit niedrigerer LR und kürzere Trainingsbudgets.

Wesentliche Erkenntnisse

Die Hauptlektion war, dass die gewinnende Konfiguration kein "Alles maximieren"-Setup war. Der bessere Weg beinhaltete ein stabiles Batch-Regime, einen längeren Trainingshorizont und sorgfältige Beseitigung von Automatisierungs- und Backend-Fehlern.

Der Entwickler betonte, dass, wenn Sie an Blackwell/5090-Training arbeiten und seltsames Verhalten sehen, "es möglicherweise nicht Ihre Einbildung ist. Einige Pfade sind einfach viel schlechter, als sie zunächst erscheinen." Der nützliche Teil dieser Übung war, einen Pfad zu finden, der stabil, automatisierbar, reproduzierbar und gut genug ist, um darauf echte Folgeexperimente aufzubauen.

📖 Read the full source: r/LocalLLaMA

Ad

👀 Siehe auch

Drei wesentliche OpenClaw-Fähigkeiten für einen stabilen Aufbau: Speicher, Sicherheit und Erkundung
Anleitungen

Drei wesentliche OpenClaw-Fähigkeiten für einen stabilen Aufbau: Speicher, Sicherheit und Erkundung

Ein Reddit-Beitrag empfiehlt, zuerst drei spezifische Arten von OpenClaw-Fähigkeiten zu installieren: eine Speicherkorrekturfähigkeit, um Kontextverlust zu verhindern, eine lokale Sicherheitsprüfungsfähigkeit, um auf bösartigen Code zu überprüfen, und einen kuratierten Entdeckungshub, um gepflegte Tools zu finden.

OpenClawRadar
Java-Leistungsoptimierung: Acht Anti-Patterns, die Ihren Code verlangsamen
Anleitungen

Java-Leistungsoptimierung: Acht Anti-Patterns, die Ihren Code verlangsamen

Eine Java-Bestellverarbeitungs-App verbesserte sich von 1.198 ms auf 239 ms Laufzeit, von 85.000 auf 419.000 Bestellungen pro Sekunde und von 1 GB auf 139 MB Heap-Verbrauch, indem acht häufige Anti-Patterns behoben wurden, die durch Java Flight Recording Profiling identifiziert wurden.

OpenClawRadar
Wie ein inaktiver Agent 50 Millionen Token pro Tag verbrannte – und wie man das behebt
Anleitungen

Wie ein inaktiver Agent 50 Millionen Token pro Tag verbrannte – und wie man das behebt

Ein inaktiver OpenClaw-Agent hat 50 Millionen Tokens pro Tag durch Heartbeat-Pings mit einer aufgeblähten Session verbraucht. Ein Reddit-Nutzer erklärt, wie er das Leck aufgespürt und mit Konfigurationsänderungen behoben hat.

OpenClawRadar
Post-Mortem: Claude Max + OpenClaw Abrechnungsfehler durch veraltete OAuth- und isolierte Cron-Jobs
Anleitungen

Post-Mortem: Claude Max + OpenClaw Abrechnungsfehler durch veraltete OAuth- und isolierte Cron-Jobs

OpenClaw-Agent stürzt zufällig ab, weil ein veralteter OAuth-Token den gesamten Anthropic-Anbieter auf die Blacklist setzt und isolierte Cron-Jobs den Extra Usage-Bucket treffen. Vollständige Lösung: Manuelles Profil entfernen, Cron in Hauptsitzung verschieben, Abrechnungssperre löschen.

OpenClawRadar