2026年4月10日金曜日

llama.cpp: Gemma 4 26B A4B 量子化されたモデルの動作メモリ

妙に使用メモリが少ないと思ったんですよ(笑)

あと、今までも妙なメモリの変動があったのはあったんですが、A4BのモデルではCPUのみとは言え、メインメモリーには展開されるはずなので…

で、不思議なのはまともに会話が成立していた点はちょっと恐ろしくもあります。

モデルカードなどに記載されている内容としては、A4Bの意味はアクティブパラメータ数が4B程度で動作するという事なのですが、最大26Bのパラメータ(に近くなるだったかな)が展開されます。(Gemma 3nとか今までの話だと起動時にできるだけ早く、そして動作が軽くなるようにレイヤ層が分けられていて、必要になったときに改めて必要なレイヤが読み込まれるといった話だった気がするのですが、それが動的に行に行われるようになったのかな?)

結局、のところ、UD-Q3_K_XLのモデルでもメインメモリーは最低でも8G程度食らいつくようになりました。(ちなみに以前はなんと4G程度w)

何でこんなことがおこったかと言えば昨日か一昨日に行われた修正(リリースb8698+1~b8705の範囲)の結果、動作がまともになったのだと思います。

ただし、この影響がGemma 4だけでなくGemma 3などの影響もしていて、今まで動作していたモデルでvision機能を利用するとおかしなことになり始めています。サクッと見た範囲だと、Gemma 3/3n/MedGemma1.5が直撃していて会話は通るのですが、画像を添付すると「6220x0x22340x0x0x98110x83211110x20x11110x = trueee `asserted** #3210x111110x0x 11111111110x= truee 32 `#42.**」と言ったようなパラメータのようなものが出力されてきたり、反応が無くなったりします。llama.cpp自体は動いている状態ですが、gpuやCPUの動作が空回りしているような状態に。

Qwen3.5は元気に動いているので、この辺の影響は無さそうです。 

昨日のリリースb8721でも解消されていないので、どうしましょうかね(笑)

色々思い返すと…Gemmaの画像認識がダメなのはこの辺の影響なのかな?? 

 

 

0 件のコメント:

コメントを投稿