不是把 48GB 全塞进显存
想象你在小书桌上查一套大百科：桌面放不下全部书，但可以先把常用页摊开，需要哪一册再从书架取。这个演示解决的正是类似问题——让装不进内存或显存的大模型，也能直接在浏览器标签页里运行。
作者把磁盘分页接到了 llama.cpp 的 WebGPU 后端。WebGPU 是浏览器调用本机 GPU 做通用计算的标准；llama.cpp 则是常用的本地模型运行工具。此前，这套办法只能配合为少数模型手写的引擎。现在，llama.cpp 已经支持的 MoE 模型可以复用同一机制，不必再逐个定制。
这里的“80B 进浏览器”需要说准确。Qwen3-Next 80B-A3B 是 MoE，也就是“混合专家”模型：模型包含许多分工不同的子网络，但每一步通常只调用少数专家。80B 指总参数规模，单次约激活 3B 参数。48.4GB 的 GGUF 文件也没有完整常驻 GPU，而是主要留在浏览器磁盘存储中。GGUF 是 llama.cpp 生态常用的模型文件格式，用来封装模型权重和运行所需信息。
本文的实现、性能和正确性数据全部来自项目作者的一篇 Reddit 帖子，尚无独立信源复核。
浏览器怎样从硬盘“借”专家
首次使用时，浏览器会完整下载 GGUF，再把它复制进自己的私有存储 OPFS。推理开始后，GPU 常驻三类东西：每一步都要用的 dense layers、记录上下文中间结果的 KV cache，以及数量固定的 expert slots——可以理解为留给专家的临时座位。
模型运行到某个 MoE 层时，路由器会选择本轮需要的专家。如果专家已经坐在槽位里，就直接使用；如果不在，系统便从 OPFS 读取权重，替换掉最久没有使用的专家。这就是磁盘分页：不一次装入全部数据，而是按需调入当前部分。用户还能根据显存预算决定留多少槽位。
这次改动位于 llama.cpp 自己的 WebGPU 底层。作者称，核心包括一种新缓冲区类型、能够映射专家槽位的计算着色器，以及管理哪些专家当前驻留的逻辑。意义不只在于跑起一个模型，而在于把此前的单模型原型变成可复用能力。
48GB 文件，GPU 占用 4.89GB
在一台配备 24GB 内存的 MacBook Pro M4 Pro 上，作者演示了 Qwen3-Next 80B-A3B 的 Q4_K_M 版本：GGUF 文件为 48.4GB，GPU 占用 4.89GB，从磁盘加载耗时 48 秒，解码速度为每秒 2.9个 token。token 是模型处理文本的基本片段，可能是一个字、词或词的一部分。作者明确把这个速度称为概念验证。
较小模型快得多。OLMoE 1B-7B 的 4.2GB 文件占用 3.92GB GPU，解码达到 22.4 token/s；LFM2 8B-A1B 的 5.0GB 文件占用 3.89GB GPU，达到 17.1 token/s。14.7GB 的 Qwen3-30B-A3B 也能运行。
这里的“48秒从磁盘加载”不是首次把整个文件复制进 OPFS。后者是另一个阶段，而且作者没有给出所需时间。运行期间的读取压力也很明显：80B 模型每生成一个 token，约要从磁盘读取 359MB。
三条实验线终于汇合
我们此前先后报道过用内存和磁盘承接放不下的 MoE 权重、浏览器 WebGPU 推理内核，以及 llama.cpp 的 GPU 专家缓存。这次更新把三条线接到了一起：浏览器负责运行，磁盘承担大容量权重，GPU 只保留当前需要的专家。
作者还补做了输出对照。对于能够完整装入的 OLMoE 和 LFM2，开启与关闭分页后，9组对话的回复全部一致。两个无法完整驻留的大模型，在不同专家槽位数量下，回复也保持一致。这只能说明少量样本中的最终文本相同，不代表每一步数值、logits——模型为候选输出计算的分数——或整体模型质量完全一致。
演示最后还有一个颇贴题的片段：作者问正在 Chrome 中运行的 80B 模型，它怎么可能待在浏览器标签页里。模型回答：“It can't.” 但真正值得看的并不是这句反差，而是底层已经从手写原型进入 llama.cpp 的通用后端。
局限与未知
- 速度仍是硬伤。80B 模型只有 2.9 token/s，提示词处理也依然很慢；每个 token 约 359MB 的磁盘读取意味着性能会受到存储和缓存命中的明显影响。
- 兼容范围很窄。目前只支持 Chrome 或 Edge 137 以上版本，而且只在 Apple silicon 上测试，不能把一台 24GB M4 Pro 的结果外推到其他设备。
- 与 llama.cpp 的 Metal 后端比较时，每9组回复只有4至8组匹配。作者将差异归因于接近并列时的 WebGPU 与 Metal 浮点舍入，但这只是作者的解释，现有材料不足以独立确认。