NVIDIA DGX Sparkは買いか｜16GB GPUを実測し公開ベンチと突き合わせて見えた、128GBが効く条件

DGX Sparkは何を解決する機械か

DGX Spark は NVIDIA GB10 Grace Blackwell Superchip を積んだ小型機で、128GB の LPDDR5x を CPU と GPU で共有する。メモリ帯域は273GB/s（2026年8月時点の公式仕様）。容量と帯域というこの2つの数字で、機械の性格はほぼ決まる。据え置きのGPUと比べて容量は桁が違う一方、帯域のほうは同じようには広がらない。

コア数と帯域のどちらが効くかはGPUのコア数はAI性能にどこまで効くかで整理している。

公式が掲げる「最大1 PFLOP」は、FP4 かつスパース性を有効にしたときの値である。拡散モデルの生成や BF16 での推論にそのまま効く数字ではないため、この一行だけで速さを見積もると実際とずれる。

画像生成側でVRAMがどこまで要るかはMiniMax H3をVRAM 16GBで動かすで扱った。

トークン生成の速度は、メモリ帯域を1トークンあたりに読むバイト数で割った値でおおよそ決まる。NVIDIA Developer Forums でも同じ形の見積もりが示されており、当サイトの実測も同じ形を示す。batch 1 の単一ユーザー利用が前提の計算で、同じ dense であればモデルが大きいほど1トークンあたりに読む量が増え、生成は遅くなる。容量に余裕があることと、出力が速く出てくることは別の話になる。

VRAMに収まる範囲では、小型のGPUのほうが速い

Qwen3 8B の Q4_K_M はファイルサイズが5.2GBで、16GB のGPUに余裕をもって収まる。この範囲では RTX 5060 Ti が 77.51 tok/s、RTX 5080 が 138.84 tok/s を出しており、DGX Spark 側の公開値 43.7 tok/s を上回る。モデルを14Bへ、あるいは gpt-oss-20b へ替えても順序は変わらない。

VRAMに収まるモデル（当サイト実測とDGX Sparkの公開値）

8B の行だけは読み方に注意が要る。DGX Spark 側は第三者が「512コンテキスト」として公開した値で、測定コマンドが公開されていない。そのためこの組ではプロンプト処理どうしを並べていない。一方 gpt-oss-20b の行は llama.cpp 公式リポジトリの測定で、同じ GGUF ファイルと同じフラグ条件（反復回数は非公開）が使われている。そちらでは 5080 の 236.16 tok/s に対して 83.43 tok/s という位置になる。

プロンプト処理の中身をさらに分解した測定はTTFTとは何を測っているのかで扱っている。

ここまでで言えるのは、モデルがVRAMに収まっている限り128GB級を選ぶ理由が見当たらない、ということである。この記事が扱いたいのは、その先にある境界の向こう側になる。

収まらなくなったとき、何が起きるか

qwen3:32b の Q4_K_M は20.2GBあり、16GB のGPUには収まらない。層数の指定を上限のままにして 5080 に渡すと、生成は 2.45 tok/s まで落ちる。同じGPUが 8B では 138.84 tok/s を出していたことを思えば、別の機械の数字のように見える。プロンプト処理も 46.16 t/s まで下がる。

VRAMに収まらないdenseモデル（qwen3:32b Q4_K_M・20.2GB）

あふれた行には前提がある。llama.cpp は 18,842MiB を確保して全65層をGPUに載せたと報告するが、このGPUの物理メモリは 16,303MiB しかない。層をCPUとGPUに振り分けた結果ではなく、GPUメモリの不足分をシステムメモリで肩代わりする仕組みの上で動いている。当サイトの測定環境は Windows で、この肩代わりはドライバの設定で無効にできる。llama.cpp の公式ドキュメントには Linux でも環境変数で同等の退避を有効にできると書かれており、そちらは当サイトでは測っていない。数字を引き写す前に、同じ仕組みが有効な環境かどうかを見ておく必要がある。

層が全部載る条件を別モデルで詰めた例はMuse Glimmer 30BをVRAM 16GBで動かすにある。

落ち方は、はみ出した割合から見積もるよりも大きい。確保量に対してあふれているのは1割強にすぎないが、生成速度とモデルサイズから逆算した実効的な読み出し速度は公称の1割にも届かない。この開きがどこから来るのかは当サイトでは測っていない。分かるのは、あふれた状態ではGPUの公称メモリ帯域がほとんど意味を持たなくなるという点である。

