探索 Transformers.js 中的跨源存储 API 提案

随着 Transformers.js 的出现，基于浏览器的机器学习（Web ML）领域发生了翻天覆地的变化。通过允许开发人员直接在浏览器中运行最先进的模型，它为保护隐私、低延迟的应用打开了大门。然而，一个显著的瓶颈仍然存在：模型大小。每次用户访问使用相同架构的不同站点时，都要下载 500MB 或 1GB 的模型，这是非常低效的。这就是拟议中的跨源存储 API（Cross-Origin Storage API）发挥作用的地方，它承诺了一个可以安全地在 Web 上共享大型资产的未来。

虽然客户端执行具有革命性，但许多开发人员仍然需要服务器端推理的强大动力和稳定性。对于那些构建生产级应用程序的人来说，n1n.ai 提供了卓越的 LLM API 聚合服务，确保当浏览器的本地计算不足时，您的应用程序可以无缝回退到高速、可靠的云端模型。

核心问题：存储分区化（Storage Partitioning）

现代浏览器采用了称为“存储分区”的安全特性。这意味着，如果站点 A 和站点 B 都使用来自同一 CDN 的相同模型文件，它们不能共享该文件的缓存版本。每个站点必须在自己隔离的存储（IndexedDB 或 Cache API）中下载并存储自己的副本。对于 Web ML 而言，模型通常有数百兆字节，这导致了：

1. 冗余带宽消耗：用户不得不为多次下载相同的权重支付流量成本。
2. 存储膨胀：用户的本地磁盘空间被重复的数据占用。
3. 延迟增加：初次访问新站点时感觉很慢，因为必须从网络获取模型。

什么是跨源存储 API？

跨源存储 API 是隐私沙盒（Privacy Sandbox）计划中的一个提案。其目标是允许不同的源（Origin）访问一个共享的存储空间，用于存储特定的、非敏感的资产，如机器学习模型或高分辨率纹理。与传统的 Cookie 或本地存储不同，该 API 在设计时充分考虑了隐私，在防止跨站点追踪的同时实现了资源共享。

在 Transformers.js 的上下文中，这将允许一个集中的“模型中心”源（如 Hugging Face）存储任何其他站点都可以请求的权重。如果权重已经存在于共享存储中，浏览器可以直接提供，而无需进行网络请求。

Transformers.js 中的技术实现

Transformers.js v3 已经在为优化存储奠定基础。目前，它使用 Cache API 在本地存储模型。集成拟议的跨源存储 API 将涉及 env.cacheDir 和获取逻辑的处理方式转变。

考虑以下共享加载器的假设性实现：

import { pipeline, env } from '@xenova/transformers'

// 假设检查跨源存储支持
if (navigator.storage && navigator.storage.getSharedStorage) {
  const sharedStorage = await navigator.storage.getSharedStorage()
  env.customFetch = async (url) => {
    // 尝试从共享存储获取
    const cachedResponse = await sharedStorage.get(url)
    if (cachedResponse) return cachedResponse

    // 如果不存在，则从网络获取并存入共享存储
    const networkResponse = await fetch(url)
    await sharedStorage.set(url, networkResponse.clone())
    return networkResponse
  }
}

const classifier = await pipeline(
  'sentiment-analysis',
  'Xenova/distilbert-base-uncased-finetuned-sst-2-english'
)

这段代码展示了我们如何拦截模型加载过程，以优先使用共享的全局缓存。虽然该 API 仍处于提案阶段，但社区正在积极尝试 Polyfill 和起源试用（Origin Trials）。

存储机制对比表

结合 n1n.ai 的混合策略

即使有了优化的跨源存储，基于浏览器的 ML 仍然有其局限性。复杂的推理任务或超大规模模型（如 Llama 3 70B）根本无法在普通的消费级硬件上运行。这就是混合策略至关重要的地方。开发人员可以使用 Transformers.js 处理轻量级任务（如基础情感分析或分词），并将更复杂的查询路由到 n1n.ai。

通过使用 n1n.ai，您可以获得访问世界上最强大 LLM 的统一接口。这使您的应用程序能够保持响应：使用本地模型进行即时 UI 反馈，使用云端模型进行深度处理。这种架构在最大化性能的同时最小化了成本。

循序渐进的实验指南

要从今天开始试验这个概念，您可以使用 Service Worker 和共享 iframe 来模拟跨源共享，尽管原生 API 会高效得多。

1. 设置中心枢纽：创建一个域名（例如 model-hub.com），用于提供带有适当 CORS 标头的模型文件。
2. 注册 Service Worker：在您的主应用中，使用 Service Worker 拦截对 .onnx 或 .bin 文件的请求。
3. 消息传递：使用 postMessage API 在您的站点和 model-hub.com 上的隐藏 iframe 之间进行通信，检查文件是否存在于其本地缓存中。
4. 流式传输：如果找到，将数据流回主线程。

虽然这种设置比较复杂，但它凸显了原生跨源存储 API 对简化开发人员体验的必要性。

Web ML 的未来

WebGPU 与跨源存储 API 的结合将使 Web 转型为 AI 的一等公民平台。我们正在从“仅限云端”的时代转向分布式模型，在这种模型中，浏览器是计算生命周期的积极参与者。

然而，对集中式 API 管理的需求永远不会消失。随着模型的发展，本地和远程推理之间的协调将成为竞争优势。像 n1n.ai 这样的平台在这一转变中起着关键作用，提供了在全球范围内扩展 AI 应用所需的基础设施，而无需管理数十个单独的提供商账户。

总结

跨源存储 API 是 Web ML 拼图中缺失的一块。通过消除冗余下载，它使 Transformers.js 应用程序的可用性和性能得到了显著提升。在我们等待浏览器厂商最终确定这些标准的同时，构建强大的混合系统是开发人员前进的最佳路径。

在 n1n.ai 获取免费 API 密钥。