Codexはフロントエンドがめちゃくちゃ苦手なんだけど、どうもサイズの概念がないっぽいんだよな
ちょっと計算してみるだけでもおかしいことはわかるはずなんだけどな
直近26週間のアクティビティ
投稿するにはログインしてください。
ログイン-
-
-
-
-
-
-
-
要点だけまとめると、DiffusionGemma GGUFは普通のGGUFモデルとして扱うと詰まる、というのが最大のポイントです。
先に知るべきこと
DiffusionGemmaは通常のautoregressive LLMではなく、diffusion-gemmaarchitectureの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.cppPR/ブランチを使い、通常の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 32visual 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で観察 反復停止は信用しすぎない -
-
-
-
-
-
-
-
-
-
ねねちが云々というより一般論としてなんだけど、Vtuberが株式投資をしているという構造がキモく感じる なんでなんだろう？ トレード配信をしているVtuberとかふぇありすとかには別に感じないんだけど
https://x.com/_nenechidayo/status/2061079865894572352
https://x.com/_nenechidayo/status/2061081399151747392 -
-
