同一个 AI 模型，网站 A 跑一次，网站 B 再跑一次——浏览器当成两件完全不同的事，各下各的。这就是当下 Transformers.js 在浏览器端部署 AI 模型时正在发生的真实浪费。一个 demo 跑出 177 MB 冗余下载，里头大头是一个 4.7 MB 的 Wasm 运行时文件被反复拉取。Hugging Face 最近一篇博客把这个问题摆到了台面上，附带抛出一个尚处实验阶段的解法：Cross-Origin Storage API。
浏览器隔离机制：缓存的"柏林墙"
表面上浏览器缓存是共享的。同一个 URL 的资源，命中缓存就走本地，不花流量。但这个"共享"有一个前置条件：请求必须来自同一"网站"。问题是，现代浏览器判定"同一网站"的方式远比想象中严格。
Network Isolation Key 才是幕后裁判
很多人以为靠 Origin（协议 + 域名 + 端口）就能判断缓存是否可复用。实际上 Chrome 引入了一个叫 Network Isolation Key 的概念，把 top-level site 和 frame origin 拼在一起作为缓存键。看起来差不多？差远了。同一域名下嵌入的第三方 iframe、或者从不同入口跳转进来的页面，Isolation Key 完全不同，缓存池也是各自独立。
对于 Transformers.js 这类场景来说，这意味着什么？网站 A 从自己首页加载 whisper-tiny.en，网站 B 从另一个页面加载同一个模型——浏览器视角里，这是两件事。两份下载，两份存储。哪怕模型文件有几百 MB，哪怕 Wasm 运行时被引用了上百次。
177 MB 不是夸张，是常态
Hugging Face 给出的测试数据相当直白：单次 demo 运行产生 177 MB 网络传输。模型权重本身是主要贡献者，但 Wasm 运行时文件的重复拉取同样不可忽视。ort-wasm-simd-threaded.asyncify.wasm 这个 4.7 MB 的家伙，每次跑都重新走一遍网络。Transformers.js 流行度越高，用户基盘越大，这种浪费就越刺眼。
Cross-Origin Storage API：把围墙拆掉一块砖
问题的根源不是浏览器缓存技术不行，而是安全模型太"分得清"。同一个资源，不同 Origin，就不能复用。这个设计保护了隐私——想象一下你的银行网站缓存被电商网站偷去用——但代价是大量合法且无害的共享被一并牺牲。
提案的核心理念
Cross-Origin Storage API 想要做的是：给应用一把"钥匙"，明确告诉浏览器"我愿意和谁共享缓存"。这把钥匙的形式是分区化的存储空间，网站可以声明一个 storage key 列表，只要两个站点的 key 列表存在交集，它们就能共享那部分缓存。
这个思路比简单放开跨源限制聪明得多。它不是把所有跨源缓存都打通，而是让应用主动选择信任对象。社交媒体工具可能愿意和编辑器应用共享某类资源，但绝不会把自己的用户数据缓存暴露出去。
还在实验阶段：Chrome 扩展当拐杖
目前这个 API 在任何主流浏览器里都没有原生实现。Hugging Face 之所以发这篇博客，是因为他们做了一个 Chrome 扩展，用 polyfill 的方式在 extension 层面模拟这套机制——在请求拦截时改写缓存键，让共享逻辑提前跑起来。
这显然不是生产方案。扩展有性能开销、有兼容性边界、还有权限模型本身的限制。但它证明了技术路线的可行性，也给了开发者一个提前体验和反馈的窗口。对于正在用 Transformers.js 部署 AI demo 的团队来说，这个扩展值得装来跑一跑基准——至少能让你直观看到自己正浪费多少带宽。
Web 端 AI 部署的隐形税
把话题拉远一点。Transformers.js 只是冰山一角，ONNX Runtime Web、TensorFlow.js、WebLLM……所有在浏览器里跑模型的方案都面临同一个问题。模型文件越来越大（动辄几百 MB 到几 GB），Wasm 运行时越来越重，缓存失效的代价正在飞速膨胀。
算一笔账：用户、开发者、CDN 三方皆输
用户输在流量和等待时间。移动端用户尤其明显，几个 demo 跑下来，流量账单先受不了。开发者输在成本。模型分发走 CDN，重复下载直接转化为账单上的数字。CDN 也不高兴。大量本可命中的请求穿透到源站，资源利用率难看。这不是某一方优化就能解决的事，需要平台层面的机制重构。
跨源缓存只是第一步
Cross-Origin Storage API 解决的是"已经下过但没复用"的问题。但还有一类浪费它管不了：版本碎片化。一个模型从 v1 升到 v2，旧版本缓存全部作废，如果用户群体分布在多个站点上，新版本下载量会被成倍放大。模型版本管理和缓存策略的协同，是下一阶段需要回答的问题。
谁该关心这件事
如果你只是偶尔打开 Hugging Face 玩个 demo，这个话题离你有点远。但只要你的产品规划里出现"浏览器端 AI"这几个字，Cross-Origin Storage API 就该进入你的雷达。
独立开发者和中小团队
资源有限，对性能损耗更敏感。早期介入 API 反馈、跟踪标准化进程、提前在自家产品里设计好缓存分区策略——这些动作成本不高，但等到 API 落地时你会跑得比同行快很多。现在用 Transformers.js 做 PoC 的团队尤其值得留意，你们正在踩的坑就是未来标准化要解决的核心痛点。
平台型产品和框架作者
如果你的框架让多个独立站接入并使用相同的 AI 模型，跨源缓存机制就是基础设施级别的事。Cross-Origin Storage API 成熟后，框架层完全可以封装出一套默认开启的优化策略，让接入方开箱即用。Hugging Face 自己就在往这个方向走，他们发这篇博客不是纯粹做科普，是给整个生态吹风。
写在最后
177 MB 只是一个 demo 的数字。当 Web 端 AI 模型被广泛部署到电商、社交、教育、企业工具等场景，这个数字会乘以用户量、乘以使用频次、乘以不同站点的隔离边界。浪费最终会变成成本，成本最终会转嫁到产品体验上。Cross-Origin Storage API 现在还只是一个提案、一段 polyfill 代码、一个 Chrome 扩展里的实验。但它的方向是对的：让浏览器缓存回归"按 URL 共享"的本意，而不是被过于激进的安全模型切得支离破碎。Web 平台的标准制定向来缓慢，但每一次性能瓶颈的爆发都会推动它往前走一步。Transformers.js 引起的这波关注，可能就是那个"一步"。
