NVIDIA DGX Sparkがやってきた

はじめに

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

先日犬型ロボットがやってきたクラスメソッドオフィスですが、実はNVIDIA DGX Sparkもやってきていました:)

https://dev.classmethod.jp/articles/unitree-go2/

128GBという大容量メモリを搭載したこのマシン、一体どこまでの大規模モデルを動かせるのでしょうか？ この記事では、DGX Sparkのセットアップから235Bパラメータモデルへの挑戦まで、実際に試してみた結果をお伝えします。

DGX Sparkってなに？

https://www.nvidia.com/ja-jp/products/workstations/dgx-spark/

3行でまとめると

1. NVIDIAが発売した$3,999のデスクトップAIワークステーション
2. 128GB統合メモリで大規模モデルも1台で動く
3. ARM Ubuntu環境で開発者フレンドリー

スペック比較表

よく比較される構成と並べてみました。

※GB10のFP16性能は公式未発表。コミュニティによる推定値（FP32累積で約62 TFLOPS、FP16累積では約123 TFLOPS）。公称値は1 PFLOPS（FP4 sparse）のみ。それでもFP16推定値でM3 Ultraの約2.4倍。

開封から起動まで

開封の儀

箱を開けると、想像以上にコンパクトな筐体が現れました。Mac miniを少し大きくしたようなサイズ感ですね。

物理スペックと消費電力

消費電力の参考値（Reddit、NVIDIA Forumsより）

GPU利用率は推論中95%前後まで上がりますが、推論が終わると即座にアイドル状態（約5W）に戻るので、待機中の電力は心配しなくてよさそうです。

初回起動とオンボーディング

DGX SparkはUbuntu 24.04 ARMがプリインストールされています。電源ON → Wi-Fiホットスポット経由でブラウザからセットアップ → ソフトウェアアップデート（15-20分、中断厳禁）という流れです。セットアップが完了すると、SSH接続やモニター直結で操作できるようになります。

ARM環境ですが、主要な開発ツールはほぼ問題なく動きました。

推論環境を整える

Open WebUIでオンボーディング

NVIDIAの公式オンボーディングでは、Open WebUI + Ollamaを使ってブラウザからチャットする方法が案内されています。セットアップ方法は2つあります。

NVIDIA Syncを使う方法（かんたん）

NVIDIA Syncアプリがインストール済みであれば、GUIからワンクリックでリモート端末からOpen WebUIを起動できます。手順は 公式ガイド のNVIDIA Syncタブに沿って進めるだけなので、ここでは割愛します。

手動でDockerコンテナを起動する方法

NVIDIA Syncを使わない場合は、以下の手順でセットアップします。

# Docker権限の設定（初回のみ）
docker ps  # permission deniedが出たら以下を実行
sudo usermod -aG docker $USER
newgrp docker

# Open WebUI + Ollamaコンテナを起動
docker run -d -p 8080:8080 --gpus=all \
  -v open-webui:/app/backend/data \
  -v open-webui-ollama:/root/.ollama \
  --name open-webui \
  ghcr.io/open-webui/open-webui:ollama

起動後、ブラウザで http://localhost:8080 にアクセスすると、管理者アカウントの作成画面が表示されます。アカウントを作成したら、チャット画面に進みましょう。

次に、gpt-oss:20bモデルをダウンロードします。gpt-ossはOpenAI初のオープンウェイトモデル（21B/稼働3.6B、MoE、Apache 2.0）。軽量かつ高性能でオンボーディングに向いています。Open WebUIのモデル選択メニューからgpt-oss:20bを検索してpullするか、ターミナルから以下のコマンドを実行します。

# gpt-oss:20bモデルのダウンロード
docker exec open-webui ollama pull gpt-oss:20b

Open WebUIのモデル選択画面でgpt-oss:20bを選ぶと、ブラウザからチャットできるようになります。ここまで来ればオンボーディングは完了ですね。

docker stop open-webui && docker rm open-webui
docker rmi ghcr.io/open-webui/open-webui:ollama
docker volume rm open-webui open-webui-ollama

実際に動かしてみた

Open WebUIで基本動作を確認できたところで、ここからはOllama CLIで直接操作しながら、DGX Sparkに向いたモデルを試していきます。

Open WebUIのDockerコンテナ内にOllamaがバンドルされているので、docker exec 経由でCLI操作が可能です。ホスト側にOllamaを別途インストールして使うこともできます。

