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,誰先在一個工作負載上證明「這個本地更好」,誰才拿到進下一格的資格。