Local AI on KnightLi Blog

Chrome Silently Downloads 4GB Gemini Nano: How to Check, Disable, and Delete It

Sat, 09 May 2026 21:37:18 +0800

Google Chrome has been reported to download a roughly 4GB local AI model file in the background without explicit user permission, sparking debate about privacy, storage usage, and environmental impact.

The files are related to Gemini Nano and are mainly used for Chrome’s local AI features. The dispute is not simply that the browser supports local AI, but whether the download process is transparent enough, whether users should be informed in advance, and whether system resources are being used reasonably.

What happened

The model file being discussed is named weights.bin and is located in Chrome’s OptGuideOnDeviceModel directory. It is believed to be a localized version of Gemini Nano, used to perform some AI inference directly on the device.

Chrome decides in the background whether to download it based on hardware capability, especially RAM and VRAM. Users generally do not need to start the download themselves, and they may not see a clear prompt before it happens.

The more frustrating part is that manually deleting the model file usually does not stop it from coming back. As long as the related feature remains enabled, Chrome may download the model again after a restart or a later update.

The platforms mentioned in the discussion include Windows 11, macOS, and Ubuntu desktop systems. Based on Chrome’s desktop install base, the number of potentially affected devices could reach hundreds of millions.

Google’s explanation

Google says these files support local AI features such as “Help me write” and scam detection. Running the model locally can reduce some data uploads and improve privacy protection.

Google also says that if device storage is low, Chrome will automatically remove the related model to free up space. In other words, the model does not necessarily occupy disk space permanently.

At the same time, Google says users have been able to disable the related feature in Chrome settings since February 2024. Once disabled, the model will no longer continue downloading or updating.

How to check and disable it

If you do not want Chrome to keep the Gemini Nano model locally, start by checking a few places.

First, open Chrome settings and look for options related to “on-device AI”, local AI, writing assistance, or optimization suggestions, then disable the features you do not need.

Second, enter this in the address bar:

`1`	`chrome://flags`

Then search for and disable:

`1`	`Enables optimization guide on device`

Finally, check Chrome’s user data directory for the OptGuideOnDeviceModel folder and delete the model files inside it. Keep in mind that deleting the file alone is usually not enough. It is better to disable the related flag or setting first, otherwise Chrome may download it again later.

Possible paths on different systems

OptGuideOnDeviceModel is usually under Chrome’s user data directory. The exact location can vary depending on the operating system and installation method, but these are good places to check first:

Windows: %LOCALAPPDATA%\Google\Chrome\User Data\
macOS: ~/Library/Application Support/Google/Chrome/
Linux: ~/.config/google-chrome/
Chromium: ~/.config/chromium/

After opening the relevant directory, search for OptGuideOnDeviceModel or weights.bin. If you use Chrome Beta, Dev, or Canary, the directory name may include the corresponding release channel.

How to tell whether weights.bin has been downloaded

The simplest method is to search Chrome’s user data directory for:

`1`	`weights.bin`

If it has been downloaded, it will usually appear inside OptGuideOnDeviceModel, and the file size may be close to several GB. You can also check the modified time to see whether Chrome recently created or updated it in the background.

If you cannot find weights.bin, that does not necessarily mean the device will never download it. Chrome may decide whether to fetch the model based on hardware conditions, region, version, feature flags, and experiment configuration.

Which Chrome AI features may be affected

After disabling the related local AI or optimization features, some on-device capabilities that depend on Gemini Nano may be affected, such as “Help me write”, local scam detection, and future browser AI features that do not go through the cloud.

For users who do not use these features, everyday browsing is usually not affected much. For users who frequently use Chrome’s built-in writing assistance, page understanding, or experimental safety detection features, the experience may fall back to cloud processing, become unavailable, or use another browser-provided alternative.

Where the controversy lies

The central question is whether a browser should download several GB of model files for AI features before the user has clearly agreed.

Supporters argue that local AI can reduce cloud processing, improve privacy, and make responses faster. Critics argue that users should at least see a clear prompt before the download, especially when the file is close to 4GB and may affect storage space and network traffic.

Privacy experts also point out that this kind of insufficiently disclosed background download may raise compliance questions under the EU ePrivacy Directive and GDPR. Whether it constitutes a violation depends on Google’s notice mechanism, default settings, data processing path, and user controls.

Summary

