2026年6月13日土曜日

途中経過

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

原因不明のエラーの調査は進めていないので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が楽しすぎて全然触れていませんが(笑) 

 

2026年6月9日火曜日

SYCL ワークサブグループが熱い!?

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

2026年6月8日月曜日

Flux.2 Klein vae syclの実行

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

2026年6月7日日曜日

キメラ合成

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

あとQwenImageは基本的に1024x1024ぐらいでないとまともに出力してくれない感じが強かったり…
Fluxはその辺結構いい感じに出力される気はしますが、QwenImageとFluxの大きな違いとしては、Fluxの方が確実にキメラ合成が多いですw
QwenImageだと精々指が多かったりたまに手がダブってたりするぐらいですが、Fluxは結構簡単に足が増えたり減ったり、とぐろ巻いてたり胴体が人体錬成状態になったりとします。もしかするとなんとかフィルターに引っかかった結果、こういう処理になっているのかもしれませんがw

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

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

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

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

実行時間

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

先ず状況(の進展はありませんw)ですが、こんな感じです。
Flux.2 kleinの1024x1024までの実行が行えました。
ただし、vaeの実行はCPUで行う必要があります。そういえばテキストエンコードはsyclで試してもいませんがメモリー的にだめかな?

512x512はvaeもsyclで動かせました。
1024x1024でvae(safetensors)をsyclで実行しようとするとまずim2colでエラーが発生し、次にconvert.cpp内のf32関連でエラーが発生します。
基本的にsyclドライバ自体の制限だったり、32bitによるアクセス制限だったりする感じです。そしてトドメにメモリー不足で現状の構成では結果的に動かせない可能性が高いです(笑)

メモリ不足解消で一番簡単なのは、もっと量子化されたモデルファイルを使う方法で、次にstable_diffusion.cppのキャッシュバッファをもっとサイズの小さいものを使用するという方法。
精度を犠牲にすることにはなりますが、すでにklein自体は結構量子化されているので一番小さい量子化モデルファイルでもさほど変わらない気はしていますw
テキストエンコードもなぁ…日本語が多分通じなくなりそうだけど、一番小さいのを使う必要があるかもなぁ…
vaeは量子化されたものを使うと出力が真っ白になることが多かったりしますが、今回の経験を活かしてなんとかできるかもしれない…

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