浏览器被4GB卡了近十年，Rust改13个文件拆墙

一、浏览器什么都装得下，唯独装不下 4GB

打开一个网页，你可以玩 3D 游戏、剪视频、跑完整的办公套件，但你很难在里面跑一个像样的 AI——不是网速问题，是墙的问题。

网页应用跑在 WebAssembly 上，这套标准 2017 年进浏览器时就用的是 32 位地址空间，单个模块的内存上限被写死在 2 的 32 次方，也就是 4GiB。而 AI 那头呢，连"小"权重都动辄好几个 GB：一个 70 亿参数的权重，压缩到 4 比特量化，文件就有约 4.4GB——刚好卡死在这道墙外面。这不是夸张，是精确的数字对撞：4.4GB 的权重，塞不进 4GiB 的房间。

10 月 8 日，Rust 官方仓库合并了一个改动：只动了 13 个文件、加上 20 行删掉 20 行。就是这 20 行，把 Rust 标准库里"只认 32 位 wasm"的条件编译全部换成了"所有 wasm 一律认"，给浏览器拆墙的第一锹土，是从这里挖下去的。

二、拆解：这堵墙是怎么一块块拆的 墙本身已经开始松动了

先说浏览器侧。Wasm 社区其实早就看清了这个问题，答案是 memory64 提案：把内存寻址从 32 位换成 64 位，理论上限直接放大到 16EB。2025 年 9 月 17 日，Wasm 3.0 标准正式完成，64 位地址空间写进了正式规范。

项目

状态

Chrome / Edge

133 版起支持（2025-02-04 发布，默认开启）

Firefox

134 版起支持（2025-01-07 发布）

Safari

至今不支持，全球约 26% 的浏览器用户被排除在外

网页侧上限

64 位内存最高 16GB，不是无上限

也就是说，浏览器的墙已经开了两条门，就差工具链这一侧没人走过去。

Rust 侧：差一个目标，差一个开关

Rust 是目前往 WebAssembly 编译的主力语言之一，它早就支持一个叫 wasm64-unknown-unknown 的编译目标。但这里有个致命缺口：Rust 不支持 wasm64 加 Emscripten 的组合目标。Emscripten 是把 C/C++ 那一整个生态搬进浏览器的老牌工具链，没有这个组合目标，大量现成库进不了 64 位 wasm 的世界。

顺带说一句现状：今天浏览器里跑 AI 的项目其实分两条路，一条走 WebGPU，直接调显卡算，不受 wasm 内存限制但兼容性看浏览器脸色；另一条把推理引擎编成 wasm 跑纯 CPU，哪里都能跑，但全部被摁死在 4GiB 之内。NobodyWho 选的是后者，理由也很直接——他们要的是"任何设备都能跑"，纯 wasm 是覆盖面最广的那条路。

把这事推起来的，是一家叫 NobodyWho 的开源项目。它专做一件事：让 AI 权重跑在各种设备上——手机、桌面、游戏引擎，甚至 Apple Watch（他们自称是全世界第一个在手表上本地跑 AI 的应用）。按他们的说法，如今大部分软件跑在浏览器里，"不支持网页"就是他们承诺里的一个巨大漏洞，所以最近开始啃 WebAssembly。

项目档案

数据

仓库

github.com/nobodywho-ooo/nobodywho

星数

1,605

语言与许可

Rust，EUPL-1.2

建仓时间

2024-09-03，持续活跃（最近推送 10-21）

最新发布

移动/桌面/Swift/Kotlin 各 v5.1.0，Godot 游戏引擎版 v12.1.0（均为 10-09）

他们没有另起炉灶，而是直接给 Rust 编译器提了两个 PR。有意思的是，提 PR 的开发者 madsmtm 本身就是 NobodyWho 的贡献者之一——一个应用开发者，顺手去改通用编译器。

第一步已经落地。编号 163794 的 PR，把 Rust 标准库里的条件编译从"只认 32 位 wasm"改成"所有 wasm 都认"：

// 改法核心：一行判断的口径变了// 之前：编译器里大量分支只照顾 32 位 wasm#[cfg(target_arch = "wasm32")]// 之后：64 位 wasm 也一起算进来#[cfg(target_family = "wasm")]

