UbuntuでTensorRT-LLMを使用してLlama-3を高速化：インストールから本番環境へのデプロイまで – ITFROMZERO

Table of Contents

実務におけるレイテンシ課題の解決

私たちのチームのLlama-3チャットボットシステムは、ピーク時に過負荷に陥ることがありました。A100クラスターでvLLMを稼働させていたにもかかわらず、ユーザー数が増えると処理速度（TPS）が急落したのです。レスポンスごとにレイテンシが10秒に達し、ユーザー体験は最悪でした。調査の結果、ボトルネックはNVIDIA GPUの専用命令セットを十分に活用できていないことにあると分かりました。

大規模言語モデル（LLM）を実運用に投入するには、単にインストールして実行する（プラグアンドプレイ）だけでは不十分です。GPUのコンパイル層に深く踏み込む必要があります. そこで登場するのがTensorRT-LLMです。レスポンス速度を秒間5〜10トークンから50トークン以上に引き上げたいなら、これが現在最も有力なソリューションです。

なぜTensorRT-LLMは圧倒的に速いのか？

TensorRT-LLMは、Transformersのような単なるモデル読み込みライブラリではありません。ニューラルネットワークのアーキテクチャ全体を、各GPUチップに最適化されたエンジンへとコンパイルするコンパイラの役割を果たします。理論だけでなく、高いパフォーマンスを実現する3つの主要技術を見てみましょう。

インフライトバッチ処理（In-flight Batching）: バッチ全体の終了を待つのではなく、古いリクエストが完了した直後に新しいリクエストを処理に投入できる技術です。
量子化（Quantization – FP8/INT8）: モデルのサイズを縮小し、H100やA100などのカードでより高速に実行できるようにします。これにより、精度をほぼ維持したままVRAMを最大40%節約できます。
カーネル融合（Kernel Fusion）: 何百もの断片的な行列演算を1つのブロックに統合します。これにより、メモリへのアクセス時間（VRAMスループット）を大幅に削減できます。

標準的な環境構築

教訓として、ホストマシンに直接インストールするのは避けるべきです。TensorRT-LLMはライブラリのバージョンに非常に敏感だからです。CUDAのパッチバージョンが一つ違うだけで、システムはエラーを吐きます。Dockerが最も安全な選択肢です。以下は、本番環境で安定稼働を確認した構成です。

OS: Ubuntu 22.04 LTS
ハードウェア: NVIDIA Ampere以降（RTX 3090, 4090, A10, A100…）
ドライバー: バージョン535以降

まず、DockerがGPUと通信できるようにNVIDIA Container Toolkitをインストールします。

curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
    sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
    sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit
sudo systemctl restart docker

3ステップのデプロイフロー

1. チェックポイントの準備

HuggingFaceの.safetensorsファイルを直接エンジンに読み込むことはできません。TensorRT-LLMの中間フォーマットに変換する必要があります. 互換性を確保するため、NVIDIA（NGC）の公式Dockerイメージを使用します。

# ソースコードを取得してコンテナに入る
git clone https://github.com/NVIDIA/TensorRT-LLM.git
cd TensorRT-LLM

# Llama-3-8Bの重みを変換
python3 examples/llama/convert_checkpoint.py \
    --model_dir ./llama-3-8b-hf \
    --output_dir ./llama-3-8b-ckpt \
    --dtype float16

2. 最適化エンジンのビルド

これが最も重要なフェーズです。trtllm-buildコマンドは、現在のハードウェアを分析し、最適な実行ファイルを生成します。max_batch_sizeの設定には注意してください。値を高く設定しすぎると、リクエストがない時でもVRAMが占有されてしまいます。

trtllm-build --checkpoint_dir ./llama-3-8b-ckpt \
    --output_dir ./llama-3-8b-engine \
    --gemm_plugin float16 \
    --max_batch_size 4 \
    --max_input_len 2048

3. Triton Inference Serverによる運用

数千人のユーザーに安定したAPIを提供するために、Pythonスクリプトを手動で実行するのではなく、常にTriton Serverを使用しています。Tritonはキュー（queue）の管理とGPUリソースの分配を非常に効率的に行います。サーバーがエンジンを認識できるように、NVIDIAのmodel_repository構成に従ってディレクトリを整理する必要があります。

docker run --gpus all --rm -p 8000:8000 \
    -v $(pwd)/model_repository:/models \
    nvcr.io/nvidia/tritonserver:24.03-trtllm-py3 \
    tritonserver --model-repository=/models

メモリ不足（OOM）エラーを避けるための注意点

実際の運用中、KVキャッシュがメモリを占有しすぎることでOOMエラーが発生しがちです。RTX 3090のようにVRAMが24GBしかないカードを使用している場合は、Weight-Only Quantizationの利用を検討してください。この手法により、Llama-3-8Bモデルを15GBから約8GBに圧縮できます。これにより、長い対話のためにmax_input_lenを増やす余裕が生まれます。

また、常にgenai-perfツールでパフォーマンスを確認してください。私たちのチームのテストでは、gemm_pluginを有効にすることで、デフォルト設定よりも行列計算が25%高速化されました。小さな最適化フラグを無視しないでください。それらの積み重ねが、スループットに大きな差を生みます。

おわりに

TensorRT-LLMの導入には、環境構築やパラメータ設定において細心の注意が必要です。しかし、その見返りとして、高い負荷に耐え、極めて高速にレスポンスを返すシステムが得られます。エンドユーザー向けのAI製品を開発しているなら、インフラコストの削減とサービス品質向上のために、このような深層レイヤーでの最適化は必須のステップと言えるでしょう。