自宅サーバのログ監視をLLMにやらせたいなぁとずっと思ってて
でも、自宅環境でGPU常時起動は嫌だなぁと思いつつ
llama.cpp ならCPUでイケてる話しを耳にして、それならVMで行けるんじゃない？
そーだ、KVMサーバのIntel CPUの内蔵GPU（iGPU）をパススルーしてみたらどうだろう？　と思っていたのをやっと試せました。

1. 今回の環境

今回の確認範囲で使った構成は以下です。

項目	内容
ホストCPU	Intel Core i7-11700
iGPU	Intel UHD 750
仮想化	KVM
ゲスト	LLM実行用VM
推論ランタイム	`llama.cpp`
GPUバックエンド	SYCL backend
モデル	`Qwen3-4B-Instruct`
量子化	`Q4_K_M`

今回は、LLM実行用の Ubuntu 24.04 LTS VM を KVM 上に作成し、
vCPU 4コア / RAM 16GB / DISK 36GB という比較的軽めの構成で確認しました。
主眼は、監視用途で常時動かす軽量LLM基盤として成立するかの確認です。

llama.cpp は、GGUF 形式のモデルをローカルで軽く動かしやすい実装です。CPUで強いのが有名ですが、実は CUDA や Vulkan、SYCL などのGPUバックエンドにも対応しています。

2. やりたかったこと

やりたかった構成は、ざっくり次のとおりです。

自宅KVMサーバ上に LLM 用 VM を作る
VM上で llama.cpp を動かす
Intel iGPU を VM にパススルーする
llama.cpp を SYCL backend 対応でビルドする
CPU-only と比較して、監視用途に向くか判断する

発想としては悪くないと思っていました。

専用GPUを常時起動しなくて済む
VM化して保守しやすい
小型GGUFなら十分現実的
iGPUが使えれば少し速くなるかもしれない

ところが、実際にやると予想以上に手間がかかりました。

3. 一番大変だったのはGPUパススルー

今回一番苦労したのは、LLMそのものよりも
Intel iGPU をVMへちゃんと渡すところでした。

この系統では、ざっくり以下のレイヤの切り分けが必要になります。

BIOS / UEFI 側の設定
IOMMU の有効化
KVM / libvirt 側の設定
ゲストOS側でのデバイス認識
推論ランタイム側でのGPU利用

つまり、

パススルーできていない
見えているが使えない
使えているつもりだがCPU実行になっている

といった状態が起きやすく、確認ポイントが多いです。

しかも、途中でVMのコンソールが止まる、戻したつもりが戻っていない、という仮想化あるあるもありました。

4. パススルーできても、それだけでは終わらない

ここが今回の重要ポイントでした。

GPUをVMに見せただけでは、llama.cpp はそのGPUを使ってくれません。

Intel iGPU を使うには、今回の構成では
llama.cpp を SYCL backend 対応でビルドする必要がありました。

つまり流れとしては、

iGPUをVMにパススルーする
ゲストOSで認識させる
SYCL / oneAPI 系の環境を入れる
llama.cpp を SYCL 有効でビルドする
実行時に GPU backend が使われていることを確認する

という段取りになります。

SYCL は、Intel GPU でも使いやすいアクセラレータ向けの実行基盤の1つです。llama.cpp の公式ドキュメントでも、SYCL バックエンドは Intel の Arc や Data Center GPU だけでなく、built-in GPU / iGPU も対象として案内されています。

5. 実際に使ったコマンド例

ここでは、今回の記事の流れに沿って、実際に使う代表的なコマンドを整理しておきます。

5-1. CPU-only でのベンチ例

./build/bin/llama-bench \
  -m ./models/Qwen3-4B-Instruct-Q4_K_M.gguf \
  -p 512 \
  -n 128 \
  -t 4

見たいのは主に次の2つです。

pp: prompt processing speed
tg: token generation speed

監視用途では、最終的な応答感に効くので tg を重視しました。

5-2. SYCL backend 版のビルド例

