TensorRT-LLM最適化：NVIDIAの推論スタックをマスターする

TensorRT-LLMがH100上でFP8を使用し、10,000+出力トークン/秒、100ms未満のTTFTを達成。本番デプロイメントではネイティブPyTorchと比較して4倍のスループットを報告。LayerNorm、行列乗算、活性化関数を単一のCUDAカーネルに統合するカーネル融合。インフライトバッチングによるGPU使用率の最大化。Hopper/Blackwell上のFP8アテンションによる更なる高速化。

Blake Crosley
2 min read Disclaimer
TensorRT-LLM最適化：NVIDIAの推論スタックをマスターする

TensorRT-LLM最適化：NVIDIAの推論スタックをマスターする

2025年12月11日更新

2025年12月アップデート： TensorRT-LLMがH100上でFP8を使用し、10,000+出力トークン/秒、100ms未満のTTFTを達成。本番デプロイメントではネイティブPyTorchと比較して4倍のスループットを報告。LayerNorm、行列乗算、活性化関数を単一のCUDAカーネルに統合するカーネル融合。インフライトバッチングによるGPU使用率の最大化。Hopper/Blackwell上のFP8アテンションによる更なる高速化。

NVIDIAのTensorRT-LLMは、他の選択肢が追いつくのに苦労するほどの生の推論パフォーマンスを提供する。H100 GPU上でFP8精度を使用すると、このフレームワークはピークスループット時に毎秒10,000出力トークン以上を達成し、最初のトークンまでの時間は100ミリ秒未満となる。¹ 本番デプロイメントでは、ネイティブPyTorch推論と比較して最大4倍のスループット向上が報告されている。このパフォーマンスにはコストが伴う：TensorRT-LLMは、vLLMのようなユーザーフレンドリーな代替手段よりも多くの設定専門知識と長い最適化サイクルを必要とする。

NVIDIAハードウェアにコミットし、最適化にエンジニアリング時間を投資する意思のある組織にとって、TensorRT-LLMは高価なGPUインフラストラクチャから最大のパフォーマンスを引き出す。フレームワークのアーキテクチャ、量子化オプション、チューニングパラメータを理解することで、チームは優れたトークン経済性を通じてプレミアムハードウェア投資を正当化する推論システムを構築できる。

アーキテクチャとコア最適化

TensorRT-LLMはNVIDIAのTensorRT推論オプティマイザをベースに構築され、コンパイルフレームワークをTransformer固有の最適化で拡張している。ライブラリはモデル定義用のPython APIと、本番デプロイメント用のC++ランタイムコンポーネントを提供する。

カーネル融合： TensorRT-LLMは複数のTransformer演算を単一の最適化されたCUDAカーネルに統合する。LayerNorm、行列乗算、バイアス加算、活性化関数は、個別のカーネル起動やメモリ転送を必要とせず、一緒に実行される。融合によりカーネル起動オーバーヘッドが削減され、中間テンソルの実体化が排除される。²

カスタムアテンションカーネル： マルチヘッドおよびグループクエリアテンションの手動最適化された実装は、最大スループットのためにTensor Core命令を活用する。Flash Attentionの変種は、数値精度を維持しながらメモリ帯域幅要件を削減する。HopperおよびBlackwell GPU上のFP8アテンションカーネルは、追加の高速化を提供する。

インフライトバッチング： 従来の静的バッチングでは、バッチ内のすべてのリクエストが最長のシーケンスの完了を待つ必要がある。インフライトバッチングは、各生成ステップで実行中のバッチに新しいリクエストを追加し、コンテキストフェーズと生成フェーズを一緒に処理する。³ このアプローチは、個々のリクエストが完了しても計算ユニットをビジー状態に保つことでGPU使用率を最大化する。