就这个口径的差别：原来编译器里一大堆代码路径写着"如果目标是 wasm32 就怎样"，64 位 wasm 走到这些地方全都掉进未定义的缝隙里。换成 target_family 之后，整个标准库对 wasm 家族一视同仁。这个 PR 共 13 个文件、加 20 行删 20 行，10 月 8 日合并进主线。

第二步还在路上。编号 163808 的 PR，要在 Rust 里新增 wasm64-unknown-emscripten 这个 tier 3 编译目标（可以理解为"试验性通道"，官方不保证质量），10 月 5 日提出，还没合并。按流程，从 tier 3 到进稳定版，通常以年计。

4GB 意味着什么

把量级摆出来，你就知道这道墙拆得多及时：

权重规格

4 比特量化后体积

在 wasm32 浏览器里

30 亿参数级

约 2GB

装得下，还要留运行余量

70 亿参数级

约 4.4GB

装不下，卡线之外

80 亿参数级

约 4.9GB

装不下

130 亿参数级

约 8GB

必须 wasm64，网页上限内可装

也就是说，wasm64 落地那天，主流的 7B 到 13B 档位第一次真正进入网页的射程。而现在的网页方案，全部被摁在 30 亿参数以下。

三、先别欢呼：拆的是墙，不是最后一公里

冷静看，这件事现在只完成了三分之一，原文作者自己也没打算掩饰这一点。

第一，tier 3 不是稳定版。wasm64-unknown-emscripten 还在评审期，就算合并了，用起来也得自己编译工具链，普通开发者短期内摸不到。原话写得很实在："这大概要花点时间，进稳定版要更久。"

第二，4GB 这个数字本身就值得抠。它是项目方自己测的口径，7B 权重 4.4GB 是社区长期共识，取整没错——但"刚好 4GB"意味着网页里还得给运行时和上下文缓存留地方，权重本体塞进去，程序也未必跑得起来。实际可用的余量比 4GiB 还要小一截。

第三，Safari 还站在墙里面。Chrome 和 Firefox 早开了门，但 Safari 至今不支持 64 位 wasm 内存，意味着这套方案落地后，相当一部分苹果用户第一年是用不上的。

第四，也是最容易被忽略的：墙拆了，门槛还在。原文结尾自己列了两个"更难的问题"——一是怎么把权重送到用户机器上（半个 GB 的小权重，在网页语境里都算大文件，用户凭什么等它下完）；二是怎么让它跑得足够快。也就是说，4GB 天花板拆掉，拿到的是入场券，不是终点线。

一个开源团队给通用编译器提 PR 而不是自己魔改一份私货，这件事本身就是答案：改在源头，所有人受益。这也是这件事比"又一个浏览器 AI 演示"更值得看的原因。

还有一层时间差的辩证值得琢磨：浏览器的门（memory64 进标准）是 2025 年 9 月开完的，工具链这头到 2026 年 10 月才有人接棒，中间隔了整整一年。规格先行、生态慢半拍，是大平台演进的老规律——标准落定那天你就能读到新闻，但真能用上的那天，往往要再等一轮工具链补课。看懂这个节奏，就不会在标准发布时冲进去，也不会在工具链补课时错过。

四、这件事跟普通开发者有什么关系

如果你做游戏：NPC 对话离线化是目前最明确的场景。NobodyWho 本来就给 Godot 游戏引擎做了插件，wasm64 通了之后，网页游戏里的本地对话成为可能——不联网、不付接口费、玩家的对话不出浏览器。

如果你做网页应用：现在就能做的部分是 3B 以下的小权重，wasm32 里塞得下；等 wasm64+Emscripten 目标进稳定版，7B 到 13B 档的隐私对话、文档摘要类功能可以整体搬进浏览器，服务器的接口成本和隐私暴露面一起归零。

如果你想提前上车：盯住两个东西就行——Rust 仓库里 163808 这个 PR 的合并状态，和 NobodyWho 仓库的 WebAssembly 支持动态。前者决定工具链什么时候能用，后者决定应用层什么时候能用。

五、说到底，这是一场"规格追工具"的接力

浏览器先拆墙（memory64 进标准），编译器跟上（Rust 补目标），应用层最后进场（推理库接入）。10 月 8 日合并的那 20 行，是这条接力赛里最小的一段，却是第一次有人从工具链那一侧伸手接棒。

最后留个问题：如果浏览器真能装下 13B 级的权重，你最想在里面塞一个什么——离线翻译、文档助手，还是游戏里一个真正会聊天的 NPC？评论区聊聊。