2GB 模型塞进浏览器，不联网、不要 API Key、不按 token 计费——Chrome 把 LLM 变成了前端的一个 window 对象

小智·AI工具控 内容创作者 2026-09-18 598 阅读

前端调用大模型这件事，终于不用再往服务器绕一圈了。

Chrome 把 Gemini Nano 直接打包进了浏览器进程。它跑在用户的设备上，不需要 API Key，不发网络请求，也不按 token 计费。你在页面上调用它，就像调用任何一个普通的 window 对象。

一个 window.LanguageModel 就够了

Prompt API 是这套能力里最通用的入口。网页里挂在 window.LanguageModel 上，扩展里则是 chrome.languageModel：

// 先问浏览器：这个模型能不能用
const status = await LanguageModel.availability();
// 返回 'available' | 'downloadable' | 'downloading' | 'unavailable'

if (status === 'downloadable') {
  // 首次使用需要后台下载（约 2GB），记得给用户一个进度提示
  await LanguageModel.create({
    monitor(m) {
      m.addEventListener('downloadprogress', (e) => {
        console.log(`已下载 ${(e.loaded * 100).toFixed(0)}%`);
      });
    },
  });
}

const session = await LanguageModel.create({
  systemPrompt: '只输出 JSON，不要解释。',
});

const reply = await session.prompt('把这段 changelog 总结成三条要点：nn' + changelog);

没有 fetch，没有 Authorization header，没有超时重试。模型就在本地，调用延迟是毫秒级。

不止是通用 Prompt：六个开箱即用的专用 API

Prompt API 是通用底座，Chrome 另外提供了六个封装好的任务型 API，各有针对性的默认参数：

  • Summarizer：生成摘要，支持句子、段落、要点列表多种格式
  • Writer：按指定的写作任务生成内容
  • Rewriter：把现有文本改写得更长/更短/换语气
  • Translator：本地实时翻译
  • Language Detector：识别任意文本的语言
  • Proofreader：校对可读性和语法

调用方式高度统一，以 Summarizer 为例：

if ((await Summarizer.availability()) === 'available') {
  const summarizer = await Summarizer.create();
  const summary = await summarizer.summarize('要总结的长文本……');
  console.log(summary);
}

这六个 API 的意义在于：你不需要学 prompt 工程，也不用自己调 temperature。它们把「总结」「翻译」「校对」这类确定性任务的默认行为固化下来了。

硬件门槛：不是所有设备都跑得动

这套 API 的可用性取决于用户设备。据 Chrome 官方文档，要运行 Prompt / Summarizer / Writer / Rewriter / Proofreader，需要满足：

  • 操作系统：Windows 10/11、macOS 13+、Linux，或 Chromebook Plus 上的 ChromeOS
  • 磁盘空间：Chrome 配置所在卷至少 22GB 可用（模型约 2GB，若剩余空间掉到 10GB 以下模型会被自动移除）
  • GPU：VRAM 严格大于 4GB；或
  • CPU 路线：16GB 以上内存 + 4 核以上

另外，Translator 和 Language Detector 用的是专用小模型，只支持桌面版。Gemini Nano 目前不支持移动端。从 Chrome 149 起，模型支持英语、西班牙语、日语、德语、法语。

所以这不是「所有用户都能用」的功能，必须做能力检测和降级。

生产环境的正确姿势：polyfill + 云兜底

Chrome 官方提供了一套实验性 polyfill（npm 包 built-in-ai-task-apis-polyfills），它在 window.LanguageModel 不存在时自动接管，并支持把 Firebase AI Logic 之类的云端后端当作 fallback：

// 只在浏览器没原生支持时才加载 polyfill
const polyfills = [];
if (!('Summarizer' in window)) {
  polyfills.push(import('built-in-ai-task-apis-polyfills/summarizer'));
}
if (!('Translator' in window)) {
  polyfills.push(import('built-in-ai-task-apis-polyfills/translator'));
}
await Promise.all(polyfills);

这条防御式导入策略很关键：原生能用就绝不用 polyfill，原生不能用时才回退到云端。否则你会在支持 Gemini Nano 的设备上白白多绕一圈网络。

能力边界：它不是 GPT-4 的替代品

别把它当成云端大模型的平替。根据实际接入经验，几个硬限制绕不开：

  • 上下文窗口小：约 4K token 输入、1K token 输出，软上限扩展到 8K
  • 不支持工具调用：stable 渠道没有 tool calling
  • stable 渠道不支持图片输入：多模态能力还在 Origin Trial
  • 首次下载成本：约 2GB，冷启动用户体验需要专门设计

它真正的价值场景是：客户端输入解析、JSON 结构修复、把 API 响应总结给 UI 显示、开发期的 stub 生成——这些任务数据量小、要求低延迟、且不该把用户数据发到云端。

先做能力检测，再谈功能

如果你想试这个能力，最短路径是：

  1. 在页面里先跑 await LanguageModel.availability()，把返回值打到控制台，看看你手头的 Chrome 返回什么
  2. 如果返回 downloadable，写一个下载进度 UI——2GB 的下载没有提示，用户会以为页面卡死
  3. 用 Summarizer 或 Translator 这种确定性任务先试水，不要一上来就做复杂 prompt
  4. 无论如何都写一套云兜底逻辑，因为大量用户设备根本跑不动

浏览器自带大模型这件事，短期看是给轻量 AI 功能开了个口子；长期看，它意味着「前端调用 AI」不再必然等于「向某个云服务付费」。这个方向值得你现在就摸清楚边界。

评论区

0 条评论

登录后可评论。

小智·AI工具控 598 阅读