TensorRT-LLM backend移行の検証設計
CHATGPT / AIChatGPTなどの生成AIを活用して運営・記事制作・更新を行っています。制作方針
TensorRT-LLMの旧engine build経路からPyTorch backendへ移る際に、release、model、API入力、GPU条件を固定し、正しさ、latency、throughput、memory、観測性、rollbackを比較する机上検証計画です。
先に結論
TensorRT-LLMのbackend移行は、trtllm-buildを削るだけのcommand置換ではありません。旧engine artifactで成立していたmodel support、quantization、API契約、warm-up、memory、性能、metricsを現行PyTorch backendで再測定し、同じSLOを満たすかを独立に判定します。現行release列はpre-releaseでknown issueも多いため、移行先をcommit／container digestで固定し、旧環境を読み取り専用のrollback候補として残したblue/green検証が安全です。
確認日時: 2026年8月9日（Asia/Tokyo）
対象version: legacy TensorRT backend削除後のv1.3.0rc21（commit1662a87）以降。現行文書とv1.3.0rc23はcommitd41ab33を基準に確認。
検証区分: 公式migration guide、CLI、supported model matrix、release noteによる机上調査・測定計画です。実測値、架空log、性能の優劣は示しません。
適用外: 特定modelの最適parallelism、未掲載architectureの対応保証、旧engineとPyTorchの数値互換、Triton Inference Server全体の移行、production rolloutの完了判定。
変更面をInventoryへ落とす
公式migration guideで明示された削除面は、Pythonのbackend=“tensorrt”、TrtLlmArgs、_tensorrt_engine.LLM、trtllm-build／refit／prune、model別checkpoint conversion、CLIの—backend tensorrt、TensorRT pip dependencyです。current pathはHugging Face checkpointをPyTorch backendへ直接loadします。
移行前にrepository、container、deployment manifestから次を抽出します。
| 面 | 旧環境で記録するもの | 現行環境で置き換えるもの |
|---|---|---|
| artifact | engine directory、build command、checkpoint revision、hash | HF／Model Optimizer checkpoint revision、hash、loader設定 |
| runtime | TensorRT-LLM release、TensorRT、CUDA、driver、GPU | TensorRT-LLM commit／container digest、PyTorch、CUDA、driver、GPU |
| API | endpoint、model名、chat template、sampling default、error形式 | 同じrequest corpusでresponse schemaと意味を再検証 |
| capacity | max batch、max sequence、parallelism、KV cache | 同じ上限から開始し、PyTorch側で一変数ずつ調整 |
| operation | engine build時間、startup、warm-up、metrics、rollback | checkpoint load、startup、warm-up、/health、/metrics、rollback |
旧設定にtrtllm-buildがあること自体を失敗とせず、移行inventoryの入力として凍結します。削除と同時に比較根拠を失わないよう、旧command、artifact hash、作成releaseを保存し、新環境の設定へ混ぜないことが重要です。
比較条件：固定値と変数を分ける
同じhardwareでbackendだけを比較できるよう、最初のrunでは次を固定します。
- GPU型番・台数、driver、power mode、MIG、他process、NUMA／CPU affinity
- model family、checkpoint revision、tokenizer、chat template、quantization、入力token列
- prompt／output長のbucket、sampling、stop条件、concurrency、request到着分布
- warm-up回数、測定時間、timeout、client、network経路、error判定
- 品質確認用の固定prompt corpusと期待schema
変数は一度に一つです。まず旧engineと現行PyTorchのdefault構成を別環境で測り、その後にtp_size、pp_size、ep_size、max_seq_len、KV cache、CUDA graph、quantizationを一項目ずつ変えます。旧engineで作ったtacticやbuild profileをPyTorch側へ効いている前提で扱いません。
現行supported model matrixにはfeature単位でYes、No、Untestedが並びます。model名が表にあるだけで、disaggregated serving、KV cache reuse、guided decoding、multimodalなど全機能が使えるとは限りません。release noteのknown issueも同じcommitへ固定して判定表へ添付します。
観測方法と合格gate
1. 正しさとAPI契約
性能より先に、HTTP status、response schema、stream終端、usage、model名、stop reason、error分類、timeout、cancelを比較します。生成内容は完全一致を要求せず、task別の正解条件、JSON schema、禁止出力、tool call構造を事前定義します。旧と新でchat templateやsampling defaultが変わる場合は、backend差と入力差を分けます。
2. latencyとthroughput
client側でqueueを含むend-to-end latency、TTFT、ITL、完了時間、timeout率を採り、server側のiteration統計と照合します。concurrencyとprompt／output長を混ぜた平均だけでなく、bucket別の中央値とtailを残します。throughputは成功したinput／output tokenとrequest数を別々に記録し、errorやcancelを分母から隠しません。
3. memoryとstartup
weight load前後、warm-up、steady state、peak、OOM、recoveryを分けます。GPU memoryだけでなくhost memory、model download／local cache、startup時間、最初のhealth成功までを記録します。旧engine build時間と現行checkpoint load時間は工程が異なるため、一つの「起動時間」に合算しません。
4. 観測性
公式CLIは/health、/metrics、/versionを提供しますが、PyTorch backendのmetricsはbetaで、旧TensorRT backendより網羅的でなく、CPU memoryなど未提供のfieldがあります。またenable_iter_perf_statsは構成により性能へ少し影響し得ます。旧dashboardをそのまま合格条件にせず、欠落field、label変更、scrape cost、alertの代替sourceを整理します。
最低限のpromotion gateは次です。
- 固定corpusの正しさとAPI schemaが許容範囲内
- crash、OOM、hang、timeout率が運用上限内
- latency、throughput、memoryが事前SLO内
- health、metrics、log、versionから障害を検知できる
- rollback手順をtrafficなしのrehearsalで完了できる
数値thresholdは本稿で捏造せず、既存SLOとcapacity planから各運用者が設定します。
Rolloutとrollback
旧releaseを同じenvironment内でdowngradeする方式は、dependencyとartifactを混ぜます。代わりに、旧engine serviceと新PyTorch serviceを別container image／別artifact storeで保持し、request mirrorまたは固定replayで比較します。model weight、tokenizer、prompt corpusへ同じhashを付け、結果はservice versionと一緒に保存します。
promotionはcanaryの前にshadowで行い、次の順に進めます。
- trafficなしでstartup、health、固定corpus、shutdownを検査
- production trafficの機密情報を除いたreplayでAPI差とcapacityを評価
- 小さいcanaryでtimeout、OOM、quality、metrics欠落を監視
- 合格後だけtraffic比率を上げ、旧serviceは即時切替できる状態で保持
- rollback条件を一つでも満たしたら新規requestを旧serviceへ戻し、新環境のartifactとlogを保存して停止
rollback条件にはcrash loop、health失敗、schema破壊、quality gate失敗、SLO超過、監視不能を含めます。旧v1.3.0rc20以前のengine backendを長期運用の安全策とみなさず、移行期間だけ隔離して維持し、security／compatibility riskを別途評価します。
Trade-offと適用外
build工程がなくなることでdeployment artifactは単純になりますが、性能調整やmodel supportの確認が不要になるわけではありません。checkpointを直接loadできる代わりに、loader、PyTorch compilation、attention backend、CUDA graph、quantization、model固有featureの組合せがruntime判断へ移ります。
また、v1.3.0rc21以降のrelease noteには特定model／GPU／multi-GPU構成のaccuracy failure、OOM、hangなどknown issueが記録されています。これらはすべての構成が危険という意味ではなく、該当条件を合格matrixから除外または個別再現すべき根拠です。異なるGPU、model、quantizationへ本稿の判断を一般化しません。
最初の起動手順が必要な場合は、TensorRT-LLMのPyTorch移行入門から確認してください。OpenAI互換APIのproduction観測項目はvLLM本番APIサーバー運用とも比較できますが、implementation固有のmetricsとflagは混用しません。
参考資料
- TensorRT-LLM Migration Guide: TensorRT Backend Removed（2026年7月30日更新、2026年8月9日確認）
- TensorRT-LLM Supported Models（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 commit
1662a87、v1.3.0rc23 commitd41ab33、2026年8月9日確認）
