llama.cpp b9145とは、SYCLバックエンドのメモリ二重消費を解消した修正リリース。
Intel Arc GPUでローカルLLMを動かすと、VRAMに余裕があるはずなのにシステムRAMが先に枯渇してOOMで落ちる。この奇妙な現象に2026年5月14日、ggml-org/llama.cppリリース「b9145」が手を入れた。SYCLバックエンドでのメモリ確保をLevel Zero API経由に切り替えることで、システムRAM消費を約9分の1に圧縮した修正です。
公式コミット記述（PR #21597）によれば、dual Intel Arc Pro B70構成で15.6 GiBのモデルを動かしたとき、これまではシステムRAMが60 GiBまで膨らんでクラッシュしていた。同じワークロードがLevel Zero経路では約6.7 GiB止まり。ローカルでマルチGPU構成を組むユーザーにとって、この差は致命的か実用的かを分ける境界線になります。
- SYCLバックエンドの sycl::malloc_device は xe kernel driver の DMA-buf/TTM 経路を通り、VRAM確保時に同サイズのシステムRAMを必ず確保していた
- b9145ではzeMemAllocDevice（Level Zero API）に置換し、SVM/P2P経路でhost stagingを省略。15.6 GiBモデルで60 GiB→6.7 GiBへ約9分の1に削減
- Level Zero SDKが無い環境でも自動でSYCL経路にfallbackする安全設計。LinuxとWindows双方でビルド可能
SYCL バックエンドで起きていた「メモリ二重消費」 現象とは
Intel ArcシリーズでローカルLLMを動かす際、これまでのllama.cpp SYCLバックエンドには見過ごせない挙動がありました。GPU側に十分なVRAMを積んでいても、モデルロードと同時にシステムRAMが急速に消費される。dual Intel Arc Pro B70環境では、15.6 GiBのモデルを読み込んだだけでシステムRAMが60 GiBに到達し、OOMキラーが走る。公式コミット記述（ggml-org/llama.cpp PR #21597）に明示された実例です。
VRAM とシステムRAM が 1:1 でミラーされる仕組み
原因は sycl::malloc_device の内部経路にあった。Intel SYCLランタイムは、デバイスメモリ確保時にLinux側のxe kernel driverを呼び出す。このとき経由するのが DMA-buf と TTM（Translation Table Maps）と呼ばれる仕組み。本来はGPU↔CPU間のバッファ共有とアドレス変換を担う共通インフラで、ディスプレイ出力や動画再生では合理的に機能します。
ところがLLM推論のような大きなVRAMブロックを長時間保持するワークロードでは、この経路が裏目に出る。xeドライバはDMA-buf経由で確保された各VRAM領域に対し、システムRAM側にも同サイズのバッキングストアを確保してミラー保持する設計になっています。たとえばVRAMに10 GiBを確保すると、システムRAMにも10 GiB分のページが予約される。読み書きが発生しないただの「保険」用領域ですが、物理メモリは実際に使われた状態として計上される仕組み。
ゲームや映像処理のように一時的なバッファであれば問題は表面化しない。ただローカルLLM運用では、量子化済みのモデル重み全体をGPUに常駐させ続けるため、ミラー領域も同じ時間だけ抱え込むことになる。これが「VRAMには余裕があるのにシステムRAMが枯渇する」 直感に反する現象の正体でした。
15.6 GiB モデルで 60 GiB のシステムRAM が消費された実例
公式コミット記述に記載された再現条件は明確。dual Intel Arc Pro B70という、VRAM・システムRAMともに大容量を備えたワークステーション構成で、15.6 GiB規模のモデルを単発でロードしたケースが対象です。
このとき消費されたシステムRAMは60 GiB。モデル本体の約4倍に達した計算になります。なぜ4倍なのかは、dual GPU構成によりVRAM側で同モデルが各GPUへ分散・複製される過程、加えてアロケータが内部で予約するパディング領域などが重なった結果と読み取れる。一方で素直な「VRAM:システムRAM=1:1」 という公式コミット記述の表現どおり、各GPU上のVRAMアロケーションが個別にDMA-buf経由でシステムRAMにマップされた合算とみるのが自然でしょう。
結果としてシステムRAMの実効空きが急速に枯渇し、推論プロセスがOOMキラーで終了する。Intel Arc Pro B70構成は本来であれば14B〜34BクラスのLLMを快適に動かせるはずのスペック帯ですが、ソフトウェア層のメモリ管理がボトルネックとなり、ハードウェア性能を引き出せていなかった構図。b9145はまさにこの「VRAMの余裕がシステムRAMの逼迫に化ける」 構造をAPIレベルで断ち切るための修正です。
Level Zero API への置換で何が変わったか
修正の本丸は、デバイスメモリ確保の呼び出しを sycl::malloc_device から zeMemAllocDevice へ置き換えた点。zeMemAllocDevice はoneAPI Level Zero仕様で定義された低レベルAPIで、SYCLよりも一段下のレイヤーでデバイスを直接扱います。
SVM/P2P 経路と host staging の違い
Level Zero経路の本質は、SVM（Shared Virtual Memory）とP2P（Peer-to-Peer）アクセスをGPUドライバの一階層下から取り扱える点にあります。SVMはGPUとCPUが同じ仮想アドレス空間を共有し、物理メモリの場所を意識せずポインタを渡し合える仕組み。P2PはGPU同士が中央CPUを介さずに直接データを転送する経路。両者を組み合わせると、デバイスメモリ確保時にCPU側で「念のためのコピー領域」を抱える必要が消えます。
これに対し DMA-buf/TTM 経路はそもそも「ホスト側にステージング領域を持つ」 ことを前提とした設計。GPU・CPU間のメモリ転送をどちらからでも開始できるよう、システムRAMにバッキングを常駐させておくのが標準動作でした。Host stagingという呼び方が示すとおり、ホスト側がI/Oの中継地点として常に介在する形。LLM推論のようにGPU内部で完結する処理が大半を占めるワークロードでは、この中継領域がほぼ使われないまま物理メモリを占有し続けることになる。
b9145ではこの中継経路を丸ごとバイパスする選択肢を導入した。GPUのVRAMに置かれたモデル重みは、推論カーネルからGPU内で直接アクセスされる。CPU側からのアクセスが必要になった場合のみ、SVMの仕組みでオンデマンドにメモリ転送が起きる。結果としてシステムRAM側に確保される領域は、純粋に「実際にCPUが読み書きするバッファ」 だけに絞り込まれます。
メモリ削減量と性能インパクト
dual Intel Arc Pro B70 構成で 15.6 GiB モデルをロードした際、sycl::malloc_device 経路ではシステムRAMが 60 GiB まで増大しOOMが発生。zeMemAllocDevice（Level Zero API）経路では同条件で約 6.7 GiB に圧縮、パフォーマンス低下なし（no performance regression）。— ggml-org/llama.cpp PR #21597
公式コミット記述では、置換後の挙動を具体的な数値で示しています。同じ15.6 GiBモデル・同じdual Intel Arc Pro B70構成で、システムRAM消費が約6.7 GiBに圧縮された。削減率にしてざっと89%減。OOMクラッシュの発生は確認されなくなり、推論ワークロードが完走するようになりました。
特筆すべきはコミット記述に「no performance regression」 と明記されている点。メモリ確保パスを変更すると、初回ロードの遅延や推論スループットに影響が出るケースは少なくない。今回はパフォーマンス指標が悪化しなかった、と開発側が明示している。Level Zero経由でもデバイス内部のメモリ転送効率は維持され、推論カーネルから見ればVRAMアロケーションの実体は同じだった点が効いているのでしょう。
ローカル運用者の視点では、これは「メモリ容量だけで構成を決められる」 状態に近づいたことを意味する。これまで余分なシステムRAMをLLM用に積み増す必要があった環境では、その余裕分を別タスクに回せる。あるいは32 GiB前後のシステムRAMしか積めないコンパクトな筐体でも、Intel Arcマルチカード構成が実用域に入る、という見方も成立する可能性があります。
dual Intel Arc Pro B70 環境での検証結果
公式コミット記述に記された検証構成は、ローカルLLMをマルチGPUで動かそうとする層が現実的に組む規模感。dual Intel Arc Pro B70構成、VRAMとシステムRAMともに大容量を備えたワークステーション環境です。コンシューマーPCよりは一段上の規模ですが、特殊な研究機材ではなく入手可能な構成範囲でした。
テスト環境と動作モデル
検証で使われたモデルは15.6 GiB規模。具体的なモデル名は公式コミット記述に書かれていませんが、量子化済みの中〜大型LLMに相当するサイズ感です。たとえばFP16換算で7Bクラス、Q8量子化で14Bクラス、Q4量子化で30Bクラスといった見立て。dual GPUで分散ロードすることを前提にすれば、単GPUのVRAM制約を超えるサイズのモデルを動かしたい層のニーズと一致します。
検証は同じハードウェア・同じモデルで、b9145修正前後の挙動を比較する形で行われた。差分はメモリ確保APIのみという制御の効いたテストで、結果の解釈に余計な変数が混ざらない設計。
before / after 比較表（システムRAM 消費・OOM 発生有無・性能）
公式コミット記述の数値を整理すると、以下のようになります。
| 指標 | b9145以前（sycl::malloc_device） | b9145以降（zeMemAllocDevice） |
|---|---|---|
| モデルサイズ | 15.6 GiB | 15.6 GiB |
| GPU構成 | dual Intel Arc Pro B70 | dual Intel Arc Pro B70 |
| システムRAM消費 | 約60 GiB | 約6.7 GiB |
| OOMクラッシュ | 発生（推論不可） | 発生なし（完走） |
| 推論性能 | 計測不能（クラッシュ） | 性能低下なし |
| メモリ確保経路 | DMA-buf / TTM（host staging有） | SVM / P2P（host staging無） |
数字だけ見ればシステムRAM消費が9分の1。これは単なる最適化ではなく、ワークロードが「動く／動かない」 を分ける質的な差です。OOM列に注目したい。修正前はそもそも推論が完走できなかったため、性能比較が成立しない。同じハードウェアで初めて「動いた」 のがb9145以降という整理になります。
性能回帰がない点も読み取れる重要情報。メモリ確保パスを変えるとスループットが落ちる、というのはGPUプログラミングではよくある罠ですが、ここではトレードオフなしの純粋改善という形で着地した。dual Intel Arc Pro B70という構成に限らず、SYCLバックエンド経由でIntel Arc GPUを使う多くのケースで同等の効果が期待できる、と読み解けます。
zeMemAllocDevice と sycl::malloc_device の使い分け
b9145の修正は sycl::malloc_device を「全廃」 したのではなく、優先経路をLevel Zero側に切り替えた構造。実行環境がLevel Zero interopを使えないケースに備え、安全な後退経路を残してあります。
Level Zero interop が使えない場合の fallback 挙動
修正後のコードはまずLevel Zeroが利用可能かを判定する。判定材料は2点。ひとつは現在のSYCLバックエンドがLevel Zeroかどうか（ggml_sycl_is_level_zero）。もうひとつはターゲットデバイスが dGPU（discrete GPU、独立型）かどうか（ggml_sycl_is_dgpu）。両方の条件を満たす場合のみ zeMemAllocDevice を呼び、いずれかが満たされなければ従来の sycl::malloc_device に戻る。fallback時は SYCL_CHECK マクロでエラー伝搬の整合性も保たれています。
この設計が意味するところは大きい。ローカル運用者から見ると、ビルド済みバイナリを差し替えるだけで自動的に最適な経路が選ばれる。Level Zero SDKが入っていないシステムでも、ビルド設定を変えずに以前と同じバイナリが動く。動作対象のGPUが iGPU（integrated GPU、内蔵型）であれば、Level Zeroが使えてもDMA-buf経路がそのまま選ばれます。
iGPUがあえて除外されている背景には、内蔵GPUの場合は物理的にCPUとメモリを共有しているためhost stagingが本質的な機能を担っている事情がある。VRAM自体がシステムRAMの一部だからです。dGPU↔dGPU間のメモリ転送のみがLevel Zero経路で最適化される、と読めばいい。デバイス種別ガードがコード中で明示的に書かれている理由でもあります。
AMD ROCmやNVIDIA CUDAバックエンドには今回の修正は波及しません。それぞれが独自のメモリ管理機構を持っており、xe kernel driverのDMA-buf/TTM経路を経由しないためです。Intel Arc専用の最適化、という性格を踏まえれば、CUDAユーザーが乗り換えを考える必要はない。ただし、これまで「Intel ArcはVRAM以前にシステムRAMが厳しい」 と判断してNVIDIA一択にしていた層には、選択肢に再評価の余地が生まれた格好です。
Level Zero SDK 未インストール環境でのビルド方法
b9145ではビルド時の柔軟性も担保されています。Level Zero SDKが導入済みの環境では自動検出、未導入でもCMakeオプションでパスを明示できる二段構え。Windows向けには専用の検出ロジックも追加されました。
CMake オプションでの制御
ビルド設定は基本的に既存のSYCL向け手順を踏襲します。Level Zero対応のためのオプションは追加されていますが、デフォルトで自動検出が試行されるため、明示指定が必要なのはパスが特殊な場合のみ。CMake実行時にLevel Zeroライブラリとヘッダーが見つかれば、コミット記述に従い zeMemAllocDevice の呼び出しが組み込まれます。
Windows環境では、PR #21597のレビュー対応として追加された LEVEL_ZERO_V1_SDK_PATH 環境変数のサポートが効きます。Intel社が配布するLevel Zero SDKをWindowsにインストールした際の標準パス、あるいはユーザーが指定したカスタムパスを、この変数で示すと CMake が自動的にインクルードディレクトリとライブラリパスを構築する仕組み。Linux環境では一般的に pkg-config 経由で解決されるため、明示指定の出番はWindowsほど多くありません。
Level Zeroが見つからない場合、ビルド自体は通常どおり完走します。生成されるバイナリは従来のSYCL経路のみで動作し、b9145以前の挙動と一致する。SDKを後から導入してビルドし直せば、自動的にLevel Zero経路を含むバイナリに切り替わる流れ。
環境変数によるランタイム切替
ビルド時にLevel Zero対応を組み込んだバイナリでも、ランタイム挙動を環境変数で調整できる設計が組まれています。SYCLバックエンド全般の挙動を制御する ONEAPI_DEVICE_SELECTOR や、Level Zero ローダーの動作を変える ZE_AFFINITY_MASK などが従来から利用可能ですが、b9145の修正はこれらと併用できる形で実装された格好。
たとえばマルチGPU構成で特定のデバイスのみを推論に使いたい場合、ZE_AFFINITY_MASKでデバイスインデックスを絞れば、Level Zero経路の対象を限定できる。サブデバイス分割を活用するハイエンドGPUでは、より細かい単位での割り当ても可能です。
ランタイム切替が効くということは、同じバイナリのまま検証を進められるという意味でもあります。「Level Zero経路で問題が出たので一時的にSYCL経路に戻したい」 という状況が発生した場合も、環境変数や設定ファイルの調整で対応できる柔軟性。動作実績の積み上げを進める段階では、こうした逃げ道の存在が運用上の安心材料になるはず。
公式コミット記述によれば、こうした柔軟性はレビュー対応の中で意識的に組み込まれた要素。例外処理を廃止し、try/catchではなくデバイス種別チェックでガードする設計に切り替えたのも、ランタイム挙動を予測可能にするための判断と読めます。
レビューで取り込まれた品質改善
PR #21597のレビュー対応では、4点の改修が加えられました。例外処理の撤廃、デバイス種別の事前チェック、共通ヘルパーのcommon.cppへの移動、Windows用Level Zero SDKパス検出の追加です。
例外処理を廃した理由
malloc/free/memcpyのヘルパーからtry/catchを除去し、代わりにggml_sycl_is_level_zeroとggml_sycl_is_dgpuでバックエンドとデバイス種別を事前判定する形に変更。例外スローのコストを排除しつつ、ランタイム挙動の予測可能性も上がった構造。
デバイス種別ガードとコード重複排除
dev2dev_memcpyのLevel Zero経路はdGPU間転送に限定され、iGPU↔dGPUは従来通りhost staged経路を維持。is_level_zero is_dgpu free_deviceを共通化したことで、保守コストが下がった点も評価できます。
Intel Arc を使ったローカルLLM ユーザーへの実用的な意味
Arc Pro B70だけでなく、Arc Aシリーズや今後のドライバ更新を待つ層にとっても、SYCLバックエンド経由のメモリ確保戦略が変わる修正。14B〜34Bクラスのモデルを動かしたい場合、Intel Arc Pro Bが再び現実的な選択肢に戻る可能性。
NVIDIA CUDA環境を主軸とするユーザーには直接の影響はありませんが、ローカルLLMで使うベース技術のメモリ効率改善は、姉妹サイトで解説しているQwen3.6-35B-A3BのMoE型LLMのようなマルチGPU運用ニーズと方向性が一致します。Phoronixの報道では、Project Battlematrixが最大8枚のArc Pro GPU対応を視野に入れており、Ubuntu 26.04 LTS + Linux 7.0カーネルでArc Pro B70の4枚同時動作も確認済み。b9145のメモリ最適化はこのスケールアウト戦略と整合する位置付け。
よくある質問（FAQ）
Q. NVIDIA GPUユーザーには関係ある？
直接の影響はありません。本修正はSYCLバックエンド固有で、CUDA経路は別実装です。
Q. Windowsでも有効？
有効です。CMakeLists.txtに**LEVEL_ZERO_V1_SDK_PATH**でのSDKパス検出が追加され、Windows/Linux双方で利用できます。
まとめ
SYCL→Level Zero切替で、Intel Arc構成のシステムRAM二重消費が解消。Arc Pro B70の15.6 GiBモデル運用でシステムRAMが60 GiB→約6.7 GiBに圧縮された実例があり、Intel Arc利用者は最新ビルドへの更新を検討する価値があります。
当サイトはAmazonアソシエイト・プログラムの参加者です。Amazonのアソシエイトとして、当サイトは適格販売により収入を得ています。
参考資料
- ggml-org 公式: llama.cpp リポジトリ
- ggml-org 公式: llama.cpp リリースノート一覧
- oneAPI 公式: Level Zero Core API 仕様
- Intel 公式: oneAPI Level Zero 概要
- Intel 公式: Arc Pro GPU 製品ページ
