一个 80B MoE 模型（Qwen3-Next，48 GB GGUF）在 Chrome 标签页中回答问题：使用 llama.cpp 的 WebGPU 后端，专家从磁盘按需分页加载

接着上周那篇关于在浏览器标签页中从磁盘流式加载 MoE 专家的帖子。那次使用了为两个模型手写的引擎。这周，同样的磁盘层接入了 llama.cpp 自己的 WebGPU 后端，因此可以用于 llama.cpp 已经支持运行的 MoE 模型，无需为每个模型单独编写引擎。视频是在 Chrome 中的一次真实录制。加速播放的部分都在画面上标明，并显示实时计时器。这次录制中的实测数据（MacBook Pro M4 Pro，24 GB）：模型（GGUF） 文件大小 GPU 占用 从磁盘加载 解码 Qwen3-Next 80B-A3B Q4_K_M 48.4 GB 4.89 GB 48 秒 2.9 token/秒（概念验证） OLMoE 1B-7B Q4_K_M 4.2 GB 3.92 GB 5.3 秒 22.4 token/秒 LFM2 8B-A1B Q4_K_M 5.0 GB 3.89 GB 6.2 秒 17.1 token/秒 Qwen3-30B-A3B 也能运行（文件大小为 14.7 GB）。工作原理。GGUF 只需下载一次，存入浏览器的私有存储（OPFS）。GPU 保存稠密层、KV 缓存，以及每层固定数量的专家槽位，槽位数量根据你选择的 GPU 显存预算确定。在每个 MoE 层，系统会读回路由器选择的专家，并将尚未驻留在槽位中的专家从 OPFS 文件中读取（通过工作线程中的同步访问句柄），载入最近最少使用的槽位。分页机制只对 ggml-webgpu 做了少量修改：新增一种缓冲区类型、映射到槽位的 MUL_MAT_ID 着色器，以及驻留管理逻辑。正确性。在同一后端上开启和关闭分页，回复完全一致（OLMoE 和 LFM2 的 9/9 组对话均一致；两个大模型无法在不分页的情况下装入显存，分别使用 8 与 32 个槽位或 16 与 64 个槽位时，回复也完全一致）。与 llama.cpp 的 Metal 后端相比，9 条回复中有 4 到 8 条一致。不一致的情况来自 WebGPU 与 Metal 在数值几乎相等时的舍入差异：以 llama.cpp 的 CPU 后端为基准，WebGPU 路径的接近程度与 Metal 相当。局限。80B 模型很慢：每生成一个 token，大约要从磁盘读取 359 MB。提示词处理仍然很慢（上周对此的批评是合理的）。仅支持 Chrome 或 Edge 137 及以上版本；仅在 Apple 芯片上测试过。首次加载会将整个文件复制到浏览器存储中。问 80B 模型如何能在浏览器标签页中运行，它自己回答：“不可能。”而它当时就在浏览器标签页中运行。试用：https://diskformer.naklitechie.com · 代码：https://github.com/NakliTechie/diskformer.js ·