大規模な信頼性の高いLLM推論

Databricksでは、Kimi、QwenなどのオープンソースモデルからOpenAI、Gemini、Claudeなどのプロプライエタリモデルまで、あらゆる最先端モデルに対応する独自の推論プラットフォームを構築しました。Superhuman、Yipit Data、Fox Sportsなど、世界最大級のエージェントアプリケーションに推論機能を提供しています。現在、毎月120兆トークン以上を処理しています。

大規模LLM推論の難しさは信頼性にあります。エージェントが仕事や生活のインターフェースとなるにつれ、推論需要は指数関数的に増加しています。特に、勤務時間中にピークを迎える非常にスパイク状の需要曲線が見られます。

スケールでのLLM推論の課題 信頼性のある推論プラットフォームとはどういう意味でしょうか？一見すると、可用性とはリクエストが処理できるかどうかです。しかし実際には、ユースケースによってレイテンシ要件が大きく異なり、これが可用性に影響します。最も高度なエージェントは、p95の最初のトークンまでの時間（TTFT）と1秒あたりの出力トークン数（OPTS）の低下を許容できません。マルチテナントLLMサービスシステムでは、信頼性とレイテンシの両方を達成することは困難です。

信頼性の面では、最先端のパフォーマンスを得るには、KVキャッシュ転送用の高帯域幅インターコネクトを備えた最新GPUが必要です。これらの計算設定は、従来のCPUシステムよりも本質的に信頼性が低く、コストもかかります。全対全通信が必要であるため、1ノードのダウンタイムは、分離型プリフィル/デコード設定で他の複数ノードの再構成を必要とします。最高帯域幅のネットワーキングには、単一の物理ラック内のシングルスパイン接続（NVL72システムなど）が必要です。つまり、単一データセンターラック内の特定システムの障害が広範囲の障害を引き起こす可能性があります。マルチAZやバックアップインスタンスタイプの活用といった分散システムの古典的な手法は、高価なバックアップGPUをアイドル状態に保つことを意味し、コスト的に現実的ではありません。オーバープロビジョニングも古典的な手法ですが、計算リソースの供給が非常に制約されているため、極めて高価で非現実的です。したがって、システムは高負荷下でも稼働を続けなければなりません。

同時に、これらの制約下でも開発速度を維持する必要があります。推論需要は年々数桁の成長を遂げており、その成長を促進しながら革新的な機能をリリースすることは困難でした。画像、動画、セキュリティ分類などの機能にはそれぞれ異なる前処理システムが必要であり、これらはすべて独立してスケールする必要があります。

最後に、最高のパフォーマンスを達成し、新しいモデルアーキテクチャをサポートするには、カスタムカーネルからプロプライエタリ推論エンジンに至るまでの最適化が必要です。アーキテクチャが微妙に変化するにつれ、新しい低レベルソフトウェアが導入されることが多く、大規模では不透明な形で失敗し、サーバーハングやGPUクラッシュなどのデバッグが困難なシナリオを引き起こします。

レイテンシの面では、多様な負荷パターンでレイテンシを制御することは困難です。これは、リクエストの処理コストが非常に変動しやすく、事前に見積もることが難しいためです。正常なサーバーでも、負荷が高くなるとすべてのリクエストの処理が遅くなり、スループット（したがってコスト効率）と製品が処理する必要のある最速レイテンシとの間のトレードオフが発生します。これは信頼性の問題として現れることもあり、割り当てられたリクエストの組み合わせによって、サーバーが予期せず不健康な状態になる可能性があります。

さらに、レイテンシは出力トークン生成に支配されますが、モデルがどのくらい出力するかを予測するのが難しいため、事前のコスト見積もりは困難です。したがって、低レイテンシサービスには、複雑な容量管理、負荷分散、リクエスト優先順位付けシステムが必要です。

全体アーキテクチャ データプレーンでは、推論ランタイム（オープンソースおよびプロプライエタリな内部エンジン）が最先端GPUにデプロイされます。モデルデプロイメント間のトラフィックを処理するために、データプレーンはAxonと呼ばれるルーター（同じモデルのレプリカ間で負荷を分散）と、レプリカ数を調整するオートスケーラーを実行します。コントロールプレーンでは、リクエストはレート制限を経てデータプレーンに到達します。リクエストメトリクスに基づいて、容量管理アルゴリズムが各ワークロードに割り当てるGPU容量を決定し、オートスケーラーがそれを実施します。

容量の把握 容量（どれだけあるか、どれだけ販売したか、顧客がどれだけ使用しているか）を大まかに把握する必要があります。そのために、「モデルユニット」と呼ばれる抽象化を導入しました。レプリカが1分間に固定数のモデルユニット（例：100）を処理できると仮定すると、次のような仮定ができます。入力または出力が長いリクエストは、同じ時間枠内で完了できる数が少ないため、より多くのモデルユニットを消費します。プリフィルとデコードではスループット特性が異なるため、出力が長いリクエストは入力が長いリクエストよりもコストがかかります。

したがって、リクエストコストを多次元関数（コスト = α × 入力トークン数 + β × 出力トークン数 + γ × その他の要素）でモデル化します。係数α、β、γは、各モデルとハードウェアタイプの組み合わせに対して自動ベンチマークで決定されます。モデルユニットは、プレフィックスキャッシュなどの最適化のためにさらに調整でき、マルチモダリティなどの機能も考慮する必要があります。このような推定は構造的に不完全ですが、マルチテナントシステムをクラウドVMのように管理しやすいものに分解する方法として機能します。VMは、予測可能なパフォーマンスを提供し、特定の顧客に割り当てることができるという望ましい特性を持っています。プロダクションエージェントワークロードでは、低レイテンシと容量の保証を提供することが重要であり、このような割り当てシステムがなければ、最善でも「ベストエフォート」の容量しか提供できず、あまりにも多くの顧客がシステムを使用すると取り戻される可能性があります。

