なぜメモリ帯域幅がホームサーバーでのAIやトランスコーディングを遅くするのか？

プロセッサやグラフィックスエンジンが作業準備ができていても、重み、活性化、またはビデオフレームを十分速く受け取れない場合、メモリ帯域幅がAIやトランスコーディングの速度を遅くします。より多くのCPUコアはそのボトルネックを解消しません。むしろ同じメモリチャネルを待つ実行ユニットの数を増やすだけです。

この効果は条件付きです。小バッチサイズの自己回帰型LLMデコードは頻繁にメモリ制約ですが、プロンプト処理は計算制約であることがあります。ビデオトランスコーディングは、コーデックエンジン、CPUフィルター、メモリトラフィック、または出力エンコードによって制限されることがあります。正しい説明は、どの段階が有用な計算に対して最も多くのデータを移動するかによります。

データ移動が計算を上回るとメモリ帯域幅が制限となる

プロセッサは、命令とデータが十分に速く到着して実行資源を占有し続ける場合にのみピークの算術性能に達します。算術強度の低いワークロードは、メモリから移動されるバイトごとに比較的少ない計算しか行いません。その性能は、CPUやGPUが公称の計算上限に達する前に帯域幅の上限に近づきます。

Rooflineモデルは、バイトあたりの演算数をピークの計算能力とメモリ帯域幅と比較することでこの境界を表現します。研究調査LLM Inference Unveiledは、このモデルを用いて、いくつかの推論層が計算ユニットを十分に活用できていないのは、算術能力ではなくメモリアクセスが制約資源であるためであることを示しています。

自己回帰型LLMデコードはモデルデータを繰り返しストリームします

LLM推論には少なくとも二つの性能領域があります。プリフィル中は、サーバーが入力プロンプトを処理し、キー・バリューキャッシュを構築します。デコード中は、モデルの重みと拡大するKVキャッシュに繰り返しアクセスしながら、一度に一つのトークンを生成します。低バッチのデコードでは、同時トークン間で読み込まれた重みの再利用が限られることが多いです。

引用されたRoofline研究では、Llama-2-7Bの例がプリフィル時には主に計算制約である一方、解析されたデコード操作全体ではメモリ制約であることが示されています。これは有用なホームサーバーの解釈を支持します：追加のCPUコアがほとんど改善をもたらさなくても、持続的なメモリ帯域幅によりデコード速度は向上する可能性があります。大まかな上限は、生成される各トークンの読み取りに必要なバイト数で割った使用可能な帯域幅ですが、実際の性能にはキャッシュの挙動、カーネル、量子化のオーバーヘッド、CPUのベクトルサポートも含まれます。

量子化はメモリトラフィックと計算の両方を変化させます

量子化は重みや場合によっては活性化やKVキャッシュデータを低精度で格納します。パラメータあたりのバイト数が減ることで、モデルのメモリフットプリントとそれらの値を移動するためのトラフィックが削減されます。デコードがメモリ制約のままであれば、その削減はトークン生成速度を向上させるだけでなく、より大きなモデルを収めることも可能にします。

これは普遍的な帯域幅の乗数ではありません。逆量子化や低ビットカーネルは独自の計算を追加し、ワークロードはRooflineモデルのメモリ制約側から計算制約側に移行することがあります。同じ研究では、量子化はメモリ制約領域で理論的な性能を向上させますが、すでに計算制約にある操作では速度向上がほとんどない可能性があると報告しています。モデルの品質とバックエンドのサポートは別の制約です。

ビデオトランスコーディングは複数の異なる段階でフレームを移動させます

トランスコーディングは単一の操作ではありません。サーバーは圧縮された入力を読み込み、フレーム表面にデコードし、スケーリング、トーンマッピング、インターレース解除、字幕の焼き込み、ピクセルフォーマットの変更を行い、新しいストリームをエンコードします。IntelのoneVPLドキュメントでは、エンコード、デコード、ビデオ処理が明確に区別されています。

これらの段階は異なるリソースプロファイルを持っています。ソフトウェアエンコーダーは計算負荷が高い場合があり、高解像度のスケーリングやフォーマット変換の段階では大きなフレーム表面がメモリを通過します。字幕のレンダリングやHDRトーンマッピングは処理経路をさらに変えることがあります。これが、サーバーが複数のダイレクトプレイストリームを処理できても、1つの複雑なトランスコードで苦戦する理由です。ダイレクトプレイは既存の圧縮ストリームを送信し、ほとんどのフレーム処理作業を回避します。

ハードウェアメディアエンジンはCPUの負荷を軽減しますが、フレームデータの交換は依然として行われます

固定機能のメディアブロックは、サポートされているコーデックをデコードおよびエンコードでき、すべての操作を汎用CPUコアに依頼する必要はありません。これによりボトルネックはCPUの計算から離れますが、フレームや中間サーフェスはアクセス可能なメモリに常駐し、パイプラインの各段階間で渡される必要があります。

Intelのプラットフォーム仕様では、ハードウェアトランスコーディングをデコード、オプションのビデオ処理、エンコードとして説明し、対応解像度はメモリ帯域幅の利用可能性に依存すると記載しています。これはすべてのハードウェアトランスコードがRAMを飽和させるわけではありません。コーデックのサポート、メディアエンジンの容量、コピー動作、フィルター、解像度、ビット深度、ストリーム数がメモリトラフィックの可視化を決定します。

統合グラフィックスとCPUは同じシステムメモリを共有します

