320B の GLM-5.3-Flash を DGX Spark 2 台で動かして 2 台にする価値を測ってみた
はじめに
こんにちは、クラスメソッド製造ビジネステクノロジー部の森茂です。
前回、320B の GLM-5.3-Flash を DGX Spark 1 台に 2-bit の GGUF で載せて、17.7 tok/s で動かしました。320B の MoE が机の上の 1 台で読める速さで返ってくるのは、それだけでも面白い光景でした。ただ、量子化は 2-bit まで削っていますし、思考を既定の max のまま動かすと日本語 10 課題に 15 分かかります。同じモデルをもう 1 台につないだらどうなるか、というのが今回の話です。
2 台あれば統合メモリは合わせて 242 GiB で、コミュニティが公開している NVFP4 の checkpoint（184.3 GiB）がそのまま載ります。削りは 2-bit よりずっと浅く、エンジンは vLLM のテンソル並列です。DGX Spark を 2 台つないで大きなモデルを動かす話は DeepSeek で 2 回書いてきましたが、1 台で測ったのと同じハーネス、同じ課題で 1 台と 2 台を横に並べられるのは今回が初めてです。2 台目を買う価値はあるのか、という問いに GLM-5.3-Flash で答えてみます。速度が伸びるのは分かりきっているので、見たいのは動くかどうかより、1 台編と同じ課題で使い物になる水準かどうかです。
先に結論を書いておくと、単発の速度は 17.7 → 26.5 tok/s の 1.5 倍で、日本語 10 課題は 927 秒が 413 秒になりました。動くだけではなく、仕事の道具として使える水準です。コード生成は 5 問すべて完答、バグ入りリポジトリの修正は 38 秒で完走、ツール呼び出しは tool_choice=required まで契約どおりで、10 ターンの壁打ちでも前提の想起は全問正解でした。ただ、2 台の価値は速度の倍率ではなかった、というのが今回の手応えです。投機デコードを載せたまま 262K コンテキストで 8 スロットが載り、8 並列の合計で 76.2 tok/s、200K トークンのプロンプトを読ませても合言葉を返します。1 人でコードを書く、長い文書を読ませる、数人で使う、多人数で共有する、と用途ごとに構成を選べるので、個人の検証機がチームのサーバーになります。初出で踏んだ日本語の文字化けは、checkpoint を RedHat 版に差し替えるだけで 0 になりました。原因と、差し替えで投機デコードの効き方が変わった話まで書いています。
1 台編（2026-08-30 時点の記事です）で素性、reasoning_effort、量子化、画像は見終えているので、この記事では 2 台で変わるところに絞ります。
2 台の配線は DeepSeek V4 Flash-0731 の 2 台編（2026-08-10 時点の記事です）から変えておらず、QSFP 直結に MTU 9000 の RDMA のままです。
この記事では、GLM-5.3-Flash の NVFP4 checkpoint を DGX Spark 2 台の vLLM で動かし、投機デコードと並列数を振って用途別の構成を決めるまでと、1 台編と同じハーネスでの比較、日本語の文字化けの原因と checkpoint 差し替えの実測を紹介します。2 台目を買うか迷っている人に刺さるといいなと思っています。
検証環境は QSFP 直結の DGX Spark 2 台と vLLM のテンソル並列
構成は 1 台を head、もう 1 台を worker にした vLLM の TP=2 です。head が OpenAI 互換の API を受け、重みは 2 台に半分ずつ載ります。環境を表にまとめます。
| 項目 | 内容 |
|---|---|
| 機体 | DGX Spark × 2（GB10、統合メモリ 121 GiB、driver 580.159.03、Docker 29.2 + compose v5） |
| ノード間 | QSFP 直結 200GbE、RoCE v2、MTU 9000。nccl-tests の all_reduce 12.14 GB/s、all_gather 11.57 GB/s |
| 役割 | head（rank 0、API は 127.0.0.1:8888）と worker（rank 1、--headless）を 1 台ずつ |
| image | ghcr.io/tonyd2wild/vllm-glm53-flash:sm121-v11-dflash2（20.7 GB。vLLM 0.1.dev20051、torch 2.13.0+cu130、flashinfer 0.6.17、NCCL 2.29.7、CUDA 13.0） |
| checkpoint | RedHatAI/GLM-5.3-Flash-NVFP4（21 ファイル、184.3 GiB、compressed-tensors） |
| drafter | incoai/GLM-5.3-Flash-DFlash2（2.2 GB、CC BY-NC-ND 4.0） |
| 起動時間 | worker と head を立ててから API が応答するまで 542〜608 秒 |
構成を図にすると次のとおりです。
compose と env、起動と停止のスクリプト、パッチはひとまとめにして公開しています。読者が今日動かすならこちらの README の手順が近道で、この記事はその裏側の実測と壁の話です。
触らない固定値だけ先に書いておきます。--block-size 2304 は fp8 の paged MQA が要求する page サイズで、外すとエラーなしに出力が壊れます。--language-model-only はマルチモーダルの front-end を読み込まないためのもので、これが無いと 15.7 GiB 余計に食います。tool call の parser は glm47 で、glm を指定すると何も言わずに tool call が消えます。起動順は worker を先に立てて 25 秒待ってから head で、止めるときは両 rank をそろって落とします。片方だけ落とすと残った GPU が 100% のまま固まります。あとはホスト側で vm.swappiness=0 と drop_caches を起動前に入れておくくらいです。
KV キャッシュのプールはサイズを固定せず、vLLM の profiler に測らせています。この checkpoint では 7.48 GiB のプールに 1,151,844 トークン分が入り、262K を満杯まで使うリクエストなら同時 4.4 本という計算です。
公式の image では起動できず、コミュニティの image とパッチで動かした
vLLM は GLM-5.3-Flash のリリースに合わせて専用の image vllm/vllm-openai:glm53-flash-arm64-cu130 を出していますが、GB10 の 2 台構成ではこのモデルを起動できませんでした。重みのロードと NCCL の接続までは通り、warmup で次の assert が出ます。
RuntimeError: concat_and_cache_mla, /workspace/csrc/libtorch_stable/cache_kernels.cu:866, pe_dim must be 64 for fp8_ds_mla
--kv-cache-dtype を fp8、fp8_e4m3、auto と変えても同じでした。GLM-5.3-Flash は rope の次元が 0 の NoPE モデルで、DeepSeek Sparse Attention の indexer が使うキャッシュ経路を stock のカーネルが受け付けないためです。2 台の Spark で動いたという報告はどれもパッチ済みの image か plugin を使っていて、stock 単体で動いた例は見つかりませんでした。
そこで本線は、tonyd2wild さんが公開している v11 の image に、同じ方が配っている SM121 向けの top-k パッチを compose の bind mount で当てた構成です。パッチは stock との差分 2 か所で、GB10 の共有メモリに収まらない persistent_topk を避けます。これが無いと長いプロンプトで engine が落ちるとのことで、実際この構成では 200K のプロンプトまで通りました。起動は 542〜608 秒で、モデル一覧、数学 1 問、tool call の 3 つのゲートを通っています。
速度を決めるのは投機デコードで、この checkpoint では MTP k=3 が最速だった
起動できたので、day-1 の構成から 1 因子ずつ変えて測りました。強制長 256 トークンの greedy で、C=1 は 3 回の中央値、コード生成は effort=low の 5 問を実際に解かせたときの実効 tok/s です。行はすべて v11 image + top-k パッチ + fp8_e4m3 KV で、262K コンテキスト、2 スロットです。
| 構成 | C=1 tok/s | TTFT 秒 | C=2 合計 | コード生成 tok/s | head 使用 GB |
|---|---|---|---|---|---|
| 投機なし | 14.60 | 0.228 | 27.50 | 12.00 | 113 |
| MTP k=3 | 26.47 | 0.249 | 29.77 | 21.97 | 113 |
| MTP k=4 | 24.10 | 0.358 | 27.99 | 22.63 | 113 |
| MTP k=5 | 22.63 | 0.263 | 26.35 | 21.75 | 113 |
| DFlash2 k=7 | 25.57 | 0.352 | 26.51 | 27.74 | 115 |
投機なしの 14.60 tok/s はコミュニティの報告（14.3〜14.6）と一致していて、ここが分母です。モデルに内蔵された MTP ヘッドを使うだけで 22.63〜26.47 tok/s になり、k=3 が単発の最速でした。1 台の llama.cpp で draft 3 が最も効いた傾向と同じです。
初出の LibertAI 版 checkpoint では、この表の顔ぶれが違いました。DFlash2 という GLM-5.3-Flash 専用の drafter（2.2 GB の別モデルを一緒に読み込む方式）が単発 30.84 tok/s で最速、MTP k=3 が 27.78 で続く並びです。RedHat 版では投機なしの分母がぴったり一致したまま、DFlash2 だけが 25.57 に下がり、MTP との差が消えました。drafter は素の重みに合わせて学習された別モデルなので、checkpoint の量子化が変わると draft の的中率が下がる、と読んでいます。受理率そのものは測っていないので、ここは解釈です。面白いのはコード生成の実効速度で、DFlash2 は 27.74 tok/s とここでは首位のままです。コードは定型句が多く draft が当たりやすいのだと思います。この drafter は CC BY-NC-ND 4.0 なので、商用なら MTP の行を使うことになります。
KV キャッシュの型と文脈長も見ておきます。KV を bf16 にすると、262K の 1 リクエスト分に必要な 3.62 GiB がプールに入らず、そもそも起動できませんでした。fp8 KV なら同じ枠で 4.4 本入るので、この構成で bf16 KV を選ぶ理由はありません。文脈長は 262K のままでも 65K に落としても、単発は 25.26 と 25.26、8 並列の合計は 76.2 と 75.3 で差なしです。文脈を削って速度を稼ぐ必要はありません。差が 3% 以内の行は同じと読んでいます。
MoE backend の flashinfer_cutlass、CUDA graph、batched 8192、autotune off、b12x、util 0.90 は今回未測です。
262K のまま 8 スロットが載り、用途は 2 構成で足りる
次に並列数です。1 台編では 65K コンテキストの 8 スロットが上限でしたが、2 台では 262K のまま 8 スロットが載りました。GLM-5.3-Flash は 45 層のうち 34 層が KV キャッシュを持たない線形 attention（KDA）で、profiler が確保した 7.48 GiB の KV プールに 1,151,844 トークン分が入ります。構成ごとの並列合計を並べます。
| 構成 | C=1 | C=2 | C=4 | C=8 |
|---|---|---|---|---|
| 262K、2 スロット、MTP k=3 | 26.5 | 29.8 | — | — |
| 262K、8 スロット、MTP k=4 | 25.3 | 26.3 | 57.7 | 76.2 |
| 65K、8 スロット、MTP k=4 | 25.3 | 36.2 | 45.8 | 75.3 |
8 スロットにしても単発は落ちず、MTP k=4 で 8 並列の合計 76.2 tok/s です。1 台の llama.cpp が 8 並列で 63.97 tok/s だったので、合計でも 2 台が上に出ました。8 本のスロットはどれも 262K の文脈を設定でき、プールの実容量は 262K 満杯なら同時 4 本強です。壁打ちや文書読解のような普通の使い方なら 8 人で叩いて破綻しません。
ここまでの実測から、構成は 2 つに絞れました。1 人で使うなら 262K に 2 スロットで MTP k=3、数人から多人数で共有するなら 262K の 8 スロットに MTP k=4 です。コードを書く時間が長い人は、1 人用の投機を DFlash2 に替えるとコード生成の実効だけ 27.7 tok/s まで伸びます。文脈長を 1 台編の 65K まで落とす必要はなく、262K のままで速度は変わりません。用途ごとの判定は、品質の結果を見たあとで「用途別にどれを選ぶか」の章にまとめます。
公開したレシピでは 1 人用が既定で、共有用は起動時に OVERRIDES で切り替えます。
# 共有用: MTP k=4 で 262K × 8 スロット
OVERRIDES="SPEC_METHOD=mtp MTP_NUM_TOKENS=4 MAX_NUM_SEQS=8" scripts/start-worker.sh
1 台のときは「自分が使うための箱」でしたが、262K の文脈を 8 本抱えたまま合計 76 tok/s が出ると、部署の何人かで叩くサーバーとして成立します。2 台にして一番変わったのは速度の数字より、この使い方の幅かなと思っています。
200K トークンのプロンプトでも合言葉を返した
長文は DFlash2 を載せた 2 スロットの構成で測りました。リクエストごとに固有の干し草を用意して 50% の深さに合言葉を埋め、強制長 512 トークンで TTFT、prefill、decode を取り、別のリクエストで合言葉を聞いて想起を確かめます。
| prompt tok | 実測 tok | TTFT 秒 | prefill tok/s | decode tok/s | 合言葉 |
|---|---|---|---|---|---|
| 2,048 | 2,054 | 1.5 | 1,369 | 36.5 | ✅ |
| 8,192 | 8,184 | 5.5 | 1,480 | 37.4 | ✅ |
| 32,768 | 32,725 | 22.3 | 1,466 | 40.9 | ✅ |
| 131,072 | 131,007 | 90.4 | 1,450 | 48.7 | ✅ |
| 200,000 | 200,342 | 139.4 | 1,438 | 52.7 | ✅ |
prefill は 1,369〜1,480 tok/s で 200K まで平坦で、TTFT は長さに比例します。200K トークンのプロンプトだと最初の 1 文字が返るまで 139.4 秒、合言葉は 5 サイズすべてで正しく返ってきました。decode が長いプロンプトで上がっているのは投機の受理率が上がったためで、干し草を復唱するような出力だと drafter がよく当たります。投機ありの decode は生成する内容に依存するので、長文の指標としては TTFT と prefill を見るのが安全ですね。
2 本同時も回しました。200K を 2 本流すと TTFT は 209.7 秒、prefill は 1 本あたり 1,070 tok/s、合計の decode は 3.5 tok/s で、292 秒で 2 本とも完走します。合わせて 400K トークン分の文脈を同時に抱えた計算です。文脈上限は 262K に設定しているので、1M までは今回試していません。
1 台と同じハーネスで測ると何が変わるのか
ここからは 1 台編と同じ課題を、8 スロットに DFlash2 を載せた serve で回した結果です。文脈長だけは 1 台と同じ 65K に揃えましたが、前章のとおり速度には効きません。1 台の列は 2-bit の GGUF を llama.cpp で動かした前回の値をそのまま使っています。
| 項目 | 2 台 NVFP4（DFlash2、8 スロット） | 1 台 2-bit GGUF |
|---|---|---|
| 速度 C=1 tok/s（TTFT 秒） | 26.05（0.346） | 17.72（0.333） |
| 並列 C=8 合計 tok/s（1 本あたり） | 59.42（13.4）。MTP k=4 なら 76.2 | 63.97（8.42） |
| 日本語 10 課題、effort=max | 6/9、14,700 tok、413.1 秒 | 6/9、14,708 tok、927.0 秒 |
| 日本語、effort=high | 6/9、47.3 秒 | 7/9、141.4 秒 |
| 日本語、effort=low | 7/9、45.7 秒 | 7/9、98.0 秒 |
| コード生成 5 問（max、low、16k） | すべて 5/5 完答、49/49 通過。high のみ 4/5、47/49 | 4/5（8192 予算の max）、ほかは 5/5、49/49 |
| ツール呼び出し | 5/5、1 メッセージに並列、required 遵守、擬似 FS ✅ | 同じ |
| コード修正（effort=max） | 5/5、5 ターン、10 ツール実行、38.1 秒 | 5/5、5 ターン、10 ツール実行、72.0 秒 |
| エージェント適性で落ちたプローブ | 多ツール選択（3 水準とも）。max は言語固定も | max は多ツール選択。low と high は長い system prompt も |
| 壁打ち A、B、C（effort=low） | 386 秒、109 秒、58 秒 | 433 秒、209 秒、88 秒 |
| 画像 | 対象外（--language-model-only） |
図表 4/4、OCR の文字誤り率 0.0 |
KV キャッシュの型は 2 台が fp8_e4m3、1 台が f16 で、ここだけは揃えられていません。effort=max の行は 8192 トークンの予算で、固有名詞を残して要約する 1 課題が両機とも思考で予算を食い切って本文が空のまま終わっています。この課題は予算を 16,384 にした別の行で測り直していて、2 台は 8/9、577.5 秒でした。落ちたのは固有名詞の 1 課題だけで、6 語中 5 語まで残して部署名を 1 つ落としています。
時間はどの項目でも短くなっています。日本語 10 課題の effort=max は 927 秒が 413 秒、壁打ち A は 433 秒が 386 秒、コード修正は 72 秒が 38 秒です。既定の max のまま動かしても 7 分弱で返ってくるので、1 台編で書いた「max はローカルの速度と桁が合わない」は、2 台だと少し柔らぐ感触でした。合否のほうは、落ちる課題が 50 字制約、指定語、固有名詞と 1 台のときと同じ顔ぶれです。コード生成の high で slugify が 11 テスト中 2 つ落としていますが、同じ問題を low、max、16k 予算では全問通しているので、能力の欠落というよりサンプリングの揺れ側だと見ています。1 台編で low を 3 回反復したときも 7/9、7/9、6/9 と揺れていたので、1 回の測定の 1 差は能力差とは言えません。壁打ち 3 シナリオの機械照合は前回同様に全問正解でした。
並列は正直に書いておくと、DFlash2 の 8 並列合計は 59.42 tok/s で、1 台の 63.97 を下回ります。DFlash2 は並列で不利になるためで、1 本あたりは 13.4 tok/s と 1 台の 8.42 より速く、共有するなら MTP k=4 で 76.2 まで出ます。合計だけを見て 2 台が遅いと読まないでください。
エージェント適性の表は、ハーネスが依存する能力を個別に突くプローブであって、ハーネス本体を動かした結果ではありません。2 台では 3 水準とも 40 ツール規模からの選択が落ち、max では応答言語を固定するプローブも 1 問落としました。これも単発の測定なので、量子化の差と断定はしていません。判定は 1 台編と同じで、opencode のようにツールが多いクライアントでは厳しく、Hermes Agent 相当なら使える、です。
日本語の文字化けは checkpoint 起因だった
初出の検証は、コミュニティで最初に公開された LibertAI 版の NVFP4 checkpoint で行っていました。その本戦の途中で、壁打ちの出力に見慣れない文字が混ざっていることに気づきます。27,757 字に U+FFFD の置換文字が 7 個、「許容�囲」「�実的」のように漢字 1 文字だけが欠ける形です。同じプローブを 1 台の 2-bit GGUF で回した 28,000 字超にはゼロでした。
LibertAI 版の上で条件を 1 つずつ潰しました。表の U+FFFD は出力全体に含まれる置換文字の数です。
| 条件（LibertAI 版、marlin、fp8_e4m3 KV、temperature 1.0、top_p 0.95） | U+FFFD | 字数 | 1 万字あたり |
|---|---|---|---|
| DFlash2 k=7 | 7 | 27,757 | 2.5 |
| MTP k=4 | 5 | 27,823 | 1.8 |
| MTP k=4 + top_k 40 | 13 | 27,475 | 4.7 |
| 投機なし | 2 | 11,840 | 1.7 |
| 投機なし + min_p 0.05（low、high） | 9、2 | 11,787、14,635 | 7.6、1.4 |
| 投機なし + KV bf16 | 14 | 27,937 | 5.0 |
| 1 台 2-bit GGUF、llama.cpp（参考） | 0 | 28,000+ | 0 |
投機の種類を変えても、外しても出ます。llama.cpp の既定に合わせて top_k 40 や min_p 0.05 で裾を刈っても消えず、KV を bf16 にしても消えません。つまりサンプラーの裾でも KV の精度でもなく、モデルが主要な候補として不正なトークンを選んでいます。return_token_ids で受けたトークン ID を checkpoint 同梱の tokenizer.json でオフライン復号しても同じ位置で壊れるので、表示側ではなくトークン列そのものの問題です。
壊れる仕組みは tokenizer の 2 バイト断片と 1 バイト継続の分割にある
tokenizer は zai-org 本家と md5 が一致しているので、checkpoint 側の改変ではありません。tokenizers ライブラリで語彙を眺めると、GLM-5.3 の byte-level BPE は日本語の新字体の多くを 1 トークンで持っておらず、「2 バイトの断片 + 1 バイトの継続」の 2 トークンで綴っています。測は e6b8 + ac、範は e7af + 84、陥は e999 + a5 という具合で、語彙 154,820 のうち 1,095 トークンは単体では正しい UTF-8 になりません。モデルが 2 バイトの断片を出したあと、1 バイトの継続を飛ばして次の文字へ進むと、そこで置換文字が生まれます。
壊れた語の統計がこの分割と一致します。「現実」は 66 回のうち 11 回壊れ、「効果測定」は 5 回、ほかに許容範囲、陥る、桁、継ぎ、併用、拡大、毀損と、どれも断片経路の字を含みます。一方、1 文字 1 トークンで綴れる「現場」は 95 回出てきて一度も壊れていません。
RedHat 版に差し替えると 0 になった
どの層で継続の判断が崩れるのかを切り分ける途中で、v11 image の作者が同じ症状をハングルで観測し、checkpoint を RedHat 版に替えると消えたと報告しているのを見つけました。LibertAI 版は ModelOpt の weight-only で routed experts を NVFP4 化した checkpoint、RedHat 版は llm-compressor で同じ層を NVFP4 化した checkpoint で、モデルも tokenizer も同じです。model の path を差し替えるだけで flags は一切変わらないので、そのまま試しました。
| 条件（RedHat 版、他は同一） | U+FFFD | 字数 | 1 万字あたり |
|---|---|---|---|
| 投機なし | 0 | 23,930 | 0.0 |
| DFlash2 k=7 | 0 | 27,086 | 0.0 |
| MTP k=4 | 0 | 27,258 | 0.0 |
同じ日本語プローブ、同じ応答数、同じ日本語比率で、壊れやすかった「測」「範」「現実」が 40 回以上出てきて 1 度も壊れません。この記事の本戦ハーネスと壁打ち 30 ターンの全出力にも置換文字はゼロでした。重みでも tokenizer でもカーネルでも投機でも KV でもなく、特定の checkpoint の量子化のつくりが原因、というのが結論です。ModelOpt 版の内部で何が悪いのかまでは切り分けられていませんが、利用者としてはここまで分かれば十分でした。
初出ではこの症状に対して、壊れるトークンを毎ステップでマスクする UTF-8 ガードの logits processor を書いて塞いでいました。投機デコードと併用できず 14.6 tok/s に落ちる回避策でしたが、RedHat 版では不要です。LibertAI 版を使い続ける場合向けに、ガードはレシピに残してあります。
用途別にどれを選ぶか
動くことと使えることの間に線を引いておきます。ここでは、ハーネスの課題を落とさないこと、待ち時間が用途に見合うこと、tool_choice のような契約を守ること、文字が壊れないこと、の 4 つを満たせば使える、どれかに条件が付けば条件付き、と判定しています。
| 用途 | 構成 | 速度の目安 | 判定 | 根拠と条件 |
|---|---|---|---|---|
| 1 人で使う、日本語で書く | 262K、2 スロット、MTP k=3 | 単発 26.5 tok/s | ✅ 使える | 日本語 10 課題は 1 台と同水準の合否で 2.2 倍速い。置換文字 0。内蔵 MTP ヘッドなので商用も可 |
| 1 人でコードを書く、直す | 262K、2 スロット、DFlash2 k=7 | コード生成の実効 27.7 tok/s | ✅ 使える | コード生成 5/5・49/49、修正 5/5 を 38.1 秒、ツール呼び出し 5/5 で required も遵守。drafter が CC BY-NC-ND なので検証・個人利用向け |
| 1 人で長い文書を読ませる、壁打ちする | 262K、2 スロット、DFlash2 k=7 | 200K の TTFT 139.4 秒、prefill 1,369〜1,480 tok/s | ✅ 使える | 2K〜200K で合言葉すべて正答、10 ターンの壁打ちの想起 6 項目も全問正解。200K は最初の応答まで 2 分強待つ前提 |
| 数人から多人数で共有する | 262K、8 スロット、MTP k=4 | 単発 25.3 tok/s、8 並列の合計 76.2 tok/s | ✅ 使える | 4 人同時なら 1 人あたり 14.4 tok/s、8 人同時でも 9.5 tok/s（1 台の 8 人同時は 8.42）。スロットは 8 本とも 262K を設定でき、プールの実容量は 262K 満杯で同時 4 本強 |
| エージェントとして常駐させる | 262K、2 スロット、MTP k=3 | — | 🟡 条件付き | Hermes Agent 相当は使える、opencode と OpenClaw は多ツール選択で厳しい。プローブでの判定で、ハーネス本体は動かしていない |
表の上 4 行は、どれも課題を落としていません。速度だけ見ると 1 台の 17.7 tok/s でも読める速さでしたが、コード修正が 72 秒から 38 秒、既定の effort=max の日本語 10 課題が 15 分から 7 分弱になると、待っている感覚がかなり違います。個人的には、1 人でコードを書くのと、数人で共有して壁打ちに使うのが、今回一番手応えのあった使い方かなと思っています。
手応えとして残ったのは、320B のモデルが 2 台でチームの道具になることでした。テストが落ちる Python リポジトリを 5 ターン 38 秒で直しきり、12,242 字の文書に質問を 8 回重ねて 58 秒で答え、200K トークンを読ませても合言葉が返ります。それが 8 人で同時に叩いても合計 76 tok/s を保ち、クラウドではなく机の上の 2 台で動いています。
条件付きの行も正直に書いておきます。エージェントの常駐は、40 ツール規模から正しいツールを選ぶプローブが 3 水準とも落ちているので、ツールの多いクライアントでは 1 台編と同じく厳しいままです。ここは 2 台にしても、checkpoint を替えても変わりませんでした。
参考までに、同じプロンプトを Fireworks の GLM-5.3-Flash（glm-5p3-flash）に手元の Mac から投げて比べておきます。単発は中央値 46.6 tok/s（10 回、34.0〜51.8）で 2 台の 26.5 の 1.8 倍、8 並列では 1 本あたり 60 tok/s、合計 397 tok/s と 2 台の 5 倍です。差が大きいのは長い入力で、200K トークンの TTFT は 7.49 秒、手元は 139.4 秒でした。1 つの時間帯に 1 回測っただけの数字で、共有テナントなので回ごとの幅も大きいのですが、速度で 2 台が勝つ場面はほぼ無い、と読んでよさそうです。それでも 2 台を選ぶ理由があるとすれば、データを外に出さない、262K の文脈を自分の箱で抱える、トークン課金がない、の 3 つで、この記事の「チームで使える」はその前提での話です。
まとめ
DGX Spark 2 台で GLM-5.3-Flash の NVFP4 を vLLM で動かし、投機デコードと並列数を振って、1 台編と同じ課題で比べました。
使い物になるか、で言えばなります。1 人でコードを書いて直す、長い文書を読ませる、数人で壁打ちする、多人数で共有する、の 4 つの用途は、課題を落とさず、1 台より速く回りました。構成は用途で選びます。1 人なら 262K に 2 スロットで MTP k=3 の 26.5 tok/s、コード中心なら DFlash2 で実効 27.7 tok/s、共有するなら 262K の 8 スロットに MTP k=4 で合計 76.2 tok/s です。2 台の価値は単発の 1.5 倍より、この幅にありました。
もう 1 つの収穫は、NVFP4 の checkpoint は作り方で挙動が変わる、という実測です。最初に使った ModelOpt 系の checkpoint は日本語の漢字が 1 万字に 2 個ほど壊れ、llm-compressor 系の RedHat 版に差し替えると 0 になりました。同じ差し替えで投機デコードの効き方も変わり、外付け drafter の DFlash2 が失速して内蔵 MTP が最速になっています。checkpoint を選ぶときは、ベンチのスコアだけでなく自分の言語・用途のプローブを 1 度通すのが安全ですね。
限界も書いておきます。公式の stock image は起動できず、動いたのはコミュニティの image とパッチの上です。DFlash2 の drafter は CC BY-NC-ND 4.0 なので、商用では MTP が上限になります。ModelOpt 版で継続トークンが落ちる内部の原因までは切り分けられていません。MoE backend の cutlass、CUDA graph、batched 8192 は未測です。エージェント適性の言語固定は max で 1 問落ちており、単発測定の揺れの範囲かは反復していません。
次は、262K を数人で同時に使う形の耐久を測って、チーム運用の成功条件を数字にしたいところです。SGLang の GB10 経路も出てきているので、同じ課題での横並びも面白そうです。
参考リンク
- RedHatAI/GLM-5.3-Flash-NVFP4 - Hugging Face — 本記事の checkpoint（llm-compressor / compressed-tensors）
- LibertAIDAI/GLM-5.3-Flash-NVFP4 - Hugging Face — 初出時の checkpoint（ModelOpt。日本語の文字化けの章を参照）
- zai-org/GLM-5.3-Flash - Hugging Face
- incoai/GLM-5.3-Flash-DFlash2 - Hugging Face — DFlash2 drafter（CC BY-NC-ND 4.0）
- tonyd2wild/GLM-5.3-Flash-NVFP4-DFlash2-2x-DGX-Spark — v11 image と SM121 top-k パッチ、checkpoint 別の U+FFFD 比較
- Libertai/glm53-flash-vllm-gb10 — stock image の assert と cutlass の util の床
- himorishige/glm53-flash-2x-dgx-spark-recipe — 今回の compose、スクリプト、パッチ
- GLM 5.3 Flash API & Playground | Fireworks AI — 参考比較に使った API
- 320B の GLM-5.3-Flash を DGX Spark 1 台で動かして実用の分かれ目を測ってみた（2026-08-30 公開）
- 284B の DeepSeek V4 Flash-0731 を DGX Spark 2 台で動かしてみた（2026-08-10 公開）
- DGX Spark 2 台をクラスタケーブルでつないでみた（2026-02 公開）
