CloudflareのKimiとGLMを提供するためのレシピ：KVキャッシュの量子化、重みの圧縮、キャッシュの検証

MoonshotのKimi KシリーズやZ.aiのGLMのような大規模混合専門家モデルを共有GPUインフラで実行することは、速度の問題である前にメモリの問題です。CloudflareのWorkers AIチームは、既存の分離されたプリフィル/デコード設定に重ねた3つの技術でこの問題に取り組んでいます：KVキャッシュの量子化、モデル重みの圧縮、そしてこれらの最適化が可能にする共有キャッシュの安全チェックの追加です。

FP8 KVキャッシュでコンテキスト容量が2倍に

KVキャッシュ—処理された各トークンのアテンションキーと値を格納する構造—は、通常、重みではなくGPUメモリを最初に満たすものです。Cloudflareはこれをデフォルトの16ビット（BF16）ではなく8ビット浮動小数点（FP8、e4m3）で格納し、サイズを半分にします。Kimi K2.6の場合、メモリに収まるコンテキストが約686,000トークンから約137万トークンに増加します。

キャッシュの量子化は生の速度向上ではありません—FP8アテンションカーネルはトークンごとに少し余分な変換作業を行うため、BF16は任意の同時実行レベルで数パーセント高速です。利点は容量です：BF16は32の同時リクエストでキャッシュが尽きますが、FP8は64まで続き、毎秒2,192トークンに達し、BF16のピークより約41%高く、トークンあたりのコストは約30%低くなります。プリフィルはメモリではなく計算に制約されるため、CloudflareはそこではキャッシュをBF16のままにし、FP8はデコードプールにのみ適用します。

精度は維持されます。GSM8K、ARC、MMLU、MMLU-Pro、および内部ベンチマーク全体で、FP8とBF16のキャッシュは統計的に区別できません。

INT4重みでGLM 5.2を40%縮小

GLM 5.2では、Cloudflareは重みを8ビット浮動小数点から4ビット整数（INT4）に圧縮します。チェックポイントは705 GBから421 GBに減少し、8ウェイテンソル並列デプロイメント全体のGPUあたりのメモリは約88 GBから52 GBに低下—同じハードウェア上に約118万トークンのKVキャッシュの余地を残します。

重みが小さくなるとデコードが速くなります。各トークンの生成はメモリから重みをストリーミングすることを意味し、デコード速度は帯域幅に制約されるからです。低同時実行では効果は劇的です：単一リクエストのスループットは毎秒60から92トークンに跳ね上がり、55%の向上です。高同時実行では向上は16〜27%に落ち着きます。プリフィルは計算に制約されるため、INT4では実際には遅くなります（FP8の10,160トークン/秒に対して8,660）。そのため、分離された設計により、CloudflareはデコードにはINT4、プリフィルにはFP8を実行できます—それぞれが勝つ場所で。精度はすべてのベンチマークでFP8の0.8ポイント以内に保たれます。

共有キャッシュの保護

両方の最適化により、同じGPUにより多くのリクエストが詰め込まれ、数百のリクエストが同じ物理KVキャッシュのページを読み書きすることになります。ページ化アテンション、連続バッチ処理、キャッシュ再利用はすべて完璧な台帳管理に依存しています。Cloudflareのリクエスト量では、10億分の1のミスでも定期的に表面化するでしょう。

彼らの防御策：すべての物理キャッシュページには再割り当て時に変更されるタグが付けられ、サーバーは各リクエストが期待するページとタグを記録します。サポートされているデコード操作がキャッシュから読み取る前に、マッピングがチェックされ、不一致があれば、間違ったページからデータを返すのではなく、リクエストを中止します。コストは、8,192トークン入力と1,000トークン出力の本番モデルで測定したところ、スループットとp95レイテンシの両方で1%未満です。チェックはアテンションカーネルに融合されるのではなく、別のバッチ検証として実行され、GPUスレッドグループ間の競合を回避します。これはデプロイメントごとに有効になり、デフォルトのno-opトラッカーはオーバーヘッドがゼロです。

次のステップ

CloudflareはFP8 KVキャッシュをフリートのさらに多くの場所に拡大し、BlackwellでのNVFP4重みを検証し、整合性チェックを無視できるコストでどこでも有効のままにすることを目指しています。この作業は、彼らが使用し貢献しているオープンソースのサービングフレームワークであるSGLangにアップストリームされています。