你以为 Chrome 只是更新浏览器，它可能顺手在本机放下一个约 4GB 的 AI 模型。

一位隐私博主最近披露，Chrome 会在部分符合条件的桌面设备上下载 Gemini Nano 本地模型权重文件。文件名是 weights.bin，路径里能看到 OptGuideOnDeviceModel。最刺眼的不是 4GB，而是用户没有看到明确同意弹窗，也很难从一个清楚入口决定“我要不要这个东西”。

这件事不能写成“所有 Chrome 用户都中招”。更准确的范围是：硬件条件满足、相关 AI 功能启用，或被灰度 rollout 命中的 Chrome 桌面设备。

文件是什么，争议卡在哪里

问题目前披露的信息
文件锚点OptGuideOnDeviceModel/.../weights.bin
文件大小约 4GB
被指用途Gemini Nano 本地模型权重文件
触发条件符合硬件条件、AI 功能启用，或被灰度命中
争议动作无明显同意弹窗、无清晰设置入口、删除后部分情况下会重新下载
受影响对象Chrome 桌面用户，尤其是磁盘、带宽、隐私和企业合规敏感用户

原作者给出的证据链，不是只截一张文件夹图。

他交叉看了 macOS 的 .fseventsd 文件系统事件、Chrome 的 Local State、功能 flags，以及 GoogleUpdater 日志。核心是确认几件事：目录何时创建，文件何时落盘，Chrome 如何判断设备条件，上游组件如何触发下载。

这仍然是第三方披露，不等于监管定性，也不等于法律结论已经成立。它目前能支撑的判断是：Chrome 的本地 AI 分发机制，至少在部分场景里越过了普通用户对浏览器更新的预期。

普通用户可以做的事很具体：在 Chrome 用户数据目录里搜索 OptGuideOnDeviceModel 或 weights.bin。如果设备空间紧张，先看它是否存在，再决定是否清理、关闭相关 AI 功能或暂时观望。

企业 IT 更麻烦。它们要关心的不是“4GB 贵不贵”，而是谁批准了这个模型进入终端，是否进资产清单，是否影响审计，删除后为什么可能重下。对管控严格的团队，合理动作是把 Chrome 的 AI 功能纳入变更评审，暂缓默认放开，而不是等员工机器里多出一个模型再补流程。

Google 的问题不是 AI 预置，而是把默认权拿得太顺手

本地 AI 本身没有原罪。

模型放在本机，理论上能减少云端请求，也可能带来更快响应。比如写作辅助、页面理解、诈骗检测这类功能，用本地模型有产品逻辑。

但四个动作叠在一起，味道就变了。

动作产品理由用户代价我的判断
预置 AI 能力功能启动更快用户未必知道可以做，但要说清
灰度或默认触发降低启用摩擦同意感变弱边界开始模糊
后台下载大文件提前准备模型占磁盘、吃带宽应有显著提示
删除后可能重下保证组件完整用户选择被覆盖信任受损

我不太买账“只是一个本地文件”的说法。

4GB 可以删。带宽可以补。硬盘可以换。难补的是同意权。

Chrome 不是一个普通 App。它在很多电脑里接近基础设施：企业默认装，个人天天用，权限高，更新勤，信任半径大。Google 把 AI 能力塞进 Chrome，商业上很好理解。浏览器正在变成 AI 入口，谁先把模型铺到终端，谁就更容易把“AI 可用”做成默认状态。

可产品速度不能吞掉授权。

“天下熙熙，皆为利来。”今天的“利”，不是单笔广告收入，而是 AI 分发速度、入口控制权和默认心智。Chrome 越像操作系统，Google 就越容易把一次浏览器更新变成一次能力投放。

用户看到的是浏览器升级。平台看到的是全球终端网络。

这才是问题。

浏览器成了 AI 分发通道，接下来盯三件事

这件事和 Anthropic 之前的争议有一点相似。

当时有说法称，安装 Claude Desktop 后，它会向多个 Chromium 系浏览器注册 Native Messaging bridge。两件事不完全一样：一个是桌面客户端跨浏览器写配置，一个是 Chrome 自己向用户目录放本地模型。

共同点在于边界感。

AI 公司都在抢默认位置。模型能力会拉近，入口会变贵。浏览器、系统、输入框、搜索框，都是新一轮分发战场。于是“先铺好，等你用”会变成很强的诱惑。

大平台不能用小工具的粗线条做法。

Chrome 的一个默认策略，可能落到海量机器上。原作者还估算过大规模分发可能带来的碳排成本，但这个数字依赖覆盖设备数量，只能当作规模推算，不能当成确定事实。

比碳排数字更应该盯的，是三件可验证的事：

  • Google 是否给出清楚说明.哪些功能需要 Gemini Nano，本地模型何时下载，占多少空间。
  • Chrome 是否提供可见开关.用户能否在设置里明确拒绝下载或删除后不再重下。
  • 企业管理是否跟上.管理员能否通过明确策略禁用、审计或延后这类本地 AI 组件。

这里的现实约束也要说清。

Google 不可能每次小组件更新都弹窗询问。浏览器需要自动更新，安全补丁更不能等用户点同意。问题在于，4GB 本地模型不是普通补丁。它不是修漏洞，而是新增能力。新增能力要占用户资源，就该给用户一个看得见的选择。

本地 AI 会成为浏览器标配，我不怀疑。

但标配不等于默认吞下。越是基础设施，越要把开关放在阳光下。否则用户最后学会的不是信任 AI，而是怀疑每一次更新背后又塞了什么。