同じ 5080 の中でも差は大きい。逆算すると、収まる 8B では毎秒725.5GB相当、収まらない 32B では毎秒49.6GB相当で、14.6倍の開きになる。生成速度×モデルサイズによる概算で、KVキャッシュの読み書きを含まず、dense でのみ成り立つ計算である。GPUの公称帯域そのものでもない。この14.6倍は、層数を上限指定にした未調整の状態での話になる。

手を入れると景色が変わる。GPUに載せる層数を絞ると、生成は 10.45 tok/s まで戻り、DGX Spark の公開値 10.7 tok/s とほぼ並ぶ位置に来る。落ちた値と戻った値の両方を見ないと、この境界で何が起きているかは読めない。

VRAMに収まらないdenseで、GPUに載せる層数を変えた場合（qwen3:32b Q4_K_M・20.2GB・全65層）

層数を振ったときの動きは単調ではない。45 までは生成もプロンプト処理も一緒に上がる。50 で生成が 10.45 tok/s まで伸びる一方、プロンプト処理だけが 52.38 t/s へ落ち、55 と上限指定では両方が下がる。生成の最良値（層数50）とプロンプト処理の最良値（層数45 の 1556.02 t/s）は同じ層数に来ない。どこで何が崩れているかまでは測っていない。振ったのは5点だけなので、間により良い組み合わせが残っている可能性はある。

同じ「あふれる」でも、denseとMoEでは効く手が違う

gpt-oss-120b の MXFP4 は約63GBある。20.2GB の dense が 2.45 tok/s まで落ちた同じ 5080 に、こちらを層数の指定なしで渡すと 8.93 tok/s 出る。ファイルサイズが3倍あるほうが速い、という逆転が起きる。どちらも設定を詰めていない状態どうしの比較である。

理由はモデルの構造にある。dense は1トークンごとに全部の重みを処理する。MoE ではエキスパート部分について、各トークンで選ばれた一部のエキスパートだけを使う。Attention や共有層は MoE でも毎回処理されるため、モデル全体で活性分しか読まないわけではないが、1トークンあたりにメモリから読む量は総パラメータ数よりはるかに小さくなる。総パラメータと活性パラメータの関係そのものはGLM-5.2をローカルで動かせるかで詳しく扱っている。

同じ傾向は DGX Spark 側の測定にも出ている。Q4_K_M で統一した第三者の公開ベンチでは、dense の生成速度がパラメータ数に反比例し、Qwen3 8B で 43.7 tok/s、Ministral 14B で 26.4 tok/s、Qwen3 32B で 10.7 tok/s となる。これに対し、総パラメータが約30Bの MoE である Qwen3 30B-A3B は 89.3 tok/s で、ほぼ同規模の dense の8倍を超える。統合メモリの機械でも据え置きのGPUでも、種別による差の出方は共通している。

VRAMに収まらないMoEモデル（gpt-oss-120b MXFP4・約63GB）

設定を詰めれば、あふれた側はどちらも大きく戻る。MoE はエキスパート層をCPU側へ置く指定（n-cpu-moe を36層に適用）で 20.49 tok/s、dense はGPUに載せる層数を50に絞ることで 10.45 tok/s。dense に逃がし方が無いわけではない。分かれてくるのはその効き方で、MoE 側はもともと各トークンで参照するエキスパートが限定されるため、その性質に合わせて配置を調整できる。n-cpu-moe が変えているのは重みの配置であって、モデルが論理的に読む量そのものではない。いずれも当サイトの環境で最良だった設定で、機体やモデルが変われば最適値も変わる。

この構成には前提がもう一つある。約63GBの重みをシステムメモリ側に置くため、測定はシステムRAMを96GB積んだ機体で行っている。RAMが足りない機体では起動しない。

GPUを2枚にすれば解決するのか

20.2GB の dense は、5080 と 5060 Ti の合計32GBに載り切る。1枚で層数を50に絞ったときの 10.45 tok/s に対して 34.73 tok/s、プロンプト処理も 983.35 t/s になり、層数を探す作業自体が不要になる。載せ切れる容量であれば、2枚目の効果は劇的に出る。

約63GB の MoE では事情が変わる。合計32GBには載せ切れないため、2枚目を足しても調整済みの1枚（20.49 tok/s）は超えなかった。とはいえ指定なしの1枚 8.93 tok/s からは 17.0〜17.62 tok/s へ上がっており、届かないのはあくまで調整済みの値に対してである。2枚の行はいずれも、エキスパート層をCPUへ回す指定を併用した測定になる。

