とてつもなく不毛なことを実行している気分ですｗ量子化 Q3とかQ2とか使っているのにとても時間がかかっております(笑)
昨日は真っ白画像と格闘しつつ、安定して出力できていますが、量子化の劣化によるものか、QwenImageの特性なのか、思った以上にプロンプトの指示が通りません。中国語じゃないとダメなのかな？
2026年5月21日木曜日
2026年5月20日水曜日
Windowsでllama.cppのmakeで蹴躓いているわけですが…
Visual Studio 2022は既にインストール済みなので、Windowsネイティブでllama.cppを動かすのは簡単だと思っていたのですが…結構大変そうですｗ
llama.cppのdocs/build.mdを読んでいていまさらながらに気づいたことが…
Intel oneMKL
Building through oneAPI compilers will make avx_vnni instruction set available for intel processors that do not support avx512 and avx512_vnni. Please note that this build config does not support Intel GPU. For Intel GPU support, please refer to llama.cpp for SYCL.
インテル oneMKL
oneAPIコンパイラを介して構築することで、avx512およびavx512_vnniをサポートしていないIntelプロセッサ向けにavx_vnniの命令セットが利用可能になります。このビルド構成はIntel GPUをサポートしていません。Intel GPU のサポートについては、SYCL 版 llama.cpp をご参照ください。
？？もしかしてavx2ではなくてavx512も動かせるっていう事？？
こ、これはぜひ試してみたいものです。これができるなら消費電力や発熱問題は出てきそうですが、チャットのレスポンスが上がるかも？
2026年5月19日火曜日
Qwen Image 2512
当初は単独のモデルファイルで動くものと思っていた画像生成。
ただチャットするだけでも分離されているmmprojとかと同様に、現状画像生成は一般的な使用方法としては各機能を分離させて扱うようで、低スペックな環境だとトレードオフによって結果がかなり変わってくるので面白いですねｗ
Qwen ImageもQ4ぐらいなら余裕で動かせるだろうと、思っていたのですが、実際はこれにllmモデルも必要で…しかも画像サイズを大きくするとメモリーを爆食いするのでそのへんも考慮するとできる限り量子化したモデルにして何とか動くかなレベルになってしまうという(笑)
当初はQ2モデルなんてほとんど動かすことは無いだろうと思ってましたが、とりあえず動かしてどんなものか見てみたいという好奇心が全てを凌駕し、手を出してしまいました。
最近だと同系列のQwen 3.6 35B A3BモデルでQ2を使用したら、結構使えたので最近のモデルならいけそうかなと言う感触を得たのですが、Qwen Imageって結構昔のモデルだったりするんですよね…。なのでどの程度なのかかなり未知数でしたが、それなりに出力させることができました。ただ、Flux.1-schnellに慣れてしまったのか画像が生成までの時間がとても厳しく…ｗ
で、それでも何枚か出力させていたのですが、途中から突然真っ白画像が出力されるように…一番に疑ったのが、ストレージの空き容量ですが、今回はそれとは違っていて、画像サイズを変えたり、パラメータを変更したり、出力できたパラメータにしたりとしたのですが、7枚も白紙の画像が作られました。低スペックなのでこれだけで軽く５，６時間かかってます(笑)step20の画像が真っ白だった時とか精神的に結構やられました。
初心に戻ってstable-diffusion.cpp/docs/qwen_image.mdを見直してみると最後に --diffusion-faとついていることに気づきました。
真っ白な画像が出力される状況は今までもvaeをGPUで動かしたときにも発生し、--faを追加すると出力できたことがあるのですが、--faを使うと時間がかかるので、あまり使いたくはないオプションとなっています。なのですが、藁にも縋る想いで --diffusion-faを追加したところようやく画像が出力されました。
--diffusion-faを付けなくても出力できていたのは偶然だったのかな…
違うんだ。そうじゃないｗ
ちょっと表現で面白いことはできないだろうか？という事でFlux.1で試してみました。
最初はschnellで。
試したことは、ふとジェイソンボーンという単語が頭に過り、骨…骸骨、スケルトン！
と言う感じになんかモンスターでも出てきたら面白いかなと…
2026年5月18日月曜日
あれ？Flux.2動かない？
色々と試行錯誤している最中ですが、巷ではすでにFlux.1の話題はすでに終了していてFlux.2に移行しているようです。
Flux.1に出てくる人物モデルのレパートリーが少ない気がするような？と、一般的なちゃんとした環境をそろえている方はおそらく物足りなくなっているのかな？とは感じます。
しかもFlux.2の生成スピードはほんの数秒で生成できるらしいような記事も見かけます。（まぁ今の環境だと単位が一つ違うのでそれでも数分で出力されたらそれはそれで驚異的なわけで…）
FP8を量子化して使って見たケドも…この検証は無意味だった件ｗ
結果から言えば全く処理速度は変わらなかったわけですが、当然と言えば当然(笑)
量子化でファイルサイズは小さくなったものの、後から分かったのですが、扱ったsafetensorsはcliplとかt5とかvaeとか全て入っているsafetensorsファイルだったものらしく、stable-diffusion.cppで実行時にエラーにはならないものの、モデルファイルのロード時に大量の「 unknown tensor」が表示されました。
2026年5月17日日曜日
Ubuntu ストレージをすべて使い切った状態に気づかず何度も出力させていた…ｗ
昔、Raspberry piとかでストレージを使い切ってしまうと結構悲惨だった記憶が残っていますｗ
まず、最終的に外部から接続できなくなり、直接コンソールを使わないと何もできなくなってしまった記憶があります。
2026年5月16日土曜日
ggml Sycl16とSycl32の差
実際にビルドしてみて使って見ると少しの差でSycl32の方が早かったわけですが、実際の演算結果の差が出るのかどうか気になったので、stable-diffusion.cppで同じモデルを使用してSYCL16とSYCL32でmakeしたものを同じプロンプトで出力させて比べてみました。
ついでにCPUと比べてもみたいわけですが、犬の看板画像で試した感じだとCPUとSYCLでは結構差が出てた記憶があります。
ようやく出そろいました。SYCL16 / SYCL32 / CPUで出力させてみました。
512x512のサイズならvaeもGPUで動く気がしたので試してみたら、出力されたものが真っ白の物でした…どこかで情報が欠落してしまっているようでｗ
なので、textencoderとvaeはすべてCPU上で動いています。
| SYCL16 | SYCL32 | CPU |
|---|---|---|
 |  |  |
