03-setup / wave 1 / status: published / 更新日: 2026-06-14

DGX Spark が ARM で動かない？DGX OS で詰まる点と回避策

要約

GB10 搭載の DGX Spark / MSI EdgeXpert を ARM64(DGX OS)で使い始めると、「nvidia-smi にメモリが出ない」「pip で導入したのに CUDA エラーで起動しない」など、故障と誤解しやすい正常挙動と、x86 前提の手順が通らない問題に立て続けに当たる。本記事は、これら「DGX Spark ARM 動かない」と感じる典型事象を、NVIDIA 公式の既知問題・公式 Playbook という一次情報と、筆者の MSI EdgeXpert 実機確認とに分けて整理し、原因と回避策を示す。対象読者は、GB10 機を入手してセットアップ・初期運用で詰まっているエンジニアである。

結論を先に言えば、ここで挙げる事象の大半は UMA(統合メモリ)と aarch64 + sm_121 という比較的新しい構成ゆえの仕様・エコシステムの未追従であって、ハードウェアの故障ではない。その多くは公式が回避策を明記している。

検証環境

筆者の実機(MSI EdgeXpert)と、公式リリースノートに記載されたソフトウェア構成は次のとおり。

項目	値	備考
機材	MSI EdgeXpert(GB10, 128GB UMA)	GB10 / 20-core Arm
アーキテクチャ	aarch64(ARM64)	実機 `uname -m` で確認
OS	DGX OS 7.5.0 系	Kernel 6.17(Canonical)
GPU Driver	580.159.03	実機 nvidia-smi で確認
CUDA	13.0(Toolkit 13.0.2)	実機 nvidia-smi 表示は CUDA Version 13.0
Compute Capability	12.1(sm_121)	実機 `nvidia-smi --query-gpu=compute_cap` で確認

注意: 上記のバージョン群(DGX OS 7.5.0 / CUDA 13.0.2 / Driver 580.159.03)は、NVIDIA 公式リリースノートでは DGX Spark Founders Edition のみに適用されると明記されている。GB10 ベースのパートナー製品(MSI EdgeXpert 等)は同じ更新を同時には受け取らない場合があるとされており、手元の版が上表と異なりうる。バージョン依存の判断をする際は、必ず実機で確認してほしい(出典: 公式リリースノート)。

DGX Spark が ARM で「動かない」と感じる詰まりどころと回避策

以下は、いずれも NVIDIA 公式の既知問題ドキュメント、または公式 Playbook に根拠がある事象である。出典の性格(公式既知問題か、Playbook か、フォーラム / Issue か)を都度示す。

nvidia-smi の Memory-Usage が「Not Supported」になるのは正常

nvidia-smi を叩くと、GPU 全体の Memory-Usage 欄が Not Supported と表示される。これは故障ではない。NVIDIA 公式の既知問題に「nvidia-smi will display ‘Memory-Usage: Not Supported’ even though per-process GPU memory is listed」と明記されており、iGPU(統合 GPU)が専用フレームバッファメモリを持たないための想定動作である。プロセス別の GPU メモリは別途表示される。

実機出力は後述の「実機確認」に載せた。要点は、「GPU 全体の Memory-Usage 欄は Not Supported だが、Processes 欄にはプロセスごとの使用量が出る」という公式記載どおりの挙動が、筆者の EdgeXpert でも再現したことである。

UMA で cudaMemGetInfo がメモリを過少報告する → drop_caches

UMA(統合メモリ)構成のため、cudaMemGetInfo が割当可能メモリを実際より小さく報告することがある。公式既知問題によれば、この API は「SWAP から回収しうるメモリを勘定しない」ため、報告値が実際に割り当て可能な量を下回りうる。

公式が示す回避策は、バッファキャッシュをフラッシュするコマンドである(原文ママ)。

sudo sh -c 'sync; echo 3 > /proc/sys/vm/drop_caches'

筆者の実機でもこの効果を確認できた。PyTorch の torch.cuda.mem_get_info()(内部で cudaMemGetInfo を呼ぶ)で計測すると、drop_caches 実行前の空きは 87.62 GiB だったが、実行後は 117.71 GiB まで回復した(total は前後とも 121.63 GiB)。約 30 GiB がバッファキャッシュとして抱えられ「空き」に計上されていなかったことになる。大型モデルのロード前に効くという公式の案内どおりの挙動である(数値は後述の「実機確認」)。