ページドKVキャッシング： オペレーティングシステムの仮想メモリにインスパイアされたページドアテンションは、連続したメモリ領域を必要とせず、非連続ブロックでKVキャッシュを割り当てる。⁴ ブロックレベルの割り当てにより、共通のプレフィックスを持つリクエスト間でKVキャッシュを共有でき、内部フラグメンテーションによるメモリ浪費をほぼゼロに抑えられる。

パフォーマンス比較：TensorRT-LLM vs vLLM

両フレームワークとも本番LLM推論を対象としているが、アーキテクチャの違いにより異なるパフォーマンスプロファイルが生まれる：

指標 TensorRT-LLM vLLM
ピークスループット（Llama 70B、A100） 約700トークン/秒 約600-650トークン/秒
最初のトークンまでの時間 35-50ms 50-80ms
短いシーケンスのスループット優位性 1.34倍 ベースライン
長いシーケンスのTPOT優位性 2.72倍 ベースライン
セットアップの複雑さ 高（数週間） 低（数時間）

TensorRT-LLMはデフォルト設定でvLLMを一貫して上回り、短いシーケンスで1.34倍高いスループット、長いシーケンスで2.72倍優れた出力トークンあたりの時間を実現する。⁵ B200 GPUでは、TensorRT-LLMのBlackwellアーキテクチャに対するより深い最適化により、パフォーマンスギャップはさらに拡大する。

vLLMは開発者体験において優位性を持つ：⁶ - ドロップイン置換のためのOpenAI互換API - コンパイルステップなしのシンプルなデプロイメント - 合理的なデフォルトによる自動モデル最適化 - NVIDIA GPU以外のより広いハードウェアサポート

推奨事項： ハードウェア効率の最大化がエンジニアリング投資を正当化する場合はTensorRT-LLMをデプロイする。絶対的なパフォーマンスよりも開発速度が重要な小規模運用や、本番環境への迅速な移行が必要な場合はvLLMを選択する。

量子化戦略

TensorRT-LLMは、精度とパフォーマンスおよびメモリ効率のトレードオフのための豊富な量子化オプションをサポートしている。適切な量子化方法の選択は、バッチサイズ、精度要件、ターゲットハードウェアに依存する。

FP8量子化（最初に推奨）

FP8は、最小限の精度劣化でパフォーマンス向上の最良のバランスを提供する：⁷

python quantize.py \
    --model_dir $MODEL_PATH \
    --qformat fp8 \
    --kv_cache_dtype fp8 \
    --output_dir $OUTPUT_PATH

FP8量子化には、適切なスケーリング係数を決定するためのキャリブレーションが必要である。キャリブレーションプロセスは、活性化範囲を測定するために代表的なサンプルで推論を実行する：

from tensorrt_llm.quantization import QuantConfig, CalibConfig

quant_config = QuantConfig(
    quant_algo="fp8",
    kv_cache_quant_algo="fp8"
)

calib_config = CalibConfig(
    calib_dataset="cnn_dailymail",
    calib_batch_size=8,
    calib_num_samples=512
)

FP8は中程度のパフォーマンス向上と非常に低い精度への影響を提供し、キャリブレーションには数分しか必要としない。HopperおよびBlackwell GPUはハードウェアFP8サポートを提供する。Ada GPUは効率は低下するがFP8をサポートする。

メモリ制約のあるデプロイメント向けINT4 AWQ

メモリがモデルサイズを制限する場合、INT4 Activation-aware Weight Quantization（活性化を考慮した重み量子化）は、許容可能な精度を維持しながら重みを4ビットに圧縮する：⁸

python quantize.py \
    --model_dir $MODEL_PATH \
    --qformat int4_awq \
    --awq_block_size 64 \
    --tp_size 4 \
    --output_dir $OUTPUT_PATH

INT4 AWQは、推論がメモリバウンドになる小バッチシナリオ（バッチサイズ≤4）で優れている。重みの読み込み時間が計算を支配するため、積極的な重み圧縮は大幅な高速化を提供する。大きなバッチでは、計算密度が増加するにつれてINT4 AWQのパフォーマンス優位性は減少する。