Intel iGPU を使うには、llama.cpp を SYCL backend 対応でビルドします。
手元では概ね次のような方向になります。

cmake -B build -S . \
  -DGGML_SYCL=ON \
  -DCMAKE_BUILD_TYPE=Release

cmake --build build -j

環境によっては oneAPI / SYCL 系ランタイムの導入が必要です。このあたりはディストリや導入方法で差が出ます。

5-3. SYCL 実行でのベンチ例

./build/bin/llama-bench \
  -m ./models/Qwen3-4B-Instruct-Q4_K_M.gguf \
  -p 512 \
  -n 128

※ 実際には GPU backend が有効になっていることを、起動ログやバックエンド表示で確認する必要があります。ここは「ベンチが動いた」だけでは不十分で、本当にSYCLで動いているかを確認するのが大事でした。

5-4. 実運用に近い推論例

./build/bin/llama-cli \
  -m ./models/Qwen3-4B-Instruct-Q4_K_M.gguf \
  -t 4 \
  -p "次のログを要約して、重要度を high / medium / low で判定してください: ..."

6. ベンチ結果

今回、確認できているベンチ結果は次のとおりです。

6-1. token generation speed 比較

backend	条件	tg
CPU	4 threads	15.39 tok/s
Intel iGPU (SYCL)	VM + iGPU passthrough	4.0 tok/s

今回の条件では、CPU の方が約4倍速い結果でした。

これはかなり意外でした。「せっかくGPUを使ったのだから少しは速くなるだろう」と思っていたのですが、結果は逆でした。

6-2. この記事で強調したいポイント

ベンチ結果として重要なのは、単に「GPUが動いた」ではなく、

ちゃんと動くまでが大変
ビルドも一手間必要
それでも速くならない場合がある

という点です。

今回のオチはまさにここでした。

自宅サーバ監視を省電力でLLM化したくて、
VMに Intel iGPU をパススルーして、
llama.cpp を SYCL backend でビルドし、
苦労してやっと動かしたら、
CPUの方が速かった。

7. なぜCPUの方が速かったのか

今回の範囲では完全な原因特定まではしていませんが、理由としては次のようなものが考えられます。

7-1. Intel UHD 750 は LLM向けに強いGPUではない

内蔵GPUは表示や動画支援には便利ですが、LLM推論で効く

メモリ帯域
演算資源
推論向け最適化

という観点では、専用GPUのような強みはありません。

7-2. llama.cpp の CPU backend がかなり強い

llama.cpp は CPU 実行の最適化がかなり進んでいます。
軽量モデル・短文用途では、CPU側がかなり健闘します。

7-3. 今回の構成が複雑だった

今回は

KVM
ゲストOS
iGPUパススルー
SYCL backend

という構成なので、ネイティブ実行より条件としては不利な可能性があります。

8. 監視LLM用途として見た学び

今回の実験で、一番大きかった学びは
「監視用途なら、まずCPU-onlyで十分現実的」
という点です。

監視LLMでやりたい処理は、たとえば次のようなものです。

ログから異常行を拾う
何のエラーか一言で説明する
すぐ見るべきかをざっくり判定する
通知文を読みやすく整える

この程度であれば、巨大モデルも専用GPUも必須ではありません。

自宅用途ではむしろ、

壊れにくい
再現しやすい
メンテしやすい
消費電力に納得できる

ことの方が重要です。

この観点では、CPU-only の llama.cpp VM はかなり有力です。

9. まとめ

今回の検証で分かったことをまとめると、次のとおりです。

自宅サーバ監視を LLM で自動化する発想はかなり有望
省電力を考えると、GPU常時起動はできれば避けたい
llama.cpp の CPU-only は思った以上に実用的
Intel iGPU の KVM パススルーはかなり大変
さらに llama.cpp も SYCL backend でビルドし直す必要がある
苦労して動かしたが、今回の条件では CPUの方が速かった

つまり、現時点での自分の結論は、

自宅サーバ監視LLMなら、まずは CPU-only の llama.cpp VM を第一候補にするのがよい

というものです。