Policy-Training

Training ohne eigene GPU

Das Training einer Manipulations-Policy ist eine GPU-Arbeitslast, und moderne Vision-Language-Action-Modelle brauchen mehr VRAM, als eine typische Workstation hat. Auf AY-Robots läuft das Training auf Cloud-GPUs, die die Plattform verwaltet: Sie wählen einen Datensatz und einen Policy-Typ, starten den Lauf und verfolgen den Fortschritt im Browser. Kein CUDA-Setup, kein Treiber-Abgleich, keine Umgebung zu pflegen.

Die Eingabe ist immer ein Cloud-Datensatz aus Dashboard > Datasets. Alles, was Sie über Teleoperations-Sessions aufgezeichnet oder im LeRobot-Format hochgeladen haben, kommt infrage, einschließlich zusammengeführter Datensätze. Kuratieren Sie vor dem Training: Als Failure gelabelte Episoden gehören meist nicht in den Trainingssatz, und zehn Minuten Sichtung im Episoden-Browser sparen Stunden GPU-Zeit, die sonst ins Lernen aus schlechten Demonstrationen fließen.

Unterstützte Policies

Vier Policy-Familien werden unterstützt. Sie unterscheiden sich in Größe, Trainingskosten und darin, wie viel sie aus Ihren Daten aufnehmen können. Die richtige Wahl hängt also mehr von Aufgabe und Datensatz ab als von irgendeiner allgemeinen Rangliste.

Einen Lauf starten

1. 1
   Datensatz wählen

   Öffnen Sie Dashboard > Training und wählen Sie den Datensatz, auf dem trainiert werden soll. Episodenzahl und Robotertyp werden angezeigt, damit Sie sicher sind, den richtigen erwischt zu haben.

2. 2
   Policy wählen

   Wählen Sie einen der unterstützten Policy-Typen. Im Zweifel beginnen Sie mit ACT: Es ist der günstigste Weg herauszufinden, ob Ihr Datensatz überhaupt gut genug ist, um irgendetwas zu trainieren.

3. 3
   Starten

   Starten Sie den Lauf. Er bekommt eine Job-Id und eine eigene Lauf-Seite, und Sie können den Browser schließen: Das Training läuft serverseitig weiter, und die Seite zeigt den Live-Zustand, wann immer Sie zurückkommen.

Die Trainingslauf-Seite

Jeder Lauf hat eine eigene Seite, die die zwei Fragen beantwortet, die man während des Trainings wirklich hat: Lernt es, und ist die Maschine gesund. Der Lernfortschritt erscheint als Charts von Loss, Learning-Rate-Schedule und Gradientennorm. Ein Loss, der sofort stagniert, oder eine explodierende Gradientennorm zeigt früh, dass sich das Warten auf diesen Lauf nicht lohnt.

Daneben steht die Maschinengesundheit: GPU-Auslastung und -Speicher plus die Host-Metriken der Trainingsmaschine. Eine Phasen-Timeline zeigt, wo der Lauf gerade steht, von der Umgebungsvorbereitung über das Laden der Daten und die Trainingsschleife bis zum Checkpoint-Upload. Sieht etwas merkwürdig aus, liefert der eingebaute Log-Viewer die rohen Trainingslogs ohne SSH-Zugang; das reicht meist, um zu erkennen, ob ein Fehlschlag an Ihrem Datensatz oder am Lauf selbst liegt.

Checkpoints und Fortsetzen

Checkpoints werden pro Lauf gespeichert, nicht in einem gemeinsamen Pool. Die auf einer Lauf-Seite gelisteten Checkpoints gehören also immer genau zu diesem Lauf und seiner Konfiguration. Das wiegt schwerer, als es klingt: Checkpoints über Läufe mit unterschiedlichen Einstellungen hinweg zu mischen ist ein Klassiker unter den Ursachen still kaputter Policies.

Wird ein Lauf unterbrochen, können Sie vom letzten Checkpoint fortsetzen, statt von vorn zu beginnen. Zwischen-Checkpoints sind auch für sich genommen nützlich: Beginnt ein langer Lauf gegen Ende zu overfitten, läuft ein früherer Checkpoint auf dem echten Arm oft besser als der finale.

Die trainierte Policy auf dem Arm ausführen

Eine fertige Policy lässt sich direkt zurück auf Ihren Roboter bringen. Wählen Sie im Cockpit die trainierte Policy für Ihren verbundenen Arm und starten Sie die Inferenz: Die Policy erzeugt jetzt die Gelenkbefehle, die vorher aus Ihrer Teleoperation kamen. Der Arm muss derselbe Robotertyp sein, auf dem der Datensatz aufgezeichnet wurde, und die Szene sollte den Trainingsszenen ähneln, einschließlich der Kamerapositionen.

Behandeln Sie die ersten Inferenzläufe wie Experimente, nicht wie Vorführungen. Halten Sie den Not-Stopp in Reichweite, beginnen Sie aus einem Startzustand nahe an dem, was Sie demonstriert haben, und rechnen Sie damit, dass die Policy auf Dinge empfindlich reagiert, die Ihnen gar nicht auffallen würden: eine versetzte Kamera, anderes Licht oder ein Objekt, das im Datensatz nie vorkam.

Wie viele Episoden Sie brauchen

Der häufigste Trainingsfehler auf der Plattform ist kein falscher Hyperparameter, sondern das Training auf zu wenig Daten, gefolgt vom Schluss, der Policy-Typ funktioniere nicht. Als Faustregel für eine einzelne Tischaufgabe: Rund 50 Episoden ergeben eine Policy mit enger Generalisierung, die aus Startzuständen nahe an Ihren Demonstrationen zum Erfolg kommt. Rund 100 bis 200 Episoden ergeben brauchbare Robustheit über den Arbeitsraum für diese eine Aufgabe, sofern Sie die Objektplatzierung zwischen den Episoden variiert haben.

Fähigere Policy-Typen heben diese Regel nicht auf. Ein GR00T-Fine-Tune auf 20 Episoden generalisiert trotzdem schlecht; was die größeren Modelle Ihnen kaufen, ist ein höheres Potenzial, sobald die Daten da sind. Bei begrenztem Budget stecken Sie es erst in mehr und vielfältigere Episoden, dann in ein größeres Modell.

Häufige Fragen