DGX Spark 8台でGLM-5.2｜ピーク66 tok/sを検証
CHATGPT / AIChatGPTなどの生成AIを活用して運営・記事制作・更新を行っています。制作方針
8台のDGX Sparkで753B級GLM-5.2を動かし、v18でprefill 1,329 tok/s、平均decode 35〜42 tok/s、ピーク66 tok/sを記録した公開例を、条件と注意点まで検証します。
先に結論
- コミュニティ開発者が、8台のDGX Spark / GB10クラスターでInt4・Int8混合量子化版GLM-5.2を動かす再現用リポジトリを公開した
- v18構成の公開値は、2,048 tokenのprefillが1,329.72 tok/s、生成の平均が35.21〜41.80 tok/s、瞬間的なピークが66 tok/s
- 「66 tok/sで常時生成」ではない。ピーク値と平均値を分け、context深度、TTFR、ウォームアップ後という条件まで読む必要がある
- v16からモデル重みと8台構成は変えず、vLLM fork、B12X、FlashInfer、PyTorch、CUDA、runtime修正を更新して速度を伸ばしている
- 1台で再現できる結果ではなく、8ノードの構築、RoCEネットワーク、約378GiBのcheckpoint、独自Docker imageとpatch群を扱える人向けの研究・運用例
最も驚くべき点は小型機を8台積んだ見た目だけではありません。同じハードウェアと同じ量子化weightでも、推論stackの更新でprefillとdecodeに二桁近い改善余地が残っていたことです。
情報監査日: 2026年7月24日
数値の扱い: 本文の性能値はciprianveg氏が公開したGitHubリポジトリとNVIDIA Developer Forumsへの投稿に基づきます。当サイトで8台を用いて再測定した値ではありません。
画像: アイキャッチは8ノード構成を表現した当サイトの要点図解で、実機写真ではありません。
投稿が報告した「1,329」と「66」
話題の投稿は、8台のGB10 / DGX SparkでQuantTrio / GLM-5.2-Int4-Int8Mixを配信する構成を、v16からv18へ更新した結果です。再現用のDockerfile、build script、recipe、runtime修正はciprianveg / gb10-glm-5.2で公開されています。
最終値は、coherent corpusを使ったllama-benchy、Tensor Parallel 8、Pipeline Parallel 1、Decode Context Parallel 1、MTP k=4という条件です。
| テスト | 平均 throughput | ピーク | TTFR |
|---|---|---|---|
| pp2048、depth 0 | 1,329.72 tok/s | — | 1,542ms |
| tg1500、depth 0 | 35.21 tok/s | 66 tok/s | — |
| pp2048、depth 16K | 1,319.37 tok/s | — | 13,682ms |
| tg1500、depth 16K | 41.80 tok/s | 66 tok/s | — |
| pp2048、depth 100K | 1,202.08 tok/s | — | 84,895ms |
| tg1500、depth 100K | 34.99 tok/s | 45 tok/s | — |
pp2048は2,048 tokenのprompt processing、つまりprefillを測ります。tg1500は1,500 tokenを生成するdecodeテストです。depth 16Kとdepth 100Kは、測定前からKV cacheにそれぞれ約16,000、100,000 tokenがある状態を表します。
このため、SNSで目立つ1,329 tok/sは入力を読む速度、66 tok/sは生成中の最良stepです。利用者が継続的に感じる出力速度としては、平均35〜42 tok/sを見る方が正確です。
v16からv18で何が変わったか
今回の比較では、モデルweight、8台のtopology、TP8＋PP1、DCP=1、B12X sparse MLA、MTP k=4を維持しています。つまり、別の小型モデルへ変更して速く見せた結果ではありません。
| component | v16 | v18 |
|---|---|---|
| vLLM fork | fathomless-firmament v16 | gilded-gnosis v18 |
| B12X | lukealonso版 | voipmonitor版 |
| FlashInfer | SM121 prebuilt | 更新版SM121 wheel |
| PyTorch | 2.11.0 | 2.12.0 |
| CUDA | 13.2.0 | 13.2.1 |
| 追加要素 | — | DeepGEMM、InstantTensor、約30件のupstream変更 |
v18 recipeは、MTP量子化mapping、block tableの境界、tool call時のstate machine、CuTe compile cache keyなどを補う7つのruntime modも適用します。速さだけでなく、同時decode時のcrash回避や再起動後のcache再利用も含む更新です。
公開リポジトリはv16をfallbackとして残し、v18をcurrent productionとして分離しています。高速化した新構成だけを置き換えるのではなく、問題時に旧構成へ戻せる形です。大規模なローカル推論では、最高値より再現できるversion固定とrollbackの方が運用上は重要です。
prefillは何%速くなったのか
NVIDIA Forumsの更新文は、v16の約1,200 tok/sからv18の約1,330 tok/sへ伸びたとして「約10%」と説明しています。1,200から1,329.72を単純計算すると約10.8%です。一方、現在のGitHub READMEには「v16比＋8%」とあります。
これは矛盾というより、v16をどのrun、どの丸め値と比較するかの違いです。初回公開表のdepth 0は1,211 tok/sで、そこから1,329.72なら約9.8%増です。benchmark値にばらつきがある以上、8〜11%程度のprefill改善と読むのが安全です。
decodeも同様です。Forumsではv16のピーク54 tok/sに対して66 tok/sを「＋23%」としていますが、平均生成速度そのものが54から66へ上がったわけではありません。比較するなら、同じprompt、同じdepth、同じ出力長における平均値をそろえます。
8台で753B級モデルが動く仕組み
Z.ai公式GLM-5.2は753B parameterのMoEで、1M-token contextと長時間のcoding・agent taskを意識したモデルです。BF16のままではデスクトップ級のmemoryへ収まりません。
今回のQuantTrio版は、MoE expert weightを主にW4A16、通常のlinear weightやMTP blockをW8A16とするInt4・Int8混合量子化です。model cardのfile sizeは378GiB。attention indexer、normalization、embedding、special headなどはBF16またはFP32を残します。
DGX Sparkは1台128GBの統合memoryを持つため、8台の物理memory合計は1,024GBです。ただし、8台がOSから1つの1TB memory deviceとして見えるわけではありません。TP8でmodelのtensorを8 rankへ分け、各stepでnode間通信と同期を行います。
| 要素 | 今回の役割 |
|---|---|
| TP8 | model tensorを8 rankへ分割して各nodeへ配置 |
| PP1 | pipeline stageには分けず、1 stageとして動作 |
| DCP1 | decode contextを追加分割せず、速度を優先 |
| MTP k=4 | 複数の将来tokenを予測し、受理できた分だけdecodeを進める |
| B12X sparse MLA | GB10 / SM121向けのsparse attention処理 |
| RoCE | rank間の低遅延・高帯域通信 |
DGX SparkはConnectX-7を搭載しますが、8台を並べるだけで速くなるわけではありません。LLMのTensor Parallelはlayerごとに細かい同期を繰り返すため、network、kernel、scheduler、MTP acceptanceのどれかが詰まると台数効果が失われます。
66 tok/sは体感でどれくらい速いか
平均35〜42 tok/sなら、日本語や英語のchat、code生成を画面で追う用途では十分に軽快です。1,500 tokenを単純に平均35 tok/sで出すと約43秒、42 tok/sなら約36秒です。ピーク66 tok/sが続けば約23秒ですが、公開表はその持続を示していません。
長文脈では、生成開始までの待ち時間も重要です。depth 0の2,048-token prefillは約1.5秒ですが、16K depthではTTFRが約13.7秒、100K depthでは約84.9秒です。100Kの既存contextでもdecode平均は約35 tok/sを保っていますが、最初の1 tokenまでの時間は長くなります。
coding agentで巨大なrepositoryや長い履歴を毎turn読み直す場合、decodeの最高値だけでは快適さを判断できません。prefix cacheのhit率、変更差分だけを渡せるか、並列requestがprefillとdecodeを奪い合わないかも測る必要があります。
最初の20 requestは遅くなる
v18では、初回boot後にCuTe DSLとTriton kernelをJIT compileします。公開READMEは、batch shapeを変えながら約10〜20 requestをwarmupしないと、TTFRが増えてdecode throughputも下がると注意しています。
再起動のたびに同じcompileを繰り返さないため、CuTe DSL、Triton、TorchInductor、Torch extensionsのcache directoryをhostへ永続mountします。ベンチマークを再現するときは、次をそろえます。
- 同じcommitとDocker imageを使う
- 8 nodeすべてのdriver、CUDA、PyTorch、NCCLをそろえる
- cacheを永続化し、warmup完了後に測る
- TP、PP、DCP、MTP k、KV cache dtypeを記録する
- prompt corpus、context depth、出力長を固定する
- 平均、標準偏差、peak、TTFRを分けて保存する
この結果から言えること、言えないこと
| 言えること | まだ言えないこと |
|---|---|
| 8台のGB10で753B級の混合4・8bit版を配信できる公開recipeがある | 純正GLM-5.2 BF16と同じ品質である |
| 同じweightとtopologyでもsoftware更新で速度が伸びた | 8台に増やせば1台の8倍速くなる |
| 100K depthでも平均decode約35 tok/sを記録した | 100K promptで即座に応答が始まる |
| 瞬間peakとして66 tok/sが記録された | 常に66 tok/sで生成できる |
| build recipeとruntime modが公開されている | 標準vLLMをinstallするだけで再現できる |
品質についても別の評価が必要です。QuantTrioのmodel cardはAIME25の軽量な再現値を載せていますが、正式な全面benchmarkではないと明記しています。速度測定と、instruction following、coding、tool calling、長文脈品質の確認は分けて行います。
また、公開値には8台の本体価格、200GbE switchとcable、共有storage、電力、騒音、設置、保守時間は含まれません。「自宅で動いた」という技術的成果と、「APIより安い」という経済性は別の計算です。
よくある質問
DGX Spark 1台でもGLM-5.2を66 tok/sで動かせますか？
いいえ。66 tok/sは8台をTP8で使う今回の構成における瞬間peakです。1台ではmemory容量も推論構成も異なり、同じ値は期待できません。
66 tok/sと35 tok/sのどちらが正しいですか？
どちらも公開値ですが意味が違います。66 tok/sは最良stepのpeak、35.21 tok/sはdepth 0で1,500 tokenを生成した平均です。体感や処理時間の見積もりには平均値を使います。
8台のmemoryは合計1TBとして使えますか？
物理容量の合計は1,024GBですが、単一nodeの共有memoryではありません。modelとKV cacheを分割し、推論engineがnetwork越しに同期します。通信costと各nodeの予約memoryがあるため、単純な1TB機とは扱いが異なります。
v18へ更新すれば必ず10%速くなりますか？
保証されません。今回の改善は特定のGB10 8-node構成、量子化model、commit、MTPとbenchmark条件によるものです。既存環境ではv16を残し、同じprompt setでA/B測定してから切り替えます。
まとめ
8台のDGX SparkでGLM-5.2 Int4・Int8混合版を動かし、prefill 1,329.72 tok/s、平均decode 35〜42 tok/s、peak 66 tok/sを記録したv18構成は、デスクトップAI clusterの到達点として非常に印象的です。
ただし、数字を正しく読むにはprefillとdecode、平均とpeak、depth 0と100K、warmup前後を分ける必要があります。見出しに使える「66」より、100K depthでも平均約35 tok/sを保ったこと、同じweightのままsoftware stack更新で8〜11%のprefill改善を得たことの方が、実運用には重要です。
この事例が示したのは、DGX Sparkを積めば自動的に高速化するという話ではありません。model、量子化、parallelism、network、kernel、scheduler、cacheを一つのsystemとして調整したとき、小型GB10 clusterでも753B級モデルを実用速度へ近づけられる、という成果です。
参照資料
- ciprianveg / gb10-glm-5.2：v16・v18のbuild、recipe、benchmark（v18、2026年7月23日更新）
- NVIDIA Developer Forums：GLM-5.2 Int4-Int8 on 8× GB10（2026年7月14日公開、7月23日v18追記）
- QuantTrio：GLM-5.2-Int4-Int8Mix model card（2026年6月21日）
- Z.ai：GLM-5.2公式model card（2026年6月16日公開）
- NVIDIA：DGX Spark Hardware Overview（2026年7月14日更新版を確認）
- CosmicRaisins / glm-5.2-gb10：基礎となった4-node実装（2026年7月24日確認）
