320B の GLM-5.3-Flash を DGX Spark 1 台で動かして実用の分かれ目を測ってみた

はじめに

こんにちは、クラスメソッド製造ビジネステクノロジー部の森茂です。

Z.ai が 2026-08-26 にリリースした GLM-5.3-Flash、気になっている方も多いのではないでしょうか。320B パラメータの MoE をアクティブ 18B で回し、GLM-5 系で初のネイティブマルチモーダル、コンテキストは 1M トークン。それが MIT ライセンスで重み公開という、かなり攻めた内容です。

https://huggingface.co/zai-org/GLM-5.3-Flash

ただ、320B ですから重みは BF16 で 642GB。手元の DGX Spark は統合メモリ 128GB（実効 121GiB）の 1 台構成なので、そのままではどうやっても載りません。頼みの綱は Unsloth の Dynamic GGUF で、1-bit 93GB・2-bit 109GB・3-bit 120GB という低ビット量子化なら物理的には収まる計算になります。載ることは載るとして、気になるのは「その状態で日常使いできるのか」です。

先に結論を書いておくと、2-bit（UD-Q2_K_XL, 109GB）は DGX Spark 1 台に載り、C=1 で 17.7 tok/s で動きました。コード修正は 5/5、コード生成も 5/5 完答・49/49 テスト全通過と、この低ビットでも実用線に届いています。ただし分かれ目は量子化ではありませんでした。思考の強さ reasoning_effort が既定で max で動き、日本語 10 課題に 29 分かかります。low を明示すると同じ課題が 98 秒で、スコアは落ちません。この一点を押さえるかどうかで、同じモデルが「使える」と「使えない」に割れます。

同じ課題・同じ条件で測っている定点観測シリーズの一本で、前回は Nemotron 3.5 Lightning を測りました（2026-08-12 時点の記事です）。

https://dev.classmethod.jp/articles/dgx-spark-nemotron-3-5-lightning-first-touch/

この記事では、GLM-5.3-Flash の素性の紹介と、DGX Spark 1 台で effort と量子化を振りながら測った実測結果を紹介します。

GLM-5.3-Flash の素性

まずは一次情報（Hugging Face のモデルカード、config.json、chat_template）から素性を整理します。

面白いのは attention の構成です。45 層のうち 34 層が KV キャッシュを持たない線形 attention（KDA）で、通常の意味での attention は 4 層に 1 層挟まる DeepSeek Sparse Attention の 11 層だけ。公式は GLM-5.3 比で attention 計算を 3.01 倍、KV キャッシュを 4.44 倍削減したとしています。1M コンテキストを現実的なメモリで扱うための設計ですね。

ここで気になるのが DGX Spark 1 台にどの量子化なら載るかです。Unsloth の Dynamic GGUF のサイズを、実際にダウンロードして確かめた判定と合わせて並べます。

3-bit はコンテキスト 65536・8 スロットで載りはしたものの、空きが 1GiB しかなく C=1 で 15.17 tok/s と 2-bit より遅い結果でした。ほかのプロセスを同居させる余地がないため、ロード確認にとどめています。本戦は本命の 2-bit と、さらに削った 1-bit の 2 段で回し、量子化でどこが崩れるかも見ていきます。

動かすまで

実行環境は DGX Spark（GB10、統合メモリ 121GiB、帯域約 273GB/s）1 台、エンジンは llama.cpp です。ただし GLM-5.3-Flash の glm5_next アーキテクチャは llama.cpp 本家にまだマージされていないため、Unsloth が公開しているブランチをビルドします。

git clone --branch glm5next/upstream --depth 1 https://github.com/unslothai/llama.cpp
cmake llama.cpp -B llama.cpp/build \
    -DBUILD_SHARED_LIBS=OFF -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=121
cmake --build llama.cpp/build --config Release -j \
    --target llama-cli llama-mtmd-cli llama-server llama-gguf-split

GB10 は compute capability 12.1 なので CMAKE_CUDA_ARCHITECTURES=121 を指定します。ビルド自体は素直に通りました。モデルは Hugging Face から量子化 2 種と、画像入力に使う mmproj を取得します。合計で約 203GB です。

hf download unsloth/GLM-5.3-Flash-GGUF \
  --include "UD-Q2_K_XL/*" --local-dir ~/models/GLM-5.3-Flash-GGUF
hf download unsloth/GLM-5.3-Flash-GGUF \
  --include "UD-IQ1_S/*" --local-dir ~/models/GLM-5.3-Flash-GGUF
hf download unsloth/GLM-5.3-Flash-GGUF \
  --include "mmproj-F16.gguf" --local-dir ~/models/GLM-5.3-Flash-GGUF

