NVIDIA講習を受けて、その流れに準拠しつつ、実際に DGX Spark(Grace Blackwell / GB10)環境で NVIDIA NIM(Inference Microservices)を使って LLM を動作できるかを検証した。
1. NVIDIA AI Enterprise における NeMo / NIM の関係
NVIDIA AI Enterprise は 「LLMを業務で使うための完成形アーキテクチャ」 として提供されています。構造を簡略化すると、次のようになります。
┌──────────────────────────────┐
│ NVIDIA AI Enterprise │
├──────────────────────────────┤
│ NIM : Inference Microservices│ ← API / サービング
├──────────────────────────────┤
│ NeMo Framework │ ← 学習・微調整
├──────────────────────────────┤
│ TensorRT-LLM / vLLM / CUDA │ ← 推論最適化
├──────────────────────────────┤
│ NVIDIA GPU (A/H/B/GB) │ ← ハードウェア
└──────────────────────────────┘
NVIDIAには、H100, A100, L40S, RTX 6000 Adaなど、多様なGPUが存在します。これら全ての環境でLLMを最高性能で動かすのは、本来非常に高度なチューニング技術が必要です。
- NeMo (学習): GPU間の通信(NVLink/InfiniBand)を最大限活用するように設計されています。特に複数のGPUにまたがる巨大モデルの学習(Megatron-LMベースの分散学習)において、手動チューニングなしで業界最高レベルの効率を出せるよう調整されています
- NIM (推論): コンテナ起動時に 「今動いているGPUは何か?」を自動検知し、そのGPUに最適なプロファイル(TensorRT-LLMのEngineなど)を自動適用します
- H100ならH100用のFP8最適化
- A100ならA100用の最適化 これらが NVIDIAによってテスト済み(Verified) であるため、エンジニアはハードウェアごとの微調整から解放されます
1. NeMo を「使う vs 使わない」の比較表
| 項目 | NeMo を使うメリット | NeMo を使わない場合 (Hugging Face / PyTorch直書き) |
|---|---|---|
| 主な用途 |
企業向けLLM開発、大規模事前学習 数億〜数千億パラメータのモデル構築 |
研究、PoC、小規模ファインチューニング 小規模な実験や学習 |
| パフォーマンス |
◎ 非常に高い Megatron-LMによる分散学習が統合されており、GPUリソース(特に複数枚・複数ノード時)を無駄なく使い切れる。 |
◯ 普通 〜 △ 設定次第 標準的な学習ライブラリでは、大規模分散環境での通信ボトルネックが発生しやすく、高度な自前チューニングが必要。 |
| 使いやすさ |
◯ 構成ファイル管理 YAMLファイルで実験管理が可能。再現性が高い。 |
◎ 非常に手軽 情報量が多く、コミュニティのサンプルコードが豊富。コピペで動くことが多い。 |
| エコシステム |
NVIDIAハードウェア特化 NVIDIA GPUで最高性能が出るよう設計されている。 |
汎用的 コードの書き換えなしでAMDやTPUなど他環境でも動きやすい。 |
| デメリット |
オーバースペック・学習コスト 小規模な実験や、GPU 1枚で済む学習には重厚長大すぎる場合がある。独自の作法を覚える必要がある。 |
スケーリングの壁 GPU数百枚規模の学習を行おうとすると、安定化させるのに高度なインフラ技術力が必要になる。 |
2. NIM を「使う vs 使わない」の比較表
| 項目 | NIM を使うメリット | NIM を使わない場合 (vLLM / TGI / llama.cpp 生利用) |
|---|---|---|
| 主な用途 |
本番環境、エンタープライズ製品への組み込み 信頼性と速度が求められる商用利用 |
個人の実験、コスト重視のスタートアップ 初期コストを抑えたいフェーズ |
| 導入スピード |
◎ 爆速 (Day 0 Support) 最新モデル(Llama 3等)が出たその日に、最適化済みコンテナが提供される。 docker run だけでAPIが立つ。 |
△ 手間がかかる 環境構築、依存関係の解消、推論サーバーの選定・設定をすべて自分で行う必要がある。 |
| 最適化・速度 |
◎ 自動最適化 TensorRT-LLMを内包しており、実行環境のGPU(H100/A100等)を検知して最大性能が出る設定を自動適用する。 |
◯ 手動調整が必要 vLLMなども高速だが、GPUごとの最適設定やメモリ管理は自分でチューニングが必要。 |
| 信頼性・保守 |
◎ エンタープライズ品質 脆弱性(CVE)スキャン済み。NVIDIA AI Enterprise契約下ならサポート窓口がある。 |
△ 自己責任 (Community Support) バグやセキュリティホールは自分で監視し、アップデート対応する必要がある。 |
| デメリット |
ブラックボックス化 & コスト 中身がいじれないため、特殊な改造は難しい。商用利用にはライセンス費がかかる場合がある。 |
運用工数の増大 「動かない」「遅い」といったトラブルシューティングにエンジニアのリソースが取られる。 |
2. 今回検証した環境(DGX Spark / GB10)
本検証は、NVIDIA が提供するデスクトップ型AIスーパーコンピュータ「DGX Spark」(Grace Blackwell 世代)実機環境で実施しました。
| コンポーネント | スペック |
|---|---|
| ハードウェア | NVIDIA DGX Spark |
| SoC |
NVIDIA GB10 Grace Blackwell Superchip NVLink-C2C Connected |
| CPU |
20 Cores Arm64 (10x Cortex-X925 + 10x Cortex-A725) |
| GPU |
NVIDIA Blackwell GPU (GB10) Dense / Sparse FP4 Tensor Cores |
| メモリ |
128 GB Unified Memory (LPDDR5x) Bandwidth: ~273 GB/s ※ CPU/GPU共有 (Coherent Memory) |
| ストレージ |
4TB NVMe M.2 SSD 自己暗号化ドライブ (SED: Self-Encrypting Drive) |
| ネットワーク |
NVIDIA ConnectX®-7 Smart NIC x2 10 GbE(RJ-45) / WiFi 7 / Bluetooth 5.3 |
| OS | NVIDIA DGX OS (Based on Ubuntu LTS) |
| GPU Driver | 580.95.05 |
| CUDA | Toolkit 13.0 |
3. NIM セットアップ手順(DGX Spark / GB10)
1. dgx-spark 対応の NIM モデルを探す
1カ月前に某社内の検証で、汎用 NIM イメージを用いた際に DGX Spark(GB10)環境で推論エンジンの初期化に失敗した経験があった。そのため今回は、最初に「DGX Spark 対応」を明示した NIM モデルがあるかを確認した。
NVIDIA の NIM リリースノート/ユーザーコミュニティに
- Llama-3.1-8B-Instruct-DGX-Spark
- NVIDIA-Nemotron-Nano-9B-v2-DGX-Spark
- Qwen3-32B NIM for DGX Spark
の 3 つが、Spark(GB10 Blackwell)向けの NIM バリアントとして記載されたモデルであった。今回は Llama-3.1-8B-Instruct-DGX-Spark を試してみる。
2. NGC API Key の準備と認証
2-1. NGC にログインし API Key を取得
まずは、NVIDIA NGC( https://ngc.nvidia.com )にログインし、 Personal API Key を作成します。
- Username:
$oauthtoken← これはこのまま - Password:
<NGC_API_KEY>← 取得したキー
2-2. Docker で nvcr.io にログイン
sudo docker login nvcr.io
⚠️ ここが通らないと NIM イメージは pull できません
認証エラーが出る場合は API Key の権限を再確認してください。
3. NIM イメージの取得
それでは、DGX Spark 対応の NIM イメージを取得します。
sudo docker pull nvcr.io/nim/meta/llama-3.1-8b-instruct-dgx-spark:1.0
4. NIM コンテナを起動
モデルキャッシュ用ディレクトリを用意しておきます。
export LOCAL_NIM_CACHE=$HOME/.cache/nim
mkdir -p $LOCAL_NIM_CACHE
chmod 777 $LOCAL_NIM_CACHE
そして、NIM コンテナを起動します。
sudo docker run -d \
--name nim-llama31-8b-dgx-spark \
--gpus all \
--shm-size=16g \
-e NGC_API_KEY=$NGC_API_KEY \
-e ACCEPT_NVIDIA_TOS=1 \
-e NIM_GPU_MEM_FRACTION=0.2 \
-e NIM_KVCACHE_PERCENT=0.8 \
-v "$LOCAL_NIM_CACHE:/opt/nim/.cache" \
-p 8000:8000 \
nvcr.io/nim/meta/llama-3.1-8b-instruct-dgx-spark:1.0
5. 起動ログの確認
NIM コンテナ起動後、以下のコマンドでログを確認します。
sudo docker logs nim-llama31-8b-dgx-spark
ログから以下の点を確認しました。
5-1. GPU として NVIDIA GB10 を正しく認識している
INFO gpu_utils.py:89] Detected GPU: NVIDIA GB10
INFO gpu_utils.py:94] Compute capability: 10.x
- NIM が実行環境の GPU として NVIDIA GB10 を正しく検出している
- 少なくとも CUDA / Driver / コンテナの組み合わせとしては成立していることが分かる
5-2. 推論エンジンとして vLLM が自動選択されている
INFO engine_selector.py:52] Selecting inference backend
INFO engine_selector.py:78] Selected backend: vLLM
- NIM は内部で TensorRT-LLM / vLLM のどちらかを自動選択する
- この環境では vLLM が選択された
5-3. FP8 プロファイルが有効になっている
INFO precision.py:41] Using precision profile: FP8
INFO kv_cache.py:67] KV cache initialized with FP8 support
- GB10(Blackwell 世代)の特徴である FP8 推論が有効化されている
- 精度・メモリ効率・スループットのバランスが取れた設定
- -dgx-spark イメージでは、このあたりが前提として調整されていると考えられる
5-4. モデルアセットファイルがキャッシュにダウンロードされている
INFO model_loader.py:112] Downloading model weights
INFO model_loader.py:145] Saving model to /opt/nim/.cache/models/...
INFO model_loader.py:178] Model weights loaded successfully
- NGC から Llama 3.1 8B Instruct のモデルアセットファイルがダウンロードされている
- キャッシュ先は /opt/nim/.cache(ホスト側では $HOME/.cache/nim)
- 初回起動時のみ時間がかかるが、2回目以降はキャッシュを再利用できる
5-5. サーバ起動完了(API リクエスト受付可能)
INFO api_server.py:245] API server started
INFO api_server.py:248] Listening on http://0.0.0.0:8000
- NIM の API サーバが正常に起動
- OpenAI 互換 API(/v1/chat/completions など)が利用可能な状態
- このログが出ていれば、次のステップ(curl での疎通確認)に進める
起動ログから、以下が確認できた。
✔ GPU として NVIDIA GB10 を正しく認識
✔ 推論エンジンとして vLLM を自動選択
✔ FP8 プロファイルが有効
✔ モデル重量ファイルのダウンロードとキャッシュが正常
✔ NIM サーバが起動し、API を受け付ける状態になった
6. 推論 API 疎通確認(OpenAI 互換)
NIM は OpenAI API 互換のエンドポイントを提供します。そのため、curl / OpenAI SDK / LangChain / Dify などから即利用可能です。
curl -s http://localhost:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "meta/llama-3.1-8b-instruct",
"messages": [
{
"role": "user",
"content": "こんにちは。こちらはどんなマシンですか?一行で答えてください。"
}
]
}'
実際のレスポンス
{
"choices": [
{
"message": {
"role": "assistant",
"content": "翻訳機です。"
}
}
]
}
👉 NIM による Llama 3.1 8B Instruct の動作確認が出来ました。
7. 汎用NIMイメージについて
実は、約1か月前に某社内で同じDGX Sparkをセットアップして検証したのですが、その時に試したのは DGX Spark 専用ではない汎用 NIM イメージ。(DGX Spark専用イメージがあるなんて知らなかった)
nvcr.io/nim/meta/llama-3.1-8b-instruct:latest
こちらをDGX Spark(GB10)環境で起動を試みましたが、推論エンジン初期化の段階でうまくいきませんでした。
これは、DGX SparkはARMアーキテクチャ(aarch64)であるため、x86向けが含まれる汎用タグや、Blackwell特有の最適化が含まれていないコンテナでは動作しない場合があり、汎用の latest タグなどは、デフォルトで x86_64 (AMD64) 向けのバイナリをプルしてしまうことが多いためのようです。
今回は、DGX Spark専用イメージで NIM の正常起動が確認できました。