Cloudflare が超巨大 LLM の土台を作ったよ！Kimi K2.5 を 3 倍速にした秘密！

やっほー、しぃちゃんだよ！今日はね、Cloudflare が「めちゃくちゃ大きい LLM をどうやって速く動かしてるの？」っていう裏側を全部見せてくれた記事を見つけちゃった。ワクワクが止まらないよ！

Cloudflare Blog blog.cloudflare.com

なにが発表されたの？

Cloudflare の Blog が、超巨大な大規模言語モデル(LLM)を自社インフラで効率よく動かすための、独自の技術スタックを作ったって発表したの。とくにエージェント用途に最適化してあって、前回紹介した Kimi K2.5 を、なんと 3 倍速くしちゃったんだって！

Kimi K2.5 は 1 兆パラメータ超え、重みだけで約 560 GB もある、とんでもなく大きいモデルなの。これを動かすには最低でも H100 GPU が 8 枚(1 枚あたり VRAM 80 GB)必要で、それでも KV キャッシュ用に 30 GB 以上の余りが残る計算だよ。ちなみに Llama 4 Scout なら H200 GPU 2 枚で動いて、120 万トークン以上を扱えるんだって。

なぜ重要なの？

モデルがどんどん大きくなると、1 枚の GPU には全然乗り切らなくなっちゃう。しかもエージェントの時代は、ツール呼び出しや長いコンテキストで「速さ」がすごく大事になるの。ただ動かすだけじゃなくて、遅延を小さく・安定させて、コストも抑える——そのための土台づくりが今回のお話だよ。

これで何が変わるの？

いちばん分かりやすいのは速さ。トークンあたりの生成時間(p90)が、だいたい 100 ms から 20〜30 ms へ、つまり 3 倍速くなったの。最初の 1 文字が返ってくるまでの時間(TTFT)もブレが小さくなって、体感がグッと良くなるよ。

しかもプロンプトキャッシュのヒット率が、混雑時でも 60 % から 80 % まで上がったんだって。キャッシュに当たったトークンは割引価格になるから、お財布にもやさしいの。

深く潜ってみよう

Cloudflare がやってる工夫を、かいつまんで紹介するね。

Prefill と Decode の分離(PD Disaggregation) 推論は、入力を読み込む prefill(計算が重い)と、出力を 1 トークンずつ作る decode(メモリが重い)の 2 段階に分けられるの。この 2 つを別々のサーバーに分けて、それぞれに合わせてチューニング。さらにトークン量を見た負荷分散もして、遅延を安定させてるよ。

プロンプトキャッシュ プロンプトキャッシュ では、x-session-affinity ヘッダーを使って、入力テンソルがキャッシュされているリージョンにリクエストを送るの。当たれば安く・速くなるってわけ。

KV キャッシュの共有 Moonshot AI の Mooncake(Transfer Engine と Store)を使って、複数 GPU 間で KV キャッシュを共有。NVLink や NVMe over Fabric みたいな RDMA で CPU を経由せずにメモリを転送して、GPU の VRAM を超えて NVMe ストレージまでキャッシュを広げられるの。

投機的デコード(Speculative Decoding) 小さなドラフトモデル(NVIDIA の EAGLE-3)が候補トークンを先に作って、本命モデルが 1 回のフォワードでまとめて検証するの。ツール呼び出しや構造化出力でとくに効くんだって。

Infire そして極めつけが Infire っていう Rust 製の自社推論エンジン。パイプライン並列・テンソル並列にエキスパート並列も組み合わせて、メモリのオーバーヘッドをすごく抑えつつ、いちばん大きいモデルでもコールドスタートが 20 秒未満なの。制約のないシステムなら、スループットが 20 % 高いって主張してるよ。

まとめ

• Cloudflare が超巨大 LLM をエージェント向けに速く動かす技術スタックを公開、Kimi K2.5 は 3 倍速に
• PD 分離・プロンプトキャッシュ・KV キャッシュ共有・投機的デコード・自社エンジン Infire を組み合わせ
• トークン生成(p90)は約 100 ms → 20〜30 ms、キャッシュヒット率は 60 % → 80 % に改善
• Kimi K2.5(約 560 GB)は H100 が 8 枚から動く

エージェントを本番で回したい人や、大規模モデルの推論最適化に興味があるエンジニアにグッと刺さる内容だよ！