背景與技術限制：為何需要手動抽取 DFlash

該名使用者日常使用 Ling-3.0-tiny 模型處理 PDF 轉 Markdown 的工作流，包括去除多餘空白與合併斷行。雖然該小模型足以勝任此任務，但推理速度對於其規模而言偏慢。

近期社群發布了針對 Ling-3.0-tiny 的 UBTree DFlash 優化技術，旨在提升推理效率。然而，目前主流推理引擎尚未原生支援完整的 UBTree 架構。

為了立即體驗加速效果，開發者從原始 UBTree 模型中手動移除了 7 個 ubtree_selector.* 張量，僅保留純 DFlash 部分。這種簡化後的模組結構相容於 llama.cpp 現有的 dflash drafter 功能。

實測數據：程式碼生成效益遠高於散文

開發者在標準 llama.cpp 主線版本上執行轉換後的模型，並記錄了不同工作負載下的效能變化。測試環境使用 Q4_K_M 量化權重搭配 BF16 精度的 DFlash 草稿模型，啟用 Flash Attention 與 32k 上下文視窗。

在一般散文生成任務中，基準速度為每秒 78.8 個 token，加入 DFlash 草稿後提升至每秒 84.8 個 token，增幅約 8%。此場景下的草稿接受率僅為 0.28，平均草稿長度為 2.7 個 token。

相較之下，在 Python 程式碼生成任務中，基準速度為每秒 79.0 個 token，加入 DFlash 後大幅提升至每秒 127.2 個 token，增幅達 61%。此場景的草稿接受率高達 0.53，平均草稿長度為 4.2 個 token。

轉換過程與未來展望

為了完成模型格式轉換，開發者對 llama.cpp 的 GGUF 轉換器進行了微小的程式碼修改，相關細節已發布於 Hugging Face 模型頁面。除轉換步驟外，其餘執行環境均使用未經修改的標準 llama.cpp 版本。

開發者指出，目前的測試僅為小規模初步驗證，結果屬於中等程度。若未來 llama.cpp 能原生支援完整的 UBTree 架構，預期將能發揮該技術的全部潛力，帶來更顯著的加速效果。