バランスの取れた最適化のためのINT8 SmoothQuant

SmoothQuantは量子化の困難さを活性化から重みに移行させ、大幅な精度損失なしに効果的なINT8量子化を可能にする：

python quantize.py \
    --model_dir $MODEL_PATH \
    --qformat int8_sq \
    --kv_cache_dtype int8 \
    --output_dir $OUTPUT_PATH

INT8 SmoothQuantは中程度のパフォーマンス向上と中程度の精度への影響を提供する。組織はまずFP8を試し、FP8の結果が要件を満たさない場合はINT8 SQにフォールバックすべきである。

量子化選択フレームワーク

NVIDIAは以下の優先順位を推奨している：⁹

  1. FP8 - 最良のパフォーマンス/精度トレードオフ、Hopper/Blackwellが必要
  2. INT8 SmoothQuant - Ada GPUまたはFP8の精度が不十分な場合の良い代替手段
  3. INT4 AWQ/GPTQ - メモリ制約のあるシナリオでの最大圧縮

KVキャッシュについては特に、ほとんどの場合で精度への影響が低いため、HopperおよびAda GPUではINT8よりもFP8量子化が推奨される。

本番デプロイメント設定

最適なTensorRT-LLMデプロイメントには、ワークロード特性に基づいた複数のパラメータのチューニングが必要である：

エンジンビルド設定

trtllm-build \
    --checkpoint_dir $CHECKPOINT_PATH \
    --output_dir $ENGINE_PATH \
    --max_batch_size 256 \
    --max_num_tokens 8192 \
    --max_input_len 4096 \
    --max_seq_len 8192 \
    --gemm_plugin auto \
    --use_paged_context_fmha enable \
    --workers 8

max_batch_size： 最近のバージョンでのデフォルトは256。最大スループットを達成する本番デプロイメントでは、インフライトバッチング機能を十分に活用するために2048まで増加させることが多い。¹⁰

max_num_tokens： バッチイテレーションごとに処理される総トークン数を制御する。デフォルトの8192はスループットとメモリ消費のバランスを取る。メモリ制約のあるデプロイメントでは削減し、モニタリングしながら慎重に増加させる。

use_paged_context_fmha： 効率的なKVキャッシュ管理のためのページドアテンションを有効にする。インフライトバッチングを使用する場合は必須。この実装はKVキャッシュメモリを事前に割り当て、モデルの重みだけよりも約60%多くのVRAMを必要とする。¹¹

Triton Inference Serverとの統合

本番デプロイメントでは、通常TensorRT-LLMバックエンドを持つNVIDIA Triton Inference Serverを使用する：

model_repository/
└── llama-70b/
    ├── 1/
    │   └── model.py
    ├── config.pbtxt
    └── tensorrt_llm/
        └── 1/
            ├── config.json
            └── engine/

Tritonは、マルチモデルオーケストレーション、リクエストキューイング、メトリクス収集、Kubernetesネイティブスケーリングを提供する。ビルド済みNGCコンテナには、インフライトバッチングとページドKVキャッシュサポートが有効化されたTensorRT-LLMバックエンドが含まれている。

メモリ計画

デプロイメント前にメモリ要件を見積もる：

総VRAM = モデルの重み + KVキャッシュ + 活性化メモリ + ランタイムオーバーヘッド

モデルの重み（FP8）：パラメータ数 × 1バイト
モデルの重み（INT4）：パラメータ数 × 0.5バイト
KVキャッシュ：batch_size × seq_len × num_layers × 2 × hidden_dim × precision_bytes

FP8の70Bパラメータモデルは概算で以下を必要とする： - 重み：70GB - KVキャッシュ（バッチ256、seq 8192）：約120GB - 活性化 + オーバーヘッド：約30GB - 合計：約220GB（H100 80GB×3またはH200 141GB×2）

