なぜiGPUはホームサーバーアプリとメモリを競合するのですか？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Why Does an iGPU Compete With Home Server Apps for Memory?

iGPUは、グラフィックス、メディア、AIのワークロードがCPUと同じシステムメモリの容量と帯域幅を使用するため、ホームサーバーアプリと競合します。

この競合は見落としがちです。なぜなら、グラフィックスエンジンは監視ツールで別のデバイスとして表示されるものの、ほとんどの統合GPUは大きな専用VRAMプールを持っていないからです。コンテナ、データベース、ファイルシステムキャッシュ、仮想マシン、モデルランタイム、そしてiGPUはすべて、同じ搭載DRAMとメモリコントローラーに依存しています。以下のセクションでは、予約済みメモリと動的使用を分けて説明し、フレームサーフェスやAIバッファが作業セットをどのように拡大するかを解説し、サーバーに空きRAMがあっても共有帯域幅の圧力で遅くなる理由を示します。

統合グラフィックスはシステムメモリプールを使用する

ディスクリートGPUは通常独自のVRAMを持ちますが、統合GPUはプロセッサやシステムパッケージに組み込まれており、プラットフォームのメインメモリにアクセスします。CPUとグラフィックスエンジンは別々の実行リソースですが、アクティブなデータは最終的に同じ物理DRAMシステムを占有します。

Intelは統合グラフィックスメモリが専用のメモリバンクではなくシステムRAMから供給されると説明しています。つまり、デコードされたフレーム、AIテンソル、デスクトップサーフェス、グラフィックスバッファは、アプリケーションページ、データベースキャッシュ、ファイルシステムデータを保持できる容量を消費します。

結果として、GPUがWindowsやLinuxが利用可能と報告するすべてのグラフィックスメモリを永久に所有するわけではありません。実際の使用量はワークロード、ドライバポリシー、ファームウェア設定、アプリケーションが現在マップしているバッファによって変化します。

報告される共有メモリは上限であり、固定予約ではない

OSはしばしば大きな「共有GPUメモリ」数値を表示しますが、これはすでにサーバーから消えたRAMと誤解されがちです。多くの実装では、この値は上限や会計上のカテゴリであり、常に保持される固定割り当てではありません。

IntelのグラフィックスメモリFAQは共有システムメモリは継続的な予約ではないと述べています。グラフィックスドライバとOSは現在のCPUとGPUのワークロードに応じてメモリを割り当てます。

この違いは容量計画時に重要です。アイドル状態のダッシュボードはほとんどのRAMが空いているように見えますが、トランスコード、ビジョンモデル、複数のリモートデスクトップが大きなサーフェスを素早く割り当て、コンテナに利用可能な余裕を減らすことがあります。

ファームウェア予約メモリは異なります。BIOSやUEFI設定でOS起動前に小さな固定グラフィックス領域を予約することがあり、その部分はiGPUがアイドルでも通常のアプリケーションからは使用できません。

フレームサーフェスはデコード、処理、エンコード中に拡大する

ハードウェアトランスコーディングは圧縮された入力と出力だけをメモリに保持するわけではありません。パイプラインはデコードされたフレームサーフェス、参照フレーム、スケーリングやトーンマッピングバッファ、非同期デコードとエンコード段階を維持するための十分なキューイングされたサーフェスも必要とします。

Intel oneVPLはデコーダーサーフェスプールを説明しており、アクティブなビデオコンポーネントに十分なフレームサーフェスを含める必要があります。解像度、ビット深度、クロマフォーマット、参照フレーム数、フィルター、同時ストリーム数が作業メモリ量を変化させます。

単一の4Kフレームサーフェスは、それを生成した圧縮パケットよりはるかに大きいです。複数の同時トランスコードは、メディアファイル自体がディスク上にあってもグラフィックスで見えるメモリ使用量を増加させる可能性があります。

固定機能のメディアエンジンはCPUの演算負荷を減らしますが、これらのフレームを共有メモリ階層で保存・移動する必要はなくなりません。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

容量圧力はアプリをリクレームやスワップに追い込むことがある

iGPUの割り当てとアプリケーションの作業セットが搭載RAMに近づくと、OSはクリーンなキャッシュページのリクレーム、メモリ圧縮、アプリケーションページの追い出し、スワップへのデータ移動を行います。最初に目に見える遅延はGPUタスクではなく、無関係なデータベースやウェブアプリで現れることがあります。

Intelの最新のメモリバランス制御は、グラフィックスメモリ需要が高いアプリとCPUメモリ需要が高いアプリのトレードオフを明確に示しています。グラフィックスの上限を上げるとあるワークロードには有利ですが、システム全体の保護は減少します。

ファイルシステムキャッシュはしばしば静かな犠牲者です。ホームサーバーはコンテナ用に十分な匿名メモリを保持しつつも、頻繁に読み込まれるメディアメタデータ、サムネイル、データベースページ、ディレクトリエントリを追い出し、ドライブの利用率が変わらなくてもストレージが遅く感じられることがあります。

帯域幅競合はRAM容量が満杯になる前に現れることがある

空き容量はどれだけのデータがさらに収まるかを示しますが、CPUとiGPUが既に使用中のデータをどれだけ速く移動できるかは示しません。両エンジンは同時にDRAM帯域幅を要求できます。

IntelのGPU最適化ガイドはCPUと統合GPU間の共有DRAMトラフィックを説明しています。ZimaSpaceのメモリ帯域幅制限の解説は、AIデコード、ビデオフレーム、アプリケーションキャッシュ、CPU作業がメモリ容量が枯渇したとタスクマネージャーが報告する前に互いに遅くなる理由を示しています。

これにより特徴的な症状が生まれます。GPUやCPUの使用率は100％未満のままでも、メモリチャネル、データレート、コピー動作、同時ワークロードによってスループットが大きく変化します。

容量と帯域幅は別々の制限として測定する

サーバーを段階的にテストします：アプリケーション単独、iGPUワークロード単独、両方同時。利用可能メモリ、コミット済みメモリ、スワップ活動、ファイルシステムキャッシュ、メモリ帯域幅、iGPUエンジン使用率、重要なアプリケーション応答時間を記録します。

WindowsはGPUメモリセグメントを公開し、Linuxツールはドライバに応じてグラフィックスエンジンとシステムメモリの活動を表示できます。重要なのは報告される「VRAM」数値ではなく、iGPUタスク開始時に全メモリシステムがどのように変化するかの比較です。

スワップや積極的なキャッシュリクレームが現れたら、RAMを増設するか、同時サーフェス数を減らすか、アプリケーションの作業セットを縮小するか、アクセラレータワークロードを分離してください。容量に余裕があるのにCPUとiGPUのスループットが共に低下する場合は、チャネル構成を改善し、コピーを減らすか、専用メモリを持つデバイスにワークロードを移してください。