DFlash 解碼加速：原理、限制與 oMLX 實作¶

狀態：已發布／持續更新　領域：AI／Local LLM／推論加速
基準：DFlash 論文 v2、DFlash 2、oMLX v0.6.2／v0.6.3rc2（查證至 2026-08-22）

這篇文章要解決什麼問題？

DFlash 如何在不讓小型 draft model 取代原模型的前提下加速 Local LLM？DFlash 2、量化、長上下文與 Apple Silicon 的 oMLX 又會如何改變實際效果？本文分開說明原始論文、後續 DFlash 2、Qwen3.8-27B 配對條件與可重現的 A／B 測試方法。

適用範圍與限制

DFlash 的公開效能主要來自 NVIDIA H200／B200；Qwen3.8-27B-DFlash2 的公開 Model Card 也以 H200 測量。Apple Silicon 的實際加速取決於 oMLX／MLX 版本、量化 kernel、Context、輸出長度與 acceptance length。本文不把 NVIDIA 結果當成 M 系列晶片的效能保證，也不把尚未公開的訓練 context length 填成推測值。

先看結論¶

DFlash 是 speculative decoding（推測式解碼），不是量化或模型壓縮。 小型 block-diffusion drafter 平行提出候選 token block，target model 再批次驗證。
「Lossless」是相對於實際 target model 的輸出分布。 前提是 Backend 正確實作驗證、接受機率與 rejection／residual correction。量化 drafter 通常影響 acceptance 與速度；若 target 本身是 4-bit，保留的是相對於該 4-bit target 的行為，不代表與 BF16 target 完全相同。
DFlash 主要加速 Decode，不消除長 prompt 的 Prefill。 長輸入、短輸出通常收益有限；長輸入、長輸出才較有機會攤平額外成本。
DFlash checkpoint 通常與特定 target 配對。 Target family、版本、Tokenizer、Vocabulary、內部 hidden representation 與 Runtime hook 都必須相容。
原始 DFlash 與 DFlash 2 的證據要分開。 原始 DFlash 有 ICML 2026 論文；DFlash 2 是後續 blog、程式、checkpoint 與 backend 整合，不能把兩者的架構與跑分混寫。
Qwen3.8-27B-DFlash2 的公開 config 名義上設定 262,144 positions，但未公開訓練 context length。 max_position_embeddings 不是訓練長度、有效能力或 Runtime 可穩定跑到 262K 的證明。
Draft 可在載入時做記憶體內量化，但選項依實作而異。 z-lab/dflash MLX CLI 提供 4／8-bit；oMLX v0.6.3rc2 UI 則提供不同的 Weight／Activation／Group-size 選項。
看到通用 DFlash UI 不代表該版本支援 DFlash 2。 應核對精確 oMLX 版本、dflash-mlx revision 與載入 log；API client 仍呼叫 target。
真正答案來自同條件 A／B benchmark。 至少記錄 TTFT、Prefill tok/s、Decode tok/s、端到端時間、acceptance length、Peak memory、Context、Output length 與 Concurrency。

快速閱讀路徑¶

先建立概念：讀第一至四節，理解量化、Draft、Target verification 與 Lossless 的範圍。
判斷值不值得用：讀第六、七、十一與十二節，分開看 NVIDIA 跑分、長上下文與本機 benchmark。
準備在 Apple Silicon 實作：讀第八至十節；oMLX 與 DFlash 2 版本仍快速變動，操作前要重新核對 release。
已熟悉量化：通用量化與 Prefill／Decode 背景可先看量化跨硬體選擇，本文只保留與 Draft acceptance、Block size 和額外記憶體直接相關的部分。

一、先把四個概念分開¶

技術	主要解決什麼	不直接解決什麼
權重量化	權重容量、權重搬運與相容低精度 kernel	不會自動縮小未量化的 KV cache
KV cache 量化	長 Context／Concurrency 的 cache 容量與流量	不會讓模型權重變小
Speculative decoding	減少 target 逐 token forward 次數、加速 Decode	不消除完整 Prompt Prefill
DFlash	用 block diffusion 平行完成 speculative drafting	不是通用 drafter，也不是模型能力升級

量化是降低數值表示精度，而不是讓 Dense model「少用一些權重」。若只有權重使用 4-bit，KV cache 仍可能保持 BF16／FP16；是否變快還要看 Runtime 是否有適合的量化 kernel。

