# Post by author (@BD1pt0ZCnY)

- Published: 2026\-06\-11T07:44:26\.249Z
- Canonical: [https://diary.soushou.net/posts/J7kXdMvBFl](https://diary.soushou.net/posts/J7kXdMvBFl)

## Content

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

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

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

```text
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`ではなく、専用の:

```text
llama-diffusion-cli
```

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

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

典型例:

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

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

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

実用ラインはだいたい:

```text
-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感覚で、

```text
-ctk q8_0
-ctv q8_0
-ctk q4_0
```

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

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

今回のモデルでは:

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

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

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

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

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

```text
--diffusion-eb-max-steps 32
--diffusion-steps 32
```

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

```text
--diffusion-visual
--diffusion-visual-progress
--diffusion-visual-interval 1
```

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

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

```text
-f prompt.txt
```

で渡すのが安全です。

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

```text
<|channel>thought
...
<channel|>
```

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

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

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

```text
しししし
多多多多
********
```

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

理想は:

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

です。

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

```powershell
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
```

短文なら:

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

長めなら:

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

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

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

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