Chrome’s adoption of Gemini Nano shows that browsers are moving more AI capabilities onto the local device. But it also creates a new product boundary problem: local models still consume disk space and bandwidth, and they can affect the user’s sense of control over their own device.

For ordinary users, the most direct step is to check Chrome’s local AI and optimization settings. If you do not need these features, disable the related options and then delete the model files in the OptGuideOnDeviceModel directory.

Canonical Ubuntu AI Roadmap: Local Inference First, No Forced Integration

Fri, 08 May 2026 22:23:46 +0800

Canonical’s recent Ubuntu AI roadmap is notable less for “putting AI everywhere” and more for trying a restrained path: AI features are layered, disabled by default, enabled only by explicit user choice, and designed to prefer local inference.

That stands apart from some of the controversy around system-level AI in Windows and macOS. Ubuntu is not trying to build an unavoidable global AI layer, nor is it promising one universal AI kill switch. Instead, the plan is to expose AI as separate tools, letting users decide whether to install them, enable them, choose a model, and allow data to leave the machine.

First, the timeline: not Ubuntu 26.04 LTS

The roadmap points mainly to Ubuntu 26.10 “Questing Quokka”, expected on October 9, 2026. Canonical plans to introduce some AI tooling as experimental previews, not as default features in Ubuntu 26.04 LTS.

That matters. LTS releases are meant for stability, enterprise deployment, and long-term maintenance. It would be unusual to place exploratory desktop AI features into an LTS default experience. A more reasonable path is to test them first in a regular release such as 26.10, gather feedback from developers and early users, and then decide what belongs in later long-term releases.

Local inference first, cloud only by choice

One core principle is local inference first. By default, inference should happen on the user’s machine. Requests should leave the machine only when the user explicitly configures a cloud provider, a self-hosted server, or an enterprise model service.

The reason is practical: system-level AI can easily touch command output, logs, file paths, errors, and system configuration. Sending that information to the cloud automatically, even to explain an error, creates obvious privacy and compliance risks.

So Ubuntu’s AI direction is not a cloud AI gateway. It is closer to a pluggable inference layer. Users may choose a local model, an internal company service, or a Canonical-managed service when needed. The important part is avoiding lock-in to one model vendor.

AI CLI: start with terminal assistance

One of the first practical features may be the AI Command Line Helper, often referred to as ai-cli.

It is not meant to replace the shell or automatically run risky commands. Its job is to help users understand commands, logs, systemd units, error output, and system state. For example, it could explain why a service failed to start, or clarify what a command-line flag means.

This fits Ubuntu’s audience well. Many Ubuntu desktop and server users already live in the terminal. Instead of starting with a flashy chat window, it makes sense to put AI into error analysis, command explanation, and operations assistance.

The safety boundary must be clear. Logs may contain tokens, internal hosts, usernames, file paths, key fragments, or business information. Even with local inference by default, tools should encourage redaction. If a user chooses a cloud backend, the UI must make clear what will be sent.

Settings Agent: natural-language system settings

Another direction is a Settings Agent that lets users query or change system settings in natural language.

This sounds simple but is easy to get wrong. A mature Settings Agent should not scrape the screen, guess buttons, and simulate clicks. It should use controlled internal APIs: what it can read, what it can change, when confirmation is required, and how failures are rolled back.

That makes it more likely to be a post-26.10 direction than a complete immediate feature. If done well, it could lower the barrier for normal users to configure desktop Linux. If done too aggressively, it becomes a new security risk.

Why not a universal AI kill switch?

Many users worry that once vendors add AI to an operating system, AI appears everywhere and becomes hard to disable. So the natural question is whether Ubuntu should provide a global AI kill switch.

Canonical’s position is that if AI features are opt-in, layered, and independently installable and configurable, a global kill switch is not the first priority. In other words, the design should avoid the pattern of “enabled by default, deeply embedded, then users have to disable it.”

Whether that is enough depends on implementation. If AI tools are not enabled by default, do not connect to remote services by default, do not collect data automatically, and each feature has clear controls, users should not need to hunt through hidden settings to turn AI off.

What it means for developers and enterprises

For developers, AI CLI tools can reduce the time spent reading documentation, parsing logs, and diagnosing system problems. They do not replace engineering judgment; they automate a lot of “help me understand this output” work.

