Discrete GPUs are pricey — can an iGPU actually run LLMs, and how big can they get? I spent a day on an Intel Arc 140T (12GB iGPU + 23.5GB shared RAM) and put two representative Gemma 4 models — E4B and supergemma4-26B — through downloads, environment setup, a five-backend benchmark, VRAM tuning, serving, and the official OpenVINO GenAI route. Bottom line: an iGPU can not only run LLMs, but a full 26B fits entirely in the iGPU — with the right flags.

Env: Windows (RDP) / Intel Arc 140T iGPU / 23.5GB RAM / llama.cpp b10621 (Vulkan, SYCL, OpenVINO, CPU) / llama-bench pp512·tg128, 8 threads. Tested 2026-09-01~02.

Two models, two fates

An iGPU has no VRAM of its own — it borrows system RAM (shared memory). Whether a model runs, and how fast, hinges on whether it fits the iGPU's usable memory budget.

E4B at 4.6GB fits the iGPU entirely — born iGPU-friendly. The 26B is a 15.63GB beast that the default 13.4GB budget cannot hold — and that is exactly the valuable part here: after tuning VRAM, the full 26B offloads successfully.

E4B: full five-backend numbers

Three findings worth unpacking:

• Decode is fastest on Vulkan at 20.3 t/s, SYCL second at 16.4, and native CPU beats OpenVINO CPU (14.9 vs 8.8)
• Prefill on OpenVINO GPU crushes it: 1667 t/s — 4.4× Vulkan, 20× native CPU
• Yet OpenVINO GPU decodes slowest (12.5 t/s) — it shines for prompt-heavy workloads; for chat/decode, Vulkan is the balanced pick

The 26B: struggling before VRAM tuning

At the default 57% shared memory the iGPU budget is only 13.4GB, and full offload of the 15.63GB 26B fails everywhere — Vulkan OOMs (OutOfDeviceMemory), SYCL dies as layer count rises (UR_RESULT_ERROR_OUT_OF_DEVICE_MEMORY), OpenVINO GPU loads but decode returns res=-3. Only partial SYCL offload works, best at -ngl 8:

Notice how raising layers from 8 to 16 makes it slower — the part spilling into system RAM drags everything down. Before tuning, the best the 26B could do was SYCL partial offload at pp 134 / tg 17.8.

The key lever: the iGPU shared-memory registry

The iGPU's usable memory budget comes from the registry key SystemPartitionCommitLimitPercentage (default 57). Set it to 87 and reboot, and the Vulkan budget grows from 12.67 GiB → 19.73 GiB — the 26B finally fits:

Vulkan full offload takes the crown: pp 243.6 (3.9× pure CPU), tg 21.4 (1.2× pure CPU). A llama-cli smoke test streams at ~14.3 t/s (thinking blocks included) — perfectly usable. How to change the registry: see iGPU VRAM tuning.

The other route: the official OpenVINO GenAI pipeline

Beyond llama.cpp's OpenVINO backend, Intel offers a native OpenVINO GenAI pipeline that consumes officially pre-converted INT4-AWQ models (14.6GB). I got the official 26B running through it:

Same official model, both 4-bit: GenAI is 75% faster at prefill (500 vs 285 t/s), Vulkan 46% faster at decode (20 vs 13.7). The gap is MoE-backend implementation (Vulkan has async expert scheduling), not a tunable flag. Full walkthrough: OpenVINO GenAI official route.

Serving: the 26B as a resident API

Finally I made it a resident HTTP service (llama-server, OpenAI-compatible /v1/chat/completions) with prefix caching for multi-turn. With cache hits each turn only processes new tokens — prefill drops from 1.75s to ~1.2s from the second turn. Long context has a catch though: 16K is stable, 20K trips the iGPU driver's ErrorDeviceLost — tuning in the 20K context fix.

Summary: the complete iGPU roadmap

• 8GB-class models (E4B, etc.): full offload directly; Vulkan fastest to decode (20 t/s), OpenVINO GPU for prompt-heavy work
• 16GB-class models (26B, etc.): raise the shared-memory registry first (57→87), reboot, then Vulkan full offload takes off
• For official weights: the native OpenVINO GenAI pipeline consumes official INT4-AWQ, with faster prefill
• As a service: llama-server resident + prefix cache; multi-turn agents only pay for increments; watch -ub batching at long context