serve は llama-server で、チャットテンプレートをそのまま使う --jinja と mmproj を渡します。

llama-server \
  --model ~/models/GLM-5.3-Flash-GGUF/UD-Q2_K_XL/GLM-5.3-Flash-UD-Q2_K_XL-00001-of-00004.gguf \
  --mmproj ~/models/GLM-5.3-Flash-GGUF/mmproj-F16.gguf \
  --host 0.0.0.0 --port 8080 \
  --ctx-size 65536 --parallel 8 \
  --n-gpu-layers 999 --jinja

2-bit をコンテキスト 65536・8 スロットで起動した状態で、メモリ使用は 110/121GiB でした。KDA 層が KV を持たない設計のおかげか、109GB のモデルを載せてもコンテキスト分の余裕が残ります。ロード時のログには blk.45.nextn.* のテンソルを無視した旨が出ており、モデル自体は投機デコード用の MTP ヘッドを内蔵しているものの、llama.cpp 側が未対応という状態も分かります。

思考の強さは、チャットテンプレートが reasoning_effort を low / high / max の 3 段で受け付けます。llama-server はリクエストごとの chat_template_kwargs に対応しているので、API 呼び出し側から次のように渡せます。

{ "chat_template_kwargs": { "reasoning_effort": "low" } }

未指定だと max に解決される点は要注意です。「思考を軽くしたい」なら明示的に low を渡す必要があり、後述するようにここが実用の分かれ目になりました。

速度

強制長 256 トークン・temperature 0 で、同時実行数を変えながら測りました。数値は tok/s です。

C=1 で 2-bit が 17.72 tok/s、TTFT は 0.333 秒。8 並列まで積むと合計 63.97 tok/s まで伸びます。320B クラスのモデルが 1 台でこの速度なら、単独利用の対話には十分実用的ですね。

ここで意外だったのが 1-bit との差です。重みは 108.7GB から 93.1GB へ 14% 減っているのに、速度は 18.68 tok/s と 5% しか変わりません。デコードの主コストがアクティブ 18B 分の読み出しと逆量子化に集中していて、総サイズの差がそのまま速度に返ってこない形です。つまり 1-bit を選ぶ動機は速度ではなく、空いた 15GB をコンテキストや同居プロセスに回せることになります。

なお、ロード時に無視されていた MTP ヘッド（blk.45.nextn.*）を llama.cpp が使えるようになれば、投機デコードで伸びる余地は残っています。本家には GLM-5.3-Flash 用の NextN ヘッドを実装する PR #27917 が draft で出ており、作者の報告では受理率 0.74、CPU オフロード環境で 15〜30% の高速化とのことです。ただし glm5_next 本体のマージが先で、今回使った Unsloth ブランチ（2026-08-30 時点）ではまだ使えません。この draft PR を先取りして試した結果は、次の章に追記しました。

MTP を draft PR で先取りしてみた

（2026-08-30 追記）前の章で触れた PR #27917 のブランチをビルドして、MTP が DGX Spark 1 台でどれだけ効くかを試しました。そのままでは Unsloth 製の GGUF を読めません。ブランチ側がアーキテクチャ名を glm5-next、Unsloth 側が glm5next と登録していて識別子が食い違うためで、src/llama-arch.cpp の名前表 1 行を glm5next に書き換えてビルドし直すと載りました。複数スロットで動かすには --kv-unified が必須で、mmproj はこのブランチでは読めないためテキストのみです。

測ったのは、同じバイナリで MTP なし・draft 3・draft 5 の 3 条件を effort=low・並列 1 で回した実生成です。強制長の速度ベンチではなく、日本語 core 4 課題とコード生成 5 問の所要から実効 tok/s を出しています。

コード生成では draft 3 で 33% 速くなりました。一方で日本語の散文は 3.6% 増と誤差の範囲で、draft 5 は受理率が落ちて日本語では 7% 遅くなっています。draft ヘッドが当てやすい出力でだけ効く、という素直な結果ですね。作者報告の 15〜30% は CPU オフロード環境の数字で、GPU に全部載っている Spark では 1 トークンあたりの素のコストが小さいぶん、外れた draft の検証コストが相対的に重くなります。

並列運用には使えませんでした。8 スロットで draft 3 を回すと、C=8 の合計がこのブランチの MTP なしの 41.09 tok/s から 24.19 tok/s へ半減し、直後に CUDA の illegal memory access で落ちています。draft PR の段階なので当然といえば当然で、本家にも同種の issue が出ています。draft 5 の正答 4/5 が MTP の副作用か temperature 1.0 の揺れかは、1 回の測定では判断できません。

