llm-d と vLLM の解説：本番環境への道

組織が大規模言語モデル (LLM) ワークロードの本番環境への導入を加速させる中で、オープンソースツールのエコシステムは急速に拡大しています。最近、大規模な推論の複雑さに対処するために、vLLM と llm-d という 2 つの強力なプロジェクトが登場しました。

これにより、エンジニアリングチームの間では「vLLM と llm-d のどちらを使うべきか」という共通の疑問が生じています。これらのツールを比較するのは当然のことですが、戦略的な答えはどちらか一方を選ぶことではなく、それらがどのように連携するかを理解することにあります。一貫した結果を出すためには、高性能なエンジンに加えて、チャンピオンシップを勝ち抜くためのレース戦略が必要であることを認識することが重要です。

エコシステムの理解：エンジンとプラットフォーム

デベロッパーが直面する主な課題は、単なるスケーリングではありません。AI スタックのさまざまなレイヤーをどのように操作するかという点です。

ラップトップでのプロトタイプから本番環境のクラスタへと移行する際、推論エンジン (モデルを実行するソフトウェア) がトラフィック管理からスケーリングまで、すべてを処理すると想定しがちです。しかし、モノリシックな LLM サーバーは、元々ダイナミックなクラウドネイティブの世界向けに設計されたものではありません。これらを単独で実行すると、特にワークロードのコンテキスト長やトークンレートが変動する場合に、GPU の使用効率が低下したり、予期しないレイテンシーが発生したりすることがあります。

これを解決するには、これらのツールがどのようにお互いを補完し合っているかを確認することが役立ちます。

vLLM：高性能な F1 カー

vLLM はあなたの F1 カーであると考えてください。これは、圧倒的なスピードと効率性を実現するために設計された、最新のエンタープライズグレードの推論エンジンです。

vLLM は馬力を提供します。そのパフォーマンスの優位性は、PagedAttention (オペレーティングシステムのようにメモリーを管理する技術)、投機的デコーディング、テンソル並列性などの深い技術革新によって支えられています。これは推論ワークロードを実行し、ノード上の GPU メモリーを管理し、迅速なレスポンスを提供する役割を担うコンポーネントです。

単一ノードや適切に調整されたマルチ GPU クラスタでモデルを提供したい場合、vLLM はあなたをトラックへと導く車となります。しかし、最速の F1 カーであっても、チャンピオンシップを勝ち抜くにはチームのサポートが必要です。

llm-d：ピットクルーとレース戦略家

vLLM が車であるなら、llm-d はピットクルー、レース戦略家、そしてテレメトリーシステムを組み合わせたものです。

llm-d は、vLLM をオーケストレートするために設計されたクラウドネイティブの分散推論フレームワークです。1 台の車が長く複雑なレースを走り抜くためにはサポートが必要であることを前提としています。llm-d は推論プロセスを分離し、管理可能なコンポーネントに分解することで、効果的なスケーリングを支援します。

なぜこの関係が有用なのかを理解するために、レースの視点から LLM 生成の 2 つのフェーズを見てみましょう：

1. プリフィル (フォーメーションラップ) ：これは、ドライバーがタイヤを温め、システムをチェックするフォーメーションラップに似ています。LLM においては、システムがユーザーのプロンプトを処理し、初期の Key-Value (KV) キャッシュを計算する段階です。これは計算負荷が高く、重い処理です。
2. デコード (レース) ：これは、高速で繰り返されるレースそのものです。モデルは一度に 1 つのトークンを生成します。このフェーズでは、新しいトークンを素早く生成するために、高速なメモリ帯域幅が必要です。

標準的なセットアップでは、1 台のマシンが両方のフェーズを処理します。llm-d はレースコントロールとして機能し、プレフィックスを考慮したルーティングを使用して、どのバックエンドがどのリクエストを処理するかを決定し、車が常に最適なモードで走行できるようにします。

連携による相乗効果：フリートのオーケストレーション

vLLM なしでは llm-d は存在しません。これらはチームメイトとして設計されています。エンジン (vLLM) とオーケストレーター (llm-d) を組み合わせることで、本番環境における複雑な障害を解決する特定の統合機能が利用可能になります：

• 独立したスケーリング (分離) ：プリフィルとデコードのワーカーを分離することで、数千億のパラメータを持つ LLM を提供できます。llm-d はこれらのフェーズを分離するため、ウォーミングアップのリソースをレースのリソースから独立してスケーリングでき、ハードウェアの使用効率を最適化できます。
• MoE のためのエキスパート並列スケジューリング：巨大な Mixture of Experts (MoE) モデルの場合、llm-d はエキスパート並列スケジューリングを可能にします。これにより、モデル内の異なる「エキスパート」を複数の vLLM ノードに分散させることができ、単一の GPU セットアップでは大きすぎるモデルを実行できるようになります。
• KV キャッシュを考慮したルーティング：これは、ピットクルーがタイヤの摩耗具合を正確に把握しているのと同等です。llm-d は以前のリクエストからのキャッシュされた KV ペアをインテリジェントに再利用します (プレフィックスキャッシュの再利用)。同様のデータを以前に処理したワーカーにリクエストをルーティングすることで、レイテンシーと計算コストを削減します。
• Kubernetes ネイティブな弾力性 (KEDA および ArgoCD) ：ここで llm-d はプラットフォームとして真価を発揮します。KEDA (Kubernetes イベント駆動型オートスケーリング) や ArgoCD とシームレスに統合されます。これにより、リアルタイムの需要に基づいて vLLM の「車」のフリートを動的に増減させることができ、アイドル状態の GPU に予算を費やすことなく高可用性を実現します。
• 詳細なテレメトリー：llm-d はレースエンジニアとして機能し、最初のトークンまでの時間、KV キャッシュのヒット率、GPU メモリーのプレッシャーなどのトークンごとの指標を監視します。

最後に

vLLM を単独でデプロイすることは、開始する方法として素晴らしいものです。しかし、グローバルにスケーラブルな LLM サービスへと移行するにつれて、単なるエンジン以上のものが必要になるでしょう。

llm-d は vLLM を置き換えるものではなく、それを強化するものです。高性能なエンジンを勝利する推論システムへと変える、クラウドネイティブなコントロールプレーンを提供します。これらを組み合わせて使用することで、AI インフラストラクチャが単に速いだけでなく、チャンピオンシップを勝ち取れる準備ができていることを確信できるでしょう。

トラックに出る準備はいいですか？この llm-d の紹介 で詳細を確認するか、30 日間のセルフサポート型 OpenShift AI Developer Sandbox でテストしてみてください。