PyTorch's shape,
in a browser tab.

Why borch

What disappears when the browser is the runtime

Python ML charges you before you start — virtualenvs, version conflicts, CUDA and cuDNN, and one more server in front if you want it on the web. borch deletes that line.

How it works

Four hops become two

What your platform asks for before this will run — nothing on macOS, iOS or Android, two Chrome switches on Linux with an NVIDIA card, and two cells still marked not measured. The page that carries the measurements, and what to do in each case, is here.

Learn · Tutorials · Models · Vision · API · Playground

Six ways in, all of them running

Read a lesson and press Run on the page you are reading. Look a name up and see the signature the compiler emitted. Or open the full editor with a loss curve and the GPU counters. Nothing to install for any of them.

All four are the same runtime. A lesson block, a tutorial block and the playground editor run identical code — the difference is how much of the page is prose and how much is yours.

Start the lessons → Or build something Check your GPU

Same kernels, Python surface

Run textbook code in the browser by changing one import

The playground has a Python mode. borch_webgpu on Pyodide calls the same WGSL kernels, so the losses match the JavaScript examples digit for digit. Pyodide and numpy are served from this repository — nothing leaves the page.

import borch_webgpu as torch

model = torch.nn.Linear(1, 1)
opt = torch.optim.SGD(model.parameters(), lr=0.1)
crit = torch.nn.MSELoss()

for step in range(201):
    with torch.scope():          # the one line the browser adds
        opt.zero_grad()
        loss = crit(model(x), y)
        loss.backward()
        opt.step()

The first run spends a few seconds loading Pyodide; after that it starts immediately. The Python page covers the surface in full — how it forwards names, what loading it costs, and where it stops. The playground carries five Python examples — tensors, autograd, linear regression, an MLP and a CNN — and lesson 6 runs the same training loop in both languages.

What exists · what does not

The long refusal list is the point

The goal is not "reproduce PyTorch" but equivalence within the range a curriculum uses. The table below is the current state, not a plan — what is missing is written as missing.

Four packages, one runtime

It is not one library any more

Each has a seat you already know, except the last one, which has no equivalent on the Python side.

The last row is the one with no counterpart. torch.hub fetches from repositories and keeps no catalog; timm has the catalog and does not publish manifests. Here a model arrives with a sample it has to reproduce, and your browser checks that before it says the model loaded.

Download a model and verify it →

It costs about ten megabytes and finishes in a couple of seconds. Nothing is installed.

Only what was measured

How fast · how correct

CIFAR ResNet-18, batch 64 — same machine, same bench

Measured again — 2026-09-03, same page, adapter named

borch-ts/test/compare.ts trains the same step in TF.js 4.22.0 (its own layers API and NHWC layout, WebGPU backend, bytes pinned by tests/browser/assets.lock) right after borch.ts on one page. Held equal: architecture, SGD 0.05/0.9, cross-entropy, the seeded batch, two warm-up steps then five timed, a loss readback every step. npm run compare:ts reproduces it.

The half this library loses — inference, same page

Same weights in both (one ResNet-18 exported from torch as safetensors and as ONNX by tests/browser/export_resnet18.py), WebGPU execution provider, and the table is printed only after both runtimes reproduce torch's logits to 1e-3 — measured Apple 7.5e-8 / 6.7e-8, NVIDIA 7.5e-8 / 4.5e-8. Forward pass, mean of twenty after three warm-ups, readback included. The eval-mode batch norm is one kernel now, and nn.utils.fusion.fuse_conv_bn_eval (torch's own name) folds each norm into the convolution before it — 176 → 56 dispatches a forward; before those two the table read Apple 9.9 / 18.8 ms and 4090 6.7 / 14.5 ms. The third was the convolution kernel — its grid, not its arithmetic: 512 → 512 channels on a 4 × 4 plane is 32 workgroups at batch 16 and 8 at batch 1 on a card with 128 SMs (about 1 % of peak), against a reduction 4,608 long. The forward now splits that reduction as the weight gradient already did (convForwardSplit), and the layer's GPU time went from 2.8 to 0.3 ms at batch 1. The fourth was the calls themselves — 64 dispatches for 3.0 ms of GPU work in the 4090's 5.6 ms — so the relu and the residual add now ride in the convolution's epilogue, torch's torch.ao.nn.intrinsic names (ConvReLU2d, ConvAddReLU2d, here nn.intrinsic): 39 dispatches, 5.6 → 4.6 ms. At batch 1 the fused network is ahead of ORT on both adapters; at batch 16 it is within 1.3–1.5×, and what is left is the early layers, where a 64-channel 32 × 32 convolution reads more than it multiplies. And the file leaves as ONNX: onnx.exportOnnx(model, sample) (torch.onnx.export in the Python binding) traces one forward and writes the file ORT Web runs — checked at 3.5e-8 against our own forward, at a batch it was not traced at too. On this page it is the fused network's own export that ORT runs: 4.5e-8 from torch's logits on Apple and 5.2e-8 on the 4090, at 3.1 / 5.3 ms and 3.2 / 3.4 ms — the same speed as the file torch exported. For inference alone, use ORT Web; what this library has that it does not is the training step above and torch's own shape of code.

One machine, and it is not written down here. The three columns can be compared with each other because they were timed against each other on the same box — they cannot be compared with anyone else's, because nothing on this page says which box it was. Correctness is measured on two vendors now; speed is one machine, so until this line can name it, read the columns as a ratio rather than a speed.

The two right-hand columns are the same kernels — the 4.9ms gap is the cost of passing through Python (Pyodide) once. The hand-written WGSL beat the TF.js version on the same bench and had no rank limit, which is why that version is gone.

Checked against real PyTorch

On top of that, 4744 golden cases hold all three implementations to the same expected values. Real torch cannot run in a browser, so the expectations are frozen natively and carried in. Golden matches on Apple Metal — agreeing 4733 / 4733 [apple / metal-3] — and on NVIDIA too: 3880 / 3880 [nvidia / blackwell] on an RTX 5080, in a real desktop session rather than a virtual framebuffer, measured on 2026-08-30 when the table held 3880 through the binding. The training agrees as well: thirty steps of a small ResNet, its per-layer gradients, its batch-norm buffers and its eval, against torch — 64 values, once through the Python binding and once through borch.ts's own API. The run that was read as a second vendor for months was not one. It passed 845 of 845 on a Linux GPU server whose adapter reported google / swiftshader — the CPU. The values were right and the vendor claim was not, which is why the runners now judge the adapter instead of printing it.

Five packages, and three of them share this name

Pick by where you intend to run

The first row said borch (PyPI) until it was checked. The distribution is named pyborch; borch is what you import. And it is not on PyPI — borch there is somebody else's package, a probabilistic-programming library, so pip install borch fetches a stranger's code. The wheel below is the install.

The npm row said borch too, and that package did not exist — the registry refused the name for being too close to borsh, batch and touch. It is published as borch-ts, which is what this repository has called it all along.

npm install borch-ts

import { init, Tensor, nn, optim, scope, keepAlive } from "borch-ts";
await init();

uv add ./pyborch-1.4.0-py3-none-any.whl

import borch as torch          # changing the import is the whole change
import borch_webgpu as torch   # on the GPU, inside Pyodide

Build AI where your users already are — in the browser.

No install, no server, no account. One tab is enough.