Cloudflare、prefill と decode で精度を分離、GLM 5.2 の decode スループットを最大55%向上

Cloudflare は、Workers AI で大規模スパースモデルを提供するための本番構成を公開した。その中核となる考え方は、推論パイプライン全体を一律に量子化するのではなく、prefill と decode のボトルネックに応じて、それぞれ異なる精度を選択することだ。すべての実験にはオープンソースの SGLang が使用され、2段階に分離した H200 デプロイメントが採用された。

Kimi K2.6 では、Cloudflare は decode 段階の KV cache を BF16 から FP8 e4m3 に変更し、格納可能なコンテキストの総量を約68万6,000 token から137万 token に増やした。同じ並列度では、FP8 カーネル自体は実際にはわずかに遅く、たとえば単一リクエストの処理速度は毎秒137 token から125 token に低下した。実質的な利点はメモリ容量の拡大にある。BF16 は並列リクエスト数が32を超えるとメモリ不足になる一方、FP8 は64リクエストと毎秒2,192 token を維持でき、BF16 のピークスループットを約41%上回った。token 当たりのコストも約30%低下したという。

GLM 5.2 の重みは FP8 から INT4 に圧縮され、checkpoint のサイズは705 GB から421 GB に縮小した。8-way tensor parallelism では、GPU 1基当たりの重みのメモリ使用量が約88 GB から52 GB に減少した。decode はメモリ帯域幅に制約されるため、単一リクエストのスループットは毎秒60 token から92 token に向上した。一方、重みを事前に展開する必要がある prefill の処理速度は、逆に毎秒10,160 token から8,660 token に低下した。このため Cloudflare は INT4 を decode のみに使用し、prefill では引き続き FP8 を採用している。

高密度化は、共有キャッシュにおける分離のリスクも増大させる。新しい仕組みでは、物理 KV ページごとに、再割り当てのたびに変化するタグを設定する。decode の前に、リクエストが想定するページとタグを照合し、一致しなければリクエストを中止する。Cloudflare の測定では、スループットと p95 latency のオーバーヘッドはいずれも1%未満だった。ただし、品質に関する結論は主に Cloudflare が独自に選定した benchmark に基づいており、一部は社内テストでもある。エンジニアリングチームは、自社の長いコンテキスト、tool calling、マルチテナント負荷テストを用いて、量子化誤差と分離動作を引き続き検証する必要がある。