DFlash 則改變 Decode 的執行排程：讓 drafter 一次提出多個候選，再由 target 驗證。兩者可以同時使用，但屬於不同層次。

術語速查¶

Forward：模型執行一次前向計算。
Hidden states：模型在每一層形成、尚未轉成最終 Token 機率的內部表示。
KV injection：把 Target 已建立的 Context 表示轉成 Draft attention 可使用的 Key／Value。
Acceptance length：每輪 Target verification 平均接受的 Token 數；不是實際倍速。
Verify width：Target 一輪同時驗證的候選寬度，通常受 Block size 影響。
Suffix decay：候選 Block 越靠後的位置，預測正確率逐步下降。
Rejection／residual correction：Sampling 模式拒絕候選後，用校正分布補償 Draft 與 Target 的差異，以保留 Target 分布。

二、為什麼傳統 Decode 很慢？¶

自回歸模型產生下一個 token 時，必須依賴前面所有 token：

Target LLM
→ token 1
→ token 2
→ token 3
→ token 4

每一步都需要新的 target forward。低 Batch 的 Decode 往往受到權重與 KV cache 搬運限制，強大的 GPU／Unified Memory 也無法完全消除這個序列相依。

傳統 speculative decoding¶

小型 draft model 先猜多個 token
→ Target 一次驗證整組候選
→ 依 Greedy 或 Sampling 規則接受候選
→ 拒絕時由 Target 驗證器修正並繼續

如果一次驗證能接受多個 token，target forward 次數便會下降。但傳統 drafter 往往仍逐 token 生成，draft 本身又形成新的序列瓶頸。

三、原始 DFlash 如何運作？¶

原始 DFlash 的核心不是單純換成 diffusion model，而是讓 drafter 持續取得 target 的內部 context：

Target Prefill／前一輪 verification
→ 從 target 多個深度抽取 hidden states
→ 經 projection 融合成 target context feature
→ 注入每一層 drafter 的 Key／Value
→ block diffusion 一次平行預測整個候選 block
→ Target 批次驗證
→ 接受有效前綴並繼續

1. Target knows best¶

小型 drafter 若只看 Token，必須自行重建語意與推理狀態，容量不足時 acceptance length 很快飽和。DFlash 從 target 淺層到深層抽取 hidden representation，再融合成 context feature，讓 drafter 不必完全從零猜測。

2. 每層 KV injection¶

DFlash 不只在 drafter 輸入端注入一次 feature，而是注入每一個 draft layer 的 Key／Value，並在 drafting iterations 間重用。這可降低深層 drafter 中 context signal 被稀釋的問題。

3. Block diffusion 平行 drafting¶

傳統自回歸 drafter 若要提出 k 個 token，通常需要多次序列 forward；DFlash 在一個 forward 中同時預測 block 內所有 masked positions。原始論文多數模型常見設定為：

五層 drafter；
五個由淺至深取樣的 target layers；
Qwen3 常用 block size 16；
Llama 3.1 使用 block size 10；
Embedding 與 LM head 與 target 共用並凍結；
只訓練 draft Transformer layers。

五層不是所有模型的固定規格；例如論文中的 Qwen3 Coder 使用八層 drafter。

四、Target verification 為什麼能維持輸出分布？¶

Drafter 的候選不是直接輸出。Greedy 與 Sampling 必須分開理解。

Greedy decoding¶

候選 Token 與 Target argmax 一致
→ 接受連續相符的前綴
→ 在第一個不相符位置改採 Target argmax

Sampling decoding¶

Sampling 不能只在拒絕後從 Target 原分布重新抽樣。標準 speculative sampling 會依 Target／Draft 機率計算接受機率；候選被拒絕時，典型做法是從校正後的 residual distribution 取樣：

residual ∝ max(p_target - p_draft, 0)

再正規化為機率分布。只有 Backend 正確完成接受機率、拒絕與 residual correction，才可宣稱保留 Target sampling distribution。

Lossless 的正確範圍

若 target 使用 4-bit 權重，DFlash 保留的是「4-bit target」的分布。前提是 Backend 正確實作 verifier 與 speculative sampling；它不會把 4-bit target 恢復成 BF16，也不保證不同 Backend、量化 recipe 或浮點誤差下逐字相同。

Draft 量化造成的主要風險通常是：

Draft 精度下降
→ 候選品質下降
→ Acceptance length 下降
→ Verification 次數增加
→ 加速幅度縮小

而不是讓 target 未驗證的錯誤候選直接輸出。

