§ Platform / Training
Train models in the browser — for real.
Training in a browser tab is the workload Scellis was built around, not a demo of one: the whole stack — gradients, optimizers, schedulers, losses, adapters, mixed precision — runs on the GPU already in your machine. Nothing to install, no CUDA, no cloud GPU meter. Every run is budgeted before it starts, checkpointed while it runs, and identified by its contents when it finishes.
The hardest workload keeps everything under it honest
Scellis trains models — it does not merely run them. Training is the workload the platform was built around precisely because it forces everything underneath to be real: a loop that touches gradients needs explicit memory planning, structured control flow, a correctness regime, reproducible randomness, and checkpoints. Harden a platform on its hardest case and the same machinery carries a simulation or a statistical analysis just as well. If you want to see what happens between your drawing and the code that runs on your GPU, the guide opens every stage: from a drawn graph to GPU code.
The GPU it uses is the one you already own — Apple, AMD, Intel, or NVIDIA, a laptop as readily as a workstation — because WebGPU is the browser's own interface to it: no CUDA, no drivers, nothing to install, no admin rights. Where a device has no usable GPU at all, the same workflow still runs on a slower CPU path, labelled as such and never silently; what that costs on a large model is written down in honest limits.
The loop itself is a program you can read. Forward, loss, backward, and optimizer step travel through the same stages as every other workflow — there is no special path for models — and the loop is driven step by step, so a decision that depends on the data, such as skipping a batch that produced a bad number or dropping the learning rate on a plateau, is something you express rather than something bolted on. A solo run never needs a server.
The full stack, not a demo subset
| Component | Count | Built-in set |
|---|---|---|
| Optimizers | 9 | Adam · AdamW · SGD · LAMB · Adafactor · Lion · Sophia · Int8Adam · Prodigy |
| Loss functions | 15 | MSE · L1 · BCE · CrossEntropy · KLDivergence · FocalLoss · HuberLoss · InfoNCE · TripletMargin … |
| LR schedulers | 14 | warmup, cosine, one-cycle, cyclic, plateau — plus a learning-rate range finder |
| PEFT methods | 6 | LoRA · QLoRA · PrefixTuning · BitFit · IA3 · PromptTuning |
| Metrics | 10 | Accuracy · F1 · Precision · Recall · ConfusionMatrix · Perplexity · AUROC · AUPRC · ECE · Brier |
| Weight initializers | 11 | Xavier · Kaiming · orthogonal · truncated-normal · sparse · pretrained … |
| Regularization | 5 | mixup · cutmix · label_smoothing · weight_decay · spectral_norm |
The counts are the built-in catalog, never a ceiling — every component is ordinary content. A method that is not in the list — distillation, DPO, MAML, curriculum learning — you can write yourself, on the same machinery, today.
Everything a training loop needs is present, budgeted, and inspectable — and every piece of it is an ordinary catalog entry rather than a hard-coded branch. All training-relevant settings live in one place, Model View: pick optimizer, scheduler, and loss from the catalog; set epochs, batch size, precision, clipping, and metrics on the model itself. The recipe stays with the model instead of scattering across scripts.
Past the table there is more: adversarial two-network (GAN) training, EMA and SWA weight averaging, gradient accumulation and clipping, activation checkpointing, augmentation with weighted sampling, NF4-quantized fine-tuning through QLoRA — with Int4 and Int8 quantization for inference — and model surgery: freeze, unfreeze, insert adapters. And the built-in set is a starting catalog, not a ceiling: an optimizer or a loss you write yourself passes the same checks as the built-in ones and runs identically — the engine cannot tell the difference.
The memory question, answered before the first step
Before any work reaches the GPU, the planner adds up the peak memory the run will need — parameters, activations, gradients, optimizer state, working memory, plus the extra full-precision copy of the weights that mixed precision keeps — and checks the total against what your device actually has. The answer is explicit: green runs; yellow runs with warnings; red is refused up front, with the fixes attached — shrink the batch, turn on activation checkpointing, stream the data, change precision. You never have to guess how much GPU memory a run will take, and you never discover the answer an hour in.
The plan is honest about capacity, too. A model whose parameters and optimizer state exceed one device's memory cannot train there at any batch size — the planner says so before you spend a minute of compute, and names what actually helps: adapters (QLoRA cuts the memory a fine-tune needs by four to eight times), splitting the optimizer state across devices, or pooling devices — which multiplies throughput, not the memory of any one device, a distinction that page states plainly.
Named mechanisms, never invented numbers
Mixed precision is a real policy, not a checkbox: loss scaling that adapts as the run goes, a step skipped when a batch produces a broken number, a full-precision master copy of the weights, and reductions accumulated in full precision. Attention is a first-class operation with a memory-efficient implementation rather than a chain of generic matrix multiplies that would need a score matrix no GPU allocation can hold, and a tensor too large for one allocation is split automatically instead of failing. Recomputing activations rather than storing them is a setting with its cost shown in the memory plan.
One claim is deliberately absent here: a speed race. A browser tab does not outrun a rented datacenter GPU, and Scellis will not print a multiplier claiming it does. The claims are the mechanisms above — plus zero install, your own hardware, offline operation, and compute that is never metered. The same register applies inward: the backward pass runs step by step rather than fused, which is correct but leaves speed on the table, and its overhead is measured and republished with each release instead of being asserted. More edges like this live in honest limits.
A run you can stop, resume, and reproduce
| In the checkpoint | What it preserves |
|---|---|
| Weights | The learned parameters, referenced by the hash of their contents. |
| Optimizer state | Momentum and variance intact — a resumed run continues instead of re-warming. |
| Random state | Named sub-streams — dropout, shuffling, augmentation — replay every draw. |
| Epoch and step | The exact position in the loop — a resume is precise to the step. |
| Metrics | The curve you watched, attached to the artifact that produced it. |
Checkpoints load by hash and continue. Intermediate ones may be cleared after a run; the final one is kept for as long as the model refers to it.
Randomness is counter-based: the same seed at the same position in the stream produces the same draw on any device, and the random state — with named sub-streams for dropout, shuffling, and augmentation — is saved with everything else. A resumed run therefore replays every draw exactly: the same batches in the same order, the same dropout masks, the same augmentations.
How reproducible the arithmetic itself is, you declare per run with the determinism tiers debug / prod / fast — carried end to end, recorded with the result, never silently defaulted; correctness shows how each tier is validated against a reference implementation. The boundary is stated with it: on the GPU, runs on different devices agree within a declared tolerance — bit-for-bit identity is what debug promises on one device, or on the reference CPU path.
A checkpoint is identified by the hash of its contents, so resuming is not a feature that can quietly regress — it falls out of how a checkpoint is stored at all. And a finished run pins everything it depended on — the program, the dataset versions, the checkpoints, the engine version — which is what makes a result reproducible from a link rather than from folklore.
A tab that takes a three-hour run seriously
A real run outlives your attention span, and a browser is a constrained place to live — Scellis says so instead of hiding it. A tab in the background is throttled by the browser: the run announces it loudly. You can hold the device awake with your permission, detach the run into its own window, and be notified when it finishes or fails. If the tab crashes mid-run, it comes back in an explicit interrupted state with one-action resume from the last checkpoint — never a phantom “running” row, never progress that quietly vanished.
Data enters the loop with the same discipline. Datasets and connectors stream under declared budgets rather than loading and hoping, and a train/validation/test split is a versioned artifact identified by its contents — the exact split behind a result stays reproducible instead of dissolving into a lost random state. And when one device is not enough, the identical loop extends across your own devices, a partner lab, or an open crowd lending idle GPUs — with the scaling story told honestly, regime by regime.
The economics follow from where the work runs: training on hardware you already own costs us nothing to meter, so it is never metered — on every plan, including none at all. For the walk-through, the guide covers training in the browser end to end.