多年来，浏览器是应用程序的漂亮面孔，而云则是困难的事情发生的地方。用户写入、点击、上传文件；前端将所有内容发送到服务器；服务器调用模型；答案回来了。

该方案仍然非常有用，但它不是免费的。每次呼叫都会带来延迟、成本、网络依赖性和隐私问题。如果用户正在写一个句子并需要建议，则需要半秒的时间。如果您对数千个小输入进行分类，几分钱就变成了真钱。如果文本敏感，将其从设备发送出去并不是一个中立的选择。

这就是 WebGPU 和设备端人工智能大肆宣传的原因。不是因为我们明天将在浏览器中运行每个模型。因为一些智能功能可以更加贴近用户。

并非一切都必须成为本地化

该争论的幼稚版本是：“云与设备”。有用的版本是混合版本。

有些任务在设备上看起来很棒：简短摘要、语言检测、轻度重写、简单分类、图像过滤器、小视觉模型、具有即时反馈的创意体验。

其他任务在云中仍然更好：复杂推理、前沿模型、服务器端数据、集中审计、统一质量、必须仔细控制每个步骤的工作流程。

健康的架构在运行时决定：

浏览器不必战胜云。它必须使云免于执行不需要在那里完成的工作。

为什么 WebGPU 很重要

WebGPU 是一种现代 API，用于从浏览器使用 GPU。它不仅仅是为了更好的 3D 图形。它也很重要，因为它公开了适合计算的原语：并行工作负载、着色器、更接近 GPU 擅长的管道。

对于人工智能、科学可视化、3D 编辑器、视频滤镜和创意工具来说，这种差异是显而易见的。 WebGL 为网络做出了很多贡献，但 WebGPU 诞生了一个更适合当前的模型。

然而，首先要编写的不是着色器。这是一个清醒的特征检测：

export async function requestWebGpuDevice() {
  if (!('gpu' in navigator)) {
    return null;
  }

  const adapter = await navigator.gpu.requestAdapter({
    powerPreference: 'high-performance',
  });

  if (!adapter) {
    return null;
  }

  return adapter.requestDevice();
}

这个功能说明了一件重要的事情：WebGPU 并不是每个设备都被授予的权利。这是一种有待验证的能力。有些浏览器不完全支持它，有些 GPU 有限制，有些企业环境禁用功能，有些用户使用的是普通硬件。

内置AI：当浏览器自带模型时

Chrome 正在推出内置 API，用于执行本地提示、摘要、写作、重写、翻译、语言检测和校对等任务。这个想法很有趣：浏览器管理模型、可用性和更新；该应用程序使用更接近平台的API。

如果运作良好，它会发生很大的变化：

• 简单任务的服务器调用更少；
• 可能保留在设备上的数据；
• 更低的延迟；
• 线下或半线下体验；
• 写作和翻译的用户体验更加自然。

但它应该被视为渐进增强。一些 API 是稳定的，其他 API 处于原始试用或预览阶段，其他 API 仍然依赖于版本、语言和设备。

type LocalCapability = 'available' | 'downloadable' | 'unsupported';

export async function getLocalSummarizerCapability(): Promise<LocalCapability> {
  const SummarizerApi = (globalThis as any).Summarizer;

  if (!SummarizerApi?.availability) {
    return 'unsupported';
  }

  const availability = await SummarizerApi.availability();

  if (availability === 'available') return 'available';
  if (availability === 'downloadable') return 'downloadable';

  return 'unsupported';
}

具体代码将会改变，但模式仍然存在：您检查可用性、解释所有下载、提供后备方案并衡量质量。

Fallback并不是一个悲伤的B计划

云回退并不是失败。它是产品的一部分。

interface AiRequest {
  task: 'summarize' | 'rewrite' | 'classify';
  input: string;
}

interface AiResult {
  output: string;
  runtime: 'local' | 'cloud';
}

export async function runAiTask(request: AiRequest): Promise<AiResult> {
  const local = await tryLocalAi(request);

  if (local) {
    return { output: local, runtime: 'local' };
  }

  const cloud = await fetch('/api/ai', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(request),
  }).then((res) => res.json());

  return { output: cloud.output, runtime: 'cloud' };
}

这种架构允许您逐步改进。那些拥有本地支持的人可以获得更好的延迟和隐私。那些没有它的人仍然可以使用该功能。您可以测量本地请求的百分比、时间、错误、内存、感知质量和成本。

如果没有指标，设备上的人工智能就会成为一种审美选择。有了指标，它就成为了产品杠杆。

模型的用户体验很重要

如果浏览器需要下载模型，用户就会感知到它。不要将其隐藏在模糊的旋转器后面。最好明确一点：“我们准备模型以便更快甚至离线使用此功能。”

很好的体验：

• 显示准备状态；
• 不会阻塞整个页面；
• 允许您继续进行云回退；
• 避免电池和内存意外；
• 尽可能记住模型；
• 用一个具体的句子解释这一好处。

最糟糕的是“智能”功能似乎已损坏，因为它正在默默地下载某些内容。

隐私：更好，但不会自动保护

在设备上处理数据可能是一个很大的优势。电子邮件草稿、内部文档或个人笔记不必离开浏览器即可收到建议。

然而，本地并不自动意味着安全。但是，您需要考虑：

• 跨站脚本攻击；
• 意外日志；
• 数据保存在存储器中；
• 来自不受信任内容的提示注入；
• 授予模型的权限；
• 自动操作中使用的输出。

如果本地模型可以读取网页然后填写表单，则该页面可以尝试对其进行操作。如果可以调用工具，则需要确认。如果它产生结构化输出，则必须对其进行验证。它在设备上运行的事实减少了一些隐私风险，但并没有消除安全模型。

真正有趣的地方

文字只是一个开始。 WebGPU 使 Web 体验变得可信，直到最近才看起来像是本机应用程序：

• 复杂的 3D 编辑器；
• 浏览器中的高斯泼溅；
• 实时视频过滤器；
• 轻量级CAD；
• 科学可视化；
• 具有即时预览功能的创意工具；
• UI 附近的视觉推理；
• 更雄心勃勃的浏览器游戏。

在这里，前端、图形和机器学习开始融合。这是一个有点尴尬的领域，但也是一个丰富的领域：浏览器重新成为一个严肃的应用程序平台，而不仅仅是我们放置表单和仪表板的地方。

生产前检查清单

在向用户展示设备上的功能之前，我会检查：

1. 目标浏览器和设备。
2. 云回退或优雅降级。
3. 下载时间和模型缓存。
4. 平均硬件上的内存和电池。
5. 与云版本相比的质量。
6. 隐私政策和用户消息。
7. 使用恶意输入进行测试。
8. 本地和云运行时的单独指标。
9. 计划更新或禁用模板。

这是一个具体的清单，因为问题是具体的。缓慢、脆弱或不透明的人工智能功能并不会因为在浏览器中运行而变得更好。

正确的妥协

我不相信未来是“设备上的一切”。而且我认为云也不会仍然是唯一合理的推理场所。最有可能的未来是一种混合：本地化，当它改善延迟、隐私或成本时；本地化，当它改善延迟、隐私或成本时；本地化，当它改善延迟、隐私或成本时。当需要质量、更新数据和集中控制时使用云。

WebGPU、WebNN 和内置 AI API 并不能让浏览器无所不能。他们让他更加成熟。对于那些构建网络产品的人来说，这是一个巨大的新闻。

有用的来源

• WebGPU API - MDN
• WebGPU 规范 - W3C
• 内置人工智能 - Chrome 开发者版
• 内置 AI API - Chrome 开发者版
• WebNN API