How RigCheck checks hardware

• Page updated 2026-10-22
• Sources checked 2026-10-20

RigCheck Lab is the name under which RigCheck publishes its checkers, data and corrections. This page explains how a checker reaches its answer, so you can check the answer yourself.

01Where the numbers come from

Each number on a checker page says who published it and whether it was measured or estimated, and the Sources list at the bottom of the page links to where it was read, with the date:

• Official: published by the model developer or the runtime project, in its repository, model card, documentation or announcement, such as the file sizes on a Hugging Face model page or a memory table in the runtime's guide.
• Community report: a published measurement by someone else, linked, with the hardware and settings it was measured on.
• Estimate: a number that was calculated rather than measured. The label says whose estimate it is: the developer's own (for example a speed it extrapolated from other cards) or RigCheck's, with the method written next to it.

Other calculators' numbers are never used as a source: they are formula estimates too, and copying them would hide where a number came from.

02Kinds of answer

Not every model can be checked the same way, so each checker says which kind of answer it gives:

• Capacity estimate (Qwen3.8-27B, Gemma 4, Mistral Medium 3.5): the memory math below, for llama.cpp and the GGUF files that exist. Qwen3.8-Flash-Next uses its own variant of it, described below.
• Published route match (for example Nemotron 3.5, GLM-5.3-Flash, FLUX 3 Klein, DeepSeek V4.1 Flash): the developer, a runtime or the publisher of the files states the hardware or memory a route needs, such as a memory table or a recipe for a named card, and the checker matches your hardware against those published routes. Some answers add RigCheck's own reading, such as which file a published memory range refers to, or file arithmetic where no figure is published, labeled as such.
• Engine's published requirements (Strata): the engine's documented minimums and its benchmark reports.
• Planning budget (Qwen-Image 2.1): image models load several files whose peak memory depends on the workflow, so the checker gives a labeled allowance, not a fit.
• Announced model (Mistral Large 4 until its weights ship): an estimate from the announced parameter count, replaced by real file sizes when the files are published.

03Memory math for llama.cpp models

The Qwen3.8-27B, Gemma 4 and Mistral Medium 3.5 checkers share one calculation:

1. The fileThe exact size of the GGUF file you pick, read from the repository's file list, not parameters × bits.
2. The KV cacheWorked out per layer from the model's config.json at your context length, following llama.cpp's own source code: a sliding-window layer caches its window plus one 512-token batch, but never more than the context rounded up to a multiple of 256 tokens (the cached length itself is rounded up the same way, as llama.cpp does), layers without attention cache nothing, and the cache is f16 unless you pick q8_0.
3. Smaller itemsRecurrent state for models that have it, a copy of the output weights where the file shares them with the input (for runs that use a graphics card or unified memory), the vision file when you turn on image input, compute buffers and 0.5 GB of host buffers. The buffer sizes are RigCheck assumptions stated on each page.
4. Usable memoryA graphics card keeps 8% of its memory for the driver and runtime; a PC keeps 8 GB of system RAM for the system and apps; a Mac or other unified-memory machine keeps 10%, at least 8 GB, for the system. On a Mac, giving the GPU that much needs its wired-memory limit raised, and the page says so.
5. PlacementWhole layers go on the graphics card until it is full, card by card; the rest runs from system RAM, which works but is slower. The input embeddings and host buffers stay in system RAM even when every layer is on the card.

Qwen3.8-Flash-Next keeps its own calculation: llama.cpp keeps its large n-gram table on the CPU side, where by default it can be read from the file as needed, and the checker conservatively counts the whole table in system RAM; it compares the rest with the combined memory of your graphics cards instead of placing whole layers card by card.

The result is a capacity check. It says whether the files and cache fit, not that a runtime has been tested with that model on that card.

04Why a parameters × bits formula can be wrong

A common shortcut multiplies the parameter count by the bits per weight and adds a fixed allowance. The files and runtimes show why that can be off in either direction:

