DocsDigest
Back to listLanguage: JA
OpenAICloudflareApr 16, 2026, 2:00 PM

Building the foundation for running extra-large language models

A condensed section focused on the key takeaways first.

Original Post
OpenAIClaude

Quick Digest

Summary

A condensed section focused on the key takeaways first.

openaienmodel: gpt-5-mini-2025-08-07

Building the foundation for running extra-large language models

inferencekv-cachemulti-gpuspeculative-decodingload-balancingprompt-caching

Key Points

  • Prefill–decode disaggregation cut tail latencies and improved intertoken throughput
  • x-session-affinity prompt caching raised cache hit ratio from ~60% to ~80%
  • Infire: multi-GPU support, lower memory overhead, and <20s cold starts

Summary

Cloudflare describes the engineering and architecture changes used to run extra-large open-source LLMs (example: Kimi K2.5) on Workers AI. Key improvements include prefill–decode (PD) disaggregation with token-aware load balancing, prompt/session caching (x-session-affinity), cross‑GPU KV‑cache sharing using Mooncake and NVMe extension, speculative decoding with a smaller draft model (EAGLE‑3), and Infire — a Rust inference engine with multi‑GPU, low‑memory overhead, and fast cold‑starts.

These changes target agentic workloads that are input‑heavy and require fast tool calls and long contexts. The result: 3x intertoken throughput improvement, lower tail latencies, higher cache hit ratios, and better hardware utilization.

Key Points

  • Prefill–decode disaggregation

    • Separate prefill (compute bound) and decode (memory bound) onto different servers so they can be tuned/scaled independently.
    • Requires a load balancer that rewrites/merges decode stream responses and performs token‑aware load balancing across endpoint pools.
    • Observed p90 time‑per‑token improved from ~100 ms to ~20–30 ms at scale.

  • Prompt caching and session affinity

    • Use x-session-affinity header to route requests to existing cached input tensors; Cloudflare incentivizes use with discounted cached tokens.
    • Worked best with agent harnesses (e.g., OpenCode); cache hit ratio improved from ~60% to ~80% during peaks.
    • Recommendation: clients should emit session affinity to reduce recompute and GPU count.

  • KV‑cache sharing and storage tiering

    • Leverage Mooncake Transfer Engine (RDMA: NVLink / NVMe over Fabric) + Mooncake Store to move KV caches across nodes and extend cache to NVMe.
    • Integration with LMCache/HiCache enables reusing prefilled caches without strict session‑aware routing inside a cluster.
    • Result: longer session retention in cache and more even load balancing.

  • Speculative decoding

    • Use a smaller draft model (EAGLE‑3) to propose multiple future tokens per forward pass; target model validates choices to reduce compute cost.
    • Tuning knob: number of future tokens from the draft model — tradeoff between throughput and rejection rate.
    • Especially effective for predictable, structured outputs and frequent tool calls.

  • Infire inference engine

    • Rust-based engine extended for multi‑GPU (pipeline, tensor, expert parallelism) and optimized for low activation/memory overhead.
    • Enables running large models (e.g., Kimi K2.5 on 8x H100) with extra GBs left for KV cache; example: Llama 4 Scout on 2x H200 with >56 GiB free for cache.
    • Faster cold starts (<20 s), and up to ~20% higher tokens/sec on unconstrained systems.

  • Practical guidance for engineers

    • For input‑heavy/agent workloads, prioritize PD disaggregation and prompt caching on clients.
    • Add x-session-affinity to harnesses to reduce GPU requirements and lower latency.
    • Use KV‑sharing (RDMA/Mooncake) and NVMe spillover to increase cache lifetime and balance within clusters.
    • Tune speculative decoding token lookahead per model and workload to maximize throughput without undermining quality.

This foundation is designed to let teams run extra‑large models more efficiently across heterogeneous hardware while keeping tail latencies and cost under control.

Full Translation

Translations

A translation section that keeps the flow of the original article.

openaijamodel: gpt-5-mini-2025-08-07

超大型言語モデルを実行するための基盤構築

概要

エージェントは大規模言語モデル（LLM）により駆動されます。数週間前、Workers AI が Moonshot の Kimi K2.5 のような大きなオープンソースモデルのホスティング領域に正式参入したことを発表しました。それ以来、Kimi K2.5 を 3x 高速化し、さらに多くのモデル追加を進めています。これらのモデルは、今週ローンチした多くのエージェント系プロダクトやハーネス、ツールの中核となっています。

