Text Generation Inference（TGI）とは？メンテナンスモード後の採用判断とvLLM移行【2026年版】

Text Generation Inference（TGI）は、Hugging Faceが公開している大規模言語モデルのサービング基盤です。Dockerイメージを1本起動するだけで、連続バッチングとトークンストリーミングを備えた推論サーバーが立ち上がります。ただし2025年12月11日付でメンテナンスモードへ移り、GitHubリポジトリも2026年3月21日を最後にアーカイブされました。本記事では、TGIが何を引き受ける道具なのか、ランチャー引数で何を決めるのか、v3で入ったプレフィックスキャッシュがどこまで効くのかを整理したうえで、新規案件で選んでよいのか、既存環境をいつまで動かせるのかを実装と保守の観点で判断します。

まとめ：新規採用を避ける条件と既存TGIを動かし続ける判断

結論から書きます。これから推論基盤を新規に組む案件で、TGIを第一候補に据える理由は残っていません。開発元自身が公式ドキュメントの冒頭で移行先を名指ししており、機能追加もモデル対応の追随も止まっているためです。

新規の第一候補はvLLM、複雑なプロンプト制御やエージェント的な呼び出しが主体ならSGLangになります。ローカル1台での小規模な実行はllama.cppやMLXの担当領域。詳しい設計はvLLMの仕組みと導入手順の側にまとめました。

一方で、すでに本番で回っているTGIを今週中に止める必要はありません。アーカイブされたのはソースコードの受け入れ口であり、公開済みのDockerイメージもモデルの重みもそのまま動きます。移行の合図になるのは、対応していないモデルを載せる要件が出たとき、依存ライブラリの脆弱性対応が必要になったとき、GPU世代を入れ替えるときの3つ。この3つのどれかが視界に入った時点で、移行の期限を切ってください。

TGIの定義｜RustとPythonで組むLLM推論サーバーの中身

まず何を引き受ける道具なのか。公式ドキュメントの定義から確かめます。

Rust製ルーターとPythonシャードが分担する3層の実行構成

Hugging FaceはTGIを「大規模言語モデルをデプロイし提供するためのツールキット」と定義しています。実装はRustとPythonの2言語にまたがり、ライセンスはApache-2.0。対応モデルの例として、Llama・Falcon・StarCoder・BLOOM・GPT-NeoX・T5といった公開モデルが挙がります。

動くときの構成は3層です。入口にあるのがtext-generation-launcherという起動役で、これが引数を解釈して残りのプロセスを立ち上げる。次に来るのがRustで書かれたルーターで、HTTPリクエストの受け付け、トークン化による入力長の検証、バッチの組み立てを担当します。最後がPython側のシャードで、実際にモデルの重みを持ち推論を回す層。ルーターとシャードの間はgRPCで、既定ではUnixドメインソケットを介して通信します。

この分業が効くのは、リクエストの捌き方とモデルの計算を別の言語へ切り離せる点です。入力検証やキューイングのようにリクエスト数ぶん走る処理をRust側に置くため、Pythonの実行時オーバーヘッドが同時実行数の頭打ちになりません。テンソル並列で複数GPUに分ける場合、シャードは--num-shardの枚数だけ起動します。推論そのものの流れはLLM推論の仕組みと基盤の選び方で扱いました。

連続バッチングとページドアテンションが処理量を伸ばす実際の仕組み

スループット側の主役は連続バッチングです。到着したリクエストを固定の枠で待たせず、生成中のバッチへ随時合流させる方式。合流の判断は--waiting-served-ratio（既定0.3）と--max-waiting-tokens（既定20）の2つで、条件を満たすと実行中のバッチを一時停止して新規のプレフィルを挟みます。

メモリ側の主役がPaged Attentionで、KVキャッシュを固定長のブロックに切って管理する仕組み。リクエストごとに最大長ぶんの領域を予約する無駄がなくなります。加えてFlash Attentionにより、長い入力ほど中間結果の書き出しを抑えた経路が効く構造。キャッシュ側の役割はKVキャッシュの仕組みと推論への効き方に整理しました。

付随機能も本番向けに揃っています。OpenAI互換のメッセージAPI、SSEによるトークンストリーミング、Prometheusメトリクス（既定ポート9000）、OpenTelemetryによる分散トレーシング、スキーマを渡して構造化出力を強制するGuidance。--lora-adaptersで複数のLoRAアダプタを起動時に読み込み、リクエスト側の指定で切り替える構成も取れます。Hub側の資産を持ち込める前提はHugging Faceでできることと使い方で扱いました。

メンテナンスモード移行とリポジトリ凍結で変わった採用判断の前提

ここが本記事の主題です。告知の中身と時系列を、日付の粒度で押さえます。

2025年12月のモード移行と2026年3月のリポジトリ凍結