五、DFlash 2 改了什麼？¶

DFlash 2 是原始 DFlash 之後的工程與架構演進，目前主要由上游 blog、repository、checkpoint 與 backend 實作支持。

Candidate path selector¶

原始 DFlash 對每個位置獨立選 Top-1，可能出現各位置單獨合理、連起來卻不連貫的 block。DFlash 2 在每個位置保留 Top-k candidates，使用輕量 selector 評分相鄰 candidate pair，再選出一致路徑。

Qwen3.8-27B-DFlash2 公開 config 顯示：

selector_top_k = 16
selector_rank = 256

Dynamic short convolution¶

候選越接近 block 尾端，準確率常逐步下降，稱為 suffix decay。DFlash 2 加入兩 tap dynamic convolution，專門處理 block 內相鄰位置的短距依賴，避免只靠增加大量 Transformer layers 解決。

Qwen3.8-27B-DFlash2 公開設定¶

Draft layers：5
Block size：8
Target layer IDs：5、19、33、47、61
Selector top-k：16
Convolution kernel size：2
Max position embeddings：262,144
Sliding window：2,048

這些是架構與 Runtime 設定，不等於訓練資料說明。

六、公開效能數字應如何解讀？¶

原始 DFlash 論文¶

原始論文主要以 NVIDIA H200 測試，SGLang serving 使用單張 B200。論文報告的代表性結果包括：

Qwen3 instruct、greedy decoding：平均約 4.9× 相對自回歸 baseline；
Temperature 1：約 4.1×；
Reasoning 模式：約 3.9–4.5×；
個別 Transformers 測試超過 6×；
相對 EAGLE-3，部分條件約有 2.5× 更高的 speedup。

Qwen3.8-27B-DFlash2 Model Card¶

公開 Model Card 使用單張 NVIDIA H200、FlashAttention 3、block size 8、最多生成 4096 token。

Acceptance length：

Task	DFlash 2 acceptance length
GSM8K	5.46
MATH-500	5.28
HumanEval	4.39
MBPP	4.79
MT-Bench	4.10

Concurrency 1 的 throughput speedup：

Task	相對自回歸 baseline
GSM8K	3.43×
MATH-500	3.34×
HumanEval	3.11×
MBPP	3.29×
MT-Bench	2.67×

Concurrency 32 時只剩約 1.01–1.45×。這說明 baseline batching 提高硬體利用率後，speculative decoding 的相對優勢會縮小。

不能直接套用到 Apple Silicon

H200 的 FlashAttention、記憶體系統、block size 8 與 oMLX／MLX 量化 kernel 不同。Apple Silicon 必須重新測量，不能把 2.7–3.4×當成保證值。

七、長上下文到底有沒有幫助？¶

先區分兩種工作負載。

長輸入、短輸出¶

32K Prompt
→ 200-token 摘要

主要時間可能花在 Prefill、建立 target KV cache 與長上下文 attention。DFlash 只加速短短的 Decode，收益可能不夠抵銷 drafter 額外成本。

長輸入、長輸出¶

16K 程式碼
→ 2K–8K token 分析／修改

Prefill 只做一次，後續有大量 Decode；DFlash 才較有機會攤平 drafter 與 verification 成本。這仍有三個前提：Acceptance 不隨 Context 明顯下降、較寬 Verification 的 attention／KV 成本可控，而且輸出長度足以回收額外開銷。

Qwen3.8 DFlash2 的已知與未知¶

公開 config 顯示：

max_position_embeddings = 262144
sliding_window = 2048

可以確認 draft checkpoint 的公開 config 採用這些名義設定，但不能據此保證模型具備等長的有效能力或 Runtime 可穩定跑滿。公開 Model Card 與 DFlash 2 blog 沒有揭露：

Training sequence length；
訓練 Context 分布；
16K／32K／64K／128K／256K acceptance benchmark；
是否專門做過 long-context adaptation。

因此最安全的描述是：

Draft config 的名義 position limit：262K
公開訓練長度：未知
公開長上下文驗證：不足

不要把原始 DFlash 長上下文實驗移植過來¶

原始論文對 Qwen3.5-27B 的實驗是：基礎 drafter 約以 4K context 訓練，再用約 1,600 筆 LongAlign-10K 樣本 fine-tune 3 epochs，測到 16K、部分資料測到 32K。這證明 drafter 可經輕量 adaptation 改善長上下文 acceptance，但不是 Qwen3.8-27B-DFlash2 的訓練證據。

