DGX Sparkで開発するうえで重要なのは、「モニターの下に置けるGPU」という点ではありません。Grace Blackwell GB10が備える128 GBのコヒーレント統合システムメモリーと、NVIDIAがサポートするソフトウェア経路（DGX OS、コンテナ、クラスタリング）の組み合わせです。これによってローカルでホストできるモデルは変わりますが、メモリー計算、サービングの不具合、クラウドの経済性がなくなるわけではありません。
この記事は、DGX Sparkとは何かを運用面から補足する記事です。仕様と製品上の説明は、NVIDIAの製品ページとリリースノートに基づいています（ドキュメントは2026-08-04に確認）。
ローカル推論でも相当な電力を消費し、熱を発します。アイドル状態のデモではなく、連続負荷に合わせて電源回路と冷却設備を設計してください。認証、TLS、ネットワークポリシーなしでOpenAI互換ポートを公開インターネットに露出させてはいけません。
統合メモリー：実務で「128 GBコヒーレント」が意味すること
従来のディスクリートGPUサーバーでは、モデルの重みとKVキャッシュを置くGPU VRAM、それ以外を置くホストRAMを分けて計画します。両者の間でPCIeをまたぐデータ転送にもコストがかかります。
Sparkでは、NVIDIAのアーキテクチャがコヒーレント統合システムメモリーを提供します。CPUとGPUが1つの大きなメモリープール（NVIDIAによれば128 GB LPDDR5x）を共有します。サービング設計では、次の点が重要です。
- 大規模モデルの重みを、ランタイムがアクティベーションとKVキャッシュに使うのと同じプールへ配置できます。
- 上限がなくなるわけではありません。重み、KVキャッシュ、フレームワークのオーバーヘッド、OS、その他のサービスをすべて収める必要があります。
- 帯域幅とレイテンシーの特性は、HBMを多用するデータセンターGPUとは異なります。NVIDIAは製品ページにメモリー帯域幅を記載していますが、これはハードウェア上の上限として扱うべきであり、tok/sを保証する値ではありません。
おおよそのメモリー予算（例示であり保証ではない）
大まかな計画に使うための概算です。実際のメモリー使用量は、アーキテクチャ、量子化、サービングエンジンによって異なります。
| 使用項目 | メモリー消費の特徴 |
|---|---|
| モデルの重み | 最大の要因。FP4／FP8／INT4によって必要量が大きく変わる |
| KVキャッシュ | コンテキスト長×同時シーケンス数に応じて増える |
| ランタイム／CUDAグラフ／フレームワーク | 無視できない固定オーバーヘッド |
| OS＋Docker＋エージェント＋監視 | 「専用」マシンでも過小評価しやすい |
| 余裕 | 使用量の急増とアップグレードに備えて残す |
1件のチャットではなく、実測したピーク時の同時コンテキスト数に基づいてメモリーを見積もってください。KVキャッシュの増大はOOMを引き起こす要因の1つです。2セッションで障害が起きるという仮定を実績のように扱わず、負荷テストで再現してください。
NVIDIAによる「単一ノードで約200Bパラメーター」という主張の読み方
NVIDIAは、大容量の統合メモリーを備えたデスクトップ1台で、最大約二千億（200 billion）パラメーターのAIモデルを扱える製品としてDGX Sparkを訴求しています。この主張は次のように解釈してください。
- あらゆるオープンウェイトのチェックポイントについて測定したSLAではなく、ベンダーによる能力訴求です。
- 暗黙に効率のよい精度形式と、サポート対象のサービング経路を前提としています。NVIDIAはFP4で最大1PFLOPというピーク性能を強調しています。
- 使用したいモデル、トークナイザー、ツール呼び出しテンプレート、評価スイートが、その規模で適切に動作するかどうかとは別問題です。
主張が言っていないこと：
- 高い同時実行数と長いコンテキストで、200Bパラメーターのモデルをフル精度で動かせること。
- 難しいタスクで、最先端のホスト型モデルと同等の品質を得られること。
- 顧客契約に記載できる特定のtokens/s値。
さらに大きなモデルやテンソル並列サービングに向けて、NVIDIAはConnectX-7を使ったマルチノード構成（一般に2～4台のSparkとして説明されます）を文書化しています。クラスタリングのドキュメントと、2台のDGX Sparkを接続するを参照してください。RoCE上でvLLMをテンソル並列実行する例など、コミュニティのレシピは個別の構成に固有です。そこに記載されたtok/sや最大コンテキストは普遍的な保証ではなく、自分の環境で再測定すべき報告値として扱ってください。
ドキュメントに記載されたサービングスタックの候補
構成イメージは次のとおりです。
DGX OS（UbuntuベースのNVIDIAスタック）
→ NVIDIAドライバー／コンテナランタイム
→ サービングコンテナ（vLLM、TensorRT-LLM、NIMなど）
→ OpenAI互換HTTP（またはgRPC）
→ LAN上のエージェント／n8n／アプリ
DGX OSとコンテナ
DGX SparkはDGX OSで動作します。他の推論ホストと同様に、アップデート、再起動時間帯、Docker（または同等の仕組み）の権限を計画してください。NVIDIAのプレイブックは、モデル側の不具合を追う前に、現行のDGX OSがインストールされ、nvidia-smiとコンテナからのGPUアクセスが機能していることを前提としています。
サービングの選択肢（流行ではなく基準で選ぶ）
| スタック | 選ぶ典型的理由 | 注意点 |
|---|---|---|
| vLLM | OpenAI互換サービング、幅広いオープンモデルへの対応、マルチノード向けレシピ | バージョンと量子化方式の互換性。最大シーケンス数とKVキャッシュの調整が必要 |
| TensorRT-LLM (TRT-LLM) | サポート対象モデル向けにNVIDIAが最適化したエンジン | エンジンのビルドコスト。モデルごとに推奨経路が限られる |
| NVIDIA NIM／NGC経路 | 一覧に掲載されたモデル向けに、NVIDIAがパッケージ化したマイクロサービスを使いたい場合 | モデルカタログとライセンス条件。すべてのHFチェックポイントに対応するわけではない |
| llama.cpp／Ollama系 | 小規模モデルや量子化モデルを手軽にローカルで使いたい場合 | Sparkで扱える最大規模のワークロードには適さない可能性がある |
NVIDIA dgx-spark-playbooksには、vLLM、TRT-LLM、Ollamaなどの手順が用意されています。まず現行のベンダー文書にあるプレイブックから評価を始め、すべてのアーティファクトのバージョンを固定してください。実機でベースラインを再現してからカスタマイズします。
エージェント向けエンドポイント
多くのSME向け連携ツール（n8n、Hermes、OpenClaw、カスタムアプリ）は、LANまたはVPN上にあるOpenAI互換の/v1/chat/completionsベースURLを前提としています。背後のエンジンを差し替えても、このインターフェース契約は安定させてください。評価を実行するたびにモデルID、量子化方式、サーバーバージョンを記録し、「品質が落ちた」ときに原因を診断できるようにします。
測定プロトコル（最小）
ローカルモデルを「本番対応」と呼ぶ前に、最低限次を実施します。
- 実際の業務を表す20～50件のプロンプトで評価セットを作ります。簡単なチャット例だけにせず、障害の種類が見つかるたびに拡充してください。これはスモークテストの目安であり、統計的な保証ではありません。
- 日付、サービングエンジンのバージョン、モデルID、精度形式、最大コンテキスト、同時実行数を記録します。
- その同時実行数でのp50／p95レイテンシーと、OOM率、タイムアウト率を測定します。
- 対象タスクで信頼できる、人による評価基準または自動チェックを使って品質を採点します。
- エンジンまたはOSをアップグレードするたびに、同じ手順を再実行します。
この反復がなければ、Sparkの評価は「先週の火曜日は速く感じた」という言い伝えになってしまいます。
設計時に想定すべき障害モード
| 障害 | 症状 | 対策 |
|---|---|---|
| 重み／KVキャッシュのOOM | プロセス終了、CUDA OOM、ワーカーのハング | コンテキスト長、同時実行数、数値精度を下げる。複数ノードへ分割する |
| 温度／電力によるスロットリング | 継続負荷時にレイテンシーが急増 | 負荷をかけて測定し、エアフローと電源回路を確認する |
| 古いコンテナ／ドライバーの不整合 | OS更新後に原因不明のクラッシュ | バージョンを固定し、更新のたびにスモークテストする |
| ディスク容量不足（モデルキャッシュ） | プルの失敗、破損したレイヤー | モデルとログに必要なNVMe容量を確保し、キャッシュを整理する |
| 単一ノード障害 | エージェントがフェイルオープンする、または気付かれずに失敗する | ヘルスチェックとクラウド／SaaSへのフォールバック経路を用意する |
| 認証のないAPI | LAN上の誰もがプライベートモデルの出力を取得できる | プライベートインターフェースにバインドし、認証とネットワークACLを適用する |
| 量子化による品質の急落 | 難しいタスクで、もっともらしい誤答を流ちょうに返す | 本番稼働前にタスク固有の評価セットで検証する |
| エージェントによるツール悪用 | ローカルモデルとシェルの組み合わせは安全ではない | サンドボックス化し（NemoClawを参照）、許可リストを使う |
ローカルだからといって、どこにもログが残らないわけではありません。プロンプト、ツールトレース、取得文書の保持方針を決めてください。ディスク暗号化とアクセス制御は、「クラウドAPIを使わない」ことと同じくらい重要です。
クラウドが依然として優位な場面
感覚ではなく、判断基準を書面で定めてください。
クラウド／マネージド推論を優先する場合：
- 評価セットで、ローカルのオープンモデルでは到達できない最先端の品質が必要な場合。
- 負荷の変動が激しく、アイドル時の設備投資負担が大きい場合。
- DGX OS、コンテナ、オンコール対応を運用できる体制がない場合。
- マルチリージョンの高可用性またはベンダーSLAが必要な場合。
- 必要なモデルやモダリティが、Sparkのサービング経路ではまだ利用できない、または安定していない場合。
Spark（またはSpark＋2台目のノード）を優先する場合：
- そのワークフローでは、データをオンプレミスまたは管理下のLANに留める必要がある場合。
- 最先端の絶対的な品質より、デスクトップやLAN上のエージェントループへの低レイテンシーが重要な場合。
- 継続的な推論量によって設備投資を償却できる場合。
- パッチ適用、評価、インシデント対応を担当する人員を配置できる場合。
見せかけの精密さを避けたコスト評価
ブログ記事を基に損益分岐までの月数を作り上げてはいけません。前提を明記した簡潔なモデルを作ってください。
| 入力 | ソース |
|---|---|
| ハードウェア＋税＋送料 | 日付付きリセラー／NVIDIA見積もり |
| 電力（連続稼働とデューティサイクル） | 実測した消費電力、またはPSU／TDPの注記×現地のkWh単価。見積もりであることを明記 |
| 月あたりのエンジニアリング工数 | 実際の人件費 |
| クラウドの代替手段 | _同じ_品質基準を満たす現行のトークン単価またはGPU時間単価 |
クラウドの代替手段が安く、かつそのデータ区分で利用可能なら、Sparkは必須ではありません。データ区分によってクラウド経路が禁止されるなら、設備投資はtok/sの最適化費用ではなく、コンプライアンス対応費です。
ハイブリッド構成は、堅実な設計として今も有効です。リクエストを分類し、制限対象の処理はローカルへ振り分け、公開情報を扱う処理や高度な推論を要する処理は、必要な秘匿化を施してから承認済みのホスト型モデルへ送ります。これはプライベートAIの導入パターンと同じ枠組みです。
構築者チェックリスト（単一ノード）
- 最新の更新を適用した基準環境で、DGX OS、ドライバー、
nvidia-smiを確認する。 - 最初の本番候補となる経路には、サービングスタックを1つ、モデルを1つ選ぶ。
- ロード時間、同時実行数を固定したtok/s、OOMになるまでの最大コンテキスト、固定評価セットでの品質を測定し、実行日を記録する。
- OpenAI互換HTTPは、認証を設定したプライベートインターフェースだけに公開する。
- ヘルスチェックと、文書化したクラウドへのフォールバックを追加する。
- その後で初めて、エージェント、チャネル、n8nを接続する。
現時点では避けること
- 精度形式、コンテキスト、実測レイテンシーを明示せず、顧客に「200Bパラメーターをローカルで動かせる」と約束しない。
- 本番用のシークレットを保存するホスト上で、最初のエージェントに無制限のシェルを与えない。
- マルチノードのドキュメントを読まずに、QSFPを接続するだけで単一ノードのOOMが解消すると期待しない。
- コミュニティが公開したtok/sのスクリーンショットを、キャパシティプランニングに使わない。
Spark上のローカル推論が実用になるのは、メモリー予算、サービングスタック、運用規律も現実的な場合です。このハードウェアは、VRAM上限という制約の一部を取り除きますが、エンジニアリングそのものを不要にはしません。