公式ドキュメントの先頭には警告枠でこう書かれています。「text-generation-inferenceはメンテナンスモードに入りました。今後は軽微なバグ修正・ドキュメント改善・軽い保守作業のプルリクエストのみを受け付けます」。Inference Endpoints側のTGIページは、移行日を2025年12月11日と明記しています。

最終リリースはv3.3.7で、公開は2025年12月19日。内容は取得画像サイズの上限指定の追加と、可視デバイス指定が「all」だったときのデバイス計算の修正という保守的なものでした。その後の変更は入っていません。

そしてGitHubリポジトリ自体が、2026年3月21日の最終pushをもってアーカイブ状態になりました。読み取り専用という意味で、プルリクエストもissueも受け付けません。

公式が指名した移行先と、マネージド環境における切り替え手順4段

移行先は公式が名指ししています。サーバー用途はvLLMとSGLang、ローカル実行はllama.cppやMLX。「TGIが始めた、推論エンジンをtransformersのモデル定義に依拠させる動きは下流のエンジンへ引き継がれた」という趣旨の説明が添えられ、設計思想ごと移った形です。

マネージド側のInference Endpointsでは、TGIをエンジンとして選ぶ画面自体はまだ残っています。ただし公式の推奨はvLLMかSGLangで、TGIで稼働中のエンドポイントには移行手順が4段で示されました。第1に同じモデルでvLLMをエンジンに選んだ新しいエンドポイントを作る、第2にテスト呼び出しで動作を確かめる、第3にトラフィックを新側へ寄せる、第4に旧エンドポイントを一時停止または削除する、という順序。

ここで押さえる制約が1つあります。既存のエンドポイントは推論エンジンを後から変更できません。作り直しが前提となるため、呼び出し側の設定を切り替える工数を移行計画に積みます。ハードウェアと設定値は流用できると案内されており、費用の見積もりは据え置きで組めます。

凍結後もTGIを動かし続けられる条件と、期限を切る判断の基準

止まったのは開発であって、稼働ではありません。公開済みのコンテナイメージは配布され続けますし、すでに動いている構成が明日壊れるわけでもない。慌てて移行しないという判断は、条件付きで成立します。

継続してよい条件は4つ。第1に、載せているモデルがv3.3.7の対応範囲に収まっていること。第2に、新機能への要求が業務側から出ていないこと。第3に、コンテナの依存ライブラリに脆弱性が出た場合、自前でイメージを再構築するか受け入れリスクを判断できる体制があること。第4に、当面GPU世代の入れ替え予定がないこと。

逆に、このどれかが崩れたら期限を切ります。とくに効くのが第3の条件で、上流の修正が入らない以上、基盤イメージの更新は自社の責任範囲へ移るためです。保守契約を巻いている受託案件なら、責任の所在を契約側にも反映させておくほうが後々もめません。

起動オプションの決め方｜ゼロコンフィグと手動指定を分ける境界

設定は引数の数が多く、どこから触るか迷いやすい部分です。v3以降は考え方が変わりました。

入力長と総トークン数とプレフィル上限が決めるメモリ予算の関係

v3で入ったゼロコンフィグは、上限系の引数を未指定のままにすると、起動時にハードウェアとモデルを見て自動で値を決める仕組みです。公式は「フラグを全部外すのが最良の性能になりやすい」と書いており、本番デプロイでも引数を持たせていないと明言しています。まずは何も指定せずに起動するのが、v3以降の出発点になります。

それでも手で決めたくなる場面があります。公式が挙げる例が分かりやすい。128kトークンのコンテキストを持つ70Bクラスのモデルを、そのコンテキスト3本ぶんしか載らないGPUで動かすと、同時3リクエストが上限になります。入力長を64kに落とせば6並列まで伸びる。ゼロコンフィグは1リクエストあたりの上限を最大化する判断であり、同時実行数を優先するなら人が切ります。

上限系の引数は3つの関係で覚えます。--max-input-tokensがプロンプト側の上限、--max-total-tokensがプロンプトと生成の合計で1リクエストのメモリ予算そのもの、--max-batch-prefill-tokensがプレフィルでまとめて流せるトークン数（既定は入力長プラス50）です。

表の最下段は運用要件に直結します。匿名の利用統計が既定で送信されるため、情報管理の要件がある案件では起動時に--usage-statsをoffへ倒してください。同時実行の上限超過は待機ではなく拒否になるので、呼び出し側に再試行の実装が要ります。

量子化方式とKVキャッシュ精度の指定で空きメモリを広げる手順

メモリが足りないときの手は2つあります。1つが重みの量子化で、--quantizeに方式を指定する。選べるのはawq・gptq・marlin・eetq・exl2・compressed-tensors・bitsandbytes系3種・fp8です。すでに量子化済みのモデルなら設定ファイルから方式が読まれるため、指定は不要になります。