コストベースの負荷分散とオートスケーリング リクエストがサーバーに与える影響は非常に変動しやすいため、ほぼ最適なルーティング決定を行うことが重要です。一般に、負荷分散はP2C（2つの選択肢の力）などの統計的手法に依存し、キューサイズに基づいて負荷を推定し、サンプリングを利用してすべての可能なターゲットを把握するためのメモリとレイテンシのオーバーヘッドを削減します。しかし、LLMのレイテンシは高く、サーバー数はスケールアウトしたCPUシステムよりも少なく、誤ったルーティングのコストは深刻です。そのため、LLMサービスには異なるアプローチが必要です。

現在、Databricksの自動シャーダーDicerを使用して、ワークロード間で動的にルーティングしています。負荷認識型ルーティングがないと、長いコンテキストのリクエストが個々のサーバーをホットスポットにし、他のサーバーは十分に活用されません。モデルユニットをDicerと統合し、ルーティングの決定を従来のリクエストベースのヒューリスティックではなく、サーバーの負荷（モデルユニット単位）に基づいて行うようにしました。Dicerはまた、ステートフルセッションを提供し、リクエストルーティングをスティッキーにします。ワークロードのリクエストはサーバーのサブセットにのみ送信され、キャッシュヒット率が向上し（レイテンシに敏感なコーディングエージェントにとって重要）、ブラスト半径が制限されます。

オートスケーリングでも同様の問題があります。保留中のリクエスト数だけでは実際の負荷を反映しません。長いコンテキストのリクエストのスパイクは短いリクエストのスパイクと同じに見え、CPUやメモリのメトリクスも実際のGPU使用率と相関しません。モデルユニットを使用することで、オートスケーラーはモデルユニット使用率に基づいてスケールアップまたはスケールダウンを決定できます。推論エンジンが最大モデルユニットの特定のパーセンテージ（ハードウェアタイプとワークロード形状によって決定）に近づくと、ピークスループットに近づいているため、スケールアップがトリガーされます。逆はスケールダウンをトリガーします。このアプローチにより、モデルごとに手動でオートスケーリングルールを調整する必要がなくなり、モデルに依存しないスケーリングインフラが実現します。

LLM推論パターンに基づいてオートスケーリングを構築することで、常に最大レプリカにスケールする必要がなくなりました。トラフィックがバーストするモデルでは、オートスケーリングによりレプリカ数を実際の需要に近づけ、ピーク時の静的プロビジョニングと比較してGPUコストを80%以上削減しました。

実行時信頼性 スマートなルーティングとスケーリングは優れた基盤を提供しますが、エンジンレベルでの障害を防ぐことはできません。どの推論エンジン（内部エンジンまたは人気のあるオープンソースオプション）をデプロイしても、プロダクションスケールではエッジケースとリソース競合が発生します。障害を自動的に検出して回復するメカニズムが必要です。

サイレント障害の検出と回復：私たちが遭遇する障害モードの1つは、サイレントハングです。エッジケース（構造化出力、マルチモーダル入力）を含むリクエストが、推論エンジンのマルチプロセスアーキテクチャで未処理のエラーを引き起こし、サーバーがエラーを表示せずに応答しなくなることがあります。これを定期的なブラックボックスヘルスチェックで検出します。最近実際のリクエストが完了していない場合に、最小限のエンドツーエンドリクエストを送信します。ヘルスチェックに失敗すると、Kubernetesのlivenessプローブがサーバーを再起動します。これは内部実装に関係なく、すべてのエンジンで機能します。ただし、高負荷下ではヘルスチェック自体がタイムアウトし、livenessプローブが実際には正常なサーバーを強制終了する可能性があり、カスケード障害のリスクがあります。この問題を解決するために、ヘルスチェックリクエストに最高のスケジューリング優先度を割り当て、高負荷下でも確実に完了するようにしました。優先度付きヘルスチェックにより、ハングの検出、異常なサーバーの強制終了、回復までの全サイクルが5分未満で完了します。誤ったlivenessプローブ障害は、週に数回からゼロに減少しました。

マルチモーダルリクエストによる予期しない負荷の処理：大規模なマルチモーダルリクエストのバッチが到着したとき、まったく別の原因によるエラー率とタイムアウトのスパイクが見られました。調査の結果、リクエストは推論エンジンのコアプロセスにすら到達していないことがわかりました。画像リクエストの処理はテキストのみのリクエストよりもリソースを消費し、追加のビジョンエンコーダーがGPUで実行されるだけでなく、CPU集約型の画像処理も行われます。特定のモデルでは、画像処理が非常に遅く、イベントループを完全にブロックしていました。ブロッキング操作を別のスレッドやプロセスに移動しても問題は解決せず、高い画像負荷の下ではリクエストが依然として蓄積されました。そこでPythonプロセスをプロファイリングし、いくつかの発見をしました。すべてのCPU画像処理操作の中で、画像処理（リサイズと正規化）は、base64デコードなどの他の操作よりも10倍遅いこと。一部のHugging FaceモデルはデフォルトでPILベースの画像プロセッサを使用し、他のモデルはより高速なTorchvisionベースのプロセッサを使用すること。