型キャスト

結構甘く見ていた型キャスト…やらかしました。

Window の〇ソメモ帳

Windows11でタブ付きになったメモ帳。

タブが付いてどんな人が喜んでるんでしょうかね？

以前に書いた内容で

すこし過去の記事を見てみると１ヵ月ぐらい前の記事で、テスト的に出力したものがあったので同じものを出力して違いを確認してみました。

ようやくSYCLだけで動かせるようになったので…（512だけですがｗ）

vaeのメモリーバカ食い問題が解消されないと1024での動作が厳しいので、当面512x512で動かしてみようかと思います。

いままで手を加えた部分を最新のソースとマージしてllama.cppやstable-diffusion.cppを動かしてみたところ若干遅くなっている部分や、最新のggml-syclの対応で実装自体が遅くなっている部分も多く、今後どうするべぇかちょっと思案しています。一番有効そうなのは、まず処理を安定させるために強制的に同期をとっているのですが、そこを何とかしたいというのが一番の課題と考えています。有効そうな手段はqueueクラスをラップして、色々といければなぁとか、漠然と考えています。

で、遅くなったか早くなったかは正直判断つかないのですが、Flux2Klein4Bモデルの量子化Q8モデルを使用し、テキストエンコードとvaeも全てsyclで動作させた結果、

[INFO ] stable-diffusion.cpp:1322 - running in Flux2 FLOW mode
[INFO ] stable-diffusion.cpp:4494 - generate_image 512x512
[INFO ] denoiser.hpp:579  - get_sigmas with discrete scheduler
[INFO ] stable-diffusion.cpp:3518 - sampling using Euler method
  |##################################################| 298/298 - 332.26MB/s
[INFO ] model_loader.cpp:1232 - loading tensors completed, taking 5.54s (read: 3.78s, memcpy: 0.00s, convert: 0.10s, copy_to_backend: 1.23s)
[INFO ] stable-diffusion.cpp:4233 - get_learned_condition completed, taking 18.65s
[INFO ] stable-diffusion.cpp:4540 - generating image: 1/1 - seed 20260625
  |##################################################| 149/149 - 520.35MB/s
[INFO ] model_loader.cpp:1232 - loading tensors completed, taking 7.88s (read: 5.90s, memcpy: 0.00s, convert: 0.00s, copy_to_backend: 1.65s)
  |==================================================| 4/4 - 66.65s/it
[INFO ] stable-diffusion.cpp:4572 - sampling completed, taking 274.89s
[INFO ] stable-diffusion.cpp:4586 - generating 1 latent images completed, taking 274.89s
[INFO ] stable-diffusion.cpp:4257 - decoding 1 latents
  |##################################################| 140/140 - 314.95MB/s
[INFO ] model_loader.cpp:1232 - loading tensors completed, taking 0.60s (read: 0.40s, memcpy: 0.00s, convert: 0.04s, copy_to_backend: 0.07s)
[INFO ] stable-diffusion.cpp:4277 - latent 1 decoded, taking 27.87s
[INFO ] stable-diffusion.cpp:4281 - decode_first_stage completed, taking 27.87s
[INFO ] stable-diffusion.cpp:4721 - generate_image completed in 321.42s 

生成のオプションとしては -H 512 -W 512 --steps 4 --cfg-scale 1.0 --diffusion-faと言った感じです。

プロンプトを日本語で徐々に長くしていますが、やはり長くなると若干遅くはなるようなので参考値ですがこんな感じですね。5分20秒ぐらいというのはやはりFluxの4Step出力は驚異的ですね。 QwenImageは512x512サイズでも低スペックな環境では1時間以上かかってしまうので(笑)

まぁ今後はもっとテコ入れして局所的にでも手を入れていってみようと思っていますが、ようやくここ1か月ぐらいですか？何もわからないところから結構触れるようになったと思います。 

ぎりぎり動いていたモデルが動かせなく…ｗ

syclで安定して動いてくれるように気づけば結構書き換え続けていますが、そろそろ大元のggmlとマージしなければ…とおもいつつ書き換えたソースをちゃんと保存したうえでgithub上で整理してみました。イマイチ使い方が分からないのと、クライアント上のgitの使い方も良く分からない感じでやっているので漏れているものもありそうですが、ggml_sycl_patchからpullしてmakeが通ったのですが、気づかないうちにベースとなるstable-diffusion.cppもpullしてしまった感じでmakeの動作が変わったようなので、stable-diffusion.cppもpullして整えてからggmlをggml_sycl_patchへ挿げ替えてmakeを通してみました。

心臓に悪いWindowsUpdate

今回のWindowsUpdateはIntelDisplayドライバーの更新がかかった様で、突然画面が真っ暗になって再構築されて再表示されたような動きをしたので精神的に非常に負荷が高かったです…もうね…ほんと…やめてほしいｗ

