Chrome Prompt API 深度解读：设备端 AI 与云端 Gemini API 的边界、限制与选型

一、问题：Web 应用集成 AI 的“三座大山”

在 Prompt API 出现之前，Web 开发者想在网页中集成 AI 能力，面临的是一道几乎无解的成本方程。

第一座山：成本失控。 调用 OpenAI、Anthropic 或云端 Gemini API，每百万 token 的支出清晰可见——GPT-5.5 输入约 $5/百万 token、输出约 $30/百万 token，Gemini 3.1 Pro 约 $2/百万 token 输入、$12/百万 token 输出。对于高并发、高频调用的场景（如实时摘要、自动补全、内容分类），云 API 账单可以轻松膨胀到每月数万甚至数十万美元。

第二座山：隐私风险。 用户数据经由网络往返云端，意味着医疗记录、法律文档、个人日记等敏感信息必须经过第三方服务器。即便有再严格的隐私政策，数据“离开设备”这件事本身就是一个无法消除的架构级风险。

第三座山：用户体验降级。 每次 AI 调用都需要等待网络往返，延迟动辄数百毫秒甚至数秒。离线场景下 AI 能力完全不可用。API 密钥管理、跨域限制、速率限制等基础设施问题进一步推高了开发复杂度。

这三座大山长期将 AI 能力限制在“有预算、能承受延迟、可接受数据外传”的少数场景中。直到 2026 年 5 月 5 日，Chrome 148 稳定版正式发布了 Prompt API。

二、方案：Chrome Prompt API 是什么？

2.1 一句话定义

Prompt API 是 Chrome 内置的 JavaScript 接口，允许网页和扩展程序直接调用浏览器本地运行的 Gemini Nano 模型——无需 API 密钥、无需网络往返、无需按 token 付费。

用更直白的话说：每个安装了 Chrome 148 的桌面用户，浏览器里都“住”着一个 4GB 的 AI 模型，任何网站用几行 JavaScript 就能唤醒它。

2.2 核心 API 三原语

根据 Chrome 官方文档，Prompt API 暴露三个核心操作：

// 1. 检查模型可用性
const status = await LanguageModel.availability();
// 返回值: 'available' | 'downloadable' | 'downloading' | 'unavailable'

// 2. 创建会话（可配置系统提示词和采样参数）
const session = await LanguageModel.create({
  systemPrompt: '你是一位专业的旅游规划师，用中文回答。',
  temperature: 0.7,
  topK: 40,
});

// 3. 发送提示词（支持流式和非流式）
const result = await session.prompt('推荐三个适合春季出游的国内目的地');
// 或流式输出
const stream = session.promptStreaming('写一篇200字的景点介绍');
for await (const chunk of stream) {
  console.log(chunk);
}

2.3 多模态与结构化输出

Prompt API 的初始实现支持文本、图片和音频输入。在 Chrome 148 中，开发者可以通过 JSON Schema 约束输出格式，确保 AI 返回可预测的结构化数据：

const session = await LanguageModel.create({
  systemPrompt: '从以下文本中提取信息，以 JSON 格式返回。',
  responseJSONSchema: {
    type: 'object',
    properties: {
      name: { type: 'string' },
      price: { type: 'number' },
      category: { enum: ['冒险', '海滩', '文化', '美食'] }
    },
    required: ['name', 'price']
  }
});

trAIlblazers 团队已经将这一能力用于标签生成等生产场景。

2.4 可用性范围

Prompt API 的可用性分三个层次：

层次	状态	说明
Chrome 扩展程序	稳定可用（Chrome 138+）	可直接在生产环境使用
普通网页	Origin Trial（Chrome 139-144）	需注册获取试用 token
普通网页（本地开发）	需开启实验 flag	chrome://flags/#prompt-api-for-gemini-nano

Chrome 148 已将 Prompt API 推至稳定状态，但对网页端的广泛开放仍依赖 Origin Trial 机制。

三、架构：设备端 AI 的技术栈与约束

3.1 推理引擎：WebGPU + WebAssembly

Chrome 内置 AI 的推理层基于两大底层技术：

• WebGPU：在 Chrome 113（2023 年 5 月）中达到稳定状态，提供 GPU 计算着色器管线，是本地 LLM 推理的性能基石。
• WebAssembly：作为编排和 fallback 层，在 GPU 不支持时提供 CPU 推理路径。

Gemini Nano 模型通过 4-bit 量化（Q4_0、Q4_K_M）压缩到约 4GB，可以在消费级 GPU 显存中运行。

3.2 硬件门槛：不是每台电脑都能跑

根据 Chrome 官方文档，使用 Prompt API 的硬件要求极为严格：