方式ごとの癖も押さえます。GPTQやAWQの重みには高速なMarlinカーネルが自動で選ばれる一方、exl2はテンソル並列と併用できません。GPU枚数を増やす計画があるならAWQ側へ寄せるのが素直です。ビット幅と品質の関係はLLM量子化の方式と精度の落ち方で詳しく扱いました。

もう1つがKVキャッシュ側の精度で、--kv-cache-dtypeにfp8系の2種を指定できます。重みではなくキャッシュを縮める手なので、長いコンテキストを多数さばく構成ほど空きが効いてくる。なお--dtypeと--quantizeは同時に指定できません。

v3の性能主張とベンチ条件｜プレフィックスキャッシュが効く場面

TGI v3の公開時、Hugging Faceは「3倍のトークン量・長文で13倍」という数字を出しました。この主張は条件を外すと読み違えます。

長文プロンプトで13倍という主張の測定条件と再現のための手順

13倍という数字が出たのは、20万トークンぶんの長文プロンプトを20リクエスト投げるシナリオです。8基のH100で70Bモデルを動かし、2回目の走行でTGIが2秒、vLLMが27.5秒。公式が2回目を採用したのは、1回目ではどちらのエンジンもプレフィックスキャッシュが空で、実運用の姿から離れるという理由でした。

同じ表の1回目走行を見ると景色が変わります。8基H100の長文シナリオはTGIが12.1秒、vLLMが28.3秒。4基のL4で短文シナリオを回した1回目は、TGIが13.0秒に対しvLLMが12.6秒と逆転しています。つまり差の大半は、同じ前置きを繰り返し投げたときにキャッシュが当たるかどうかで説明できます。

メモリ量の主張も同じ読み方をします。24GBのL4単体で8Bモデルを動かしたとき、TGIは30kトークンを抱えられ、vLLMは約10kにとどまったという比較。差の一因は公式自身が説明していて、10万トークン級の入力では対数確率の計算用テンソルが25.6GBに達し、モデル本体の16GBを超えます。TGIはこれを既定で返さない設計にしてキャッシュへ回しました。--enable-prefill-logprobsで戻せますが、扱えるプロンプト長は縮みます。

そのうえで注意が要ります。この測定はv3公開時点のもので、比較対象のvLLMもその後に版を重ねました。前置きの共有率が低い業務なら、13倍という数字は自社で再現しません。

レプリカを増やすとキャッシュが外れる問題と負荷分散側の対処法

プレフィックスキャッシュには構成上の弱点があります。同じエンドポイントの背後に複数レプリカを置くと、利用者のリクエストが毎回同じレプリカへ届く保証がありません。前置きを持つのは特定のレプリカだけなので、振り分けが変わった瞬間に効果が消えます。

公式が挙げる緩和策はスティッキーセッションによる負荷分散です。ただし無条件に適用するなという但し書きが付きます。偏りでスケールアウトの意味が薄れるため、命中率を測って効果が確認できた構成だけに適用する順番が安全です。

KVキャッシュの容量不足も競合を招きます。多数のクエリが同じ領域を奪い合うため、対処は--max-total-tokensを絞って1件あたりの占有を下げるか、GPUを増やすかの二択。照合自体のオーバーヘッドは5〜6マイクロ秒と小さく、ここが遅さの原因にはなりません。

TGIからvLLMへ移す手順と起動オプションの対応関係を整理する

移行の実作業は、コンテナの差し替えと引数の写し替えが中心になります。

起動オプションの対応表とゼロコンフィグを前提にした移し替え方

TGI側で明示していた引数は、vLLM側の対応する引数へ読み替えます。名前は違っても、決めている対象はほぼ同じです。

ただし値をそのまま移すと詰まります。TGIは残りメモリからバッチ総量を推定する作りに対し、vLLMは起動時に指定割合をKVキャッシュ用として先取りする作りだからです。移行後は割合とモデル長の2つを実機で測り直してください。詰め方はvLLMのメモリ設計と並列化の考え方にまとめてあります。

API互換の差分と、並行稼働から切り替えるまでの実際の進め方

呼び出し側の改修は小さく済みます。どちらもOpenAI互換のメッセージAPIを備えており、ホスト名を差し替えるだけで動く構成が多い。ただし互換なのは主要な経路で、TGI固有の生成エンドポイントや透かし・best-ofといった独自寄りの機能を使っているなら、代替手段の有無を先に確かめます。

差分が出やすい箇所を4つ挙げます。第1にチャットテンプレートの適用結果で、設定が同じでも空白や改行の扱いに差が出る場合がある。第2に構造化出力の指定方法で、TGI側のGuidanceとvLLM側の制約付きデコードでは記法が違います。第3に上限超過時の挙動、第4にメトリクスの名前で、監視ダッシュボードは作り直しになります。

