Chrome 从 138 版本开始把 Gemini Nano 塞进了浏览器，官方说法是”用 AI 能力改善用户体验、保护用户隐私”。听起来很美。我们在自己的 B 端产品里试了三周，结论有点分裂：有些场景它是真的省了一整条链路，有些场景它是真的慢到不能用，而它最大的价值可能根本不在前面两者——在于”这个请求根本不需要离开设备”。
这篇文章是那三周的账：延迟、质量、可用性，以及最关键的——什么任务该交给它，什么任务坚决不能。
一、先搞清楚 Chrome 内置 AI 到底给了什么
多数教程把它讲成”浏览器里有个大模型”，这是错的。Chrome 内置 AI 是一组 Web API，各自封装不同能力，目前都在早期阶段：
| API | 能力 | 成熟度 | 我们的使用情况 |
|---|---|---|---|
| Prompt API | 通用文本生成、摘要、改写 | 实验性，需手动开启 | 核心测试对象 |
| Summarizer API | 长文本摘要 | 相对可用 | 试过，效果一般 |
| Translator API | 端侧翻译 | 早期 | 对比过云端，差距明显 |
| Language Detector | 语种识别 | 可用 | 用了，轻量准确 |
| Writer / Rewriter | 写作与改写 | 最早期 | 稳定性不足，弃用 |
第一个坑在开启方式。这些功能默认不对普通网页开放，需要用户在 chrome://flags 里手动启用，或者你的站点加入 Chrome 的早期测试计划（Origin Trial）。这意味着它现在不能被当作”用户打开就能用”的能力来设计产品——它是预览版能力，不是基础能力。
二、Prompt API 的真实延迟账
我们把 Prompt API 和同等规模的云端 API 做了对照。模型是 Gemini Nano（约 3B 参数量级），对比对象是某个主流云端小模型。测试任务是统一的：输入一段 600 字中文产品描述，输出五点结构化卖点。
| 指标 | Chrome 端侧 | 云端小模型 | 备注 |
|---|---|---|---|
| 首次调用（含模型加载） | 18.4 s | 1.2 s | 端侧需下载/初始化模型 |
| 后续调用（稳态） | 1.1–2.6 s | 1.4 s | 端侧反而略优 |
| 生成速度（token/s） | 约 22 | 约 55 | 受设备 CPU 限制明显 |
| 低端笔记本表现 | 4–7 s | 1.6 s | 不可用区间 |
| 断网场景 | 完全可用 | 不可用 | 端侧唯一决定性优势 |
把这张表读清楚，端侧 AI 的产品定位就出来了：它的稳态延迟不比云端差，但它的稳定性完全取决于用户设备。同样一段代码，在高配工作站上 1.1 秒，在两年前的办公笔记本上 7 秒。你没办法给用户一个稳定的体验承诺。
三、质量：能用，但有两条硬边界
3B 量级的模型，能力边界比云端旗舰窄得多。我们拿 120 个真实产品描述任务做了人工评分（1–5 分，两名标注员）：
| 任务类型 | 端侧得分 | 云端小模型 | 结论 |
|---|---|---|---|
| 提炼已有文本要点 | 3.9 | 4.2 | 基本可用 |
| 改写句式/调整语气 | 3.4 | 4.0 | 可用，偶有不通顺 |
| 信息分类打标签 | 4.1 | 4.3 | 可用 |
| 需要事实推理的任务 | 1.8 | 2.6 | 不可用 |
| 长文档综合分析 | 2.1 | 3.4 | 不可用 |
规律很清晰：端侧模型处理”对已有信息的重组”是合格的，处理”需要理解和推理的任务”是不合格的。它能帮你把一段话改得更顺、提取出要点、判断这段话是投诉还是咨询；但它不能回答”这个产品描述里有没有不实承诺”，那种需要上下文理解的判断，它会自信地给出错误答案。
四、真正的价值：零成本、零外发
讲完缺点，说它真正不可替代的那一点。以下三类任务，端侧即使慢、即使笨，也是唯一正确的选择：
- 数据不能出设备的场景。医疗记录、内部财务、未公开的法务文档。端侧处理意味着”请求从未离开过电脑”，这不是加密传输能比拟的保证——因为根本没有传输。对这类场景，延迟是次要问题，合规是主要问题。
- 请求量极大、单位价值极低的任务。比如给一万条用户评论自动打情绪标签。云端按 token 计费，一万条就是一万次的费用；端侧模型的边际成本是电费。
- 离线/弱网环境的可用性。我们测试过在飞行模式下完成摘要和分类任务，全部正常。这是云端 API 永远做不到的。
五、落地的三条工程建议
- 必须做能力探测和降级。调用前先检查
window.LanguageModel是否存在、模型是否已下载、设备性能档位。检测不到就自动切到云端或者隐藏功能，永远不要让用户看到一个加载了三秒还没有反应的按钮。 - 把首次加载的等待显式告知用户。18 秒的模型下载如果发生在用户点击之后，会被理解为”页面卡死了”。我们的做法是在页面闲置时预加载模型，把成本移到用户不注意的时刻。
- 任务分级，不是全用或全不用。正确的架构是混合的：分类、打标、摘要这类轻任务走端侧；推理、长文档、创造性任务走云端。两条链路并存，按任务类型和用户设置路由，这才是当下最实际的方案。
六、和其他方案的对比
| 方案 | 延迟 | 质量 | 隐私 | 成本 | 适合场景 |
|---|---|---|---|---|---|
| Chrome 内置 AI | 中 | 中低 | 最高 | 零边际 | 轻任务、隐私敏感、离线 |
| 本地部署（Ollama 等） | 低 | 可控 | 高 | 硬件摊销 | 企业内部工具 |
| 云端小模型 API | 低 | 中 | 中 | 按量计费 | 通用场景 |
| 云端旗舰模型 | 中 | 最高 | 中低 | 最高 | 复杂推理 |
值得注意：它并没有取代本地部署方案，而是抢走了其中一部分场景。以前”想在用户浏览器里跑点 AI”基本只有 WebAssembly 跑小模型这一条路，麻烦且性能差；现在浏览器原生给了接口。它的对手不是 Ollama，是”为了隐私而不得不做的云端脱敏方案”。
总结
三周测试的结论可以压成三句话：Chrome 内置 AI 目前是预览能力，不是可以无条件依赖的基础能力，必须先探测再降级；它的质量边界清晰——重组已有信息合格，推理任务不合格；它真正不可替代的价值是零边际成本和数据不离开设备，在这两点上，再强的云端 API 也替代不了。
判断一个任务该不该交给它，问一个问题：这个请求失败了、慢了、或者答错了，用户能接受吗？能，就用；不能，就上云端。这个标准比任何性能测试都简单可靠。
互动提问：你们的产品里有没有那种”又需要 AI、又不敢把数据发出去”的需求？现在是用什么方案兜住的？
互动提问：如果端侧 AI 的推理质量短期追不上云端，你觉得最先被它吃掉的会是哪一类功能？
— IMAI 编辑部 | 2026-10-30