LLMに雑談をさせようとすると、あんまりうまくいかない。もっと積極的に、そしてこちらの予想もつかないことを話させるためにはどうするべきか？ 適当にネットサーフィンとか青空文庫でも読ませて、コンテキストを「汚染」するべき？ たぶんその方向性はあっていて、本テキストをこちらの会話内容以外のものから入れて、もっと多様な、記憶というか文脈を、変なもの、特殊なものにさせないといけない。 その一つとして俺が思っているのは、乱数で例えば「あ」とか「タ」とかを生成して、その5文字を頭文字にした単語をいくつか作る。さらに、その5文字のうちどれかを使って文章を作る。そういうことをやった後で、それらについて雑談する、みたいな工程を一回挟む。 つまり、決定論的な過程によってランダムを無理やり作る。それによって雑談の独自性や独創性を上げる必要があるのかなと思う。 これって人間でもやっていて、ランダムなワードメーカーみたいなもので適当に複数の単語を出力して、それらを組み合わせて新しいものを発見する、というのはよくある手法なんだけど、その応用みたいなことができるんじゃないかなとはちょっと思ってる。 あと、人間において雑談が面白く感じるのって、その人が自分とは違う体験をしているからだと思う。ってことは、AIというかLLMエージェントにおいても、自分とは全然違う体験をさせる必要がある。 それをどうやるかとなると、やっぱりこの現実世界に放流することなんじゃないかと思う。現実世界こそが一番ランダム性を生み出しやすい場所なので、そこに何らかの形で参画させて、そこでコンテキストを「汚染」する必要があるんじゃないかなと思うん。 それこそSNSとかに放流して体験を蓄えさせたり。そうしないと、なんかつまらないエージェントにしかならない気がする。

codex, めっちゃ細切れにタスク完了を報告してきてストレスだなぁ、って思ったけど、それなら/goalを使うのが本筋なんだな。　というか、これあれかな、/goal向けの調整をしている感じなんだろうな　マジで/goalが前提だ

