GLM-5.2を8×H200で自前ホストしたら
315 tok/sになった
— 専用GPUの速さと、正直な原価
「トークンが出てくる速さ」は、コーディングエージェントや音声対話ではそのまま体験の質になります。 そこで GLM-5.2(公式配布のFP8・追加の量子化なし)を 8×H200 SXM 1ノードに載せ、 推論エンジンの設定をひとつずつ変えながら、どこまで速くなるかを1日かけて実測しました。 結論を先に言うと、単一ストリームで 315 tok/s、一般的なAPI経由の約2倍です。 ただし原価は「常時ほぼ満杯」でないと従量APIより高くなります。その両方を、数字のまま公開します。
測り方
- モデル: zai-org/GLM-5.2-FP8(753Bパラメータ MoE・重み704GB)。量子化は公式FP8のまま、それ以上は落としていません。
- ハード: 8×H200 SXM(141GB×8=1,128GB)1ノード・Tensor Parallel 8。
- エンジン: SGLang 0.5.19(比較の起点として vLLM 0.28 も1回)。コンテキスト長は掃引中は32Kに固定。
- プロンプト: 「Transformerを数式つきで説明」(512tok・3回)、「CSV解析のPython関数」(512tok・2回)、「コンピュータ史1,500語」(2,048tok・1回)。temperature 0。
- tok/s の定義: 表の「掃引」は非ストリーミングで完了トークン数÷総時間。「比較」はストリーミングで、最初のトークン以降の生成速度(decode)と TTFT を分けて記録。
何が効いたか — 投機デコードの掃引
素の状態(vLLM・投機デコードなし)は 112 tok/s でした。GLM-5.2 には MTP(Multi-Token Prediction)層が同梱されているので、 SGLang の NEXTN 投機デコードでこれをドラフトに使い、1ステップで何トークン先読みするかを変えていきました。
| 構成 | 説明文 512 | コード 512 | 長文 2,048 | 備考 |
|---|---|---|---|---|
| vLLM・投機なし | 112 | — | 112 | 起点 |
| SGLang・投機なし | 115 | — | 114 | |
| MTP steps 2 / draft 3 | 232 | 227 | 231 | ここまでは前日分 |
| MTP steps 3 / draft 4 | 270 | 181〜223 | 255 | |
| MTP steps 4 / draft 5 | 291 | 238 | 254 | |
| MTP steps 5 / draft 6 | 305 | 232 | 251 | 採用 |
| MTP steps 6 / draft 7 | 291 | 229 | 246 | 頭打ち |
| steps 5/6 + allreduce融合 + symm-mem | 300 | 250 | 256 | コードだけ改善 |
| steps 3/4 + FP8 KVキャッシュ | 251 | 235 | 220 | 逆効果 |
| torch.compile | 起動失敗 | 子プロセス異常終了 | ||
| ツリー投機(topk 2/4) | 起動不可 | DSA注意機構では非対応 | ||
| Single Batch Overlap | 起動不可 | Hopper(SM90)非対応 | ||
採用構成の受理長(1回の検証で確定するトークン数)は平均 3.58、受理率 0.52 でした。steps を増やすほど先読みは伸びますが、6 で検証コストが勝ち始めます。 「コード」だけ伸びが鈍いのは、コードは分岐が多くドラフトの当たり率が下がるためです。
python3 -m sglang.launch_server \
--model-path zai-org/GLM-5.2-FP8 --tp 8 \
--context-length 32768 --mem-fraction-static 0.85 \
--speculative-algorithm NEXTN --speculative-eagle-topk 1 \
--speculative-num-steps 5 --speculative-num-draft-tokens 6一般的なAPI経由と同条件で比べる
同じ3プロンプトを、同じ日にストリーミングで測りました。比較対象は公開マーケットプレイス経由の GLM-5.2 で、 「既定ルーティング(勝手に振り分け)」「最速のプロバイダを指定」「最安のプロバイダを指定」の3通りです。
| 経路 | TTFT | 説明文 | コード | 長文 |
|---|---|---|---|---|
| 専用 8×H200(本記事の構成) | 0.05s | 315 | 239 | 254 |
| マーケットプレイス・既定ルーティング | 0.6〜0.8s | 170 | 222 | 141 |
| 同・最速プロバイダ指定 | 0.4〜0.6s | 158 | 140 | 129 |
| 同・最安プロバイダ指定 | 0.5〜0.8s | 49 | 86 | 59 |
TTFT の差はもっと大きく、0.05秒 対 0.5〜0.8秒です。音声対話やエージェントの「間」はここで決まります。 なお teai.io の共有プランの GLM-5.2 は原価が最小の経路に寄せているため、速度はこの表の「最安プロバイダ」の帯にいます。 速さが要る用途では、共有プランと専用GPUで体験が変わる、というのが今回の実測の意味です。
同時接続を増やすと — 合計スループットと原価
1ノードを1人で使うのはもったいないので、同時に何本まで流せるかも測りました(512トークン×N本・temperature 0.7)。 原価は 8×H200 の時間単価(この実験で使ったクラウドの表示価格 $36.72/時)を、その時間に出た出力トークン数で割ったものです。
| 同時本数 | 合計 tok/s | 1本あたり tok/s | 出力1Mトークンの原価 |
|---|---|---|---|
| 1 | 315 | 315 | $32.4 |
| 8 | 917 | 115 | $11.1 |
| 16 | 1,419 | 89 | $7.2 |
| 32 | 1,523 | 48 | $6.7 |
| 64 | 2,119 | 33 | $4.8 |
| 128 | 2,739 | 21 | $3.7 |
Kimi K3 は載らなかった
同じ日に Kimi K3 も同じ構成で試しました。結果は断念です。 公開されている K3 の重みは FP8 で 2.82TB、4bit重み+FP8活性(W4AFP8)で 1.48TB、NVFP4 で 1.61TB。 8×H200 の合計 1,128GB にはどれも収まりません。唯一載る 1bit 量子化(GGUF・606GB)は llama.cpp 系エンジンで 10〜18 tok/s しか出ず、8枚のGPUを並列に使い切れませんでした。K3 を速く動かすには 16×H200(2ノード)か、 メモリ 288GB の B300 が必要です。B200/B300 は8枚構成の在庫がまだ薄く、今回は見送りました。 自前ホストの費用感は Kimi K3を自分でホストしたらいくら? にまとめています。
まだ試していないこと
- DFlash(ブロック拡散型のドラフト)。GLM-5.2-FP8 向けの学習済みドラフトが公開されており、MTP より受理長が伸びる可能性があります。今回は時間切れで未計測。
- Blackwell(B200/B300)。HBM帯域が約1.7倍で、デコード速度はほぼ帯域に比例します。Single Batch Overlap も Blackwell 専用でした。
- 128K コンテキストでの再測。掃引は32Kで固定しています。単一ストリームの生成速度はKVキャッシュ容量にほとんど左右されない見込みですが、未確認です。
teai.io 専用プラン(専用GPU)はお問い合わせください
この記事の構成(8×H200・GLM-5.2・315 tok/s)を、お客様専用のエンドポイントとして用意します。 モデル・リージョン・同時接続数・稼働時間帯に合わせて見積もります。既存の teai.io API キーのまま切り替えられます。