PYTHON · NUMPY

Your device is a fabric

See the real cross-fabric runtime measure your device and route each workload to the backend that wins on it — tiny work to the CPU, large work to your GPU — the adaptive heterogeneous compute the whole course runs on.

01Challenge

Every model in this course trained on-device, in your browser. But 'on-device' is not one device — the machine in your hands is a fabric of very different processors: a CPU with a handful of fast general cores, a GPU with thousands of parallel ones, often an NPU tuned for neural math. None is best at everything. A GPU is a rocket that takes a moment to light: for a tiny matmul the launch overhead costs more than the work, so the CPU wins; for a large one the GPU's throughput wins by orders of magnitude. The Bench runs the actual Ferric WebGPU runtime in your tab. It times matmuls of growing size on your GPU and on CPU-wasm, and routes each to the faster one. Watch the crossover on YOUR hardware: small sizes stay on the CPU (green above red), then the GPU pulls away. Same code — it adapts to the silicon it lands on.

02Model

This is the systems truth under every on-device model: performance comes from using the right processor for each operation, and which processor that is depends on the operation's size and the hardware present. The cost of an operation on a device is roughly a fixed dispatch overhead plus the work divided by that device's throughput. The CPU has low overhead and modest throughput; the GPU has high overhead (encode a command, submit it, synchronize) and enormous throughput; an NPU sits elsewhere again. So the fastest device is a function of the workload: below a crossover size the low-overhead CPU wins, above it the high-throughput GPU wins — and a smart runtime measures those numbers on the actual box and routes each op accordingly, keeping results deterministic across backends. That is why the tiny models in this course correctly run on the CPU here — routing them to the GPU would be slower — while the very same code sends a large network, a batched training run, or a real vision-language-action model to the GPU automatically. It is also why 'no GPU needed' was the wrong framing: the right framing is 'use the GPU when it is the right tool', decided per workload. Ferric proves this fabric runs one pure-Rust source bit-identically across Metal, Vulkan, and the browser's WebGPU — the on-device, zero-lock-in substrate physical AI needs. In the browser your fabric has two devices — CPU-wasm and WebGPU. On the full native runtime the same law routes across four: the CPU; the GPU through the portable path; the GPU's tensor units, reached through raw Metal 4 because no portable API exposes them, running the same matmuls up to ~14× faster; and the Apple Neural Engine, reached through CoreML — and added to the fabric only when Apple's own compute-plan receipt confirms the Neural Engine actually runs the work. Measured on an M5 Max: the tensor units sustain trillions of operations per second where the portable path manages hundreds of billions, and the ANE lands at ~700 GFLOP/s with the highest dispatch overhead of the four — so on that machine the router never picks it. On a phone, where the NPU is the strong unit, the same measurement flips the answer. That is the entire doctrine in one sentence: the fabric does not assume what your silicon is good at — it measures, and the numbers decide.

03Guided practice

Step A (boot WebGPU): the Bench starts the real Ferric runtime on your tab's GPU and prints the backend it found (for example BrowserWebGpu on Apple silicon). Step B (watch the sweep): it times each matmul size on your GPU and your CPU. For the small sizes the CPU line (red) sits below the GPU line (green) — the CPU is faster, because the GPU's launch overhead dominates. Step C (the crossover): as the size grows the GPU line drops below the CPU line and stays there — at the largest size the GPU is many times faster. The router picks the winner at each size. Step D (the lesson): nothing about the code changed between sizes; the runtime measured your hardware and adapted. That is the smart heterogeneous fabric — and if your browser has no WebGPU, the Bench tells you so and explains that CPU-wasm is then correctly the only backend.

04Feedback

PASS WHEN PASS when the fabric has measured your device and routed each matmul to the faster backend — small to the CPU, large to your GPU.

If your run fails, check:

The Bench boots real WebGPU in your tab — give it a moment to compile the pipeline and sweep the sizes.
No WebGPU in your browser? That's fine — the Bench explains that CPU-wasm is then correctly the only backend.

05Retrieve & space

Why does the CPU beat the GPU for a tiny matmul, and the GPU win by orders of magnitude for a large one?
What two numbers does the router measure per device, and how do they set the crossover size?
Why is 'use the GPU when it is the right tool' a better principle than either 'always use the GPU' or 'no GPU needed'?
The Neural Engine is only added to the fabric when a compute-plan receipt confirms it runs the work. Why is that refusal-to-assume the right engineering doctrine?

06Mastery & project

You watched a real cross-fabric runtime measure your own device and route each workload to the silicon that wins on it. The full native fabric extends exactly this across four kinds of silicon — CPU, portable GPU, the GPU's tensor units, and the Neural Engine, the last admitted only on Apple's own scheduler receipt — and every routing decision comes from measurement, never assumption. That adaptive heterogeneous compute is the on-device foundation everything you built in this course stands on.

The models here are small, so they ran on your CPU — but the same fabric sends a large net, a batched training run, or a vision-language-action policy to your GPU automatically. Natively it goes further: an opt-in fast path routes big matmuls, quantized-model prefill, convolutions, and full training steps through the GPU's tensor units, and the dispatch layer chains a whole graph's work on the GPU so it pays one synchronization instead of one per op. This is the substrate for scaling physical AI on-device, zero-GPU-lock-in, from a phone to a workstation.

GO FURTHER · THE LIVE PLAYGROUND

Ferromotion — Ferric's sibling, on crates.io ↗ — the kinematics/dynamics/learning toolkit this course runs on — same one-source cross-fabric doctrine as the runtime you just watched route.

← The industry agrees: structure-as-differentiation, at scale The model meets reality →

PYTHON · NUMPY

Your device is a fabric

Live: the real Ferric WebGPU runtime in your browser, routing matmuls between your CPU and your GPU by measuring which wins on your device.

You read

the arrays and values already in scope

You change

the code you write in each cell

Fixed

the dataset and the checks that grade you