パフォーマンスチューニングワークフロー

体系的な最適化により、TensorRT-LLMデプロイメントから最大のパフォーマンスを引き出す：

フェーズ1：ベースライン測定

trtllm-benchを使用して迅速なパフォーマンス評価を行う：

python -m tensorrt_llm.bench \
    --model_dir $ENGINE_PATH \
    --input_len 512 \
    --output_len 256 \
    --batch_size 32 \
    --num_requests 1000

ベンチマークユーティリティは最適なエンジンパラメータを自動的に設定し、完全なTritonデプロイメントの複雑さなしにベースラインパフォーマンスを提供する。¹²

フェーズ2：量子化選択

精度要件に対してまずFP8をテストする。精度が許容閾値を超えて劣化した場合は、INT8 SQまたはINT4 AWQを評価する。パープレキシティ測定だけでなく、代表的なタスクで評価ベンチマークを実行する。

フェーズ3：バッチサイズ最適化

1からmax_batch_sizeまでのバッチサイズでスループットをプロファイルする。追加のバッチングで収穫逓減となるスループット曲線の変曲点を特定する。トラフィックスパイクに対応するため、このポイントより20-30%高くmax_batch_sizeを設定する。

フェーズ4：KVキャッシュチューニング

本番ワークロード中のKVキャッシュ使用率を監視する。使用率が一貫して80%を超える場合は、max_num_tokensを増加させるか、max_batch_sizeを減少させる。使用率が50%を下回る場合は、割り当てを減らしてより大きなバッチ用のメモリを解放する。

フェーズ5：継続的モニタリング

本番環境で主要なメトリクスを追跡する： - 毎秒トークン数（スループット） - 最初のトークンまでの時間（レイテンシ） - キュー深度（キャパシティ） - KVキャッシュ使用率（メモリ） - GPU使用率（効率）

高度な最適化

投機的デコーディング

TensorRT-LLMは、小さなドラフトモデルを使用してメインモデルで検証される複数のトークンを予測する投機的デコーディングをサポートしている。この技術は互換性のあるワークロードで1.5-2倍の高速化を提供する：

# エンジンビルドで投機的デコーディングを有効化
trtllm-build \
    --speculative_decoding_mode draft_tokens_external \
    --max_draft_len 5 \
    ...

投機的デコーディングは、スループットよりも完了までの時間が重要なレイテンシに敏感なアプリケーションに有益である。この最適化には、ドラフトモデルとターゲットモデルの両方をメモリに維持する必要がある。

マルチGPU構成

TensorRT-LLMは、分散推論のためにテンソル並列（TP）、パイプライン並列（PP）、エキスパート並列（EP）をサポートしている：

# 4ウェイテンソル並列
trtllm-build \
    --tp_size 4 \
    --pp_size 1 \
    ...

TPは各層をGPU間で分割し、各層境界でall-reduce操作を必要とする。PPはパイプラインステージで層をGPU間で分割する。推論では、TPは通常より良いレイテンシを提供し、PPは

[翻訳のためコンテンツは切り詰められています]

You Might Also Like

日本のAIインフラ：アジア最大の経済大国が目覚める

日本のAIインフラ：アジア最大の経済大国が目覚める

KVキャッシュ最適化：本番LLMのためのメモリ効率化

KVキャッシュ最適化：本番LLMのためのメモリ効率化

シンガポールと東南アジアがグローバルAIインフラの中心地として台頭

シンガポールと東南アジアがグローバルAIインフラの中心地として台頭

お見積り依頼_

プロジェクトについてお聞かせください。72時間以内にご回答いたします。

> TRANSMISSION_COMPLETE
✓

リクエストを受信しました_

お問い合わせありがとうございます。弊社チームがリクエストを確認し、72時間以内に回答いたします。

QUEUED FOR PROCESSING