MacとNVIDIA DGX SparkでLLMワークロードを最適化する方法
CHATGPT / AIChatGPTなどの生成AIを活用して運営・記事制作・更新を行っています。制作方針
MacとNVIDIA DGX Sparkを組み合わせ、LLM推論、クライアント利用、分散構成、役割分担を考えるための最適化ガイド。
先に結論
本記事はMacから単一のDGX Spark APIを使う構成を測定の基準とし、指標の取り方と設定を見直す順序をまとめます。モデルが1台へ収まらない、または単一ノードで目標を満たせない場合だけ、DGX Spark同士の公式マルチノード構成を検討します。
確認日: 2026年8月12日（Asia/Tokyo）
確認対象: DGX OS 7.5.0、NVIDIA Sync User Guide（2026-07-31更新）、NVIDIA vLLM Playbook（2026-08-03更新）
調査方法: NVIDIA公式資料による机上調査。MacまたはDGX Spark実機でbenchmarkは実施していません。
未検証範囲: 個別モデルの収容可否、tokens/s、TTFT、複数利用者時のthroughput、QSFP・LAN・Tailscaleの実効性能。
最適化前に構成を一つ選ぶ
| 構成 | 向く用途 | 計算を行う場所 | 注意点 |
|---|---|---|---|
| Mac → DGX Spark API | アプリ開発、チャット、RAG | DGX Spark | 最初の基準構成に向く |
| Mac → NVIDIA Sync/SSH | remote development、JupyterLab、運用 | DGX Spark | port forwardingと認証を確認 |
| DGX Spark複数台 | 1台に収まらないモデル、対応する分散推論 | DGX Spark群 | QSFP、SSH、Ray、対応Recipeが必要 |
| Mac単独 | 小型モデル、offline作業 | Mac | DGX Sparkとの計算共有ではない |
ここでいうAPI連携は「Macがpromptを送り、DGX Sparkが回答を返す」構成です。Apple SiliconのMetal backendとDGX SparkのCUDA backendを、vLLMが一つのtensor parallel groupへ自動参加させる公式手順は確認できませんでした。
基準構成は単一ノードにする
NVIDIAのDGX Spark向けvLLM Playbookは、対応コンテナとモデルRecipeを使ってOpenAI互換APIを提供する流れを案内しています。まず次の条件を固定します。
- DGX OS、GPU driver、CUDA、container imageのtagまたはdigest
- モデルIDとrevision、量子化方式
max_model_len、同時実行数、sampling条件- prompt dataset、入力token数、出力token数
- warm-upの有無と測定回数
「最新」という名前だけでcontainerやmodelを入れ替えると比較できません。公式Recipeにある組み合わせを起点にし、変更は一項目ずつ行います。
Macからの通信時間を測定に含める
接続の作成手順（NVIDIA Sync、SSH tunnel、アクセス制御）は環境構築ガイドで扱う内容です。ここでは、同じAPI・同じ接続経路を保ち、DGX Spark上のserver計測とMacからのend-to-end計測を分けます。RAGで文書を転送する場合は、indexや原文の置き場所もnetwork待ちに影響するため、測定条件として記録します。
測る指標を分ける
最適化は単一のtokens/sだけで判断できません。
| 指標 | 見る内容 | 主な影響要因 |
|---|---|---|
| TTFT | requestから最初のtokenまで | network、queue、prompt長、prefill |
| Inter-token latency | 生成token間の待ち時間 | model、quantization、batch |
| Request throughput | 単位時間の処理request数 | concurrency、scheduler、memory |
| Prompt throughput | prefillの処理量 | prompt長、batch、kernel |
| Memory使用量 | model・KV cache・runtimeの合計 | context長、並列数、dtype |
Macからのend-to-end測定と、DGX Spark上のserver測定を分けると、network待ちと推論時間を切り分けられます。平均だけでなく、p50とp95、失敗数、OOMの有無も残します。
設定はこの順で見直す
- モデルが収まるか確認する。 重みだけでなくKV cache、runtime、display予約分の余裕を残します。
- context長を実需へ合わせる。 最大contextを常に確保する必要はありません。
- 単一requestを測る。 prompt processingとgenerationを分けます。
- 同時実行数を増やす。 throughputの増加とTTFT悪化を同時に見ます。
- 量子化やbackendを比較する。 品質検証と速度測定を同じdatasetで行います。
- 最後にmulti-nodeを検討する。 1台で達成できない要件を明記してから増設します。
DGX Spark Release Notesは2026年7月版でunified memoryのOOM feedback改善を案内していますが、OOMが起きないことを保証するものではありません。異常終了時は設定を無理に増やさず、model、context、concurrencyの順に戻して原因を切り分けます。
複数台構成の境界
公式Playbookのmulti-node対象はDGX Sparkで、QSFP connectivity、passwordless SSH、Rayを前提とします。ConnectX-7 Networking Guideでは、NVIDIA Sync Cluster Assistantが機器確認、network設定、link performance確認、node間SSHを支援します。
これはMacを計算nodeへ追加する手順ではありません。また、複数台にすれば常に速くなるわけでもありません。modelの分割、node間通信、request数によってはsingle-nodeよりlatencyが増えるため、同じprompt setで比較します。
Prefill/decode分離はvLLMに存在する高度なserver構成ですが、Macをprefill node、DGX Sparkをdecode nodeにするという意味ではありません。対応hardware、KV connector、network、release固有の手順が必要なため、DGX Sparkの一般的な初期構成としては扱いません。
判断基準
- 1台へ収まり目標を満たす: Mac → single DGX Spark APIを維持する。
- UIだけ遅い: Mac側のrendering、stream処理、networkを先に測る。
- TTFTだけ遅い: prompt長、prefix cache、queueを調べる。
- throughputだけ不足: concurrencyとbatchを段階的に試す。
- memory不足: context、concurrency、quantizationを見直し、それでも不足なら公式multi-node Recipeを探す。
- 公式Recipeがない: productionへ持ち込まず、隔離した検証環境で扱う。
本記事の「最適化」は構成と測定手順の整理です。実機測定をしていないため、倍率、tokens/s、memory削減率の断定はしていません。
