Klapp das Modell auf.

Skizziere die Architektur auf der Canvas, justiere sie Feld für Feld im Formular, oder schreib sie als Code — eine kompakte, lesbare Modellsprache, die du reviewen, vergleichen und einer Kollegin schicken kannst. Die drei widersprechen sich nie, denn sie sind drei Ansichten einer Definition, nicht drei Kopien: Ändere einen Layer irgendwo, und die anderen beiden rendern in unter 16 ms aus denselben Daten neu. Vertippst du dich im Code bei einem Layer-Namen, schlägt der Parser den gemeinten vor.

Die Synchronisation ist ehrlich darin, was sie tragen kann und was nicht. Der Code hält die Bedeutung des Modells — Architektur und Trainingssemantik —, die Canvas hält das Layout. Ein Layout lässt sich in Text nicht ausdrücken; nach einer Codeänderung legt die Canvas das Modell deshalb neu aus, statt so zu tun, als hätte der Text sich gemerkt, wo jeder Kasten saß. Alles, was ausmacht, *was* das Modell ist, übersteht den Rundlauf; die Anordnung auf dem Schirm wird neu hergeleitet — und wir schreiben das hin, statt es dich entdecken zu lassen.

Öffne ein trainiertes Modell, friere ein, was du ihm glaubst, und adaptiere den Rest. Einfrieren geht Layer für Layer oder Gruppe für Gruppe; Adapter docken an, wo du sie brauchst — aus dem Katalog gewählt, statt in dein Trainingsskript geforkt. Layer können sich einen Satz Gewichte teilen und zusammen einen einzigen Optimizer-Schritt machen, und Lernraten-Gruppen lassen den Kopf ein anderes Tempo laufen als die Basis — so erledigen ein paar Millionen Parameter die Arbeit von hundertachtundzwanzig.

Nichts davon ist Modellen vorbehalten, die hier geboren wurden. Ein Checkpoint, der als safetensors oder ONNX über Daten & Konnektoren ankommt, öffnet sich auf derselben Oberfläche, und dieselbe Chirurgie treibt sein Feintuning. Während du änderst, wandern die Parameter- und Speicherzahlen mit dem Modell mit — gesamt, trainierbar, eingefroren und der Speicherbedarf, auf den du zusteuerst —, und der Trainings-Planer macht aus dieser Schätzung eine harte Prüfung, bevor der erste Schritt läuft.

Alles, was einen Trainingslauf formt, wird dort konfiguriert, wo das Modell lebt: Optimizer, Zeitplan, Losses an die Outputs verdrahtet, Epochen, Batch-Größe, Mixed Precision, Gradient Clipping, Metriken — ein Ort, nie über die App verstreute Einstellungen. Jede Auswahlliste wird vom Katalog gespeist: Die Optimizer-Liste ist das, was dein Katalog hält — die mitgelieferte Bandbreite steht bei Training — und eine Methode, die du selbst geschrieben hast, erscheint in derselben Liste wie die mitgelieferten.

Zwei Einstellungen verdienen einen eigenen Satz. Der Trainingsmodus ist offen — standard, adversarial, multi-objective oder einer, den du definierst — und wie exakt der Lauf reproduzieren muss, wird hier deklariert, pro Lauf: debug, prod oder fast, sichtbar und nie still für dich gewählt. Weil das Setup Teil des Modells ist, bleibt es an ihm: Teile das Modell, und sein Trainings-Setup kommt unversehrt an — die Person am anderen Ende drückt auf Start, so wie es der Trainings-Guide durchgeht.

Hinter jeder Aktion in Model View steht ein Befehl — einen Layer hinzufügen, zwei Ports verbinden, eine Gruppe einfrieren, den Zeitplan setzen — ein Befehl pro Aktion. Der Copilot benutzt genau diese: Bitte ihn, den Decoder umzubauen, und er wendet dieselben geprüften Änderungen an, die du klicken würdest — zugeordnet, vorher erfragt und einzeln rückgängig machbar. Dieselben Befehle sind die offene Schnittstelle; ein Skript ist hier also nie zweite Klasse.

Die Historie ist so geschnitten, wie du denkst. Model View führt drinnen einen eigenen Undo-Stapel, und beim Hinausgehen faltet sich die ganze Sitzung zu einem einzigen Eintrag in der Historie des Workflows — eine Modelländerung, egal wie viele Gesten sie brauchte. Gespeichert wird versioniert wie überall: Ein veröffentlichtes Modell ändert sich nie an Ort und Stelle — dein Speichern prägt die nächste Version, und bestehende Versionen bleiben genau so, wie sie waren; was an ihnen hängt, bedeutet weiter, was es bedeutete.