プリフィルとデコードには異なるチップが適する。経済性もそれを裏付け始めた

プリフィルは KV キャッシュを作り、デコードは各トークンを生成するため、そのキャッシュを繰り返し読みます。一方は計算能力、もう一方はメモリ帯域幅に制約されます。多くの環境では、別々の GPU に分離しても、両方のチップに同じベンダーの製品を使っています。

Gimlet Labs の分析、異なるハードウェアプラットフォーム間で LLM 推論を分割するでは、B200:Gaudi 3 という複数ベンダーの構成を評価しています。分離型の H100:H100 を基準に、プリフィル中心のワークロードで約 3 倍、デコード中心で最大 4 倍の TCO 面の利点を示しました。モデル化されたこれらのケースでは、すべて NVIDIA で構成する B200:B200 の分離型構成も上回ります。

この差は細かな調整から生まれたのではありません。推論の異なる段階に、それぞれ適したチップを割り当てた結果です。

構成

二つの段階、二つの特性：

• プリフィルはプロンプトを取り込み、KV キャッシュを構築します。計算能力が制約となり、高い FLOPS が有利です。
• デコードはそのキャッシュを繰り返し読み、トークンを生成します。メモリ帯域幅が制約となり、高い GB/s が有利です。

同じ GPU で両方を動かすと互いに干渉します。プリフィルは演算ユニットを占有し、デコードはメモリ帯域幅不足に陥ります。どちらでもチップを十分に使い切れません。

先行研究（Splitwise、DistServe）は、段階を別々の GPU に分けることで、既に 2～7 倍のスループット向上を示しています。今回の新しい問いは、二つのプールに異なるベンダーを使ってもよいのではないか、というものです。

分析で得られたパレートフロンティア：

• プリフィルの最有力は NVIDIA B200。この分析では、コスト効率のよい FP8 計算能力で最も強い選択肢です。
• デコードでは、コスト効率のよいメモリ帯域幅のパレートフロンティア上に Intel Gaudi 3、AMD MI300X、NVIDIA B200 の三つが並びます。デバイスあたり合計約 3000～4000 Gbps の帯域幅で十分なら、Gaudi 3 が最もよさそうです。

B200 でプリフィル、Gaudi 3 でデコードを行うと、プリフィル中心のワークロードで約 3 倍、デコード中心で最大 4 倍の TCO 面の利点があります。デコード中心の場合、すべて B200 の分離型構成は約 2.5 倍です。モデル化されたこれらのシナリオでは、異種構成が同種構成を上回ります。

4 倍の意味は数字以上に大きい

本番でもこのような結果が得られれば、通常の効率改善より大きな影響があります。

エージェントの可能性が広がります。多くのエージェントのワークフローは、ツール呼び出しの間で短い生成を何度も行い、デコードの比重が高くなります。デコードが安くなれば、そのコスト構造は直接改善します。

長いコンテキストの費用も正当化しやすくなります。「この 100 ページの PDF を要約する」といった仕事は、プリフィルの比重が高いため、そのコストが下がれば、大きなコンテキストウィンドウの採算がよくなります。

制御の中心が移るかもしれません。異種ハードウェアによる推論が実用化すれば、各段階をどこで実行するかを決めるランタイムとスケジューリング層の価値が高まります。

大きな示唆は、レイテンシ目標を満たす範囲でのトークン単価が、主要なシステム制約になりつつあることです。デコード側の大幅なコスト削減は、大規模な推論サービスの経済性を実質的に変えます。

KV キャッシュがネットワークの基本要素になる

ベンダーをまたぐ推論への分かりやすい反論は、チップ間で KV キャッシュを移すと遅いはずだ、というものです。

数値は、そうではないことを示します。レイヤーごとにパイプライン化した転送の追加時間は 5～10 ms。NVIDIA のキャッシュ形式から Intel の形式への変換は 20～50 マイクロ秒です。数百 ms の時間予算に対しては、ごく小さな差です。

より深い意味は、数値よりアーキテクチャにあります。KV キャッシュは、GPU 内部の実装詳細というより、移動、変換、スケジューリングすべきシステム全体のオブジェクトになり始めています。それだけであらゆるキャッシュパターンが実用的だと証明されるわけではありませんが、可能性は想像しやすくなります。

データプレーンの形式変換、配置、追い出し、パイプライン転送を担うものが、推論スタックの重要な層を握ることになるかもしれません。

まだ準備が整っていないのはソフトウェア

物理的には成り立ち、経済性も成り立ちます。しかし、ランタイムはまだです。

vLLM と llm-d は複数ベンダーでの導入をサポートしますが、その対応は均一ではなく、同じワークロードを異なるベンダーのアクセラレーターに分離することは、今も難しいままです。本番利用の主な障害の一つは、ここにあると考えられます。

同時に、ここは競争優位が生まれる場所でもあります。複数ベンダーのフリートでは、複数のドライバースタック、ファームウェアの更新周期、運用上の障害パターンを扱います。スイッチ一つで移行できるものではありません。

統一されたサービング層の背後で KV キャッシュの移動を適切に処理し、実用的なベンダー横断スケジューラーを提供できるチームは、大きなコスト優位を得る可能性があります。その正確な大きさは、実際のワークロードが分析でモデル化したものに、どれほど近いかによります。

エージェントのワークロードは二分法に収まらない

プリフィルとデコードの分離は、チャットと RAG では機能します。それぞれが一回の LLM 呼び出しで、プロンプトの取り込み（プリフィル）と、回答のストリーミング（デコード）からなります。分離がワークロードの形に合っています。しかし、エージェントのワークフローでは不十分です。

エージェントには、プリフィルとデコードが一回ずつあるわけではありません。多数の短い生成の間に、ツール呼び出し、検索、しばしば別のモデルの段階も挟まります。各ステップが異なるハードウェア特性を必要とするため、単純な「プリフィルプール」と「デコードプール」の抽象化には限界があります。

この分析は、異種プール間の動的な分割という形で、その方向性に触れています。

固定的なハードウェアプールは、過渡期のアーキテクチャかもしれません。自然な方向は、ベンダー名ではなくワークロードの特性に基づき、異種プールに処理を振り分けるスケジューラーです。

**私の見立てでは、**そのスケジューラーはまだ完全な形では存在せず、構築することが AI サービングの重要なインフラ課題の一つになり得ます。

この分析をどう生かすか

**大規模な推論を運用する方へ：**すべて NVIDIA という既定の選択を、異種構成と改めて比較する価値があります。モデル化されたワークロードは、支払う上乗せコストが大きい可能性を示しています。

**推論ソフトウェアを開発する方へ：**大規模なプラットフォーム組織を持たないチームでも異種構成を運用できるようにする、ベンダー横断スケジューラーと KV キャッシュのデータプレーンに、重要な機会があります。

**推論を使う製品を開発する方へ：**特定のワークロードで推論コストが下がれば、以前は採算が微妙だった機能を再検討する価値が出るかもしれません。

一体化が続いてきたのは、分離が難しかったからです。この分析は、ハードウェアの経済性が別の設計を支えられることを示唆します。今も最も難しいのは、ソフトウェアです。

この問題に取り組んでいる方と、ぜひ知見を交換したいと考えています。