なお公式リリースノート(2025 年 11 月)には UMA でのメモリ報告差異を改善した旨の記載もあるが、過少報告自体は既知挙動として引き続き念頭に置くのが安全である。

mDNS(spark-xxxx.local)が企業ネットワークでブロックされる → IP直指定

デバイスは mDNS で spark-abcd.local 形式のホスト名を広告する。公式 Playbook(connect-to-your-spark)は、「複雑な企業環境などでは mDNS が期待どおり動作せず、デバイスの IP アドレスを直接使う必要がある」と明記している。

典型的な失敗症状は次のとおりである。

ssh: Could not resolve hostname spark-abcd.local: Name or service not known

この場合は .local 名ではなく IP を直接指定する。IP はルータの管理画面、またはディスプレイをつないで Ubuntu のネットワーク設定から確認できる。SSH やポートフォワード(DGX Dashboard は 11000 番)も、ホスト名の代わりに IP を渡せばよい。

ブート直後・初回セットアップ直後はネットワークや SSH がまだ来ない → 数分待つ

電源投入直後や初回セットアップ完了直後に SSH やネットワーク接続ができなくても、故障とは限らない。サービスが立ち上がるまでには時間がかかる。

ただし「何分待てばよいか」は文脈によって異なるため、本記事では単一の数値には断定しない。

NVIDIA Sync の初回接続が失敗した場合、公式 Playbook は 3〜4 分待って再試行するよう案内している。SSH はアップデート完了後に利用可能になる。
一方、first-boot ドキュメントは、全アップデートのインストールとホームネットワーク参加に 最大 10 分かかることがあるとし、リブート表示後も最大 10 分はセットアップが継続しうるとしている。

つまり初回は「3〜4 分」より長く、最大 10 分を見込むのが安全である。詳しい初回セットアップ手順は初期セットアップ完全ガイドを参照してほしい。

電源アダプタ要件・HDMI ディープスリープからの復帰

これらも公式既知問題に挙げられている。

電源アダプタ: 公式は「最適な性能のため付属の電源アダプタを使うこと。別のアダプタでは性能低下・起動不可・予期せぬシャットダウンを引き起こしうる」としている。付属品以外での運用は避けたい。
HDMI ディープスリープ: 長時間の無操作後、接続した HDMI ディスプレイがディープスリープに入り、キー入力やマウス操作で復帰しないことがある。この場合はモニタ本体の物理ボタンを押して復帰させる。

給電要件が重い背景には、製品仕様上の PSU 240W / GB10 TDP 140W という値がある。

x86 前提の手順が通らない(ARM64 = aarch64)

本記事の主題の一つがこれである。GB10 機は ARM64(aarch64)であり、x86 前提の手順やバイナリは原則そのままでは動かない。

