LLM GPU Benchmark

GPU LLM benchmark: measure your own graphics card in the browser

Most GPU comparisons for local AI are estimates derived from specification sheets. This one is not — it runs a real workload on the GPU in front of you and reports what it measured. There is nothing to install: the test uses WebGPU, takes about ten seconds for the first stage, and optionally goes on to load a genuine language model into the browser and time it generating tokens. It works on NVIDIA, AMD and Intel cards, on Apple Silicon, and on integrated graphics, which makes it a practical way to answer "how does an AMD GPU actually do at LLM inference" without buying one first and without trusting a vendor's slide.

What is measured and what is estimated — the important distinction

The tool produces three kinds of number and labels them differently, because conflating them would make it useless:

• Measured on your hardware. Stage 1's memory bandwidth in GB/s and compute throughput in GFLOPS, and Stage 2's real decode and prefill rates in tokens per second. These come from timing actual work on your GPU.
• Measured by other people. The community leaderboard, aggregated from submitted results.
• Calculated. The table of predicted speeds for models you did not download. These are extrapolated from your measured bandwidth and are estimates, presented as such.

The tool is also careful about a fourth thing it does not claim. Matching your measured bandwidth against known hardware produces a "performs like" comparison, never an identity claim. Only the browser's renderer string can say what card you have; a bandwidth figure can only say what your card performs like.

Stage 1: the micro-benchmark

The bandwidth test dispatches a WebGPU compute shader across 65,536 invocations that stride through a large buffer — up to 512 MB, or as much as your device's storage-buffer limit allows — summing four-wide vectors. The buffer is deliberately far larger than any cache, so the numbers reflect real memory traffic rather than cache hits. The compute test does the opposite: a tight loop of fused multiply-add operations with no memory traffic at all, measuring FP32 throughput in GFLOPS. WebGPU has no portable FP16 compute path, so FP32 is what can honestly be reported.

Both stages run a warm-up pass first to compile the pipeline, then iterate for at least five seconds and at least five samples, and report the median. That design is intentional. A short burst test flatters a GPU — turbo clocks are highest in the first moments and caches are cold in a helpful way — whereas LLM inference is a sustained workload that settles into steady state. The median across a five-second run is closer to what you will live with.

These two measurements map directly onto the two halves of inference: bandwidth governs token generation, which reads all active weights and the KV cache for every token produced, and compute governs prompt processing, which runs the whole prompt through in parallel. A card can be strong at one and weak at the other, and this is where you find out which.

Stage 2: a real model, really running

The second stage is optional because it involves a download. It loads the WebLLM runtime from a CDN, lists the small instruction-tuned models WebLLM ships that need under roughly 1.6 GB of VRAM, and lets you pick one — typically something in the 0.5B to 1B range, a few hundred megabytes, cached by the browser for repeat runs. It then runs a warm-up generation to compile the GPU kernels, and times a fixed 256-token completion from a fixed prompt. Where the engine exposes its own instrumentation, those decode and prefill figures are used in preference to wall-clock timing.

This is a real measurement of real inference on your machine. It is also a browser measurement, which is not identical to what Ollama or llama.cpp will give you natively — more on that below.

The accuracy self-check

Run both stages and the tool does something unusual: it checks its own methodology in front of you. It takes the Stage 1 bandwidth, predicts what decode speed that implies for the model you just ran, and compares the prediction against the measurement. Agreement of 65% or better is reported as trustworthy; 40–65% as moderate, with predictions to be treated as rough; below 40% as a sign that something is interfering — another application using the GPU, thermal throttling, or a driver problem. If the two numbers disagree badly on your machine, the extrapolated table below them is not to be relied on, and you are told so rather than left to assume otherwise.

Stage 3: what it means for models you have not downloaded

The predictions table applies the memory-bound decode relationship to fifteen popular models at Q4_K_M and 8,192 tokens of context, using each model's real architecture for the weight and KV cache byte counts. Two adjustments are worth understanding, because they are the difference between an honest estimate and an optimistic one:

