Chrome 149 上线端侧 AI 模型管理功能,用户可以主动拒绝下载或删除已有模型。这是谷歌在端侧 AI 策略上的重要转向,把选择权还给用户,但也暴露了本地模型管理的复杂性。

Chrome 149 让你删 AI 模型了

谷歌 Chrome 149 稳定版本周推送,最大变化是新增端侧 AI 模型管理选项。用户现在可以主动拒绝浏览器下载 AI 模型,也能直接删除此前已下载的所有模型。

这是谷歌在端侧 AI 策略上的一次明确转向。过去几个月,Chrome 因为静默下载多达 4GB 的 Gemini Nano 模型引发不少用户不满,尤其是那些磁盘空间本就紧张的设备。现在谷歌终于把选择权交还到用户手中,但这个改变背后,也暴露了浏览器端侧 AI 落地的复杂性。

端侧 AI 的尴尬:你不用它,它却占着空间

Chrome 从 147 版本开始内置 Gemini Nano 模型,用于诈骗检测、内容摘要、文本校对等功能。按照谷歌的设计,模型会在首次调用相关 API 时自动下载,浏览器会先跑一个 GPU 性能测试,决定下载 4B(40 亿参数)还是更小的模型变体。

Chrome 149 设置界面中的端侧 AI 模型管理选项

问题在于,这个"自动"下载机制对多数用户来说是黑盒。你可能只是打开了一个启用了增强保护的页面,浏览器就开始在后台下载几个 GB 的模型文件,没有任何明确提示。等你发现 C 盘空间莫名其妙少了一大块,模型早就装好了。

更尴尬的是,即使你从不用 Chrome 的 AI 功能,模型也会一直占着空间。直到 Chrome 149 之前,删除模型的唯一办法是手动找到 %LocalAppData%\Google\Chrome\User Data\On-Device Model 目录删掉,或者改注册表禁用下载策略。这对普通用户来说门槛太高。

新增的管理选项做了什么

Chrome 149 在系统设置中新增了「AI 与模型管理」入口,提供两个核心功能:

拒绝下载模型:关闭后,浏览器不会自动触发模型下载,即使调用了相关 API。
删除已下载模型:一键清理所有本地 AI 模型,包括基础模型和 LoRA 权重。

需要注意的是,删除模型不会影响浏览器的常规功能,但会导致依赖 Gemini Nano 的特性失效,比如 AI 模式、内容摘要、文本校对等。而且删除后不会自动重新下载,必须再次手动调用 API 才能触发新的下载流程。

这个设计有点微妙。谷歌显然想平衡两件事:一方面给用户控制权,另一方面又不想完全放弃端侧 AI 的推广。所以它选择让用户"主动拒绝",而不是"主动启用"。默认情况下,模型下载仍然是打开的,只是现在你能看到开关在哪。

模型管理的复杂性

端侧 AI 模型的管理比想象中复杂。Chrome 的文档显示,Gemini Nano 的生命周期包括下载、更新、热交换、清除等多个阶段,每个阶段都有不同的触发条件:

下载时机

首次调用 Summarizer.create() 等 API 时触发
启用增强保护且用户刚创建新配置文件时,调用 availability() 也可能触发下载
下载前会检查 GPU 性能和磁盘空间(至少需要 22GB 可用空间)

更新机制

浏览器启动时检查基础模型更新
每天检查 LoRA 权重更新
更新采用热交换,不会中断已有的 AI 会话

自动清除

磁盘空间低于阈值时自动删除
30 天内未使用相关功能时清除
企业策略禁用时立即清除

这套机制的初衷是让用户无感知,但实际效果却是让很多人摸不着头脑。你可能突然发现磁盘空间少了几个 GB,也可能发现之前能用的 AI 功能突然不可用了,因为模型被自动清除了。

开发者需要注意什么

Chrome 的端侧 AI API 设计假设模型随时可能不可用。这意味着:

不要假设模型一直存在:即使用户之前成功调用过 API,下次调用时模型可能已被清除。
处理 availability() 的所有返回值:包括 readily、after-download、no。
准备降级方案:当端侧模型不可用时,考虑回退到云端 API 或关闭相关功能。

这个设计哲学跟传统的前端开发不太一样。你需要把模型当成一种不稳定的外部依赖,而不是浏览器的固有能力。

