DGX Spark を 2 か月使って見えた「向いている仕事」 と 「向いていない仕事」
はじめに
こんにちは、クラスメソッド製造ビジネステクノロジー部の森茂です。
DGX Spark を使い始めてから約 2 か月が経ちました。この間、LLM 推論、ファインチューニング、映像 AI、ロボティクス、画像生成と、思いつく限りのワークロードを動かしてきました。公開した記事はいつの間にか 20 本を超えていました。。。
ひと通り触ってみて感じたのは、「128GB は万能ではないけれど、代替が効かない場面が確かにある」ということです。この記事では、実測データと失敗経験をもとに「DGX Spark が得意なこと」と「苦手なこと」を整理してみます。購入を検討している方、すでに持っているけれど使い道を探している方の参考になればうれしいです。
DGX Spark を一言でいうと
DGX Spark の最大の特徴は、128GB の統合メモリ（UMA: Unified Memory Architecture）です。CPU と GPU がメモリを共有しているので、32GB VRAM の RTX 5090 では物理的に載らないモデルが、そのまま動きます。
よく比較される構成と並べてみました。
| 項目 | DGX Spark | Mac Studio M3 Ultra | RTX 4090 | RTX 5090 |
|---|---|---|---|---|
| 価格 | $4,699 | $3,999〜（96GB） | $1,599（MSRP） | $1,999（MSRP） |
| メモリ | 128GB LPDDR5x | 最大 512GB | 24GB GDDR6X | 32GB GDDR7 |
| メモリ帯域幅 | 273 GB/s | 819 GB/s | 1,008 GB/s | 1,792 GB/s |
| 消費電力 | 170W（TDP） | 〜200W | 〜450W | 〜575W |
| OS | Ubuntu 24.04 ARM | macOS | Windows/Linux | Windows/Linux |
この表で目を引くのはメモリ帯域幅の差ですね。273 GB/s という数値は Mac Studio（819 GB/s）の 3 分の 1、RTX 4090（1,008 GB/s）の 4 分の 1 程度で、RTX 5090（1,792 GB/s）と比べると約 6.5 倍の開きがあります。一方で RTX 5090 でも VRAM は 32GB なので、大きなモデルを載せきれないという制約は変わりません。この帯域幅の差が、後述する「向き・不向き」に直結しています。
ざっくり言うと、DGX Spark の強みは「速さ」ではなく「載ること」。128GB のメモリ空間に大きなモデルをまるごと載せて、ローカルで完結させられるのが最大の価値です。カンファレンスでも AI の利用環境には F1 vs SUV に分類できると比喩していたものがあったのですが、その例えからだと DGX Spark は SUV 側のイメージと言えそうです。
向いている仕事
2 か月使ってみて「これは DGX Spark ならでは」と感じた用途を 5 つ紹介します。
大きなモデルをまるごと載せる推論
RTX 5090 の 32GB では動かせない 70B〜120B クラスのモデルが、DGX Spark なら 1 台で動きます。
Nemotron 3 Super（120B-A12B）を Ollama で動かしたところ、モデルロードに約 87GB のメモリを消費し、JCommonsenseQA（日本語常識推論）で正答率 94.4% を記録しました。同ファミリーの軽量モデル Nano（30B-A3B）は 87.0% だったので、パラメータ数の差が精度にしっかり反映されています。
NVIDIA の gpt-oss:120b（アクティブ 5.1B の MoE）も 1 台で動作しましたし、Qwen3-235B-A22B（MoE、アクティブ 22B）も 1 台でギリギリ載りました。「デスクトップ 1 台で 100B 超のモデルが動く」というのは、触ってみるとインパクトがあります。
30GB を超えるファインチューニング
ファインチューニングは推論よりもメモリを食います。モデル本体に加えて、勾配やオプティマイザの状態を保持する必要があるためです。RTX 5090 の 32GB ではオフロードやメモリ節約テクニックが必須になるような学習タスクでも、128GB の統合メモリなら余裕を持って回せました。
たとえば FLUX.1（12B）の Dreambooth LoRA ファインチューニングでは、学習中に GPU メモリ 71GB、システムメモリ 96GB を使用しました。LoRA Rank も通常の 8〜64 ではなく 256 に設定でき、品質面でも攻められます。学習時間は 500 ステップで約 3.4 時間でした。
ロボティクス分野でも、GR00T N1.6 のファインチューニングが 90.8GB / 128GB のメモリ消費で 5 時間 47 分かけて完走しています。128GB をほぼ使い切る水準ですが、OOM にはならずに済みました。
Nemotron 9B-v2-Japanese の RAFT LoRA や、Qwen3.5 4B の日本語キャラクター LoRA、LeRobot ACT の模倣学習なども問題なく動いています。「学習タスクをローカルで完結させたい」という用途には、128GB の統合メモリが効いてきます。
映像 AI のローカル完結パイプライン
NVIDIA VSS（Video Search & Summarization）を使った映像 AI パイプラインは、DGX Spark と相性が良い用途の一つです。
VSS 2.4.x では LLM + VLM + Embedding + Reranker を組み合わせた映像検索エージェントを動かしました。GPU メモリ消費は VLM に約 37GB、LLM に 18GB、NIM（Embedding + Reranker）に 6GB と、合計で約 61GB とそれなりに重い構成でしたが、日本語クエリでの映像検索や要約が動作しています。
より軽量な構成も可能です。Event Reviewer は CV（GroundingDINO）+ VLM（Cosmos-Reason2-8B）の 2 段構成で、コンテナ数は 8 つ、GPU メモリ使用量は 45GB / 128GB（35%）に収まりました。コンベアベルト上の段ボール箱を検出し、VLM で損傷判定を行うユースケースでは、GPU 使用率 1〜37% と余裕のある負荷で動いています。
映像データをクラウドに出せない環境や、常時稼働の監視用途には、ローカルで完結する DGX Spark の構成が選択肢になりそうです。
ロボティクスの学習基盤
SO-ARM101 というロボットアームの模倣学習（ACT: Action Chunking with Transformers）を DGX Spark で学習させたところ、GPU メモリ 18GB の消費で約 7 時間（100,000 ステップ）で完了しました。
興味深かったのは、推論時の FPS が成功率に直結する点です。Mac の MPS（15Hz）では成功率 40% だったのに対し、DGX Spark の CUDA（30Hz）では成功率 90% まで上がりました。ロボティクスのように「学習→推論→実機評価」のサイクルを手元で回す用途では、GPU メモリの余裕と CUDA の安定した推論速度が活きてきます。
常駐する開発インフラ
DGX Spark は消費電力が低く（アイドル時 40〜45W、推論時 135〜140W）、ファンレスに近い静音設計です。電源を入れっぱなしにしても気にならない存在感で、開発インフラとして常駐させるのに向いています。
Continue.dev + VS Code でローカル LLM によるコード補完環境を構築したり、Cosmos-Reason2-8B（32GB）を常駐させて映像分析に使ったり、NemoClaw でローカルエージェント環境を立ち上げたりと、「必要なときにすぐ使えるローカル AI」として重宝しています。
クラウド API の従量課金を気にせず、思いついたときに試行錯誤できるのは精神的にも楽ですね。
向いていない仕事
一方で、「これは DGX Spark でやるべきではなかった」と感じた場面もありました。同じことを試そうとしている方の時間を節約できればと思い、正直に共有します。
トークン生成速度が求められる用途
LLM の推論は、大きく 2 つのフェーズに分かれます。プロンプトを一気に読み込む prefill と、トークンを 1 つずつ生成する decode です。
prefill は並列処理が効くので、DGX Spark の計算能力が活きます。Nemotron 3 Super で prompt eval 112.4 tok/s が出ています。しかし decode はメモリ帯域に律速されるため、273 GB/s の DGX Spark では 17.9 tok/s にとどまりました。
「プロンプトを読むのは得意だけれど、文章を書くのは苦手」というのが直感的な理解です。長文のバッチ生成やリアルタイムチャットでレスポンス速度を求める用途では、HBM を搭載したクラウド GPU のほうが快適でしょう。
128GB を使い切るモデル
128GB は大きいですが、上限は上限です。Cosmos Predict 2.5 の 14B モデルに挑戦した際は、モデルロードには成功した（約 51GB）ものの、推論時に中間テンソルが一気にメモリを消費し、システムごとフリーズしました。3 回試して 3 回とも同じ結果です。14B という数字は一見小さく見えますが、動画生成モデルは画像生成モデルよりフレーム分のアクティベーションが大きく、128GB でも足りなくなるケースがあるということですね。
推論時には中間テンソルやアクティベーションでモデルサイズ以上のメモリが必要になるため、「モデルが載る ≠ 推論できる」という点は注意が必要です。実感としては、学習タスクでは 90GB 程度（128GB の 70%）が安全圏で、それを超えると OOM のリスクが高まります。
2 台クラスタで速度を稼ぐ
DGX Spark は ConnectX-7（200Gbps）で 2 台を直結できます。メモリ空間を 256GB に拡張して、1 台では載らないモデルを動かせるのは確かです。
ただし、速度面の改善は限定的でした。Qwen3-235B-A22B で測定したところ、1 台構成の 15.51 tok/s に対して 2 台構成で 14.57 tok/s と、むしろ若干遅くなっています（RPC のオーバーヘッド）。Dense 123B モデルの Devstral 2 では 2 台構成で decode 2.64 tok/s と、実用的とは言いにくい速度でした。
2 台クラスタの価値は「速くなること」ではなく「より大きなモデルが動くこと」にあります。Qwen3-Coder-480B（168GB）や Llama 4 Maverick（143GB）のように 1 台に収まらないモデルを動かしたい場合には有効ですが、速度向上を期待して 2 台目を買うのはおすすめしません。
なお、2026 年 3 月の NVIDIA 公式ブログでは最大 4 台までのクラスタ構成が紹介されており、512GB のメモリ空間で DeepSeek-R1 671B のようなモデルを動かすシナリオが示されています。自分はまだ 4 台構成を試せていませんが、興味のある方は以下のブログを参照してみてください。
Claude Code のローカル代替
DGX Spark の 128GB があれば Claude Code をローカル LLM で代替できるのではないかと期待して試しましたが、結論としては難しい状況でした。
gpt-oss の 120B モデルでもツール呼び出しの精度が安定せず、Edit ツールの成功率にばらつきがありました。これはハードウェアの問題というよりモデル側の課題で、120B でもエージェント的なタスクの精度には壁があるようです。ローカル LLM の進化とともに状況が変わる可能性はありますが、現時点ではクラウドの Claude に頼るのが現実的です。
prefill vs decode を理解する
ここまで「向き・不向き」の話をしてきましたが、その根底にあるのがメモリ帯域幅の問題です。少しだけ掘り下げます。
LLM の推論が 2 フェーズに分かれることは先ほど触れました。
prefill はプロンプト全体を一括で処理するフェーズです。行列積の並列演算が主体なので、GPU の計算能力（FLOPS）がボトルネックになります。一方の decode はトークンを 1 つずつ生成するフェーズで、毎ステップで全パラメータをメモリから読み出す必要があるため、メモリ帯域幅がボトルネックになります。
DGX Spark の GB10 は計算能力（FP16 推定 ~62 TFLOPS）は十分にありますが、メモリ帯域幅は 273 GB/s と控えめです。そのため prefill は速い（Super で 112.4 tok/s）のに、decode は遅い（同 17.9 tok/s）という非対称な性能特性になります。
この特性を理解しておくと、DGX Spark の使い道が見えてきます。
- prefill が重要な用途（大量の入力を読み込んで短い出力を返す）→ DGX Spark が活きる
- RAG の検索クエリ処理、映像の VLM 分析、コード補完の提案生成
- decode が重要な用途（長い文章を逐次生成する）→ クラウド GPU のほうが快適
- ブログ記事の全文生成、翻訳の一括処理、チャットボットのストリーミング応答
ユースケース判定フローチャート
自分の用途に DGX Spark が合うかどうか、簡易的な判定フローを作ってみました。
あくまで目安ですが、判断のとっかかりにはなるかと思います。
2 か月使って感じたこと
最後に、スペックや実測データには現れにくい使用感を少しだけ。
静音性は想像以上です。アイドル時 40〜45W、推論が終われば GPU がすぐにアイドルに戻るので、常時起動していても気になりません。自分はデスク横に置いて開発インフラとして使っていますが、存在を忘れることもあります。
ARM64 環境のハマりポイントは覚悟しておいたほうがいいです。x86 前提でビルドされたコンテナイメージや Python パッケージが動かないケースに何度か遭遇しました。NVIDIA の NIM（Nemotron-Nano-9B-v2）の ARM64 イメージが中身 x86 バイナリだったこともありましたし、vLLM の CUTLASS カーネルが sm_121 に非対応で動かない場面もありました。大抵は回避策が見つかりますが、「すべてがすんなり動く」とは思わないほうがいいですね。
Playbook エコシステムは充実してきています。NVIDIA が公式に提供する Playbook を使えば、TRT-LLM の推論設定や FLUX.1 の学習環境を手順に沿って構築できます。「何から始めればいいかわからない」という方でも、Playbook を起点にすれば手を動かしやすいかなと思います。
まとめ
2 か月間、DGX Spark でさまざまなワークロードを動かしてきました。見えてきたのは、このマシンの本質が「速さ」ではなく「128GB 統合メモリに載ること」にあるということです。
RTX 5090 x 1 では物理的に不可能だった 120B モデルの推論や 70GB 超のファインチューニングが、$4,699 のデスクトップで完結します。一方で、トークン生成速度はメモリ帯域幅に律速されるため、クラウド GPU にはかないません。「載るか載らないかの壁」を突破したい場面で、DGX Spark は代替不可能な選択肢になりました。
この記事で紹介したデータの多くは、個別の検証記事で詳しく扱っています。興味のある分野があれば、以下のリンクからたどってみてください。