操作系统：

• Windows 10 或 11
• macOS 13+（Ventura 及更高版本）
• Linux
• Chromebook Plus 设备（平台 16389.0.0+）

重要限制：Prompt API 尚不支持 Android 版 Chrome、iOS 版 Chrome 和非 Chromebook Plus 设备上的 ChromeOS。

存储空间：包含 Chrome 配置文件的卷上至少 22 GB 可用空间。

GPU 模式：VRAM 严格超过 4 GB。

CPU 模式：RAM 达到 16 GB 或更高，且 CPU 核心数 4 个或更多。

音频输入：使用音频输入的 Prompt API 必须配备 GPU。

网络：需要无限数据或不按流量计费的连接（Wi-Fi/以太网优先，移动网络可能不会自动下载）。

有分析指出，满足这些条件的用户可能只占 60% 左右。开发者必须为不支持的设备和浏览器准备 fallback 方案。

3.3 模型下载：4GB 的“不速之客”

Gemini Nano 模型文件（weights.bin）约 4GB，存储在 Chrome 用户配置目录的 OptGuideOnDeviceModel 子目录中。

关于下载机制，官方文档的解释是：

“虽然 API 内置于 Chrome 中，但模型会在来源首次使用该 API 时单独下载。”

具体而言，第一次调用 *.create() 函数（如 LanguageModel.create()）会触发模型下载。在某些情况下，调用 availability() 也可能触发下载——例如在新用户配置文件启动后不久且 Gemini Nano 的欺诈检测功能激活时。

3.4 会话与上下文限制

Prompt API 的会话模型与云端 Gemini API 有显著差异：

维度	Prompt API (Gemini Nano)	云端 Gemini API
输入上下文	~4K tokens	最高 100万+ tokens
输出长度	~1K tokens	可配置
总上下文	软扩展到 8K	无硬性限制
工具调用	不支持	完整支持
图片输入	Origin Trial 中	原生支持
会话状态	每次 create 新建	可维持长对话

四、对比：Prompt API vs 云端 Gemini API

4.1 成本维度

这是两者最本质的区别。

Prompt API（设备端） ：

• 前期成本：用户设备需满足硬件条件（22GB 存储 + 4GB+ VRAM 或 16GB+ RAM）
• 运行成本：零边际成本——每次推理消耗的是用户设备的电力和算力，无 token 计费
• 适用场景：高频调用、大规模用户、对成本敏感的功能

云端 Gemini API：

• 前期成本：需 Google Cloud 账号和 API 密钥配置
• 运行成本：按 token 计费——Gemini 3.1 Pro 约 $2/百万 token 输入、$12/百万 token 输出
• 适用场景：低频率、高复杂度、对模型能力要求高的任务

以 Trip.com 的实践为例：通过 Prompt API 在本地为数百万用户生成个性化旅行摘要，完全规避了 token 账单。如果改用云端 API，按百万用户每人每次生成 500 token 计算，单日成本即可达数万美元。

4.2 能力维度

能力项	Prompt API	云端 Gemini API
模型规模	Gemini Nano（小参数量）	Gemini Pro/Flash（大参数量）
推理质量	基础任务可用，复杂推理有限	业界领先水平
多语言支持	英语最佳，其他语言有损	全语言高质量支持
长上下文	4K 输入（软扩展 8K）	100万+ token
工具调用/函数调用	❌	✅
结构化输出	✅（JSON Schema）	✅
实时流式	✅	✅
多模态（图+文+音）	Origin Trial 中	✅ 完整支持

4.3 延迟维度

设备端推理消除了网络往返延迟：

• Prompt API：首次调用需加载模型（数秒预热），后续推理在 M1+ 芯片上可达亚秒级响应。无网络抖动，延迟完全取决于本地硬件。
• 云端 Gemini API：每次调用需经历网络往返（通常 200-800ms）+ 服务端排队 + 推理时间，且受网络状况影响。

4.4 隐私维度

Prompt API 的架构级隐私优势无可争议：

“当推理完全在用户设备上运行时，数据永远不会离开该设备。这不是政策承诺或合同保证，而是架构事实。”

云端 API 无论如何承诺数据安全，用户输入必须经由网络传输至第三方服务器这一事实无法改变。

但需注意：Google 近期修改了 Chrome 设置中“On-device AI”的措辞，删除了“不将你的数据发送到 Google 服务器”的表述。虽然 Google 发言人表示“数据处理方式未变”，这一改动仍在社区引发了广泛担忧。

4.5 对比总结

