超大規模言語モデルを実行するための基盤の構築
2026-04-16 Michelle Chen Kevin Flansburg Vlad Krasnov 8分で読める
エージェントは大規模言語モデルによって駆動される必要があります。数週間前、Workers AIが公式にMoonshot's Kimi K2.5のような大規模なオープンソースモデルをホストするアリーナに参入することを発表しました。それ以来、Kimi K2.5を3倍高速化し、さらに多くのモデル追加が進行中です。これらのモデルは、今週立ち上げている多くのエージェント製品、ハーネス、ツールのバックボーンとなっています。
AIモデルのホスティングは興味深い課題です。ソフトウェアと非常に高価なハードウェアの間の微妙なバランスが必要です。Cloudflareでは、巧妙なソフトウェアエンジニアリングを通じてハードウェアから最大限の効率を引き出すことが得意です。これは、超大規模言語モデルを実行するための基盤をどのように構築しているかについての深い掘り下げです。
ハードウェア構成
前回のKimi K2.5ブログ投稿で述べたように、モデルに最適なサービスを提供するために、さまざまなハードウェア構成を使用しています。多くのハードウェア構成は、ユーザーがモデルに送信する入力と出力のサイズに依存します。
例えば、モデルを使用してファンフィクションを書く場合、いくつかの小さなプロンプト（入力トークン）を与えながら、ページ単位のコンテンツ（出力トークン）を生成するよう要求するかもしれません。逆に、要約タスクを実行している場合、数十万の入力トークンを送信しますが、数千の出力トークンのみで小さな要約を生成します。
これらの対立するユースケースに直面して、選択をする必要があります。入力トークンの処理を高速化するようにモデル構成をチューニングすべきか、それとも出力トークンの生成を高速化すべきか？
Workers AIで大規模言語モデルを立ち上げたとき、ほとんどのユースケースはエージェント用に使用されることを知っていました。エージェントでは、大量の入力トークンを送信します。大規模なシステムプロンプト、すべてのツール、MCPで始まります。最初のユーザープロンプトで、そのコンテキストは成長し続けます。ユーザーからの新しいプロンプトは、以前に言われたすべてのもの（すべての以前のユーザープロンプト、アシスタントメッセージ、生成されたコードなど）で構成されるモデルへのリクエストを送信します。
Workers AIの場合、2つのことに焦点を当てる必要がありました。高速な入力トークン処理と高速なツール呼び出しです。
Prefill Decode（PD）分離
パフォーマンスと効率を向上させるために使用するハードウェア構成の1つは、分離されたプリフィルです。LLMリクエストを処理するには2つのステージがあります。入力トークンを処理してKVキャッシュを入力するプリフィル、および出力トークンを生成するデコードです。プリフィルは通常、計算バウンドですが、デコードはメモリバウンドです。これは、各ステージで使用されるGPUの部分が異なることを意味し、プリフィルは常にデコードの前に実行されるため、ステージは互いにブロックします。
最終的には、単一のマシンでプリフィルとデコードの両方を実行する場合、すべてのGPUパワーを効率的に利用していないことを意味します。
プリフィルデコード分離により、各ステージに対して個別の推論サーバーが実行されます。まず、リクエストはプリフィルステージに送信され、プリフィルを実行してKVキャッシュに保存します。次に、同じリクエストがデコードサーバーに送信され、プリフィルサーバーからKVキャッシュを転送してデコードを開始する方法に関する情報が含まれます。
これには多くの利点があります。サーバーが実行している役割に対して独立してチューニングされたり、入力が多いまたは出力が多いトラフィックを考慮してスケーリングされたり、異種ハードウェアで実行されたりすることができるためです。
このアーキテクチャを実現するには、比較的複雑なロードバランサーが必要です。上記のようにリクエストをルーティングするだけでなく、デコードサーバーの応答（ストリーミングSSEを含む）を書き直して、キャッシュされたトークンなどのプリフィルサーバーからの情報を含める必要があります。さらに複雑なことに、異なる推論サーバーはKVキャッシュ転送を開始するために異なる情報を必要とします。
これを拡張して、トークン認識ロードバランシングを実装しました。プリフィルエンドポイントとデコードエンドポイントのプールがあり、ロードバランサーはプール内の各エンドポイントに転送中のプリフィルまたはデコードトークンの数を推定し、この負荷を均等に分散しようとします。
公開モデルの立ち上げ後、入力/出力パターンが大きく変わりました。新しい使用パターンを分析し、顧客のユースケースに合わせて構成をチューニングしました。以下は、同じ数のGPUを使用しながらリクエスト量が増加した新しいPD分離アーキテクチャにトラフィックをシフトした後のp90 Time to First Tokenドロップのグラフです。
テール遅延の分散が大幅に改善されました。同様に、p90トークンあたりの時間は高い分散を伴う約100msから20～30msに低下し、トークン間遅延が3倍改善されました。
プロンプトキャッシング
エージェントのユースケースは通常長いコンテキストを持つため、毎回入力テンソルを再計算しないために効率的なプロンプトキャッシングを最適化します。x-session-affinityというヘッダーを活用して、リクエストが以前に計算された入力テンソルを持つ正しいリージョンにルーティングされるようにします。これについては、Workers AIで大規模LLMを立ち上げることについての元のブログ投稿で書きました。
OpenCodeのような人気のあるエージェントハーネスにセッションアフィニティヘッダーを追加しました。プロンプトキャッシングの小さな違いがユーザーの合計スループットの大幅な増加につながることに気付きました。
プロンプトキャッシングの小さな違いがユーザーの間で合計され、モデルを実行するために必要な追加GPUの係数になる可能性があります。内部的にはKV認識ルーティングがありますが、クライアントがx-session-affinityを送信してプロンプトキャッシングについて明示的にすることにも依存しています。ヘッダーの使用を奨励するために、キャッシュされたトークンの割引料金を提供しています。ユーザーがプロンプトキャッシングを活用して、より高速な推論とより安い価格設定を実現することを強く推奨しています。
最も重いユーザーと協力してこのヘッダーを採用しました。結果として、ピーク時の入力トークンキャッシュヒット率が60％から80％に増加しました。これにより、処理できるリクエストスループットが大幅に増加し、OpenCodeやAIコードレビューのようなインタラクティブまたは時間に敏感なセッションのパフォーマンスが向上します。
KVキャッシュの最適化
より大きなモデルをサービスしているため、1つのインスタンスが複数のGPUにまたがることができます。これは、GPU間でKVキャッシュを効率的に共有する方法を見つける必要があることを意味します。KVキャッシュは、プリフィルからのすべての入力テンソル（セッション内のプロンプトの結果）が保存される場所であり、最初はGPUのVRAMに存在します。すべてのGPUには固定のVRAMサイズがありますが、モデルインスタンスが複数のGPUを必要とする場合、KVキャッシュがGPU間に存在し、互いに通信する方法が必要です。
Kimiでこれを実現するために、Moonshot AIのMooncake Transfer EngineとMooncake Storeを活用しました。Mooncakeの転送エンジンは、高性能なデータ転送フレームワークです。NVLinkやNVMe over Fabricなどの異なるRemote Direct Memory Access（RDMA）プロトコルで動作し、CPUを関与させずにメモリ間の直接データ転送を可能にします。複数のGPUマシン間でのデータ転送の速度を向上させます。これは、モデルのマルチGPUおよびマルチノード構成で特に重要です。
LMCacheまたはSGLang HiCacheと組み合わせると、キャッシュはクラスター内のすべてのノード間で共有され、プリフィルノードが別のノードで元々プリフィルされた前のリクエストからキャッシュを識別して再利用できます。これにより、クラスター内でのセッション認識ルーティングの必要性が排除され、トラフィックをより均等に負荷分散できます。
Mooncake Storeはまた、キャッシュをGPU VRAMを超えて拡張し、NVMeストレージを活用することを可能にします。これにより、セッションがキャッシュに残る時間が延長され、キャッシュヒット率が向上し、より多くのトラフィックを処理し、ユーザーにより良いパフォーマンスを提供できます。
推測的デコーディング
LLMは、それより前のトークンに基づいて、シーケンス内の次のトークンを予測することで機能します。素朴な実装では、モデルは次のnトークンのみを予測しますが、実際にはモデルの単一の前方パスでn+1、n+2...トークンを予測できます。この人気のある手法は推測的デコーディングとして知られており、Workers AIに関する以前の投稿で書きました。
推測的デコーディングでは、より小さなLLM（ドラフトモデル）を活用して、ターゲットモデルが選択する候補トークンをいくつか生成します。ターゲットモデルは、単一の前方パスで候補トークンの小さなプールから選択するだけで済みます。
トークンの検証は、より大きなターゲットモデルを使用してトークンを生成するよりも高速で計算コストが低くなります。ただし、ターゲットモデルが最終的にドラフトトークンを受け入れるか拒否する必要があるため、品質は維持されます。
エージェントのユースケースでは、推測的デコーディングは、モデルが生成する必要があるツール呼び出しと構造化出力の量のため、本当に輝きます。ツール呼び出しは大部分が予測可能です。名前、説明があり、JSONエンベロープでラップされていることがわかります。
Kimi K2.5でこれを実現するために、NVIDIAのEAGLE-3（Extrapolation Algorithm for Greater Language-model Efficiency）ドラフトモデルを活用しています。推測的デコーディングをチューニングするためのレバーには、生成する将来のトークンの数が含まれます。その結果、高品質の推論を実現しながら、トークン/秒のスループットを高速化できます。
Infire：当社の独自推論エンジン
2025年のBirthday Weekで発表したように、Cloudflareは機械学習モデルを高速化する独自の推論エンジンInfireを持っています。Infireはrust で書かれた推論エンジンで、分散グローバルネットワークを考慮した推論に関するCloudflareの独自の課題をサポートするように設計されています。
実行を計画しているこの新しいクラスの大規模言語モデルのInfireサポートを拡張しました。これは、すべてを機能させるために新しい機能をいくつか構築する必要があることを意味しました。
マルチGPUサポート
Kimi K2.5のような大規模言語モデルは1兆を超えるパラメータを持ち、約560GBのモデルウェイトです。典型的なH100は約80GBのVRAMを持ち、モデルウェイトを実行するためにGPUメモリに読み込む必要があります。これは、Kimi K2.5のようなモデルがメモリにモデルを読み込んで実行するために少なくとも8つのH100が必要であることを意味します。これはKVキャッシュに必要な追加のVRAMを含まないもので、コンテキストウィンドウが含まれます。
Infireを最初に立ち上げてから、マルチGPUサポートを追加する必要がありました。推論エンジンが複数のGPUで実行され、パイプライン並列またはテンソル並列モードで実行でき、エキスパート並列化もサポートされています。
パイプライン並列化の場合、Infireはパイプラインのすべてのステージを適切に負荷分散しようとし、1つのステージのGPUが他のステージが実行されている間に飢えるのを防ぎます。一方、テンソル並列化の場合、InfireはクロスGPU通信を削減し、可能な限り高速にすることを最適化します。ほとんどのモデルでは、パイプライン並列化とテンソル並列化の両方を組み合わせて使用することで、スループットと遅延の最適なバランスが得られます。
さらに低いメモリオーバーヘッド
vLLMよりもはるかに低いGPUメモリオーバーヘッドを既に持っていますが、Infireをさらに最適化し、アクティベーションのような内部状態に必要なメモリを緊密にしました。現在、Infireはわずか2つのH200 GPUでLlama 4 Scoutを実行でき、KVキャッシュ用に56 GiB以上が残っており、100万以上のトークンに十分です。
Infireはまた、8つのH100 GPU（はい、H100です）でKimi K2.5を実行でき、KVキャッシュ用に30 GiB以上が利用可能です。どちらの場合でも、vLLMを最初に起動するのに苦労するでしょう。
より高速なコールドスタート
マルチGPUサポートを追加している間、ブート時間を改善する追加の機会を特定しました。Kimi K2.5のような最大のモデルでさえ、Infireは20秒以内にリクエストの提供を開始できます。読み込み時間はドライブ速度によってのみ制限されます。
より高速なスループットのためにハードウェアを最大化
独自の推論エンジンへの投資により、制約のないシステムで最大20％高いトークン/秒のスループットを取得することでハードウェアを最大化でき、以前は完全に実行不可能だった最新のモデルを実行するために低エンドのハードウェアを使用できるようになります。
旅は終わらない
新しいテクノロジー、研究、モデルが