応答速度と加速

LLMのメモリ帯域幅と演算性能、どちらが効くのか

GPUのAI演算性能ははるかに高いものの、ローカルモデルはそれほど速くはなりません。スペック表を誤解したのでしょうか？計算準備が整っても、モデルの重みが到着するのを待つ必要があります。「どのくらい計算するか」と「どのくらい速く取得するか」を比較すれば、この差が分かります。

演算を始める前にも、待ち時間がある

モデルは多くの重みを読み、次のトークンを生成します。1人のユーザーがトークンを1つずつ受ける場合、計算装置がメモリから処理するデータを取得する操作が速度を制限する可能性があります。1秒あたり取得できるデータの量がメモリ帯域幅です。

同様の理由で、メモリ容量と帯域幅を区別して扱う必要があります。容量が大きいほどモデルを収容しやすくなりますが、その重みを読み取る速度がそれに比例して大きくなるとは限りません。大きなモデルが実行されるという利点と、回答が速いという利点は別々に確認する必要があります。

1トークンの出力を作成するたびに、モデルの重みがメモリから計算デバイスへと流れている図 — 単一ユーザーデコードは同じ重みを繰り返し読み取るため、メモリ帯域幅の影響を大きく受ける。

数値で感を掴んでみましょう

重み20GBをトークンごとに1回読み、帯域幅が400GB/sであると仮定すると、読み取りだけでは約0.05秒かかります。その逆数は約20回/秒になります。これは実際の製品の測定値ではなく、帯域幅が制約をもたらす理由を示す仮想的な計算です。

ここでは計算・キャッシュアクセス・プログラムコストが抜けており、MoEのようにすべての重みを毎回使用しない構造も存在します。したがって、この式で実際のtok/sを確定することはできません。理論帯域幅をそのまま購入性能として約束するのは避けるべきです。

広い計算格子内で多くの入力トークンを一括で処理するプリフィル行列計算図 — プリフィルは入力トークンを並列に処理するため、長い入力では演算装置の計算能力をより積極的に活用できます。

長い文書では、計算の進め方が変わる

プリフィルでは複数の入力トークンを同時に処理できます。単一トークンを順に生成する場合よりも、計算をまとめてGPUリソースを活用する可能性があります。この場合、演算パフォーマンスの差がより明らかになります。

複数のリクエストをバッチで処理するサーバーにも条件が異なります。したがって、短い会話では似た設備が、長いドキュメント処理では差が現れる可能性があります。TOPSまたはメモリ帯域幅をすべてのタスクの代表的なスコアとして使うのは難しいです。

メモリ運搬装置と計算装置のどちらが遅い側が全体の速度を制限するボトルネックの図 — 実際の速度は、メモリ供給と計算処理のどちらかがまず制限に達した側で決まるため、TOPSだけでは比較できません。

量子化すると読み込む量は減ります

重みを低いビットで保存することで、メモリを移動する量は減る可能性があります。しかし、圧縮された表現を計算に使う処理やカーネルの効率にも影響を与えます。ファイルが半分になったため、速度が2倍になるという計算で終わらせるのはできません。

メーカーの理論スペックと実際の利用率は異なります。モデル構造・実行プログラム・量子化形式・冷却条件が変われば、同じ設備でも結果が異なります。スペック表は候補を理解する出発点であり、同じ条件での実行結果が次の確認データになります。

どの数字を最初に見るかを決める

Chunkが多数の場合には、ロード可能かどうかの後にデコードを確認します。長いドキュメントを読み込めるか、複数のリクエストを処理できるかについては、プリフィルと処理量も別途確認する必要があります。加速機能を有効にした記録と基本記録を混同しないことも重要です。

GPUが高価であるにもかかわらず、期待よりも速く動作しなかった場合、より高いグレードを検討する前に、どこで待っているかを確認してください。必要なのは、より多くのメモリであったり、より優れた実行経路であったりする可能性があります。ボトルネックが見つかった場合、スペック表で次に確認すべき項目が変わります。