Opera推WebAI，本地模型进浏览器

Opera把本地AI模型开放给了网页

Opera在10月27日发布WebAI提案，试图让网站和浏览器扩展直接使用运行在用户设备上的AI模型，而不必把每次推理请求都发送到云端服务器。首批能力将进入Opera One，Opera GX与Opera Neon随后跟进。

**WebAI是一套面向网站和浏览器扩展的本地AI访问标准提案，它为网页提供统一接口，以调用由浏览器管理并在用户设备上运行的模型。**这意味着开发者可以把摘要、改写、翻译、分类乃至部分智能体能力放进网页，却不需要自行处理不同操作系统、推理框架和硬件后端之间的差异。

这次发布最值得注意的地方，不是Opera又给浏览器侧边栏增加了一个聊天机器人，而是它试图把本地模型变成一种Web平台能力。过去浏览器中的AI功能通常属于浏览器厂商：网站只能展示结果，无法直接使用浏览器已经下载和加载的模型。WebAI想要改变的，正是这层边界。

不过，**WebAI目前更准确的身份是Opera提出的标准化方案，而不是已经获得W3C等标准组织批准、并被主流浏览器共同实现的正式Web标准。**Opera可以率先在自家产品中实现接口，但只有Chrome、Edge、Safari、Firefox等浏览器跟进，WebAI才可能从厂商功能变成开发者可以普遍依赖的平台能力。

WebAI解决的是“最后一公里”问题

**WebAI解决的核心问题，是网页缺少一个模型无关、硬件无关的高层AI接口。**今天在浏览器里运行模型并非不可能，开发者已经可以使用WebGPU、WebAssembly或Transformers.js加载模型，但这条路线仍然需要应用自己下载权重、管理缓存、选择量化版本，并处理显存不足和浏览器兼容问题。

现有方案更像是给每个网站一套零件，让开发者自己组装发动机；WebAI则希望由浏览器准备发动机，网站只需要说明要完成什么任务。浏览器负责模型发现、资源调度、权限确认和硬件适配，网页只处理业务逻辑与用户界面。

一次典型的WebAI任务可能经过以下几层：

1. 网站或扩展请求执行摘要、文本生成或其他AI任务。
2. 浏览器检查网站权限、模型可用性和设备资源。
3. 浏览器选择兼容的本地模型及推理后端。
4. 模型在用户设备上处理数据，并将结果返回网页。
5. 浏览器在任务结束后继续管理内存、模型缓存与后台资源占用。

**模型无关是WebAI能否形成生态的关键。**Opera强调该方案可以配合多种AI模型，而不是将网站绑定到某一家模型供应商。Opera此前已经测试过Meta的Llama、Google的Gemma、Mistral AI的Mixtral以及Vicuna等本地模型，这些模型在参数规模、许可证、上下文长度和硬件需求上都有明显差异。

这种抽象方式与浏览器处理摄像头、麦克风和图形计算的思路相似：网页不需要知道用户的摄像头来自哪家厂商，也不必直接操作显卡驱动。问题在于，文本生成模型的输出差异远大于摄像头或音频设备，换一个模型不仅会改变速度，也会改变回答风格、事实准确率和安全边界。

WebAI不是WebGPU的替代品

**WebAI与WebGPU、WebNN处在不同抽象层级，三者并不是直接替代关系。**WebGPU让网页访问GPU的通用计算能力，WebNN面向机器学习计算图与硬件加速，而WebAI试图向网页提供可以直接完成任务的模型能力。

| 方案 | 抽象层级 | 模型由谁管理 | 开发者控制力 | 主要适用场景 | |---|---|---|---|---| | WebAI | 高层AI任务接口 | 浏览器或用户 | 较低 | 摘要、改写、翻译、分类、生成 | | WebNN | 神经网络计算图接口 | 应用或运行时 | 中等 | 跨硬件执行机器学习模型 | | WebGPU | 通用GPU计算接口 | 应用 | 高 | 自定义推理引擎、图形和并行计算 | | WebAssembly | 通用字节码运行环境 | 应用 | 高 | CPU推理、跨平台运行时 | | 云端模型服务 | 远程服务接口 | 服务提供方 | 取决于服务 | 大模型推理、联网检索、复杂智能体 |

