Kimi・GLMをGPU一枚に効率的に詰め込む — Cloudflareが実践するメモリ最適化の3つの技術

はじめに: LLM推論のボトルネックはメモリ

LLM(大規模言語モデル)の推論インフラを運用していると、GPUメモリが常に課題になります。特に最近注目されているKimi K2.6やGLM 5.2のようなモデルは、数十億パラメータと長いコンテキストを処理するため、単にモデルの重みをロードするだけでは不十分です。

CloudflareのWorkers AIプラットフォームは、世界中のデータセンターにあるGPUでこれらの大規模モデルを推論しています。今回公開された事例では、単に「高速化」するだけでなく、**「同じハードウェアにより多くのリクエストを収容する」**ことに焦点を当てています。核となるのは以下の3つです。

1. KVキャッシュの量子化 (FP8)
2. モデル重みの圧縮 (INT4)
3. 共有キャッシュの保護 (整合性チェック)

本記事では、各手法の必要性と、実際の性能指標による検証結果を解説します。

本論1: KVキャッシュをFP8に量子化し、2倍のコンテキストを確保

なぜKVキャッシュが問題になるのか

モデルがテキストを生成する際、処理済みトークンのAttention Key(K)とValue(V)をKVキャッシュに保存します。このキャッシュにより、長い会話でも毎回コンテキスト全体を再読込する必要がなくなります。しかし、このキャッシュがGPUメモリの大部分を占めることが問題です。

デフォルトではKVキャッシュは16ビット精度(BF16)で保存されます。Cloudflareはこれを8ビット浮動小数点数(FP8, e4m3)に変換し、キャッシュサイズを半分に削減しました。Kimi K2.6では、メモリに保持できるコンテキストが約68万6千トークンから137万トークンへと2倍に増加しました。

性能への影響: 単なる速度ではなく「収容力」の問題

# 概念コード: KVキャッシュのデータ型変換例
import torch

# 従来のBF16キャッシュ (メモリ使用量2倍)
k_cache_bf16 = torch.randn(4096, 128, dtype=torch.bfloat16)

# FP8に変換 (メモリ使用量半分)
from torchao.quantization import quantize_
quantize_(k_cache_bf16, fp8_e4m3)

print(f"BF16メモリ: {k_cache_bf16.element_size() * k_cache_bf16.nelement() / 1024**2:.2f} MB")
print(f"FP8メモリ: {k_cache_bf16.element_size() // 2 * k_cache_bf16.nelement() / 1024**2:.2f} MB")

以下の表は、Kimi K2.6のデコード(生成)段階におけるH200 GPUの同時リクエスト数ごとのスループットを比較したものです。重要な点は、BF16が単一リクエストではわずかに高速ですが、32同時リクエストでメモリ限界に達するということです。

同時リクエスト数	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	OOM	2,192

FP8はBF16の最大スループット(1,558 tok/s)よりも約41%高い2,192 tok/sを記録し、トークンあたりのコストは約30%削減されました。**重要なのは「より高速」ではなく「より多くのリクエストを収容できる」**ことです。

精度は同じか

ベンチマーク	BF16 KV	FP8 KV
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精度	92.2%	92.6%

ベンチマークの結果、FP8とBF16は実質的に同じ精度を示しています。実務で適用しても、モデル品質を低下させることなくメモリ効率を向上できることがわかります。

本論2: モデル重みのINT4圧縮とキャッシュ保護

重み圧縮: 705GB → 421GB

KVキャッシュの次にメモリを消費するのはモデルの重みです。GLM 5.2の場合、Cloudflareは重みを8ビット浮動小数点数(FP8)から4ビット整数(INT4)に圧縮しました。チェックポイントサイズは705GBから421GBへ約40%削減され、8ウェイテンソル並列デプロイメントでのGPUあたりのメモリ使用量は約88GBから52GBに減少しました。

# 概念コード: FP8 vs INT4の重みメモリ比較
model_size_params = 400_000_000_000  # 400Bパラメータ想定

fp8_bytes = model_size_params * 1  # 8bit = 1byte
int4_bytes = model_size_params * 0.5  # 4bit = 0.5byte

print(f"FP8モデルサイズ: {fp8_bytes / 1024**3:.1f} GB")
print(f"INT4モデルサイズ: {int4_bytes / 1024**3:.1f} GB")

デコード段階では、モデルの重みをGPUメモリからストリーミングしてトークンを生成するため、メモリ帯域幅がそのまま速度になります。INT4で圧縮すると読み込むデータが減るため、単一リクエストのスループットが55%向上します。

同時リクエスト数	GLM FP8 (tok/s)	GLM INT4 (tok/s)	INT4利得
1	60	92	+55%
8	425	513	+21%
16	683	825	+21%
32	994	1,267	+27%
64	1,672	1,933	+16%

ただし、プリフィル段階では計算量が多いため、INT4はむしろ遅くなります。FP8は毎秒10,160トークン、INT4は8,660トークンです。このためCloudflareは**プリフィルとデコードを分離(Disaggregation)**し、それぞれに有利な方式を適用しています。

共有キャッシュ保護: 10億分の1の確率も許容できない

量子化と圧縮により、数百のリクエストが同じGPUメモリを共有できるようになりました。効率は良いですが、キャッシュページを誤って参照すると、他のユーザーのデータが混ざるリスクがあります。Cloudflareはこれを防ぐためにKVキャッシュ整合性チェックを実装しました。

• すべての物理キャッシュページには、再割り当て時に変更されるタグが付与されます。
• サーバーは各リクエストが使用するページとタグのマッピングを記録します。
• デコード前にマッピングを確認し、不一致が見つかった場合は該当リクエストを中断します。

この検証の性能コストは非常に低いです。

同時実行数	スループット変化	p95レイテンシ変化
1	-0.53%	+0.42%
4	-0.79%	+0.63%
8	-0.43%	+0.80%

コストが1%未満であるため、デフォルトで有効化してもサービス品質に影響を与えません。

まとめ: 実務適用の観点と次のステップ

日本市場における適用コンテキスト

日本国内でも、LLM推論にGPUを使用するスタートアップや大企業が増えています。しかし、多くは単純にGPUを追加する形で拡張しています。今回のCloudflareの事例は、「ソフトウェア最適化によるハードウェア効率の最大化」というアプローチを示しています。特に日本のクラウドコストが高い状況では、KVキャッシュ量子化と重み圧縮は即座にコスト削減効果が期待できる戦略です。

この技術の限界または注意点

• 精度の微小な変化: FP8とINT4はどちらもベンチマークで有意な差はありませんが、特定のドメイン(例: 医療、法律)では微小な差が敏感になる可能性があります。
• プリフィル/デコード分離の必要性: INT4はデコードにのみ有利なため、アーキテクチャを分離しないと逆に性能が低下する可能性があります。
• ハードウェア依存性: FP8 e4m3変換は、最新のGPU(H100、H200など)でのみ効率的にサポートされます。

次のステップとしての学習方向

1. SGLangフレームワークの学習: 今回の最適化の基盤となったオープンソースの推論フレームワークです。
2. 量子化手法の深掘り: INT4、FP8以外にもNVFP4、AWQなど様々な手法を比較してみてください。
3. コストモデリング: 同じハードウェアでスループットが2倍になるとコストがどう変わるか、自分で計算してみることをお勧めします。

合わせて読みたい記事

• MS Sovereign Private Cloud、Azure Localで数千ノードまで拡張可能に
• Generali MalaysiaのAmazon EKS運用最適化事例: 自動化・セキュリティ・コスト削減の三位一体

---

本記事はCloudflareブログの原文に基づき再構成されたものです。