Liquid AI草稿模型解碼提速3.18倍

8月20日，Liquid AI在Hugging Face上釋出一組LFM2.5-DSpark草稿模型，為自家三款模型配上推測解碼：LFM2.5-1.2B-Instruct、2.6B與8B-A1B。官方公布的加速幅度最高達3.18倍，輸出結果與原始模型完全一致。

推測解碼的原理並不複雜：先讓一個小模型把接下來的幾個詞猜出來，大模型不必逐字計算，而是把這串候選詞放進一次前向傳播裡一併驗證。猜對就直接採用，猜錯才重新計算。省下來的全是權重反覆搬進搬出的時間。

655MB換來兩三倍速度

Liquid AI這次搭配的草稿模型都非常小。1.2B版本對應一個2.957億參數的草稿模型，2.6B與8B-A1B則共用一個3.277億參數的版本。架構為5層全注意力機制、隱藏維度2048、中間層6144，32個查詢頭共享8組KV，每次提出9個候選詞。BF16精度下，顯示記憶體用量為655MB。

拿一台16GB記憶體的Mac粗略估算：655MB約占總記憶體的4%，換來的是本機對話回應快上一倍多。這個交換比在端側場景裡相當划算。端側最缺的從來就不是運算力峰值，而是等待時那幾秒的空白。

數字要看跑在什麼硬體上

官方基準測試分成兩套環境，結果落差不小。

標題那個3.18倍，來自8B-A1B在H100上的最佳成績。同一個模型換到M4 Max筆電上，只剩1.18倍。Liquid AI自己把原因寫了出來：llama.cpp的Metal後端目前對混合專家（MoE）架構的實作還不夠完善，端側MoE是這套方案的弱點。

接受率的數據也一併公開了。8B-A1B在MATH500上，平均每10個候選詞能被接受8.27個，GSM8K上則只有4.02個。像數學證明這類結構工整、可預測性高的文本，草稿模型猜得準；換成小學應用題那種表達方式隨意的題型，命中率立刻掉了一半。

另一項數據更貼近實際用途：在多工具函式呼叫的場景下，2.6B版本的延遲平均降低了57%。代理（Agent）每一步都得等模型吐出結構化呼叫，這類來回處理最怕延遲層層疊加。

這套方法從哪裡來

DSpark這個名字不是Liquid AI取的。它出自今年6月底DeepSeek與北京大學聯合開源的一篇研究，用並行草稿骨幹搭配輕量馬可夫頭，再加上一層依GPU即時負載調整驗證長度的機制。當時公布的數據是：單一使用者的生成速度提升60%到85%，在嚴格延遲目標下，單卡吞吐量最高衝到6.6倍。

兩個月後，這套方法出現在一家美國端側模型公司的發表中。SGLang的啟用方式是加一個--speculative-algorithm DSPARK參數，llama.cpp首日就支援Metal後端的FP16 GGUF格式。上游框架把演算法名稱直接當成開關值寫進命令列，這件事本身就說明這套方法已被當作事實標準。

中國的實驗室這兩年開源了不少推論端的工程成果，討論多半集中在能不能省下算力成本。DSpark這次的外溢效應提供了另一種回報：方法被納入別人的預設路徑，往後所有基於該框架的部署，跑的都是你的想法。

授權條款劃了一條線

權重以Safetensors與GGUF兩種格式釋出，採用LFM開放授權1.0：年營收低於1000萬美元的主體可免費商用，超過這條線就得另外洽談商業協議。部署方式僅限自行架設（Self-hosted），Liquid AI並未提供代管API。

這條線卡在新創公司與中大型企業之間，意圖相當明確——用免費額度換取開發者的預設選擇，把營收留給付得起的那一群。

參考來源：Hugging Face官方部落格、Liquid AI模型卡、CocoLoop、MarkTechPost；加速倍數、參數量與接受率數據以官方基準測試表為準，授權條款以模型頁面為準。