# 「おにぎりに巻かれた黒いやつ」で、gemma-4-12Bの量子化ビルドを炙ってみた ローカルLLMを触っていると「量子化すると頭が悪くなる」という話を山ほど聞く。でもその「悪くなる」を、英語のベンチじゃなく、日本人なら一瞬で判定できる形で見たことはあるだろうか。 自作のベンチツールでgemma-4-12Bを量子化・ビルド違いで回していて、面白い壊れ方を見つけた。お題はこれ。 > おにぎりに巻かれている黒いやつってなんだっけ？小学生にもわかる感じで教えて。 このお題のキモは「簡単なこと」ではない。**海苔を普通こんなふうには呼ばない**ところにある。「海苔って何？」と直接聞いていない。「おにぎりに巻かれた黒いやつ」という、一段ひねった言い方から、海苔という概念を手繰り寄せられるか——連想力を見ている。同時に、日本のことを学習していれば当然データセットに入っているであろう、ど真ん中の常識でもある。 結論から言うと、**どのモデルも「のり」には正解した。連想は全モデル通った。** 差がついたのは、その先の日本語の出力品質である。そしてそこに、ビルド元による明確なグラデーションが出た。 ## 壊れ方には3段階あった 同じgemma-4-12Bでも、Unsloth量子化のビルドだけが、深さの違う3種類の破綻を見せた。プロンプトは全モデル共通（system: 自然な日本語で変なスペースを入れずに答える / user: 上記のお題）。 **① 多言語が漏れる — Unsloth QAT-UD-Q4_K_XL** > 海weed（うみのも）という海の植物を、細く切って乾（かわ）かしたものです。 「海weed」。英単語の weed が日本語の出力に直接漏れ出し、しかも「うみのも」という存在しない読みが振られている。 **② ふりがなが壊れる — Unsloth Q3_K_S** > 海藻（かいも）の一種で、お寿司やて焼き物などにも使われることが多いです。 漢字「海藻」は正しいが、読みが「かいも」（正しくは「かいそう」）。さらに「て焼き物」という謎単語も出た。（海苔ではないらしいが海藻を焼き物に使うことはあるようだ。「藻掛け」） **③ 文法がねじれる — Unsloth IQ4_XS** > お米に巻くと、磯のいい香りがして、おにぎりをおいしく食べてくれるための大切な材料です。 漢字も読みも正常。だが「おにぎりをおいしく食べてくれるための材料」は、主語と動作がねじれた不自然な日本語になっている。 一方、Google公式（lmstudio-community配布）の2ビルドは、この種の破綻を一切起こさなかった。 **lmstudio QAT-Q4_0** > 海（うみ）の近くにいる「海藻（かいそう）」という植物を乾燥させて作ったものです。 **lmstudio Q4_K_M** > 海の中の海藻（かいそう）という植物からとられたもので、おにぎりを包むと、お米が手にくっつきにくくなるし、おにぎりの形も崩れにくくなるので便利なんだよ。 読みも文法も自然。同じ12Bのベースモデルだが、日本語の出力品質の保たれ方が違う。 ## 数字で見たトレードオフ 面白いのは、この「壊れたビルド」たちが、速度では勝っていたこと。手元の実測（max 1024 / 同一プロンプト・条件で揃えた）はこうなった。 | 配布元 / ビルド | 量子化 | 速度 (t/s) | VRAM | 品質 (目視で手vote) | 日本語の破綻 | |---|---|---|---|---|---| | lmstudio-community gemma-4-12B-it | Q4_K_M | 12.35 | +7759 MiB | 100% (4/4) | なし | | lmstudio-community gemma-4-12B-it-QAT | QAT-Q4_0 | 22.13 | +7754 MiB | 100% (4/4) | なし | | unsloth gemma-4-12b-it | Q3_K_S | 26.28 | +6431 MiB | 75% (3/4) | 読み（かいも） | | unsloth gemma-4-12B-it-qat | QAT-UD-Q4_K_XL | 26.83 | +7751 MiB | 75% (3/4) | 語彙（海weed） | | unsloth gemma-4-12b-it | IQ4_XS | 26.93 | +7624 MiB | 75% (3/4) | 文法ねじれ | > 計測条件: llama.cpp b9518 / CUDA / n-gpu-layers 99 / flash-attn on / KV cache q8_0 (k/v両方) / fit-ctx 65536 / 単一モデル・parallel 1。OpenAI互換API（/v1/chat/completions）経由、リクエストの max_tokens=1024（サーバ上限 n-predict=4096 のため実効上限は1024）。VRAM実測はこのKV量子化前提の値。 きれいに傾向が出ている。**速いビルドほど品質voteを落とし、品質満点のビルドほど遅い。** 公式Q4_K_Mは品質100%だが12 t/sしか出ず体感はかなり重い。逆にUnslothは26〜27 t/sと快適だが、おにぎりベンチで日本語の破綻を見せて1票減点された。 「日本語で快適に使う」と「日本語が壊れない」のちょうどよさはlmstudio-community gemma-4-12B-it-QAT が近そうだが、しかし26tpsと22tpsの差は案外大きい。 ## なぜ気づけたか（測り方の話） このベンチツールでは指標を2軸に分けている。ひとつは**機械スコア**で、tokens/sとVRAMから機械的に出す「快適さ」の指標。もうひとつは**品質スコア**で、出力を見て自分でup/downを押した票の比率。 機械スコアだけ見ていたらUnslothが「速くて良い」で終わっていた。「海weed」に気づいたのは、出力そのものを目で見て品質voteを押す側の工程があったからだ。速いから良い、では拾えない差が、ここにある。 ## 次にやること - 同じおにぎりベンチをQwen系・llm-jp系でも回し、量子化耐性に差が出るか見る（gemma 4 E2Bあたりは、この問いに対して同規模のQwenにはない独特の逃げ方をした記憶があるので、それも別途） - 「海weed」型の破綻を一問一答でなく、もう少し体系的な日本語タスクセットに育てる - 機械スコアと品質スコアの相関（速いほど壊れるのか）をモデルをまたいで検証 ツールは自作で、ローカルのllama.cpp / LM Studioを相手にbenchmarkをqueue実行し、速度・VRAM・品質を記録できるようにしている。

Codexはフロントエンドがめちゃくちゃ苦手なんだけど、どうもサイズの概念がないっぽいんだよな ちょっと計算してみるだけでもおかしいことはわかるはずなんだけどな

要点だけまとめると、**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で観察 反復停止は信用しすぎない ```