llama.cpp b10472、AMD APUのメモリ判定を修正し、Strix Haloに存在しない空き容量が割り当てられる問題を回避

llama.cppは8月17日にb10472をリリースし、Linux上のAMD APUにおける統合メモリの判定を修正した。以前、NVIDIA DGX Sparkをサポートするために追加されたUMAロジックでは、OSの`MemAvailable`をアクセラレーターが利用できる容量として扱っていた。しかし、この近似値はStrix HaloなどのAMD APUでは信頼できない。BIOSにより統合メモリをシステムRAMとVRAMの異なるcarveoutに分割できるため、Linuxで利用可能なメインメモリは、HIPランタイムが実際に割り当て可能なグラフィックスメモリと一致しないからだ。

b10472では、HIPビルド時にこの上書きをスキップし、AMD APUが引き続き`hipMemGetInfo`から報告されるfree／total値を使用するようにした。この変更はベンチマーク性能の最適化ではなく、リソーススケジューリングの正確性を高めるものだ。llama.cppは利用可能な容量に基づいて、テンソルのオフロード、モデルをGPUに格納できるかどうか、KV cacheおよびバッチ設定を決定する。容量が過大評価されると、サービスが大きすぎるモデルやコンテキストをいったん受け入れた後、割り当て段階でOOMに陥る可能性がある。特に、小さなcarveout、コンテナ化されたデプロイ、高い共有メモリ負荷を抱えるシステムで発生しやすい。

マージ時の議論では、Strix HaloはBIOS設定によってシステムRAMが約32GBしか残らず、残りがGPUに割り当てられる場合があると指摘された。`/proc/meminfo`だけを参照しても、この境界を再現することはできない。エンジニアリングチームはアップグレード後、起動時のHIP free／total、実際にオフロード可能なレイヤー数、最大KV cacheを改めて記録すべきであり、この修正を利用可能なメモリが突然増えたものと解釈してはならない。この変更で明示的に対象となるのはLinux HIPパスのみで、メンテナーはWindowsのROCmではメモリ報告メカニズムが異なることを確認している。また、このバージョンではスループットやOOM発生率の比較データは提供されていないため、今後も異なるBIOS carveout、カーネル、ROCmバージョンで検証する必要がある。