7MB模型在浏览器CPU上5ms跑完，在无服务器推理之上能造的产品

问题是什么

Hacker News的Show HN上出现的Ternlight,精准戳中了要害。一个7MB的嵌入模型靠WebAssembly在浏览器CPU上完整运行,单次调用约5ms,服务器调用为零。它输出384维向量,衡量文本之间的语义相近程度。它暴露的不是一个工具,而是一块空白。今天要给Web产品加上语义搜索、意图分类、FAQ匹配、个性化,多数团队都把每一次输入往返到服务器的嵌入API。每一次往返都压上网络延迟,用得越多令牌成本越堆越高,用户敲进去的文字离开设备落到别人的服务器上,一到飞行模式或公司内网,功能整个停摆。最常见的AI功能,却压在最重的基础设施之上。

为什么是现在

两条曲线刚刚交叉。一条是模型变得足够小。Ternlight用Mamba系结构加二值权重,不做浮点运算,小到能出5MB的迷你版。另一条是浏览器运行时成熟了:WASM已经跑出可用速度,WebGPU在后面托底。这里再叠上第三股力量。云推理单价正被开放权重压垮,而端侧不是压低单价,而是直接归零。再加上让数据不离开设备的隐私合规压力。超轻量的端侧推理,正站在个人demo即将固化成标准产品层的那块空白上。

怎么构建

把嵌入压回浏览器,连向量索引也放在本地。用户输入,模型在浏览器内取出向量,在本地索引里算相似度,一次网络都不走就返回结果。产品面很宽:浏览器扩展式语义搜索,离线笔记与文档应用的即时搜索,数据绝不外传的隐私优先FAQ机器人,客户端表单自动分类,无服务器的边缘个性化。工具面也实在:端侧嵌入SDK,浏览器本地向量库,小模型的量化与蒸馏流水线。

flowchart LR
  A[用户输入] --> B[浏览器内模型, CPU上的WASM]
  B --> C[端侧向量索引]
  C --> D[约5ms排好序的结果]
  B --> E[无服务器, 私密, 离线]

入口要窄。从瞄准单一嵌入型工作负载(比如文档搜索)的拖入式SDK起步,一行装好,再叠上本地向量库与分类、排序,最后靠框架集成铺开。收费上,开发者SDK按席位或用量计,做成成品的终端产品再叠订阅。

成功条件

第一,包体积预算。首屏多加的几MB不能把用户赶走,所以要靠懒加载和回访缓存,保证第二次起零网络。第二,诚实的质量边界。小模型不如前沿嵌入精准,把端侧够用的工作负载和服务器更胜一筹的工作负载分开来卖,信任才立得住。第三,窄窄的楔子。别去追整个端侧AI,谁先在一个工作负载上证明”这个本地更好”,谁才拿到进下一格的资格。