27B 模型，6GB 显存，浏览器里每秒 30 token——作者自述

mentria.ai 是一个浏览器推理引擎，我独自一人用 WebGPU/WGSL 从头构建。本周，它跨过了我追寻已久的一个里程碑：一个 27B 的 1-bit 模型，在配备 6 GB 显存的 RTX 3060 笔记本 GPU 上，在 Chrome 中通过网页页面，回答速度高达每秒 30 tokens。无需安装，无需服务器，一切都不会离开这台机器。

模型

Bonsai-27B 是一个由 Prism ML 训练并发布的原生 1-bit 模型。我将其重新打包以适配我们的引擎，编写了运行它的内核，并亲自检查了它的质量（与 FP16 的 Qwen3.6-27B 相比的完整评估差异，见 HF 模型卡）。每个权重仅为一个符号位，每 128 个权重共享一个缩放系数，即每参数约 1.14 比特，因此 270 亿参数仅占用 3.8 GB 显存。重新打包和具体数字见：huggingface.co/mentriaai/Bonsai-27B-mentria

实现 30 tok/s 的工程

在这篇帖子发布的两天前，同样的模型在这台笔记本上解码速度为 15 tok/s。解码受限于内存带宽：27B 模型的一个词需要 804 次 GPU 调度，其中 401 次是 1-bit 矩阵乘向量内核，每次生成一个词都要将模型 3.6 GB 的 matmul 权重流式读取一遍（嵌入层使文件达到 3.8 GB）。胜出的内核是为手机编写的：四个 1-bit 权重只有 16 种可能的局部答案，因此它一次性将全部 16 种结果计算到片上暂存区，每一行直接查表得到答案，而无需相乘（见 station 258 —— facts 页面上的编号文章）。在 Ampere 架构上，这个表遇到的瓶颈完全不是权重本身：暂存内存有 32 个 bank，表的地址访问让每个 warp 中的十六条线程都落在同一个 bank 上，导致内核只跑出了显卡带宽的 38%。每行增加一个 padding 槽位后，地址被均匀分散到不同 bank；内核处理一个词的时间从 26.5 ms 下降到约 21 ms，叠加查表本身带来的 15 → 26 tok/s 提升，这台笔记本最终原始速度达到 32 tok/s —— 25–30 是聊天中扣除采样和 UI 开销后实际保留的速度（见 s259）。提示处理阶段的分块布局也存在同样的问题；重新分块后，一个 1,489 token 的提示从 29.6 秒缩短到 25.3 秒。每项改动只有在输出与先前的构建字节完全一致时才会发布，这也是为什么内核以固定顺序累加部分和，并接受 44% 的占用率上限。

这里的每一项说法都可以在 engine facts 页面 上找到对应的编号文章。

数字

* 解码：显卡预热后，在聊天界面中 25–30 tok/s。
* 提示处理：1,489 token 的提示约需 25 秒。
* 上下文：在这块 6 GB 显卡上为 3,072 tokens；16 GB Mac 上为 8,192；更大显卡上更多，每个 token 占用 128 KiB。KV 缓存是精确计算，没有量化缓存。在 6 GB 上的下一步是将引擎的数千个小 GPU 缓冲合并为少数几个大内存池，让驱动不再持有约 300 MiB 的 slab 余量；这是实现 4,096 上下文的算法，但尚未实现。
* 加载：从浏览器缓存加载不到 10 秒；首次下载为 3.8 GB，一次性。

引擎中还有

较小的模型层级（Qwen3.5 0.8B、2B、4B）覆盖手机和低端设备；几 MB 的 LoRA 适配器可在不到一秒内在矩阵乘法处热替换；此外还有一个视觉塔用于图像输入。

可在这里试用：[https://mentria.ai/tools/ai-chat/4（当你的 GPU 达标时会显示 27B 选项）。发布的代码、基准测试和我的测量方式都在仓库中：[https://github.com/mentria-ai/website5。关于引擎和模型实际工作原理，见 engine facts 页面：[https://mentria.ai/assets/learn/engine-facts.html6