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

遺伝的多様性プログラミング 仕様書だけ与えて、うまく動作してそうな完成品を10種類作る。この時、LLMモデルは2,3種類使う。 A/Bテストのような感じで10種類を使い、最も良かったものを選別し、その度合いに応じて使用頻度を調節する。ただし、致命的な欠陥や、セキュリティの穴があった場合のパージに備えて全部残しておく。 つまり何を言いたいかと言うとDNAとLLMとで、もっとアナロジーを検討するべきじゃないか

1. YoutubeのAPI経由だと「生配信のアーカイブ」と「プレミア公開の動画」が区別できない 「普通の動画」と「Shorts」が区別できない → 再生時間で仕分ける必要がある(1分以下の普通の動画はShorts, 10分以下の生配信はプレミア公開の動画 のような感じ) 2. チャンネルurlから歌ってみた動画を抽出するより、歌ってみた動画をまとめてある再生リストから抽出する方が筋が良い ただし、りかしぃの歌ってみた動画リストにはペトラとのアイデンティティが入っていないことに注意すること 場合によっては自作するのが良い

RT @kenn: （redditのclaude板にて） Codex 5.2ってClaude Codeより強くない？ （claudeのモデレーターボット） TL;DR（200件のコメントを読んだ上での自動要約） 結論は圧倒的に「Yes」。ただし、単純な話ではない。このス…

後でもうちょい整理するかmo ### 漫画家やVtuberなどの "見られる側" は「内輪じゃないんだぞ、誰でも見れるSNSでそんなこと言うのが悪い」と叩かれ"見る側"によって燃やされる。 一方で、読者や視聴者などの "見る側" が、"見られる側" の投稿を引用するなどして炎上させたときは「晒し上げ」「ファンネル飛ばし」「犬笛」と非難される。 こういう風にSNS上では非対称な扱いがされるわけだけど、この構造ってだいぶ興味深い気がする。 "見る側" が "見られる側" を品評するのは当然の権利として想定されているのに、その逆は想定されていないんだよな。 以前、Steamのレビューのスクショを投稿してその内容を制作者が批判した時も「レビューを晒すな」とバッシングを受けていたけれど、あれも似たような構造だった。 "見られる側" は活動者とかインフルエンサーとか、いわゆる「発信者」と言ってもいいんだけど、どうもこの立場は流動的ではないらしい。 あたかも演劇の舞台のように、一度「客席」に座った人間は、どれだけ野次を飛ばして注目を集めても「演者」とは見なされない。あくまでも "見る側" の安全圏に置かれたままで、不可侵。本来SNS上においては "見られる側" と "見る側" にはグラデーションがあるはずで、舞台に上がってるかどうかなんて区別しようがないはず。でもどこか空気でその身分（クラス）が固定されている。 ちなみに俺の意見としては、その空気感は間違いで、Twitterはコロッセオでありバトルアリーナで、皆が平等にグラディエーターなんだと思っている。 Twitter上に投稿するということは、リングの上に立つということ。そこに対する反撃や文句は所与の前提でありナンセンス。たとえ相手が格上のインフルエンサーでも、リングの上に上がったなら誰だって殴られる可能性があるし、逆に一般人だからといって客席から安全に石を投げられると思うなよ、という話。 ただし、「外界での振る舞い」をスクショなどで持ち込んで、Twitter上で燃やすことに対しては文句を言ってもいいと思う。 Steamのレビュー欄や日常生活は、Twitterという「戦場」の外の話だ。 リングの上にいる相手を殴るのはルール内だが、外で見かけたからって殴ってはいけないのと同じ理屈だ。別の場所（文脈）で過ごしている人間を、無理やりリングに引きずり上げて殴るのはただの野蛮な行為だろう。Twitterが治外法権のバトルアリーナだとしても、そのルールを外の世界にまで適用してはいけない。 つまり何が言いたいのかというと、Twitterはゴミなので、俺みたいに自分でサイトを作ってブログもどきで石を投げるべきってこと。