LocalAIで遊んでいるminiPCと同一のminiPCでWindowsを使用しているのですが、windows用のintelグラフィックスドライバの更新をおこなったら、インテル・グラフィックソフトウェアが新しくなり、ようやく内蔵のGPUがどんなものなのか目視することができました。
まぁ型番ははあれなんですが。
N150の内蔵GPUはコアが２つ…１つじゃないんだね？というか、なんかどこかで２つになってても機能的には１つとか何とかあったような気がするな…
共有メモリは実メモリの半分。で8GBまでとなっている。変な制約は無さそうです。
Ubuntu 24.04.4 LTS (GNU/Linux 6.17.0-22-generic x86_64) ServerでoneAPIなどをインストールして見える限り共有メモリの扱いが全く分からないし、OSレベルで設定すらできなさそうなのですが、xpu-smiで見る限り、メインメモリは全て扱えそうな雰囲気になっていることに最近気づきました。
~$ sudo xpu-smi stats -d 0
| GPU Memory Bandwidth (%) | N/A |
| GPU Memory Used (MiB) | 15564 |
| GPU Memory Util (%) | 99 |
| Xe Link Throughput (kB/s) | N/A |
intel_gpu_topだとゲージで使用率はわかるものの具体的な数値が全く分からないのですが、xpu-smiをみてみると、15,564となっているのはスワップに1G割いているので、その分が小さくなっていて、残りのメモリがすべて使えるようになってそうな雰囲気です。（Usedとなっているのが意味不明なわけですが。）
freeやhtopなどで見る限り、
~$ free -m
total used free shared buff/cache available
Mem: 15734 6473 203 14 9364 9260
Swap: 1572 1572 0
となっているので、共有メモリがusedから割当たれてそうなのはわかるのですが、整合性が良く分かりません。
ちなみにllama.cppでSYCLを有効にしたバイナリでQwen 35B A3Bとかメモリを超えるモデルファイルを実行するとOOMで落ちるわけではなく、限界までメモリ占有してリモート環境で使っている場合は制御不能になります。メインコンソールでkillできればいいんでしょうが…電源ボタンシャットダウンも効かなくなっていたので、もしかするとメインコンソールでもダメかも？。
CPU単体で動作させた場合は、実際にモデルファイルの読込みは行われますが、不要なレイヤーは解放されるのでunsloth_Qwen3.6-35B-A3B-UD-Q2_K_XL.ggufであれば実行中は6GB程度の消費で済みました。なのでもう少し大きくてもいけそうです。SYCLを有効にしている場合はほぼメモリを消費状態に陥ってこれ以上大きなモデルはメモリが16GしかないPCではダメっぽいです。
SYCLを有効にすると色々と障害が大きくなるので何とかならないかと考えてはいるのですが、vulkanにしても動作があまり変わらなかったので、openCLベースやOpenVINO [In Progress]ベースでビルドすれば改善できるかもと期待はしているのですが…ダメかな？ｗ
0 件のコメント:
コメントを投稿