# コンテナ内のOllamaを使う場合
docker exec -it open-webui ollama run gpt-oss:20b

# ホスト側にOllamaをインストールして使う場合
curl -fsSL https://ollama.com/install.sh | sh
ollama run gpt-oss:20b

モデル選びの詳細については、2026年のローカルLLM事情を整理してみたも参考にしてみてください。2025年4月のQwen3リリース以降、同じVRAMでより高性能なモデルが使えるようになり、選択肢がかなり増えています。

ここでは、この中から2つをピックアップして実際に動かしてみました。

Qwen2.5-Coder 32Bでコーディング補完

コーディング補完に特化したモデルも試してみました。32Bパラメータですが、128GBメモリなら余裕をもって動作します。

ollama run qwen2.5-coder:32b

同じフィボナッチの問題を投げてみると、再帰版とループ版の2パターンを提示してくれました。

>>> TypeScriptでフィボナッチ数列を計算する関数を書いて

// ループを使った方法
function fibonacciIterative(n: number): number {
    if (n <= 0) return 0;
    if (n === 1) return 1;

    let a = 0, b = 1, temp: number;

    for (let i = 2; i <= n; i++) {
        temp = a + b;
        a = b;
        b = temp;
    }

    return b;
}

Thinkingなしで即座にコードを返してくるので、コード補完用途には向いていますね。Continue.devなどのエディタ拡張と組み合わせると、ローカル完結のコード補完環境として使えそうです。機密コードを扱うプロジェクトでは、この構成が現実的な選択肢になるかなと思っています。

なお、2025年4月にリリースされたQwen3-14Bは、Qwen2.5-32B相当の性能をより少ないVRAMで実現しています。汎用チャット用途ならQwen3-14Bへの乗り換えも検討の価値がありますね。また、2025年7月にはQwen3-Coderもリリースされていますが、480Bパラメータ（稼働35B）と大規模なため、ローカル実行には290GB以上のVRAMが必要です。Coder特化の小型バリアントのリリースに期待したいところです。

GLM-4.7-Flashで高速推論

2026年1月にリリースされ海外のAIコミュニティで注目を集めているGLM-4.7-Flash。30Bパラメータ（稼働3B）のMoE構成で、SWE-benchで59.2%というスコアを記録しています（Qwen2.5-Coderの約2.7倍）。オープンソース（MITライセンス）という点も魅力的ですね。

ollama run glm-4.7-flash

同じフィボナッチの問題を投げたところ、Thinking部分で実装プランを整理してから、3パターンの実装（配列版・変数版・再帰版）と使い分けガイドまで返してくれました。Thinkingモデルなのでレスポンス開始までは少し待ちますが、出力内容は丁寧です。

>>> TypeScriptでフィボナッチ数列を計算する関数を書いて

<think>
（実装方針の検討：配列版・変数版・再帰版の3パターンを整理...）
</think>

// 2. N番目の数値を計算する（効率的）
function getNthFibonacci(n: number): number {
  if (n <= 1) return n;

  let prev = 0;
  let curr = 1;

  for (let i = 2; i <= n; i++) {
    const temp = prev + curr;
    prev = curr;
    curr = temp;
  }

  return curr;
}

MoEにより実質3Bしか稼働しないため、小回りが利きます。複数モデルを同時起動して用途別に使い分けるといった運用にも向いていますね。

prefill vs decode - 体感速度の違い

LLMの推論には2つのフェーズがあります。

詳しくは後述の「発展的な話題」で。

ベンチマーク結果

llama.cppでの参考値（Q4_K_M量子化、Reddit - LocalLLaMAより）

※8Bの数値はコミュニティによる実測値です。環境や設定により異なる場合があります。

Ollama経由での自分の実測値も載せておきます。同じプロンプト（TypeScriptのフィボナッチ関数生成）で計測しました。

gpt-oss:20bはMoEで稼働パラメータが3.6Bと小さいため、decode速度が61 tok/sと快適です。一方、120bはprefillが282 tok/sと桁違いに速く、DGX Sparkの計算性能が活きるパターンですね。decodeは39 tok/sで、読む速度と同じくらいの体感でした。

体感としては、8B〜14Bモデルなら実用的な速度でコード補完やチャットに使えます。70Bモデルは動くものの遅いため、バッチ処理向けですね。