**开发者需要控制具体模型和推理参数时，WebGPU等底层能力仍然不可替代。**例如，一个图像编辑器可能需要固定的扩散模型、特定量化方式和可复现输出，此时把模型选择完全交给浏览器并不合适。

**开发者只关心任务结果时，WebAI的吸引力会明显更大。**邮件网站只需要把一段文字改得更正式，文档应用只需要生成摘要，论坛只需要判断内容类别，这些场景通常不值得为每个用户重复部署完整推理链路。

本地运行最直接的价值是数据不离开设备

**本地AI的首要优势是敏感输入可以留在用户设备上。**网页中的邮件正文、未公开文档、浏览历史和企业内部信息，不必为了摘要或分类上传到第三方服务器，这会降低传输和云端留存带来的风险。

本地运行并不等于绝对隐私，因为网页仍然可能通过其他请求收集输入或输出。WebAI真正能保证到什么程度，取决于浏览器是否提供清晰的权限提示、数据流限制和开发者审计机制，而不能只依赖网站的一句“本地处理”声明。

**本地AI的第二个优势是边际推理成本接近于零。**云端模型通常按照输入与输出量计费，当摘要、改写和分类被嵌入高频网页操作后，即使单次费用很低，累计成本也会成为产品扩张的阻力。本地方案把主要成本转移到用户已有的CPU、GPU或NPU，以及首次下载模型所消耗的带宽与磁盘空间。

**本地AI的第三个优势是离线可用和更稳定的短任务延迟。**模型加载完成后，网页不再依赖网络往返和远端队列，短文本改写、页面分类等任务有机会获得更快响应；但大模型生成长文本时，性能仍取决于设备内存带宽、模型规模和量化精度。

本地模型也不是免费的午餐。Opera早期本地LLM测试所涉及的模型文件通常达到数GB级别，历史报道给出的下载空间约为2GB至10GB。对于拥有独立显卡的台式机，这个代价可能可以接受；对于低内存笔记本、旧手机或存储空间紧张的设备，它足以直接阻止功能启用。

真正的难点不是把模型跑起来，而是管起来

**WebAI面临的第一道门槛是硬件碎片化。**同一个网页可能运行在32GB内存的高端电脑、8GB内存的轻薄本或移动设备上，而不同芯片对FP16、INT8、INT4和专用NPU算子的支持并不一致。

如果浏览器自动选择模型，网站就很难预测输出质量；如果网站强制指定模型，WebAI又会退回由开发者管理权重和兼容性的旧路。比较现实的方案，是标准定义设备能力与任务能力，让网站声明最低要求，并为不支持本地推理的设备准备降级路径。

**WebAI面临的第二道门槛是模型结果不可移植。**传统Web API通常有相对明确的输入输出，而生成式模型带有概率性，同一个提示在Llama、Gemma和Mixtral上可能得到完全不同的结果。开发者因此不能把“支持文本生成”理解为“输出行为一致”。

标准需要回答一系列很具体的问题：

• 网站能否指定模型系列、参数规模或最低上下文长度？
• 浏览器是否向网站暴露模型名称、量化精度和版本？
• 用户更换本地模型后，网站行为是否会无提示变化？
• 同一模型更新权重后，应用如何做回归测试？
• 模型不支持某种语言或任务时，接口如何返回能力不足？

**WebAI面临的第三道门槛是资源滥用。**一个恶意网页如果能持续占用GPU或NPU，就可能造成耗电、发热、风扇噪声和系统卡顿；多个标签页同时调用模型，还可能耗尽内存并拖慢整个浏览器。

浏览器因此需要像管理摄像头和后台标签页一样管理AI权限。合理的机制至少应包括用户授权、前台优先级、并发限制、任务取消、资源配额和清晰的运行指示，否则“本地AI”很容易变成新的网页挖矿式滥用入口。

**WebAI面临的第四道门槛是新的安全攻击面。**网页内容可能通过提示注入操纵本地模型，扩展程序也可能诱导模型读取不应访问的数据。模型虽然运行在本地，但如果权限边界过宽，攻击者不需要把模型搬到云端，也能利用它整理、筛选甚至泄露本机信息。

Opera想把浏览器变成AI运行时

**Opera的战略不只是增加AI功能，而是争夺本地模型的分发与调度入口。**谁负责下载模型、分配硬件资源、展示授权弹窗和决定默认模型，谁就掌握了浏览器AI生态中的关键控制层。