ディスクリートGPUは通常、独自のローカルメモリサブシステムを持ちます。一方、統合グラフィックスはCPUと共有するシステムメモリを使用します。Intelの統合グラフィックスとディスクリートグラフィックスの説明は、この共有メモリの違いを直接示しています。

コンパクトなホームサーバーでは、iGPUのトランスコード、CPUベースのLLM推論、コンテナ、ファイルシステムキャッシュ、通常のアプリケーション作業が同じメモリコントローラーを共有します。共有容量が必ずしも全帯域幅の競合を意味するわけではありませんが、同時トラフィックは一方のワークロードが他方の利用可能な帯域幅を減らす可能性を高めます。シングルチャネルのメモリ構成は、正しく構成されたマルチチャネル構成よりもその境界が早く現れることがあります。

メモリ容量、帯域幅、レイテンシ、および計算能力は異なる制限を生み出します

複数のボトルネックはしばしば「RAM不足」と表現されますが、それぞれ異なる解釈が必要です。容量は作業セットが収まるかを決定し、帯域幅は持続的なデータ移動を制御し、レイテンシは個々のアクセスが完了する速さに影響し、計算能力は読み込まれたデータをどれだけ速く処理できるかを決定します。

ストレージ速度も別の境界です。SSDからモデルを読み込むことが起動時間を支配することがあり、モデルがメモリに常駐した後のトークン生成はメモリと計算に依存します。同様に、メディアファイルの読み込みはトランスコードパイプラインがメモリ制限されていなくてもストレージ制限になることがあります。起動、定常状態の処理、出力配信を「RAM速度」の1つの結果にまとめてはいけません。

同時実行性は共有帯域幅の圧力を見やすくします。

1つのAIリクエストや1つのビデオストリームでは、かなりの帯域幅が未使用のままになることがあります。複数のLLMセッションは重みとKVキャッシュのトラフィックを増やし、複数のトランスコードはフレームサーフェスとコーデックエンジンの作業を増やします。両方のワークロードを同時に実行すると、それぞれが単独で許容範囲内で動作していても競合が発生する可能性があります。

同時実行性はすべての要求を線形にスケールしません。AIリクエストをバッチ処理することで、より多くの作業に対して重みを再利用し、算術強度を高め、総合スループットを向上させつつ、リクエストごとのレイテンシを変化させます。ビデオエンジンも、コーデック、解像度、セッション、メモリの境界に達するまで複数のストリームを効率的に処理する場合があります。したがって、単一ワークロードのベンチマークは単純な加算で混合ホームサーバーワークロードを予測できません。

RAM速度を責める前にアクティブパイプラインを測定してください。

観察可能な段階から始めます。ローカルAIの場合、モデルの読み込み、プロンプトの事前入力、最初のトークンまでの時間、1秒あたりのデコードトークン数、同時リクエストのスループットを分けて評価します。メディアの場合は、直接再生、ソフトウェアトランスコーディング、ハードウェアデコード、フィルター、ハードウェアエンコード、ネットワーク配信を分けて評価します。

• メモリが意図したチャネル構成で動作していることを確認してください。
• 測定された帯域幅を、プラットフォームの持続可能な上限と比較してください。広告されている上限ではありません。
• CPU、統合GPU、デコーダー、エンコーダー、メモリの活動を一緒に観察してください。
• ローカルLLM推論のためにプリフィルとデコードを別々にテストしてください。
• 異なるメディアパスとして、ダイレクトプレイ、基本的なトランスコード、フィルター多用のトランスコードをテストしてください。
• 現実的なAIセッションとメディアストリームを同時に実行して測定を繰り返してください。

RAMのデータレートが高いことは、ワークロードが実際にメモリトラフィックで制限されていて、CPU、マザーボード、メモリチャネル、ファームウェアがそれを利用できる場合にのみ役立ちます。メディアとローカルAIを同じマシンに置くべきか判断する読者は、このPlexとローカルAIのワークロード配置に関する記事を補足的なアーキテクチャの参考にできます。

よくある質問

RAMを増やすとメモリ帯域幅は増えるか？

容量が増えても帯域幅が自動的に増えるわけではありません。帯域幅はメモリのデータレート、バス幅、アクティブチャネル数、メモリコントローラー、プラットフォーム構成に依存します。モジュールを追加してサポートされている別のチャネルが有効になる場合は帯域幅が増えますが、すでにバランスの取れた構成に容量を追加しても増えないことがあります。

LLM推論は常にメモリ帯域幅に制限されるのか？

いいえ。低バッチの自己回帰デコードはしばしばメモリ制限ですが、プリフィル、大きなバッチ、特定のカーネル、一部の量子化操作は計算制限になることがあります。モデルのアーキテクチャ、コンテキスト長、バックエンド、キャッシュの挙動、ハードウェアがバランスを変えます。

ハードウェアトランスコーディングはシステムメモリのトラフィックをなくすか？

いいえ。固定機能ブロックは一般的なCPUの作業を減らしますが、圧縮データ、デコードされたフレーム、処理されたサーフェス、エンコードされた出力は依然としてメモリ階層を通過します。そのトラフィックが性能を制限するかは、ストリーム数、解像度、フィルター、コピー、コーデックのサポート、グラフィックスエンジンがシステムRAMを共有しているかどうかによります。

なぜホームサーバーは空きRAMがあっても帯域幅制限を受けるのか？

空き容量はより多くのデータが収まることを示しますが、データの転送速度を示すものではありません。ワークロードはインストールされたRAMの一部しか使用しなくても、そのデータを繰り返し高速にストリーミングして利用可能なメモリチャネルを飽和させることがあります。