八、DFlash draft 可以量化嗎？¶

可以，但要先說清楚是哪一套實作。

`z-lab/dflash` 的 MLX CLI¶

該 CLI 明確提供：

--draft-bits 4
--draft-bits 8

程式碼會對 drafter 執行：

nn.quantize(draft, group_size=64, bits=draft_bits)

上游提供 target 與 draft 同時 4-bit 的範例：

dflash generate mlx \
  --model mlx-community/Qwen3.8-27B-4bit \
  --draft z-lab/Qwen3.8-27B-DFlash2 \
  --draft-bits 4 \
  --block-size 5 \
  --reasoning xhigh \
  "<PROMPT>"

Hugging Face 上的 draft checkpoint 本身是 BF16；--draft-bits 4 是載入時在記憶體中進行量化。Activation、KV cache 與非量化元件不會因此全部變成 4-bit。這只能證明 z-lab/dflash 這條 MLX CLI 路徑，不代表 MLX 平台只允許 4／8-bit，也不能直接推論所有 oMLX 版本的 UI 選項。

oMLX 的 `dflash-mlx` 整合¶

主線 oMLX v0.6.3rc2 的 UI 原始碼另外提供：

Draft weight：2／4／8-bit；
Activation：16／32-bit；
Group size：32／64／128。

這是 oMLX 該版本的整合介面，不應與 z-lab/dflash --draft-bits 混成同一組規格。不同版本仍需核對實際 Runtime pin 與載入 log。

為什麼量化 MLX 建議 block size 不超過 5？¶

較大 block 可增加每輪候選上限，卻不保證更快。查證至 2026-08-22，z-lab/dflash README 指出其當時的量化 MLX kernel 在較大的 verify width 下效率可能下降，因此建議：

block_size <= 5

這是上游對特定實作與版本的工程建議，不是 MLX 永久規格，也不保證適用所有 oMLX build。Apple Silicon 可從 3、4、5 做 A／B 測試，而不是直接照搬 H200 的 block size 8。

九、容量：48GB Apple Silicon 是否放得下？¶

查證至 2026-08-22，Hugging Face safetensors 檔案約為：

元件	磁碟檔案大小
`mlx-community/Qwen3.8-27B-4bit`	約 14.95 GiB
`Qwen3.8-27B-DFlash2` BF16 checkpoint	約 3.58 GiB
合計	約 18.54 GiB

這只能說明 48GB 裝置對「權重檔案 payload 看似仍有空間」，不能判定任何指定 Context 可穩定載入。執行時還要預留：

macOS 與其他程式；
Target／Draft KV cache；
Activation；
Verification buffers；
Runtime workspace；
長 Context 與 Concurrency。

Draft 載入時 4-bit 量化可降低可量化權重的常駐量，但不會把所有額外成本縮成四分之一。

十、在 oMLX 中如何正確配對？¶

先查精確版本，而不是只看 UI 是否出現 DFlash 欄位。查證至 2026-08-22：

oMLX 路徑	DFlash 2 狀態	注意事項
主線 v0.6.2	有通用 DFlash UI，但其 Runtime pin 未含 `DFlash2DraftModel`	看到欄位不能證明可載入 Qwen3.8 DFlash2
`z-lab/omlx-fork` 0.6.2-dflash2	專用 DFlash 2 build	屬歷史專用 fork；使用前保留原 app 與 rollback
主線 v0.6.3rc2	原始碼、Runtime pin 與 UI 範例已包含 DFlash 2	仍是 Release Candidate；正式環境需評估 RC 風險

還應在載入 log 確認 Runtime 實際建立 DFlash 2 drafter，而不是只有通用 DFlash 設定被儲存。

1. 下載模型¶

Target：

mlx-community/Qwen3.8-27B-4bit

Draft：

incoai/Qwen3.8-27B-DFlash2

z-lab/Qwen3.8-27B-DFlash2 是相同 checkpoint 的 mirror；在同一部署中固定 repository 與 revision，避免日後更新造成 Target／Draft 不一致。上游範例證實這組 MLX target／draft 可配對，不代表任意自行轉換的 Qwen3.8 量化檔都相容。

2. 編輯 target model¶

在已確認支援 DFlash 2 的版本中，編輯 Qwen3.8 target。專用 0.6.2-dflash2 路徑的已知設定為：

DFlash：enabled
Draft model：incoai/Qwen3.8-27B-DFlash2
Draft quantization：enabled
Runtime block size：先使用 5
Verify mode：dflash