2枚構成では分割方式でも差が出る。約63GBのモデルでは、テンソル分割のプロンプト処理が 82.21 t/s まで落ち、レイヤー分割の 546.19 t/s を大きく下回った。生成速度側は両方式でほとんど差がない。プロンプト処理だけが落ちる形は、GPU間の通信が細いほどテンソル分割が不利になることを示している。ここで使った2枚目は OCuLink 接続の RTX 5060 Ti で、GPU間の帯域・分割方式・モデル構造・GPUの性能が変われば結果も変わる。今回の約63GB級 MoE ではこうなった、という範囲の話になる。

2枚構成の消費電力と電源容量についてはローカルLLM推論時のGPU電力を実測で測っている。

画像生成・動画生成ではどうなるか

拡散モデルでは、LLMのような容量の崖が出にくい。処理がテキストエンコード・ノイズ除去・デコードと工程に分かれており、工程ごとに必要なモデルだけをGPUに置いて入れ替えられるためである。重み全体が同時にVRAMへ載っている必要がない、という構造の違いが効く。

画像生成・動画生成にかかる時間（初回ロード後の反復生成。条件は表内に記載）

Tom’s Hardware のレビューでは、ComfyUI で同一シードの FLUX.2 Klein 9B を回したとき、初回ロード後の反復生成が DGX Spark で60秒強だったとされる。LTX-2 の動画生成は720pの短い動画で3分強。ステップ数と解像度は記事に明記されていない。

同じ128GB級でも、Strix Halo 側の報告は様子が違う。画像は DGX Spark の約4倍かかり、動画は ROCm 7.1.1 でも HIP エラーが出て ComfyUI が停止するかデスクトップ環境ごと落ち、実行できなかったとされている。2026年1月時点のレビューでの状況で、ROCm の対応状況は変わりうる。

比較として、当サイトの検証環境の16GBのGPUの数字を置く。1024×1024・4ステップの FLUX.2 Klein 9B は 6.17秒。動画も1280×720まで上げて収まりきり、2回目以降は88.0秒で完了した。ただしVRAMのピークは15,746MBで、搭載16GBに対する余白はほとんど残っていない。

動画については、出力される長さに対して所要時間が桁で大きいという性質のほうが効く。41フレーム・24fps は約1.7秒の動画で、16GBのGPUでは 512×320 で約23倍、1280×720 では約52倍の時間がかかっている。1ステップあたりで見ると 512×320 が1.95秒、1280×720 が4.40秒。いずれも2回目以降の所要時間をステップ数と動画の長さで割った値で、追加の測定ではない。ステップ数は20である。

これらを並べても、秒数の差をそのまま性能比として扱うことはできない。レビュー側はステップ数・解像度・尺のいずれも記載がなく、条件が揃わないためである。読み取れるのは桁の違いまでになる。レビュー筆者自身も、潤沢なメモリのおかげで Spark はほぼどんな画像モデルでも扱えるが、ディスクリートGPUのほうがさらに速い、ただし手持ちのVRAMを用途に合わせる必要がある、という整理をしている。

画像・動画で128GBの統合メモリが買うのは速度ではない。測れた範囲の中では、16GBのGPUのほうが速く終わっている。買えるのはその範囲の外にある余白のほうで、解像度やフレーム数を上げれば中間データが増え、工程ごとの入れ替えでは逃がせなくなる。ワークフローごとの条件は下の表の「条件」列にある通りで、そこを超える領域は当サイトでは扱っていない。動画で測ったのも LTX-2 19B distilled の Q4 版で、この範囲の話になる。

参考: 当サイトのGPUでのワークフロー別内訳

「1ステップあたり」は所要時間をワークフローのステップ数で割った値、「動画1秒あたり」は出力される動画の長さ（41フレーム÷24fps＝約1.7秒）で割った値で、どちらも測定値からの割り算である。所要時間は2回目以降、つまりモデルが載った状態の平均になる。この表で見ているのは時間とVRAMのピークだけで、生成物の品質は評価の対象にしていない。

同じ128GBのStrix Haloと比べる

