オープンソースの大規模言語モデル推論フレームワーク「llama.cpp」において、RPC（リモートプロシージャコール）を用いた分散処理時に、ローカルの統合GPU（iGPU）が認識されなくなる問題が修正された。とくにAMDのStrix Haloのように、128GBのユニファイドメモリを備え統合GPUが主力演算装置となるシステムで、モデル読み込みが完全に失敗する事態を解消する。

この記事を一言でいうと

RPC接続されたリモートデバイスがあるだけで、搭載している統合GPUが無視され、モデルの読み込みに失敗するというllama.cppのバグが修正された。大容量ユニファイドメモリを活用する新型PCにとっては死活問題となる修正だ。

なぜ話題なのか

AIのローカル推論では、複数マシンをRPCで束ねて大規模モデルを動かす手法が普及しつつある。llama.cppもRPC機能を備え、ネットワーク越しにGPUリソースを追加できる。ところが先日、統合GPUの分類方法を変更した際、RPCデバイスが1台でも登録されるとローカルの統合GPUを「スキップ」してしまうロジックが混入した。

これが深刻なのは、AMD Strix Haloのように「統合GPUこそがメインの演算装置であり、システムメモリと統合された大容量のユニファイドメモリを売りにする」プラットフォームにおいて、ローカルGPUが存在しないものとして扱われてしまうからだ。結果として、すべてのテンソルがRPC接続先のリモートデバイスに割り振られ、メモリ不足などでモデル読み込みに失敗していた。

一般読者や企業にどう関係するのか

AIを自社のパソコンやサーバーで動かしたい企業、とりわけデータの機密性を重視しクラウドに送れないユースケースでは、統合GPUの大容量ユニファイドメモリは大きな魅力だ。Strix Haloのような128GBの統合メモリ環境は、パラメータ数の大きいモデルでもGPUメモリ不足に陥りにくい。

このバグ修正により、ローカルの大容量iGPUとRPC経由のリモートGPUを組み合わせて、より大きなモデルや高速な推論を実現する構成が正常動作するようになる。日本国内でもエッジAIやオンデバイス推論に関心を持つ製造業・医療機関・研究機関にとって、安定した推論環境整備に貢献する修正といえる。

AI業界の構造で見ると何が変わるのか

この修正が示唆するのは、AI推論の「分散化」が一段と進むという構造変化だ。推論の実行場所が、クラウドの単一GPUから、ローカルGPU、統合GPU、そしてRPCで接続された複数ノードへと分散する流れが加速している。

llama.cppのようなオープンソース推論フレームワークは、こうした分散環境をソフトウェア面で支える基盤となる。GPUベンダーもNVIDIA、AMD、Intel、Apple Siliconと多様化しており、デバイスの種類を正しく認識し適切に負荷分散する「スケジューラ」の重要性が増している。今回のバグは、まさにそのスケジューラ部分で生じた問題であり、マルチベンダー・マルチデバイス時代のソフトウェア開発の複雑さを浮き彫りにした。

一次情報から確認できる事実

  • llama.cppのプルリクエスト#23868において、RPCデバイス追加時にローカルのiGPUが除外されるバグが報告された
  • 原因は先行する変更#23007で統合CUDA/HIPデバイスをIGPUとして再分類した後、RPCデバイスによってmodel->devicesが空でなくなり、iGPUの選択ロジックがスキップされるようになったこと
  • Strix Halo（128GBユニファイドメモリ搭載環境）では、iGPUが主計算デバイスであるにもかかわらず、すべてのテンソルがRPCピアのみに割り当てられ、モデル読み込みに失敗した
  • 修正ではiGPUの組み込み条件をgpus.empty()に変更し、RPCピアの存在がローカルiGPUを抑制しないようにした
  • この修正によりissue #23858がクローズされた

関連企業・関連技術

  • AMD: Strix Halo（Ryzen AI Maxシリーズ）は、統合GPUに大容量ユニファイドメモリを組み合わせる新アーキテクチャ
  • llama.cpp: MetaのLLaMAモデルを中心に、多様なハードウェアで効率的な推論を実現するオープンソースのC++実装
  • NVIDIA / Intel / Apple: それぞれ統合GPUやディスクリートGPU、独自のユニファイドメモリアーキテクチャを持ち、マルチデバイス推論の対象となる
  • RPC（gRPC）: ネットワーク越しにGPUリソースを共有し、複数マシンでの推論を可能にする技術

今後の論点

  • RPCを含むマルチデバイス環境での負荷分散ロジックは、他のフレームワーク（vLLM、TensorRT-LLMなど）でも同様の課題を抱える可能性がある
  • 大容量ユニファイドメモリを備えた次世代SoC（Snapdragon X Elite、Apple Mシリーズ次世代など）が普及するにつれ、推論フレームワーク側の対応成熟度が競争軸となる
  • オープンソース推論エコシステム全体で、デバイス種別の認識とスケジューリングを標準化する動きがあるか、引き続き注視する必要がある