Post by @BD1pt0ZCnY | soushou Diary

要点だけまとめると、DiffusionGemma GGUFは普通のGGUFモデルとして扱うと詰まる、というのが最大のポイントです。

先に知るべきこと
DiffusionGemmaは通常のautoregressive LLMではなく、diffusion-gemma architectureのGGUFです。なので、普通のllama-cli、llama-server、LM Studio、Ollama、Unsloth Studioの通常推論経路では、モデルファイル自体が正しくても実行できないことがあります。

典型的なエラーはこれです。

unknown model architecture: 'diffusion-gemma'
llama.cpp does not support this GGUF's model architecture ('diffusion-gemma')

この場合、モデルが壊れているのではなく、runner側が未対応です。

必要なrunner
現状はDiffusionGemma対応入りのllama.cpp PR/ブランチを使い、通常のllama-cliではなく、専用の:

llama-diffusion-cli

をビルドして使うのが本筋です。

CUDAビルドの罠
GPUで使うならCUDAビルドが必要です。ただし古いCUDA Toolkitだと、最近のMSVCでビルドに失敗します。

典型例:

error STL1002: Unexpected compiler version, expected CUDA 12.4 or newer.

これはCUDAが古いという意味です。CUDA 12.4以上を使うのが安全です。

低VRAMでの現実
8GB VRAM級ではモデル全体は載りません。全部GPUに載せようとするより、部分オフロードが現実的です。

実用ラインはだいたい:

-ngl 8
--diffusion-kv-cache on
--diffusion-eb on

-ngl autoや-ngl allは一見便利ですが、低VRAM環境ではVRAM/RAMを攻めすぎて不安定になりがちです。手動で-nglを固定した方が安全です。

KV cacheはON
--diffusion-kv-cache onはかなり効きます。
OFFだと毎stepの負荷が重くなりやすいです。まずONで試すべきです。

KV cache量子化は万能ではない
通常LLM感覚で、

-ctk q8_0
-ctv q8_0
-ctk q4_0

などを入れたくなりますが、DiffusionGemmaでは必ず速くなるとは限りません。特にV cache量子化はFlash Attention絡みで失敗・低速化する可能性があります。まずはデフォルトKV型でよいです。

-nの意味が普通と違う
DiffusionGemmaでは-nは普通の「最大生成token数」として体感しにくいです。
内部では固定長canvasをブロック単位でdenoiseします。

今回のモデルでは:

canvas_length = 256
-n 1     -> 1ブロック
-n 512   -> 2ブロック
-n 1024  -> 4ブロック

短い回答なら-n 1で十分。
献立や計画のような長めの回答は-n 512が必要です。

step数と品質
--diffusion-eb-max-stepsが実用上かなり重要です。

16 steps: 速いが崩れやすい
32 steps: 遅いがだいぶ読める

--diffusion-stepsだけ下げても、EB modeでは--diffusion-eb-max-steps側が効いている場合があります。両方揃えるのが分かりやすいです。

--diffusion-eb-max-steps 32
--diffusion-steps 32

visual modeが面白い
DiffusionGemmaを試す価値は、普通のtoken streamingではなく、canvasがstepごとに更新されるところです。

--diffusion-visual
--diffusion-visual-progress
--diffusion-visual-interval 1

を付けると、途中で文が崩れたり整ったりする過程が見えます。

日本語プロンプトの罠
Windowsでは日本語を-pで直接渡すと文字化けすることがあります。
UTF-8のプロンプトファイルを作って:

-f prompt.txt

で渡すのが安全です。

thinking/channel問題
モデルやテンプレート次第で、出力にこういうものが混ざります。

<|channel>thought
...
<channel|>

これはチャットテンプレート/モデル形式/runner未成熟の問題です。
可能ならテンプレートにenable_thinking=falseを渡す、または表示側で<channel|>以降だけ抜くと扱いやすくなります。

ただし、観察目的なら全部見えていた方が面白いです。

反復検出の罠
runner側が反復を見つけて出力を切ることがあります。

しししし
多多多多
********

みたいな崩れを止める目的ですが、DiffusionGemmaではこれが暴発して、-n 512で2ブロック生成するはずが1ブロックで止まることがあります。

理想は:

EOG tokenなら終了
反復は表示上trimしてもよい
でも反復だけで次ブロック生成を止めない

です。

おすすめ初期設定
まず試すならこれです。

llama-diffusion-cli `
  -m model.gguf `
  -f prompt.txt `
  -dev CUDA0 `
  -ngl 8 `
  -n 512 `
  --fit off `
  --diffusion-eb on `
  --diffusion-kv-cache on `
  --diffusion-eb-max-steps 32 `
  --diffusion-steps 32 `
  --diffusion-visual `
  --diffusion-visual-progress `
  --diffusion-visual-interval 1

短文なら:

-n 1
--diffusion-eb-max-steps 16

長めなら:

-n 512
--diffusion-eb-max-steps 32

最終評価
低VRAM環境では、DiffusionGemmaはまだ普通のLLMより実用的とは言いにくいです。
ただし、5 canvas-token/s相当くらいは出ることがあり、visual mode込みの「面白枠」「研究枠」「将来比較用」としてはかなり価値があります。

一発でやるなら、最初からこう考えるのが近道です。

普通のGGUF runnerではなく専用diffusion runnerが必要
CUDA 12.4以上でビルド
-nglは手動固定
KV cacheはON
-nはcanvasブロック数
品質はEB stepsで調整
日本語はUTF-8ファイル
visual modeで観察
反復停止は信用しすぎない

会話