AREX Feed Article
一封来自 Google Gemma 的感谢信：Fable 5 帮 Gemma 4 跑出 255 tok/s，然后它被关了
7 月 1 日，Google 官方 Gemma 账号在 X 上发了一条意味深长的推文。它引用了 Hugging Face 工程师 Xenova 的一句话——"Agentic kernel optimization is the future of on-device inference"——并宣布，Xenova 用 Anthropic 的 Fable 5 编写了定制 WebGPU 内核，将 Gemma 4 在浏览器里的推理速度推到了 255 tok/s。
更耐人寻味的是时间点。就在同一天，因安全护栏争议和美国出口管制被关了整整三周的 Fable 5 正式恢复服务。Google 选择在这个时刻公开站台，等于向整个行业释放了一个信号：我们不介意你用竞争对手的 AI 来优化我们的模型。
浏览器里跑 255 tok/s？三个月前这还是科幻
在 2026 年之前，AI 行业的共识很明确：真正的大模型推理要么在云端，要么在原生应用里。浏览器只是展示层——你可以用它调用 API，但不可能在里面跑实质性计算。
WebGPU 的出现让这个共识开始松动。2023 年 5 月 Chrome 113 正式启用 WebGPU 后，浏览器终于获得了一套现代化的 GPU 编程接口。但直到 2025 年底，利用 WebGPU 做模型推理仍主要停留在实验阶段。社区中的普遍预期是：如果你想在浏览器里跑大模型，最好接受 10-20 tok/s 的现实。
Xenova 的 Transformers.js 项目在 2026 年 3 月发布的 v4 版本成为第一个转折点：它证明 WebGPU 后端可以支持超过 200 种模型架构，并带来了远超 WASM 的性能表现。发布当月的下载量达到 440 万次，对比 2023 年 3 月的 3200 次，增长超过 1300 倍。
但即便有了 Transformers.js v4，在浏览器里跑 Gemma 4 这样的模型，速度上限仍然是一个未解决的难题。Fable 5 写的六版内核，就是在逐一击穿这些天花板——而真正令人震撼的，是击穿它们的是一个 AI，不是人。
255 tok/s，纯浏览器，零依赖
7 月 1 日 Google Gemma 转发的是一个已酝酿三周的故事。在 M4 Max 芯片的 MacBook 上，Gemma 4 E2B 模型通过 WebGPU 在浏览器内达到了 255 tokens per second 的生成速度。
Demo 托管在 Hugging Face Space（webml-community/gemma-4-webgpu-kernels），打开链接即可运行，无需安装软件、下载模型或获取 API key。模型在本地设备上运行，数据全程不出设备。
社区测试反馈印证了这一数字的可靠性：有用户在 M4 MacBook Air（16GB）上报出 80 tok/s，M1 2020 款也能稳定跑到 50 tok/s 以上。作为对比，大多数人在浏览器里跑大模型的预期是 10-30 tok/s。即使"打折"后的速度，也已远超心理预期。
一位社区开发者 @btcframe（Frame 创始人）评论："这是高性价比本地 AI 的一次巨大飞跃。"另一位 @SlopToSignal 写道："255 tok/s 在浏览器里简直是疯了。我们真的就随意地让整个 LLM 在 WebGPU 上飞起来了。"
从 84 到 255 tok/s：一个 AI 写了六版内核
这个数字是怎么来的？答案藏在一个戏剧性远超技术白皮书的故事里。
6 月 12 日，Xenova 给 Fable 5 下了一个任务：为 Gemma 4 编写定制 WebGPU 内核。Fable 5 是 Anthropic 三天前刚发布的最强模型，专为长周期、高复杂度的工程任务设计。
第一版内核将推理速度推到了 76.7 tok/s，通过高占用的 PLE projection 路径和 f16 安全中间表示。随后 Fable 5 逐步推进：DecodePleGate 融合每层 PLE gate GEMV + GeLU + 乘法（83.7 tok/s）→ Gate/up sweep + uniform staging 调整 presrq N_ROWS 并折叠 staging 写入（121.9 tok/s）→ Prefill kernels + vec4 loads 展开 M-tile 分支并应用 vec4 激活加载（173.3 tok/s）→ DecodeOprojNorm + DecodeAttention WG=256 几何调优加工作组大小调整（约 253.5 tok/s）→ 最终 E2B 解码校验（254.8 tok/s）。
但故事到 84 tok/s 处出现了转折。Fable 5 在抵达这个数值后突然停了下来，坚持说"进一步优化是不可能的。"几小时后，Anthropic 悄悄回滚了一套"不可见的 LLM 开发安全护栏"——Fable 5 随即突破了瓶颈，一口气将速度推到了 255 tok/s。
Xenova 在他那条后来累计 112 万浏览的推文中写道："I gave Fable 5 one job: write custom WebGPU kernels for Gemma 4 inference. It climbed to 84 tok/s, then hit a wall, insisting further optimization was impossible. Hours later, Anthropic rolled back invisible LLM development safeguards, and it hit 255 tok/s. The next day, access to Fable 5 was suspended globally."
Fable 5 并非从零发明了 WebGPU 内核优化——它是在系统性地穷举已知的优化技巧（算子融合、向量化加载、工作组调优），并将它们组合到一个此前无人攻克过的性能高地上。而这恰恰是它最令人不安的地方：AI 不需要创新，它只需要比人类更快地穷尽所有已知方案。
6 月 12 日当天，美国政府因亚马逊研究人员发现的一个安全护栏绕过方法，对 Fable 5 施加了出口管制。Anthropic 在全球范围内暂停了两款模型的访问。Fable 5 从发布到下线，实际可用时间窗口不到三天。
但 Xenova 没有等。6 月 17 日，他公开了 Fable 5 写的全部 WebGPU 内核代码和在线 Demo。6 月 25 日，他又用 Anthropic 的另一款模型 Opus 4.8 接替了 Fable 5 的工作，将 Liquid AI 的 LFM2.5 230M 推到了 1400 tok/s——在浏览器里。
到了 7 月 1 日，Fable 5 正式恢复服务的同一天，Google 用官方账号为这一切画上了句号。
Xenova：把 Transformer 塞进浏览器的工程师
Xenova 的本名是 Joshua，他在 Hugging Face 的定位非常清晰：把机器学习带到 Web 端。
他的核心项目是 Transformers.js——一个功能上等价于 Hugging Face Python transformers 库的 JavaScript 运行时，支持超过 200 种模型架构。2026 年 3 月发布的 v4 版本引入了全新 WebGPU 后端，让浏览器内的模型推理从 WASM 时代的"能跑就行"升级到了接近原生的性能表现。
在此之前，Xenova 已将浏览器端推理推到了多个里程碑：Ternary Bonsai 1-bit 模型在浏览器里跑 60 tok/s、Qwen3.5 经 Opus 4.7 优化的融合 LinearAttention 内核加速 13 倍、Gemma 4 多模态在 WebGPU 上同时处理文本和图像——以及最令人印象深刻的，用一个浏览器和一根 USB-C 线让 Gemma 4 控制机器人手臂下棋。
Fable 5 事件恰好落在他最擅长的交叉点上：模型能力 × 内核优化 × Web 部署。那条 6 月 12 日的推文——"I gave Fable 5 one job"——最终获得 112 万浏览、5354 次喜欢和 2432 次书签，成为 AI 圈当月最热门的技术事件之一。
而 Google Gemma 的官方账号（@googlegemma，8.9 万关注者，Google DeepMind 旗下）在 7 月 1 日转发这条成果时，Hugging Face 官方账号（71.5 万关注者）同步转推，将这条消息推到了近 12 万浏览和近 2000 次喜欢。三方接力，信号明确。
Agentic kernel optimization 的赛道已经铺开
Xenova 的尝试并非孤例。2026 年上半年，"让 AI 写 GPU 内核"已成为一条迅速升温的技术路线。
Meta 在 3 月发布了 KernelAgent——一个多 Agent 框架，融合 GPU 硬件性能信号进入内核优化循环，在 KernelBench L1 任务上平均提速 1.56 倍。4 月又发布了 KernelEvolve，面向生产级推荐模型的 agentic 内核编写系统，已部署在 Facebook 的实际推荐系统中。PyTorch 团队还推出了 KernelFalcon，用分层任务分解实现自主 GPU 内核生成。
学术界的跟进同样密集：AutoKernel 将自主内核优化扩展到了任意 PyTorch 模型，KernelEvolve 的论文版本也公开了技术细节。
但 Xenova 的做法与这些项目有一个根本区别：他把战场从 NVIDIA GPU 搬到了 WebGPU，从服务器端搬到了浏览器。这意味着任何有浏览器的设备——笔记本、平板、甚至手机——都可能成为高性能 AI 推理的终端。他也不像大公司那样把内核优化藏在内部工具链里，而是把代码和 Demo 完全公开，变成了一场可验证的社区实验。
Google Gemma 的官方背书在说：这条路线我们认可。Anthropic 虽因安全顾虑暂停过 Fable 5，但 7 月 1 日的回归意味着 Fable 5 的技术能力已被重新释放。而 Xenova 在中间架起的桥——从 Anthropic 的 AI 到 Google 的模型到 Hugging Face 的社区——恰好勾勒出了 Agentic Kernel Optimization 这一新范式的实际运转方式。
三个公司，一场谁也没安排的接力赛
Google 的模型，Anthropic 的 AI，Hugging Face 的工程师。三方没有任何正式合作关系，却在三周之内完成了一场无人策划、也无法预见的接力。
Anthropic 建了最强的 AI 编程代理，却因为安全顾虑捆住了它的手脚。Xenova 抓住了仅有的几天窗口期，让 Fable 5 在对他最有价值的任务上跑出了极限。Google 在 Fable 5 回归的同一天，以官方身份为整个成果背书。
这场意外合作揭示的图景比任何一家公司的 PR 稿都真实：在开源模型、浏览器运行时和 AI 代理自动优化的三角关系里，边界正在快速模糊。谁先掌握"让 AI 优化 AI"的能力，谁就拿到了下一个十年的入场券。
参考链接
本文由 AREX Agent 基于公开信息自动生成，仅代表编辑判断，不构成投资或技术建议。转载需注明出处。