KoutuxiaHow much faster is WebGPU than WASM for in-browser background removal? 489 real-device timings
Koutuxia's free background removal downloads the AI model into your browser and runs it there, so images are not uploaded to our server. Every timing on this page comes from that production code path, and the raw summary is downloadable from the benchmarks page.
Most WebGPU vs WASM background-removal comparisons online are a single number from one high-end computer. Koutuxia's model runs in the visitor's own browser, and its timing telemetry is bucketed by execution backend and device class, so we can publish a cross-device table instead. The short answer: on the same machine with the same image, WebGPU inference really is several times faster. On real visitors' devices, a first cutout also pays for runtime loading and warm-up, so the gap is smaller. More importantly, the WebGPU backend in ONNX Runtime Web 1.27 produced wrong results with our int8 weights, so since September 13, 2026 production runs on WASM only.
Same machine, same image: WebGPU inference was about 6× faster, and wrong
On September 13, 2026 we compared both backends in a browser on our development machine (Apple M4, 16 GB), using the same 1024-input int8 model, the same image, and the same page: WASM inference took 16.8 s and WebGPU 2.8 s. The same model with fp32 weights on WebGPU took 3.7 s.
Speed was not the problem; correctness was. With int8 weights on WebGPU the lowest output logit was only −5.34 (WASM: −20.70), background confidence collapsed, and the share of pixels with alpha ≤ 0.05 fell from 76.0% to 2.2%. fp32 on WebGPU matched WASM, so the fault was the int8 DequantizeLinear path in the ORT-web 1.27 WebGPU backend, not WebGPU itself.
In finished cutouts — 7 opaque objects from the AIM-500 dataset, production build, real browser, scored against ground truth — WebGPU at 1024 had a median SAD of 6.15 against 1.10 for WASM at 1024, and WASM won on all 7 images. We disabled WebGPU the same day.
How WASM got the speed back
Part of WASM's slowness was also the int8 weights, because dequantization adds a layer of work. After switching to fp16 weights, 1024-input inference on the same image dropped from 16.8 s to 6.95 s, about 8.0 s end to end — level with the 6–8 s users had been getting on WebGPU — with quality back at a median SAD of 1.10.
So the answer here is not “WebGPU is faster, pick WebGPU”. When you run a quantized model in the browser, check that WebGPU output matches WASM value for value before comparing speed. Our condition for re-enabling WebGPU is fp16 weights that match WASM in a real browser; as of the September 13 notes the fp16 conversion was stuck on a mixed-type Conv, and WebGPU is still off in production.
The distribution on real visitors' devices
The table below is the telemetry's “first cutout” phase, from pressing the button to getting a result, including decoding, preprocessing, inference, and compositing, split by backend, device type, and CPU core bucket. All WebGPU rows were recorded from September 8 to 12, before it was disabled, with a 768 input; most WASM rows use a 512 input. Because the input sizes differ, this is not a strict like-for-like comparison.
A few things stand out. WASM first cutouts on 8–11-core desktops have a p50 of 2.1 s (72 samples) but a p95 of 10.2 s, so machines in the same bucket vary a lot. WebGPU on 4–7-core desktops had a first-cutout p50 of 14.3 s (3 samples), with session creation alone taking 8.5 s. Where WebGPU shines is warm runs: later cutouts on 8–11-core desktops had a p50 of 1.6 s (3 samples).
On phones, WebGPU first cutouts had a p50 of 12.2 s (2 samples), single-threaded WASM 44.1 s (2 samples, 768 input), and multi-threaded WASM 4.1 s (5 samples, 512 input). On a phone, whether WASM can use several threads matters more than which backend you pick.
What this data cannot tell you
The browser buckets the device (desktop or mobile, CPU core range) before reporting, the raw User-Agent is never collected, and samples are not deduplicated. So we can count samples but not devices or phone models, and one person cutting out ten images contributes ten samples.
Since September 13 the default tier has been WASM with 1024 fp16 weights, and that tier is not yet included in the telemetry summary, so the table does not show how today's default performs on real devices. A baseline run on the fixed sample set is also still pending. We will update this page when both are in.
First-cutout time (real-device telemetry, Sep 8 – Oct 11, 2026)
| Backend · device · CPU cores | Model input | Samples | p50 | p95 |
|---|---|---|---|---|
| WebGPU · desktop · 12+ | 768 | 2 | 4.7 s | 7.4 s |
| WebGPU · desktop · 8–11 | 768 | 1 | 4.8 s | single sample |
| WebGPU · desktop · 4–7 | 768 | 3 | 14.3 s | 17.2 s |
| WebGPU · phone · 8–11 | 768 | 2 | 12.2 s | 12.3 s |
| WASM · desktop · 12+ | 512 | 33 | 3.6 s | 9.7 s |
| WASM · desktop · 12+ | 768 | 1 | 6.1 s | single sample |
| WASM · desktop · 8–11 | 512 | 72 | 2.1 s | 10.2 s |
| WASM · desktop · 4–7 | 512 | 3 | 11.3 s | 14.6 s |
| WASM · desktop · 1–3 | 512 | 6 | 5.2 s | 6.4 s |
| WASM · phone · 8–11 | 512 | 5 | 4.1 s | 5.4 s |
| Single-threaded WASM · phone · 8–11 | 768 | 2 | 44.1 s | 44.9 s |
Source: the benchmarks data endpoint, exported October 14, 2026. p50/p95 are computed over raw samples in the window, not averaged from daily percentiles. Rows under 30 samples only indicate order of magnitude. All WebGPU rows predate the September 13 shutdown.
Reproduce it on your own device
Step 1 · Open the benchmarks page
It lists all five phases — model download, cache hit, runtime load, first cutout, and later cutouts — with JSON / CSV downloads of the raw summary under CC BY 4.0.
Step 2 · Cut out one image in a foreground window
Browsers throttle background tabs, which makes timings far slower. Keep the window in front, the machine idle, and DevTools' Network panel open.
Step 3 · Read the numbers in the telemetry request
When your session is sampled (20% of sessions), the page posts its timings to /api/benchmarks/collect; that payload holds the first-cutout and pure-inference times, measured the same way as the table above.
Who this data is for
- ·Developers shipping ONNX models in the browser and choosing between WebGPU and WASM
- ·People who want to know how long a cutout takes on their own laptop or phone
- ·Writers who need cross-device measurements rather than a single-machine benchmark
- ·Teams checking whether no-upload, in-browser background removal works on low-end devices
FAQ
Is WebGPU background removal always faster than WASM?
For pure inference on the same machine and image, we measured 2.8 s on WebGPU against 16.8 s on WASM (int8 weights). A first cutout also includes runtime loading and warm-up, though, and on real visitors' desktops WebGPU first cutouts had a p50 between 4.7 s and 14.3 s (6 samples in total), so it is not always faster. The advantage is clearest on warm runs.
Why doesn't Koutuxia use WebGPU now?
The WebGPU backend in ONNX Runtime Web 1.27 computes int8 weights incorrectly: background confidence collapses, giving a median SAD of 6.15 against 1.10 on WASM. Since September 13, 2026 production runs on WASM only, and with fp16 weights a 1024-input cutout takes about 8 s end to end.
Why are there no specific device models in the table?
Telemetry only reports coarse device buckets and never the raw User-Agent, so we cannot tell models apart or count devices. That is the cost of the privacy design, and we would rather lose that dimension.
Are my images uploaded?
Not on the free local path. The model runs in your browser, and telemetry sends only timing numbers and device buckets — no images, file names, or anything derived from the image. You can also switch it off at the bottom of the benchmarks page.