自宅サーバのログ監視を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 を第一候補にするのがよい
というものです。