浏览器与硬件要求，附具体数字
哪些浏览器能用、WebGPU 改变了什么、导入前就能套用的内存估算、手机上收紧的限额，以及没有 GPU 时生成档的真实速度。
· 9 分钟阅读
所有处理都跑在一个浏览器标签页里，所以实际要求只有三条：一个最近两年内的浏览器、装得下运行时和索引的内存、几十兆用来缓存嵌入模型的存储空间。WebGPU 是可选的生成模型的速度加成，对检索没有任何影响。
浏览器需要具备哪些能力
四种内核，各自需要几项能力：带线程的 WebAssembly、Web Worker、IndexedDB、Cache API、Service Worker。
| 浏览器 | 较新版本 | 说明 |
|---|---|---|
| Chrome | 可以 | 默认的测试环境。桌面端和较新的 Android 硬件上有 WebGPU |
| Edge | 可以 | Chromium 内核，表现与 Chrome 一致 |
| Firefox | 可以 | 轻量档完整支持。WebGPU 的支持比 Chromium 晚，且随平台而异 |
| Safari | macOS 和 iOS 上可以 | 轻量档能跑。真正的限制来自 iOS 的内存上限，而不是 API 有没有 |
这里刻意不写具体版本号。各平台的内核能力上线时间不一致，能负责任的说法就是测过的说法：最近两年发布的版本，在桌面系统上跑轻量档没有附加条件。如果你的浏览器比这更老，失败通常是立刻而明显的——模型初始化不起来，或者 Worker 根本起不来——不会悄无声息。
这里不需要插件、不需要本地安装程序、也不需要管理员权限。站点就是一组静态文件，它运行的代码只有你从它那里收到的那份。
WebGPU 有和没有的差别
WebGPU 是一套让页面把计算交给显卡的接口。有它的时候，向量化那一步和可选的生成模型会走显卡；没有的时候，两者回落到跑在处理器的 WebAssembly，带 SIMD 和多线程。
差别只在用户能感觉到的一处体现出来。
| 任务 | 有 WebGPU | 没有它 |
|---|---|---|
| 导入文档、建立索引 | 更快，但几百个块的差距也就是几秒 | 功能完整，只是慢一些 |
| 提问（向量化问题、检索、抽取答案） | 毫秒级 | 毫秒级 |
| 用可选模型生成回答 | 桌面硬件上流畅，每秒几十个 token | 每秒几个 token，短回答可用 |
中间那一行才是大家在意的。一个普通问题不会去跑语言模型，它只把一句短问题向量化、走一次混合检索、再挑句子。这条路径在处理上快到让 WebGPU 变得无关。我们自己的测试机器是 Chrome 配 Radeon RX 580，一张不支持 WebGPU 的卡，日常用的就是轻量档。
想知道你的浏览器怎么报，可以打开控制台执行 navigator.gpu。返回一个值而不是 undefined，说明接口存在；是否好用是另一个问题，工具的做法是试着用，不行就回落。
导入前先估一下内存
这些数字都不大，摆出来更有意义，因为真正让人意外的结论是：索引本身不是占内存的大头。
| 项目 | 大致开销 | 说明 |
|---|---|---|
| 嵌入模型权重加运行时工作区 | 按几百兆留余量 | 下载量约 23MB 或 25MB，但运行时会在权重旁边保留工作缓冲区 |
| 文本块正文 | 1000 个块约 0.7MB 英文文本；中文按每字三字节算约 2MB | 默认按约 700 字符切块、15% 重叠 |
| 向量 | 每 1000 个块约 1.5MB | 定长浮点，和索引放在一起 |
| 关键词索引 | 文本量的一个零头 | 关键词那一半检索所需的词频与二元组统计 |
| 可选的生成模型 | 处理器版约 400MB，WebGPU 版约 1.0GB | 权重占磁盘，运行时还要占工作内存 |
举个具体例子。一个顶到 20000 块的库，差不多是二十份各一千块的文档：
| 组成 | 20000 块时 |
|---|---|
| 向量存储 | 约 30MB |
| 文本块正文（英文） | 约 14MB |
| 文本块正文（中文） | 约 42MB |
| 关键词索引 | 几兆 |
| 模型与运行时 | 几百兆的余量 |
| 轻量档合计 | 1GB 以内，还有富余 |
真正的天花板既不是磁盘也不是索引，而是浏览器标签页；超了之后的表现是整个标签页被丢弃，这一次会话跟着丢。4GB 内存的机器能跑轻量档，8GB 很从容；比文档里写的上限大得多的库会在导入前被拒绝，并点名是哪一份文件，理由相同。
手机和平板上的收紧限额
| 限额 | 桌面 | 手机 |
|---|---|---|
| 单库文件数 | 40 份 | 10 份 |
| 单个文件 | 25MB | 25MB |
| 总量 | 200MB | 200MB |
| 单库文本块 | 20000 | 20000 |
要按文件数这一行来规划。移动端浏览器给标签页的内存比桌面少得多，超出的代价不是页面变慢，而是页面直接消失，连带正在进行的那次导入一起没。10 份这个上限，是为了把一次会话压在手机真正愿意给的预算之内。
手机上还有两点不同。标签页要保持在前台：切到别的应用久一点，浏览器可能丢弃页面，代价就是重新导入一次。生成档在手机上不实用，即使浏览器报告支持 WebGPU——权重会占掉设备可用存储的很大一块，而标签页能拿到的内存比这个模型的工作集还小。
没有 GPU 时生成档的实际速度
可选的生成档有一个如实的限制，它限制的是速度而不是能力。
| 引擎 | 模型 | 下载量 | 典型速度 | 现实用法 |
|---|---|---|---|---|
| WebGPU | Qwen2.5 1.5B，4-bit | 约 1.0GB | 桌面显卡上每秒几十个 token | 多轮追问、短摘要 |
| 处理器回落 | Qwen2.5 0.5B，4-bit | 约 400MB | 约每秒 3 到 8 个 token | 短回答，需要耐心 |
按每秒 3 到 8 个 token 算，一段两百 token 的回答要花二十五秒到一分多钟。这个速度慢到需要你先真心想要它再启用，界面也是这么直说的。第一次生成之前还得把模型下载完，而下载只在一次写明模型名和体积的确认之后才开始。
这一档是可选的，原因就在这。默认的作答方式是抽取式的——从检索到的文本块里挑句子，逐句挂上编号引用——在任何受支持的浏览器上都是交互级速度，有没有 GPU 都一样。生成改变的是文字的形态，不是底下那份证据。
照着这些数字对自己做判断
一条简短的决策路径：
- 只想要带引用的答案。 任何受支持的浏览器、轻量档、不需要 WebGPU。这是测过的默认路径。
- 文档库里中英混着放。 同上，改用约 120MB 的多语模型，切换时重建一次索引。
- 想要改写过的表述，而不是被引用的原句。 启用生成档。纯处理器机器上约 400MB，有 WebGPU 约 1.0GB，并且请预期纯处理器那条路是慢，不是坏。
- 在手机上用。 控制在十份以内，留在轻量档，接受浏览器丢弃标签页时要重新导入一次。
凡是答案看起来“看情况”的地方，那个变量几乎总是可选模型，而不是核心引擎。检索是为普通硬件设计的，也是你在任何地方都能指望的那一部分。