TensorRT-LLMのPyTorch移行入門

先に結論

現行TensorRT-LLMでは、TensorRT engineを先にbuildする旧手順ではなく、対応するHugging Face checkpointをtrtllm-serveへ直接渡します。最初の成功は、小さな対応model、localhost、固定したrelease／container、単一GPUに絞り、/healthとChat APIの応答を確認することです。旧記事のconvert_checkpoint.pyやtrtllm-buildを現在の手順へ混ぜないでください。

確認日時: 2026年8月9日（Asia/Tokyo）
対象: TensorRT-LLMの2026年7月30日更新文書（commit d41ab33）とv1.3.0rc23 release列。v1.3.0rc21以降でlegacy TensorRT backendが削除された系統です。
検証区分: 公式資料を基にした机上調査・最短手順です。この制作環境にはNVIDIA GPUがなく、container、model download、起動、API応答を実行していません。
注意: v1.3.0rc23はpre-releaseです。本番では「latest」を追わず、組織が検証したreleaseまたはcontainer digestを固定してください。

始める前に旧手順を分ける

TensorRT-LLMの名前に「TensorRT」が残っていても、現在のLLM実行backendはPyTorchです。公式migration guideでは次が削除対象です。

旧経路	現行経路
`LLM(backend=“tensorrt”)`	`LLM(model=“<hf_model>“)`
`trtllm-build`／`trtllm-refit`／`trtllm-prune`	engine build工程なし
model別`convert_checkpoint.py`	checkpoint変換なし
`—backend tensorrt`	指定を省くか`—backend pytorch`

ただし「任意のcheckpointが無条件に動く」という意味ではありません。現行のSupported Modelsでarchitectureを確認し、modelごとのfeature matrix、GPU世代、quantization、known issueも照合します。

公式のLinux pip手順はUbuntu 24.04で検査され、CUDA Toolkit 13.1、wheelに合わせたPyTorch 2.10.0／CUDA 13.0などを案内しています。依存関係をhostへ混ぜたくない初回は、公式Quick Startが第一選択にするNGCのpre-built release containerを、tagまたはdigest固定で使う方が戻しやすい構成です。

最短手順：CheckpointからServeする

以下はTensorRT-LLMを導入済みの公式container内で行う最小例です。modelは公式Quick Startと同じ小型checkpointです。初回はAPIを外部公開せず、localhostだけで確認します。

trtllm-serve "TinyLlama/TinyLlama-1.1B-Chat-v1.0" \
  --host 127.0.0.1 \
  --port 8000

別terminalからhealth checkを行います。

curl --fail --silent http://127.0.0.1:8000/health

次に、OpenAI互換のChat endpointへ固定入力を1件送ります。

curl --fail --silent http://127.0.0.1:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "TinyLlama/TinyLlama-1.1B-Chat-v1.0",
    "messages": [{"role": "user", "content": "Reply with only: READY"}],
    "max_tokens": 8,
    "temperature": 0
  }'

成功確認は「期待した単語が出た」だけで終えません。

server processが異常終了せず、/healthが成功する
JSONにchoicesまたはAPI仕様どおりのerrorが返り、HTMLのproxy errorではない
requestのmodelが起動時のcheckpointと一致する
起動に使ったTensorRT-LLM release／commit、container digest、GPU、driver、CUDA、model revisionを記録する

実務modelへ進む前に、trtllm-serveの公式CLI文書とmodel固有deployment guideを読み、tp_size、max_seq_len、KV cache、quantizationを一つずつ追加します。

つまずきやすい点と戻し方

trtllm-buildが見つからない

現在のmigration guideでは削除済みです。古いblogやscriptからcommandだけを復活させず、そのscriptを停止して、checkpointを直接trtllm-serveへ渡す経路へ置き換えます。旧engine artifactは消さず、どの旧releaseで作ったものかを記録して隔離します。

modelが未対応または起動時に失敗する

model名だけで判断せず、architectureとfeature matrixを確認します。未掲載model、Untestedのfeature、release noteのknown issueに該当する場合は、flagを推測で増やさず、公式deployment guideがある対応modelへ戻します。—trust_remote_codeを理由なく有効にしないでください。

GPU memory不足やwarm-up失敗

大きなmodelへ進まず、小型model、単一GPU、短いmax_seq_lenへ戻してserver自体の成立を確認します。その後にmodel、quantization、parallelismを一つずつ変えます。旧engineのmemory値やthroughputを現行PyTorch backendの期待値として流用しません。

APIは動くが外部から到達できない

最初はそれが安全な状態です。公開が必要なら、認証、TLS、rate limit、request size、監査logを持つgatewayを別に設計し、直接bindを広げる前に組織のnetwork境界で検証します。OpenAI互換はendpoint形状の互換であり、既存clientとの完全な挙動一致を保証しません。運用設計はvLLM本番APIサーバー運用の観測項目も参考にできますが、flagはTensorRT-LLM公式文書へ合わせてください。

さらに深く理解する

TensorRT-LLM backend移行の検証設計では、旧engine環境と現行PyTorch環境を、API契約、model対応、正しさ、latency、throughput、memory、観測性、rollbackで比較します。

参考資料

TensorRT-LLM Migration Guide: TensorRT Backend Removed（2026年7月30日更新、2026年8月9日確認）
TensorRT-LLM Quick Start Guide（commit d41ab33、2026年7月30日更新、2026年8月9日確認）
TensorRT-LLM trtllm-serve（commit d41ab33、2026年7月30日更新、2026年8月9日確認）
TensorRT-LLM Releases（v1.3.0rc21〜rc23、2026年8月9日確認）