Intel Arc B580はローカルLLMの速度が出ない？ 対処法で3倍に〜Arc B580ローカルLLM 第1話

2026年7月28日

以前から保有しているRTX 3060 12GBと同じく、12GBのVRAMを積んでいるGPUボード、Intel Arc B580を入手しました。RTX 3060と比べて、ローカルLLM（LLM: 大規模言語モデル。文章を生成するAIの本体）でどれくらいの差があるのか、調べてみました。

ところが、Intel Arc B580 でローカルLLMを動かしたところ、あまりに遅かったため原因を調べました。

本記事では、Ubuntu に入っていたグラフィックドライバ「Mesa」を更新するだけで最大3.3倍に高速化した経緯を、実測値とともに記録します。

測定環境は Ubuntu 24.04 LTS、CPU は Ryzen 9 3950X、GPU は Intel Arc B580 と NVIDIA GeForce RTX 3090 の2枚挿しです。推論には Ollama 0.30.5 を使いました。2026年7月時点の結果です。

使用した機器の概要

使用したデスクトップは、下記のとおりです。このPCにIntel Arc B580を追加しました。

玄人志向 Intel Arc B580 搭載 グラフィックボード GDDR6 12GB AR-B580D6-E12GB/DF

購入したのは、玄人志向のGPUボード、ファンが２つついた、とてもシンプルな見た目をしています。

最初の実測値がおかしかった

B580 を挿して最初に測った decode 速度（文章を生成する速さ）が、これです。

• nemotron-3-nano:4b … 28.52 tok/s
• phi4-mini … 41.76 tok/s

手元の GeForce RTX 3060 では同じローカルLLMのモデルで 90.6 tok/s が出ていました。B580 のメモリ帯域は 456GB/s で、RTX 3060 の 360GB/s を上回ります。帯域が広いB580ほうが遅い、しかも3分の1以下という結果は、明らかに何か不具合があると考えられます。

疑った仮説

仮説1: PCIe接続が劣化している

`lspci` で確認すると、B580 は PCIe 1.0 x1 と表示されました。本来 PCIe 4.0 x8 の製品なので、これなら遅くて当然です。

さらに調査をすると、Intel の公式サポート文書に、Arc シリーズはカード内部に PCIe の階層構造を持つため、標準ツールでは常に「Gen1 x1」と表示されると明記されています。正しい値はカード上流のブリッジ側に出ており、実際には PCIe 4.0 x4 で動作していました。

念のため実測でも裏を取りました。B580 へ 2.61GB を転送するのに要した時間は 4.87 秒です。仮に PCIe 1.0 x1（実効250MB/s）なら転送だけで10.4秒以上かかる計算になり、この時間では成立しません。`lspci` で確認した PCIe 1.0 x1の表示が誤りであった、ということが確認できました。

仮説2: CPUが古い

今回テストで使っているPCのCPUは、Ryzen 9 3950X という Zen 2 世代のCPUで、決して新しくありません。Arc シリーズは Resizable BAR（GPUのメモリへCPUがまとめてアクセスする仕組み）が必須で、無効だと最大24%の性能を失うとされています。

確認したところ、当環境では Resizable BAR は有効でした。Zen 2 と X570 は対応世代であり、この点で 3950X は不利、ということはないようです。

仮説3: バックエンドの選択が悪い

Ollama は Intel GPU に対して Vulkan（GPUを動かすための規格のひとつ）を使います。Intel 純正の SYCL に変えるべきかと考えましたが、これも見当違いでした。llama.cpp の開発者による集計では、B580 では Vulkan が SYCL の約2倍速いと報告されています。すでに最良の経路を使っていたわけです。

本当の原因は Mesa のバージョンだった

Phoronix による Linux 環境の検証に、次の記述がありました。

新しいカーネルは Vulkan のスループットにほぼ何も寄与しなかったが、Mesa 26.1 への移行はテキスト生成に意味のある高速化をもたらした