現時点の使いどころは「単発でコードを書かせるなら draft 3 を試す価値あり、日本語の対話と並列運用では切る」です。本家へのマージ後に、条件を揃えて測り直す予定です。

日本語

日本語 10 課題（機械判定 9 + 自由記述 1）を、effort の 3 水準で測りました。ここが今回の記事で一番深掘りした章です。

effort=max 行は出力予算 16384 トークン・サーバスロット 2、low と high の行は予算 8192・スロット 8 での測定です。2-bit の low は 3 回反復し、表には 1 回目を載せています（3 回のスコアは 7 / 7 / 6）。

まず所要時間です。low は 98 秒、high は 141 秒、max は 1736 秒。low と high はスコアが同じ 7/9 で、max は 18 倍の時間をかけて 6/9 と、むしろ下がっています。「思考した課題」の列を見ると、low は 10 課題中 8 課題で思考をまったく書いておらず、実質は非思考モードとして動いています。high は 7 課題で思考しつつ 141 秒に収まるので、思考を残したいならここが現実的な水準ですね。

max で何が起きているかは、固有名詞を残して要約する課題がよく示しています。思考が 16384 トークンをまるごと食い切って本文が空のまま打ち切られ、この現象は 8192 予算でも、2-bit でも 1-bit でも再現しました。予算を倍にすると思考も倍に伸びる（同課題の思考が約 1.4 万字から約 2.8 万字へ）ので、予算の積み増しでは解決しません。Z.ai 自身の評価では HLE で最大生成 163,840 トークン、Terminal-Bench でも 65,536 トークンを与えており、max はその桁の思考予算を前提にした設定です。17.7 tok/s のローカル環境とは桁が合いません。

思考の中身も見ておきます。日本語で聞いているのに、思考は全編英語でした。max の 10 課題すべてが The user is asking me in Japanese... で始まり、数値推論に至っては Let me translate the problem と英訳してから解いています。これ自体は出力の日本語には響いていないのですが、落ちた課題を並べると「英語で考えて日本語を数える」構造が指示精度に効いている様子が見えてきます。

落ち方は 3 パターンに整理できました。1 つ目は 50 字以内で答える課題で、2-bit は 5 回すべて不合格です。ただし中身を見ると、そのうち 3 回は本文が 42〜47 字に収まっていて、末尾に付けた文字数の自己申告が制約を押し出していました。high の出力がこれです。

日本の首都は東京です。かつて江戸と呼ばれたこの地は、明治維新後、政治の中心として発展しました。

（43 文字）

本文は 47 字。自己申告の数字も違っていて、その注釈ごと数えると 55 字で不合格になります。残り 2 回は 3 字超過と、制約を無視して 258 字書いた回でした。一方 1-bit は 2 回とも 38〜41 字で、自己申告を付けずに通過しています。

2 つ目は必須語・禁止語つきの社内連絡文で、3 反復中 1 回と max の回が不合格でした。どちらも本文は合格しています。落ちた理由は末尾に付けた自己チェックで、「禁止語：「革命」「シームレス」は使用していません」と禁止語を名指ししたために判定に引っかかりました。丁寧に確認した報告が、そのまま違反になる形です。

3 つ目は固有名詞を残して 150 字以内に要約する課題で、完走した 6 回すべてで「150 字以内」と「固有名詞 6/6」が両立しませんでした。150 字ちょうどに収めた回は名前を 2 つ落とし、6/6 を守った回は 235 字。6/6 を守れなかった 5 回はすべて人名の白瀬透を落としていて、会社名と製品名は一度も落ちていません。長さと固有名詞を天秤にかけたとき、人名から削る癖があるようです。

通った側も書いておきます。敬語変換・JSON スキーマ出力・図表の数値転記・長文からの事実抽出の 4 課題は、両量子化・全 effort・全反復で一度も落ちていません。自由記述の書きぶりも 1 つ引用します。2-bit・effort=low の出力です。

メリット

1. 通勤時間の削減 — 毎日の移動が不要になるため、時間と交通費を節約でき、その分を仕事やプライベートに充てられる。
2. 柔軟な働き方 — 自分に合った環境や時間帯で仕事に取り組めるため、集中力や生産性が向上しやすい。

日本語の文章そのものは自然で、敬語も崩れません。弱いのは「日本語で書く力」ではなく「日本語で数える力」と、聞かれていない自己申告を付ける癖です。運用としては、文字数制約のある用途では「文字数を書かないでください」と一言足すか、後段で数えて切る前提にしておくのが現実的かなと思っています。