Ryzen AI Max+ 395（Strix Halo）は、メモリ帯域が256GB/sで DGX Spark の273GB/sに近い。数字が近いぶん、公開ベンチの読み方で結論が動く。同じ gpt-oss-20b・同じコンテキスト深度32768でも、ROCm では生成 52.23 tok/s・プロンプト処理 1124.14 t/s、Vulkan では生成 61.12 tok/s・プロンプト処理 555.73 t/s と、得意が入れ替わる。生成の速いほうとプロンプト処理の速いほうを別々のバックエンドから拾い、1台の性能として並べることはできない。ここに挙げた2つ以外のバックエンドも同じ公開ベンチは測っており、そこまで含めた確認はしていない。

同じ深度32768での DGX Spark 側は生成 61.65 tok/s・プロンプト処理 2689.42 t/s。Strix Halo はどちらのバックエンドを選んでも、この2つを同時には上回らない。生成はほぼ同着で、開いているのはプロンプト処理のほうである。長い入力を毎回読ませる使い方をするかどうかが、選択を分ける軸になる。いずれも当サイトの実測ではなく公開された測定値で、ビルドもバックエンドも異なるため、テスト条件が同じでも厳密な同条件比較ではない。

買ってすぐ全力が出るわけではない

NVFP4 での推論については、vLLM が2026年6月に DGX Spark 向けの解説を公開しており、専用の配信インターフェースは不要で標準の OpenAI 互換サーバで動くとされている。ただし同記事が検証に使っているのは nightly 系のコンテナイメージで、動作確認済みのイメージやタグを選ぶ手間は残る。推論エンジンそのものの選び方はローカルLLM推論エンジン比較で扱っている。

ComfyUI 側では、DGX Spark で .safetensors 形式のモデルを読み込むとメモリを二重に消費し、使えるメモリが実質半分になるという問題が報告されていた。GGUF 形式では発生しない。報告された Issue は2026年6月にメンテナがクローズしているが、そこから関連付けられている修正 PR は2026年8月時点でも未マージのままで、現行版で完全に解消しているかは本記事では確認できていない。GitHub 上の状態を2026年8月21日に確認した時点の話になる。

整備が進んだ領域と、専用ビルドや指定が要る領域が同居している、というのが2026年8月時点の状況である。

結局、誰が買うべきか

常用するモデルが手元のGPUに収まっているなら、買う理由は出てこない。あふれる側にいて、設定を詰める作業を挟まずに動かしたいのであれば、そこが DGX Spark の立ち位置になる。統合メモリに収まっている限り、1枚のGPUでやったような層数の振り分けは発生しない。ただし2枚に載せ切れる容量帯では、2枚構成のほうが生成もプロンプト処理も上回り、そちらも層数を探る必要が無い。

差の出方はモデルによって違う。20.2GB の dense では調整後の 10.45 tok/s が公開値 10.7 tok/s とほぼ並ぶ。一方、約63GB の gpt-oss-120b では当サイトの最良設定が生成 20.49 tok/s・プロンプト処理 657.75 t/s であるのに対し、DGX Spark 側は 58.72 tok/s・2443.91 t/s で、どちらの指標も倍以上に開く。比べた2点はサイズだけでなく dense と MoE の違いも、値の出所も異なるため、サイズだけで説明できる法則としては読めない。

常用モデル別の判断表

境界のどちら側にいるかは、常用するモデルのファイルサイズと種別で決まる。ファイルサイズは Ollama なら一覧表示の容量欄、GGUF を直接置いているならファイルの容量がそのまま目安になる。種別は、モデル名に「30B-A3B」のように総パラメータと活性パラメータが併記されていれば MoE を疑う手掛かりになる。ただし MoE が必ずこの表記を持つわけではない。gpt-oss は 20b も 120b も MoE だが、そうした表記は無い。命名は手掛かりに留まるので、最終的な確認はモデルカードのアーキテクチャ欄で行う。

MoE をあふれさせて動かす選択肢は、システムメモリの量に左右される。重みをシステムメモリ側に置くため、モデルのファイルサイズを超える空きが要る。当サイトの測定は96GBを積んだ機体によるもので、これより少ない機体で成立するかは確認していない。必要量はモデルのサイズで変わるため、約63GBのモデルでの話として読む必要がある。常用モデルが MoE なら、128GB級を検討する前に手元のメモリ量を確認する価値がある。

費用は、据え置きGPU1枚 → 2枚 → 128GB級の順に上がる。

GPU以外にどこまで予算を回すかの考え方はAI用PCでCPUはどこまで重要かで整理している。

候補になる機種