環境を突き合わせると、差は明確でした。

カーネルは十分に新しいのに、Mesa だけが1世代古い状態でした。

Mesa とは何か

Mesa は Linux で GPU を動かすためのオープンソースのドライバ群です。Vulkan や OpenGL の実装本体にあたります。

ここで重要なのは、NVIDIA と Intel でドライバの供給元が違う点です。

NVIDIA は自社でドライバを配布していますが、Intel と AMD は Linux 用ドライバの本体が Mesa です。llama.cpp の Vulkan バックエンドは計算処理を「シェーダ」というプログラムとして GPU に投げ、それを Intel GPU の機械語へ翻訳・最適化するのが Mesa ANV にあたります。Mesa はコンパイラとして働いており、その出来がそのまま速度に直結します。

B580 は 2024年末に登場した比較的新しい GPU のため、最適化が Mesa に入るのが後追いになっていた、という構図でした。

更新した結果

kisak-mesa という配布元から Mesa を更新しました。

sudo add-apt-repository -y ppa:kisak/kisak-mesa
sudo apt update && sudo apt full-upgrade -y

これで Mesa 25.2.8 から 26.1.5 へ更新されます。影響範囲は Intel と AMD の Vulkan・OpenGL のみで、NVIDIA 純正ドライバには関係しません。同じ機体に挿している RTX 3090 は影響を受けませんでした。

更新前と同じ条件で測り直した結果です。

設定は何も変えていません。ドライバのバージョンを上げただけです。

測定を1度間違えた話

実はこの再測定で、最初に誤った値を出しました。165〜171 tok/s という数字が出たのですが、これは以前に測った RTX 3090 の Vulkan 実測値（167.57 tok/s）とほぼ一致していました。

原因は、B580 に処理を載せるために RTX 3090 のメモリを確保しておく手順が失敗していたことです。当時 3090 は別の作業で21GB使用中で、確保に失敗していました。ところが「使用量が多い」という理由だけで成功と判定してしまい、測定中にその別作業が終わって 3090 が空いた結果、モデルがそちらへ移っていました。

「使用量が多い＝自分が確保できた」ではないという初歩的な取り違えです。以降は次の3系統で検証しています。

1. 確保処理そのものの成否を、出力を読んで確認する
2. NVIDIA 側に推論プロセスが存在しないことを確認する
3. 生成中に B580 のクロックが上がっていることを確認する

検証後の測定では、生成中に B580 が 1200MHz から 2850MHz へ上昇し、同時に RTX 3090 は使用率0%・クロック210MHz のまま動いていませんでした。

更新後の位置づけ

同じモデルでの他GPUとの比較です。いずれも同一機体で実測した値です。

B580 は RTX 3060 を上回る位置に移動しました。文献にある「B580 は RTX 3060 相当」という記述とも一致しており、更新前の 28.52 tok/s が異常値だったことが確定します。

なお同じ表から、Vulkan というバックエンド自体のオーバーヘッドは 7.6% と分かります（RTX 3090 の CUDA 181.41 に対し Vulkan 167.57）。Vulkan だから遅いという説明は成り立ちません。

まとめ

Ubuntu の LTS 版（長期サポート版）は安定性を優先して古いバージョンを固定します。これは通常は利点ですが、新しい GPU では性能面で大きく不利に働きます。

Intel や AMD の比較的新しい GPU を Linux で使うなら、まず Mesa のバージョンを確認することをお勧めします。確認は次のコマンドで行えます。

dpkg -l | grep mesa-vulkan-drivers

一方で注意点もあります。kisak-mesa はシステム全体のグラフィックスタックを更新するため、他の用途で使っている機体では慎重に判断してください。元に戻す場合は sudo ppa-purge ppa:kisak/kisak-mesa で戻せます。

また本記事の数値は2026年7月時点のものです。Mesa の Intel 向け最適化は現在も進行中で、今後さらに変わる可能性があります。

参考にしたサイト

検証に使用した機材