AI 模型與平台更新推理加速

Liquid AI 的 DSpark 為 LFM2.5 帶來高達 3.2 倍的吞吐量提升——且不改變貪婪輸出

Liquid AI 發布了 LFM2.5-1.2B-Instruct、2.6B 和 8B-A1B 的 DSpark 草稿檢查點，新增推測解碼以大幅加速：GPU 上最高達 3.18 倍，設備端達 2.87 倍，且記憶體開銷極小，貪婪輸出保持一致。llama.cpp 與 SGLang 即日支援，使其成為邊緣與代理工作負載的實用升級方案。

NexusAi 研究團隊2026年8月25日2.1K 次閱讀8 分鐘閱讀

Liquid AI 的 DSpark 為 LFM2.5 帶來高達 3.2 倍的吞吐量提升——且不改變貪婪輸出

AI 簡報

Liquid AI 的 DSpark 以草稿檢查點形式推出三款 LFM2.5 模型，新增推測解碼路徑，在保持貪婪輸出不變的同時提升解碼吞吐量——在 H100 GPU 上最高達 3.18 倍，在 MacBook 上達 2.87 倍，且記憶體開銷極小。DSpark 結合平行骨幹、輕量序列頭與信心調度驗證器，提升接受率並攤薄多標記權重負載。llama.cpp 與 SGLang 即日支援，團隊可快速在 GPU 與設備端環境評估。結論是：較小的指令調校模型現能達到聊天、程式與代理循環（尤其是功能呼叫）的互動速度，無需重新訓練或犧牲貪婪條件下的輸出確定性。

Liquid AI 正式推出 LFM2.5-1.2B-Instruct、2.6B 及 8B-A1B 的 DSpark 草稿檢查點，為解碼路徑新增推測解碼。其主張明確：在單顆 H100 GPU 上吞吐量最高提升至 3.18 倍，設備端則達 2.87 倍，同時保持貪婪輸出與基線完全一致。這種一致性至關重要——DSpark 會驗證每個提議的標記，因此團隊能在不影響既有評估基準的前提下採用加速方案。配合 SGLang 與 llama.cpp 的即日支援，這不僅是實驗室展示，而是能立即在常見推理架構中運行。其影響最明顯於需要即時反應的小型模型，如本地聊天、程式助理與代理功能呼叫，DSpark 亦大幅降低延遲。

為何現在能奏效？大型語言模型解碼通常受限於記憶體：反覆從 DRAM 讀取龐大權重成為延遲瓶頸。DSpark 透過使用緊湊的草稿器一次提議多個標記，接著由目標模型單次驗證，攤薄權重讀取流量。其方法結合 DFlash 式平行骨幹與輕量馬可夫頭以增加標記間依賴，並搭配信心調度驗證器修剪低信心後綴。Liquid AI 的草稿器約 3 億參數，訓練目標為提高接受率而非純損失，推動每次驗證通過更多標記。結果是每個輸出標記所需的記憶體往返次數減少，換來更高吞吐量且不改變貪婪輸出。

效能在不同場景表現不一。對於小型密集模型（1.2B–2.6B），DSpark 在 GPU 上穩定帶來 2–3 倍提升，且在設備端也有顯著加速，達到互動即時感受。8B-A1B MoE 模型在 GPU 上表現強勁，但設備端提升較有限，因現有 Metal MoE 效率與跨多專家驗證多標記的成本所限。儘管如此，DSpark 提升筆電標記處理速度，使本地助理與代理更實用，且在代理流程中，Liquid AI 報告功能呼叫延遲平均降低超過一半，對於工具密集場景中回應時間瓶頸是一大勝利。

操作上，DSpark 是低摩擦升級：在 SGLang 中將草稿附加至目標模型，或使用支援 DSpark 的 llama.cpp 版本，接著監控接受率與 draft_n/draft_n_accepted 以驗證效益。從與目標 LFM2.5 模型匹配的草稿器及適中區塊大小開始，針對領域文本調整以穩定接受率。由於推測解碼在貪婪條件下精確，評估工具與基準仍保持一致。生產環境中，需端到端驗證代理效能，特別是工具延遲與功能呼叫節奏，因 DSpark 的實際投資報酬率在多步工具呼叫主導回應時間時最為顯著。

