Run Chrome's Tiny Gemini Nano AI on PC Without a GPU

Chrome ships a small, on-device foundation model — Google calls it Gemini Nano — behind the browser's built-in AI APIs (Prompt API, Summarizer, and related surfaces). The pitch is on-device inference with no server round-trip. The catch that trips up a lot of developers and enthusiasts: Chrome's own eligibility check for downloading and running that model is gated on GPU VRAM, not just CPU horsepower or RAM. This piece synthesizes what that requirement actually is, why it exists, what CPU-only workarounds really involve, and where you're better off reaching for a dedicated local-inference runtime instead.

What Chrome's On-Device Model Actually Is

Gemini Nano is Google's smallest deployable member of the Gemini model family, distilled down for on-device use inside Chrome and Android. It's designed to handle lightweight generative tasks — summarization, rewriting, simple prompt completion — locally, without sending text to a cloud API. Chrome surfaces this through a set of built-in AI JavaScript APIs that web developers can call directly, per Chrome's built-in AI documentation.

Because the model runs in-browser rather than in the cloud, Chrome has to manage the download, storage, and hardware-eligibility lifecycle itself — which is where the GPU requirement comes in.

The Official Hardware Requirements

Per developer.chrome.com's built-in AI guide, the documented eligibility criteria for downloading and running the on-device model are:

That GPU line is the one that matters for this article. It's not a soft recommendation — it's a hard gate in the standard download flow. A machine with an integrated GPU or a discrete card under the VRAM threshold, and no way to spoof past the check, will simply be told it isn't eligible rather than falling back to a slower CPU path automatically.

Why the Check Exists

Running a multi-billion-parameter model — even a small one — well enough to feel responsive in a browser tab is a meaningfully different workload on GPU versus CPU. GPUs parallelize the matrix multiplications that dominate transformer inference; CPUs do not, at least not nearly as efficiently per watt or per dollar of silicon. Google's eligibility gate exists to keep the default built-in AI experience fast and consistent for the median Chrome user, not to lock out CPU inference on principle.

That tradeoff is the same one that shows up any time a small model targets constrained hardware — SpecPicks' related coverage of running tiny local LLMs on a Raspberry Pi 4 8GB with Ollama and on a Raspberry Pi Zero W documents the same CPU-bound ceiling from the opposite direction: extremely low-power ARM CPUs running quantized tiny models with no GPU at all.

What Developers Actually Use to Poke at Eligibility

Chrome exposes a diagnostics page, chrome://on-device-internals, documented at developer.chrome.com/docs/ai/on-device-internals. It surfaces the current eligibility result, download state, and lets a developer trigger a fresh eligibility check or force a download attempt for testing purposes. This is a debugging surface aimed at web developers building against the built-in AI APIs — it's not documented by Google as an official CPU-only override, and treating any flag combination as a guaranteed, supported bypass is not something this synthesis can verify.

If you're experimenting with chrome://flags entries related to "Optimization Guide On Device Model," understand you're operating outside Chrome's documented support surface. Behavior can change across Chrome versions without notice, and a device that technically starts a download despite failing the VRAM check may still fall back to whatever CPU delegate the underlying inference runtime supports — with no guarantee of usable latency.

Performance Reality: What to Expect Without a GPU

General principle, not a specific benchmark: swapping a GPU delegate for a CPU delegate on a small (single-digit billion parameter) language model typically costs a large multiple in throughput and adds noticeably to per-token latency. The exact tokens-per-second figure depends heavily on the CPU's core count and instruction set support (AVX2/AVX-512), the model's quantization level, and the inference runtime's CPU kernel optimization — none of which Chrome's built-in AI stack publishes hard numbers for. Treat any specific tok/s claim you encounter elsewhere for this exact configuration with skepticism unless it links a reproducible source.

For a directionally comparable reference point, SpecPicks' Raspberry Pi 4 8GB tok/s coverage and TinyLlama/Phi benchmarks show what fully CPU-bound, low-power inference looks like for comparably small models — useful context even though the hardware class (ARM SBC vs. desktop x86) differs.

If You Actually Want CPU-Only Local Inference: Skip the Browser

If the goal is "run a small model without a GPU" rather than specifically "run it inside Chrome," a dedicated local-inference runtime is the more reliable path. Projects like llama.cpp and Ollama are built around CPU execution as a first-class case, not a fallback — they ship CPU kernels optimized for common instruction sets and don't gate on VRAM the way Chrome's built-in AI eligibility check does.

This is the same territory SpecPicks has covered from the hobbyist-hardware angle: the Laguna XS.2 landing in llama.cpp piece looks at a tiny hybrid model built for exactly this kind of constrained local inference, and the Cactus hybrid-router coverage of Gemma4-2B running locally with a Gemini cloud fallback documents a hybrid local/cloud approach that sidesteps the all-or-nothing GPU gate entirely. Google's own Gemma model family page also documents CPU-runnable quantized builds distinct from the Chrome-integrated Gemini Nano path, which is worth checking if the browser integration itself isn't a requirement for your use case.

Should You Bother With CPU-Only Chrome AI?

The Bottom Line

Chrome's built-in AI intentionally checks for a GPU with more than 4 GB of VRAM before it will download Gemini Nano, per Google's own documentation — that's a deliberate quality bar, not an oversight. Diagnostics pages like chrome://on-device-internals exist to help developers understand eligibility state, not to officially unlock CPU-only execution. Anyone who genuinely needs to run a small model with no GPU in the loop gets a more predictable outcome from a purpose-built CPU inference runtime like llama.cpp or Ollama than from working around Chrome's browser-integrated model gate.

Hardware that clears the 4 GB VRAM gate

If the goal is running Chrome's built-in AI as the docs intend rather than working around the check, an entry-level current-generation NVIDIA card puts a machine over the eligibility bar with room to spare. Three commonly stocked options:

• MSI GeForce RTX 4060 Ventus 2X 8GB — 8 GB GDDR6, doubles Chrome's 4 GB threshold, roughly $330 street.
• MSI GeForce RTX 4060 Ti Gaming X Slim 16GB — 16 GB GDDR6, 4× the threshold and enough headroom for larger local models alongside Chrome's Gemini Nano.
• MSI GeForce RTX 4060 Ti Ventus 2X 8GB — same 8 GB tier as the base 4060 with faster memory bandwidth for local-inference workloads.

Any of these clears the documented eligibility gate. For readers considering a used-market alternative, the RTX 3060 12GB path is covered in our Mistral local-inference commentary.

Citations and sources

• Chrome Built-in AI documentation — Chrome, Google
• Chrome Built-in AI: Get started — Chrome, Google
• Chrome on-device internals debugging page — Chrome, Google
• Gemma model family — Google AI

This piece is editorial synthesis based on publicly available information. No independent first-party benchmarking is reported.