ループの形が落ち着いてきたのでここらへんで…

何度も書き直しつつ、再びcpy.cppに展開していたのですが、同じコードをコピペして、必要な修正を少しして、動きを見て…と繰り返すのも飽きてきたので何とかできないかと模索していました。

ループ処理

公開もしていない記事がいくつもあったりしますが、久しぶりにまともに書けそうです。

笑いが止まらないｗ

mulでも…と思って手を加えようと思いながらも…どこからどうやって動いているのかさっぱりわがんねｗ／(^o^)＼

Flux.2 Klein の実行命令

cpy_f32_f32の部分を手を入れて、結構足掻いてみた物の、最終的には現状のロジックのまま、SYCLに対する純粋な最適化を行った形で落ち着きました。

途中経過

七転八倒しながら結構いい感触を得られています。

原因不明のエラーの調査は進めていないので512x512レベル止まりですが、cpyロジックも手を加えた結果、

vae   24.13s 全体では 322.93s（テキストエンコードはCPU）となりました。

手元のテキストの過去の記録を見てみると…vaeのベストと比べると誤差レベルで遅くなっていますが、全体では20s程度短くなっています。

GGML的にはdup（複製）の中のcpyロジックのf16->f32とf32->f16部分のみ。モデルファイルがQ4_K_M、Q8_0、safetensorsファイルを使っているのでこの辺の変換にも手を加えるともっと実行速度が短くなりそうです。

あと、実際のログを見て効果の高そうな処理から手を加えた方が効果的かなとも。

cpyのロジックを見る限り、正当に処理を実装しているのでとても無駄が多い実装になっています。どうしても計算量を減らそうとするとそのままではあまり効果が出ないので、実データをを踏まえて実装しなおしています。そのため、結構限定的な実装になってはいます。

当面の目標としては512x512で1分ぐらいで出来上がると嬉しいかなぁ…とか思いながら遊んでいますが、vaeベースを考えると 24秒×5=120秒程度ぐらいには行けるのかな？とは感じていますが…メモリ的にテキストエンコードがCPUのままにしているのでこれよりは遅くなりそうかな？

 

そういえばLocalAIのバージョンアップも行われていますね…SYCLが楽しすぎて全然触れていませんが(笑) 

 

SYCL ワークサブグループが熱い！？

さっきまでワークサブグループってなんかの単位何だろうな…とあまり意識していませんでした。この感動をどう伝えたらいいのだろうか…。今風の書き方ならまず結果を書くべきなのかな？

Flux.2 Klein vae syclの実行

寝る前に実装して実行したところ、実行時間が逆に遅くなったので、その原因を見つけるために見直していました。

キメラ合成

テストで実行しつつ様子見していますが、QwenImageは普通に出力させるにしても20step必要なので1024x1024の画像だと結構かかるのですが、Flux.2Kleinだと4stepで1024x1024でも70分ぐらいで出てくるので512x512で出力されたもので、もうちょっと見てみたいものがあると試すような感じで実行しています。

まぁ512x512でも10分ぐらいなのであれなんですがｗ

とは言え、QwenImageだとたしか512x512でも20以上かかるので結構手軽さが違います。

あとQwenImageは基本的に1024x1024ぐらいでないとまともに出力してくれない感じが強かったり…

Fluxはその辺結構いい感じに出力される気はしますが、QwenImageとFluxの大きな違いとしては、Fluxの方が確実にキメラ合成が多いですｗ

QwenImageだと精々指が多かったりたまに手がダブってたりするぐらいですが、Fluxは結構簡単に足が増えたり減ったり、とぐろ巻いてたり胴体が人体錬成状態になったりとします。もしかするとなんとかフィルターに引っかかった結果、こういう処理になっているのかもしれませんがｗ

ただ例のフィルターの反応がTextToTextでは結構はっきりと拒否されるのでわかりやすいのですが、TextToImageだと正直よくわかりません。

あと面白いのが骸骨の腰に布が挟まっているように出力されたこともありました…正直すごい謎な出力でした。

画像出力でネタができたら記事にしたいのですが、現状日本語プロンプト少し変化させてテスト的に実行している程度なので面白ネタにまでは到達できていません…

でも出力サイズと実行時間的には悪くないレベルにはなってる気がします。クラウドの生成AIの様な速さは無いですが、仕事でなければ画像生成にそこまで速さは関係無いですからね。

実行時間

状況は全く変わっていませんが、中身の書き換えは徐々に進みつつあるのと、凡人ながらもう少し実行時間を短くできるかもしれないという手法があるのでそれを試してみたくて疼いていますｗ

先ず状況（の進展はありませんｗ）ですが、こんな感じです。

Flux.2 kleinの1024x1024までの実行が行えました。

ただし、vaeの実行はCPUで行う必要があります。そういえばテキストエンコードはsyclで試してもいませんがメモリー的にだめかな？