AI モデルのホスティングは興味深い課題で、ソフトウェアと非常に高価なハードウェアの綱渡りを要します。Cloudflare では、巧みなソフトウェア工学でハードウェアの効率を最大限に引き出すことに長けています。本稿は、超大型言語モデルを動かすための基盤をどのように構築しているかの詳細解説です。

ハードウェア構成

前回の Kimi K2.5 ブログで述べたように、モデルの提供に最適化するために複数のハードウェア構成を使用しています。多くの構成は、ユーザーがモデルに投げる入力（input tokens）と出力（output tokens）のサイズに依存します。

  • ファンフィクション生成のように、入力は少量で出力が大量になるケース
  • 要約タスクのように、入力が数十万トークンで出力は数千トークン程度のケース

これらの対立するユースケースに対して、入力トークン処理を速くするか、出力生成を速くするかを選択する必要があります。Workers AI の主要ユースケースはエージェント系であり、エージェントでは大きな入力コンテキスト（system prompt、ツール、MCPs 等）を送り、会話が続くごとに文脈が増えていきます。したがって、Workers AI では以下の2点に注力しました。

  • 高速な入力トークン処理
  • 高速なツール呼び出し

Prefill decode (PD) の分離（disaggregation）

一つの改善策は prefill の分離です。LLM リクエストの処理は通常2段階あります：

  1. prefill（入力トークンを処理して KV キャッシュを作る）— 通常は compute-bound
  2. decode（出力トークンを生成する）— 通常は memory-bound

同じマシンで両方を実行するとステージが互いにブロックし、GPU リソースを効率的に使えません。PD 分離では、各ステージを別々の推論サーバとして動かします。まず prefill サーバにリクエストを送り KV を作成・保持し、その後 decode サーバに同じリクエストを送り、KV キャッシュ転送の情報を渡してデコードを開始します。

このアーキテクチャの利点：

  • 各サーバを役割ごとに独立してチューニング可能
  • 入力重視／出力重視トラフィックに応じてスケール可能
  • 異種ハードウェア上での運用が可能

ただし、複雑なロードバランサが必要です。decode サーバのレスポンス（SSE を含むストリーミング）を書き換えて prefill 側のキャッシュ情報を含める必要があり、KV 転送の開始に必要な情報は推論サーバごとに異なります。さらに、トークン量を考慮したトークンアウェアなロードバランシングを実装し、prefill/decode の各エンドポイントに対してインフライトの prefill/decode トークン数を推定して負荷を均等に分散しています。

公開モデルのローンチ後、入出力パターンはさらに変化しました。新しい利用状況を解析し、構成を調整した結果、同じ数の GPU を使いながら PD 分離アーキテクチャにトラフィックを移行した後、p90 Time to First Token が大幅に低下しました（リクエスト量は増加）。テールレイテンシの分散が顕著に改善し、p90 のトークン当たり時間は高分散で約100msから 20–30ms と約3x 改善しました。

プロンプトキャッシュ

エージェント系では長いコンテキストが普通なので、毎ターン入力テンソルを再計算しないよう効率的なプロンプトキャッシュを最適化しています。x-session-affinity というヘッダを利用して、既に計算済みの入力テンソルを持つリージョンへリクエストをルーティングするのに役立てています（Workers AI ローンチ時のブログでも解説）。

OpenCode のような主要なエージェントハーネスに session affinity ヘッダを追加したところ、総スループットが顕著に増加しました。ユーザー側の小さなプロンプトキャッシュの差が必要な追加 GPU 数に大きく影響します。社内では KV-aware ルーティングを持ちつつも、クライアントが x-session-affinity を明示的に送ることに依存しています。キャッシュ済みトークンに対して割引を提供することでヘッダの利用を奨励しています。

結果として、最も重い内部ユーザーと協働してこのヘッダを採用したところ、ピーク時の入力トークンのキャッシュヒット率が 60% から 80% に上昇しました。これによりリクエストスループットが大幅に増え、OpenCode や AI コードレビューのようなインタラクティブ／時間制約のあるセッションで性能が向上しました。

KV-cache 最適化

大きなモデルをサーブする際、1 インスタンスが複数 GPU にまたがることがあります。KV cache（prefill の結果である入力テンソル群）は最初 GPU の VRAM に置かれますが、インスタンスが複数 GPU を使う場合は GPU 間で KV を共有する仕組みが必要です。