VS Code: 公式 Playbook は ARM64 版 .deb の導入を明示的に要求し、検証手順として uname -m の出力が aarch64 であることを確認させる。x86 版は想定されていない。
Ollama: 公式 Playbook は公式インストールスクリプト(curl -fsSL https://ollama.com/install.sh | sh)の利用を示しており、Blackwell architecture 向けと記載されている(スクリプト側でアーキテクチャを解決する前提と思われる)。
一般化すると、Docker イメージや pip wheel も aarch64 対応版が必要であり、x86 バイナリは原則動かない。導入時はアーキテクチャ対応の有無を必ず確認すること。

VS Code Remote-SSH を含む実際の導入手順は初期セットアップ完全ガイドで扱っている。

sm_121(Compute Capability 12.1)固有のハマり

GB10 の CUDA Compute Capability は **12.1(sm_121)**であると、NVIDIA スタッフが開発者フォーラムで「The DGX Spark will have compute capability 12.1」と明言している(2025-09-25。フォーラム由来の一次情報)。さらに筆者の実機でも、nvidia-smi --query-gpu=compute_cap の出力が 12.1 となることを確認した(後述の「実機確認」)。フォーラムの一次情報と実機実測の両方で sm_121 が裏付けられている。

問題は、既存のプリビルドバイナリの中に sm_120 までのカーネルしか同梱せず、sm_121 を含まないものがある点だ。vLLM の Issue #36821 では、「同梱の PyTorch バイナリが sm_120 までのカーネルしか含まないため、sm_121 を要求する Blackwell GPU で起動時にクラッシュする」と報告されている。これは実行時の設定変更では解決せず、sm_121 + aarch64 対応の wheel か、再ビルドした Docker イメージが必要になる(Issue 由来のため、確度は公式既知問題より弱い)。

実用上の示唆はこうだ。「PyTorch やライブラリを pip で導入できたのに、起動で CUDA エラーになる」というハマりは、aarch64 であることに加えて sm_121 非対応が原因のことがある。

ただし留保もある。筆者の実機では sm_121(12.1)そのものは確認できたが、sm_121 起因と思われる CUDA エラーには遭遇していない。ollama は正常に動作しており、上記のクラッシュは vLLM Issue #36821 で報告された事象である(Issue 由来のため、確度は公式既知問題より弱い)。また個別ライブラリ(conda / mamba、flash-attention 等)の aarch64 / sm_121 対応状況は公式一次情報での裏取りが未完のため、本記事では個別の断定を避ける(未検証)。

実機確認

筆者の MSI EdgeXpert(2026-06-14 時点)で確認できた事実を、公式記載と区別してまとめる。

A. nvidia-smi の Memory-Usage が実機でも「Not Supported」 GPU 全体の Memory-Usage 欄は Not Supported だが、Processes 欄には ollama の llama-server が 81649MiB(約 80GB)と表示された。「プロセス別 GPU メモリは出るが、GPU 全体の Memory-Usage 欄は Not Supported」という公式記載どおりの挙動を実機で確認した。GPU-Util 95% / 71C / P0 / 45W、NVIDIA-SMI 580.159.03 / Driver 580.159.03 / CUDA Version 13.0。実機出力(抜粋):

| N/A   71C    P0             45W /  N/A  | Not Supported          |     95%      Default |
...
|    0   N/A  N/A          396913      C   ...local/lib/ollama/llama-server      81649MiB |

B. uname -m → aarch64 実機で aarch64 を確認した。ARM64 であることの一次証拠であり、前述の「x86 前提が通らない」問題の根拠でもある。

C. Compute Capability は実機でも 12.1(sm_121) 当初 deviceQuery(CUDA Samples)は未導入で実行できず、通常の nvidia-smi 出力にも Compute Capability 欄が無かったが、nvidia-smi --query-gpu=compute_cap を使うと実機で 12.1 が出力された。フォーラムの一次情報(NVIDIA スタッフ明言)が実機実測でも裏付けられた形である。

$ nvidia-smi --query-gpu=compute_cap --format=csv
compute_cap
12.1

なお実機では sm_121 起因の CUDA エラーには遭遇しておらず、ollama は正常に動作している。

D. cudaMemGetInfo の過少報告と drop_caches の効果 PyTorch の torch.cuda.mem_get_info() で空きメモリを計測したところ、drop_caches 実行前後で次のように変化した。total は不変で、free のみ約 30 GiB 回復している。過少報告(キャッシュ分が空きに計上されない)と公式回避策の効果を、実機で確認できた。

drop_caches 実行前: free = 87.62 GiB / total = 121.63 GiB
drop_caches 実行後: free = 117.71 GiB / total = 121.63 GiB

考察

これらの事象がなぜ起きるのかを、原理から整理する。

第一に、nvidia-smi の Not Supported と cudaMemGetInfo の過少報告は、UMA(統合メモリ・専用フレームバッファなし)という設計に由来する。GB10 は GPU 専用の VRAM を持たず、128GB の LPDDR5x を CPU と GPU が共有する UMA 構成(公称帯域 273GB/s)である。専用フレームバッファが存在しないため、従来の「GPU の VRAM 使用量」という表示が成立せず、Not Supported になる。また、システムメモリと共有しキャッシュ・SWAP が絡むため、cudaMemGetInfo の瞬間値が実際の割当可能量を下回りうる。いずれも独立 VRAM を前提にした x86 ディスクリート GPU の常識をそのまま当てはめると「故障・容量不足」と誤解しやすいが、UMA では想定内の挙動である。

第二に、pip で入れたのに起動で落ちる類のハマりは、aarch64 + sm_121 という比較的新しい組み合わせにエコシステムが追従しきれていないことが原因と考えられる。多くのプリビルドバイナリは x86_64 向けを主に整備されており、aarch64 ホイールが無い、あるいは古いことがある。さらに GPU 側も sm_121 という新しい Compute Capability であり、sm_120 までしか含まないバイナリでは実行時に対象アーキテクチャが見つからずクラッシュしうる(vLLM Issue #36821)。だからこそ NVIDIA は最新機能を NGC コンテナ経由で配布し、検証済みの組み合わせを提供している。逆に言えば、ollama のように aarch64 + Blackwell 向けに整備された経路を使えば素直に動く(筆者実機で確認済み)。

要するに、本記事の事象は「壊れている」のではなく、UMA と新アーキテクチャという前提の違いから生じている。前提を理解すれば、回避策の多くは公式が用意している。

まとめ

nvidia-smi の Memory-Usage「Not Supported」は正常。iGPU で専用フレームバッファが無いため(公式既知問題)。プロセス別メモリは表示される(実機確認済み)。
cudaMemGetInfo の過少報告は UMA 由来。回避策は sudo sh -c 'sync; echo 3 > /proc/sys/vm/drop_caches'(公式)。
mDNS が企業網でブロックされたら IP 直指定。失敗症状は Could not resolve hostname(公式 Playbook)。
ブート直後につながらないのは仕様。NVIDIA Sync 初回は 3〜4 分、初回セットアップ全体は最大 10 分を見込む(公式)。
電源は付属アダプタ必須、HDMI 復帰はモニタの物理ボタン(公式既知問題)。
x86 前提は通らない。aarch64 対応版を使う。uname -m は aarch64(実機確認済み)。
GB10 は sm_121(Compute Capability 12.1)。フォーラムの一次情報に加え、実機 nvidia-smi --query-gpu=compute_cap でも 12.1 を確認済み。sm_120 までしか含まないプリビルドバイナリは起動時に CUDA エラーになりうる(クラッシュ報告は vLLM Issue #36821 由来。確度は弱め)。筆者実機では未遭遇で、ollama は正常動作している。
最新機能は NGC コンテナ経由で導入するのが安全(公式)。

次に読む記事:

MSI EdgeXpert セットアップ完全ガイド — 初回起動から NVIDIA Sync・DGX Dashboard・VS Code Remote-SSH まで、ARM64 前提の正しい導入手順を実機で解説。
ollamaで120B級モデルを動かす — aarch64 + Blackwell 向けに整備された経路で大規模モデルを実際に動かした記録。本記事の「素直に動く例」の詳細。

取材メモ

検証環境の前提(公式リリースノート)

DGX OS 7.5.0 / CUDA Toolkit 13.0.2 / GPU Driver 580.159.03 / Kernel 6.17(Canonical)。ただしこのバージョン群は「DGX Spark Founders Edition のみ」適用で、GB10ベースのパートナー製品(MSI EdgeXpert 等)は同時に更新を受け取らない場合があると明記。→ EdgeXpert では版が異なりうる点を本文で注意喚起すること。出典: https://docs.nvidia.com/dgx/dgx-spark/release-notes.html
同リリースノートに「unified memory architecture でのメモリ報告の差異(memory reporting differences)」を改善した旨の記載あり(2025年11月リリース)。UMAのメモリ過少報告は既知挙動として継続。出典同上。

1. nvidia-smi の Memory-Usage が「Not Supported」(正常)

公式既知問題に明記: 「nvidia-smi will display ‘Memory-Usage: Not Supported’ even though per-process GPU memory is listed. This is expected because iGPUs do not have dedicated framebuffer memory.」→ iGPU(統合GPU)で専用フレームバッファを持たないための正常動作。故障ではない。出典: https://docs.nvidia.com/dgx/dgx-spark/known-issues.html

2. UMA で cudaMemGetInfo が割当可能メモリを過少報告 → drop_caches

公式既知問題: UMAのため cudaMemGetInfo が利用可能メモリを過少報告する。APIは「SWAPから回収しうるメモリを勘定しない」ため、報告値が実際に割当可能なメモリより小さくなりうる。
公式回避策コマンド(原文ママ): sudo sh -c 'sync; echo 3 > /proc/sys/vm/drop_caches'(バッファキャッシュをフラッシュ)。出典: https://docs.nvidia.com/dgx/dgx-spark/known-issues.html

3. mDNS(spark-xxxx.local)が企業ネットワークでブロック → IP直指定

公式Playbook(connect-to-your-spark): デバイスは mDNS で spark-abcd.local 形式のホスト名を広告する。「複雑な企業環境などでは mDNS が期待通り動作せず、デバイスのIPアドレスを直接使う必要がある」と明記。
典型的な失敗症状: ssh: Could not resolve hostname spark-abcd.local: Name or service not known。
IPの調べ方: ルータ管理画面、またはディスプレイを繋いでUbuntuのネットワーク設定で確認。
SSH例: ssh <USER>@<SPARK_HOSTNAME>.local / ポートフォワード例: ssh -L 11000:localhost:11000 <USER>@<SPARK_HOSTNAME>.local(11000はDGX Dashboard)。出典: https://github.com/NVIDIA/dgx-spark-playbooks/blob/main/nvidia/connect-to-your-spark/README.md

4. ブート直後/初回セットアップ直後はネットワーク・SSHがまだ来ない → 数分待つ

connect-to-your-spark Playbook: 「初回セットアップ完了後、デバイスはアップデートしネットワークに現れるまで数分かかる。NVIDIA Sync が接続失敗したら3〜4分待って再試行」。SSHは「アップデート完了後に利用可能」。
first-boot docs: 「全アップデートのインストールとホームネットワーク参加に最大10分かかることがある」「リブート表示後も最大10分セットアップ継続」。→ 初回は「3〜4分」より長く、最大10分と考えるのが安全。出典: https://github.com/NVIDIA/dgx-spark-playbooks/blob/main/nvidia/connect-to-your-spark/README.md , https://docs.nvidia.com/dgx/dgx-spark/first-boot.html

5. 電源アダプタ / HDMIモニタのディープスリープ(公式既知問題)

電源: 「最適な性能のため付属の電源アダプタを使用すること。別のアダプタを使うと性能低下・起動不可・予期せぬシャットダウンを引き起こしうる」(原文ママ要約)。
HDMI: 「長時間の無操作後、接続したHDMIディスプレイがディープスリープに入り、キー入力やマウス操作で復帰しないことがある」→ モニタ本体の物理ボタンを押して復帰させる。
製品仕様: PSU 240W / GB10 TDP 140W(EdgeXpertでも給電要件は重い点の裏付け)。出典: https://docs.nvidia.com/dgx/dgx-spark/known-issues.html , https://www.nvidia.com/en-us/products/workstations/dgx-spark/

6. x86前提の手順が通らない(ARM64=aarch64)

VS Code: 公式Playbookは ARM64版 .deb を明示要求。検証手順は uname -m → 期待出力 aarch64。x86版の利用は想定外(walkthrough全体がARM64前提)。出典: https://github.com/NVIDIA/dgx-spark-playbooks/blob/main/nvidia/vscode/README.md
Ollama: 公式インストールスクリプト curl -fsSL https://ollama.com/install.sh | sh がアーキ判定を処理する想定。「Blackwell architecture」向けと記載。出典: https://github.com/NVIDIA/dgx-spark-playbooks/blob/main/nvidia/ollama/README.md
→ Dockerイメージ・pip wheel は aarch64 対応版が必要。x86バイナリは原則動かない点を本文で一般化して注意。

7. 最新機能は NGC コンテナ経由で提供

既知問題docs: CUDAは「ソフトウェア更新リリース時点でハードウェアと動作検証済み」で、最新機能はNGCコンテナ経由で提供される旨。
vLLM Playbook: vLLMはNGCコンテナイメージ経由が主(docker pull nvcr.io/nvidia/vllm:<version>)。ソースビルドはCMake/Ninjaの知識を要する代替手段と位置付け。出典: https://docs.nvidia.com/dgx/dgx-spark/known-issues.html , https://github.com/NVIDIA/dgx-spark-playbooks/blob/main/nvidia/vllm/README.md
- ※ vLLM Playbook READMEの個別モデル向けタグ(特定バージョン名)は取得結果の信頼度が低く、本文転載は避ける(要再確認)。一般論(NGCコンテナ配布/ソースビルドはARM64で要追加作業)のみ採用。

8. CUDA Compute Capability sm_121(Blackwell)固有のハマり

GB10のCUDA Compute Capability は 12.1(sm_121)。NVIDIAスタッフが開発者フォーラムで「The DGX Spark will have compute capability 12.1」と明言(2025-09-25)。出典: https://forums.developer.nvidia.com/t/dgx-spark-gb10-cuda-compute-capability/342864
既存のプリビルドバイナリは sm_120 までしか同梱せず sm_121 を含まないものがあり、起動失敗の原因になる。vLLM Issue #36821: 「同梱のPyTorchバイナリが sm_120 までのカーネルしか含まないため、sm_121 を要求するBlackwell GPUで起動時にクラッシュ」。runtimeの回避策では解決せず、sm_121 + aarch64 対応のwheelか再ビルドしたDockerイメージが必要。出典: https://github.com/vllm-project/vllm/issues/36821
→ 「PyTorchやライブラリのpip導入はできたのに起動でCUDAエラー」というハマりは、aarch64であることに加え sm_121 非対応が原因のことがある点を本文で整理。

DGX Dashboard / 更新手順(補足)

DGX Dashboard: システムのメトリクス表示・アップデート適用・一部設定変更・ローカルJupyter Notebookアクセスを提供。ローカルはUbuntuアプリ一覧、リモートはNVIDIA Sync/SSHトンネル経由、通常 http://localhost:11000。出典: https://docs.nvidia.com/dgx/dgx-spark/dgx-dashboard.html
手動更新コマンド(advanced): sudo apt update → sudo apt dist-upgrade → sudo fwupdmgr refresh → sudo fwupdmgr upgrade → sudo reboot。公式は「DGX Dashboard 経由を強く推奨」。なおこの更新手順記載も「Founders Edition のみ」適用で、他社製は手順が異なりうると明記。出典: https://docs.nvidia.com/dgx/dgx-spark/os-and-component-update.html

実機確認(筆者 MSI EdgeXpert / 2026-06-14)

A. nvidia-smi の Memory-Usage が実機でも「Not Supported」。同時に Processes 欄には ollama の llama-server が 81649MiB(約80GB)と表示され、「プロセス別 GPU メモリは出るが GPU 全体の Memory-Usage 欄は Not Supported」という公式記載どおりの挙動を実機で確認。GPU-Util 95% / 71C / P0 / 45W。NVIDIA-SMI 580.159.03 / Driver 580.159.03 / CUDA Version 13.0。実機出力(抜粋):
```
| N/A   71C    P0             45W /  N/A  | Not Supported          |     95%      Default |
...
|    0   N/A  N/A          396913      C   ...local/lib/ollama/llama-server      81649MiB |
```
B. uname -m → aarch64 を実機で確認。ARM64 であることの一次証拠。
C. Compute Capability は実機でも 12.1(sm_121)。当初 deviceQuery(CUDA Samples)は未導入で実行できず、通常の nvidia-smi 出力にも Compute Capability 欄が無かったが、nvidia-smi --query-gpu=compute_cap --format=csv で 12.1 を確認(出力: compute_cap / 12.1)。フォーラムの一次情報(NVIDIAスタッフ明言)が実機実測でも裏付けられた。なお実機で sm_121 起因の CUDA エラーには遭遇していない(ollama は正常動作)。

未確認 / 留意リスト

mDNS の「3〜4分」と first-boot の「最大10分」は文脈が異なる(NVIDIA Sync初回接続 vs 初回セットアップ全体)。本文では両方を文脈付きで提示し、断定的に単一の数値にしない。
vLLM Playbook README の個別モデル向けコンテナタグ・特定モデル名(例として返ってきた文字列)は要約モデルの信頼度が低く未確認。本文転載しない。
first-boot docs は mDNSホスト名 spark-xxxx.local の形式を明記していない(ホスト名形式の根拠は connect-to-your-spark Playbook 側)。
conda/mamba の aarch64 対応、flash-attention 等の個別ライブラリ非対応は、公式一次情報での裏取りが未完。sm_121関連の一般傾向(プリビルド非対応)としてのみ言及し、個別ライブラリ名の断定は避ける(要追加取材)。
GB10公称固定値の再確認済み: 128GB LPDDR5x UMA / 帯域 273GB/s / 最大200Bパラメータ / 最大1 PFLOP FP4(sparsity注記あり)。20-core Arm(Cortex-X925×10 + Cortex-A725×10)。出典: https://www.nvidia.com/en-us/products/workstations/dgx-spark/