// 检查模型可用性的推荐写法
const availability = await ai.summarizer.availability();

if (availability === 'readily') {
  // 模型已下载,直接使用
  const summarizer = await ai.summarizer.create();
  const result = await summarizer.summarize(text);
} else if (availability === 'after-download') {
  // 需要下载模型,可以选择等待或降级
  // 注意:下载可能需要几分钟,也可能因为磁盘空间不足而失败
  showDownloadingUI();
  const summarizer = await ai.summarizer.create();
  // ...
} else {
  // 模型不可用,使用降级方案
  fallbackToCloudAPI();
}

Chrome 的 AI 野心还在继续

虽然给了用户删除模型的选项,但谷歌显然没打算放慢端侧 AI 的步伐。Windows Report 发现,Chrome 正在测试直接跳过搜索首页,把用户引导到"AI 模式"的功能。谷歌回应说这只是探索,没有正式上线计划,但这个方向很明确:让 AI 成为浏览器的默认交互方式。

开发者工具方面的更新也在持续。Chrome 149 的 DevTools 新增了 MCP 服务器实现和面向 AI 智能体的命令行接口,CSS 面板还加入了由 Gemini 驱动的样式自动补全功能。这些改动表明,谷歌想把 AI 深度整合进开发者的日常工作流,而不只是面向用户的功能。

Chrome DevTools 中 Gemini 驱动的 CSS 自动补全功能演示

端侧 AI 的平衡难题

端侧 AI 的理想状态是:模型始终可用,响应速度快,不占用云端资源,用户无感知。但现实是,这四个目标很难同时满足。

要始终可用,就得占磁盘空间,可能引发用户反感
要响应快,就得用大模型,空间占用更大
要不占云端资源,就得接受离线场景下的功能受限
要用户无感知,就得自动下载更新,又回到了静默安装的争议

Chrome 149 的改动是一个折中方案:给用户选择权,但默认仍然是开启状态。这样既能缓解空间压力带来的批评,又不至于让端侧 AI 功能形同虚设。

从开发者的角度看,这也是一个信号:端侧 AI 还远没到"开箱即用"的阶段。你需要考虑模型不可用的情况,需要处理下载失败,需要准备降级方案。这跟调用一个云端 API 的心智模型完全不同。

其他值得关注的更新

Chrome 149 还有一些其他改动:

ARM64 Linux 官方支持:谷歌终于为 ARM 架构 Linux 提供了官方 deb 和 rpm 包,之前只有 x86_64 架构有官方构建。对于用 ARM 设备做开发的人来说,这意味着不用再依赖发行版维护的第三方 Chromium 包,更新和兼容性都会更好。
429 项安全修复:这个数字看起来很大,但多数是常规的内存安全和权限隔离修复,没有特别严重的漏洞。
WebMCP API 调试功能:实验性功能,用于调试使用 WebMCP API 的页面。MCP(Model Context Protocol)是 Anthropic 提出的协议,现在 Chrome 也在支持。
Intl.Locale 支持语言变体:这是一个小但实用的改进,开发者可以更精确地处理多语言场景。

Chrome 150 预计 6 月 30 日发布。如果你对频繁更新有顾虑,可以切换到 Extended Stable 分支,八周更新一次。

写在最后

端侧 AI 是个好方向,但落地细节还需要打磨。Chrome 149 的改动至少解决了最基本的问题:用户现在能看到模型在哪、能删掉它。但更深层的问题还在:端侧模型到底该怎么分发?该不该默认安装?用户不用的时候该不该自动清理?

这些问题没有标准答案。不同用户、不同场景下的需求差异很大。谷歌选择了一个相对保守的策略:默认开启,但给用户关闭的选项。这可能不是最优解,但至少比之前"你爱用不用反正我装了"的态度要好。

对开发者来说,现在是时候重新审视你对浏览器 AI 能力的假设了。端侧模型不是一个稳定的运行时环境,它更像一个可选的增强功能。你的代码需要为此做好准备。

参考来源

谷歌 Chrome 149 稳定版发布,允许用户删除已下载的端侧 AI 模型 - IT之家 - Chrome 149 主要更新内容
如何阻止谷歌 Chrome 浏览器 147 静默下载 4GB 端侧 AI 模型 - IT之家 - 通过注册表禁用模型下载的方法