评估维度	设备端 (Prompt API)	云端 (Gemini API)
成本	✅ 零边际成本	❌ 按 token 付费
隐私	✅ 数据不离设备	⚠️ 需经网络传输
延迟	✅ 无网络往返	❌ 受网络影响
离线可用	✅ 支持	❌ 需网络
模型质量	❌ 小模型能力有限	✅ 大模型高质量
上下文长度	❌ 4K 限制	✅ 百万级
工具调用	❌ 不支持	✅ 完整支持
跨浏览器	❌ Chrome 专属	✅ 任何平台
硬件门槛	❌ 要求高	✅ 无硬件要求
用户覆盖	⚠️ ~60% 桌面用户	✅ 100% 有网络用户

五、竞品与生态：不是 Chrome 一个人的游戏

5.1 浏览器战场：Edge 的 Phi-4 与 Firefox 的反对

Microsoft Edge 也在探索类似的设备端 AI 路径，通过 Prompt API 调用 Phi-4 mini-instruct 模型。

一份 2026 年 2 月发布的对比报告揭示了残酷的现实：

任务类型	Chrome (Gemini Nano)	Edge (Phi-4)
生成类任务失败率	15.17%	24.29%
分类任务失败率	23.93%	29.58%

两个浏览器的设备端 AI 在生成类任务中均有超过 15% 的失败率——这意味着每 6-7 次调用就有 1 次失败。这对于生产级应用是不可接受的。

Mozilla Firefox 则选择了另一条路——坚决反对。

5.2 标准之战：Mozilla、Apple、W3C TAG、Microsoft 的联合反对

Chrome 148 发布 Prompt API 时，Mozilla、Apple 的 WebKit 团队、W3C 技术架构组（TAG）、Microsoft 以及一名参与批准该功能的 Chrome 工程师都提交了正式反对意见。

Mozilla 开发者关系负责人 Jake Archibald 在 2026 年 5 月 6 日的帖子中（获得超过 2000 个赞和约 13 万次浏览）总结道：

“Mozilla：反对。WebKit：反对。Microsoft：多项担忧。W3C TAG：多项担忧。开发者：多数负面。Chrome：照常发布。这是 Web 标准的悲哀时刻。 ”

Mozilla 的正式立场文件（standards-positions issue #1213）指出，Prompt API 对 Web 平台的可互操作性、可更新性和中立性产生了严重的负面影响。

核心争议点包括：

1. 模型耦合：开发者会针对 Gemini 的特定行为（拒绝模式、输出风格）调优提示词，导致 Firefox/Safari 用户遭遇功能破损。
2. 政策锁定：使用 Prompt API 意味着接受 Google 的“生成式 AI 禁止使用政策”——该政策禁止“令人不安”等内容（并非违法，只是 Google 的单方判断）。
3. 资源消耗：任何顶级网页都可以静默调用 AI 推理——消耗用户的电池、CPU 和 GPU 资源，却无需进一步征求许可。Apple WebKit 团队指出这是一个根本性设计缺陷：调用 API 的网站获得收益，用户支付硬件成本。

Web 标准专家 Mat Marquis 甚至发文抨击，称 Prompt API 是“我所见过的最明目张胆的 Web 标准霸凌尝试”，严重程度超过此前备受争议的 AMP 和 Manifest V3。

5.3 生态工具：早期实践者

尽管争议不断，开发者社区已开始探索 Prompt API 的实际应用：

• Sylius 翻译插件：在 Sylius 后台为每个可翻译字段添加翻译按钮，所有推理在设备端完成，数据永不离开浏览器。
• Browser Agent AI 扩展：使用 Prompt API 和/或本地 Ollama 模型的浏览器自动化代理，可理解自然语言命令并自主执行浏览器任务。
• trAIlblazers 标签生成：通过 JSON Schema 约束输出，从预定义列表中建议分类标签。

六、安全风险：被忽视的另一面

6.1 静默下载与隐私争议

2026 年 5 月，安全研究员 Alexander Hanff（ThatPrivacyGuy）报告称，Chrome 在用户不知情、未同意的情况下下载约 4GB 的 Gemini Nano 模型文件。

更令人担忧的是：

• 即使用户手动删除该文件，Chrome 会重新下载
• Google 虽然在 2026 年 2 月提供了通过 Chrome 设置禁用和删除模型的选项，但默认状态是 “开启”
• 整个下载过程约需 15 分钟，用户完全不知情

Google 的回应是：模型下载由首次调用 create() 触发，有时 availability() 也可能触发。但这并未平息隐私倡导者的质疑——用户是否有权在下载 4GB 文件前被告知并选择？

6.2 Prompt 窃取与恶意扩展

安全专家已发出警告：恶意 Chrome 扩展程序可秘密监控和窃取用户的 AI 对话。这些扩展伪装成广告拦截器，实际上在读取对话记录、模型元数据和订阅信息。