CPUだけはおでこの模様が異なってたり、首紐が無かったり、輪郭が違っています。SYCL16とSYCL32の違いはfluxの「f」の文字の太さが違っているのと、背景の左側の人が若干異なっている程度です。
ほぼ、同じ結果を得られていますが、「同じ」出力にはならないのが本当に面白いですね。
乱数誤差なのか内部バッファのメモリ形式が異なっていることによる差なのか…要因はいくつか考えられます。
他にもいくつか同じ構成で違うバックエンドで出力させたものがありますがSYCL16とSYCL32はほとんど違いがないですが、やはりどこか違っている部分があります。バグなのか実装の仕様なのかかなり難しい部分ですね。
参考として出力から得られた実行時間はそれぞれ、456.72s / 440.92s / 997.77s。消費電力は1Step目はそれぞれ15W程度かかっていましたが、2～4Stepの間はSYCL16/32は10W。CPUはすべてのステップでGPU電力は0WでしたがCPUだけで15W消費していました。瞬間的に表示上16.01Wとか表示されてはいました。テキストエンコーダとvaeはCPUのみなのでこちらも15W消費している感じです。
出力が真っ白になってしまいましたが、vaeもGPUで動作させた場合はSYCL16は382.46s、SYCL32は366.12sでした。vaeの処理が滑っていただけかもしれないので、あくまでも参考値として残しておきます。
2026年5月15日金曜日
The oneAPI toolkits no longer support 32-bit libraries
make時には気づかなかったが、実行時にこんなメッセージが…
The oneAPI toolkits no longer support 32-bit libraries, starting with the 2025.0 toolkit release. See the oneAPI release notes for more details.
oneAPIツールキットは、2025.0ツールキットリリース以降、32ビットライブラリをサポートしなくなりました。詳細については、oneAPIリリースノートを参照してください。
一応グーグル翻訳から
LocalAI v4.2.4 なんか収集つかなくなってそう…
昨日の昼の時点で4.2.3がリリースされていることに気づき、夜には4.2.4のリリース。
で、手元の環境で動かしてみたのですがチャットを試していますがなんか節々がダメそうｗ
処理速度と言えば…
生成AIがどんなものか全くわからなかったので、本腰を入れて環境整備をする気にもなれず、かと言って生成AIを動かせる最低限のメモリーを積んでいるPCが無かったので、タイムリーに16GiBのメインメモリーを搭載したミニPCが安かったのでぽちっただけで…ｗ
正直CPUもAMDと悩んだんですよ。でも値段の差でN150と言う選択に(笑)
で、そもそもしょぼい環境で遊んでいるのでそれなりに解っているはずでしたが、ちょっと検索したページの記事を見ると
「FP8版の FLUX.1 [dev] を使用して、20 Stepsで生成しています。サイズは 1440x816 です。筆者の環境では生成に125～140 秒程度かかります」
とサクッと書いてあって、1024x1024で20Stepっていうとdevでもschnellでもほぼ時間は変わらず5～6分程度ですので…ざっくり120分(笑)単位が違うｗ
画素数の差は1440x816：1024x1024 ＝ 1,175,040：1,048,576 で少ないにもかかわらず、60倍の差がｗ
FP8版は使ったことがないのでわかりませんけど…そのうち試してみてもいいかな…たしかになんかちっちゃいサイズのモデルが多いなぁとは感じてはいましたが。
そもそも、チャットで遊べればいいだろうという環境なので、その環境で画像を出力させ始めたのが気の迷いだったという事を思い出させていただきましたｗ
stable-diffusion.cpp Flux1-schnell "sycl-16" vs. "sycl-32"
今までとてもデリケートなイメージのSYCLですが、ほぼほぼ安定しているので処理が軽いイメージのsycl-16で動かしてみようかと。
で、1024x1024のサイズの出力をしていて、ターミナルのフォントなどを調節しながらいろいろ試していいるうちに気づいたら結構時間がたってて、動作確認すると落ちてました…
2026年5月14日木曜日
スペック不足で現実的ではない物の…
そういえばggmlとかllama.cppって同時に起動して、どれもGPUを使用した場合はどうなるんでしょうね？
SYCLの場合はオーバーフロー問題があるので、根本的に解決しないとダメだと思いますが、メモリーがもてば、ちゃんと動いちゃうのかな？
デバイスの占有ができなくても、仕組み的には大丈夫だと思うんだけど、ことキューに関してはどうなるのだろう…メモリ管理とかSYCL側で管理できてるからいいのかな？なんか行けそうな気がしてきた…どうやって試そう…小さいモデルを同時に動かせばいいかな？なかなか気が滅入りそうｗ
ほんと、いままでSYCLがハングしてしまうので積極的に使用しない様に扱ってたのですが、安定したなら積極的に使っていこうと思うんですが、どうなんだろうなぁ…気になりますよねぇ…
2026年5月13日水曜日
移動中に気づいたんですがv4.2.3がリリースされてました
backend元のcommit具合でリリースが頻繁に行われているのはとてもいいと思いますｗ
寝る前に今日こそビルドできたらいいかな…。llama-cppにもSYCLパッチあてて試してみたいし…
と言うような愚痴は置いておいてｗ
いざ、実際にちゃんと動き出してみると気になるポイントがいくつかで来るもので…
まず1Step目の処理の間、消費電力が１５Wとか表示の上で１７Wとかも飛び出したことも。
しかもCPU温度が正直見たことのない８５度を超えるような温度とか…壊れないかな？壊れないよね😅
そして２Step目以降はちゃんと１０W前後の見慣れた消費電力にCPUも安定の６４度とか６２度とか安心する温度に。
なんかヤバそうな問題だから多少実効速度がおとてもいいから対処方法を知りたい…CPUスレッドを減らして対処してもいいかもな…
２つ目の気になるポイントは、GPUで実行する時のメモリ消費量が倍化してる気がする問題。
モデルをオフロードするとか言う表現が未だにしっくりきてなかったりしますが、ふつうに考えると１つのテンソルレイヤ分の大きさはメインメモリとGPUメモリに２重持ちしないとだめではないかとは思うんですが、感覚としてモデル丸ごと二重持ちしてる気がします。
しかしCPU単体で動かすと、これがそこまで大きくならない。と、いうかモデルのファイルサイズ分の綺麗に消費してる感じです。
先日llama.cppでファイルから直接GPUメモリーにロードできるようにしたとかそんな記憶がありますが、その辺の実装も気になるのと、それは各GPUで対応する必要があるのか無いのかとか…
メモリー消費量は結構直近でスッキリさせたいところですかねぇ…でもハード的に熱問題もｗ
cuda だとどうなるのか？
かなり気になったので見てみると、ハード的な制約は無さそうといった印象
ただ、非同期処理で
と、なってるのでミューテックスを取得するまで待機しちゃうように思える。やべぇこの辺全く記憶にないやｗ検索だな
やっぱミューテックスじゃ確実にロックがかかっちゃうねぇ…
この辺は実装でどうにでもなるから、まぁいいんだろうけど、対してSYCLではqueueにぶち込んで終わりなので簡単だけど、このqueueがポンコツすぎ。
何が非同期だから取得できないだよ。制限ありきで参照させりゃぁいいのに…
厳密にやるかどうかだけど。
と、ざっくり見た感じロックしちゃってもいいんじゃね？っていうのが、現時点での結論だったり。
リアルタイムでcompute()かけたければそれこそワーカースレッド内で処理させるべきなんだろうな。
あくまでもGPU演算が非同期処理で実装されてるからそれに合わせてるだけと考えればいいのかな？
stable-diffusion.cpp SYCL Flux1-schnell Step4 1024x1024 の出力ができた
とりあえず一通り、syclのggml分のソースは目を通したと思います…ｗ
結果から言えば単純に高負荷になるcompute()内で同期をとるようにしました。
sycl:: と dpct:: の違いは何でしょう？ｗ
namespaceが違うというのはわかるので、違っているような感じなのですが、どこかの定義で一致してるのかな？
ggml/sycl内ではcommon.hppでtypedef sycl::queue_ptr *queue_ptrとか記述があったので、sycl内では特にしていなければsycl::queue_ptrとなっているはずなのですが、dpct::queue_ptrと明示されているところもあるわけでして…
syclとdpctの違いも良く分かってないのですが、sycl2020ではsycl::queue_ptrと記述するのがよろしいようで…ただ、dpctのドキュメントではdpct::を使えという指示が明記されているので、正直悩みますｗ
2026年5月12日火曜日
2026年5月11日月曜日
dpct::queue_ptrって？
enum ggml_status ggml_backend_graph_compute(ggml_backend_t backend, struct ggml_cgraph * cgraph) {
enum ggml_status err = ggml_backend_graph_compute_async(backend, cgraph);
ggml_backend_synchronize(backend);
return err;
}
結局のところ、いろいろ経由したものの長い旅を経て、ようやくここまでたどり着いた…ｗ
ggml v0.11.1
llama.cppでsyclの実装が結構行われていたのでソースを眺めていたらリリースされました。
SYCL目線でみると、未実装部分の追加が行われているのと、sync関連で少し手が入っている部分があったので…もしかするとこれで上手くいくように…ならないかなｗ
2026年5月10日日曜日
生成した画像を見せてみた。
現状使えそうなモデルはあまりないのですが、ここ最近生成された画像から写真っぽい画像をGemma4 E4B it UD_Q8_0とQwen3.6 35B A3B UD_Q2_K_XLのモデルでどちらも若干ハンデがある感じになっているのですが…そこはいまストレージに入ってるモデルを減らしているのですみません…ｗ mmprojはどちらもBF16のモデルを使用しました。
llama-cppが新しくなったので、少しチャットして様子を見てみた。
SYCLの動きが少しまともになってるかどうか確認するために少し動かしてみました。
起動直後、数回空振りした感じもありましたが、モデルのロードが終わって動きだしてしまえばすこし文字の出力がスムーズになったような気がします。（という思い込みで見ているので変わってないかもしれないｗ）
LocalAI内で無視されてるかもしれないが、GPUのレイヤーを9999とかに設定しても落ちなくなりました。
で、今回は少し前に気になっていたGemma4の調整済みのit版ではなく素のモデルとチャットしてみました。
モデルはGemma4E4Bのit版とは違ってこちらはLLMを使用する上で必要となる調整が行われていないモデルなので、調整で使用したテンプレートなどもなく、最低限の物だけとなります。
適当に設定して動かしてみると、とりあえず会話はできましたが、本当に会話ができるレベルでした。
とりあえず、いつも通り挨拶して、自身の説明をお願いすると、なんとChatGPT3.5Turboと言い出しました…。この辺はベースとなるモデルという事なのか、生成AIの定義の知識の断片なのかは判断できませんでしたが、そういう感じなのでしょう(笑)
その後も何度か自身の説明を求めましたがここまで具体的な回答は得られなかったので、学習内容の断片なのかな。
すでに会話の中で少し矛盾もチラホラ見えているので、調整が行われていないモデルはこんな程度なのかな？まぁ量子化モデルなのも影響しているとは思いますが。普通に考えると、得られたトークンからその先のトークンを補完するという生成AIの純粋な出力なのかもしれません。
システムプロンプトを設定すると反映されているものの、it版とは違って人格のようなものが全くない状態で本当にデータを検索している感じが強く感じることができます。下地はしっかりしていて、チャットは行えるのでもう少し時間を取って調べてみたいと思いました。
LocalAI backend llama-cpp
LocalAIのリリースが行われないかと今か今かと待っている人間です…内部が結構拡張されているのでそろそろリリースされるかと期待して、早１０日…なしのつぶてです😢
2026年5月9日土曜日
SYCL とりあえずのデバッグ出力
この昨日llama.cppでb9060がリリースされ、いくつかのメソッドの実装が行われていました。sycl: add FILL, CUMSUM, DIAG, SOLVE_TRI, SSM_SCAN, GATED_DELTA_NET (#22149)
表を見比べるとvulkanやopenCLなどはSYCLよりも未実装な部分が多いのを知りました。
そっちもすごい気になるのですが、
2026年5月8日金曜日
Windows11 Wifiが切断→再接続を繰り返しシステムがラグる。
気になりだしたのはここ１，２か月ぐらいかな？
とあるPCで突然スピーカーからノイズが走ったかと思うと、なんだかシステム全体がラグりだしていた。
最初は何が原因かわからなかったものの、よく見るとWifiの接続が切断状態になって再接続を繰り返しているような状態だった。その接続のたびにOneDriveやアップデートなどのプロセスが起動してシステム全体がラグるという最悪だな、この設計。
2026年5月7日木曜日
MiniCPM-V 4.6
llama.cppのリリースを見ていてなにやらMiniCPM-V 4.6という名前を見かけた。
CPMと言うと、個人的な記憶としてはMS-DOSの前身となるOSだよねとか、そのぐらいの知識しかなくて、実際に触ったのは兄の払い下げが父親に譲り渡されたNEC PC-8801mkⅡに無線モデムをつないで、そのターミナルを動かすために使ったぐらい。
まぁここではそうではないんだろうと、早速検索してみると、8Bモデルクラスでマルチモーダルな全部入りでTTSとSTTが同時に行えて超クールな中国産のLLMモデルと言うようなことだった。
それをサポートしたというリリース情報。
早速これも試してみたいなぁ…たた環境が…そろってないしSSDもお腹いっぱいだからなぁ…
Sycl16とSycl32
Sycl16とSycl32の違いをあまり気にせず単純に色々と軽そうだからという事でSycl16を使っていたのですが、もしかすると動作が変わるかもしれないという淡い期待の元makeしてみました。
そもそも、CUDAではF16にしないと処理時間が4倍になるという話を見かけたので、実質的に16ビット前提にやってたところがあります。
2026年5月6日水曜日
Sycl で死ぬパターン
Flux1の出力を一通り（主にClipLを変えただけｗ）終えた気になったので、とっても気の進まないSyclでの動作を試していこうかと。
sycl版のバイナリをmakeしてFlux1で試し始めたのですが、どうもStep1で処理が止まってしまいます。ただ、Stepの表示が行われたため、速度の比較対象としてCPU動作の1Stepと比べることができます。大体ですが、開始させて1分30秒程度なので、ざっくり2.4倍程度の処理が行われていることになります。初期化処理やモデルの読込なども含んだ時間なので、これよりも処理速度は速いものと思われます。
2026年5月5日火曜日
Stepって…
仕組みとしては何となくザックリとした感じとしてとらえていましたが、実際にはどういう感じなんでしょうね？
と言うわけで、Flux1-devは推奨値50のところそれ以下だったらどうなってるのだろう？という疑問が湧いてきたので実際にやってみます。
Step1で終わらせてみると
さすがになんだかわからん状態です。(笑)
（追記）step5ができました。
経験上20でもまともそうな画像が得られたので半分の10では？
こーなりました…
何かとりあえずまともそうじゃないですかね…てか、後ろ向いてるんだ（汗
今のところ時間があればやってみたいなーレベルで、safetensorsからggufへの変換についてもう少し突っ込んで知りたいという点と、stable-diffusion.cppで指定したStep数以外の中間地点でも画像出力させたら面白いんじゃないかなとか。
生成AIの原理として、チャットを前提に考え何らかの処理で画像を起こして、あとは適当な部分に注目して細部化して整えていくのかと思ってたのですが、根本的に違ってるってことなんでしょうね。非常に興味深い…。いまstep5も出力してるからそのあと15も出してみましょうかね…。
(追記)できました…15でこれってことは正面を向くまで劇的変化がどこかでおこるのでしょうか…気になりますねｗ
ただ、２０と比べると輪郭とか髪とかおんなじだったりするんですよ…まるで騙し絵です。
以前と同じものですが20と50の画像も再掲載しておきます。プレビューで間違い探しをしても面白いとおもいます。
Flux1 ClipLの量子化の影響
Flux1-devでは細部まで物体の詳細を持っているためなのか、影響の比率が少ないのかわかりませんが、あまりClipLの影響を受けていない感じ、対してschnellではClipLの影響を思っていた以上に受ける結果となりました。
結果から言えば、Flux1-schnellではClipLの量子化モデルは使用すべきではないと言えるでしょう。Flux1-devでは出力の影響の差が少ないのと、矛盾と言うよりフィルタ効果がの意味合いが強そうなので、好みで使い分けられるかもしれません。
2026年5月4日月曜日
ちょっと気になったのでサンプル程度に。
Flux1用のプロンプトではないのですが、gemma4に作ってもらったプロンプトをベースにしたものを流用してどんな差が出るのか比べてみました。（多分一般的ではない比較ｗ）
そもそも(あくまでも量子化されたモデルで)devとschnellの違い。テキストエンコーダの量子化の違い。あと、Stepの違い。
この辺がどの程度変わるのか、気になったわけです。SD3.5では違いはあるものの、基本的な部分は変わらないかなと。
まず、devとschnellの違いとしては、似てるけど、別物という結論に至りました。SD3.5とFlux1との差ほど違いは無いですが、同じプロンプト、同じseed値、同じテキストエンコーダを使っても出力されているものは内容は同じものの、がらりと変わっています。
step数による違いは思っていた以上に出るような気がします。(SD3.5でStep50とかで動かしたことがないので比較はできませんがｗ)。とは言え、プロンプトに指定した内容は固定化されているので、指定されていない部分の差が出てくる感じでしょうか。
テキストエンコーダの量子化の差については乱数の誤差が出てくるためにやはり結果が異なってきますが、全体的なイメージはStepの影響よりは出にくいようで、この辺はSD3.5も同様だった感じです。実際のオブジェクトも誤差の結果で変わってきているようですがｗ
以下モデル、Step、ClipLの量子化状態のマトリクスが以下のようになります…まぁ未完成ですが、気が向いたら埋めていくかも？ｗあと、ClipLはsafetensorsのままでもいけると思うので、それとの比較や、あとは、現状512x512のみ出力サイズですが、サイズを変えたものも並べていきたいんだよなぁ…
| - | Steps | clip l | ||
|---|---|---|---|---|
| Q4_0 | Q8_0 | safetensors | ||
| schnell | 4 |  |  |  |
| 20 |  |  |  | |
| dev | 20 |
 |
 |  |
| 50 |  |  |  |
ちなみにClipLとT5xxlのエンコーダはFlux1に同梱されているものではない(SD3.5ベース)ですが、すべて同じプロンプト「Full body shot of a beautiful woman standing, dynamic pose, highly detailed, realistic photography, natural lighting, golden hour, soft shadows, cinematic quality.」で作成しています。Seed値はstable-diffusion.cppのデフォルト値(42)です。
恐ろしい話として、実行環境はN150 CPUのみでStep50で出力時間は3時間。1Stepあたり3.6分。これはdevでもschnellでもほぼ変わらずでした。なのでStep4の画像でも15分程度かかってたりします(笑)てか、SYCLも試したい…ｗ
|
|
|
サイズ違いでschnellでClipLはQ4_0、Step4、サイズを768x768にしたパターンが出来上がりました。なんかポージングから違ってるｗこりゃぁ難しいですねｗプロンプトで抑止すれば落ち着いてくれるのだろうか？ネガティブプロンプトもないのであれですが、指の本数が明らかに多いｗと、放置してるとQ8_0も出来上がりました。服の細かいところもしっかりしているイメージです。サイズが大きくなるとClipLの量子化も結構影響が出てきますね。背中の乗っかりが脂肪なのか筋肉なのか判断が難しいですが、ちょっと不自然な感じがしますね。
そうこうしているうちに768x768サイズのClipLの最終版、safetensors版も出来上がりました。Q8_0でボトムに布が追加されてますが、safetensorsでは無くなっていますね。
safetensorsを正とすると量子化されたことにより劣化によるノイズが発生しているととらえられるかもしれませんね。そもそもClipLの量子化モデルファイルを使う意味合いは、ファイルサイズ的にもあまりないことなのですが、予想以上の影響が出ている気がします。
番外編として追加でもう一枚。こちらはClipLをzer0intさんが調整されたもので出力してみました。比較するとQ8やQ4とも混ざっている感じ。予想ですが、元となるClipLが最初からか途中からかわかりませんが、一旦F16とかBF16、もしくは部分的に量子化されてしまっているのかもしれません。ベルトのあたりはQ8_0みたいになっていますが、ボトムの布地は無い様子。トップが違うのはまぁ小物の数も違うのでその辺の乱数ズレで変わってる感じがします。ご参考までに。
2026/05/05 16:06 ようやく貼り終えた…orz
2026年5月3日日曜日
分割されたsafetensorsファイルの結合
ちょっとした予想はしてました。全体がメインメモリーを超える大きさのsafetensorsファイルの結合って結構厄介カモということを…
現状を踏まえると、stable-diffusion.cppが分割されたsafetensorsファイルを直接読み込めればいいのですが、どうもダメそうなので、結合作業を事前に行う必要があります。
Ubuntu 24.04.4 LTS (GNU/Linux 6.17.0-23-generic x86_64)のapt update
先週あてた後、2，3日でなんかアップデートパッケージが30個とか出てたんですが、とりあえず無視してて、再起動ついでにapt updateしたら何やらいくつかのupdatelistが拾えず…まぁとりあえず無視してupgradeでもしとくかと…してたんですけども。
2026年5月1日金曜日
.safetensorsのggufへの変換
一般的なllmであれば、llama.cppのconvert_hf_to_gguf.pyが一番なのは間違いなさそうですが、実際にやりたいのはstable-diffusionで使用するclipなんとかとか、t5なんとかの.safetensorsで正直中身がどうなってるのか良く分かってない。
登録:
投稿 (Atom)