Cloudflareが1兆パラメータAIを動かす技術 FP8とINT4量子化の中身

705GBあるモデルの重みを421GBまで削って、精度の落ち幅はベンチマーク全体で0.8ポイント以内。

Cloudflareが公開した実測値がこれで、数字を見た瞬間に手が止まりました。

KVキャッシュの持ち方を変えただけでコンテキストが倍になる話まで含めて、中身を分解します。

Cloudflareが公開した巨大モデル運用の中身

2026年8月3日、CloudflareがWorkers AI上でKimi K2.6とGLM 5.2をどう現実的なコストで捌いているかを公開しました。

最初に整理しておきたいのが、この2モデルの規模です。

ひとまとめに「1兆パラメータ級」と呼ばれがちですが、中身はけっこう違います。

どちらもMoE(Mixture of Experts)構成なので、推論のたびに全パラメータが火を噴くわけではありません。

Kimi K2.6は1兆のうち320億だけがトークンごとに動きます。

ただし重みは全部GPUメモリに載せておく必要があるので、必要なメモリ量は総パラメータ側で決まる。

計算量は320億相当なのに、メモリは1兆相当を要求される。

このギャップが今回の話の出発点です。

FP8量子化とは KVキャッシュを半分にしてコンテキストを倍にする仕組み

モデルがテキストを生成するとき、処理済みの全トークンについてアテンションのキー(K)とバリュー(V)を保存しておきます。

これがKVキャッシュで、あるおかげで新しいトークンを1個吐くたびに全文を読み直さずに済む。

裏を返すと、会話が長くなるほどキャッシュは膨らみ続けます。

デフォルトではこのキャッシュを16ビット精度(BF16)で持っています。

CloudflareはこれをFP8のe4m3形式、つまり8ビットの浮動小数点に落としました。

1トークンあたりの記憶サイズが単純に半分になります。

で、浮いたメモリで何が起きるか。

Kimi K2.6がメモリに保持できるコンテキストが、約686,000トークンから約137万トークンへ、ちょうど倍になりました。

「キャッシュを削ったのに容量が増える」と一瞬ねじれて見えますが、削ったのは1トークンあたりのサイズで、増えたのは同じメモリに入るトークン数です。

1件が軽くなった分、同じGPUに倍の会話を同時に載せられる。

ここがFP8化の狙いです。

INT4量子化とは 705GBのモデルを421GBに縮める仕組み

FP8がキャッシュ側の話だったのに対して、INT4は重み側の話です。

GLM 5.2の重みを8ビット浮動小数点から4ビット整数(INT4)まで落とす。

結果、チェックポイントが705GBから421GBに縮みました。

削減率にして約40%です。

効いてくるのはここからで、8枚のGPUに分散して載せる構成だと、GPUあたりのメモリ使用量が約88GBから52GBまで下がります。

1枚あたり36GB空く。

その空きに何を入れるかというと、さきほどのKVキャッシュです。

GLM 5.2で約118万トークン分が載ります。

重みを削る、GPUに空きができる、空きをキャッシュに回す、同時に捌けるリクエストが増える。

この連鎖が量子化の本丸で、単なるファイルサイズ削減の話ではないのがミソです。

速くなる場所と遅くなる場所 並行数別の実測値

ここ、マジでおもしろいんですが、量子化は「全部速くなる」わけじゃありません。

GLM 5.2のデコード性能、つまりトークンを吐く速さをFP8とINT4で並べた実測値がこれです。

全域でINT4が勝っていて、特に並行1での+55%が目立ちます。

デコードはメモリ帯域が律速なので、読み込む重みが軽いほど素直に速くなる。

一方でプレフィル、つまり入力を読み込む処理のほうは逆に遅くなります。

FP8が毎秒10,160トークンなのに対して、INT4は8,660トークン。

理由は明快で、INT4に潰した重みは掛け算の前に元の精度へ展開し直す必要があるからです。

