😀
Blackwell実機検証：NVFP4量子化によるLLM推論をDGX Sparkで動かす
はじめに
NVIDIAの次世代アーキテクチャ Blackwell 搭載の DGX Spark 上で、Llama 3.1 8B Instruct を NVFP4（4-bit Floating Point）量子化で動作させた実機検証の記録です。環境構築からスループット計測まで、実際に手を動かして得られた結果をまとめます。
検証環境
| 項目 | 値 |
|---|---|
| GPU | NVIDIA GB10（Blackwell） |
| Driver | 580.95.05 |
| CUDA | 13.0 |
| メモリ | 128GB UMA（統合メモリ） |
| OS | Ubuntu（Linux 6.14.0-1015-nvidia） |
| Docker | 28.5.1 |
| 推論エンジン | TensorRT-LLM 1.2.0rc6 |
| モデル | nvidia/Llama-3.1-8B-Instruct-FP4 |
Step 1: DockerからのGPUアクセス確認
まず、DockerコンテナからGPUが正しく認識されるかを確認します。NVIDIA Container Toolkit が正常に動作していなければ、以降のステップは全て失敗します。
ユーザーをdockerグループに追加
sudo usermod -aG docker $USER
newgrp docker
GPUパススルーの確認
docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi
確認結果
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 580.95.05 Driver Version: 580.95.05 CUDA Version: 13.0 |
+-----------------------------------------+------------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| 0 NVIDIA GB10 On | 0000000F:01:00.0 On | N/A |
| N/A 44C P8 4W / N/A | Not Supported | 0% Default |
+-----------------------------------------+------------------------+----------------------+
GB10 が認識され、コンテナ内から nvidia-smi が正常に実行できることを確認しました。Memory-Usage: Not Supported は UMA 構成のため個別 VRAM 表示に非対応であることを示しており、正常です。
Step 2: 環境変数の設定
export HF_TOKEN="<your_huggingface_token>"
export MODEL_HANDLE="nvidia/Llama-3.1-8B-Instruct-FP4"
export DOCKER_IMAGE="nvcr.io/nvidia/tensorrt-llm/release:1.2.0rc6"
-
HF_TOKEN: Hugging Face の Read 権限トークン。モデルダウンロードの認証に使用 -
MODEL_HANDLE: NVIDIA が Blackwell 向けに NVFP4 量子化済みで公開しているモデル -
DOCKER_IMAGE: TensorRT-LLM の推論エンジンイメージ（NGC で公開）
NGC レジストリへのログイン
NGC のコンテナイメージは認証が必要です。NGC Personal Key を発行し（権限は NGC Catalog のみで十分）、以下でログインします。
docker login nvcr.io -u '$oauthtoken'
# Password: に NGC Personal Key を入力
Step 3: Blackwell最適化設定ファイルの作成
TensorRT-LLM サーバーのチューニング設定です。
cat > ~/extra-llm-api-config.yml <<EOF
print_iter_log: false
kv_cache_config:
dtype: "auto"
free_gpu_memory_fraction: 0.9
cuda_graph_config:
enable_padding: true
disable_overlap_scheduler: true
EOF
| 設定 | 効果 |
|---|---|
free_gpu_memory_fraction: 0.9 |
GPUメモリの90%をKVキャッシュに割り当て。NVFP4でモデルが小さい分、文脈保持に全振り |
cuda_graph_config.enable_padding: true |
CUDA Graph を有効化し、カーネル起動オーバーヘッドを削減 |
disable_overlap_scheduler: true |
最初のトークンが返るまでの遅延（TTFT）を最小化 |
Step 4: TensorRT-LLM サーバーの起動
docker run --name trtllm_fp4_server --rm -it \
--gpus all --ipc host --network host \
-e HF_TOKEN=$HF_TOKEN \
-v $HOME/.cache/huggingface/:/root/.cache/huggingface/ \
-v $HOME/extra-llm-api-config.yml:/tmp/config.yml \
$DOCKER_IMAGE \
trtllm-serve "$MODEL_HANDLE" \
--max_batch_size 64 \
--port 8355 \
--extra_llm_api_options /tmp/config.yml
注意: 複数行に分ける
\の直後にスペースが入るとdocker: invalid reference formatエラーになります。エラーが出る場合は1行にまとめて実行してください。
起動完了時のログ:
[TRT-LLM] [I] get signal from executor worker
INFO: Started server process [1]
INFO: Waiting for application startup.
INFO: Application startup complete.
コマンドの解説
| オプション | 役割 |
|---|---|
--gpus all |
GPUをコンテナにパススルー |
--ipc host |
共有メモリを共有。GPU間の大量データ転送に必要 |
--network host |
ホストネットワークを使用。localhost:8355 で直接アクセス可能 |
-v $HOME/.cache/huggingface/:... |
HFキャッシュをマウント。2回目以降の再ダウンロードを防止 |
--max_batch_size 64 |
最大64リクエスト同時処理 |
推論テスト
テスト 1: 基本的な動作確認
curl -s http://localhost:8355/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "nvidia/Llama-3.1-8B-Instruct-FP4",
"messages": [
{"role": "system", "content": "You are a helpful assistant."},
{"role": "user", "content": "Explain what a neural network is in 3 sentences."}
],
"max_tokens": 200,
"temperature": 0.1
}' | python3 -m json.tool
結果
{
"choices": [
{
"message": {
"content": "A neural network is a computer system inspired by the structure and function of the human brain, designed to recognize patterns and make decisions based on data. It consists of layers of interconnected nodes (neurons) that process and transmit information, allowing the network to learn from experience and improve its performance over time. By mimicking the brain's ability to recognize patterns and make connections between data, neural networks can be trained to perform complex tasks such as image recognition, speech recognition, and predictive modeling."
},
"finish_reason": "stop"
}
],
"usage": {
"prompt_tokens": 33,
"completion_tokens": 98,
"prompt_tokens_details": {
"cached_tokens": 2
}
}
}
finish_reason: stop（自然に生成完了）で、整った英文が返されました。NVFP4 量子化でも十分な品質です。
テスト 2: 品質の限界
曖昧な知識領域（例: "What is Blackwell architecture?"）では出力が途中で崩壊する現象を確認しました。8B モデル + FP4 量子化の組み合わせでは、モデルが不得意な領域で破綻しやすい傾向があります。system メッセージの追加と低い temperature（0.1）の設定で安定性が改善しました。
検証結果
VRAM 占有量と UMA の挙動
nvidia-smi（サーバー稼働中）
| 項目 | アイドル時 | サーバー稼働中 |
|---|---|---|
| Perf State | P8（省電力） | P0（最大性能） |
| 温度 | 44C | 50C |
| 消費電力 | 4W | 11W |
GPU メモリ使用量（プロセス別）
| プロセス | GPU Memory | 役割 |
|---|---|---|
| python（APIサーバー） | 240MiB | trtllm-serve |
| python（推論エンジン） | 8,486MiB | モデル本体 + KVキャッシュ |
| 合計 | 約8.7GB |
内訳の推定:
- モデル重み（NVFP4）: 約5GB（8B params × 4bit + オーバーヘッド）
- KVキャッシュ: 約3.7GB（
free_gpu_memory_fraction: 0.9の割り当て分）
FP16 では約16GB 必要なため、メモリ使用量が約1/3 に削減されています。
UMA メモリ状況（/proc/meminfo）
| 項目 | 値 | 意味 |
|---|---|---|
| MemTotal | 約120GB | UMA全体 |
| MemFree | 約4.3GB | 未使用メモリ |
| MemAvailable | 約70.6GB | 実質的な空き（キャッシュ解放分含む） |
| Cached | 約61.6GB | Linux ファイルキャッシュ |
MemFree が少なく見えますが、Linux がメモリをファイルキャッシュに積極利用しているためで、実質の空きは MemAvailable の約70.6GB です。128GB UMA のうち、GPU + OS + アプリで約50GB 使用、残り70GB 以上が利用可能という余裕ある状態でした。
スループット計測（単一リクエスト）
512トークン生成での計測結果:
| 指標 | 値 |
|---|---|
| completion_tokens | 512 |
| 応答時間 | 15.9秒 |
| スループット | 約32.2 tokens/sec |
| cached_tokens | 43/44 |
FP16 との比較（理論値含む）
| 項目 | FP16 | NVFP4 | 改善 |
|---|---|---|---|
| モデルサイズ | ~16GB | ~5GB | 約1/3 |
| メモリ帯域消費 | 基準 | 約1/4 | KVキャッシュに余裕 |
| Tensorコア演算 | FP16演算 | FP4最適化演算 | 最大2倍 |
トラブルシューティング
NGC レジストリの Access Denied
NGC コンテナイメージは認証が必要です。docker login nvcr.io でログインしてから再実行してください。
まとめ
DGX Spark（Blackwell GB10）上で NVFP4 量子化の LLM 推論を動作させ、以下を確認しました:
- メモリ効率: 8B モデルが約5GBに収まり、FP16比で約1/3。128GB UMA に対して余裕がある
- スループット: 単一リクエストで約32 tokens/sec を達成
- KVキャッシュ: NVFP4 で節約したメモリをKVキャッシュに割り当てることで、長文生成や多リクエスト処理に有利
- 運用性: サーバー稼働中でも消費電力11W、温度50Cと、デスクサイド運用に問題のない水準
Discussion