## RTX 2080 SUPER 8GB で Qwen3.5-35B-A3B に対して DFlash の推測デコーディングを動かすことに成功しました。VRAM がかなり限られた環境でも、**DFlash 推測デコーディング**が llama.cpp で動作させられました。これはこの DFlash PR でテストしました：https://github.com/ggml-org/llama.cpp/pull/22105 ビルドテスト済み：```text 67cb0d507 (8942) 

セットアップ：

GPU: RTX 2080 SUPER 8GB モデル: Qwen3.5-35B-A3B Q5_K_M ドラフトモデル: Qwen3.5-35B-A3B-DFlash Q4_K_M バックエンド: CUDA 

メインモデルは 35B MoE の GGUF で、だいたい 24.44 GiB です。なので当然ながら 8GB VRAM には収まりません。コツは MoE エキスパートの CPU オフロード と DFlash を組み合わせることでした。

ベースライン

私の DFlash なしの通常の最良の実行はだいたい：

~26.8 tok/s 

で、概ね：

-ngl 999 -ncmoe 32 -fa 1 -ctk q8_0 -ctv q8_0 --no-mmap -t 5 

-ncmoe 32 が最良のベースラインでした。これより小さい値だと VRAM を使いすぎてしまい、性能も悪化し、これより大きい値だと徐々に速度が低下しました。

DFlash 設定

DFlash では次を使いました：

ターゲットモデル: C:\models\Qwen3.5-35B-A3B-Q5_K_M.gguf ドラフトモデル: C:\models\Qwen3.5-35B-A3B-DFlash-Q4_K_M.gguf 

ドラフトモデルはターゲットに比べてとても小さいです：

DFlash ドラフトサイズ: ~267.8 MiB ドラフトパラメータ: ~474M ドラフト量子化: Q4_K_M 

なぜなら DFlash のドラフトも VRAM を必要とするため、最適な -ncmoe 設定が少し変わりました。通常の実行では -ncmoe 32 が最良でした。DFlash では最適点が：

-ncmoe 34 

最終コマンド

これはテストに使った最終的なコマンドです：

build\bin\Release\llama-speculative-simple.exe ^ -m "C:\models\Qwen3.5-35B-A3B-Q5_K_M.gguf" ^ -md "C:\models\Qwen3.5-35B-A3B-DFlash-Q4_K_M.gguf" ^ --dflash ^ -p "クイックソート、マージソート、ヒープソート、二分探索の完全な Python 実装を書いてください。簡潔なコメントを入れてください。コードのみを書いてください。" ^ -n 512 ^ --draft-max 6 ^ -cd 512 -c 4096 ^ --temp 0 --top-k 1 --seed 42 ^ -ngl 999 -ngld 99 -ncmoe 34 ^ -fa on ^ -ctk q8_0 -ctv q8_0 ^ -ctkd q8_0 -ctvd q8_0 ^ --no-mmap ^ -t 5 

結果

典型的な DFlash の結果：

encoded 39 tokens in ~1.0 sec decoded 514 tokens in ~14.3-14.5 sec speed: ~35.6-35.8 tok/s n_draft = 6 n_predict = 514 n_drafted = 430 n_accept = 427 accept = 99.302% 

ベースラインと比較すると：

通常: ~26.8 tok/s DFlash: ~35.6-35.8 tok/s 増加: ~1.33x 

つまり、8GB の RTX 2080 SUPER で 生成速度が約 33–34% 改善しました。

ドラフト長の調整

--draft-max をいくつか試しました：

draft-max 5: ~34.6 tok/s, accept ~97.9% draft-max 6: ~35.6-36.9 tok/s, accept ~99.3% draft-max 7: ~35.7 tok/s, accept ~95.8% draft-max 8: ~34.1 tok/s, accept ~94.7% draft-max 12: ~31.5 tok/s, accept ~83.4% 

--draft-max 6 が最適でした。値を大きくしても受理率が下がるため、良くなりませんでした。

使用した量子化

ターゲットモデル：

Qwen3.5-35B-A3B-Q5_K_M.gguf ファイルサイズ: 24.44 GiB 種別: Q5_K_M 

内部的には、ターゲット GGUF は次を報告します：

f32: 301 tensors q8_0: 312 tensors q5_K: 80 tensors q6_K: 40 tensors 

DFlash のドラフトモデル：

Qwen3.5-35B-A3B-DFlash-Q4_K_M.gguf ファイルサイズ: 267.80 MiB 種別: Q4_K_M 

内部的には、ドラフト GGUF は次を報告します：

f32: 34 tensors q4_K: 49 tensors q6_K: 8 tensors 

KV キャッシュ：

ターゲット KV: q8_0 / q8_0 ドラフト KV: q8_0 / q8_0 

ドラフト KV の量子化を低くすることも試しましたが、あまり効果はありませんでした：

ドラフト KV q8_0/q8_0: ~35.8 tok/s ドラフト KV q4_0/q4_0: ~35.6 tok/s 

そのため、ドラフト KV は q8_0 のままにしました。

メモ / 注意点

私がテストした PR/build には、パフォーマンス要約の表示にいくつか奇妙なタイミング出力があり、総時間がマイナスになったり、未計上のメモリ値が変だったりしています。

そのため、壊れている要約の項目は無視して、安定している部分に注目しました：

decoded tokens / seconds accept rate n_draft / n_accept 

生成されたテキストからも、実際に DFlash が使われていることが分かります：

n_draft = 6 n_drafted = 430 n_accept = 427 accept = 99.302% 

また、ドラフトモデルは GPU に完全にロードされていました：

DFlash ドラフトモデルバッファサイズ = ~267.80 MiB GPU にオフロードされた層 9/9 

結論

DFlash はここではかなり役に立ちました。

私の環境：

RTX 2080 SUPER 8GB Qwen3.5-35B-A3B Q5_K_M DFlash ドラフト Q4_K_M MoE CPU オフロード llama.cpp PR #22105 

速度が：

26.8 tok/s 

から：

35.6-35.8 tok/s 

現在の最適設定：

-ncmoe 34 --draft-max 6 -fa on -ctk q8_0 -ctv q8_0 -ctkd q8_0 -ctvd q8_0 --no-mmap -t 5 

この結果にはかなり満足しています。特に、GPU の VRAM は 8GB しかないことを考えると。