• Files are not uniformly "4-bit". By that formula, 27 billion parameters at 4 bits is 13.5 GB; Unsloth's UD-Q4_K_XL file of Qwen3.8-27B is 17.6 GB. Q4 types store more than 4 bits per weight once their scales are counted (4.89 on average for Q4_K_M in llama.cpp's own measurement; see quantization names), and Unsloth's UD- files choose the type layer by layer. RigCheck uses each file's listed size.
• The KV cache depends on the architecture. In Qwen3.8-27B only 16 of the 64 layers cache keys and values for the whole context; the other 48 keep a fixed-size state. In Gemma 4 12B, 26B-A4B and 31B, the sliding-window layers cache at most 1,536 tokens with llama.cpp's default batch however long the context is (1,024 on E2B and E4B). A rule that gives every layer a full cache overstates the memory; one that ignores the context length understates it.
• Some buffers grow with the vocabulary. By RigCheck's arithmetic, the output (logits) buffer for a 512-token batch over Qwen3.8-27B's 248,320-token vocabulary is about 0.51 GB on its own (part of the buffer allowance stated on the model page as RigCheck's assumption).
• Not all memory is usable. The driver, the operating system and other apps keep part of it, which is why RigCheck compares against usable memory, not the number on the box.
• Fitting is not running. A runtime has to support the model's architecture on your hardware; memory arithmetic cannot show that.

05What the verdicts mean

• Fits: what the checker needs on the graphics card or in unified memory fits there; for llama.cpp models that is every layer and the output, while the smaller items listed above may still need system RAM.
• Published route match: a route published by the developer, a runtime or the publisher of the files names hardware like yours.
• With caveats: a capacity estimate, planning budget or route match that holds only under a condition the page states, such as part of the model running from system RAM, a raised Mac memory limit, a smaller context or a step nobody has verified yet. Whether it has actually been run is said in the answer's own notes.
• Experimental: a route exists, but as a community patch, an unmerged change, a file its own tools have not been tested with, or a platform the engine itself still calls experimental.
• Weights pending: the model is announced, but its files are not out yet.
• Does not fit: in a full checker, the file, context and hardware you picked do not fit; another file or a shorter context may. In the home page finder's quick answers, no file or route the quick mode checks fits. For a planning budget it means below the budget, not proven impossible.
• Not covered: no source covers this hardware, so the checker gives no answer rather than a guess.

Model pages whose models have published files also have a "Common setups" table with the checker's quick answer on eight fixed setups, from a GeForce RTX 3060 (12 GB) with 32 GB of RAM to a 512 GB Mac Studio; the same answers are published as JSON under /data/fit/ (see Data). Pages for models whose weights are not out yet have neither.

06Speeds

A speed (tokens per second, seconds per image) is labeled with what it is, and is never presented as a measurement of a setup nobody measured:

• Measured: an official or community measurement, shown with the model size, file, hardware and runtime it was measured on.
• RigCheck measurement: a run by RigCheck Lab itself (see below), shown only for the file, context and card it was run with.
• Published estimate: a developer's own extrapolation to other cards, labeled as its estimate with the margin it gives.
• RigCheck ceiling: on Mistral Medium 3.5, an idealized upper bound worked out from memory bandwidth for one request at a time with a short context and no speculative decoding, labeled as a RigCheck estimate, not a measurement.
• Nearest measurement: when no one measured your setup, a page may point to the closest measured one and say how it differs (another file, two cards). It is never adjusted by a formula and never shown as your speed.

Where no one has published a measurement, the page says so.

07Review and rechecks

1. Sources savedThe model card, file lists, runtime code and guides a page relies on are saved with the date they were read.
2. Independent reviewBefore a new page or a change to its numbers goes live, a second AI model reviews it against the saved sources: one from a different developer than the model that wrote the change where available, otherwise a separate read-only session that does not see the author's reasoning, and the review archive says which. Each confirmed mistake is fixed and gets an automated test so it cannot come back, then the reviewer checks again.
3. Daily source watchSources that can be watched automatically (repository changes, file sizes, the numbers on a page) are fingerprinted every day, and a change is queued until it has been checked against the page; changes to runtime source code, which moves daily, are sorted weekly. Sources the watch cannot follow, such as discussion threads, or cannot reach are rechecked by hand.
4. Shelf lifeThe target is to re-read a page against its sources every 30 days while it is new or being searched for, otherwise every 60 days; each week the pages closest to or past that date go first. Superseded pages that no one has found in 90 days are archived and no longer rechecked.

Where shown, "Sources checked" records when the numbers were last compared with their sources; "Page updated" records the last content change. Corrections are listed under "Recently updated" on the home page and in the update feed. To report one, see Corrections.

08RigCheck Lab

RigCheck Lab is the editorial name of this small independent project; it does not name its editor, so the method above, the dated sources and the published data are how you can check the work. How the project is funded and what may never change an answer is on the independence page.

RigCheck Lab also measures some setups itself, labeled RigCheck measurement. The first 24 runs (October 21, 2026) cover Qwen3.8-27B and Gemma 4 26B-A4B on an RTX 4090 and an RTX 4060 Ti 16 GB, each with the file the checker's quick mode picks for a card with that much memory at a 32K context, measured at about 4K and 32K context. How they are made:

• Rented cloud cards, one per run. Each card is rented by the hour on a cloud marketplace, Vast.ai; the record keeps the host's power limit, PCIe link, CPU and the memory allocated to it, because hosts with the same card differ.
• Pinned versions. One llama.cpp build (the project's own CUDA image) and one file revision, with the file's checksum; a newer build or file can be faster or slower.
• Three separate runs per setup, each one llama-bench process repeating its test three times. Pages show the lowest and highest of the three averages; every sample is in the data.
• Failures kept. A run that runs out of memory, fails to load or crashes is recorded as such and not quietly rerun. Only a GPU memory allocation error counts as "does not fit".
• Corrections in public. Once published, a record is never edited or deleted silently: a correction adds the date, the field, the old and new value and the reason, and a withdrawn record stays in the data marked as withdrawn. An automated check compares every published record with a snapshot of the published records, which may only grow or take appended corrections, and the public data repository on GitHub keeps every earlier version.

All records are in /data/lab.json under CC BY 4.0 (see Open data). Lab measurements are not adjusted to other files, contexts or cards, and they do not change a checker's answer; whether they agree with the checker's memory estimate is still being studied.