Opera在2023年开始围绕Opera One和Aria强化AI浏览器定位，2024年又在开发者版本中加入本地LLM测试。此前的能力主要服务于浏览器自身，而WebAI向前走了一步：让第三方网站和扩展也能使用这套本地模型基础设施。

这一步对Opera尤其重要。与Chrome、Edge和Safari相比，Opera缺少操作系统、搜索引擎或办公软件生态作为后盾，但它可以通过率先开放浏览器AI能力吸引开发者。对于规模较小的浏览器厂商，开放标准也是放大影响力的一种办法。

**WebAI能否成为标准，最终仍由竞争对手而不是Opera自己决定。**Google已经在Chrome生态中推进内置AI与WebGPU，Microsoft拥有Windows、Edge和Copilot体系，Apple则控制Safari与设备端芯片。它们都有能力实现类似接口，却未必愿意接受Opera设计的模型发现、权限和能力描述方式。

| 参与方 | 可能获得的价值 | 可能产生的顾虑 | |---|---|---| | 浏览器厂商 | 掌握模型分发、权限和硬件调度 | 维护成本、资源滥用、安全责任 | | 网站开发者 | 降低推理费用，获得离线能力 | 输出不一致、兼容性复杂 | | 模型开发者 | 增加模型触达和设备端分发 | 许可证、版本管理、量化质量 | | 用户 | 隐私更强、响应更快、可离线使用 | 占用存储、电量和内存 | | 云端模型厂商 | 可提供本地与云端混合体验 | 部分轻量任务被本地模型替代 |

最先受益的不会是通用聊天机器人

**WebAI最适合的是输入较短、容错空间较大、隐私敏感且重复频率高的任务。**页面摘要、文字润色、标签分类、表单辅助填写和离线翻译，都比复杂搜索、深度研究或长链智能体更适合作为首批场景。

以下几类产品可能较早受益：

• **企业内部工具：**在不上传合同、邮件和会议记录的情况下完成摘要与分类。
• **内容创作工具：**为编辑器提供改写、语气调整、标题建议和关键词提取。
• **无障碍功能：**本地生成图片描述、简化长文本或调整表达方式。
• **浏览器扩展：**分析当前页面内容，同时减少将完整页面上传到外部服务器的需求。
• **教育应用：**在网络不稳定的环境中提供基础问答、语法修改和文本解释。

**大型联网任务仍然更适合云端模型。**需要数十万Token上下文、实时搜索、多模态生成或高质量复杂推理时，消费级设备上的小模型暂时无法稳定替代数据中心中的大型模型。

未来更可能出现的是本地与云端混合架构：隐私敏感、低难度任务优先在本地执行，复杂任务在获得用户同意后交给云端。WebAI如果能够提供清晰的能力检测，将成为这种分层调度中的本地入口，而不是消灭云端AI。

现在应该如何看待WebAI

**WebAI是一个方向正确但仍需验证的浏览器平台提案。**它把本地AI从浏览器厂商的专属功能，推进为网站可能调用的公共能力，这比再增加一个AI侧边栏更有长期价值。

开发者现在不宜把WebAI视为可以直接依赖的跨浏览器标准。Opera One的首发实现适合用于验证产品场景、权限设计和本地模型体验，但正式产品仍应保留无AI模式、传统前端逻辑或云端能力等降级方案。

接下来最值得观察的并非Opera支持多少个模型，而是三件事：接口规范是否公开稳定、其他浏览器是否参与讨论，以及模型权限和资源配额是否足够透明。缺少这三点，WebAI只是Opera的专有功能；具备这三点，它才有机会成为浏览器时代的新基础设施。

**浏览器可能成为本地AI最自然的入口，但“能运行”距离“能成为标准”还有很长一段路。**Opera已经把第一版答案摆上桌面，现在轮到浏览器厂商、模型开发者和Web社区决定是否愿意坐到同一张桌前。

参考来源

• iThome：Opera让用户可下载并在本机执行、测试LLM：介绍Opera早期本地模型测试，以及Llama、Gemma、Mixtral和Vicuna等模型支持情况。
• GPUWeb规范仓库：WebGPU标准规范与浏览器GPU计算能力的权威技术资料。
• WebNN规范仓库：Web Neural Network API的规范草案与设计讨论。
• Transformers.js文档：介绍如何直接在浏览器中运行Transformer模型，可用于理解WebAI出现前的开发路径。