LFM2.5 加入 DSpark 草稿模型，H100 解碼吞吐量最高提高 3.18 倍

Liquid AI 為 LFM2.5-1.2B-Instruct、2.6B 與 8B-A1B 釋出 DSpark 草稿模型，提供原生及 GGUF 檢查點。這些約 3 億參數的 sidecar 不負責產生最終答案，而是先提出一段候選 token，再由原模型一次驗證；只要採樣與驗證實作正確，便可維持目標模型原有的輸出分布。

DSpark 與一般平行草稿器的差別，是在平行 backbone 後加入輕量順序模組，讓同一候選區塊內的 token 能互相依賴，減慢越接近區塊尾端、接受率越低的問題。信心頭再估算候選前綴的存活機率，讓排程器按硬件吞吐曲線及系統負載縮短驗證長度，避免高併發時把批次容量浪費在低信心尾段。

以 LFM2.5-2.6B 為例，Liquid AI 在五組數學、程式及對話測試上，測得單張 H100 的平均解碼速度由每秒 323 token 升至 864 token，即 2.67 倍；M4 Max 則由平均 61 升至 139 token，即 2.27 倍。多工具情境的函式呼叫延遲平均下降 57%。整個系列的單項峰值為 H100 的 3.18 倍及裝置端的 2.87 倍。

工程團隊應把接受長度、草稿器記憶體、批次大小與尾延遲一併量度。結構化數學和程式碼通常比開放式對話容易預測，官方表格也顯示不同資料集的收益差距可超過一倍；現有結果主要來自供應商、batch 1 與特定硬件配置。llama.cpp 的 DSpark 路徑亦仍集中在伺服器共用層，直接嵌入其核心 C API 的應用未必能立即啟用。