Kimi では Moonshot AI の Mooncake Transfer Engine と Mooncake Store を活用しました。Mooncake Transfer Engine は高性能データ転送フレームワークで、NVLink や NVMe over Fabric といった RDMA プロトコルを用い、CPU を介さずにメモリ間転送を行います。これによりマルチGPU・マルチノード構成でのデータ転送速度が向上します。

LMCache や SGLang HiCache と組み合わせることで、クラスタ内の全ノードでキャッシュを共有し、ある prefill ノードが別ノードで事前に生成されたキャッシュを識別して再利用できます。これによりクラスタ内でのセッションアウェアなルーティングが不要になり、トラフィックのロードバランスが容易になります。Mooncake Store は GPU VRAM を越えて NVMe ストレージにキャッシュを拡張できるため、セッションがキャッシュに残る時間を延ばしキャッシュヒット率を改善します。

Speculative decoding（推測デコード）

LLM は前のトークン列に基づいて次のトークンを予測します。通常は次の n トークンだけを予測しますが、1 回のフォワードパスで n+1、n+2… と複数の未来トークンを同時に予測することが可能で、これを speculative decoding と呼びます（Workers AI の以前の記事でも解説）。

speculative decoding では小さめの LLM（draft model）を使っていくつかの候補トークンを生成し、ターゲットモデルはその小さな候補プールから選択するだけになります。候補の検証は大きなターゲットモデルで生成するよりも速く、計算コストが低いです。品質は最終的にターゲットモデルが候補を受け入れる／拒否することで担保します。

エージェント系ではツール呼び出しや構造化出力が多く、推測デコードの効果が特に顕著です。ツール呼び出しは比較的予測可能（名前や説明があり JSON でラップされる）なため効率的に扱えます。Kimi K2.5 では NVIDIA の EAGLE-3（Extrapolation Algorithm for Greater Language-model Efficiency）を draft model に利用し、生成する未来トークン数を調整することで品質を維持しつつ tokens-per-second を高速化しています。

Infire：当社独自の推論エンジン

2025 年の Birthday Week に発表した通り、Cloudflare には Infire という独自の推論エンジンがあり、機械学習モデルを高速化します。Infire は Rust で書かれ、グローバルに分散したネットワーク特有の推論課題に対応するよう設計されています。今回の超大型モデル群に対応するために、いくつかの新機能を追加しました。

マルチGPU サポート

Kimi K2.5 のような 1 trillion parameters 超のモデルは約 560GB のモデル重みがあり、典型的な H100 は約 80GB の VRAM を持つため、少なくとも 8 台の H100 がモデルをロードして実行するのに必要です（KV cache 用の追加 VRAM は別途必要）。Infire にはマルチGPU サポートを追加し、pipeline-parallel、tensor-parallel、expert-parallelism をサポートします。

  • pipeline parallelism：パイプラインの各ステージを適切にロードバランスしてあるステージが枯渇しないようにする
  • tensor parallelism：GPU 間通信を削減して高速化する

多くのモデルでは pipeline と tensor の両方を併用することがスループットとレイテンシのバランスで最良です。

さらに低いメモリオーバーヘッド

vLLM よりも既に低い GPU メモリオーバーヘッドを持つ Infire をさらに最適化し、活性化関数など内部状態に必要なメモリを締め上げました。現在の Infire は Llama 4 Scout を H200 2 台で稼働させ、KV-cache に 56 GiB 以上を残すことができ、これで 1.2M トークン以上を扱えます。Kimi K2.5 は 8 台の H100 で実行可能（注：H100）で、KV-cache に 30 GiB 以上を確保できます。これらの場合、vLLM ではそもそも起動できないことが多いです。

より速いコールドスタート

マルチGPU 対応の追加と併せ、ブート時間の短縮機会を見出しました。Kimi K2.5 のような最大級モデルでも、Infire はドライブ速度に依存するものの 20 秒未満でリクエストを受け始められます。

ハードウェア最大化とスループット向上

独自推論エンジンへの投資により、制約の少ないシステムでは tokens-per-second を最大で 20% 向上させ、従来では実行不可能だった低スペックハードウェアで最新モデルを動かすことを可能にしています。

おわりに（Journey doesn’t end）

新技術、研究、モデルは継続的に登場します。我々の取り組みはここで終わらず、ソフトウェア側の最適化とハードウェア選定を両輪に、より効率的でスケーラブルな大規模モデルホスティング基盤を作り続けていきます。