その展開コストがそのまま乗ってくる。

長いプロンプトを一気に読ませる用途ではINT4が不利、長い出力を吐かせる用途では有利。

ここ、知らずに選ぶと罠です。

Kimi K2.6側のFP8 KVキャッシュも傾向は同じでした。

64並行で毎秒2,192トークンとBF16のピークより約41%高く、トークンあたりのコストは約30%安い。

ただし単発のリクエストだとBF16のほうが数パーセント速い。

同時実行が多いほど量子化が効く、という構造になっています。

精度はどこまで落ちたのか

僕が真っ先に確認したのがここでした。

「で、頭は悪くなってないの?」という話です。

Cloudflareが回したベンチマークはGSM8K、ARC-Easy、ARC-Challenge、MMLUの4本。

INT4版とFP8版の差は、全ベンチマークで0.8ポイント以内に収まりました。

0.8ポイントは実運用でまず区別がつかない水準です。

モデルサイズを40%削ってこれしか落ちない、というのが今の量子化技術の到達点。

ただし念のため書いておくと、これは提供側の自己測定値です。

推論の重い用途や日本語まわりで同じ差に収まる保証まではないので、本番に載せる前に自分のタスクで確かめる価値はあります。

メモリを共有すると起きる問題とその対策

FP8にしろINT4にしろ、やっていることは1枚のGPUメモリをより多くのリクエストで分け合えるようにすることです。

効率は上がりますが、代償として1つの物理KVキャッシュに数百のリクエストが同時に読み書きする状況が生まれます。

怖いのは、あるリクエストが別のリクエストのキャッシュページを読んでしまうケース。

他人の会話が混ざって返る事故です。

Cloudflareの対策は、物理ページごとにタグを振ることでした。

ページが再割り当てされるたびにタグが変わり、サーバー側は「このリクエストはどのページのどのタグを使うはず」を記録しておく。

デコード処理がキャッシュを読む直前にこの対応関係を検証して、食い違ったらそのリクエストを中断します。

間違ったページの中身を返すくらいなら落とす、という判断です。

派手さのない仕組みですが、他人と同じGPUを共有して推論を借りる立場からすると、ここが一番の安心材料になります。

開発者側から見て何が変わるか

Workers AI上ではKimi K2.6とGLM 5.2の両方がすでに使えます。

Kimi K2.6は262.1kトークンのコンテキストウィンドウで、関数呼び出しと推論と画像入力に対応。

GLM 5.2はエージェント型のコーディングを前面に出したモデルです。

Workers AI Models

Browse the catalog of machine learning models available on Workers AI.

developers.cloudflare.com

実務で効いてくるのは3点です。

1. 長い入力が通りやすくなる。KVキャッシュが半分になった分、同じインフラで長いコンテキストを流せる
2. 同時実行が多いほど得をする。単発の速度で比べると量子化の恩恵は小さく、並行数が上がるほど差が開く
3. 自前でGPUを並べなくても1兆パラメータ級に手が届く。705GBのモデルを個人や小規模チームで載せるのは、まず現実的じゃない

Cloudflare側は次の手として、FP8 KVキャッシュを他の環境へ広げること、Blackwell世代でNVFP4という4ビット浮動小数点の重みを検証すること、整合性チェックを常時オンにできるようコストを下げることを挙げています。

Smaller, faster, safer: running Kimi and GLM at scale

Serving frontier models like Kimi and GLM means fighting for GPU memory. Here's how we quantize KV caches, compress model weights, and add integrity checks to serve them faster, cheaper, and safely.

blog.cloudflare.com

巨大なモデルを作ることと、それを安く動かすことは、まったく別の技術です。

前者の競争はニュースになりますが、僕らが実際に払う値段と待ち時間を決めているのは後者のほうです。

705GBが421GBに縮んで、精度は0.8ポイントしか落ちない。

この積み上げのほうが、来月の請求書には効いてきます。