大語言模型在生成文字時，最主要的效能瓶頸往往不在於計算量，而是在於記憶體頻寬。在解碼階段，系統必須不斷將龐大的權重數據從 DRAM（動態隨機存取記憶體）搬運到 SRAM（靜態隨機存取記憶體）中，這種記憶體受限（Memory-bound）的特性導致推論速度難以突破。為了解決這個問題，Liquid AI 推出了 LFM2.5-DSpark 投機解碼模型，旨在不犧牲輸出品質的前提下，顯著提升從高效能 GPU 到行動裝置的推論吞吐量。
背景與投機解碼原理
投機解碼（Speculative Decoding）是一種優化推論速度的策略。其核心邏輯是使用一個極小且輕量化的草稿模型（Draft Model）先行預測接下來可能出現的一組標記（Tokens），然後由主模型（Target Model）在一次前向傳播中同時驗證這些候選標記。如果主模型認同草稿模型的預測，就可以一次性產出多個標記，而非一個接一個地生成，從而分攤搬運權重的時間成本。
Liquid AI 引入的 DSpark 技術則進一步優化了這個過程。DSpark 結合了三項關鍵組件：首先是類 DFlash 的並行骨幹網路，它能根據主模型的上下文特徵，在一次傳播中產生所有草稿標記的隱藏狀態；其次是一個輕量級的序列頭（Sequential Head），透過馬可夫鏈（Markov chain）建模來捕捉標記之間的依賴關係，提升後續位置的接受率；最後是信心調度驗證器（Confidence-scheduled Verifier），它能預測每個標記的生存機率，並在驗證成本高於潛在收益時，果斷剪除低信心的後綴。
模型架構與訓練細節
為了支持 LFM2.5 系列模型，Liquid AI 釋出了對應 LFM2.5-1.2B-Instruct、LFM2.5-2.6B 以及 LFM2.5-8B-A1B 的 DSpark 草稿模型。這些草稿模型規模極小，參數量約在 3 億（300M）左右。其結構簡化為僅包含 5 層的注意力機制（Attention-only）模型，並在涵蓋指令微調（SFT）、對話、程式碼及函數調用（Function-calling）的多樣化數據集上進行了 15 個 Epoch 的訓練。
值得注意的是，Liquid AI 在選擇最佳模型權重時，並非追求最低的損失函數（Loss），而是選擇標記接受率（Acceptance Rate）最高的版本，因為這直接決定了投機解碼的實際加速效果。由於投機解碼在貪婪解碼（Greedy Decoding）模式下，只有在草稿標記與主模型分佈完全一致時才會被採納，否則會由主模型修正，因此 DSpark 在保證速度提升的同時，能與原版模型維持完全相同的輸出品質與準確度。
實測性能與應用影響
根據測試數據，DSpark 在不同硬體環境下展現了顯著的加速效果。在 NVIDIA H100 GPU 上，最高可實現 3.18 倍的吞吐量提升；而在 M4 Max MacBook Pro 等邊緣裝置上，平均加速比約為 2.27 倍。對於 LFM2.5-2.6B 模型，其在 MacBook 上的生成速度可達每秒 140 個標記，遠超許多雲端私有模型的互動體驗。
此外，DSpark 對於需要高頻率呼叫外部工具的代理人（Agentic）場景具有重大意義。實測顯示，LFM2.5-2.6B 在執行函數調用時，平均延遲降低了 57%。這意味著 AI 代理人在思考與採取行動之間的停頓感將大幅減少，使即時互動變得更加自然。
技術限制與實作部署
儘管整體表現強勁，但 DSpark 的加速效果在不同架構的模型中有所差異。例如在 LFM2.5-8B-A1B 這一類 MoE（混合專家模型）上，雖然標記接受率較高，但在邊緣裝置上的提升僅約 18%。這是因為目前的 MoE 實作在驗證多個標記時，會激活更多專家權重，導致記憶體流量增加，抵消了部分加速效果。
目前 LFM2.5-DSpark 已提供對 llama.cpp 與 SGLang 的原生支持，使用者可以透過 GGUF 或 Safetensors 格式載入草稿模型，快速將其整合進現有的推論管線中。透過這種方式，開發者可以在不增加顯著記憶體開銷的情況下，讓模型在端側裝置上擁有接近雲端等級的反應速度。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。