進め方は並行稼働から入ります。新旧を同時に立ち上げ、同じプロンプト集合を両方へ投げて出力と遅延を突き合わせる。合否の基準は、代表タスクでの出力品質、95パーセンタイル遅延、想定同時実行数での安定稼働の3つを事前に決めておきます。満たしたらトラフィックを段階的に寄せ、切り戻し用に旧環境を数日残してから落とす順序です。

新規案件でTGIを選んでよい条件と、避けておくべき3つの状況

ここまでの材料で判断を言い切ります。まず、TGIを新規に選んでよい場面は狭いながら存在します。

既存資産と検証期間から採用してよい場面を条件付きで切り分ける

採用してよいのは3つの条件が同時に立つときです。第1に、社内にTGIの運用実績があり、監視・デプロイ・障害対応の手順が既に整っていること。第2に、載せるモデルがv3.3.7の対応範囲に収まっており、今後1年で入れ替える計画がないこと。第3に、その環境の寿命が短いこと。具体的には、数か月で結論を出す検証や、期間の決まった実証実験がこれに当たります。

この3条件が揃う場面では、慣れた道具を使うほうが速い。既存の起動スクリプトと監視設定を流用でき、新しいエンジンの容量設計をやり直す工数も要りません。逆に、条件が1つでも欠けるなら、開発が止まった基盤を保守し続ける負担が初期の学習コストを上回ります。

新規案件で見送るべき3つの場面と、代わりに選ぶ移行先の決め方

見送るべき場面は3つに絞れます。1つ目が、新しく公開されたモデルを載せる要件がある案件。対応の追加は今後入らないため、動かない可能性を最初から抱えます。2つ目が、複数年の保守を約束する受託案件。上流の修正が止まった基盤の脆弱性対応を自社で背負う契約になり、見積もりに反映できない負債が残ります。3つ目が、GPU世代の入れ替えを見込む構成で、新しいハードウェア向けのカーネル対応が入らない以上、性能を引き出せません。

代わりの選び方は用途で決めます。多数の同時リクエストをGPUでさばくサービングならvLLM、プロンプトの分岐や制御が込み入った処理が主体ならSGLang、1台の端末やCPU環境で少数を回すならllama.cppやMLX。判断の分岐点は同時実行数とハードウェアの前提で、ここが決まればエンジンはほぼ一意に決まります。

移行を外部に頼む場合は、範囲の切り分けを先に合意してください。エンジンの差し替えだけを頼むのか、モデル選定と品質評価まで含めるのかで工数が桁で変わります。生成AI開発・AI受託開発のように、モデル選定から基盤構築と運用引き渡しまでを一体で扱える体制かを、見積もりの前に確認する順番が手戻りを減らします。

よくある質問

TGIはもう動かなくなるのですか？

動かなくなるわけではありません。アーカイブされたのはGitHubリポジトリで、公開済みのコンテナイメージは配布され続けます。ただし不具合が見つかっても修正版は出ないため、稼働を続けるなら脆弱性対応を自社で追う体制が前提です。

TGIとvLLMではどちらが速いのですか？

条件によります。v3公開時の公式ベンチでは、同じ長い前置きを繰り返し投げるシナリオの2回目走行でTGIが大差を付けた一方、キャッシュが効かない1回目や短いプロンプトでは差が小さく、一部の構成では逆転していました。自社のプロンプト分布と同時実行数で測り直すのが確実です。

マネージドのInference Endpointsは影響を受けますか？

エンジンとしてのTGIは選択肢に残っていますが、公式の推奨はvLLMかSGLangへ移りました。既存エンドポイントの推論エンジンは変更できないため、移行するなら同じモデルで新しいエンドポイントを作り、テストののちトラフィックを寄せ、旧側を停止または削除します。

匿名の利用統計は止められますか？

止められます。起動引数の--usage-statsにoffを渡すと収集を無効化でき、no-stackを選べばエラーの詳細を送らずクラッシュ事実だけを送る中間の設定になります。既定はonなので、閉域網や情報管理の要件がある案件では起動時に必ず指定してください。

ゼロコンフィグのまま本番へ出してよいですか？

多くの場合は問題ありません。ただし長いコンテキストのモデルでは、1件あたりの上限を最大化した結果として同時実行数が数本まで落ちる場合があります。業務で必要な入力長まで切り下げ、残りを自動決定に任せる形が折り合いを付けやすい構成です。

関連記事

• vLLMとは？PagedAttentionの仕組み・使い方とOllama・TensorRT-LLMとの違い
• LLM推論とは？仕組みと推論基盤・APIの選び方
• KVキャッシュとは？推論高速化の仕組みとメモリ設計
• LLM量子化とは？方式ごとの精度とメモリの落ち方
• SLMとは？小規模言語モデルとLLMの違いと使い分け
• Hugging Faceとは？できること・使い方・料金