Jetson AGX ThorとDGX Sparkは何が違う？128GBでもロボット・LLMで選択が変わる理由

1. 同じ128GBでも、買う目的が違う#

Jetson AGX Thorは、ロボットやエッジ機器にAIを組み込むための開発プラットフォームだ。本記事では128GBのJetson T5000を搭載する開発者キットを比較する。64GBのT4000や、車載向けのDRIVE AGX Thorとは区別する。

DGX Sparkは、机の上でAIモデルの推論、検証、プロトタイプ開発、ファインチューニングを行う小型コンピューターだ。今回は128GB・4TB SSDの販売構成を対象とする。現行の公式ページにはOEM経由の64GB構成もあるため、「Sparkはすべて128GB」とは言えない。

両方ともBlackwell世代だが、同じGPUを周辺機器だけ変えて載せた製品ではない。CUDAコア数やCPUを含む計算資源の構成も異なる。その上で、センサー接続、ソフトウェア、電力設計、製品への組み込み方が選択を分ける。

^[1,2,3]

2. 仕様は、演算条件と構成をそろえて読む#

Thorの公称AI演算性能は2,070 TFLOPS、Sparkは最大1 PFLOP、つまり1,000 TFLOPS。いずれもFP4・スパース条件の理論ピークだ。約2.07倍という比率は、この条件の演算性能の比較であり、LLMの文章生成やVLAの行動出力が2倍になるという意味ではない。

両機のメモリ帯域は273GB/s。128GBはCPUとGPUで共有するシステムメモリであり、128GBの専用GPU VRAMではない。OS、カメラ処理、モデルの重み、KVキャッシュなどが容量を使うため、モデル用に128GBすべてを確保できるとは限らない。

^[1,2,3]

3. 国内価格は、現行ページと対象構成を確認する#

リョーサン菱洋のThor開発者キットは、2026年11月12日に取得した販売ページで通常販売価格998,800円（税込）を確認した。一方、元原稿のELSA ONLINEのDGX Spark・4TB構成1,045,000円（税込）は検索索引には残るが、商品ページ本体は今回404で取得できなかった。したがって、この金額を現在の販売価格と断定したり、両機の差額を確定したりはしない。

Thorの掲載価格も全国最安値や在庫、納期を保証するものではない。アカデミック向け価格は別条件で、通常価格との比較に混ぜない。購入時は最新の見積もりで、税、SSD容量、保証、送料、必要なケーブルやセンサー、キャリアボードなどを含めて比べる。

^[10,11]

4. TFLOPSだけでLLM速度を予測できない理由#

LLMの推論には、入力を読み込むprefillと、続きを順番に生成するdecodeがある。長い入力の処理速度と、回答が一語ずつ出てくる速度は分けて比較する必要がある。どちらもtokens/秒で表せるが、同じ仕事ではない。

FP4の理論ピークを出すには、精度やスパース性、対応するカーネルなどの条件が必要だ。量子化モデルを使うだけで、公称FP4ピークをそのまま使えるわけではない。モデル形式、推論エンジン、バッチ数、文脈長、電力モード、GPUへの配置も実行速度を変える。

大きなDenseモデルを小さいバッチで生成する場合は、重みを繰り返し読み出すメモリ帯域が制約になりやすい。一方、gpt-oss-120bはMoEモデルであり、毎トークンに全パラメータを使うDenseモデルの例として扱ってはいけない。帯域が同じでも、実効帯域や計算構成、実装が違えば速度は一致しない。

元原稿にある「Thor 41.8対Spark 52.9 tokens/秒、入力938対1,689」という2025年の比較は、リンク先の原表3件が今回の確認では404だった。JetsonHacksの記事本文には当時のビルドb6767の記載が残るが、数値の再照合ができないため、本記事ではその表や26％・80％という優位幅を確定値として再掲しない。

