GLM-5.2はオープンウェイトのコーディングモデルに、実際の1Mトークンのコンテキストウィンドウを提供します。難しいのは、そのフルウィンドウを、すでに多くのチームが本番運用で使っているハードウェア上で提供すること：Hopperです。

私たちはSGLangを用いて、GLM-5.2-FP8をW4AFP8に量子化し、単一の8×H200ノードで検証しました。このチェックポイントにより重みメモリは755GBから368GBへ削減され、1MトークンのKVキャッシュとランタイムの余裕に使えるHBMが387GB分確保されます。

なぜ重要か

GLM-5.2は、長いコンテキストに関するモデル側の課題はすでに解決しています。疎な注意（sparse attention）、IndexShare、MTPによる推測デコーディング、ツール利用、推論、そして1,048,576トークンのウィンドウです。しかしデプロイには、もう一つの問題があります。1Mトークンのウィンドウには、モデルの重み、KVキャッシュ、CUDAグラフ、ランタイムバッファ、そしてサービングに伴うオーバーヘッドのためのスペースが必要です。

公式のFP8チェックポイントは、適切な一般的なサービングのベースラインです。Hopper上では、このベースラインはフルコンテキストウィンドウに向けて押し上げると、メモリの余裕（スラック）が大幅に減ってしまいます。W4AFP8は、モデルファミリー、トークナイザ、APIの形、またはGLM-5.2の挙動を変えることなく、メモリ予算を変更します。