Expel 公司警告称，这类扩展打开了多种风险的大门，包括身份盗窃、定向钓鱼攻击以及敏感数据在地下论坛出售。

6.3 提示注入攻击

虽然 Prompt API 本身相对较新，但浏览器 AI 生态已暴露出提示注入漏洞。例如，Chrome 的 Gemini Live 功能曾存在 CVE-2026-0628 漏洞，允许低权限扩展通过提示注入劫持摄像头、麦克风和本地文件访问。

间接提示注入攻击也日益频繁，攻击者利用日历邀请等载体绕过隐私控制实施侦察。

6.4 资源耗尽攻击

任何顶级网页都可以静默调用 AI 推理——消耗用户的电池、CPU 和 GPU 资源，而无需进一步征求许可。这意味着恶意网站可以：

• 通过高频调用耗尽用户设备电量
• 占用 GPU 显存影响其他应用性能
• 在后台持续运行导致设备发热

目前 Chrome 未提供针对这类攻击的防护机制。

七、选型决策框架

7.1 什么场景选择 Prompt API（设备端）？

✅ 高频、低复杂度任务

• 实时文本摘要、翻译、分类
• 客户端输入解析与格式化
• 自动补全、内联改写

✅ 隐私敏感场景

• 医疗笔记、法律文档、个人日记处理
• 企业内部数据（财务预测、商业机密）

✅ 成本敏感的大规模部署

• 百万级用户的免费功能
• 不想承担 token 账单的创业项目

✅ 离线优先应用

• 现场数据采集
• 嵌入式信息亭
• 无网络环境下的生产力工具

7.2 什么场景必须用云端 Gemini API？

✅ 高复杂度、需要大模型能力的任务

• 需要 100 万+ token 上下文的文档分析
• 需要工具调用/函数调用的 Agent 工作流
• 多语言高质量翻译（非英语）

✅ 跨浏览器兼容性要求

• 必须支持 Firefox、Safari 用户

✅ 低硬件门槛要求

• 面向移动设备用户
• 面向低配置设备用户

✅ 对失败率零容忍的生产环境

• 15%+ 的失败率不可接受的关键业务流程

7.3 推荐架构：混合模式

现实世界的 AI 应用不应在设备端和云端之间二选一——而应该两者兼用。

async function getAIResponse(prompt) {
  // 1. 优先尝试设备端
  if ('LanguageModel' in window) {
    const status = await LanguageModel.availability();
    if (status === 'available') {
      try {
        const session = await LanguageModel.create({ systemPrompt: '...' });
        return await session.prompt(prompt);
      } catch (e) {
        console.warn('Device AI failed, falling back to cloud:', e);
      }
    }
  }
  
  // 2. Fallback 到云端 API
  return await callCloudGeminiAPI(prompt);
}

这种混合架构：

• 在支持的设备上零成本运行
• 在不支持的设备上自动降级到云端
• 对用户透明，体验一致

Trip.com 等企业已采用此模式，将个性化旅行摘要扩展到数百万用户。

八、结论：AI 的“边缘计算时刻”

Chrome Prompt API 的发布标志着 AI 从云端向边缘设备迁移的关键转折点。

从技术角度看，它解决了 Web 应用集成 AI 的三大痛点——成本、隐私、延迟。但从生态角度看，它引发了关于 Web 标准中立性、浏览器垄断、用户知情权 的深刻争议。

对于开发者，我的建议是：

1. 保持务实：Prompt API 是强大的工具，但不是银弹。硬件门槛（仅 ~60% 桌面用户达标）和高失败率（15%+）意味着它目前无法作为唯一的 AI 基础设施。

2. 拥抱混合架构：设备端 + 云端 fallback 是最稳妥的工程实践。既享受零成本推理的收益，又保证 100% 的用户覆盖率。

3. 关注标准演进：Prompt API 的标准化之路充满不确定性。Mozilla、Apple、Microsoft 的反对意味着它可能长期停留在“Chrome 专属功能”而非“Web 标准”。

4. 重视安全与隐私：静默下载、提示注入、恶意扩展窃取对话等风险真实存在。在采用 Prompt API 时，需在应用层做好防护。

5. 场景驱动选型：高频、简单、隐私敏感 → 设备端；复杂、长上下文、跨浏览器 → 云端。没有“最好”的方案，只有“最合适”的方案。

正如一位开发者所言：“2026 年是设备端 AI 停止成为研究玩具的一年。”Prompt API 可能还不完美，争议可能还会持续，但它已经不可逆转地改变了 Web 应用与 AI 的关系。对于开发者来说，现在正是躬身入局、探索边界的最佳时机。