The AI Performance You Actually Get

LynxBenchAI is an AI hardware benchmark you install and run yourself, together with the methodology behind it. It measures performance as a property of the complete hardware-and-software stack, sustained inside a declared measurement window, reported per precision, under a bounded optimisation budget. A run produces four scores — Training, Inference, Compute, and GT — and submits them to a public leaderboard. The Personal Edition is released and free for non-commercial use.

pip install lynxbench-ai on Python 3.11 or later, on Linux or on Windows through WSL2. A run needs roughly 15 GB of free disk, downloads about 2 GB of model data once, and takes 15 to 30 minutes. It runs on NVIDIA GPUs through cuda, AMD GPUs through ROCm on that same path, Intel GPUs through xpu, and on CPUs. Read the install guide →

Training, Inference, and Compute are category scores, each meaningful on its own as how well that AI Executor handles that class of work. GT is an ordinal aggregate of the three, weighted 0.4 for Training, 0.4 for Inference and 0.2 for Compute. GT is unbounded and carries no reference-device normalisation, so it implies no 0–100 scale. Read the category that matches your workload first; a device that trains badly and infers well shows up as exactly that rather than being averaged away. The derivation is in the LynxBenchAI methodology.

26Q3 is the name of the current release; the next one is 27Q1. A release fixes the model catalogue, the precisions, the correctness thresholds, and the scoring formula, and every result carries the name of the release that produced it. Scores are comparable within a release name and not across release names, because the thing being measured changed. There is no fixed release cadence and none is promised.

Publicly available software, and only publicly available software. The benchmark installs a declared environment built on mainstream PyTorch, and a submitter may diverge from it — an optimised build, a newer driver, a different runtime — provided every component is a version anyone can obtain and install. A build produced for LynxBenchAI, or tuned against it and shipped to nobody else, falls outside the methodology. This is a declared rule rather than a technically enforced one: the submission record captures the driver, framework, and runtime a result ran on, which makes the rule auditable after the fact, but nothing in the client prevents a non-public build from being used.

Because the two measure different things. A vendor figure is generally the best result obtainable from a stack tuned for that workload on that device, quoted at its peak. A LynxBenchAI figure is what a publicly available stack does on a machine in the state it is actually in, sustained across a timed window rather than caught at its best instant, under constraints applied identically to every device on the board. Comparability is bought by giving up maximality: the number comes out lower, and it is much closer to what you will see before anyone has tuned anything. Peak vs steady-state performance →

Four things, all at the method level. The model catalogue is held small enough that a laptop CPU and a data-centre accelerator can attempt the same work and each be measured at its own saturation point, so they share one scale rather than sitting in separate tables. Nothing enters that catalogue unless it already runs on at least two vendors' stacks, and the models are prepared before any target device is known, so a vendor-specific path has nowhere to exist. A failed or unsupported workload is scored zero and stays in the aggregate, so omissions cannot help a device. And every result is bound to the whole stack that produced it rather than to the silicon. Why benchmarks mislead procurement →

It is built and funded by TechnoLynx, and is not commissioned by or produced on behalf of any hardware vendor. Its founder, Balázs Keszthelyi, was lead programmer of CLBenchmark, later CompuBench CL — the cross-vendor OpenCL benchmark published from 2010 — and several vendors corrected non-compliant OpenCL implementations in response to it. He sat on the Khronos OpenCL and SYCL working groups and is a named contributor to the SYCL specification.

Every result is signed by the released LynxBenchAI client, and the collection server accepts a submission only when its signature matches that release's exact build — establishing that the payload came from the released client, not a hand-edited results file or an outside build. It does not establish that the machine behind it was representative; an operator who controls their own hardware can still submit a faked or freak result, which is what the surrounding population of runs for that device is there to expose, not the signature alone. Some entries, typically for less common devices, are measured directly by TechnoLynx on rental hardware rather than contributed externally; those pass through the identical signed pipeline, with no separate path. See what a submission does and does not establish →.

On the leaderboard, ordered by GT with a full drill-down to category, precision, and method for every entry. Runs submit automatically, so the board grows as people measure their own machines, and a device's absence from it is itself visible information. If there's a specific device you want measured, tell us about your hardware →.