Ein Modell im Browser trainieren

Scellis führt die komplette Trainingsschleife — Autograd, Optimizer, Scheduler, Mixed Precision, PEFT — auf deiner eigenen GPU aus, in einem Browser-Tab, offline nach dem ersten Laden. Und der Anspruch ist präzise: Ein Tab überholt keine gemietete Datacenter-GPU, und Scellis behauptet das auch nie. Was du bekommst: null Installation, Berechnung, die auf deinem Gerät bleibt, freies lokales Compute auf jedem Tarif — und Runs, die per Konstruktion reproduzierbar sind. Diese Seite geht den Weg von Anfang bis Ende: konfigurieren, budgetieren, ausführen, checkpointen, fortsetzen.

Konfigurieren im Model View, nicht in verstreuten Einstellungen#

Alles, was einen Trainingslauf definiert, lebt am Modell selbst, im Model View — dem Vollbild-Editor, den du per Doppelklick auf einen Modell-Node betrittst. Dasselbe Modell erscheint dort dreifach zugleich — als Graph, als Formular und als Code in SML, der Scellis Model Language — drei Projektionen eines einzigen Datensatzes, synchron innerhalb eines Frames. Die Trainings-Pipeline ist Teil dieses Datensatzes:

model: user/ada/tiny_transformer@3
optimizer:  { block_id: training/optimizer/adamw, lr: 3.0e-4, weight_decay: 0.01 }
scheduler:  { block_id: training/scheduler/warmup_cosine, warmup_steps: 500 }
loss:       { block_id: training/loss/cross_entropy, label_smoothing: 0.1 }
epochs: 10
batch_size: 32
grad_clip:  { max_norm: 1.0 }
precision:  { policy: mixed_f16, master_weights: f32, loss_scaling: dynamic }
determinism_tier: prod   # debug | prod | fast — never silently defaulted
seed: 42                 # counter-based RNG, checkpointed with the run

Nichts davon versteckt sich in globalen App-Einstellungen — mit einer Konsequenz, die man unterstreichen sollte: Teilst du das Modell, reist die gesamte Pipeline mit; wer es öffnet, bekommt dein Trainings-Setup, nicht nur deine Architektur. Und beachte die letzten beiden Zeilen: Die Determinismus-Stufe ist eine explizite, sichtbare Entscheidung, und der Seed speist einen zählerbasierten RNG, dessen Zustand mit dem Lauf gecheckpointet wird.

Der mitgelieferte Komponenten-Stack#

Der Komponenten-Stack wird als Katalog-Content mitgeliefert — ein Start-Set, nie eine Obergrenze. Jeder Eintrag ist austauschbar, und jede Kategorie erweiterst du über denselben Authoring-Pfad, den auch die Built-ins genommen haben; dein eigener Optimizer erscheint in diesen Pickern genau wie ein mitgelieferter.

Eine ehrliche Fußnote zu PEFT: Die LoRA-Familie wird in den kompilierten Op-Graphen abgesenkt; Prefix- und Prompt-Tuning laufen heute auf dem Eager-Pfad — ein deklarierter Zustand, kein versteckter.

Ein Speicherplan vor dem ersten Schritt#

Bevor irgendetwas ausgeführt wird, berechnet der Planer die vollständige Speichergeschichte: Parameter, Aktivierungen, Gradienten, Optimizer-Zustand und Arbeitsspeicher — plus die f32-Master-Kopie der Gewichte unter Mixed Precision. Diese Klassen liegen gleichzeitig im Speicher: Passen muss ihre SUMME, der Spitzenwert; verschachtelte Schleifen multiplizieren ihn sichtbar. Der Spitzenwert wird gegen die realen Grenzen deines Geräts geprüft und kommt mit einem von drei Urteilen zurück: Grün — passt; Gelb — passt, mit Warnungen; Rot — abgelehnt, und die Ablehnung benennt die Abhilfe. Batch verkleinern, Activation Checkpointing aktivieren, Präzision wechseln: Jede Empfehlung kommt mit ihrer geschätzten Ersparnis — du entscheidest mit Zahlen statt per Trial and Error.

Dieselbe Ehrlichkeit gilt für Kapazität. Mehr Geräte zu poolen multipliziert Durchsatz, nicht Speicher: Ein Modell, dessen Parameter plus Optimizer-Zustand das VRAM eines Geräts übersteigen, kann dort bei keiner Batch-Größe trainieren — der Planer sagt das explizit und verweist auf die PEFT- und Sharding-Pfade (QLoRA allein senkt die Fine-Tuning-Schwelle um grob 4–8×). Wie sich Arbeit über Geräte verteilt — und was das ehrlich einbringt — ist die Geschichte von verteiltem Compute.

