公開もしていない記事がいくつもあったりしますが、久しぶりにまともに書けそうです。
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日月曜日
2026年6月7日日曜日
キメラ合成
テストで実行しつつ様子見していますが、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時間は超えてない気がします。ほぼデータを入れて外しっぱなしで放置していただけなので…。前回、全く問題なさそうだったのでそのまま使えると思ってたのですが、全くだめだったみたいですねｗ
まぁデータ移動時には全く問題がなかったので安心していたのですが、そろそろ移動しておかないと物理的に破損するかも…容量は不明ですが５，６台は転がってるので早くなんとかしないとだめな状況かな。
2026年6月4日木曜日
2026年6月2日火曜日
なんとなくソースが怪しいので
CUDAの方のソースも見てみました。
現時点のソースを見ると、カーネル内のプログラムはブロックのX、Yの動きができていますが、SYCLの方ではxのみ。無論、呼び出し元の形も一次元のみのブロック展開対応となっています（しかも実装が中途半端感が非常に強い）
なんとなくですが、単純に猿真似するだけでFlux.2のvaeがちゃんと動いてくれそうな気がしてきました…
寝る前にちょっと試してみようかな…
2026年6月1日月曜日
Flux.2 klein で vae 変換時に ggml 内でエラー
今までもろもろの条件により、vaeもcpuで実行していたのですが、--diffusion-fa指定しなきゃ出力できないなら、vaeもgpuでいいんじゃね？的なことを感じたのでちょっと試したところ、256x256では出力できました。
毎度いつもの…ｗ
Flux.2 kleinが出力できた記念として…いつもの行きますｗ
プロンプト「fish」
プロンプト「fish at deep sea.」
Flux.2のtext encodeがqwen 3の8Bとかだったので日本語でもやってみました。（3.6ベースだったら安心して日本語でもいけそうですが、3だとちょっと怪しくなりそうです）
プロンプト「魚」
日本語の理解力にかかってきますが、慣れ親しんだ言葉で通じるのは楽ですね。ただ、きちんとした指示を出すことを考えると、英語の方が端的に表現できるので、ケースバイケースかな？あ、でも、gemmaとかにプロンプトを考えてもらえなくてもプロンプトがザックリ作れるから楽にはなるのかな？
登録:
投稿 (Atom)