512x512はvaeもsyclで動かせました。

1024x1024でvae(safetensors)をsyclで実行しようとするとまずim2colでエラーが発生し、次にconvert.cpp内のf32関連でエラーが発生します。

基本的にsyclドライバ自体の制限だったり、32bitによるアクセス制限だったりする感じです。そしてトドメにメモリー不足で現状の構成では結果的に動かせない可能性が高いです(笑)

メモリ不足解消で一番簡単なのは、もっと量子化されたモデルファイルを使う方法で、次にstable_diffusion.cppのキャッシュバッファをもっとサイズの小さいものを使用するという方法。

精度を犠牲にすることにはなりますが、すでにklein自体は結構量子化されているので一番小さい量子化モデルファイルでもさほど変わらない気はしていますｗ

テキストエンコードもなぁ…日本語が多分通じなくなりそうだけど、一番小さいのを使う必要があるかもなぁ…

vaeは量子化されたものを使うと出力が真っ白になることが多かったりしますが、今回の経験を活かしてなんとかできるかもしれない…

結構どっぷりハマりながらチマチマ書き換えてテスト実行してますが、少しずつ実行時間が減っていくのは楽しいですｗ

外付けHDD

先日、バックアップ用の外付けHDDのデータを移して、この空いたHDDをSWAP用のドライブとして動かしていたのですが、再び昨日接続したところモノすっごい聞いたことのないような異音が…

このドライブはもう何年前のドライブなのだろう。1TBのドライブが出る前のもので、もしかすると２０年ぐらい経っているのか？全然そういう感覚ないけどｗ

データの中身はたいしたものは入っていませんが、稼働時間は精々300時間は超えてない気がします。ほぼデータを入れて外しっぱなしで放置していただけなので…。前回、全く問題なさそうだったのでそのまま使えると思ってたのですが、全くだめだったみたいですねｗ

まぁデータ移動時には全く問題がなかったので安心していたのですが、そろそろ移動しておかないと物理的に破損するかも…容量は不明ですが５，６台は転がってるので早くなんとかしないとだめな状況かな。

まさに七転八倒…でも…

まさに五里霧中な状態で手探りで触っています(笑)

ふむ…

先日から牛歩です(笑)

結構根本的に色々と蹴躓いているので、例のフラグ(-fno-sycl-id-queries-fit-in-int)をどこにセットすればコンパイルに反映してもらえるか少し試してみました。

例外処理の途中経過

何もない知識の中から経験値だけで突き進んでいるわけですが…

なんとなくソースが怪しいので

CUDAの方のソースも見てみました。

現時点のソースを見ると、カーネル内のプログラムはブロックのX、Yの動きができていますが、SYCLの方ではxのみ。無論、呼び出し元の形も一次元のみのブロック展開対応となっています（しかも実装が中途半端感が非常に強い）

なんとなくですが、単純に猿真似するだけでFlux.2のvaeがちゃんと動いてくれそうな気がしてきました…

寝る前にちょっと試してみようかな…

Flux.2 klein で vae 変換時に ggml 内でエラー

今までもろもろの条件により、vaeもcpuで実行していたのですが、--diffusion-fa指定しなきゃ出力できないなら、vaeもgpuでいいんじゃね？的なことを感じたのでちょっと試したところ、256x256では出力できました。

昔の生成画像で人物の指の数がおかしくなる原因

常識なのかもしれませんが、あらためて実感したことです。

毎度いつもの…ｗ

Flux.2 kleinが出力できた記念として…いつもの行きますｗ

プロンプト「fish」

背景が真っ白になってしまうのはこれが魚に見えるだろうという自信の表れなのか、背景が無指定の場合のデフォルトが白色で設定されているからなのかは謎ですが、Qwen Image 2512もこんな感じだったので流行なのでしょうか？ただ、明らかに本当に存在してそうな雰囲気です。でも寂しいのでもう一枚。

プロンプト「fish at deep sea.」
 

結構かっこいい感じの絵が出てきました。英語は苦手なので定冠詞が無いだとかinだとか言わないでもらえると助かります(笑)。

Flux.2のtext encodeがqwen 3の8Bとかだったので日本語でもやってみました。（3.6ベースだったら安心して日本語でもいけそうですが、3だとちょっと怪しくなりそうです）

プロンプト「魚」

プロンプト「深海にいる魚」

ほぼ同一の画像が生成されました。相違点はプロンプトの処理で乱数がずれたのでしょう。

日本語の理解力にかかってきますが、慣れ親しんだ言葉で通じるのは楽ですね。ただ、きちんとした指示を出すことを考えると、英語の方が端的に表現できるので、ケースバイケースかな？あ、でも、gemmaとかにプロンプトを考えてもらえなくてもプロンプトがザックリ作れるから楽にはなるのかな？