GLM-5.2を8×H200で自前ホストしたら
315 tok/sになった
— 専用GPUの速さと、正直な原価

「トークンが出てくる速さ」は、コーディングエージェントや音声対話ではそのまま体験の質になります。 そこで GLM-5.2(公式配布のFP8・追加の量子化なし)を 8×H200 SXM 1ノードに載せ、 推論エンジンの設定をひとつずつ変えながら、どこまで速くなるかを1日かけて実測しました。 結論を先に言うと、単一ストリームで最大 315 tok/s(3種のプロンプト平均は 269 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 を分けて記録。
• 計測位置: 専用GPU側はサーバと同じマシン内から(ネットワーク往復を含まない)。比較対象のAPIは東京の回線から(往復を含む)。TTFT の比較はこの差を割り引いて読んでください。GPU の所在は欧州リージョンです。日本からの往復を含む TTFT は、別途「日本からの実測」節で米国リージョンの同構成に対して測りました。

何が効いたか — 投機デコードの掃引

素の状態(vLLM・投機デコードなし)は 112 tok/s でした。GLM-5.2 には MTP(Multi-Token Prediction)層が同梱されているので、 SGLang の NEXTN 投機デコードでこれをドラフトに使い、1ステップで何トークン先読みするかを変えていきました。

採用構成の受理長(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通りです。計測は 2026-09-08 09:50〜10:30(JST)、対象は同マーケットプレイスの z-ai/glm-5.2 エンドポイントで、割り当てられたプロバイダ名と生ログは問い合わせいただければ開示します。

TTFT の差はもっと大きく、0.05秒 対 0.5〜0.8秒です。音声対話やエージェントの「間」はここで決まります。 なお teai.io の共有プランの GLM-5.2 は原価が最小の経路を優先する設計のため、速度はこの表の「最安プロバイダ」の帯が目安です。 速さが要る用途では、共有プランと専用GPUで体験が変わる、というのが今回の実測の意味です。

日本からの実測 — 往復遅延を含めると TTFT の差は消える

サーバ内 0.05 秒の TTFT は、日本のユーザーには届きません。そこで同じ構成(8×H200・sglang・steps 5/draft 6)を米国リージョンに立て直し、 東京のデータセンター(teai.io のゲートウェイが動いている場所)から、クラウドの HTTP プロキシ経由でストリーミングの最初のバイトまでを測りました(2026-09-08 19:30 JST・16トークン・3回)。

同時接続を増やすと — 合計スループットと原価

1ノードを1人で使うのはもったいないので、同時に何本まで流せるかも測りました(512トークン×N本・temperature 0.7)。 原価は 8×H200 の時間単価(この実験で使った予約枠の表示価格 $36.72/時)を、その時間に出た出力トークン数で割ったものです。同じクラウドの公開価格は H200 SXM 1枚 $4.59/時(8枚で $36.72/時)で、この実験の単価と一致します。在庫次第で $28.72/時の枠が表示されることもあり、その場合は下の原価がいずれも約22%下がります。投機デコードは全行で ON のまま測っています(大バッチでは投機を切った方が合計が伸びる可能性があり、そこは未計測)。

読み方の目安: 8人のチームが同時に使うと1人あたり約115 tok/s、32人なら約48 tok/s です。見出しの315 tok/sは「1人で占有したとき」の数字で、専用プランで実際に体感する速度は同時本数で決まります。

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 専用でした。
• 日本近郊リージョンでの TTFT 再測。米国からの往復を含むと TTFT の優位は消えました(上の「日本からの実測」)。日本DCに在庫が出た時点で測り直します。
• 128K コンテキストでの再測。掃引は32Kで固定しています。単一ストリームの生成速度はKVキャッシュ容量にほとんど左右されない見込みですが、未確認です。

もっと詳しく読む