Cloudflareは、Workers AIで大型オープンモデルを高速に提供するための効率化手法を公式ブログで公開しました。
対象はMoonshotのKimiシリーズとZ.aiのGLMなど、能力が高くメモリ要求も厳しい長文脈のMixture-of-Experts（MoE）モデルです。精度を落とさず、より多くのリクエストを低いコストで捌くための実測付きの解説になっています。
この記事では、公開された3つの手法と、企業・開発者が押さえておきたいポイントを整理します。
公式の説明はCloudflare Blog（https://blog.cloudflare.com/smaller-faster-safer-models/ ）で確認できます。
何が難しいのか
Workers AIは、世界各地のCloudflareデータセンターにあるGPUで推論を回し、ユーザーに近い場所でモデルを提供します。
一方でKimiやGLMのような大型・長文脈モデルは、GPUメモリの制約がボトルネックになりやすいです。重みだけでなく、会話を伸ばすためのKVキャッシュがメモリを圧迫します。
Cloudflareはこれまでも、推論のprefill（文脈読み込み）とdecode（トークン生成）を分離してGPUを効率使う設計を公開してきました。今回はその上に、次の3層を重ねた内容です。
- KVキャッシュの量子化（FP8）
- モデル重みの圧縮（INT4）
- 共有キャッシュの完全性検証
手法1：KVキャッシュをFP8に
モデルが文章を生成するとき、すでに処理したトークンの注意キー（K）と値（V）をKVキャッシュに保存します。長文脈モデルでは、重みより先にこのキャッシュがGPUメモリを埋めがちです。
通常はBF16で持つところを、FP8（e4m3）で持つことでサイズを半分にしています。Kimi K2.6では、保持できるコンテキストが約68.6万トークンから約137万トークンへ、およそ2倍になったとされています。
単発の速度そのものより、「同時に何件のリクエストをメモリ上に置けるか」がポイントです。BF16は同時32件付近でメモリ不足になる一方、FP8は64件まで伸ばせ、ピークスループットは約41%高く、トークンあたりコストは約30%下がったと説明されています。
ベンチマーク上も、GSM8KやMMLUなどでBF16とFP8の差はほぼ誤差範囲。回答品質を変えずに収容力を上げる、という位置づけです。
手法2：重みをINT4に圧縮
もう一方のメモリ消費はモデル重みです。GLM 5.2では、重みをFP8からINT4へ圧縮し、チェックポイントを705GBから421GBへ約40%削減したとしています。
8-wayテンソル並列では、GPUあたりメモリが約88GBから約52GBへ下がり、同じハードウェアで約118万トークン分のKVキャッシュ余地が生まれる計算です。
decodeは「毎回重みをメモリから読み出す」ため帯域律速になりやすく、データ量が減るとトークン生成が速くなります。低同時実行では最大約+55%の高速化例も示されています。
一方prefillは計算律速で、INT4は展開コストが増えて遅くなるため、CloudflareはdecodeをINT4、prefillをFP8と使い分ける方針です。精度差も各ベンチで0.8ポイント以内と説明されています。
手法3：共有キャッシュの完全性検証
上記2つはどちらも「1枚のGPUに、より多くのリクエストを載せる」効果があります。そのぶん、数百のリクエストが同じ物理KVキャッシュのページを読み書きするリスクも増えます。
paged attentionやcontinuous batching、キャッシュ再利用は正確な管理が前提で、ごくまれな取り違えでも大規模トラフィックでは無視できません。
そこでCloudflareは、物理キャッシュページに再割当のたびに変わるタグを付け、各リクエストが期待するページとタグを記録。decode前に照合し、不一致なら誤データを返す前にリクエストを中断する仕組みを入れています。
オーバーヘッドはスループット・テールレイテンシともおおむね1%未満。検証はattentionカーネルに埋め込まず別バッチで行い、必要ないデプロイではほぼゼロコストの経路も用意されているとのことです。
企業・開発者が考えるべきこと
これは「巨大モデルを安く速く出す」話であると同時に、AI導入側の設計判断にも効きます。
- モデル名だけでなく、推論基盤のメモリ設計・量子化方針を見る
- 長文脈・同時利用者数・コストのどこがボトルネックかを先に決める
- prefillとdecodeで最適条件が違う前提で、用途を分ける
- 共有キャッシュやバッチ処理では、正しさの検証コストも設計に含める
- 精度維持の根拠（ベンチ・社内評価）をベンダーや自前運用で確認する
社内システムやWebサービスにAIを載せるときも、「どのモデルか」だけでなく「どう配信し、どう監視するか」が成果とコストを分けます。
AI導入とインフラ設計
Cloudflareの公開は、フロンティア級のオープンモデルをエッジGPUで安定提供するための実務知見です。今後はFP8 KVの拡大、Blackwell向けNVFP4重みの検証、完全性チェックの常時ON化などが続く方針とされています。
Makoto Tejimaでは、最新のAIモデル活用とあわせて、既存システム連携、権限・監視、コスト設計まで含めた導入支援をしています。
社内AI、エージェント導入、既存WebシステムへのAI追加など、進め方のご相談があればお気軽にご連絡ください。
まとめ
Cloudflareは、KimiやGLMのような大型・長文脈モデルをWorkers AIで効率よく動かすため、FP8のKVキャッシュ、INT4の重み圧縮、共有キャッシュの完全性検証という3つの手法を公開しました。
共通する狙いは、精度を維持したままメモリ制約を緩め、同時処理とコスト効率を上げることです。AI導入でも、モデル選定と推論基盤の設計はセットで見る必要があります。
AIを使ったシステム開発や、コストと安定性を両立した導入設計、見積や進め方のご相談などがありましたら、お気軽にお問い合わせください。
