如果你最近发现Chrome所在的文件夹莫名多出4GB,别急着当成bug。它叫weights.bin,藏在一个叫OptGuideOnDeviceModel的文件夹里,是Google的本地AI模型Gemini Nano。你没同意过安装它,删掉它,重启Chrome它还会自己装回来。
瑞典隐私研究员Alexander Hanff通过分析macOS内核日志发现了这件事,随后Windows、Linux上也确认存在同样的行为。Snopes抽查了6名员工的设备,3台中招。比“占了多少硬盘”更值得琢磨的是:这个组件从头到尾就没出现在Google自己的开发者文档里。
满足条件就装,删了还装回来
触发逻辑很简单:GPU等级、CPU核心数、16GB以上内存、22GB以上存储达标,Chrome就在后台静默下载,14分钟装完,全程不弹窗、不提示。手动删掉weights.bin也没用——Chrome把这次删除判定成“临时错误”,下次启动照样拉回来。有用户反映老版本没清干净,残留文件叠加到超过12GB。
Google的说法是这模型2024年就在提供了,2026年2月起给部分用户推送了“On-Device AI”关闭开关。问题是,包括Hanff本人在内,大量用户到现在都没等到这个开关,只能去chrome://flags翻,或者自己改注册表。
官方文档从来没承认过它
Chrome开发者文档里,Google给端侧模型留的正式入口是chrome://on-device-internals,可用的调试flag叫optimization-guide-on-device-model,文档里唯一写明的硬件门槛是“GPU显存大于4GB”——跟这次报道里说的16GB内存、22GB存储对不上号。换句话说,没有一份官方文档正面承认过weights.bin或OptGuideOnDeviceModel的存在,它只活在调试入口和Chrome官方支持社区的用户投诉帖里,标题直接就是“Google自动下载了一个叫OptGuideOnDeviceModel的AI模型”。
一个已经跑在几十亿台设备上的组件,连自家产品文档都不愿意认领,这比隐私协议写得含糊更能说明问题。
你点的AI在云端,你不知道的AI在设备里
Chrome地址栏那个显眼的“AI Mode”按钮,处理逻辑跟这4GB模型没关系——每一次输入都发到Google云端。真正调用本地Gemini Nano的,是右键菜单里那些多数人从没点开过的功能:反诈骗检测、页面摘要、智能粘贴。
存储和带宽是用户先垫上的,隐私上的好处却没落到用户天天用的场景里。更麻烦的是,Chrome最近悄悄删掉了一句关于端侧AI“数据不会发送到Google服务器”的承诺——因为Prompt API从Chrome 148起默认开启,网站可以直接调用本机的Gemini Nano,数据不发给Google了,但可能发给调用它的第三方网站。
看得见的AI在云端,看不见的AI在设备里,用户两头都没占到便宜。
同意这道关,是拦得住还是没打算拦
欧盟ePrivacy指令第5(3)条要求,在用户设备上存储信息前必须取得“自由、具体、知情、明确”的同意——这条规则催生了满世界的Cookie弹窗。一个4KB的Cookie需要弹窗确认,一个体量是它百万倍的4GB模型却直接装进设备,这个反差正是Hanff指控的核心。若认定成立,Google可能面临相当于全球营收4%的罚款,2025年3月德国法院对Google Tag Manager“需事先同意”的判决,已经给这条路铺了先例。
- 风险.目前官方渠道查不到“2026年2月已推送关闭开关”的确切依据,这个说法只能算未经证实。
Google对外的说法是“这就是产品自带的功能,所以没问题”,回避了同意本身该怎么给。但企业版Chrome早留了后门:管理员在注册表里新建一个叫GenAILocalFoundationalModelSettings的策略值,就能彻底挡住这个模型的下载和重装。
- 结论.技术上并非做不到“可控可关”,只是这条路一直没对普通消费者开放。
端侧AI这个方向本身没问题——把推理放到设备上能省云端成本、降低隐私暴露面,Apple Intelligence已经证明这条路能走通,前提是明确告诉用户哪些任务留在设备、哪些必须上云。哪怕只是弹一个“我们将安装4GB本地模型用于反诈骗和写作辅助,是否继续”,大多数用户大概率会点同意,这功能确实有用。不弹这个窗口,不是技术做不到,是权衡过的选择:一旦允许拒绝,总有人会拒绝,装机率一低,围绕Gemini Nano搭的开发者生态也跟着慢下来。一家占据全球六到七成浏览器份额的公司,很难不心动去跳过这一步。天下熙熙,皆为利来,这次的利是装机率,代价是用户对“同意”二字的信任被磨掉一层。