For enterprises, local inference and pluggable backends matter more. Many companies cannot send source code, logs, customer data, or infrastructure details to public model services. If Ubuntu can connect system-level AI with local models, private inference services, and enterprise permissions, it may offer useful assistance in compliant environments.

This is also an opening for Linux desktops and workstations. Windows and macOS can more easily fold AI into vendor ecosystems. Ubuntu’s advantage is openness, auditability, replaceability, and self-hosting. If Canonical preserves those principles, AI could strengthen the professional Linux experience.

Do not overread it

It is too early to say that Ubuntu will preinstall a specific small model, that Ubuntu 26.04 will include an AI audit mode, or that there will be a fixed ubuntu-ai command. The clearer public information is about direction, not final product shape.

The safer reading is this: Canonical is preparing a system-level AI tooling framework for Ubuntu, starting with command-line help, settings assistance, local inference, and backend choice. The default posture is user choice, not vendor choice.

Summary

The important part of Ubuntu’s AI roadmap is not that Ubuntu is “joining the AI wave”. It is the attempt to define a more restrained model for AI in open source operating systems: intelligence can become infrastructure, but privacy, control, and user choice must come first.

If the experimental features in 26.10 live up to those principles, Ubuntu may take a different path from consumer operating systems: AI not as an unavoidable system ad slot, but as a selectable, replaceable, and auditable productivity layer.

References:

Which Local AI Models Can a Laptop RTX 4060 8GB Run?

Fri, 08 May 2026 13:41:15 +0800

A laptop RTX 4060 8GB can run local AI, but the boundary is clear: the key question is not whether a model starts, but whether it stays inside VRAM. Mobile RTX 4060 cards are also limited by laptop power, cooling, memory bandwidth, and vendor tuning, so sustained performance varies between machines.

In 2026, 8GB VRAM is still the entry baseline for local AI. With the right quantized models and tools, it can run 3B-8B LLMs, SDXL, SD 1.5, some quantized FLUX workflows, Whisper transcription, and image feature extraction. If you force 14B+ LLMs, unquantized large models, or heavy image workflows, performance can collapse once data spills into system memory.

Short version: do not chase the largest model. Use small models, quantized weights, and low-VRAM workflows.

VRAM Budget

Windows 11, browsers, drivers, and background apps already use part of the GPU memory. The usable AI budget is often closer to 6.5GB-7.2GB than the full 8GB.

Practical rules:

LLM: prefer 3B-8B with 4-bit quantization.
Image generation: prefer SDXL, SD 1.5, and FLUX GGUF/NF4 low-VRAM workflows.
Multimodal: prefer light 4B-class models.
Speech: Whisper large-v3 can run, but long batches generate heat.
Image indexing: CLIP, ViT, and similar feature models are a good fit.

If VRAM spills to system memory, speed can become painful. A smaller model fully on GPU is usually better than a larger model half offloaded.

LLMs: 3B-8B Quantized Models

For local chat and text reasoning, use Ollama, LM Studio, koboldcpp, llama.cpp, or another GGUF-friendly frontend. The sweet spot for 8GB VRAM is 3B-8B with 4-bit quantization.

Lightweight General Use: Gemma 4 E4B

Gemma 4 E4B is one of Google’s small Gemma 4 models released in 2026. It is aimed at local and edge use, and is a reasonable daily model for Q&A, summaries, light multimodal tasks, and low-cost inference.

On a laptop RTX 4060, start with an official or community quantized build. Do not start with the highest-precision weights. First confirm speed, VRAM, and answer quality.

Good for:

Daily Q&A.
Summaries and rewriting.
Light document organization.
Simple code explanation.
Light image understanding.

Reasoning and Long Text: DeepSeek R1 Distill 7B/8B, Qwen 3 8B

For logic, math, complex analysis, and long Chinese text, try DeepSeek R1 distill 7B/8B or quantized Qwen 3 8B.

With Q4_K_M, 8B-class models usually fit within an 8GB laptop GPU budget. Actual speed depends on context length, backend, driver, and laptop power mode. Short chats are comfortable; long contexts increase both VRAM and latency.

Avoid starting with 14B, 32B, or larger models. They may launch with CPU offload, but the experience is usually worse than a smaller full-GPU model.

Coding: Qwen 2.5 Coder 3B/7B

For coding, Qwen 2.5 Coder 3B or 7B is a good choice. The 3B version is fast and fits real-time completion, explanations, and small snippets. The 7B version is stronger but heavier.