壁打ちとして使えるか

単発の課題だけでは、数ターン続けたときの劣化や、長い文書を抱えたままの想起は分かりません。そこで記事固有のプローブを 3 本組み、2-bit で effort=low と high を回しました。思考は履歴に戻さず、一般的なチャット UI と同じ方式です。

機械照合は両 effort とも全問正解でした。A は 1 ターン目に仕込んだ担当者・予算・対象ライン・期限を 7 ターン目に表で正確に再現し、5 ターン目で減額した予算を 10 ターン目の整理でも正しく使っています。10 ターンを通して日本語比率は 0.95 以上、過去発話との重なりは最大 0.07 で焼き直しもなく、劣化の兆候は見えませんでした。

壁打ちの質は本文を読んで判断するしかないので、印象を書いておきます。1 ターン目から「率直な感想を言います」と切り出し、異物の定義が未定・既存検査との重複・成果指標が主観的・品証部だけでは進まない、と弱点を並べたうえで「まず異物データの分析結果があるかどうかを確認させてください。それがスタート地点です」と返してきます。3 ターン目に「不良品写真なら 400 枚ある」と反論しても折れず、異物 5 種で割れば 1 種 80 枚、しかも要るのは良品画像のほう、と理由を立てて 400 枚を学習データではなく要件定義の材料と位置づけ直しました。high では一歩進んで、正常品だけで学習する異常検知方式に切り替えて 400 枚は検証用の正解データに回す、という筋のいい代替案まで出てきます。5 ターン目の減額には「範囲の広さではなく機能の豪華さを削る」と方針を立て、それまでの自分の主張と矛盾なく繋げました。

B では仕込んだ矛盾 3 件を章番号付きで拾ったうえで、自分が意図していなかった矛盾を 2 件追加で見つけてきました。「管理部門へ 5 分以内に通知」と「管理部門には 10 分以上の停止のみ通知」の食い違い、「リアルタイム表示」と「クラウド転送は 5 分周期」の食い違いで、どちらも文書として実際に破綻しています。レビュアーとしては、仕込んだ側が負けた格好ですね。

C は約 1 万トークンの文書を貼った最初の返答に 46 秒かかりますが、以降は llama.cpp のプロンプトキャッシュが効いて、短い問いなら 1〜8 秒、提案を 5 つ書かせた 7 ターン目でも 24 秒で返ります。1 万トークンの文脈を抱えたまま 8 ターン、事実 4 件の想起はすべて正解で、6 ターン目の「ここまでの質問と回答を一覧に」も 4 件とも正確でした。長い資料を貼って質問を重ねる使い方は、初回だけ待てばあとは軽いという手触りです。

コストは A で 1 返答あたり low 17〜75 秒、high 17〜92 秒でした。チャット感覚の即答ではありませんが、考えている間に自分も考える壁打ちなら許容範囲かなと思っています。なお 3 シナリオとも 1 回ずつの測定で、反論の鋭さは人読みの印象です。

コードを書かせる

日本語仕様からのゼロ書き 5 問（採点は手元の pytest 49 テスト）と、バグ入りミニリポジトリの修正課題です。まずゼロ書きから。

1-bit の max を除く全構成が 5/5 完答・49/49 全通過です。仕様の中に「読み飛ばすと落ちる条項」を仕込んである課題セットなので、これは素直に強い。1-bit の effort=max だけ 4/5 なのは、期間パースの 1 問で思考が 16384 トークンを食い切ったためで、コードが書けなかったのではなく思考が終わらなかったという、日本語の章と同じ症状です。コード生成に関しては effort を上げても下げても結果が変わらないので、ここでも low で十分という結論になります。

既存バグの修正はエージェント動作（ツールでファイルを読み、編集し、テストを回す）で測ります。

30 ターンの上限に対して 5〜6 ターン、72〜84 秒で 3 つのバグをすべて直して自分から final_answer を宣言しています。ここは effort=max でも思考が暴走せず、Terminal-Bench 2.1 で 84.3 という公表値に恥じない動きでした。興味深いのは、自由回答の課題では長考が止まらないのに、ツールの実行結果が毎ターン返ってくるエージェント動作では思考が短く収まることです。

ツールとして使えるか

ツール呼び出しの形から見ていきましょう。GLM-5.3-Flash のツール呼び出しは <tool_call>{関数名}<arg_key>...<arg_value>...</tool_call> という GLM 独自の XML 形式ですが、llama.cpp の --jinja がこれをネイティブに解釈し、OpenAI 互換の JSON に変換して返してくれます。パーサの追加設定は不要でした。