一次の投稿本文で確認できた別のThor実測例では、gpt-oss-120b MXFP4、llama.cpp b6771、JetPack 7.0、MAXNとjetson_clocks有効、初期文脈深度0、入力2,048トークン、生成32トークンで、prefill 967.20、decode 42.00 tokens/秒が報告されている。2025年のコミュニティ測定であり、本紙による実機測定ではない。ビルドの異なるSparkの数字と組み合わせて順位をつけない。

購入判断に使うなら、使いたいモデルと量子化ファイルを固定し、同じエンジンの版、入力長、出力長、バッチ、電力条件で両機を測る。文章生成速度に加え、最初の応答までの時間、最大メモリ使用量、継続実行時の温度と電力も記録する。

^{[2,1,12,13,14]}

5. ロボットでは、センサーと関節への接続が選定を変える#

例として「机の上のボトルを見つけ、双腕ロボットが把持する」処理を考える。カメラ画像から対象を認識し、VLAが行動候補を出し、ロボットの状態や制約を確認してから、制御基板へ目標を渡す。GPUでの推論速度だけでなく、この経路全体を作る必要がある。

Thor開発者キットにはCANヘッダーと、Holoscan Sensor Bridgeを利用するQSFP接続のカメラ入力系がある。採用するカメラ、ブリッジ、ケーブル、ドライバーの組み合わせは別途確認が必要であり、どんなカメラでもそのまま直結できるという意味ではない。

Sparkの公式I/O一覧には標準CAN端子がないため、CAN機器にはUSB-CANやEthernet経由のインターフェースなどを検討する。USBカメラやネットワークカメラも候補になる。USB-CANを使うだけで制御遅延が必ず問題になるとは言えず、周期、バス負荷、遅延のばらつきを実測して判断する。

なお、Holoscan Sensor Bridgeの現行対応表にはDGX Sparkも載っている。高速センサー処理がThorだけの専売機能という整理は正しくない。ThorとSparkではネットワーク経路や推奨構成が異なるため、実際の対応表に沿って構成を選ぶ。

^[1,2,8]

6. MIG・PVA・RTカーネルが助けるのは処理の共存#

ボトルを見つけるカメラ認識と、VLAの行動生成と、別のAIタスクが同時に動くと、計算資源の取り合いが起こり得る。平均速度が十分でも、一部のフレームだけ大きく遅れると、制御系が使う観測が古くなる。

JetPack 7.2のThor向けMIGは、GPUを2つの独立したインスタンスへ分割し、計算資源、キャッシュ、メモリ帯域を割り当てる機能だ。認識処理と別のAI処理の干渉を抑える選択肢になる。ただし分割した資源は各処理が独占的に使える最大量を減らす。実際のモデルが割当内に収まるか確認する。

PVAは画像処理に使える専用アクセラレーターで、対応する処理をGPUから分担できる。すべてのVLA処理が自動でPVAへ移るわけではない。MIGもPVAも、アプリケーションが対応経路や配置を利用して初めて効果を評価できる。

PREEMPT_RTカーネルはOSのスケジューリング遅延のばらつきを減らすための選択肢だ。NVIDIAの導入資料ではDeveloper Previewとして提供され、標準カーネルとは別に導入する。現在のHoloscan資料も標準設定ではないことと、本番用途を意図しないPreview品質を明記している。CPU隔離やスケジューリングの設定を含め、自分の環境で検証する必要がある。

これらは、モーターの1kHz制御や非常停止、機能安全を自動的に保証するものではない。本紙の設計上の推奨として、高速な関節制御や異常時の停止は独立した制御基板側に持たせ、上位AIの遅延や停止があっても安全側へ移れる構成を検討する。

^[5,1,6,7,4]

7. 40〜130Wと240Wを、そのまま比べてはいけない#

Thorの40〜130WはT5000モジュールの電力設定範囲。Sparkの140WはCPUとGPUを含むGB10のTDPで、240Wは付属外部電源の定格だ。測定対象も意味も異なるため、これらの数字だけで「ThorはSparkの半分の電力」とは言えない。

