重要な二つの速度
デコードスループットは、モデルが回答の生成を開始してからトークンを出力する速度で、一秒あたりのトークン数（tok/s）で測定します。チャットの返信やコード補完が画面に表示されるまでの速さを決めます。 プリフィルレイテンシは、モデルが入力を処理して最初のトークンを生成するまでの時間で、1 トークンあたりのミリ秒（ms/token）で測定します。Enter キーを押してから出力がストリーミングされ始めるまでの待ち時間を決めます。 ワークロードによって重視すべき速度は異なります。最初のトークンが生成されるまでの時間（TTFT）は、プリフィルレイテンシにスケジューリングやキューの遅延を加えたものです。ローカルハードウェアでの単一ユーザー利用では、TTFT はおおよそプリフィル時間と等しくなります。同時負荷がかかると、キューイングが TTFT に独立して追加されます。
精度が速度に与える影響
精度はモデルの各重みを表すビット数を制御します。ビット数が少ないほど重みが小さくなり、モデルが占有するメモリ量と、GPU がトークンごとに読み取るデータ量の 2 つが変化します。精度がデコードとプリフィルに異なる影響を与える仕組み
これが重要なポイントです。デコードとプリフィルは異なるハードウェアのボトルネックに影響を受けるため、同じ精度変更でもそれぞれに与える影響は異なります。デコードはメモリ帯域幅律速
デコード中、モデルは一度に 1 トークンを生成します。トークンごとに重み行列全体をメモリから読み取り、重みあたりごくわずかな計算を実行します。GPU はほとんどの時間を計算ではなく、メモリからのデータ到着待ちに費やします。 重みが小さいほど読み取るデータが減り、デコードが高速化します。高速化の度合いはおおよそメモリ削減量に比例します。- FP16 → FP8：約 1.8〜2.0x のデコード高速化
- FP16 → INT4：約 2.5〜3.5x のデコード高速化
- FP16 → NVFP4：約 2.5〜3.0x のデコード高速化
プリフィルは計算律速
プリフィル中、モデルはすべての入力トークンを並列に処理します。重みは一度だけ読み取りますが、すべてのプロンプトトークンにわたる大規模な行列乗算を実行します。GPU はほとんどの時間をメモリ待ちではなく、計算に費やします。 量子化がプリフィルに与える効果は小さくなります。ボトルネックが重みの読み取りではなく計算だからです。- FP16 → FP8：約 1.3〜1.5x のプリフィル高速化
- FP16 → INT4：約 1.2〜1.5x のプリフィル高速化
- FP16 → NVFP4：約 1.3〜1.5x のプリフィル高速化
実用的な意味
精度を下げると、デコードはプリフィルよりも大きく改善します。INT4 では、FP16 でもたついていたモデルが素早くテキストを生成するようになりますが、長いプロンプトではまだ顕著な一時停止があります。この非対称性が、以下のワークロード別の推奨事項の根拠となります。精度別の消費電力
低精度は 2 つの理由で消費電力を削減します。メモリ読み取りの減少（メモリアクセスがエネルギーコストの大部分を占める）と、演算の単純化（INT4 乗算は FP16 乗算よりもコストが低い）です。DGX Spark の電力範囲
DGX Spark の GB10 チップは、Grace CPU と Blackwell GPU で共有する約 40W の TDP を備えています。以下は推論時に観測された電力範囲です。コンシューマ GPU の電力想定
24/7 稼働のコスト
DGX Spark をデコード負荷で連続稼働させた場合：
RTX 4090 のようなコンシューマ GPU を一日 10 時間使用した場合：
ベンチマーク手法
実際の環境で以下のテストを実行し、精度が特定のモデルとハードウェアにどのように影響するかを確認してください。デコードスループットの測定
短いプロンプトから一定数の出力トークンを生成し、一秒あたりのトークン数を測定します。プリフィルレイテンシの測定
プロンプト長を変えて、モデルが 1 番目のトークンを生成するまでの時間を計測します。消費電力の測定
報告すべき内容
テストした各精度について、以下の表に記入してください。実践的な判断表
主要なワークロードに合致する行を選択してください。なぜ常に INT4 を使用しないのか？
なぜ常に INT4 を使用しないのか？
INT4 量子化（GPTQ、AWQ、Q4_K_M）は、小規模モデルや指示追従タスクで品質が顕著に低下します。13B パラメータ未満のモデルでは、FP16 と INT4 の品質差が出力を劣化させる可能性があります。70B 以上のモデルでは、モデルが量子化ノイズを吸収する余裕が大きいため、その差は縮まります。採用を決める前に、実際に使用するモデルでテストしてください。
KV キャッシュの精度はこれらの数値に影響しますか？
KV キャッシュの精度はこれらの数値に影響しますか？
はい。FP8 KV キャッシュ（vLLM で
--kv-cache-dtype fp8 を設定）は、重みの量子化とは独立に KV キャッシュメモリを半分にします。デコード速度への影響は最小限ですが、より長いコンテキストやより多くの同時ユーザーを処理できるようになります。サイズの目安はDGX Spark メモリチューニングを参照してください。コンテキスト長はデコード速度にどのように影響しますか？
コンテキスト長はデコード速度にどのように影響しますか？
デコードはトークンごとに KV キャッシュ全体を読み取ります。会話が長くなるとキャッシュが大きくなるため、コンテキストが伸びるにつれてデコードは遅くなります。同じハードウェア上で、4K コンテキストでは 40 tok/s で生成できたモデルが、25 tok/s に低下することがあります（32K コンテキストの場合）。仕組みについてはKV キャッシュとコンテキストを参照してください。
クイックベンチマークコマンド
これらを出発点として、単一モデルで精度を比較してください。vLLM ベンチマークスイート
llama.cpp ベンチマーク
Ollama 組み込み評価
精度間の比較
各精度で同じプロンプトを実行し、結果を表に記録します。次のステップ
DGX Spark メモリチューニング
KV キャッシュのサイズ設定、バッチのトレードオフ、128GB 統合メモリのチューニングパラメータについて説明します。
DGX Spark での vLLM
インストール、NVFP4 設定、および最適な起動コマンドについて説明します。
デプロイメントのベンチマーク
Tokios を介したエンドツーエンドのテスト — レイテンシ、ストリーミング、クライアント比較。
量子化の概念
GPTQ、AWQ、GGUF、および量子化のトレードオフに関する詳細な説明。