単発呼び出しは両量子化とも 5/5、複数ツールは 1 メッセージに並列で返すタイプで、擬似ファイルシステムを操作させるエージェント課題も両者完走しました。差が出たのは tool_choice=required です。2-bit は強制指定を守ってツールを 1 件返しましたが、1-bit はリクエストを受理したままツール 0 件で返してきました。エラーではなく静かに契約が破られるので、required 前提のクライアントで 1-bit を使うのは避けたほうがよさそうです。

次にエージェント適性のプローブです。これはハーネスが依存する能力を個別に突くプローブであって、ハーネス本体を動かした結果ではない点にご注意ください。

全構成で落ちているのは 40 ツール規模からの選択課題だけで、それ以外は 2-bit の effort=max なら全通過。ハーネス別の判定でも 2-bit + effort=max は Hermes Agent 相当で「使える」判定が出ています。opencode のようにツール数が多いクライアントでは、この多ツール選択の弱さが効いてくるため「厳しい」判定でした。

ここは日本語やコード生成と逆の傾向で、effort を下げるほど落ちるプローブが増えます。low と high は約 2,500 字の長い system prompt を守れず、high はテンプレートの安定性まで落としました。単発の測定なので揺れはあるにせよ、無人運用の定型出力を任せるなら max が要る、というのが今回の読みです。日常の対話やコード生成は low、エージェントとして常駐させるなら max と、用途で effort を切り替える使い方になりそうです。

量子化の影が見えるのはここでも 1-bit です。effort=max で言語固定が崩れて日本語の質問に英語で答え始め、effort=low ではテンプレート安定性も落ちます。コア能力の表では見えなかった 1-bit の劣化が、エージェント運用の端々に顔を出す格好ですね。

画像

ネイティブマルチモーダルの看板を、mmproj 経由の画像入力で確かめます。課題は合成画像なので正解は厳密に決まっています。

棒グラフ 4 値の転記は両者 4/4、日本語帳票の OCR は文字誤り率 0.0 と、低ビット量子化でも図表と文字は完璧に読めています。設備点検記録の日付・設備番号・振動値まで一字も外しませんでした。

物体列挙（作業者の保護具を挙げる課題）は自動判定こそ両者 ❌ ですが、中身はまったく違いました。2-bit の出力はヘルメット 2 つと反射ベストを正しく挙げたうえで「保護メガネ、手袋、マスクなどは写っていないため挙げていません」と正しく否定しており、判定器がこのまとめ否定の言い回しを幻覚と誤検出した偽陽性です。一方 1-bit は反射ベストそのものを見落としました。図表と OCR では差が出ないのに、自由な視覚認識では 1-bit の劣化が出る、という結果です。

まとめ

DGX Spark 1 台で GLM-5.3-Flash を使うなら、2-bit（UD-Q2_K_XL）+ effort=low の明示指定が今回の実測から出た答えです。この構成なら 17.7 tok/s で動き、コード生成は 5/5 完答、バグ修正も 72 秒で完走し、ツール呼び出しも tool_choice=required まで含めて契約どおりでした。壁打ち 10 ターンでも前提を取り違えず、反論にも折れないので、企画の相談相手としても成立します。320B の MoE が 1 台のデスクトップ機でこの水準というのは、1 年前の感覚からするとかなり不思議な光景ですね。

限界もはっきりしました。既定の effort=max は 10 万トークン級の思考予算を前提にした設定で、ローカルの速度とは桁が合いません。そのうえ英語で考えて日本語を数える構造のせいか、長く考えるほど文字数制約や自己注釈で崩れます。日本語の文章そのものは敬語変換や連絡文を見るかぎり自然で、弱いのは「日本語で書く力」ではなく「日本語で数える力」でした。量子化については、1-bit まで削ってもコア能力は 2-bit とほぼ並ぶ一方、tool_choice の契約破り・言語固定の崩れ・画像での見落としと、端の挙動から先に壊れていきます。15GB の節約でそれを受け入れるかは用途次第ですが、自分なら常用は 2-bit にします。

MTP は draft PR の先取りで手応えをつかめたので、本家へのマージ後に条件を揃えて測り直します。opencode のような実クライアントに繋いだときに多ツール選択の弱さがどう効くかも、続編で試してみたいところです。

参考リンク

• GLM-5.3-Flash - Hugging Face
• GLM-5.3-Flash: How to Run Locally - Unsloth Documentation
• unsloth/GLM-5.3-Flash-GGUF - Hugging Face
• GLM-5.3-Flash - Z.AI 開発者ドキュメント
• GLM-5: from Vibe Coding to Agentic Engineering - arXiv