Ternlight 把 Embedding 塞进浏览器：7MB 模型跑 WASM

Ternlight 发布 7MB 浏览器端 Embedding：向量化这件事，服务器可以不用了

本周，一个叫 Ternlight 的项目在开发者圈里冒了出来——一个体积只有 7MB 的 Embedding 模型，通过 WebAssembly 直接在浏览器里跑推理，配合 IndexedDB 做本地向量存储，整条 RAG 链路从头到尾不需要一台服务器。Demo 页面（ternlight-demo.vercel.app）打开就能试，加载完首屏之后，后续所有向量化请求都在你自己的浏览器 tab 里完成。

如果你最近在做 RAG，应该能立刻明白这意味着什么。过去两年里，Embedding 服务是整个检索管线里最尴尬的一环：调用频率高、单次计算量不大、但延迟又必须压得很低。你要么忍受 OpenAI text-embedding-3 每百万 token 几美分的账单缓慢累积，要么自己在 GPU 上跑 bge、gte，然后为了几行文本的向量化维护一整套推理服务。Ternlight 给出的答案是：这些都不用，前端搞定。

7MB 是怎么做到的

先说结论——这不是一个能替代 bge-large 的模型，但对于绝大多数前端场景，它够用了。

主流的开源 Embedding 模型，哪怕是所谓的"轻量"级别，参数量也在 100M 上下，量化后落到磁盘上通常是 60-100MB。放到网页里加载是灾难性的：一个中等网速用户光下模型就得十几秒，还不算首次编译 WASM 的开销。Ternlight 把体积压到 7MB，走的是几条组合拳：

• 架构极简化：模型层数和 hidden size 都做了大幅裁剪，只保留生成句向量所需的最小结构；
• INT8 量化 + 权重打包：把 FP16 权重转成 INT8，同时对稀疏部分做压缩；
• 词表精简：BPE 词表从常见的 30k+ 砍到更紧凑的规模，只保留高频 token；
• WASM SIMD 指令：靠浏览器原生的 128-bit SIMD 做矩阵乘法加速，避免调用 WebGPU 带来的兼容性负担。

代价当然存在——这个模型在 MTEB 这类通用基准上肯定跑不过 bge-m3。但对于"我要在浏览器里搜一下这几百条笔记"、"帮用户在本地文档里做语义匹配"这类前端场景，7MB 换来的部署便利性，是任何服务端模型给不了的。

Transformers.js 路线的一次实践

技术选型上，Ternlight 走的是 Xenova 那套 Transformers.js + ONNX Runtime Web 的路子，但把体积做到了一个新的下限。之前 Reddit 上就有开发者用 Transformers.js + IndexedDB 搭过纯浏览器向量库，那时候大家的普遍反馈是——能跑，但模型体积和首次加载体验劝退。Ternlight 相当于把这条路线里最痛的"模型太大"这一环拧掉了。

典型的使用姿势大概是这样：

// 伪代码示意
import { TernlightEmbedder } from 'ternlight';

const embedder = await TernlightEmbedder.load();
// 模型权重从 CDN 拉取一次，之后走浏览器缓存

const vec = await embedder.embed('这是一段要向量化的文本');
// 返回 Float32Array，直接塞进 IndexedDB 就完事了

// 检索
const results = await vectorStore.search(queryVec, { topK: 5 });

整个链路里没有一次 fetch 走出用户设备。这对做隐私敏感应用的团队来说，几乎是最优解——用户的文档、笔记、聊天记录不需要离开浏览器，你也不用为了合规去搭 VPC、做数据脱敏。

它适合什么，不适合什么

我在自己的项目里跑了一下，谈几个具体的判断：

适合的场景：

1. 浏览器插件的语义搜索：比如做一个书签/历史记录的语义检索插件，服务端零成本，用户装完就能用。
2. 本地笔记类应用的 Web 版：Obsidian、Logseq 这类工具的 Web 端，本地向量化是天然刚需。
3. 在线文档编辑器的相关内容推荐：用户写着写着，实时给出"你可能想引用这段"的建议，走服务端每次都要额外一跳。
4. 教育、Demo 场景：教学生 RAG 是怎么回事，一个 HTML 文件跑起来比让他们注册 API Key 直观得多。

别硬上的场景：

1. 企业级知识库：几十万文档以上的规模，索引构建和检索精度都不是浏览器该扛的活。
2. 中英混合的复杂查询：小模型的多语言能力天花板明显，对精度敏感的话还是老老实实用 bge-m3、jina-embeddings-v3 这类。
3. 需要跨设备同步的向量数据：IndexedDB 是设备本地的，多端场景还是得回到服务端方案。

和服务端 Embedding 的成本账

算一笔账更直观。假设一个中小型应用每月有 100 万次 Embedding 请求：

• OpenAI text-embedding-3-small：约 $20/月
• 自建 bge 服务：一台 GPU 实例最低 $200/月起步
• Ternlight 浏览器方案：$0（除了那次 7MB 的 CDN 流量）

当然，服务端方案换来的是更强的模型和更好的多语言支持，这不是一个能简单替代的关系。但对于"我就想给用户一个能语义搜索的功能，别整那么复杂"的产品经理来说，Ternlight 这条路省下的不止是钱，还有整个后端基础设施的心智负担。

更大的趋势：推理正在往边缘挪

Ternlight 不是孤立事件。过去半年里，浏览器端 AI 推理的动作明显密集了起来：Chrome 内置了 Gemini Nano 的 Prompt API，WebGPU 生态里 WebLLM 已经能跑 8B 的模型，Transformers.js 的模型库越铺越广。核心逻辑很朴素——用户设备的算力这几年翻了几倍，一直闲着；而云端推理的电费和 GPU 折旧，最终都要用户或产品方买单。

Embedding 这一环，因为单次计算量小、对模型精度容忍度相对高，天然是最先被"边缘化"的候选。生成式模型往浏览器里塞还有各种权衡，但 Embedding 这块，Ternlight 这样的方案已经开始给出"直接不要服务器"的答案。

对开发者而言，一个更现实的组合姿势可能是：Embedding 走本地，生成走云端。用户在浏览器里做完检索，把 top-K 的相关文档拼进 prompt，再调用云端的 GPT-5、Claude 4.5 之类的大模型做生成。这样既省了 Embedding 的调用费和延迟，又保留了大模型的生成质量。

如果你在做这种混合架构，云端那部分 OpenAI Hub 可以直接兜底——一个 Key 打通 GPT、Claude、Gemini、DeepSeek 各家，国内直连不用折腾代理，兼容 OpenAI 格式改一下 base_url 就能跑，剩下的精力可以都放在把浏览器端 Embedding 用得更漂亮上。

一点保留

作为一个跑了几年 RAG 的编辑，我对 Ternlight 的态度是：这是一个很棒的工程实践，但别把它当银弹。7MB 的模型在语义理解的细腻度上，注定和大模型 Embedding 有代差。做原型、做轻量应用、做隐私敏感场景，它是当前能拿到的最优解之一；但如果你的业务对检索精度足够敏感，服务端 Embedding 该用还是得用。

真正让人兴奋的不是这一个 7MB 的模型本身，而是它证明了一件事——Embedding 服务这个存在了几年的"基础设施"，正在被重新定义。当模型足够小、浏览器足够强，很多我们习以为常的架构假设，都值得再拿出来问一遍。

参考来源

• Bye RAG Servers: 我在浏览器里直接做了向量数据库 - Reddit r/LocalLLaMA — 早期用 Transformers.js + IndexedDB 构建浏览器端向量库的实践讨论，Ternlight 的思路延续这条技术路线