Back to home

How Can I Run AI works

Methodology, assumptions, data sources, and limits behind our local AI model compatibility estimates.

Last updated: 2026-10-19

What the checker answers

Can I Run AI estimates whether a local AI model fits on a selected GPU or Apple Silicon device, the likely generation-speed range, a safe context length, and the most practical runtime. It is a planning tool: use it before downloading a large model, then confirm with the runtime on your own machine.

V1 currently displays text-generation models. The catalog structure is designed to support embedding, reranking, speech, transcription, image, and video models later, but those categories are not shown until their estimates are useful enough.

Hardware detection and selection

On first visit, the browser tries WebGPU adapter information and then a WebGL renderer string. Browser privacy controls often reduce or hide these details. navigator.deviceMemory, when available, is only a coarse system-memory hint.

Detection runs locally. The raw adapter or renderer label is displayed only so you can verify it; it is not included in a share snapshot. You can select a known profile or enter custom accelerator memory, system memory, and bandwidth at any time. The confirmed profile—not a hidden fingerprint—is what drives the estimate.

The catalog contains desktop and laptop NVIDIA RTX generations, Apple Silicon memory variants, experimental AMD and Intel profiles, and a CPU fallback. Laptop GPUs with the same product family can vary by power limit, so their speed ranges are intentionally wider.

Memory estimate

Every result adds three components:

  1. Model weights — parameter count × effective quantization bits, plus a small file/runtime allowance. Models published only in a native low-bit format use the size of the official checkpoint instead.
  2. KV cache — computed from the model architecture: 2 (keys and values) × attention layers × KV heads × head dimension × 2 bytes per token, matching the default f16 cache. Full-attention layers grow with the whole context, sliding-window layers stop growing at their window, and linear-attention or Mamba layers keep a small fixed state instead of a cache. Multi-head latent attention (MLA) models cache one compressed latent per layer (kv_lora_rank + qk_rope_head_dim). If a model has no architecture details yet, a size-based fallback is used and the result's confidence drops one level.
  3. Runtime overhead — buffers, temporary allocations, and runtime bookkeeping.

The selected context is capped at the model's native window, and a "max" badge marks results where that happened. The detail view also shows the longest context that still fits your hardware with the current settings.

Usable memory depends on the kind of hardware:

  • Discrete NVIDIA, AMD, and Intel GPUs — VRAM minus about 0.5 GB for the display and driver. When a model does not fit, offloaded weights can use up to 75% of system RAM after a 4 GB operating-system reserve.
  • Apple Silicon — one unified pool. macOS lets the GPU use about 75% of it by default, so that is the budget. Between 75% and about 85% the result is a tight fit that needs a raised iogpu.wired_limit_mb; beyond that it won't fit. There is no separate offload tier.
  • CPU only and integrated graphics — system RAM minus about 4 GB for the operating system, also without an offload tier.

The four fit labels mean:

  • Runs comfortably — the estimate fits with at least 20% headroom in that memory pool.
  • Tight fit — it fits, but background GPU use or longer prompts can cause allocation failures. On a Mac it may also need the raised wired-memory limit described above.
  • Runs with offload — discrete GPUs only: some weights live in system memory, usually with a substantial speed penalty.
  • Won't fit — the estimate exceeds the usable pool, plus system-memory spill on discrete GPUs.

Quantization and precision

The checker lists Q4_K_M, Q5_K_M, Q8_0, BF16, FP8, and NVFP4. Q4 is usually the best starting point for limited memory. Q5 uses more memory in exchange for better quality retention. Q8 is close to the original weights. BF16 represents the original 16-bit weights and can be useful on very large-memory machines. FP8 requires supported NVIDIA Ada, Hopper, or Blackwell hardware. NVFP4 requires NVIDIA Blackwell hardware.

All choices remain visible. Unsupported hardware-specific formats are disabled with a reason instead of being hidden. Memory capacity alone does not make a GPU support FP8 or NVFP4: the required compute architecture and runtime kernels must also exist. File formats and kernels vary between runtimes, so the numbers are normalized planning estimates, not a promise that every repository exposes every precision artifact.

Speed estimate and runtime

Speed is a range, not a benchmark. Generating a token is mostly limited by memory bandwidth: each new token reads the active weights (only the routed experts for mixture-of-experts models) plus the KV cache. The estimate divides those bytes by the hardware's memory bandwidth and applies a runtime efficiency factor. With offload, the time per token is split: the part kept on the GPU is read at VRAM bandwidth and the offloaded part at system-RAM bandwidth, which defaults to 60 GB/s (roughly dual-channel DDR5) when the hardware profile does not state it. Results that won't fit show no speed. Prompt processing and token generation are different workloads; the displayed range primarily represents interactive token generation after the prompt is processed.

The precision you pick names a file format, so the runtime must be able to load it. GGUF quantizations (Q4_K_M, Q5_K_M, Q8_0) use Ollama or llama.cpp on every platform, Apple Silicon included. MLX builds have their own bit widths, so they are offered as an alternative command rather than labelled with a GGUF name. BF16 uses MLX on Apple Silicon and Transformers elsewhere, FP8 uses vLLM, and NVFP4 uses TensorRT-LLM. For models that fit, the detail view lists copyable commands for Ollama, llama.cpp, LM Studio, and (on a Mac) MLX, built from verified repository names. Driver versions, kernel support, thermals, power limits, and concurrent workloads can move real performance outside the estimate.

Arena quality ranking

When an exact model-version match exists, the list also shows its open-source rank, score, and vote count from the public Arena Text Leaderboard dataset. Arena measures anonymous human preference, not local speed. Unmatched or ambiguous versions stay unranked rather than inheriting a nearby model's score.

The snapshot currently uses Arena data published on 2026-07-10. The dataset is released under CC BY 4.0; the UI links to the filtered Arena leaderboard and identifies the publication date.

Catalog evidence

Each model records its source URL, retrieval date, and confidence. Sources favor official model cards and publisher repositories. Parameter counts, context limits, licenses, and commercial-use terms are catalog facts. Memory and speed are calculated estimates, and the detail view keeps those two kinds of information visibly separate.

Catalog and evaluation-engine versions appear with every result. Shared pages freeze the inputs, results, model identity, and evidence metadata from the time the link was created; they are not recalculated when the live catalog changes.

Interpreting a result safely

Leave extra memory for the desktop, browser, and other applications. Start with the recommended Q4 model and a shorter context, close GPU-heavy applications, and test a representative prompt. For business use, follow the linked model license and verify its current terms with the model publisher.

This tool does not execute third-party models, inspect files on your computer, or guarantee model quality, accuracy, safety, or legal suitability.