一个自称“7MB”的句子嵌入模型，最近在Reddit的r/reactjs和r/LocalLLM上刷了一轮存在感。项目名叫Ternlight，作者是GitHub用户soycaporal，卖点很直白：用Rust编译成WASM塞进浏览器，不用服务器、不用API，装完npm包三行代码就能做语义搜索，官网Demo拿React官方文档做了个搜索框，号称嵌入一次只要5毫秒。
这套说辞听着诱人，但翻到Hugging Face上的模型说明才发现，7MB这个数字没那么简单——真正的模型权重文件只有4.6MB，剩下的是WASM运行时和胶水代码凑出来的打包体积。这个细节官网只字未提，却是判断这个项目到底有多“轻”的关键。
号称7MB，权重只有4.6MB
Ternlight提供两个npm包，@ternlight/base（7MB）和@ternlight/mini（5MB），官网页面把这两个数字当卖点反复强调。但Hugging Face上的模型卡显示，实际权重文件model-int4.bin只有4.6MB，说明官网写的7MB更像是引擎加权重打包后的总体积，不是模型本身的大小。这不是造假，但容易让读者误以为“模型只有7MB”，而实际模型更小，多出来的是运行时代码。
这个区分很实际。关心浏览器加载体积和下载时间，看7MB没问题；想横向比较模型压缩程度，该盯4.6MB这个数字，跟同类量化模型对比才有意义。
95%质量保留，代价谁来验证
Hugging Face的说明给了两个量化数据：相对教师模型的Spearman相关系数0.835，相对fp32学生模型保留了95%的质量。翻译一下，这个int4量化版本在语义相似度打分上，跟没压缩的版本比，排序一致性打了折扣，但幅度不算离谱。
问题在于，这两个数字、以及官网页面写的“约5ms”嵌入延迟，全部来自项目作者自己的说明和Reddit自述帖——作者在帖子里给出的实测数据其实是约2ms、每秒500次嵌入，跟官网的5ms对不上。差距可能来自测试环境或批量大小不同，但目前没有第三方跑分复现过这些数字，读者只能先当作作者自证，不能当成独立验证的结论。
所有性能数字目前都出自作者一人之口，尚无第三方复现
放进生态坐标系里看
浏览器端语义搜索这条赛道并不新，业界更常见的做法是Transformers.js配合Xenova的all-MiniLM-L6-v2，输出384维向量，支持WebGPU、回退到WASM，社区验证多年，生态成熟。Ternlight的差异化卖点是体积更小、接入更简单——三行代码，没有模型下载步骤。但官网和Hugging Face的说明里都没有给出Ternlight和MiniLM系列在检索质量上的正面对比，这恰好是开发者最该关心、却拿不到答案的一项。
- 风险.Demo覆盖约2000条React文档条目用的是什么检索方式没有说明，如果是暴力余弦相似度，语料规模一旦变大，浏览器端查询延迟会明显上升；服务器场景常用的sqlite-vss一类向量索引方案本身也不适配WASM环境，扩展性是个悬念。
谁该关心这件事
如果Ternlight的数据经得起检验，它确实给前端和全栈开发者提供了一个轻量、隐私友好（数据不出浏览器）的选项，适合FAQ匹配、意图分类、商品卡片匹配这类短文本场景，对离线应用和边缘设备尤其有吸引力。但拿到独立的第三方基准测试之前，更现实的做法是把它当候选先观察，不必急着替换已经跑通的Transformers.js+MiniLM路线。
接下来该盯的是：开源代码是否公开可复现、npm包下载量和真实反馈、以及有没有人做出跟MiniLM正面对比的检索质量测试。这些答案出来之前，7MB这个数字更多是一句漂亮的营销开场白。