このコンテンツは自動機械翻訳サービスによる翻訳版であり、皆さまの便宜のために提供しています。原本の英語版と異なる誤り、省略、解釈の微妙な違いが含まれる場合があります。ご不明な点がある場合は、英語版原本をご確認ください。
エージェントは大規模な言語モデルで動作する必要があります。数週間前、私たちは、Workers AIが正式に、Moonshotのkimi K2.5のような大規模なオープンソースモデルをホストする分野に正式に進出することを発表しました。それ以来、当社はKimi K2.5を3倍高速化し、より多くのモデルを実行中です。これらのモデルは、当社が今週発売した多くのエージェンティック製品、利用、ツールの基盤となっています。
AIモデルのホスティングは、興味深い課題です。ソフトウェアと、非常に高価なハードウェアの間の微妙なバランスを取る必要があるのです。Cloudflareは、賢いソフトウェアエンジニアリングを通じてハードウェアからあらゆる効率性を引き出すことに長けています。これは、超大規模言語モデルを実行するための基盤作りについて、深く掘り下げたものです。
以前のKimi K2.5ブログ記事で述べたように、当社はモデルに最適なサービスを提供するために、様々なハードウェア構成を使用しています。ハードウェア構成の多くは、ユーザーがモデルに送信する入力と出力のサイズに依存します。例えば、モデルを使ってファンフィクションを書く場合、いくつかの小さなプロンプト（入力トークン）を与え、コンテンツページ（出力トークン）を生成するよう依頼することができます。
逆に、要約タスクを実行する場合、何十万もの入力トークンを送信することになるかもしれませんが、出力トークンは小さな要約しか生成されないことになります。このような相反するユースケースがあるため、モデル構成を調整して、入力トークンの処理をより高速にすべきか、出力トークンをより高速に生成できるか、選択を迫られます。
Workers AIで大規模な言語モデルをローンチしたとき、ユースケースのほとんどはエージェントに使用されることをわかっていたのです。エージェントの場合、大量の入力トークンを送ります。すべてのツール、MCPを含む大きなシステムプロンプトから始まります。最初のユーザープロンプトで、そのコンテキストは拡大し続けます。ユーザーからの新しい各プロンプトがモデルにリクエストを送信します。モデルは、以前書かれたすべての内容（これまでのユーザープロンプト、アシスタントメッセージ、生成されたコードなど）で構成されます。Workers AIの場合、これは「高速な入力トークン処理」と「高速なツール呼び出し」の2つに集中する必要がありました。
当社がパフォーマンスと効率性を向上させるために使用するハードウェア構成の1つに、分散したプリフィルメントがあります。LLMリクエストの処理には、入力トークンを処理してKVキャッシュに入力するプリフィルと、出力トークンを生成するデコードの2つの段階があります。通常、プリフィルはコンピューティングの制約があり、デコードはメモリの制約があります。つまり、各ステージで使用するGPUの部品が異なり、プリフィルは常にデコード前に行われるため、各ステージは互いにブロックします。つまり、単一のマシンでプリ入力とデコードの両方を行うと、GPUの能力を効率的に活用できないということになります。
事前入力デコードの分解により、各段階で別の推論サーバーが稼働します。まず、リクエストがプリフィルステージに送信され、プリフィルを実行してKVキャッシュに保存します。次に、同じリクエストがデコードサーバーに送信され、プリフィルサーバーからKVキャッシュを転送し、デコードを開始する方法に関する情報とともに送信されます。これには、サーバーが実行している役割に合わせて個別に調整したり、より入力が多い、または出力が多いトラフィックを考慮するために拡張したり、さらには異種ハードウェア上で実行することができるため、多くの利点があります。
このアーキテクチャを実現するには、比較的複雑なロードバランサーが必要です。前述のようにリクエストをルーティングするだけでなく、デコードサーバーのレスポンス（ストリーミングSSEを含む）を書き換えて、キャッシュされたトークンなどプリフィルサーバーからの情報を含める必要があります。問題を複雑にしているのは、推論サーバーごとに、KVキャッシュ転送を開始する際に必要な情報が異なるためです。Cloudflareはこれを拡張して、トークン認識型の負荷分散を実装しました。この負荷分散では、プリ入力エンドポイントとデコードエンドポイントのプールがあり、ロードバランサーはプール内の各エンドポイントに転送されているプリ入力トークンまたはデコードトークンの数を推定し、この負荷を分散しようとします。均等に。
パブリックモデルのローンチ後に、当社のインプット/アウトプットのパターンが再び大きく変わりました。新しい利用パターンを分析し、お客様のユースケースに合わせて設定を調整しました。
これは、トラフィックを新しいPD分離アーキテクチャに移行した後、同じ量のGPUを使用してリクエスト量が増加した場合の、p90の最初のトークンの時間（TTFB）の低下率のグラフです。テール遅延のばらつきに大幅な改善が見られました。
同様に、トークンあたりのp90は、変動が大きい約100ミリ秒から20～30ミリ秒になり、トークン間遅延が3倍改善されました。
エージェントの使用ケースには通常、長いコンテキストがあるため、毎回入力テンソルを再計算しないように、効率的なプロンプトキャッシングを最適化します。当社では、x-session-affinityと呼ばれるヘッダーを活用して、以前に計算された入力テンソルがあった正しい地域にリクエストがルーティングされるようにしています。このことについては、当社のオリジナルブログ記事Workers AIでの大規模LLMローンチに関する人気のエージェント機能にセッションアフィニティヘッダーを追加しましたOpenCodeのような、総スループットが大幅に増加したことがわかりました。ユーザーからのプロンプトキャッシュにおけるわずかな違いは、モデルを実行するのに必要な追加のGPUの要因につながる可能性があります。内部的にKVを認識するルーティングがありますが、プロンプト**キャッシング**を明示するために、クライアントがx-session-affinityを送信することに依存しています。当社は、キャッシュされたトークンの割引を提供することで、ヘッダーの使用に割引を提供します。当社では、ユーザーがより迅速な推論とより安価な価格設定のために、プロンプトキャッシングを活用することを強くお勧めします。
当社は、社内の最支援ユーザーと協力して、このヘッダーを採用しました。その結果、ピーク時に入力トークンのキャッシュヒット率が60%から80%に増加しました。これにより、Cloudflareが対応できるリクエストのスループットが大幅に向上し、OpenCodeやAIコードレビューなど、インタラクティブで時間を重視するセッションのパフォーマンスが向上します。
現在はより大規模なモデルを提供しているため、1つのインスタンスが複数のGPUにまたがることが可能です。つまり、GPU間でKVキャッシュを共有するための効率的な方法を見つけなければならなかったのです。KVキャッシュは、プリ入力（セッション内のプロンプトの結果）からのすべての入力テンソルが保存される場所であり、最初はGPUのVRAMにあります。すべてのGPUのVRAMサイズは固定ですが、モデルインスタンスに複数のGPUが必要な場合は、KVキャッシュがGPU間で存在し、互いに通信する方法が必要になります。キミのためにこれを実現するために、私たちはMoonshot AIのMooncake Transfer EngineとMooncake Storeを活用しました。
Mooncatの Transfer Engineは、高性能なデータ転送フレームワークです。これは、NVLinkやNVMe over Fabricなどのさまざまなリモートダイレクトメモリアクセス（RDMA）プロトコルと動作し、CPUを必要とせずに直接的なメモリからメモリへのデータ転送を可能にします。これにより、複数のGPUマシン間でデータを転送する速度が向上します。これは、モデルのマルチGPUおよびマルチノード構成で特に重要です。
LMCacheまたはSGLang HiCacheと組み合わせると、キャッシュはクラスター内のすべてのノードで共有され、プリフィルノードは別のノードで事前入力された以前のリクエストからのキャッシュを識別して再利用することができます。これにより、クラスター内でセッションを意識したルーティングを行う必要がなくなり、トラフィックをより均等に負荷分散することができます。Moon取り除く Storeでは、GPU VRAMを超えてキャッシュを拡張し、NVMeストレージを活用することもできます。これにより、セッションがキャッシュに留まる時間が長くなり、キャッシュヒット率が向上し、より多くのトラフィックを処理し、ユーザーにより良いパフォーマンスを提供できるようになります。
LLMは、その前に来たトークンに基づいて、シーケンス内の次のトークンを予測することで機能します。単純な実装では、モデルは次の n トークンのみを予測しますが、実際にはモデルの1回のフォワードパスで次の n+1、n+2... トークンを予測させることができます。この人気のある技術は、投機的デコーディングとして知られており、これについては、Workers AIに関する以前の投稿で紹介しました。
投機的デコーディングでは、小規模なLLM（草稿モデル）を活用して、ターゲットモデルが選ぶための候補トークンをいくつか生成します。ターゲットモデルは、1回のフォワードパスで小さな候補トークンプールから選択するだけで済みます。トークンの検証は、大規模なターゲットモデルを使用してトークンを生成するよりも高速で計算コストが低いです。しかし、ターゲットモデルは最終的にドラフトトークンを受け入れるか拒否する必要があるため、品質は維持されます。
エージェンティックな使用例では、モデルが生成する必要のあるツールコールと構造化された出力の量のため、投機的デコーディングが特に活躍します。ツールの呼び出しはたいてい予測可能です。名前と説明があり、JSONエンベロープに囲まれていることがわかっています。
Kimi K2.5でこれを行うために、NVIDIAのEAGLE-3（Extrapolation Algorithm for Greater Language-model Efficiency）ドラフトモデルを活用します。投機的デコーディングのチューニングには、将来生成するトークンの数も使っています。その結果、1秒あたりのスループットを高速化しながら、高品質な推論を実現できます。
2025年のバースデーウィーク中に発表したように、Cloudflareには独自の推論エンジンInfireがあり、機械学習モデルをより高速化します。InfireはRustで記述された推論エンジンで、Cloudflareの分散型グローバルネットワークからの推論で当社独自の課題をサポートするために設計されています。私たちは、実行する予定の、この新しいクラスの大規模言語モデルのInfireサポートを拡張しました。つまり、すべてを機能させるために、いくつかの新しい機能を構築する必要があったのです。
kimi K2.5のような大規模言語モデルには1兆以上のパラメータがあり、モデルの重みの約560GBに相当します。典型的なH100はVRAMが約80GBで、モデルを動作させるためにはGPUメモリに重みをロードする必要があります。つまり、kimi K2.5のようなモデルは、モデルをメモリにロードして実行するために、少なくとも8 H100が必要だということです。それには、コンテキストウィンドウを含むKV キャッシュに必要な余分なVRAMも含まれないことになります。
Infireをローンチした当初から、マルチGPUのサポートを追加し、推論エンジンをパイプライン並列またはテンソルパラレルモードの複数のGPUで実行できるようにし、専門家による並列性もサポートしました。
パイプラインの並列性のために、Infireはパイプラインのすべてのステージを適切に負荷分散して、他のステージが実行されているときにあるステージのGPUが枯渇するのを防ぐことを試みます。一方、テンソル並列性の場合は、InfireはGPU間の通信を減らし、可能な限り高速にするために最適化します。ほとんどのモデルでは、パイプライン並列性とテンソル並列性の両方を組み合わせることで、スループットと遅延の最良のバランスが得られます。
GPUメモリのオーバーヘッドは既にvLLMより遥かに低いですが、Infireはさらに最適化され、アクティベーションなどの内部ステートに必要なメモリを削減しました。現在、Infireはわずか2台のH200 GPUでLlama 4 Scoutを実行することができ、KVキャッシュ用に56GiB以上が残っており、120万以上のトークンに十分です。Infireは、8つのH100 GPU（もちろんH100です）でのみK2.5を実行することができ、30 GiB以上をまだKVキャッシュに利用できます。どちらの場合も、そもそもvLLMを起動することさえ困難となるでしょう。
私たちは、マルチGPUのサポートを追加しながら、起動時間を改善する他の方法を特定しました。Kim K2.5のような最大規模のモデルでも、Infireは20秒以内にリクエスト処理を開始できます。読み込み時間は、ドライブ速度によってのみ制限されます。
当社独自の推論エンジンへの投資により、制約のないシステムで毎秒スループット毎秒最大20%高いトークンを得られ、ハードウェアを最大限活用できるようになりました。また、以前は完全に不可能だったローエンドハードウェアを最新のモデルに使用できるようになりました。
機械学習コミュニティでは、新しい技術、研究、モデルが毎週のように登場しています。当社は、GPUを効率的に運用しながら、高品質でパフォーマンスの高い推論をお客様に提供するために、継続的に技術スタックを最適化しています。ご関心がおありでしたら、ぜひご応募ください！