128GBメモリの限界に挑戦してみた

「見せてもらおうか、NVIDIAのデスクトップAIの性能とやらを！」

ここからが本題です。DGX Sparkの128GBメモリ、どこまで攻められるのでしょうか？「ギリギリ動く」大規模モデルを試してみました。

128GBのうちGPUとOS予約でモデルに使えるのは実質約115GB程です。

Qwen3-235B-A22B（動作確認済み）

まずはQwen3-235B-A22B。235Bパラメータですが、MoE（Mixture of Experts）アーキテクチャにより、実際にアクティブになるのは22Bパラメータのみです。なお、現在一般公開されているのはQwen3-235B-A22B-Instruct-2507（2025年7月リリース、8月更新で100万トークンコンテキスト対応）です。

ここで注意が必要です。Ollama公式の qwen3:235b-a22b はQ4_K_M量子化で約142GBあります。実質115GBなので、Q4_K_Mは確実にメモリ不足になります。実際に試してみたところ、ollama run qwen3:235b-a22b を実行した瞬間にシステム全体がフリーズしてしまいました。。。

Q3_K_L版（約112GB）なら理論上は収まりますが、残り約3GBではKVキャッシュ（推論時のコンテキスト保持領域）がほとんど確保できません。短いプロンプトならギリギリ動く可能性はありますが、実用的とは言い難いですね。

# ❌ Q4_K_M（142GB）は128GBメモリでは動かない
ollama pull qwen3:235b-a22b  # → フリーズの原因に

# ⚠️ Q3_K_L（112GB）はギリギリ。HuggingFaceからGGUFを取得してインポート
# https://huggingface.co/bartowski/Qwen3-235B-A22B-GGUF
ollama create qwen3-235b-q3kl -f Modelfile

128GBでの「限界挑戦」としては、gpt-oss:120b（メモリ使用量約65GB）あたりが余裕をもって動かせる実質的な上限ラインかなと思っています。235Bクラスを快適に使うには、クラスタケーブルで2台接続して256GB構成にするか、Q2_K以下の量子化で品質を保てる手法が出てくるのを待つ必要がありそうです。

JGLUEベンチマークで日本語性能を測る

JGLUEのJCommonsenseQA（日本語5択常識推論）で評価してみました。

問題例:

問: 主に子供が食べるものは？
選択肢: (1) 背脂 (2) ## お子様カレー ## (3) 激カラカレー (4) コーヒー (5) レモン

参考スコア

※ JCommonsenseQA v1.3 validationセット全1,119問で3-shot評価（temperature=0）。人間スコアはJGLUE論文（LREC 2022）よりDev 98.8%、Test 99.0%。

Gemma 3 27Bが93.9%でトップという結果は少し意外でした。Googleのマルチリンガルモデルは140言語対応を謳っていますが、日本語の常識推論でもしっかり強いですね。gpt-oss:20bは稼働パラメータがわずか3.6Bながら92.7%と健闘しており、効率の良さが光ります。

面白いのはGemma 3 12Bの91.8%です。12Bクラスでこのスコアは優秀ですね。一方、GLM-4.7-FlashはSWE-benchで59.2%と高いスコアを出しているものの、日本語の常識推論では81.9%とやや控えめです。コーディング特化モデルの得意・不得意がはっきり出た結果かなと思っています。

評価にはlm-evaluation-harness（Stability AI版）を使用しました。

開発ワークフローへの統合

DGX SparkとOllamaの組み合わせは、VS CodeのContinue.dev拡張機能との相性が良いですね。ローカルで動くLLMをコード補完に活用できるため、機密コードを扱うプロジェクトでも安心して使えます。

詳しい設定方法と、実際の開発での使用感については、これから調査して記事にしてみようと思います。

発展的な話題

帯域幅ボトルネックの話

DGX Sparkの最大の制約はメモリ帯域幅 273 GB/sです。これはMac Studio M3 Ultra（819 GB/s）の約1/3、RTX 4090（1,008 GB/s）の約1/4に相当します。LLMのdecodeフェーズではモデルの重みを繰り返し読み込むため、帯域幅が狭いと応答速度が遅くなります。

統合メモリとMoEモデルの相性

