Intel Arc Pro B70 32GBで31B Denseモデルを150W運用する
ローカルLLM用に大容量VRAMを確保しようとすると、真っ先にNVIDIA、次にAMDが候補に挙がります。特に30B超級のDenseモデルや長いコンテキスト、マルチモーダルをローカルで動かすには32GB以上のVRAMが欲しくなりますが、NVIDIAの32GBプロ向けカードは国内では非常に高価です。AMD Radeon AI PRO R9700も有力な候補ですが、B70より少し上の価格帯になります。
そこで候補に浮上するのが、Intel Arc Pro B70 32GB(GDDR6 ECC)です。日本国内ではAmazon.co.jp掲載例で税込22万円台〜28万円台程度です。決して「安い買い物」ではありませんが、32GB VRAMを持つプロ向けGPUとしては、RTX PRO 4500 Blackwellよりかなり手を出しやすい価格帯に収まります。
筆者の環境では、このArc Pro B70を日常運用のLLMサーバーとして導入し、夏場の発熱・静音性を考慮して 150Wに電力制限した状態 でGemma 4 31B(Dense)を常時稼働させています。
結論から言うと、Arc Pro B70は「最速の32GB GPU」ではありません。メモリ帯域(608GB/s)やソフトウェアスタック(SYCL/Level Zero)の成熟度ではNVIDIA/CUDAに明確な差をつけられています。
しかし、環境さえ正しく組めば、150W制限下でも31B Dense Q4で約22 tok/s、MTP(Speculative Decoding)併用で約34 tok/s という実用的な生成速度が出ます。
本記事では、実際に稼働させているビルド手順、ランタイムの落とし穴、150W制限下の実測ベンチマーク、および競合32GBカードとの立ち位置を整理して共有します。
実行環境
検証および本番運用しているホスト(マシン名: K8)の構成です。
| 項目 | 内容 |
|---|---|
| ホスト | K8 |
| CPU | AMD Ryzen 7 8845HS (8C/16T, Radeon 780M内蔵) |
| メインメモリ | 64GB (iGPUへ8GB割当、OS認識 53GiB) |
| dGPU |
Intel Arc Pro B70 Graphics (PCI ID 8086:e223) |
| dGPU VRAM | 32,656 MiB(約32GB GDDR6 ECC) |
| OS / Kernel | Ubuntu 26.04 LTS / 7.0.0-29-generic
|
| GPU Driver |
xe ドライバ |
| 推論バックエンド | llama.cpp (llama-server) / SYCL + Level Zero |
SYCL経由では次のように認識されます。
SYCL0: Intel(R) Arc(TM) Pro B70 Graphics (32656 MiB, 32585 MiB free)
このホスト上で llama-server を起動し、LAN内(http://192.168.0.5:8080/v1)にOpenAI互換APIとして公開しています。
ソフトウェアスタックとビルド手順
使用している llama.cpp のバージョンおよびビルド環境です。
| 項目 | 設定値 |
|---|---|
| llama.cpp build |
b10288 (commit 360e1349f0...) |
| ビルド精度 | fp16 |
| バックエンド | SYCL / Level Zero |
| oneAPI | 2026.1 (icx / icpx 2026.1.1) |
CMakeによるビルド
oneAPI環境変数をロードした上で、SYCLおよびLevel Zeroを有効にしてビルドします。
source /opt/intel/oneapi/2026.1/oneapi-vars.sh --force
cmake -S "$WORKTREE" -B "$BUILD_DIR" -G Ninja \
-DCMAKE_BUILD_TYPE=Release \
-DCMAKE_C_COMPILER="${ONEAPI_ROOT}/bin/icx" \
-DCMAKE_CXX_COMPILER="${ONEAPI_ROOT}/bin/icpx" \
-DCMAKE_INSTALL_PREFIX="$CANDIDATE" \
-DBUILD_SHARED_LIBS=ON \
-DGGML_NATIVE=ON \
-DGGML_SYCL=ON \
-DGGML_SYCL_F16=ON \
-DGGML_SYCL_DNN=ON \
-DGGML_SYCL_GRAPH=ON \
-DGGML_SYCL_HOST_MEM_FALLBACK=ON \
-DGGML_SYCL_SUPPORT_LEVEL_ZERO_API=ON
cmake --build "$BUILD_DIR" --parallel "$BUILD_JOBS"
cmake --install "$BUILD_DIR"
注意点: Graph機能の扱い
ビルド時には-DGGML_SYCL_GRAPH=ONを指定していますが、実行時の安定性を最優先するため、起動時の環境変数でexport GGML_SYCL_ENABLE_GRAPH=0としてGraphを無効化しています。現状のSYCL実装では、Graph有効化によるわずかな速度向上よりもクラッシュ回避の安定性を取った方が無難です。
⚠️ Compute Runtimeのバージョン罠(重要)
Intel GPUでローカルLLMを動かす際、最大のハマりどころが Intel Compute Runtime のバージョン選定 です。
現在、以下のバージョンで安定稼働を確認しており、勝手に更新されないよう apt-mark hold しています。
libze-intel-gpu1 26.22.38646.6-1~25.10~ppa1
intel-opencl-icd 26.22.38646.6-1~25.10~ppa1
intel-ocloc 26.22.38646.6-1~25.10~ppa1
一方、検証したKobuk PPAの 26.27.39122.12-1~26.04~ppa1 では、B50/B70でのSYCL推論時に SIGSEGVが発生 しました(旧版に戻すと正常化)。
Intel GPU環境では、性能比較以前に「どのランタイムバージョンで動いているか」が動作の生命線になります。
- 関連Issue: intel/compute-runtime #971, #972
本番モデル構成とサーバー起動設定
モデル構成
日常運用では、31B DenseモデルをベースにVisionとMTP(投機的サンプリング)を組み合わせています。
-
Main Model:
gemma-4-31B-it-qat-UD-Q4_K_XL.gguf(約17GB, QAT版 UD-Q4_K_XL) -
MTP Draft Model:
mtp-gemma-4-31B-it.gguf(約267MB, speculative decoding用) -
Vision Projector:
gemma-4-31B-mmproj/mmproj-BF16.gguf(約1.12GiB, BF16) -
API Alias:
local-vision
llama-server 起動コマンド
llama-server \
-m gemma-4-31B-it-qat-UD-Q4_K_XL.gguf \
-md mtp-gemma-4-31B-it.gguf \
--spec-type draft-mtp \
--spec-draft-n-max 4 \
--spec-draft-p-min 0.8 \
--mmproj gemma-4-31B-mmproj/mmproj-BF16.gguf \
--alias local-vision \
--host 192.168.0.5 \
--port 8080 \
-c 98304 \
-ub 1024 \
-ctk q8_0 \
-ctv q8_0 \
--jinja \
-ngl all \
-sm none \
-t 8 \
--device SYCL0 \
--parallel 1 \
-fa 1
設定パラメータのポイント
-
-ngl all/-sm none: 31Bモデルの全レイヤーをB70へオフロード。 -
-c 98304: コンテキスト長は約98kトークン確保。 -
-ctk q8_0 -ctv q8_0: 長大コンテキスト時のVRAM圧迫を防ぐため、KV CacheをQ8_0量子化。 -
--parallel 1: 複数スロットでのVRAM競合と応答遅延を避けるため、あえて1スロット運用に限定。 -
--spec-draft-n-max 4/--spec-draft-p-min 0.8: MTPの投機深度と受理判定の閾値。
実行時環境変数
export ONEAPI_DEVICE_SELECTOR=level_zero:gpu
export GGML_SYCL_ENABLE_OPT=1
export GGML_SYCL_USE_LEVEL_ZERO_API=1
export GGML_SYCL_ENABLE_VMM=1
export GGML_SYCL_ENABLE_DNN=1
export GGML_SYCL_ENABLE_FLASH_ATTN=1
export GGML_SYCL_ENABLE_GRAPH=0
export UR_L0_ENABLE_RELAXED_ALLOCATION_LIMITS=1
export LLAMA_ARG_THINK_BUDGET=256
LLAMA_ARG_THINK_BUDGET=256 は対話時の体感速度改善に効果的です。Thinkingモデル特有の長考を適度に抑制し、ファーストトークンまでの待ち時間を短縮できます。
なぜ150Wに電力制限するのか?
Arc Pro B70の公称TBPは230Wクラスですが、本環境ではスクリプトで 150Wに制限 して運用しています。
理由はシンプルで、「24時間365日、静かに安定稼働させるため」 です。
単発のベンチマークであれば230Wフルパワーで回せばスコアは伸びますが、常時起動のホームサーバーとしてDiscord Botや作業PCから呼び出す場合、夏の室温上昇、ファンの騒音、電源への負荷が問題になります。150Wまで絞ることで、ファンノイズと発熱を抑えつつ常用可能なラインを維持しています。
参考: 150W制限を外した状態の確認とベンチマーク
150W制限を外した状態でも、同じB70で追加ベンチマークを取りました。
まず、本当に150W制限が外れているかをsysfsで確認しています。
power1_label=card
power1_cap=330000000
power1_crit=575000000
power1_cap=330000000 なので、カード側のcapは330Wです。少なくとも、以前の150W制限状態ではありません。
また、ベンチ前後でPL系のスロットリング理由も確認しました。
reason_pl1=0
reason_pl2=0
reason_pl4=0
ベンチ中のhwmonサンプリングでもPL1/PL2/PL4の発火は確認していません。したがって、以下の値は「150W制限を外した状態のB70」として扱います。ただし、完全な製品定格比較というより、本環境でのcap 330W設定下の実測値です。
Gemma 4 31B Dense
| テスト | 150W制限下 | 150W制限解除 | 伸び | 平均カード電力 | 最大VRAM温度 |
|---|---|---|---|---|---|
| PP512 | 460.81 tok/s | 621.52 tok/s | 1.35倍 | 116.9 W | 52.0 ℃ |
| TG128 | 21.94 tok/s | 23.64 tok/s | 1.08倍 | 175.4 W | 58.0 ℃ |
Prompt Processingはかなり伸びます。一方で、Token Generationは1.08倍に留まりました。31B Denseの生成フェーズはメモリ帯域やkernel効率の影響が強く、単純に電力を上げても比例して伸びるわけではない、という見え方です。
Qwen3.5-35B-A3B MoE
Gemma 4 31B Denseとは別に、MoEモデルでの挙動を見るため Qwen3.5-35B-A3B-UD-Q4_K_XL.gguf でも150W制限解除状態の測定を行いました。このモデルは後述するR9700公開値とモデル名・量子化を揃えやすく、B70の立ち位置を見るための参考になります。
| テスト | B70 150W | B70 150W制限解除 | 伸び | R9700公開値 | R9700 / B70制限解除 |
|---|---|---|---|---|---|
| PP512 | 1275.84 | 1406.89 | 1.10倍 | 2713 | 1.93倍 |
| PP1024 | 1258.05 | 1414.21 | 1.12倍 | 2643 | 1.87倍 |
| PP2048 | 1241.47 | 1392.55 | 1.12倍 | 2610 | 1.87倍 |
| PP4096 | 1217.95 | 1365.47 | 1.12倍 | 2546 | 1.86倍 |
| PP8192 | 1195.13 | 1341.25 | 1.12倍 | 2413 | 1.80倍 |
| PP16384 | 1157.35 | 1305.01 | 1.13倍 | 2196 | 1.68倍 |
| PP32768 | 1096.85 | 1235.22 | 1.13倍 | 1877 | 1.52倍 |
| TG128 | 75.89 | 78.31 | 1.03倍 | 127.4 | 1.63倍 |
Qwen3.5 MoEでも、PPは1.10〜1.13倍ほど伸びますが、TGは1.03倍です。R9700との差は少し縮まりますが、まだTGで約1.63倍の差があります。
この結果を見る限り、B70の150W運用はかなり現実的です。電力制限を外すとPPは伸びますが、チャット体感に直結しやすいTGの伸びは小さいため、常用サーバーとしては150W制限のままでも性能損失は許容しやすいと判断しています。
150W制限下での実測ベンチマーク
1. llama-bench 単発スループット測定
CI環境で取得した llama-bench(build b10288)の測定結果です(-r 1、150W制限下)。
| モデル | テスト | スループット |
|---|---|---|
| Gemma 4 26B A4B Q4 | PP512 (Prompt Processing) | 1396.61 tok/s |
| Gemma 4 26B A4B Q4 | TG128 (Token Generation) | 56.56 tok/s |
| Gemma 4 31B Dense Q4 | PP512 (Prompt Processing) | 460.81 tok/s |
| Gemma 4 31B Dense Q4 | TG128 (Token Generation) | 21.94 tok/s |
31B Dense Q4で 生成速度 21.94 tok/s。人間が読む速度を余裕で上回っており、チャット用途として十分実用的です。
※最新ビルド b10454 での再測定でも 22.02 tok/s とほぼ同等のスコアを維持しています。
2. MTP(投機的サンプリング)による生成速度の改善
Gemma 4 31B Denseに対し、MTP draft model(mtp-gemma-4-31B-it.gguf)を有効にしたAPIベンチマークを測定しました。
(同一プロンプト、temp=0、max_tokens=1024、5回測定中ウォームアップを除く4回平均)
| 条件 | 平均応答時間 (wall time) | eval速度 (llama.cpp) | API生成速度 | 消費電力 (平均) | VRAM最大温度 |
|---|---|---|---|---|---|
| MTPなし | 18.48 秒 | 20.81 tok/s | 20.62 tok/s | 146.10 W | 58.0 ℃ |
| MTPあり | 11.50 秒 | 34.15 tok/s | 33.64 tok/s | 142.07 W | 56.0 ℃ |
- 生成速度(eval): 20.81 tok/s → 34.15 tok/s(約1.64倍)
- 応答時間(wall time): 18.48秒 → 11.50秒(約37.7%短縮)
- Draft Acceptance Rate: 62.10% (Mean Accepted Length: 2.63 tokens)
MTPの追加によってドラフトモデル用のVRAM消費は約0.76GiB増えますが、生成速度は1.6倍以上に跳ね上がります。31B Denseの重量級モデルであっても、MTPを噛ませることで体感速度が劇的に向上します。
VRAM使用量の内訳
ロード直後のSYCL空き容量から算出したVRAM使用量です(Total: 32,656 MiB)。
| 状態 | 使用VRAM | 空きVRAM |
|---|---|---|
| アイドル時 | 76 MiB | 32,580 MiB |
| 31B Dense(MTPなし) | 22,238 MiB (約21.7 GiB) | 10,418 MiB |
| 31B Dense(MTPあり) | 23,018 MiB (約22.5 GiB) | 9,638 MiB |
| 本番構成(31B + MTP + Vision) | 約24,059 MiB (約23.5 GiB) | 8,597 MiB |
31B Dense + MTP + Vision Projector + 98k KV Cacheを展開しても約23.5 GiBで収まり、32GB VRAMの恩恵をフルに享受できています。
32GB級GPUスペック・性能比較
2026年8月18日時点で、代表的な32GB VRAMカードの国内価格を含めて比較すると次のようになります。Amazon.co.jpの掲載価格は変動が大きいため、ここでは価格.com経由で確認できたAmazon.co.jp掲載例と国内価格の目安として扱います。
| GPU | VRAM | メモリ帯域 | 公称TBP | 国内価格の目安 |
|---|---|---|---|---|
| Intel Arc Pro B70 | 32GB GDDR6 ECC | 608 GB/s | 230W (本稿150W) | Amazon.co.jp掲載例で約22.5万〜28.7万円 |
| AMD Radeon AI PRO R9700 | 32GB GDDR6 ECC | 640 GB/s | 300W | Amazon.co.jp掲載例で約26.7万〜28.0万円 |
| NVIDIA RTX PRO 4500 Blackwell | 32GB GDDR7 ECC | 896 GB/s | 200W | Amazon.co.jp掲載例で約57万円〜、国内価格は約62万円台〜 |
- Intel Arc Pro B70 仕様
- AMD Radeon AI PRO R9700 仕様
- NVIDIA RTX PRO 4500 Blackwell 仕様
- 価格.com: Intel Arc Pro B70 Amazon.co.jp掲載例
- 価格.com: Radeon AI PRO R9700 Amazon.co.jp掲載例
- 価格.com: RTX PRO 4500 Blackwell Amazon.co.jp掲載例
メモリ帯域とソフトウェア最適化の壁
純粋なメモリ帯域で見ると、B70(608GB/s)はAMD R9700(640GB/s)と約5%差ですが、GDDR7を積んだRTX PRO 4500 Blackwell(896GB/s)には約32%離されています。
また、実際の推論速度にはバックエンド(CUDA / ROCm / SYCL)のカーネル最適化やFlash Attentionの完成度も影響します。
参考までに、公開されているベンチマークデータと同一モデル(Qwen3.5-35B-A3B-UD-Q4_K_XL.gguf)をB70(150W)で追加測定した結果を比較します。
| GPU / バックエンド | モデル | PP512 | TG (Generation) | 出典・備考 |
|---|---|---|---|---|
| Arc Pro B70 (SYCL, 150W) | Gemma 4 31B Dense Q4 | 460.8 tok/s | 21.94 tok/s | 本稿実測(MTPなし) |
| Arc Pro B70 (SYCL, 150W) | Gemma 4 31B Dense Q4 + MTP | - | 34.15 tok/s | 本稿API実測(MTPあり) |
| RTX PRO 4500 Blackwell | Gemma 4 31B Q4_K_M | - | 33.8 tok/s | Exxact公開値 (Ollama, 素の生成速度) |
| Radeon AI PRO R9700 (Vulkan) | Qwen3.5-35B-A3B Q4 | 2,713 tok/s | 127.4 tok/s | llama.cpp discussion公開値 (MoE) |
| Arc Pro B70 (SYCL, 150W) | Qwen3.5-35B-A3B Q4 | 1,275.8 tok/s | 75.89 tok/s | 本稿追加実測 (MoE) |
| Arc Pro B70 (SYCL, 150W制限解除) | Qwen3.5-35B-A3B Q4 | 1,406.9 tok/s | 78.31 tok/s | 本稿追加実測、card cap 330W |
- 出典:
MoEモデル(Qwen 35B A3B)において、R9700(Vulkan)は生成 127.4 tok/s、B70は150W制限解除後でも78.31 tok/sと明確な差がつきます。電力条件に加え、ドライバやVulkan/SYCLカーネル最適化の差が出ていると見られます。
素の生成性能でNVIDIAやAMDの上位環境に勝てるわけではありません。また、国内価格で見るとB70とR9700の差は数万円規模であり、B70だけを「激安」とは言えません。
それでも、B70 + MTP構成にすることで、国内では50万円台後半〜60万円台以上になりがちなBlackwell 32GBカードの素の生成速度(~34 tok/s)に近い使用感を、20万円台のB70で狙える というのは大きな魅力です。R9700に対しては絶対性能で負けますが、150W運用・SYCL構築・MTPを含めた実運用の落としどころとして、B70は十分に成立します。
運用で得られたノウハウ・注意点
1. プロセス多重起動によるカーネルハング対策(advisory lock)
32GB VRAMがあっても、31Bモデル運用中に誤って別のベンチマークやサーバーを起動すると、VRAM枯渇からOSごとハングアップすることがありました。
対策として、本番サーバー起動スクリプトとベンチマークスクリプトの間で共通のファイルロック(flock)を取得するようにしています。
LOCKFILE="/run/user/$(id -u)/llama-b70.lock"
exec 200>"$LOCKFILE"
flock -n 200 || { echo "GPU is busy (locked by another process)"; exit 1; }
2. Intel GPUでローカルLLMを運用する現実
- 導入のハードル: CUDAのように「ドライバを入れてバイナリを落とせば即使える」状態ではありません。oneAPIでのソースビルドや環境変数調整が必要です。
-
フレームワークの制約:
llama.cppはSYCLサポートが手厚いですが、vLLMやSGLangなどの他のサービングフレームワークではNVIDIAに比べてセットアップの手間がかかります。 - 再現性の担保: 前述の通りCompute Runtimeの更新で突然推論が壊れることがあるため、安定版パッケージの固定(hold)は必須です。
まとめ
Intel Arc Pro B70 32GBは、万人向けの「挿すだけで最速のGPU」ではありません。
しかし、
- 国内20万円台で手に入る32GB ECC VRAM
- 150W制限下でも31B Dense Q4を約22 tok/s、MTP併用で約34 tok/sで動かせる実力
- Vision Projector + 長大コンテキストを余裕で飲み込むキャパシティ
を備えています。国内価格ではR9700との差は大きくありませんが、RTX PRO 4500 Blackwellとは価格帯が明確に異なります。「静音・低発熱で30B超級のローカルLLMを24時間運用したい」かつ「50万円超の32GB GPUまでは出しにくい」用途において、B70は現実的な選択肢 に仕上がっています。
「ローカルLLMならCUDA一択」と思っている方も、選択肢のひとつとして検討してみてはいかがでしょうか。