複数の旧世代GPUノードにおける長文コンテキストPrefillの最適化

概要

AIアプリケーションにおいてエージェントワークフローがますます普及するにつれ、 モデルは大幅に長いコンテキスト長を処理する必要があります。 この変化は、システム利用率を最大化しながらサービスレベル目標（SLO）を 維持するという重要な課題をもたらします。 特に、長いコンテキストリクエストのTime-To-First-Token（TTFT）を削減するために、 prefill性能の最適化が不可欠です。 これに対処するため、我々はSLO-Driven Prefill Engine（SLOPE）を開発しました。

SLOPEは、マルチノードGPUクラスター上でcontext parallelism技術 （Ulysses + Ring Attention）を適用し、長いコンテキスト入力の SLO駆動型最適化を実現する専用prefillエンジンです。 既存のLLMエンジンは、長い入力プロンプトを処理する際、 prefill計算が単一ノードに制限されるため、TTFTを一定の閾値以下に 削減することが根本的に困難です。SLOPEは、複数ノードにわたって prefill計算を並列化することでこの制限を克服し、 同時ユーザーリクエスト数を最大化しながら、TTFTを目標SLO閾値を 大幅に下回るレベルまで削減します。

SLOPEは、既存のLLMエンジンとprefill/decode disaggregationモードで 統合でき、専用のprefill workerとして動作します。

Context Parallelismの紹介

Tensor parallelism（TP）は、LLM推論で最も広く使用されている並列化技術です。 TPは線形層のパラメータをデバイス間に分散し、attention headsをデバイス間で 分割してAllReduce通信を必要とします。 しかし、TTFTを削減するために単純にTPサイズを増やすことには限界があります：

• 非効率なGEMM操作：過度なパラメータ分割により、非効率なGEMM操作が発生します。
• 冗長な計算：attention headsの数がTPサイズより小さい場合、冗長な計算が発生します。
• 通信オーバーヘッド：TPサイズが増加すると、ノード間AllReduceが必要となり、通信オーバーヘッドが大幅に増加します。

Context parallelismは、シーケンス次元に沿って入力プロンプトを分割します。 特に長いコンテキストのシナリオでは、シーケンス次元で利用可能な 大規模な並列性により、context parallelismはtensor parallelismよりも効率的です。 attention層を除くほとんどの操作はトークン間の依存関係がなく、 完全に独立して処理できます。 attention層におけるトークン間の依存関係は、2つのアプローチで対処できます：

• Ulysses：attention計算の前にquery、key、valueに対してall-to-all通信を行い、head次元に沿って分割することで独立した計算を可能にします。
• Ring Attention：各デバイス上で部分的なquery、key、valueを使用してattention計算を行いながら、同時に隣接デバイスとkey、valueを送受信します。

これら2つのアプローチには相補的なトレードオフがあります。 Grouped Query Attention（GQA）やMulti-Head Latent Attention（MLA）を 使用する場合、keyとvalue headsの数が減少するため、Ulyssesの適用は制限されます。 一方、Ring AttentionはUlyssesよりも大きな通信量を伴います。 しかし、シーケンス長が長くなると、attention計算が比例的に支配的になり、 通信をattention計算で隠蔽できるようになります。 そのため、コンテキスト長とSLO要件に基づいて適切に組み合わせる必要があります。

Context parallelismを適用すると、すべてのデバイスがモデルパラメータの 複製を保持するため、TPと比較してメモリ使用量が増加します。 これに対して、context parallelismと併せてpipeline parallelismを 適用することで対処しています。

評価

4ノードAMD MI250クラスター（ノードあたり8デバイス）上で、 Ulysses、Ring Attention、Pipeline Parallelの様々な組み合わせによる 異なる並列化構成でのSLOPEのprefill性能を評価し、 TP=8のSGLangと比較しました。すべての実験で、openai/gpt-oss-120bモデルを 使用してprefill性能を評価し、32K、64K、100Kの3つのコンテキスト長でテストしました。

下の表に示すように、SLOPEはすべてのコンテキスト長で非常に低いTTFT SLOを 満たしていますが、SGLangがこれらの要件を満たす能力は状況によって異なります。

図1は、様々な並列化構成と同時実行レベルにおけるTTFTとスループットの測定結果を 示しています。結果は、SLOPEが32Kと64Kの両方のコンテキストで1秒未満のTTFTという 非常に低いレイテンシSLOを達成することを確認しています。 TP=8のSGLangと比較して、SLOPEは同じTTFTでより高いスループットを達成しており、 SLO要件を満たしながらより多くの同時ユーザーリクエストを処理できることを意味します。 100Kのコンテキスト長でも、SLOPEは2秒未満のTTFTを達成していますが、 TP=8のSGLangは約9秒に制限されています。 これは、SLOPEが長いコンテキストのLLM推論に対する実用的なソリューションを 提供することを示しています。

異種クラスターにおけるSLOPEエンジン

SLOPEエンジンの用途は、長いコンテキスト推論の応答レイテンシの削減や トークンスループットの向上にとどまりません。 データセンターに既に存在するレガシーGPUサーバーを効率的に活用する方法も提供します。

一般的に、LLM推論は複数ノードにわたって並列化することが困難であり、 これが大規模LLMを処理するためにより高速で大容量かつ高価なGPUが 導入され続ける理由の一つです。 しかし、SLOPEエンジンを使用すれば、少なくともprefill段階では、 複数の旧世代GPUサーバーを集約して十分に低いレイテンシと 高いスループットを達成できます。

この種の活用が実現可能であることを実証するため、 AMD MI250 GPUクラスター上でSLOPEを評価しました。 AMD MI250 GPU（NVIDIA A100に匹敵）とより新しいMI300シリーズGPUが 共存するシステムでは、MI250 GPUをSLOPEに割り当て、 MI300シリーズGPUが従来の推論エンジンを使用してdecodingを実行することで、 より高い全体的なシステム効率を実現できます。 これらの機能は、2026年第1四半期からMoAI Inference Frameworkを通じてサポートされる予定です。