最近のローカルLLMではllama.cppの--n-cpu-moeオプションによるCPU MoE Offloadingが注目されています。MoEのExpert重みをGPU VRAMからシステムRAMに退避することで、限られたVRAMでも大規模MoEモデルを動かせる手法です。

ただし、DGX SparkやApple Siliconのような統合メモリアーキテクチャでは事情が異なります。CPUとGPUが同じメモリプールを共有しているため、「VRAMからRAMに退避する」という概念自体が成り立たず、CPU MoE Offloadingによるメモリ節約効果はありません。これはMac Studio M3 Ultraでも同様です。

逆に言えば、統合メモリはMoEモデルと相性が良い面もあります。dGPU構成ではExpertの読み込みにPCIe転送（実効16 GB/s程度）がボトルネックになりますが、統合メモリならメモリ帯域幅（DGX Spark: 273 GB/s、M3 Ultra: 819 GB/s）でそのままアクセスできるため、オフロードのペナルティなしに動作します。235B-A22Bが（メモリに収まりさえすれば）動くのも、このアーキテクチャの恩恵ですね。

CUDAバージョンと互換性

DGX SparkのCUDA環境を確認してみましょう。

$ nvcc --version
nvcc: NVIDIA (R) Cuda compiler driver
Cuda compilation tools, release 13.0, V13.0.88
Build cuda_13.0.r13.0/compiler.36424714_0

CUDA 13.0、ドライバ580.126.09という構成です。統合メモリアーキテクチャのため、nvidia-smiのMemory-Usageは「Not Supported」になります。

$ nvidia-smi
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 580.126.09             Driver Version: 580.126.09     CUDA Version: 13.0     |
+-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|=========================================+========================+======================|
|   0  NVIDIA GB10                    On  |   0000000F:01:00.0 Off |                  N/A |
| N/A   69C    P0             42W /  N/A  | Not Supported          |     93%      Default |
+-----------------------------------------+------------------------+----------------------+

llama.cppやOllamaはCUDA 13に対応しており、実用上の問題は発生しませんでした。一方、CUDA 11/12時代のライブラリはビルドに失敗するケースがあります。ARM（aarch64）環境であることも含めて、使いたいツールの対応状況は事前に確認しておくとよいですね。

参考までに、システム構成の詳細も載せておきます。

まとめ

DGX Sparkは「機密コードを手元で扱いたい」「大規模MoEモデルを1台で試したい」という開発者にとって、現時点で数少ない現実的な選択肢です。128GBの統合メモリでgpt-oss:120bクラスまで余裕をもって動かせますし、静音・低消費電力でオフィスにも置けます。機密コードのリファクタリング支援やRAGシステムの構築など、クラウドに出せないワークロードでこそ真価を発揮するマシンだなと感じました。

一方で、メモリ帯域幅273 GB/sという制約から、大規模モデルのインタラクティブな応答速度ではMac Studio M3 Ultra（819 GB/s）に譲ります。最速の推論速度を求めるならRTX 4090やMac Studio、macOSが必須ならMac Studio、予算を抑えたいならまずクラウドAPIから試す方が良いでしょう。用途と予算が合うなら、ローカルLLM環境としてかなり満足度の高い1台です。

参考リンク

公式ドキュメント

• NVIDIA DGX Spark 公式ページ
• NVIDIA DGX Spark ドキュメント
• NVIDIA DGX Spark First Boot Guide
• Connect to your Spark（オンボーディング）
• Open WebUI on Spark（推論環境セットアップ）
• NVIDIA DGX Spark Porting Guide
• Canonical - NVIDIA DGX Spark Ubuntu Base

ツール・ソフトウェア

• Ollama
• Open WebUI
• llama.cpp
• Continue.dev

モデル関連

• Qwen3 公式ブログ
• Qwen3-Coder GitHub
• gpt-oss Hugging Face
• Devstral Small 2 公式ブログ
• GLM-4.7-Flash Hugging Face
• 2026年のローカルLLM事情を整理してみた

ベンチマーク・比較記事

• Reddit - Performance of llama.cpp on NVIDIA DGX Spark
• Reddit - DGX Spark AMA
• ServeTheHome - DGX Spark Review
• Engadget - NVIDIA starts selling its $3,999 DGX Spark
• LMSYS - NVIDIA DGX Spark In-Depth Review

クラスタリング関連

• DGX Spark Multi-Node LLM Inference Report
• Detailed Compute Performance Metrics for DGX Spark