LLMのメモリ帯域幅 vs 演算性能：速度のボトルネックを見つける方法

LLMはモデルに保存された重みを使って次のトークンを計算します。1人への回答では、前のトークンが決まってから次を生成します。その間、必要な重みをメモリから繰り返し取得します。演算装置がデータを待っているなら、演算ユニットを増やす前にその待ち時間を短くする必要があります。

ここでは容量と帯域幅の役割が異なります。モデルとKVキャッシュ⁷を置くには十分な容量が必要で、計算用のデータを速く供給するには帯域幅が必要です。モデルが収まっているのに回答が遅い場合は、容量を増やすだけでなく、実際のデコード速度とデータの供給経路を調べると役立ちます。

1トークンの計算に必要な重みが20GBで、実際の転送速度が400GB/sだと仮定します。読む時間は20÷400=0.05秒です。1秒間に繰り返すと1÷0.05=20回になります。読む量が減るか転送が速くなると、同じデータを待つ時間が短くなる仕組みです。

この例で計算したのは重みを読む時間だけです。実際のtok/sには演算、KVキャッシュへのアクセス、実行プログラムの処理時間も含まれます。仕様上の最大帯域幅ではなく実際の転送速度を仮定しており、MoE⁸のように一部の重みを選ぶ構造では読み込む量も変わります。式は帯域幅の役割を理解するために使い、機器の速度は同じモデルの実行結果で比較しましょう。

文書を受け取ると、モデルは回答の前に入力トークンを処理します。プリフィルではすでに与えられたトークンをまとめて計算でき、演算装置を広く活用できます。長い契約書を送ってから最初の返答まで時間がかかるなら、プリフィルの処理量と最初のトークンまでの遅延を比較しましょう。

複数の利用者のリクエストをまとめるバッチ処理でも、同じ重みを複数の計算に使えます。サーバー全体のトークン処理量が増える一方、個々のリクエストは待ち行列で待つ場合があります。個人のチャットでは1つの回答の速度を、共同サーバーでは個別の遅延と全体の処理量を合わせて確認しましょう。

量子化⁹は重みを少ないビットで保存し、読む量を減らせます。その表現を効率よく計算するカーネルがあれば、容量と速度の両方に役立ちます。同じ元モデルでも、形式と実行プログラムを記録して、どの組み合わせで時間が短くなったか確認できるようにしましょう。

会話が長くなると、以前の文脈を保持するKVキャッシュも大きくなります。生成中にキャッシュを参照する負担が増え、短い質問と長い文書で速度が変わることがあります。入力の長さを固定し、出力トークン数も記録すると、作業量の変化による差を減らせます。

まずモデルと実際の文脈がメモリに収まるか確認します。その後、同じ文書と質問で、最初のトークンまでの時間、生成速度、完了までの時間を記録してください。3つを分けると、高性能な機器が作業のどの部分を短縮するのか判断しやすくなります。