Intel ARC PRO B70着荷しました。
2026年9月2日水曜日。来ました来ました。お荷物が。
Intel ARC PRO B70でございます。開梱しますと、内容はこんな風になっておりました。
1つは本体、1つは 8pin x2→12pin 変換ケーブルでした。
これを取り付けるわけですが、本当はこうしたかったんですけどダメでした。Z440に乗せると、電源を入れたらPOSTで赤ランプ点滅でBEEP音x4鳴らした後に沈黙というオチ。おそらくはBIOS側でInquiryが取れなかったのか、電力的にOUTだったのか（高出力タイプだったくせにー！ヽ(# `Д´)ﾉﾑｷｰ!!）、PCI-Exバスが古すぎてなのか。
なので、Z440のGPUは配置を戻して再度電源を投入して、そのあとWindowsに乗せることにしました。GTX1660はポイ捨てしたのち、こんな風に搭載。こちらは電源ケーブルもきちんと充足してることもあって正常に動きましたのですよ。
間に挟まってるのは、元々Z440の蓋についてたフィラーブロックです。捨てずに置いといてよかった・・これを支えにしたらちょうどピタッとはまりまして。
Windowsの場合、GPUを認識させるにはWindowsドライバを公式からダウンロードしてくる必要があります。
Intel® Arc™ Pro Graphics – Windows*
This download installs Intel® Graphics Driver 32.0.101.8805 for Intel® Arc™ Pro Series Graphics and select Intel® Core™ …
Intel
これを導入すると、こんな風にデバイスドライバでも認識してくれます。
Intel ARC PRO Toolでもこんな風に認識してくれます。
llama.cppを動かす
さて、よりによってllama.cppをWindowsで動かす羽目になりました。いちいちビルドするのはさすがに心が居れたので、以下のところからバイナリとDLLファイルを丸々ダウンロードすることにしました。
Releases ?? ggml-org/llama.cpp
LLM inference in C/C++. Contribute to ggml-org/llama.cpp development by creating an account on GitHub.
GitHub
最新Buildはb10752でしたので、これをダウンロードしました。Windows x64（SYCL)を入手しています。
ZIPファイルがダウンロードされてきますので、これを回答すると、沢山のDLLファイルとEXEファイルが解凍されてくるので、私の場合はこれを C:\llama.cpp 配下にコピーしています。
最近のWindowsはセキュリティ監視が厳しく、以下の対応が必要でした。
- コピーしたファイル全てに（ディレクトリ単位でもいいけど）Windows Defenderでスキャンさせる
- 一通りのバイナリをWindowsターミナルから起動してみて、Windows Defenderで検知・隔離されたファイルをすべて「復旧」させる
何も考えずに実行すると、どうやら勝手に重大な脅威とみなして隔離措置をとるっぽいのでそこが一番面倒です。
で、まずはコンソールで起動してみる。
PS C:\llama.cpp> C:\llama.cpp\llama-server --model C:\llama.cpp\models\Muse-Glimmer-30B-UD-Q2_K_XL.gguf -t 4 -np 1 --temp 1.0 --top-p 0.95 --top-k 64 --host 0.0.0.0 --port 32211 --device SYCL0 -mg 0 --fit off --no-warmup --no-cache-prompt --cache-ram 0 -c 131072 -b 2048 -ub 2048 --reasoning on --log_verbosity 4 --model-draft C:\llama.cpp\models\Muse-Glimmer-30B-DFlash2-Q4_K_M.gguf --spec-type draft-dflash --spec-draft-n-max 4 --mmproj C:\llama.cpp\models\mmproj-MuseGlimmer-kquant.gguf --log-file C:\llama.cpp\logs\llama-MuseGlimmer.log
0.00.599.260 I cmn common_param: common_params_print_info: build 10752 (b96806d96) with Clang 20.1.8 for Windows x86_64
0.00.599.262 I cmn common_param: common_params_print_info: verbosity = 4 (adjust with the `-lv N` CLI arg)
0.00.599.264 I cmn common_param: device_info:
0.00.909.578 I cmn common_param: - SYCL0 : Intel(R) Arc(TM) Pro B70 Graphics (32558 MiB, 32523 MiB free)
0.00.909.589 I cmn common_param: - CPU : Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz (32612 MiB, 18553 MiB free)
0.00.909.635 I cmn common_param: system_info: n_threads = 4 (n_threads_batch = 4) / 8 | CPU : SSE3 = 1 | SSSE3 = 1 | AVX = 1 | AVX2 = 1 | F16C = 1 | FMA = 1 | BMI2 = 1 | LLAMAFILE = 1 | OPENMP = 1 | REPACK = 1 |
0.00.909.701 I srv init: running without SSL
0.00.909.796 I srv init: using 7 threads for HTTP server
0.00.910.159 W srv llama_server: -----------------
0.00.910.162 W srv llama_server: CORS is set to allow all origins ('*') and no API key is set
0.00.910.164 W srv llama_server: this can be a security risk (cross-origin attacks)
0.00.910.164 W srv llama_server: more info: https://github.com/ggml-org/llama.cpp/pull/25655
0.00.910.165 W srv llama_server: -----------------
0.00.910.199 I srv start: binding port with default address family
0.00.918.373 I srv load_model: loading model 'C:\llama.cpp\models\Muse-Glimmer-30B-UD-Q2_K_XL.gguf'
0.00.918.378 I srv load_model: local path 'C:\llama.cpp\models\Muse-Glimmer-30B-UD-Q2_K_XL.gguf'
0.01.159.935 I llama_model_loader: loaded meta data with 36 key-value pairs and 731 tensors from C:\llama.cpp\models\Muse-Glimmer-30B-UD-Q2_K_XL.gguf (version GGUF V3 (latest))
0.01.159.982 I llama_model_loader: Dumping metadata keys/values. Note: KV overrides do not apply in this output.
0.01.160.275 I llama_model_loader: - kv 0: general.architecture str = muse-glimmer
0.01.160.280 I llama_model_loader: - kv 1: general.type str = model
0.01.160.282 I llama_model_loader: - kv 2: general.name str = Muse-Glimmer-30B
0.01.160.283 I llama_model_loader: - kv 3: general.size_label str = 28B
0.01.160.459 I llama_model_loader: - kv 4: muse-glimmer.block_count u32 = 52
0.01.160.461 I llama_model_loader: - kv 5: muse-glimmer.context_length u32 = 131072
0.01.160.462 I llama_model_loader: - kv 6: muse-glimmer.embedding_length u32 = 6656
0.01.160.463 I llama_model_loader: - kv 7: muse-glimmer.feed_forward_length u32 = 19968
0.01.160.464 I llama_model_loader: - kv 8: muse-glimmer.attention.head_count u32 = 32
0.01.160.465 I llama_model_loader: - kv 9: muse-glimmer.attention.head_count_kv u32 = 2
0.01.160.470 I llama_model_loader: - kv 10: muse-glimmer.rope.freq_base f32 = 500000.000000
0.01.160.473 I llama_model_loader: - kv 11: muse-glimmer.attention.layer_norm_rms_epsilon f32 = 0.000010
0.01.160.474 I llama_model_loader: - kv 12: muse-glimmer.attention.key_length u32 = 128
0.01.160.475 I llama_model_loader: - kv 13: muse-glimmer.attention.value_length u32 = 128
0.01.160.477 I llama_model_loader: - kv 14: muse-glimmer.final_logit_softcapping f32 = 20.000000
0.01.160.479 I llama_model_loader: - kv 15: muse-glimmer.logit_scale f32 = 0.196116
0.01.160.480 I llama_model_loader: - kv 16: muse-glimmer.attention.sliding_window u32 = 2048
0.01.160.481 I llama_model_loader: - kv 17: muse-glimmer.attention.sliding_window_pattern u32 = 4
0.01.160.482 I llama_model_loader: - kv 18: tokenizer.ggml.model str = gpt2
0.01.160.483 I llama_model_loader: - kv 19: tokenizer.ggml.pre str = llama4
0.01.225.919 I llama_model_loader: - kv 20: tokenizer.ggml.tokens arr[str,202048] = ["À", "Á", "õ", "ö", "÷", "ø", ...
0.01.245.349 I llama_model_loader: - kv 21: tokenizer.ggml.token_type arr[i32,202048] = [1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, ...
0.01.380.883 I llama_model_loader: - kv 22: tokenizer.ggml.merges arr[str,439802] = ["Ġ Ġ", "Ġ ĠĠĠ", "ĠĠ ĠĠ", "...
0.01.380.892 I llama_model_loader: - kv 23: tokenizer.ggml.bos_token_id u32 = 200000
0.01.380.893 I llama_model_loader: - kv 24: tokenizer.ggml.eos_token_id u32 = 200001
0.01.380.894 I llama_model_loader: - kv 25: tokenizer.ggml.padding_token_id u32 = 200018
0.01.380.895 I llama_model_loader: - kv 26: tokenizer.ggml.add_bos_token bool = true
0.01.380.896 I llama_model_loader: - kv 27: tokenizer.ggml.add_sep_token bool = false
0.01.380.903 I llama_model_loader: - kv 28: tokenizer.chat_template str = {%- macro render_content(content) -%}...
0.01.380.905 I llama_model_loader: - kv 29: tokenizer.ggml.eot_token_id u32 = 200008
0.01.380.906 I llama_model_loader: - kv 30: general.quantization_version u32 = 2
0.01.380.907 I llama_model_loader: - kv 31: general.file_type u32 = 15
0.01.380.908 I llama_model_loader: - kv 32: quantize.imatrix.file str = Muse-Glimmer-imatrix.gguf
0.01.380.909 I llama_model_loader: - kv 33: quantize.imatrix.dataset str = Muse-Glimmer-calibration.txt
0.01.380.910 I llama_model_loader: - kv 34: quantize.imatrix.entries_count u32 = 416
0.01.380.911 I llama_model_loader: - kv 35: quantize.imatrix.chunks_count u32 = 166
0.01.380.913 I llama_model_loader: - type f32: 313 tensors
0.01.380.914 I llama_model_loader: - type q2_K: 136 tensors
0.01.380.914 I llama_model_loader: - type q3_K: 151 tensors
0.01.380.915 I llama_model_loader: - type q4_K: 77 tensors
0.01.380.916 I llama_model_loader: - type q5_K: 46 tensors
0.01.380.916 I llama_model_loader: - type q6_K: 8 tensors無事に起動しました。あと、Dflash-2も無事動いてるようです。mmprojに若干の時間を要しています。
これで次にWebインタフェースを起動してみます。
何とか動いてそうです。
Windowsサービス化する
最初、scコマンドで作ろうとしたのですが、なぜか起動したプロセスが判断できないようでTimeoutと共にサービスが落ちるという珍現象が発生したので、調べてみたところ、この手の実装は今はOSS頼りみたいです。
Release WinSW v2.12.0 · winsw/winsw
🐛 Bug fixesFix download exceptions when ignoring errors (#854
GitHub
ここから、WinSw-x64.exe をダウンロードします。
そして、C;\llama.cpp 上に WinSw.exe として保存しときます。そしてこれもあまり納得いかないんですが、その構成ファイルであるXMLファイルはどうやら WinSw.xml として保存しないといけないらしく。うわーめんどくせーと思いながらXMLファイルを作ります。
<service>
<id>llama-cpp-Muse</id>
<name>LLaMa-cpp Muse Glimmer</name>
<description>LLaMa.cpp Muse Glimmer Service.</description>
<workingdirectory>C:\llama.cpp</workingdirectory>
<executable>llama-server.exe</executable>
<arguments>--model C:\llama.cpp\models\Muse-Glimmer-30B-UD-Q3_K_XL.gguf -t 4 -np 1 --temp 1.0 --top-p 0.95 --top-k 64 --host 0.0.0.0 --port 32211 --device SYCL0 -mg 0 --fit on --no-warmup --no-cache-prompt --cache-ram 0 -c 131072 -b 2048 -ub 2048 --reasoning on --log_verbosity 4 --model-draft C:\llama.cpp\models\Muse-Glimmer-30B-DFlash2-Q4_K_M.gguf --spec-type draft-dflash --spec-draft-n-max 4 --mmproj C:\llama.cpp\models\mmproj-MuseGlimmer-kquant.gguf --log-file C:\llama.cpp\logs\llama-MuseGlimmer.log</arguments>
<log mode="rotate"/>
<logpath>C:\llama.cpp\logs</logpath>
</service>WinSw.exe はどうやらv2系とv3系で動きが異なるみたいなのですが、私はStable版であろうv2.12.0を使用しましたので、この辺り勝手が違うのかもしれませんね。
そして管理者用コマンドプロンプトで C:\llama.cpp へ移動して以下のように実行します。
C:\llama.cpp>WinSW.exe install WinSw.xml
2026-09-02 14:17:49,654 INFO - Installing service 'LLaMa-cpp Muse Glimmer (llama-cpp-Muse)'...
2026-09-02 14:17:49,713 INFO - Service 'LLaMa-cpp Muse Glimmer (llama-cpp-Muse)' was installed successfully.無事サービス化したみたい。起動したらちゃんと起動したよ、よかった・・・
ただ、ログに関しては少々癖があります。どうもWinSwと言うファイル名で、標準出力、標準エラー出力、ラッパーとしての出力の各ログが設定され、そこにログが書き込まれるようになってるようです。ぐぬぬ。このあたりは、Windowsで動かす間は我慢なのかな。
ログから見るIntel ARC Pro B70の動き
今回、CUDAではなく、Intel OneAPIを介した動きとなり、SYCLを介して動作するようで、SYCLというのは「標準C++を使ってCPUやGPU、FPGAなどの異なるプロセッサー（ヘテロジニアス環境）を単一のコードで効率的に制御・プログラミングするためのオープンな業界標準規格」のことだそうです。
CUDA0,CUDA1,…と設定されていた識別子は、SYCL0,SYCL1,…となります。
IntelARCは以下のように認識されました。
0.01.057.199 I Found 1 SYCL devices:
0.01.057.200 I | | | | |Max | |Max |Global | |
0.01.057.201 I | | | | |compute|Max work|sub |mem | |
0.01.057.202 I |ID| Device Type| Name|Version|units |group |group|size | Driver version|
0.01.057.203 I |--|-------------------|---------------------------------------|-------|-------|--------|-----|-------|---------------------|
0.01.057.942 I | 0| [level_zero:gpu:0]| Intel Arc Pro B70 Graphics| 20.2| 256| 1024| 32| 33456M| 1.15.37858|Muse Glimmerの重みデータもちゃんとそこへのっかっていってるようです。
0.09.773.301 I load_tensors: CPU_Mapped model buffer size = 1052.08 MiB
0.09.773.302 I load_tensors: SYCL0 model buffer size = 11677.44 MiBKVバッファ
0.17.774.910 I llama_context: SYCL_Host output buffer size = 0.77 MiB
0.17.774.913 I llama_kv_cache_iswa: creating non-SWA KV cache, size = 131072 cells
0.17.782.236 I llama_kv_cache: SYCL0 KV buffer size = 1664.00 MiB
0.17.889.114 I llama_kv_cache: size = 1664.00 MiB (131072 cells, 13 layers, 1/1 seqs), K (f16): 832.00 MiB, V (f16): 832.00 MiB
0.17.889.127 I llama_kv_cache: attn_rot_k = 0, n_embd_head_k_all = 128
0.17.889.128 I llama_kv_cache: attn_rot_v = 0, n_embd_head_k_all = 128
0.17.889.132 I llama_kv_cache_iswa: creating SWA KV cache, size = 4096 cells
0.17.889.929 I llama_kv_cache: SYCL0 KV buffer size = 156.00 MiB
0.17.897.268 I llama_kv_cache: size = 156.00 MiB ( 4096 cells, 39 layers, 1/1 seqs), K (f16): 78.00 MiB, V (f16): 78.00 MiB
0.17.897.280 I llama_kv_cache: attn_rot_k = 0, n_embd_head_k_all = 128
0.17.897.281 I llama_kv_cache: attn_rot_v = 0, n_embd_head_k_all = 128計算バッファ
0.17.962.178 I sched_reserve: SYCL0 compute buffer size = 1100.07 MiB
0.17.962.183 I sched_reserve: SYCL_Host compute buffer size = 632.08 MiBDFlash-2の重みデータ
0.18.684.065 I load: special tokens cache size = 2048
0.18.753.797 I load: token to piece cache size = 1.4065 MB
0.19.055.358 I load_tensors: offloading output layer to GPU
0.19.055.364 I load_tensors: offloading 4 repeating layers to GPU
0.19.055.365 I load_tensors: offloaded 6/6 layers to GPU
0.19.055.368 I load_tensors: SYCL0 model buffer size = 1556.95 MiBDFlash-2用バッファ。
あれ、CUDAの時は同だったっけ、もう少し容量を食ってた気がするのだが・・
0.19.948.651 I llama_kv_cache_iswa: creating non-SWA KV cache, size = 131072 cells
0.19.950.575 I llama_kv_cache: size = 0.00 MiB (131072 cells, 0 layers, 1/1 seqs), K (f16): 0.00 MiB, V (f16): 0.00 MiB
0.19.950.585 I llama_kv_cache: attn_rot_k = 0, n_embd_head_k_all = 0
0.19.950.586 I llama_kv_cache: attn_rot_v = 0, n_embd_head_k_all = 0
0.19.950.589 I llama_kv_cache_iswa: creating SWA KV cache, size = 4096 cells
0.19.951.178 I llama_kv_cache: SYCL0 KV buffer size = 80.00 MiB
0.19.955.643 I llama_kv_cache: size = 80.00 MiB ( 4096 cells, 5 layers, 1/1 seqs), K (f16): 40.00 MiB, V (f16): 40.00 MiB
0.19.955.651 I llama_kv_cache: attn_rot_k = 0, n_embd_head_k_all = 128
0.19.955.651 I llama_kv_cache: attn_rot_v = 0, n_embd_head_k_all = 128DFlash-2用計算バッファ
0.19.972.612 I sched_reserve: SYCL0 compute buffer size = 1907.07 MiB
0.19.972.618 I sched_reserve: SYCL_Host compute buffer size = 68.05 MiB
0.19.972.619 I sched_reserve: graph nodes = 715 (with bs=2048), 615 (with bs=1)mmproj用まとめて
0.19.982.819 I load_hparams: model size: 1335.41 MiB
0.19.982.821 I load_hparams: metadata size: 0.28 MiB
0.36.646.691 I get_dummy_batch: warmup with image size = 896 x 896タスクマネージャから見た様子
推論中の様子です。VRAMではなく、何故かメインメモリが大量に食われてるのが分かります？
これ、どうやらIntelドライバの影響のようで、intelのGPUドライバはあまりGPUのVRAMを侵食することを良しと思わないドライバらしく、アイドルが続くとGPUメモリの中にあるものをすべてメインメモリに一回ズバッと出しちゃうらしいです。とはいえ、実際にはそんなメモリの大入れ替えが発生してもパフォーマンスが極端に低下するとかそういうのはありません。
ただ、一時的にページングファイルへの書き出しやらなんやら起きる関係で、影響が全くなくゼロと言えばちょっと違うようには見受けられます。このあたりの調整事はユーザの手ではどうにもならない仕様らしく、それがみんながIntel ARC Proを敬遠する理由だったりするのかな？と思わなくもないです。これを何とかするにはOSプラットフォームをLinuxにするしかないとのこと。しかし、Linuxマシンは今回今の機種では絶対載らないことも分かってしまったわけで、今後ワークステーション入れ替えの時を待つしかないっすね。
なお、さすがシロッコファン。ファンが回りだすとそれなりにうるさいです。
推論パフォーマンスは？
あんまりよくないですねぇ。Muse Glimmer 30B ＋ Dflash2というLinuxマシンでもやってた頃とあまり変わらない構造で臨みましたが、なぜかやたらとAcceptanceが低いです。コマンドラインの引数はほとんど同じにしたんですけどねｼｮﾎﾞ──(´･ω･`)──ﾝ
5.18.096.166 I slot print_timing: id 0 | task 0 | n_gen = 100, tg = 13.35 t/s, tg_3s = 13.49 t/s
5.21.196.721 I slot print_timing: id 0 | task 0 | n_gen = 148, tg = 13.98 t/s, tg_3s = 15.48 t/s
5.24.325.581 I slot print_timing: id 0 | task 0 | n_gen = 193, tg = 14.07 t/s, tg_3s = 14.38 t/s
5.27.419.411 I slot print_timing: id 0 | task 0 | n_gen = 230, tg = 13.68 t/s, tg_3s = 11.96 t/s
5.30.510.852 I slot print_timing: id 0 | task 0 | n_gen = 277, tg = 13.92 t/s, tg_3s = 15.20 t/s
5.33.597.986 I slot print_timing: id 0 | task 0 | n_gen = 319, tg = 13.88 t/s, tg_3s = 13.60 t/s
5.34.630.327 I slot print_timing: id 0 | task 0 | prompt eval time = 22088.07 ms / 472 tokens ( 46.80 ms per token, 21.37 tokens per second)
5.34.630.362 I slot print_timing: id 0 | task 0 | eval time = 23949.23 ms / 341 tokens ( 70.44 ms per token, 14.20 tokens per second)
5.34.630.364 I slot print_timing: id 0 | task 0 | total time = 46037.30 ms / 813 tokens
5.34.630.366 I slot print_timing: id 0 | task 0 | graphs reused = 182
5.34.630.650 I slot print_timing: id 0 | task 0 | draft acceptance = 0.21081 ( 156 accepted / 740 generated), mean len = 1.84
5.34.630.655 I slot print_timing: id 0 | task 0 | acc per pos = (0.427, 0.227, 0.130, 0.059)読み取りパフォーマンスの低さはまだ謎ですが、今後じっくり向き合っていくしかないかなと思います。
できるなら、llama.cpp動かすならやっぱりLinuxがいいっすねぇ（しみじみ）
コメント