gpuemu
Catch silently-wrong CUDA/Triton kernels before they ship — a GPU-less correctness oracle that finds the bugs a single-shape torch.allclose check misses.
Overview
gpuemu targets a failure mode that is becoming common as models write more GPU code: a kernel that is not obviously broken. It compiles, it runs, it produces numbers in the right shape, and a single-shape comparison against a reference implementation passes. The error appears only at particular sizes, particular reduction lengths, or particular numerical regimes, and it reaches production as a quality regression nobody can attribute.
The oracle catches these without a GPU. A double-precision reference computes what the kernel should produce. Adversarial input generation is schema-aware, so it knows that a matrix multiply and an attention kernel have different edge cases and constructs inputs that probe tail masks, accumulator scales, and the rescaling logic in online softmax. Tolerances are calibrated per operation rather than set globally, because a tolerance loose enough for a long reduction hides real bugs in a short one. A static lint pass over PTX and SASS catches a further class of problem before anything is executed.
Running without a GPU is the property that changes where this fits. Validation belongs in continuous integration, and continuous integration runners do not have accelerators. A correctness check that requires the hardware it is checking runs after the merge, on somebody's workstation, sometimes. One that runs on an ordinary runner blocks the pull request instead.
Failures replay byte-for-byte from a seed, which turns "the fuzzer found something" into a reproducible test case a developer can attach to a fix. Without deterministic replay, adversarial testing produces reports that cannot be acted on, and engineers learn to ignore them.
On the evidence: on an extended 26-operation corpus measured across five GPU classes, the standard one-shape check accepts all ten deliberately-buggy LLM-style kernels as correct, while the seeded oracle catches ten of ten with no false positives on sixteen correct controls (nine of nine on the 24-operation single-GPU corpus). That is a small and deliberately-constructed set, and it is reported as what it is rather than as a general accuracy claim; it says nothing about bug classes the corpus does not contain.
Where it loses: gpuemu checks correctness, not performance. A kernel that is exactly right and four times slower than it should be passes cleanly, and nothing here will tell you that. KernelBench and TritonBench measure performance and are the complementary tools. The reference oracle is also slower than the kernel under test, which is fine for a CI gate over representative shapes and wrong for exhaustive validation of a production workload.
The workflow this is designed for is a pull request that changes a kernel. The oracle runs on an ordinary runner over a set of shapes chosen to exercise the operation's known edge cases, reports a failing seed when it finds one, and the developer reproduces the failure locally from that seed without needing the accelerator either. That loop is the whole product; everything else — the fuzzer, the tolerance calibration, the PTX lint — exists to make it produce actionable output rather than a noisy report people learn to skip.
Primary use case
Catch silently-wrong LLM-generated GPU kernels in CI without access to a physical GPU.
How it compares
gpuemu is one option in a category that includes torch.allclose, KernelBench , and TritonBench. Our Compare page has the full side-by-side.