Get the app

Hardware detection - what the app really sees

How Abliteration reads your CPU, RAM, and GPU, why an integrated GPU is named but not used, and why some devices in Device Manager never appear on the Hardware screen.

Short answer

Abliteration reads your CPU, RAM, and every graphics adapter the operating system knows about on startup, on both Windows and macOS. It names whichever GPU the machine actually has, integrated Intel, AMD APU, discrete NVIDIA or Radeon on Windows, Apple Silicon or AMD on the Mac, and then decides whether it can accelerate on that GPU. On Apple Silicon the answer is “yes, through Metal” and the app runs the model on the GPU cores by default. On Windows, only modern NVIDIA cards qualify today, and every other adapter is named but reported as CPU-only. On Intel Macs, the app stays on the CPU path even when a discrete AMD GPU is present.

Some devices you might see in Windows Device Manager or in the macOS system report, USB dock display outputs (DisplayLink, Plugable), virtual displays (Parsec, remote-desktop adapters), the Basic Display Adapter, never appear on the Hardware screen. They are display sinks, not compute devices, and treating them as GPUs would be wrong.

Detailed explanation

What “GPU acceleration” means here. Abliteration’s inference runs on llama.cpp. On Apple Silicon Macs the Metal backend is on by default and the M-series GPU cores do most of the work, see Apple Silicon acceleration. On Windows and Intel Macs the app runs on the CPU today, with optional GPU backends planned (CUDA for NVIDIA, Vulkan for cross-vendor, see GPU roadmap). Until then, the only Windows GPUs the app can meaningfully use are modern NVIDIA cards with a driver branch >= 450; those get shown in green with their VRAM. Every other adapter is named in amber and paired with:

GPU acceleration is not available on this PC. Abliteration runs on your CPU.

That sentence is one string, deliberately the same for every non-usable case (integrated iGPU, older NVIDIA, discrete AMD, unknown adapter, no adapter). We don’t try to explain per-vendor why acceleration is absent - the honest answer, for now, is always the same: it’s a llama.cpp CPU pass on this hardware.

The “PCI bus” filter, on Windows. Windows Management Instrumentation returns every device that has a display driver, which includes some things that are not GPUs. A USB dock feeds pixels to a monitor over a USB-video protocol; a virtual display driver like Parsec’s is a software surface for streaming; the Basic Display Adapter is Windows’ fallback framebuffer. None of them can do the vector maths a language model needs.

Abliteration filters these out with a single rule: the device’s PNP DeviceID must begin with PCI\VEN_. Anything else, USB\, SWD\, ROOT\, VMBUS\, is dropped before scoring. This is why a Zenbook with a DisplayLink dock plugged in shows Intel Arc Graphics on the Hardware screen, not “DisplayLink USB Device”: the DisplayLink was filtered out, and the real integrated GPU won on its own merits. A virtualised guest (VMware, QEMU/QXL) does pass this filter, because those virtual GPUs sit on a synthetic PCI bus; they land in the same “acceleration not available” case as every other non-usable adapter, which is the truthful answer inside a VM.

GPU detection on macOS. The Mac build queries IOKit for the graphics adapter and Metal for compute capability. On Apple Silicon the answer is straightforward: the chip’s own GPU, unified memory, Metal on. On Intel Macs the app names whichever AMD or Intel adapter macOS reports, and stays on CPU for the reasons explained in Apple Silicon acceleration. External GPUs on Thunderbolt are named too, but not currently used, so they land in the same “acceleration not available” state.

The name we display. Windows drivers report their product name with trademark marks - Intel(R) Arc(TM) Graphics, NVIDIA(R) GeForce RTX 4070. Abliteration strips (R), (TM), (r), (tm) and collapses extra whitespace before showing the name. Intel Arc Graphics, not the literal WMI string. The rest of the name is kept exactly, because it identifies the part - Intel Arc Graphics is an integrated GPU and Intel Arc A770 is a discrete card, and those are different products.

How the “You can run” line is computed. Five tiers - 3B, 7B, 13B, 30B, 70B - each with a calibrated total-RAM need (3.5, 7, 12, 22, 50 GB respectively; these include weights + KV cache at 8K context + Windows overhead). Each tier gets a colour:

  • Green - fits in your CURRENT free RAM, will load right now.
  • Amber - fits in your TOTAL RAM once ~6 GB of headroom is available, so close some apps.
  • Red - won’t fit at all on this machine.

The colours reflect what will actually happen if you try to load that tier now, not what the sticker on your laptop says.

The 6 GB headroom. OS, browser tabs, IDE - all of that stays running while you use Abliteration. The 6 GB budget is subtracted from your total RAM before comparing to a tier’s need, so amber = “you have the RAM in principle, but only after freeing some”. Without headroom the number would be technically true and practically useless.

Why it matters

Two categories of user hit this screen with real questions:

  1. “I have an integrated GPU (Intel Iris Xe, Intel Arc, AMD Radeon Graphics). Why does it say acceleration is not available?” Integrated GPUs share system RAM with the CPU. Their memory bandwidth is roughly the CPU’s, not a discrete GPU’s, and the drivers are not on the CUDA path our current backend uses. Naming them keeps the detection honest - the app saw the hardware - but the app runs on CPU because that is actually faster for local LLMs on integrated graphics.

  2. “I have a discrete AMD Radeon RX / Intel Arc A-series. Why does it say acceleration is not available?” Same reason - the current backend only accelerates on CUDA-capable NVIDIA. AMD and Intel discrete GPUs will be usable when the Vulkan backend lands (GPU roadmap). Not now.

Both cases used to read no GPU for AI inference regardless of what was in the machine, which people fairly read as detection failure. Naming the card and explaining once, in one sentence, that acceleration isn’t available - answers “did you see my GPU?” with “yes, here it is” before it answers anything else.

In Abliteration specifically

Detection runs once per launch and is cached, except for the two numbers that actually change: free RAM and free disk. Those refresh every time you open the Hardware screen. Detection uses local OS APIs on both platforms and never touches the network.

The same detection code powers the first-launch popup, so the wording matches the Settings screen. The HTTP bridge’s /rig endpoint returns a superset of the same information for abliteration.org model pages to size their fit-check UI against your specific machine.

Catalog is the map. Apps are the tools.

Run models on your own machine, not in the cloud.

Every model page has an "Open in Abliteration" button that hands the model directly to the first-party desktop client, at the quantization your rig can actually run. No API keys, no subscription, no prompt leakage.

Get the app Browse the catalog
Open in Abliteration