GB10 を積んだ機械は複数社から出ているが、チップ（GB10）・128GB LPDDR5x・ConnectX-7 SmartNIC・10GbE・Wi-Fi 7・NVIDIA DGX OS は各社版で共通している。そのため表に載せたのは、機種ごとに実際に違う項目になる。

GB10 版どうしの主な違いは、選べるストレージの世代と容量、それに筐体の寸法と重量にあたる。ASUS Ascent GX10 の重量は日本の公式仕様ページの表記で、グローバル版のページには1.48kgと記載があり、表記に差がある。

もう一つ、各社版に共通する要素として、2台を ConnectX-7 でつなぐと扱えるモデルの規模が上がる。報道では1台で2000億パラメータ級、2台で4050億パラメータ級とされている。扱える規模の話であって、速度の話ではない。

まとめ

判断の分かれ目は、常用するモデルがGPUのVRAMに収まっているかどうかにある。収まっている間は据え置きのGPUが速く、当サイトの実測でも公開されている測定値でも順序は動かない。あふれた時点で、それまでの単純な速度差では読めなくなる。設定を詰めたかどうか、dense か MoE か、合計VRAMに載せ切れるかで順位が入れ替わるためである。

あふれた側での手当ては2通りある。dense はGPUに載せる層数を絞り、MoE はエキスパート層をCPU側へ回す。どちらも手を入れて初めて戻る値で、放置した状態の数字とは別物になる。DGX Spark が提供するのは、その手当てが要らない容量帯の広さのほうで、速度そのものではない。画像・動画についても同じ形で、測れた範囲では16GBのGPUが速く終わっている。

最初の一歩は、常用しているモデルのファイルサイズを確認し、手元のGPUのVRAMと突き合わせるところに置ける。Ollama なら一覧表示の容量欄で足りる。収まっているならGPUの世代や枚数のほうが効き、あふれているなら層数やエキスパート配置の指定を試し、それでも足りない場合に128GB級が検討対象に入る、という順序になる。

よくある質問

DGX Spark の128GBは、そのまま全部モデルに使えるのか

使えない。128GB の LPDDR5x は CPU と GPU で共有する統合メモリで、OS もそこから使う。モデルに回せる上限が実際どこまでかは本記事では確認していない。128GB をそのまま上限として容量を計算すると、見積もりがずれる。

dense の70B級モデルは動くのか

動作報告はあるが、生成の速さには帯域から来る上限が効く。NVIDIA Developer Forums には、vLLM で Llama 3.3 70B を FP8 で動かした場合に batch 1 で毎秒2〜3トークン程度になり、同スレッドの一利用者が「GB10 で想定される上限」と回答した事例がある。コミュニティ利用者の報告で、NVIDIA の公式見解ではない。同じスレッドでは別の利用者が、draft model を使う方式でチャットが毎秒7〜8トークン、コード生成では18トークン以上という報告もしている。後者は推論エンジンが異なり（llama.cpp 系）、量子化も同一ではない。通常の1トークンずつの生成に帯域の上限が効くこと自体は変わらないものの、推論方式によって実効的な出力速度が上がる余地は残る。

コンテキストが長くなると速度は落ちるのか

落ちる。同じ gpt-oss-20b の公開ベンチで、DGX Spark はコンテキスト深度0で 83.43 tok/s、深度32768では 61.65 tok/s になる。本記事の当サイト側の表はいずれも深度0での測定なので、長い履歴を抱えたまま使ったときの落ち方は、ここに載せた数字からは読み取れない。

GB10 を積んだ各社版は、どれを選んでも同じ結果になるのか

チップは同じ GB10 で、128GB LPDDR5x・ConnectX-7 SmartNIC・10GbE・Wi-Fi 7・NVIDIA DGX OS も共通している。公開仕様の上で違うのは、選べるストレージの容量と世代、筐体の寸法と重量にあたる部分になる。選ぶ基準としては、必要なストレージ容量と設置場所の条件が先に来る。

参考資料

• NVIDIA DGX Spark 製品ページ（仕様）
• llama.cpp 公式リポジトリの DGX Spark ベンチマーク
• DGX Spark の dense / MoE 比較ベンチマーク（Q4_K_M 統一）
• NVIDIA Developer Forums: dense 70B が3 tok/s になる理由
• AMD Strix Halo のバックエンド別ベンチマーク
• ComfyUI: DGX Spark で .safetensors 読み込み時にメモリを二重に使う問題
• Tom’s Hardware: NVIDIA DGX Spark レビュー（性能）