公式は保守のみの状態へ移ったと告知し、別の実行基盤を勧めています。
乗り換えの作業量は呼び出し箇所の数で決まります。18か所が、層を挟むかどうかの分かれ目でした。
公式が保守のみへ移ったと告知しています。乗り換えの作業量は、呼び出し箇所の数で決まります。
Text Generation Inference（TGI）は、保守のみの状態へ移りました。公式はtext-generation-inferenceは現在、保守のみの状態にあると述べています。
同じ告知の中で、別の実行基盤が勧められています。では乗り換えにどれだけかかるのか実際に数えて比べました。
呼び出し箇所を数え、1か所 18分で直す場合と、間に挟む層を作る場合を比べる
間に挟む層は作るのに 240分、1か所の差し替えは 4分として計算した
呼び出し箇所 そのまま直す 層を挟んで直す 差 層を挟むほうが得になるか
12か所 3.6時間 4.8時間 -1.2時間 損
60か所 18.0時間 8.0時間 10.0時間 得
300か所 90.0時間 24.0時間 66.0時間 得
1,200か所 360.0時間 84.0時間 276.0時間 得
分かれ目は 18 か所。これより少なければ、層を挟まず直したほうが早い。
12か所なら、そのまま直すほうが1.2時間早く終わります。層を作る手間が回収できません。
300か所では66.0時間の差です。90.0時間が24.0時間になりました。
この計算は1回の乗り換えだけを見ています。2回目があるなら、層を挟んだ側は層の中だけで済みます。
だから分かれ目の18か所は、1回で終わる前提での値です。回数が増えれば、層を挟む側がさらに有利になります。
呼び先を切り替えられる形にしておく話はLiteLLMの記事でも扱いました。
18か所を境に、層を挟む側が逆転する。
text-generation-inference is now in maintenance mode.原文Hugging Face 公式ドキュメント「Text Generation Inference」 この内容の有効期限2027-02-18
複数の機材へ分けられます。載せるための手ですが、分けた分だけ持ち寄りが要ります。
Text Generation Inferenceは、複数の機材へ分けて動かせます。公式は複数のGPUでより速く推論するためのテンソル並列を挙げています。
分けると何が要るのか。実際に計算して数えました。
重み 140GB のモデルを、1枚 80GB の機材へ分けて載せる
層 80・隠れ次元 8192・16bit。1トークン出すたびに層ごとの持ち寄りが要る
分割数 1枚あたりの重み 載るか 1トークンの持ち寄り 1000トークンでの持ち寄り 重み以外に残る容量
1枚 140.0 GB 載らない 0.00 MB 0.00 GB —
2枚 70.0 GB 載る 1.25 MB 1.22 GB 10.0 GB
4枚 35.0 GB 載る 1.88 MB 1.83 GB 45.0 GB
8枚 17.5 GB 載る 2.19 MB 2.14 GB 62.5 GB
1枚では140GBが載りません。2枚に分けて70.0GBになり、初めて載ります。
そのとき1000トークンあたり1.22GBの持ち寄りが発生します。分けなければ0だったものです。
8枚まで増やしても、持ち寄りは2.14GBです。2枚の1.22GBから1.75倍にしかなりません。
一方で重み以外に残る容量は10.0GBから62.5GBへ6.25倍になります。文脈に使える分が増えます。
つまり分割数を増やす判断は、持ち寄りより文脈の余裕で決まることになります。
Tensor Parallelism for faster inference on multiple GPUs原文Hugging Face 公式ドキュメント「Text Generation Inference」 この内容の有効期限2027-02-18
入ってきた要求を続けて詰めます。効くのは、出力の長さがばらついている場合だけです。
Text Generation Inferenceは、要求を続けて詰めます。公式は全体の処理量を増やすための、入ってくる要求の連続的な詰め合わせを挙げています。
どんなときに効くのか。実際に流して比べました。
依頼 600件・同時に処理できる数 8・1トークン 8ミリ秒 出力の長さ: 85%は40〜200トークン、15%は400〜1000トークン 詰め方 平均の待ち時間 p95 最大 全体の所要 1秒あたり まとめて始めて終わる 151.36秒 260.13秒 272.69秒 326.4秒 1.84件 空いた枠から入れる 34.62秒 60.26秒 66.79秒 120.3秒 4.99件 出力の長さがそろっている場合（全員150トークン） 詰め方 平均の待ち時間 全体の所要 まとめて始めて終わる 19.67秒 91.0秒 空いた枠から入れる 19.38秒 91.0秒
長さがばらついていると、平均の待ちが151.36秒から34.62秒になります。4.4分の1です。
全員150トークンにそろえると、19.67秒と19.38秒でほぼ同じでした。
効く理由は、長い1件が枠を占めたまま短い依頼が待つ状況を解消できるからです。
だから導入の前に、出力の長さがどれだけばらついているかを測ることになります。そろっていれば得るものがありません。
3つの計測はいずれも手元で書いた模型で、実際のTGIを動かしたものではありません。1か所18分・層の作成240分といった工数は置いた値で、実際の作業量とは違います。持ち寄りの量も層ごとに2回という単純な式からの計算で、実装によって変わります。1トークン8ミリ秒も置いた値です。ここで見せているのは、乗り換えの判断が呼び出し箇所の数で決まるという点と、詰め方の工夫は長さがばらついていなければ効かないという点の2つです。
Continuous batching of incoming requests for increased total throughput原文Hugging Face 公式ドキュメント「Text Generation Inference」 この内容の有効期限2027-02-18
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る