Verteilten Trainings- und Inferenzcode für maschinelles Lernen ändern, ohne ihn zu beschädigen

## Erst den Code lesen und vor Änderungen an gemeinsamer Konfiguration oder APIs nachfragen Lies vor einer Änderung die relevante Implementierung, Muster in benachbarten Modulen, Konfigurationsverträge und Tests. Verwende die Umgebungsverwaltung, das Formatierungswerkzeug, das Prüfwerkzeug für statische Codeanalyse und die Pre-Commit-Werkzeugkette des Projekts; umgehe keine Prüfhooks. Trage Anmeldedaten, maschinenspezifische Pfade, Dienstendpunkte oder die Clustertopologie niemals fest in den Code ein. Errate keine Einstellungen des Auftragsplaners und baue nicht als Abkürzung bei der Fehlersuche die Beschleunigertreiber oder Laufzeitumgebungen neu auf. Hole vor folgenden Handlungen eine Entscheidung ein: - gemeinsame Konfigurationsstrukturen ändern; - Abhängigkeiten hinzufügen; - das Verhalten des Startprogramms oder des Auftragsplaners ändern; - öffentliche APIs löschen, umbenennen oder inkompatibel ändern. Wenn die benötigte Hardware oder der Clusterzugriff nicht verfügbar ist, gib an, welche Integrationsprüfungen aus welchem Grund ausgelassen wurden. Überführe keine ungeprüfte Annahme über das verteilte System in Code. Ordne die Arbeit dem jeweiligen Teilsystem zu: Trainingsmodul, Inferenzmodul, Algorithmus, Startprogramm, Auftragsplaner, Datensatz, Belohnung, Arbeitsablauf oder verteilte Fehlersuche. Nutze eine vorhandene spezialisierte Implementierungsanleitung oder den vorgesehenen fachlichen Prüfweg des Projekts. ## Teilsysteme getrennt halten und Daten mit ihrer Gewichtsversion kennzeichnen Behandle Orchestrierung, Rollout-Erzeugung, Training, Inferenz, Infrastruktur, Modellanpassung, Belohnungen, Datensätze und querschnittliche Hilfsfunktionen als getrennte Verantwortungsbereiche. Die Trainingskomponente koordiniert die Schleife, das Laden der Daten und die Arbeitsabläufe. Rollout-Arbeitsabläufe legen die asynchrone Episodenerzeugung fest. Inferenzmodule erzeugen Ausgaben und empfangen Gewichtsaktualisierungen; Trainingsmodule verarbeiten Rollout-Tensoren, berechnen Aktualisierungen und veröffentlichen neue Gewichtsversionen. Verknüpfe in asynchronen Systemen sowohl erzeugte Daten als auch Aktualisierungen mit ausdrücklichen Metadaten zur Gewichtsversion. Trainiere oder evaluiere niemals mit unbemerkt voneinander abweichenden Modellversionen. Gib Messwerte über das standardmäßige Nachverfolgungssystem aus, speichere Artefakte dauerhaft unter dem konfigurierten Ausgabestammverzeichnis und verwende den kanonischen Speicher- und Wiederherstellungspfad für Checkpoints. Beobachtbarkeit und Wiederherstellbarkeit gehören zum Ausführungsvertrag. Bevorzuge Komposition und Delegation gegenüber tiefer Vererbung. Halte Erweiterungsgrenzen so klein, dass Module, Arbeitsabläufe und Modelladapter unabhängig voneinander getestet werden können. ## Schnellen Beschleunigercode ohne Synchronisierung zwischen Gerät und Host schreiben Befolge die bestehenden Benennungs-, Typisierungs- und Protokollierungskonventionen des zuständigen Moduls. Verwende ausdrückliche Typannotationen und Importe; nutze niemals Importe mit Platzhaltern. Binde umfangreiche optionale Abhängigkeiten nur innerhalb der Funktionen oder Codepfade ein, die sie benötigen. Verwende die Projektprotokollierung statt direkter Druckausgaben. Nimm den Kontext der Komponente und des verteilten Rangs in die Protokolleinträge auf, damit sich nebenläufige Ausgaben weiterhin ihrer Quelle zuordnen lassen. In leistungsrelevanten Beschleunigerpfaden: - vermeide eine Gerät-zu-Host-Synchronisierung, etwa das Auslesen von Skalar- oder Listenwerten für die Protokollierung; - bündele Tensoroperationen, statt einzelne Elemente in Python nacheinander zu durchlaufen; - lege Gerät und Datentyp ausdrücklich fest; - prüfe an Schnittstellen mit Zusicherungen, ob die Tensorformen den Erwartungen entsprechen. Halte Rollout-Arbeitsabläufe blockierungsfrei. Warte asynchrone Modulaufrufe und Dateioperationen ab; führe keine synchrone E/A in einen asynchronen Episodenpfad ein. Orientiere dich bei neuer Funktionalität am nächstgelegenen funktionierenden Modulmuster, ergänze gezielte Tests und vermeide sachfremde Umstrukturierungen. ## Konfigurationsfelder und öffentliche APIs ändern, ohne Nutzer zu stören Ordne Konfigurationsfelder in dieser Reihenfolge an: erforderliche Felder, häufig verwendete optionale Felder, selten verwendete optionale Felder und schließlich interne Felder. Validiere sie bei der Initialisierung mit einer klaren Ausnahme, die den ungültigen Wert oder die verletzte Einschränkung nennt. Füge öffentliche Felder mit sicheren Standardwerten hinzu. Kennzeichne sie vor dem Entfernen als veraltet und vermeide es, bestehende Feldtypen zu ändern. Öffentliche Konfigurationsklassen müssen Einschränkungen und zulässige Werte dokumentieren. Stelle Befehlszeilenoptionen mit begrenztem Wertebereich durch eingeschränkte Typen statt durch frei formulierte Zeichenketten dar. Verwende kanonische Konfigurationsdatenklassen erneut, anstatt parallele Strukturen zu schaffen. Behandle gemeinsame Konfigurationen, Startprogramme, Auftragsplaner und Namen öffentlicher APIs als Bereiche mit großer Tragweite. Lege die Auswirkungen auf die Kompatibilität in der Änderungsbeschreibung ausdrücklich dar und hole vor zerstörerischen oder inkompatiblen Änderungen eine Genehmigung ein. Wenn sich das richtige Verhalten nicht aus den geltenden Verträgen bestimmen lässt, hinterlasse eine klar abgegrenzte Nachverfolgungsmarkierung und melde die ungeklärte Einschränkung, anstatt einen Standardwert zu erfinden. ## Prozessgruppen und Kollektivoperationen auf allen Rängen einheitlich halten Erstelle beim Import niemals eine globale Prozessgruppe. Übergib die vorgesehene Prozessgruppe ausdrücklich und frage den Rang bezogen auf diese Gruppe ab, wenn die Gruppenzugehörigkeit von Bedeutung ist. Richte die Abmessungen des Gerätegitters am deklarierten Parallelitätsmodell aus, einschließlich der jeweils zutreffenden Achsen für Datenaufteilung, Tensoren, Kontext, Experten und Expertentensoren. Kollektivoperationen sind globale Verträge: - jeder beteiligte Rang muss dieselbe All-Reduce-Operation in derselben Reihenfolge aufrufen; - wähle die Reduktionsoperation bewusst aus, etwa Summe gegenüber Mittelwert; - Broadcast-Operationen müssen einen ausdrücklichen Quellrang benennen; - Barrieren sind Diagnosewerkzeuge und keine routinemäßige Synchronisierungsstrategie. Untersuche bei Hängern, ob die Abfolgen der Kollektivoperationen voneinander abweichen. Prüfe bei falschen Ergebnissen die Reduktionssemantik und die Gewichtsversionen. Prüfe bei Speichererschöpfungsfehlern die Datenaufteilung, die Tensorplatzierung und die Gerätezuordnung, bevor du den Funktionsumfang des Modells verringerst. Nutze ausführliche Diagnosefunktionen für die verteilte Ausführung, die Kommunikationsbibliothek und den synchronen Start nur zur gezielten Fehlersuche. Entferne oder deaktiviere sie, sobald das Problem verstanden ist. ## Verteilten Code testen und übersprungene Testreihen im Pull Request nennen Benenne Tests nach Verhalten, Bedingung und erwartetem Ergebnis und gliedere sie in Vorbereitung, Ausführung und Prüfung. Kennzeichne langsame, asynchrone, beschleunigerbezogene und verteilte Tests, damit die Standard-CI die richtigen Testsammlungen auswählen kann. Überspringe nicht verfügbare Beschleuniger- oder Mehrknotentests kontrolliert und mit ausdrücklicher Begründung. Verwende die simulierte Prozessgruppe des Frameworks für verteiltes Verhalten auf Komponentenebene; ersetze keine Interna tiefer Datenaufteilung oder verteilter Tensoren durch Attrappen, wenn der Test gerade deren Semantik prüfen soll. Vergleiche Tensoren mit ausdrücklich festgelegten relativen und absoluten Toleranzen. Bevorzuge verwaltete temporäre Pfade und auf einen klaren Geltungsbereich begrenzte Monkeypatches. Führe zuerst die eng abgegrenzte Komponententestsammlung aus und anschließend, sofern die Hardware dies erlaubt, die unmittelbar betroffene Beschleuniger- oder verteilte Testsammlung. Führe vor der Einreichung die vollständige Formatierungs- und Pre-Commit-Werkzeugkette aus. Erzeuge die Befehlszeilenreferenzdokumentation mit dem kanonischen Generator. Erstelle die Veröffentlichungsdokumentation mit dem projektspezifischen Hilfsprogramm, das die erforderliche statische Einrichtung und Paketierung ausführt, und nicht mit einem untergeordneten Dokumentationsbefehl, der Projektschritte auslässt. Nenne im Änderungsantrag das Problem, die Risikobereiche, die genauen Testbefehle, ausgelassene Testsammlungen mit Gründen sowie etwaige Hardwarebeschränkungen. Verwende konventionelle Commit-Betreffzeilen im Imperativ und entferne Zwischencommits vor der Prüfung.