Cloudflare、巨大AIモデルをGPUで効率的に動かす3つの技術

問題巨大モデル、さらに大きなメモリ需要

GPUで大規模MoEモデルを動かすのはメモリのパズルゲームです。モデルの重みが場所を取り、KVキャッシュ——各トークンのアテンションキーとバリューを保存するスクラッチパッド——はさらに多くの場所を取ります。Kimi K2.6やGLM 5.2のような長コンテキストモデルでは、KVキャッシュが先にGPUメモリを消費し、1つのGPUを共有できるリクエスト数が制限されます。

Cloudflare Workers AIチームは、分離型プリフィル-デコードアーキテクチャに積み重ねる3つの最適化技術を詳述。すべての実験はSGLang上で実行され、パッチはオープンソースに還元されています。

技術1KVキャッシュ量子化（FP8）

デフォルトのKVキャッシュは16ビットBF16精度で保存されます。Cloudflareは8ビットFP8（e4m3）に変更し、サイズを半減。Kimi K2.6のコンテキスト容量が約68.6万トークンから約137万トークンに倍増します。

FP8アテンションカーネルは読み取り時に値の変換が必要なため、個々のリクエストは数%遅くなります。しかし真のメリットはキャパシティ。64同時リクエスト時、FP8は毎秒2192トークン——BF16のピーク1558より41%高い——を達成し、トークンあたりのコストは約30%低減。

同時リクエスト数	BF16 KV (tok/s)
1	137
8	731
16	1,106
32	1,558
64	メモリ不足

技術2重み圧縮（INT4）

GLM 5.2の重みを8ビットFP8から4ビットINT4に圧縮。チェックポイントが705GBから421GBに縮小（40%削減）、8ウェイテンソル並列でGPUあたりのメモリが約88GBから52GBに低下。

同時リクエスト数	GLM FP8 (tok/s)
1	60
8	425
16	683
32	994
64	1,672

分離型アーキテクチャにより、デコードはINT4、プリフィルはFP8——両方の長所を活かせます。精度の差は0.8ポイント以内。

技術3KVキャッシュ完全性保護

数百のリクエストが1つのGPUキャッシュを共有する際、ページ化アテンション、連続バッチ処理、キャッシュ再利用といったメカニズムは完全な台帳管理に依存します。Cloudflareのリクエスト量では、10億分の1の確率のエラーでも定期的に発生します。

解決策：各物理キャッシュページに、再割り当て時に変更されるタグを割り当てます。デコード操作がキャッシュを読み取る前に、サーバーはタグの一致を確認。一致しない場合はリクエストを中止します。

同時実行数	スループット変化
1	−0.53%
2	−0.38%
4	−0.79%
8	−0.43%

オーバーヘッドは1%未満。チェックは独立したバッチ操作として実行され、アテンションカーネルに融合されることなく、GPUスレッドグループ間の競合状態を回避します。

今後カバレッジ拡大

CloudflareはFP8 KVキャッシュをフリート全体に拡大し、BlackwellでNVFP4重みを検証し、完全性チェックを無視できるコストでデフォルト化することを目指しています。

これらの最適化はすでに本番稼働中。Cloudflareは精度を変えず、より低いコストでより多くの顧客をサポートできる。