Was tatsächlich ausgeführt wird#

Dein Modell kompiliert eine inspizierbare IR-Leiter hinab zu WGSL-Compute-Kerneln; nichts umgeht sie. Die Trainingsschleife selbst ist host-getrieben — genau das macht datenabhängigen Kontrollfluss alltäglich: NaN-Skip bei übergelaufenen Schritten, Plateau-getriggerte LR-Absenkungen, Early Stopping. Mixed Precision ist eine echte numerische Policy — dynamisches Loss-Scaling, f32-Master-Gewichte, Reduktionen in f32 akkumuliert — mit offen ausgesprochener numerischer Decke: WGSL hat kein bf16 (f16 mit Loss-Scaling ist der ehrliche Browser-Pfad) und kein f64 auf der GPU (echtes f64 lebt auf dem WASM-Orakel). Rund um die Schleife erledigt der Compiler die unglamouröse Arbeit: automatisches Tiling um WebGPUs 128-MB-Binding-Grenze, ein erstklassiges Flash-Attention-Lowering und Activation-Rematerialisierung, wo du sie angefordert hast.

Fusions-Ehrlichkeit#

Kernel-Fusion greift im Fast-Tier-Inference-Forward. Der Trainings-Backward läuft auf dem Eager-Tape: Der Gradient ist korrekt, nicht fusioniert. Das erwartete Overhead-Band eager-gegen-fusioniert wird auf dem Konformitätskorpus gemessen und mit jedem Engine-Release neu veröffentlicht — nie eine erfundene Konstante.

Checkpoints setzen exakt fort#

Jeder Checkpoint ist ein inhaltsadressiertes Bündel:

{
  "weights":         "sha256:9c1e07…",
  "optimizer_state": "sha256:4b77aa…",
  "rng_state":       { "algorithm": "philox4x32", "counter": 18432000 },
  "epoch": 7,
  "step": 21875,
  "metrics": { "loss": 0.4181, "val_accuracy": 0.887 }
}

Weil der RNG zählerbasiert ist, liefern derselbe Seed und Zähler dieselben Züge auf jedem Backend — mit benannten Teilströmen für Dropout, Shuffling und Augmentierung. Einen Checkpoint fortzusetzen setzt das Training exakt fort, nicht ungefähr. Die Garantien sind gestuft und werden dir klar gesagt: Auf debug sind zwei Runs auf demselben Gerät bitweise identisch; auf prod hält die Übereinstimmung über Geräte hinweg die deklarierte Toleranz; geräteübergreifende Bit-Exaktheit ist der CPU-Orakel-Pfad. Runs, Datensatz-Versionen (per Hash referenziert — siehe Daten und Connectors), Checkpoints und Metriken sind allesamt Provenienz-Aufzeichnungen: Experimente zu vergleichen ist eine Abfrage über Aufzeichnungen, die ohnehin existieren — die Substanz von Reproduzierbarkeit und der Grund, warum ein Ergebnis zu reproduzieren eine URL ist, kein Ausgrabungsprojekt.

Fine-Tuning auf derselben Oberfläche#

Ein trainiertes Modell öffnet sich wieder im selben Model View — ein importiertes ebenso, über ONNX-, safetensors- und PyTorch-State-Dict-Codecs, die Content sind, keine Engine-Features. Friere ein, was du für verlässlich hältst, hänge PEFT-Adapter Layer für Layer an, tausche einen Head, schicke es zurück ins Training. Es gibt kein separates Fine-Tuning-Produkt: eine Oberfläche, ein Planer, ein Ausführungspfad.

Der lange Lauf, ehrlich#

Browser drosseln Hintergrund-Tabs, und Scellis sagt das, statt es zu überspielen: Wandert ein Trainings-Tab in den Hintergrund, wird die Verlangsamung laut angekündigt, und das Produkt bietet einen einwilligungspflichtigen Screen Wake Lock und ein abgekoppeltes Lauf-Fenster, um einen langen Lauf im Vordergrund zu halten. Ein abgestürzter Tab wird zu einem expliziten „unterbrochen“-Zustand abgeglichen — mit Ein-Klick-Fortsetzung vom letzten Checkpoint. Und es gibt keinen unbeaufsichtigten Modus zu verkaufen: Ein geschlossener Tab rechnet nichts.