本記事の執筆には Anthropic の Claude とそのリサーチ機能を使用しています。
はじめに
2026年8月3日、Cloudflareがエンジニアリングブログで「Smaller, faster, safer: running Kimi and GLM at scale」を公開しました。Workers AI 上で Moonshot AI の Kimi K2.6(総パラメータ1兆)と Z.ai の GLM 5.2(同744B)という巨大 MoE モデルを商用サービスとして回すために、どんな最適化を入れたかを H200 実測値付きで開示した内容です。
オープンウェイトモデルは「重みファイルが手に入る」だけでは仕事をしてくれません。1兆パラメータ級ともなると、どう置き、どう削り、どう詰め込むかという運用レイヤの設計がコストと品質を決めます。この記事はその運用ノウハウを、スループット表・精度ベンチ・オーバーヘッド計測まで含めて公開している点で貴重です。
本記事では技術的な要点を整理した上で、「ローカルLLM運用者が何を持ち帰れるか」「どこを鵜呑みにすべきでないか」まで踏み込みます。Cloudflare の打ち手は次の3つに整理できます。
| 打ち手 | 対象 | 主な効果 | 副作用・条件 |
|---|---|---|---|
| ① KVキャッシュ FP8化(e4m3) | decode 側の KV | 保持コンテキスト2倍、64並列で +41% スループット | 低並列では BF16 比 数%遅い |
| ② 重み INT4化 | decode 側の重み(GLM 5.2) | 705GB→421GB、低並列 decode 最大 +55% | prefill では逆効果 |
| ③ ページ整合性チェック | 共有 KV キャッシュ | 誤ページ読み出しを abort で防止 | オーバーヘッド 1% 未満(デフォルト無効) |
なお、以下の数値はすべて Cloudflare の自己申告値であり、第三者による再現検証はまだない点を先に断っておきます。
題材となる2つのモデル
| Kimi K2.6 | GLM 5.2 | |
|---|---|---|
| 総パラメータ | 1T | 744B |
| アクティブ/トークン | 32B | 約40B |
| エキスパート数 | 384(選択8+共有1) | 256(選択8+共有1) |
| 層数 | 61 | 78(先頭3層は dense FFN) |
| Attention | MLA | MLA + DSA(sparse) |
| 最大コンテキスト | 262k | 1M |
| 配布時の精度 | INT4(QAT) | FP8 |
両者とも MLA(Multi-head Latent Attention)を採用しています。MLA は KV を潜在空間へ低ランク圧縮する仕組みで、標準的な MHA に比べて KV キャッシュがもともと小さい。つまり後述の FP8 KV 量子化は「MLA で圧縮済みの KV をさらに半分にする」二段構えです。
もう一点、両者で立場が違うのが重みの精度です。Kimi K2.6 は MoE 部分に INT4 の量子化認識学習(QAT)を最初から施した「ネイティブ INT4」のモデル(K2-Thinking 世代からの Moonshot の方針)。一方 GLM 5.2 の配布形態は FP8 で、ここに Cloudflare が事後的に INT4 化を適用した、という関係になります。
Smaller: 「何を」「いつ」削るか
Cloudflare が入れた圧縮は2系統です。
KV キャッシュの FP8 化。 attention の K/V テンソルをデフォルトの BF16 から FP8(e4m3)に量子化。サイズは半分になり、Kimi K2.6 では GPU 上に保持できるコンテキストが約68.6万トークンから約137万トークンへ倍増しました。
モデル重みの INT4 化(GLM 5.2)。 FP8 配布の GLM 5.2 を INT4 に圧縮。チェックポイントは 705GB → 421GB(約40%減)。8-way tensor parallel 構成では GPU あたり約88GB → 約52GB になり、空いた分で約118万トークンぶんの KV キャッシュ余地を確保しています。
本当の肝: prefill / decode 非対称レシピ
個人的にこの記事で一番面白いのはここです。Cloudflare は prefill と decode を別の GPU プールに分離(disaggregation)した上で、フェーズごとに別の数値フォーマットを使っています(図1)。
図1: フェーズごとに数値フォーマットを使い分ける非対称レシピ。prefillは高精度のまま、decodeだけを低ビット化する
| フェーズ | 重み | KVキャッシュ |
|---|---|---|
| prefill(compute-bound) | FP8 | BF16 |
| decode(memory-bound) | INT4 | FP8 |
なぜ prefill では INT4 を使わないのか。prefill は演算律速なので、INT4 重みの展開(dequantize)コストが逆に足を引っ張るからです。実際、GLM 5.2 の prefill は FP8 で約 10,160 tok/s、INT4 だと約 8,660 tok/s に落ちると報告されています。
これはルーフラインモデルで整理すると腑に落ちます(図2)。decode は毎トークン全アクティブ重み+KV を読み出すため演算強度が低く、帯域の傾きの上に乗っている。ここで重みと KV のバイト数を減らすことは、演算強度を引き上げてグラフ上の点を右上に動かすことに等しく、そのままトークンレートに効きます。一方 prefill は大きな GEMM が支配する演算律速領域にいるため、バイト数を減らしても屋根(演算ピーク)は上がらず、展開コストの分だけ損をします。
図2: 「低ビット化=常に速い」ではない。decodeでは効き、prefillでは効かない(むしろ逆効果)ことがルーフライン上の位置から説明できる
「低ビット化=常に速い」ではなく、ボトルネックの種類に合わせてフォーマットを使い分ける。この設計判断を1兆パラメータ級の本番環境で数値実証した点に価値があります。
Faster: 数値で読む
FP8 KV は「速くなる」のではなく「詰め込める」
意外かもしれませんが、FP8 KV は同一並列数ではむしろ BF16 より数%遅くなります(変換コストのため)。効くのは収容数のほうです(図3)。
図3: Kimi K2.6のdecodeスループット(H200実測)。BF16は32並列でメモリ枯渇するが、FP8なら64並列まで積める
実測値の詳細:
| 並列数 | BF16 KV (tok/s) | FP8 KV (tok/s) |
|---|---|---|
| 1 | 137 | 125 |
| 8 | 731 | 689 |
| 16 | 1,106 | 1,028 |
| 32 | 1,558 | 1,489 |
| 64 | メモリ枯渇 | 2,192 |
BF16 は32並列で KV キャッシュが尽きて33本目を受けられません。FP8 なら64並列まで積めて、ノード全体のスループットは BF16 ピーク比で約+41%、トークンあたりコストは約30%減。個々のリクエストを速くする技術ではなく、サービング事業者の経済性を変える技術だ、という位置づけがはっきり分かる数字です。
INT4 重みは低並列ほど効く
decode はメモリ帯域律速なので、毎トークン読み出す重みのバイト数が小さいほど速くなります(図4)。
図4: GLM 5.2のdecode高速化率(H200実測)。1並列で+55%(60→92 tok/s)と、並列数が少ないほど効果が大きい
並列数が上がるとバッチ処理や通信など他の要因が支配的になり、効きが鈍っていきます。逆に言うと「1並列で+55%」という数字は、単一ユーザーで回すローカル推論の条件にかなり近い測定です。ここは後段でもう一度触れます。
Safer: 精度検証と、もう一つの「安全」
タイトルの safer はガードレールの話ではなく、2つの技術的な意味を持っています。
精度検証(とその限界)
1つ目は量子化前後でベンチマークスコアが変わらないことの確認です。
FP8 KV(Kimi K2.6):
| ベンチ | BF16 | FP8 |
|---|---|---|
| GSM8K | 94.24 | 94.09 |
| ARC-Easy | 89.06 | 89.14 |
| ARC-Challenge | 66.72 | 67.49 |
| MMLU | 89.11 | 89.04 |
| MMLU-Pro | 80.29 | 79.29 |
| Tool-call validity | 92.2% | 92.6% |
INT4 重み(GLM 5.2)は FP8 比で全ベンチ 0.8 ポイント程度以内(GSM8K 94.39→93.56、MMLU 86.60→86.54、MMLU-Pro 80.80→80.47)とされています。差分を図にすると次の通りで、最大の低下は Kimi K2.6 の MMLU-Pro の −1.0pt です(図5)。
図5: 量子化前後のスコア差分(Cloudflare自己申告値)。ほぼ±1pt以内に収まるが、評価スイート自体に偏りがある点に注意
ただし、この評価スイートには重大な欠落があります。コーディングベンチ(LiveCodeBench、SWE-bench 系)と長文推論が入っていないのです。K2.6 / GLM 5.2 の主戦場はエージェント・コーディング用途で、そこでは微小な tool call エラーが長時間タスクで累積します。Hacker News でもまさにこの点が突かれていました。KV 量子化への感度はモデルファミリごとに異なるのに1モデルしか検証していない、「精度不変」を主張するならトークン分布の距離(KL divergence 等)で示すべきだ、といった指摘です。
参考までに、vLLM が2026年4月に公開した同種の FP8 KV 検証は LiveCodeBench を評価に含めています。また、長コンテキスト(128k〜256k)では KV 低ビット量子化の誤差が累積し、アグレッシブな設定では大きく劣化しうるという研究報告もあります。「MMLU が変わらない」ことと「エージェントタスクで劣化しない」ことは別問題、と読むのが安全です。
共有 KV キャッシュの整合性チェック
2つ目の safer がこちらで、本番サービングの開示としてはかなり珍しい内容です。
量子化で1GPU に詰め込めるリクエスト数が増えた結果、数百のリクエストが同一の物理 KV キャッシュページ群を、paged attention・prefix cache 再利用・continuous batching 経由で共有することになります。この帳簿付け(bookkeeping)がひとつでも狂うと、あるリクエストが別のリクエストの KV を読んで壊れた出力を返します。Cloudflare のリクエスト規模では10億分の1の確率のミスでも定常的に顕在化するとして、次の防御を入れたそうです(図6)。
- 物理ページごとに、再割り当てのたびに更新されるタグを付与
- 各リクエストは、自分が使うページとタグの組を記録
- decode の読み出し前にタグを照合し、不一致ならそのリクエストを abort
図6: 物理ページの世代タグとリクエスト側の記録をdecode前に照合し、不一致なら壊れた出力を返す前にabortする
attention カーネルには融合させず、別バッチのチェックとして実装(スレッドグループ間の race を避けるため)。オーバーヘッドはスループット・p95 レイテンシとも1%未満と報告されています。なお、デフォルトは no-op トラッカーで無効化されており、常時有効化にはまだ至っていないとのことです。
「そんなバグ実在するの?」と思うかもしれませんが、実在します。SGLang には radix cache のブロック境界で stale な KV ブロックが前のリクエストの prefix として再利用されるバグ報告(#22819)があり、vLLM にも prefix cache の破損事例(#30931、#5543)があります。既存エンジンのブロックハッシュは「同じ prefix かどうか」を判定するためのもので、「割り当てが正しいか」を実行時に検証する機構ではありません。OS のメモリタギングや世代カウンタに相当する仕組みを LLM サービングに持ち込んで本番投入した、という点で新規性のある取り組みだと思います。
推論エンジンは SGLang
運用面でもう一つ注目すべきなのは、Cloudflare がこれらの実験と本番トラフィックをすべてオープンソースの SGLang で回していると明言していることです。自社製の Rust 推論エンジン(Infire)を持っている会社が、巨大 MoE の本番には SGLang を選び、パッチを upstream に還元している。
オープンウェイトモデルの価値は重みそのものだけでなく、周辺の OSS サービングスタックに各社の運用ノウハウが還流するループにある、という良い実例です。
ローカルLLM運用者が持ち帰れること
Cloudflare の話はデータセンター(H200、8-way TP、prefill/decode 分離)の話ですが、支配している物理法則はローカルと同じです。
| Cloudflare の知見 | ローカルでの対応物 |
|---|---|
| decode は帯域律速、重み削減が直接効く | 4bit 級量子化が標準になっている理由そのもの。帯域が1桁細いぶん効きはむしろ大きい |
| 1並列で INT4 が +55% | 単一ユーザーのローカル利用とほぼ同条件の実測値 |
| FP8 KV で保持コンテキスト2倍 | llama.cpp / MLX の KV キャッシュ量子化で長コンテキストを VRAM に収める |
| prefill/decode 非対称レシピ | コンポーネント別の非対称量子化(MoE エキスパートのみ低ビット等)と同じ思想 |
| 量子化条件の開示問題 | API プロバイダ選定時のチェック項目 |
decode が帯域律速なのはローカルも同じ。むしろ効きは大きい。 H200 の HBM 帯域に対して、Apple Silicon のユニファイドメモリやコンシューマ GPU の帯域は1桁近く細い。重みのバイト数削減がそのままトークンレートに効くという構図はローカルでこそ顕著で、ローカル界隈で 4bit 級量子化が標準になっているのはまさにこのためです。図4の「1並列で+55%」は、ローカルの単独利用とほぼ同じ土俵の数字として参考になります。
KV 量子化は「長コンテキストを載せる」ために使う。 FP8 KV の本領は収容数でした。ローカルの単独利用では並列数を稼ぐ意味は薄いですが、「限られた VRAM / ユニファイドメモリに長いコンテキストを収める」という形で同じ恩恵を受けられます。llama.cpp や MLX の KV キャッシュ量子化オプションがこれに相当します。ただし、低並列では BF16 比で数%遅くなるトレードオフも同時に引き継ぐことになります。
非対称レシピの発想。 ローカル単機で prefill/decode の物理プール分離はできませんが、「フェーズやコンポーネントごとに最適フォーマットを変える」という思想自体は応用できます。MoE のエキスパート部だけ低ビットにして attention や共有エキスパートは高精度を保つ、といった非対称量子化はローカル向け推論エンジンでも採られているアプローチで、Cloudflare の設計判断はその妥当性をデータセンター側から裏付けるものと読めます。
量子化の開示を確認する習慣。 逆に、API プロバイダを「使う側」としての教訓もあります。HN では「量子化した事実をモデルページに明記せず、ブログでだけ言うのはどうなのか」という批判がかなり強く出ていました。ホスティングされたオープンウェイトモデルは、同じモデル名でもプロバイダごとに量子化条件が違う可能性がある。エージェント用途で品質差を感じたら、まず量子化条件を疑うべきです。
批判的に読むためのチェックリスト
- 全数値は Cloudflare の自己申告で、ベンチ生データ・評価スイート詳細は非公開
- INT4 の量子化アルゴリズム(GPTQ / AWQ / 独自か)、キャリブレーションデータ、スケール粒度は非開示。他所での再現性は担保されない
- 精度検証にコーディング・長文推論ベンチがない(前述)
- 整合性チェックの「オーバーヘッド1%未満」は特定条件下の測定で、しかもデフォルト無効
- 投機的デコーディング(MTP / EAGLE 系)や expert parallelism の通信など、MoE サービングの重要トピックには触れていない
まとめ
Cloudflare の記事から抽出できる「オープンウェイトモデルの使い方」は、3点に集約できると思います。
- ボトルネックに合わせて削る。 prefill は compute-bound なので高精度のまま、decode は memory-bound なので重みも KV も低ビットに。ルーフラインモデルで考えれば当然の帰結を、1兆パラメータ MoE の本番で数値実証した(図1・図2)
- 量子化の目的は速度ではなく密度。 FP8 KV は単発ではむしろ遅い。それでも入れるのは、同じハードに倍のコンテキストと倍の並列を詰め込めるから(図3)
- 詰め込んだら整合性を守る。 共有 KV キャッシュは bookkeeping 一つで壊れる。規模が大きいなら、実行時検証を入れる価値がある(図6)
オープンウェイトの真価は重みファイルそのものではなく、こうした運用知見が SGLang のような OSS に還流していくエコシステムの側にあります。ローカルで数百B級 MoE を回す場合も支配方程式は同じ(帯域律速の decode、収容量との戦い)なので、学べるものは素直に学んでいきたいところです。
参考リンク
- Smaller, faster, safer: running Kimi and GLM at scale — The Cloudflare Blog
- The State of FP8 KV-Cache and Attention Quantization in vLLM — vLLM Blog
- moonshotai/Kimi-K2-Thinking — Hugging Face(Moonshot の INT4 QAT 方針)
本記事の数値・引用内容は2026年8月時点の公開情報に基づきます。図はすべて筆者作成(データ出典: Cloudflare ブログ)。