AyoobAI Hadron
Home Demo Sectors Live comparisons
10 of 10 sectors live
Home / Sectors / On-device training and personalisation

On-device training.

Gradient compute where each step picks its own backend - with categorical refusal for shapes that would hurt on GPU.
The buyer's problem

Personalisation models that train on user data (recommendations, classifiers, autocomplete) face an impossible choice today: ship the data to the cloud (privacy nightmare, regulator headache), or train locally with a hand-rolled gradient loop that picks one backend up front and lives with the consequences.

What Hadron replaces

The hand-rolled gradient compute loop. The compute engine decides per-step: forward matmul, loss reduction, backward matmul, parameter update - each one gets a fresh dispatch decision based on layer shape, batch size, and precision tolerance (patent-protected). Some model shapes are categorically GPU-hostile - those route to Worker or CPU with a named reason (patent-protected).

What the buyer gets

Models that train visibly while the page stays responsive. Training labels and trained weights both never leave the device. The dispatch decision is observable per gradient step - investors and regulators see exactly which backend ran each operator. The refusal mechanism makes the system honest about workloads where GPU would lose.

Patents demonstrated: P2 P5 Reference customers: privacy-focused browsers, on-device ML platforms, and regulated SaaS
How to tell Hadron is working

Hadron is not claiming “train your model in the browser, the GPU will handle it”. The interesting story is the opposite: every gradient step picks its own backend. A 64-batch matmul on a quantised 128-feature MLP goes to GPU; the layer-norm and softmax after it stay on CPU; a tiny logistic-regression model has so little per-step work that the scorer correctly refuses GPU and runs on Worker. The dispatch is what makes browser training viable.

GPUForward + backward matmul on layer sizes large enough that compute dominates upload cost.
WORKERBackground thread for small models where GPU transfer would dominate but the page should still stay responsive.
CPULayer-norm, softmax, parameter updates - low arithmetic intensity, GPU upload not worth it.
REFUSEDcategorical refusal mechanism for very small models, shape-mismatched ops, or precision-risk workloads that would lose on GPU.
UI heartbeat: 0 frames painted Longest frame gap (last 5s): 0 ms main thread responsive
← Back to sectors index
Hadron is a product of AyoobAI.