主線 v0.6.3rc2 的 UI 預設 Verify mode 是 adaptive，並另外提供 dflash、ddtree、off；應依該版本 release 說明與 A／B 結果選擇，不要把專用 fork 的設定無條件套過去。儲存後卸載並重新載入 target model，再檢查載入 log。

3. API 呼叫哪個模型？¶

應用程式／OpenAI-compatible API
→ 呼叫 Qwen3.8-27B target
→ oMLX 內部呼叫 DFlash2 draft
→ Target 驗證並輸出

不要把 DFlash2 checkpoint 當成對外主模型；它不是可獨立對話的 LLM。

4. 何時才需要換 oMLX build？¶

若是主線 v0.6.2，即使已有一般 DFlash UI，也不能據此判定支援 Qwen3.8 DFlash2。應選擇已固定並驗證的路徑：專用 0.6.2-dflash2，或明確認知 RC 風險後使用主線 v0.6.3rc2 以上。安裝前保留原 app、設定與 rollback；日後正式版發布後再依 release note 更新本文。

5. oMLX 的 Concurrency 限制¶

上述 oMLX DFlash engine 是 single-stream：同一時間處理一個請求，並發請求會在 MLX executor thread 排隊。它不是一般 LLM BatchedEngine 的 continuous batching 路徑。

因此：

適合先測低 Concurrency、單人互動式 Decode；
不能用 H200 Model Card 的 Concurrency 8／32 結果預測 oMLX；
若設定 dflash_max_ctx 讓長 Prompt fallback 到 BatchedEngine，Fallback 請求已不是同一條 DFlash execution path，benchmark 必須另外標記。

十一、工程決策流程¶

目標主要是縮小模型或 KV cache？
├─ 是 → 先處理權重／KV cache 量化，不要把 DFlash 當壓縮
└─ 否
   ↓
主要瓶頸是長 Prompt Prefill？
├─ 是 → DFlash 幫助有限，先看 Prompt cache、Attention 與 KV 路徑
└─ 否，主要是長輸出 Decode
   ↓
有與 target 精確配對的 DFlash checkpoint？
├─ 否 → 不要硬套其他 drafter
└─ 是
   ↓
Runtime 支援該模型 family、量化與 verification path？
├─ 否 → 等待相容版本或改用支援 backend
└─ 是
   ↓
以相同條件比較 DFlash off／on
   ↓
Acceptance、Decode TPS、端到端時間與記憶體均符合需求？
├─ 是 → 保留並記錄版本
└─ 否 → 調整 block size／量化，或停用 DFlash

十二、可重現 benchmark matrix¶

固定條件¶

每次 A／B 測試必須保持相同：

Target model repository、revision 與量化；
Prompt 文字與 chat template；
Context length；
temperature、top_p、top_k；
Reasoning effort；
Maximum new tokens；
oMLX／MLX 版本；
dflash-mlx revision 與 oMLX execution path；
DFlash single-stream、一般 BatchedEngine 或 Context-threshold fallback；
背景程式、電源模式與散熱條件。

建議矩陣¶

維度	測試值
Context	4K、8K、16K、32K；有需要再測 64K
Output	256、1024、4096 token
DFlash	Off、On
Block size	3、4、5
Draft quantization	Off、4-bit；容量允許時可加 8-bit
Sampling	Greedy、實際使用的 temperature／top-p／top-k
Workload	數學、Coding、一般對話、長文件推理

oMLX DFlash 路徑是 single-stream，故主測試應以 Concurrency 1 進行。若另外測多個同時請求，要記錄排隊延遲，不能把結果當成 continuous batching throughput。

記錄指標¶

指標	回答什麼問題？
TTFT	Prefill 與排程是否變慢？
Prefill tok/s	DFlash 沒有處理的輸入成本多大？
Decode tok/s	推測式解碼是否真的提高輸出速度？
End-to-end time	使用者實際等候是否縮短？
Acceptance length	每輪 target verification 平均接受多少 token？
Verification steps	同樣輸出需要多少 target cycles？
Peak unified memory	Target、Draft、KV 與 Buffer 是否造成壓力？
Output length／stop reason	兩次測試是否真的做了相同工作？

長上下文判讀

Context 增加後，如果 Acceptance length 持續下降，即使 target 本身仍能處理該 Context，DFlash 的加速收益也可能逐步消失。max_position_embeddings 只能說明 position 設定，不是效能證明。