Each predicted model is also checked for fit against your GPU's known memory, so the table separates "this would be fast" from "this would not load". Those two questions have different answers more often than people expect — a mixture-of-experts model reads few parameters per token and generates quickly, but still has to be held in memory in full.

Comparing across vendors, including AMD and Intel

Cross-vendor LLM benchmarks are usually confounded by software. An NVIDIA card is measured through CUDA, an AMD card through ROCm or Vulkan, an Intel card through SYCL or OpenVINO, and the maturity of those stacks differs enough that you end up comparing runtimes rather than silicon. A WebGPU benchmark sidesteps that: every vendor runs the identical shader through the same browser API, so the bandwidth and compute figures are a genuinely like-for-like measurement of the hardware.

That is a strength and a caveat at the same time. It tells you what an AMD or Intel card is capable of in bytes per second, which is the quantity that governs token generation. It does not tell you how well your chosen native runtime exploits it — and for non-NVIDIA hardware the gap between capability and what llama.cpp or Ollama actually delivers is the real variable. Read the measured bandwidth as the ceiling and the software stack as the thing that decides how close you get to it. This is also why the browser-to-native uplift is applied conservatively to integrated graphics: an earlier, more optimistic factor produced predictions for Intel integrated users that the hardware could not possibly meet.

The hardware dataset behind the "performs like" comparison covers NVIDIA from GTX 10-series through B200, AMD Radeon consumer cards and MI300X, Intel Arc, every Apple Silicon tier, and plain CPU inference on DDR4 and DDR5, so a match is usually available whatever you are running.

The community leaderboard

Results can be contributed to a shared leaderboard that ranks hardware by measured bandwidth and, where Stage 2 was run, by measured decode speed per model. Submission is opt-in and anonymous: the tool shows you exactly what would be sent — and offers the raw payload for inspection — before anything leaves your browser. Raw IP addresses are never stored; a salted hash is kept purely to rate-limit submissions to five per hour. The dataset is shared with sibling sites that embed the same tool, so the sample is broader than one site's traffic.

Aggregate community numbers are a useful sanity check on your own run: a card sitting well below its peers usually means background GPU load, a battery-saver power profile, or thermal throttling in a laptop chassis. Bear in mind the leaderboard reports averages across submissions of varying quality — it is a comparison aid, not a controlled review.

Getting a clean run

• Close other GPU-heavy applications and tabs. Video calls, games and even a hardware-accelerated video playing in another tab will depress the result.
• On a laptop, plug in. Battery power profiles cut GPU clocks substantially, and the tool records whether you were on battery when you submit.
• Let the machine cool between runs if you are comparing configurations. Sustained tests are designed to catch throttling, which means back-to-back runs will show it.
• Use Chrome, Edge, or Safari 18 or newer. If no WebGPU adapter is available the tool says so explicitly rather than silently guessing.
• If hardware acceleration is disabled in your browser, the GPU is hidden from every website and no measurement is possible — the tool distinguishes this from simply failing to recognise the card.

Honest limitations

The most important one: a browser benchmark is not a native benchmark. WebGPU sits above the driver, cannot use FP16 or INT8 compute paths portably, and cannot reach the tensor-core kernels that CUDA-based engines use for prompt processing. Measured bandwidth transfers reasonably well to native decode speed, which is why the extrapolation is built on it; the compute number is best treated as a relative comparison between GPUs rather than an absolute FLOPS rating for llama.cpp or vLLM.

Stage 2 is limited to models small enough to load in a browser tab, so it cannot tell you directly how a 70B behaves on your card — that is what the extrapolation is for, with the accuracy self-check as the guard against trusting it blindly. And every number here is single-stream. Batched serving with vLLM changes throughput characteristics entirely.

If you want the memory question rather than the speed question — whether a given model fits at all, at what quantisation, and at what context length — the results link through to the VRAM calculator, the inference speed calculator, and the hardware-first model shortlist with your measurements already carried across.