核心要點

貪婪輸出一致且實現真實加速

DSpark 驗證每個提議標記，確保貪婪解碼輸出與基線一致，同時在 GPU 上提供最高 3.2 倍吞吐量及強勁設備端提升，適合重視正確性與響應速度的場景。

邊緣與代理工作負載優先受益

較小的密集 LFM2.5 模型在本地達到互動速度，多工具代理流程中 DSpark 平均將功能呼叫延遲削減超過一半，顯著降低回合時間。

快速採用，精準衡量

附加 DSpark 草稿器，追蹤接受率與 draft_n_accepted，評估標記成本效益與端到端延遲。MoE 設備端提升較薄弱，待 Metal 核心與排程成熟後效益將更明顯。

Liquid AI 最新發布及其重要性

DSpark 為三款 LFM2.5 模型提供草稿檢查點，啟用推測解碼以提升吞吐量且不改變貪婪輸出。這項提升對雲端與邊緣皆具意義：在 H100 GPU 上測得最高 3.18 倍，MacBook 級設備上達 2.87 倍，且額外記憶體開銷極小。配合 SGLang 與 llama.cpp 的即日支援，DSpark 不僅是研究分支，而是接近生產的方案。對於重視響應速度與成本的創業者與平台團隊，這讓較小模型能在程式編碼、聊天與代理循環中達到互動速度，減少僅為降低延遲而擴大模型的壓力。

DSpark 如何提升吞吐量並保持貪婪一致性

推測解碼透過輕量草稿器一次提議多個標記，並由目標模型單次驗證，解決記憶體限制的解碼瓶頸。DSpark 結合平行骨幹處理所有草稿標記、序列馬可夫頭提升後位標記接受率，以及信心調度驗證器修剪低信心後綴，推動每次驗證接受更多標記。Liquid AI 訓練約 3 億參數的草稿器，目標為提高接受率而非僅降低損失。在貪婪解碼下，遭拒絕的提議會由目標模型自行選擇替代，確保輸出與基線一致。結果是每個輸出標記所需的記憶體往返次數減少，實現更高標記每秒且不改變輸出。

最適用場景：GPU 與設備端差異及 MoE 注意事項

對於 1–3B 的密集模型，DSpark 在 GPU 上常見 2–3 倍吞吐量提升，且在現代筆電上超過 2 倍，足以改變聊天與程式體驗並加速代理循環。8B-A1B MoE 變體在設備端加速較有限，因現有 Metal 後端效率及跨多專家驗證多標記的成本所限。若工作負載工具密集，功能呼叫延遲平均降低 57% 尤為重要。總結：針對追求互動體驗或成本敏感服務的小至中型模型，選擇 DSpark 是理想方案；MoE 設備端則需保守預期，待核心與後端支援成熟後效益將更明顯。

整合指南：從實驗室到生產的信心建立

採用 DSpark 時，將目標 LFM2.5 模型與相符草稿器配對於 SGLang，或使用支援 DSpark 的 llama.cpp 版本。從預設草稿區塊大小開始，透過接受率與每次回應的 draft_n 與 draft_n_accepted 監控效益。於真實流量組合（聊天、程式、數學與工具使用）中評估，避免過度擬合單一語料。設備端部署時，配合所選量化與上下文長度評估記憶體餘裕。生產環境中，追蹤端到端代理延遲與標記成本效益，而非僅是標記每秒，以捕捉 DSpark 對功能呼叫回合時間與整體用戶感知響應的影響。

限制、風險與後續觀察重點

DSpark 的貪婪輸出一致性不適用於非貪婪設定；溫度採樣或核採樣會改變接受動態，可能重新引入漂移，故需在要求一致性時使用確定性解碼。MoE 模型驗證多標記會啟動更多專家，並飽和記憶體頻寬，導致設備端加速有限，直至核心優化。草稿器帶來少量記憶體開銷，需與上下文長度及 KV 快取一併預算。最後，持續關注 SGLang 與 llama.cpp 的上游支援；隨著核心與排程優化，特別是在 Metal 平台，MoE 設備端差距有望縮小。