十三、常見誤解¶

「DFlash 是另一種 4-bit 技術」¶

錯。DFlash 是 Decode 排程／推測式解碼；4-bit 是數值表示。兩者可以組合，但不是同一技術。

「Drafter 量化後就不 Lossless」¶

不一定。量化 drafter 可能降低接受率；只有 Backend 正確完成 verification、接受機率與 residual correction 時，才可保留 target 分布。若 target 也量化，保留的是量化後 target 的分布。

「Config 寫 262K，代表訓練到 262K」¶

錯。這只是 draft config 的名義 position limit；訓練 Context、有效能力、Runtime 穩定性與長 Context acceptance 都需要另外揭露或測量。

「Block size 越大越快」¶

錯。較大的候選 block 會增加 verification width，且量化 MLX kernel 可能在較大 width 下效率降低。最佳值必須實測。

「oMLX 看得到 DFlash checkpoint，就一定已啟用」¶

不一定。Downloader 能找到模型只證明可下載；通用 DFlash UI 也不代表該 Runtime 支援 DFlash 2。還要核對 oMLX／dflash-mlx revision、完成配對、重新載入，並由載入 log 與 A／B 結果確認。

「DFlash 可以加速長 Prompt」¶

主要不是。它主要加速 Decode；Prefill、Target KV cache 與長 Context attention 成本仍存在。

十四、對本次討論的整理與修正¶

量化減少使用的權重或快取

條件式修正：量化降低權重表示精度；KV cache 只有另行量化時才縮小，不是讓 Dense model 少使用權重。

DFlash 一次預測多個可能

保留並精確化：Drafter 平行提出 token block；DFlash 2 可保留多候選並選路徑，最終仍由 Target 驗證。

對輸入部分幫助不大

保留：DFlash 主要加速 Decode，不消除 Prompt Prefill。

oMLX 應呼叫 Qwen3.8

保留：API 對外呼叫 Target；DFlash2 是內部 Drafter。

看到 DFlash UI 就一定能直接使用 DFlash 2

不採用：必須核對精確 oMLX 與 dflash-mlx revision。主線 v0.6.2 的通用 DFlash UI 不等於 Qwen3.8 DFlash 2 Runtime 支援。

Qwen3.8 DFlash2 訓練到 262K

不採用：公開資料只證明 draft config 的名義 position limit；Training Context 與長 Context 能力未揭露。

十五、尚待實測¶

[ ] 48GB Apple Silicon 上，Qwen3.8-27B 4-bit 搭配 draft 4-bit 的 Peak unified memory。
[ ] oMLX 下 block size 3、4、5 的 Acceptance length 與 Decode tok/s。
[ ] 4K、8K、16K、32K Context 下的長上下文退化曲線。
[ ] Greedy 與實際 sampling 設定下的速度差異。
[ ] 長輸入、短輸出與長輸入、長輸出的端到端 break-even point。

這些未測項目不妨礙理解方法，但在取得特定裝置數據前，不應把任何倍速寫成 M5 Pro 的保證。

十六、來源¶

DFlash: Block Diffusion for Flash Speculative Decoding, arXiv:2602.06036v2：原始方法、訓練、H200／B200 實驗與 long-context adaptation。
DFlash upstream repository：目前的模型／backend matrix、MLX CLI、draft quantization 與 block-size 警告。
DFlash 2: Keep Drafting Parallel：Candidate selector、dynamic convolution 與後續實作說明。
Qwen3.8-27B-DFlash2 Model Card：Checkpoint 配對、H200 benchmark、Acceptance length 與 Throughput。
Qwen3.8-27B-DFlash2 config：Block size、Target layer IDs、Sliding window 與 Position 上限。
MLX nn.quantize source（v0.32.0）：MLX 模組量化 API 的版本固定原始碼參考。
DFlash-capable oMLX release reference：特定整合版本的歷史參考；不表示所有現行使用者都必須改裝此 build。
oMLX v0.6.2 source：通用 DFlash UI 與當時的 dflash-mlx pin，用於說明「看到欄位」不足以證明 DFlash 2 支援。
oMLX v0.6.3rc2 source：DFlash 2 Runtime pin、Qwen3.8 DFlash2 UI 範例、量化欄位與 single-stream 限制。
dflash-mlx revision b7f6255：oMLX v0.6.3rc2 固定的 Runtime；包含 DFlash2DraftModel loader、candidate selector 與 speculative sampling residual correction。