Suggested use:

Realtime completion: 3B.
Q&A and explanation: 3B or 7B.
Small refactors: quantized 7B.
Large architecture analysis: do not expect an 8GB laptop to hold the full project context.

Image Generation: SDXL Is Stable, FLUX Needs Quantization

RTX 4060 8GB is usable for image generation, but model choice matters.

SD 1.5 and SDXL

SD 1.5 is very friendly to 8GB VRAM, fast, and mature. SDXL needs more memory but remains usable.

Recommended tools:

ComfyUI
Stable Diffusion WebUI Forge
Fooocus

SD 1.5 is good for fast generation, LoRA, ControlNet, and old model ecosystems. SDXL is better for general quality. SDXL with Forge or ComfyUI is a stable starting point.

FLUX.1 schnell

FLUX has stronger prompt understanding and image quality, but the original models are heavy. On 8GB VRAM, use GGUF, NF4, FP8, or other low-VRAM paths with ComfyUI-GGUF or equivalent workflows.

Practical tips:

Use FLUX.1 schnell GGUF Q4/Q5.
Reduce resolution or batch size.
Use low-VRAM nodes or --lowvram in ComfyUI.
Avoid too many LoRA, ControlNet, and hi-res fix steps at once.
Watch whether VRAM is released after workflow changes.

You can try 1024px generation, but do not copy workflows meant for 16GB/24GB desktop GPUs.

Multimodal and Utility Workloads

Whisper large-v3

Whisper large-v3 works for speech-to-text. RTX 4060 can process ordinary audio quickly, useful for meeting recordings, lessons, video subtitles, and media organization.

For long batches, enable performance mode and keep cooling under control.

CLIP / ViT Image Indexing

For a photo search system, RTX 4060 8GB is a strong fit. CLIP, ViT, and SigLIP feature models do not require extreme VRAM and can process thousands of images quickly.

Typical pipeline:

Extract image embeddings with CLIP/ViT/SigLIP.
Store them in SQLite or a vector database.
Search by text or similar image.
Use a small LLM for tags, descriptions, or album summaries.

This workload suits 8GB GPUs better than large LLMs because it is mostly feature extraction and batch processing.

Recommended Combos

Local chat:

Ollama / LM Studio
+ Gemma 4 E4B quantized
+ DeepSeek R1 Distill 7B/8B Q4
+ Qwen 3 8B Q4

Coding:

1
2
3

Qwen 2.5 Coder 3B
+ Qwen 2.5 Coder 7B Q4
+ Continue / Cline / local OpenAI-compatible server

Image generation:

ComfyUI / Forge
+ SDXL
+ SD 1.5
+ FLUX.1 schnell GGUF Q4/Q5

Photo search:

1
2
3

CLIP / SigLIP / ViT
+ SQLite / FAISS / LanceDB
+ Gemma 4 E4B or Phi-4 Mini for text organization

Pitfalls

Scenario	Advice
Large models	Avoid 14B+ unless you accept major slowdown
Quantization	Start with `Q4_K_M`, then try Q5 if quality matters
VRAM	Monitor with Task Manager or `nvidia-smi`
Cooling	Use laptop performance mode for generation and batches
Resolution	Start image generation at 768px or one 1024px image
Browser	Close GPU-heavy tabs while running models
Driver	Keep NVIDIA drivers reasonably current
Workflows	Do not copy 16GB/24GB ComfyUI workflows directly

If VRAM stays above 7.5GB, lower the model size, lower context, close apps, or enable low-VRAM mode.

My Take

A laptop RTX 4060 8GB is best seen as a cost-effective local AI entry platform.

Good fit:

3B-8B local LLMs.
Small coding models.
SDXL and SD 1.5.
Quantized FLUX experiments.
Whisper transcription.
Image vector indexing.
Photo management and local data organization.

Poor fit:

Long-term 14B/32B LLM use.
Unquantized large models.
High-resolution batch FLUX workflows.
Large-scale video generation.
Many models resident at the same time.

For a photo retrieval system, use the GPU for CLIP/SigLIP feature extraction and small-model tagging, then store vectors in SQLite, FAISS, or LanceDB. Models like Gemma 4 E4B, Phi-4 Mini, or Qwen 2.5 Coder 3B/7B are more efficient than forcing a large model.