バッテリー駆動の機体では、目的のVLAを動かしながら、カメラ、SSD、通信、冷却を含む入力電力を測る。待機時とピーク時に加え、稼働時間、冷却余裕、ケーブルや電源変換の損失も判断材料になる。

完成品の外形ではSparkのほうがコンパクトだ。Thorの利点は開発者キット自体が必ず小さいことではなく、100×87mmのT5000モジュールを使い、キャリアボードや冷却を機体に合わせて設計できることにある。独自設計には開発費と検証が必要になる。

^[1,2,10]

8. Sparkをロボットに使ってもよいのか#

使える可能性はある。NVIDIAのIsaac ROS Benchmark対応表は、Jetson、NVIDIA GPU搭載のx86_64機に加え、DGX Sparkも明示している。ただし、対応するOSやROS、ソフトウェアの版をそろえることが前提で、すべてのロボットアプリが無変更で動く保証ではない。

机上で電源につないだ研究機で、USBカメラ、USB-CAN、独立した関節制御基板を使うなら、Sparkも候補に残せる。VLAの行動更新を10Hzとする設計例なら1周期は100msだが、これは性能測定値でも推奨値でもない。対象モデルとタスクが要求する周期に対し、撮影、転送、認識、推論、通信を合わせた時間が収まるかを確認する。

推論が100ms以内でも、カメラ画像が古い、通信に待ち行列がある、時刻同期がずれている、といった問題は残り得る。平均だけでなく遅延の上位分位や最大値、行動の陳腐化、途中で異常が起きた場合の動作を評価する。

^[9,8,2]

9. EmplifAIのOpenShellへ導入するなら#

ここでいうOpenShellは、EmplifAIの双腕ロボットを指す。以下は導入設計の比較案であり、ThorやSparkを搭載した実機評価が完了したという報告ではない。

USBカメラとOpenArmのCAN系を使う研究用の試作段階では、両機を候補に残す。まず同じVLAモデルで、画像入力から行動出力までの遅延、安定した更新周期、メモリ、入力電力を比べる。Sparkでも既存の接続機器で成立するなら、組み込み向けの追加機能を必須条件にする必要はない。

機体への組み込み、自律稼働、電源や冷却の最適化、高度なセンサー統合を進める段階では、T5000モジュールとJetPackのあるThorを優先して評価する。これは統合のしやすさについての本紙の判断であり、「ThorのVLA推論が常に速い」という結論ではない。

社内の机上でLLMやAIエージェントを開発するならSparkを先に比較する。ただしモデルが専用GPUのメモリに収まる場合は、GPU搭載PCも比較対象になる。128GBという容量の価値と、実際の生成速度、導入費を別々に評価したい。

^[1,2,9]

10. 用途別の選び方と、購入前の測定項目#

ロボット用なら必ずThor、LLM用なら必ずSparkという二択ではない。搭載条件と必要な接続が厳しいほどThorの設計が効き、机上のAI開発が中心であるほどSparkを評価しやすい。大規模なフル学習や高い同時処理能力が必要なら、この2機に絞らずGPUサーバーも含めて考える。

比較時は、モデル名と重みのハッシュ、量子化形式、ソフトウェアの版、文脈長とバッチ、電力モード、接続するセンサーを固定する。その上で、LLMならprefillとdecode、ロボットなら撮影から行動出力までの遅延と揺らぎを測る。長時間動作時の熱、入力電力、再起動や切断時の挙動も記録する。

判断の中心は、公称TFLOPSではなく、自分の処理が必要な周期と品質で動くかどうかだ。Thorの価値は大容量のLLM推論機であることだけでなく、機体のセンサーとAIを一体として設計できることにある。Sparkの価値は、その大容量メモリを机上のAI開発へ持ち込みやすいことにある。

^[1,2,9]