合計の上限の9割まで使うと1,297,187件さばけました。上限ちょうどにすると721,800件です。
外れた宛先の分が残りへ寄り、そこも上限を超えます。連鎖して崩れます。
上限を超えた宛先は外れます。外れた分が残りへ寄るので、上限の手前で崩れます。
LiteLLMは、上限を超えた宛先を外します。公式は1分あたりや1トークンあたりの上限を超えた宛先を除くと述べています。
外れた分は残りへ寄ります。どこで崩れるのか実際に流して数えました。
宛先 4か所・1か所あたり毎分 600件まで。合計の上限は 毎分 2400件
600分ぶん。上限に達した宛先は次の1分だけ外す
合計に対する負荷 外れた宛先のある分 全部外れた分 さばけた件数 取りこぼし
40% 0分 0分 577,171件 0件
70% 0分 0分 1,009,186件 0件
90% 0分 0分 1,297,187件 0件
100% 599分 0分 721,800件 718,810件
120% 300分 300分 720,000件 1,008,575件
9割までは外れる宛先が0分で、取りこぼしもありません。1,297,187件をさばけています。
上限ちょうどにすると、600分のうち599分で外れた宛先が出ます。さばけた件数は721,800件まで落ちました。
1か所が外れると、その分の負荷が残り3か所へ寄ります。寄った先も上限を超えて外れます。
120%では300分が「全部外れた」状態でした。1件も通らない分が半分あります。
だから余力は9割ではなく、もっと手前に置くことになります。同じ形はレート制限の記事でも扱いました。
上限の手前までは順調で、届いた瞬間に崩れる。
Filters out deployment if tpm/rpm limit exceeded原文LiteLLM 公式ドキュメント「Router - Load Balancing」 この内容の有効期限2027-02-18
公式はでたらめに配る方式を勧めています。ただし手元の計測では、待ちがいちばん長く出ました。
LiteLLMは、既定の割り振り方を勧めています。公式は本番での最良の性能のために、simple-shuffle（既定）を使うことを勧めると述べています。
待ちの上ではどうなるのか。3つの方式を実際に流して比べました。
宛先 4か所・1800秒ぶん・毎秒 約24件。処理は平均 140ms でばらつく 割り振り方を変えて、待ちと宛先ごとの偏りを見る 割り振り方 平均の待ち 95%点 いちばん多い宛先 いちばん少ない宛先 順繰り 424.0 ms 1521.4 ms 10,762件 10,761件 でたらめ 720.4 ms 2455.1 ms 10,925件 10,579件 いちばん空いている 152.1 ms 606.3 ms 10,904件 10,669件
空きを見て配ると平均152.1msです。でたらめに配る720.4msの4.7分の1でした。
件数の偏りはどれも小さく、10,579件から10,925件の範囲です。差が出たのは待ちのほうでした。
この計測は1つの手元で全部の状態が見える前提です。宛先の空き具合を、遅れなく知っています。
実際には呼び出す側が複数に分かれます。空き具合を共有する仕組みが要り、その分が費用になります。公式も同じ箇所で、この方式は割り振りを決めるときの上乗せが最小だと説明しています。
つまりこの表が示すのは、状態を正確に知れるなら空きを見るほうが速いということです。知れない場合の比較にはなっていません。
We recommend using simple-shuffle (default) for best performance in production.原文LiteLLM 公式ドキュメント「Router - Load Balancing」 この内容の有効期限2027-02-18
失敗した要求をやり直せます。費用の上乗せは小さく、残る失敗は大きく減ります。
LiteLLMは、失敗した要求をやり直します。公式は非同期と同期の両方の関数について、失敗した要求のやり直しに対応していると述べています。
やり直しの費用と効き目を実際に回して数えました。
200,000 件。失敗したらやり直す。何回まで試すかを変える やり直しても料金は毎回かかる。呼び出し回数が何倍になるかを見る 失敗する割合 1回まで 2回まで 3回まで 5回まで 0.1% 1.000倍 / 残188件 1.001倍 / 残0件 1.001倍 / 残0件 1.001倍 / 残0件 1.0% 1.000倍 / 残1998件 1.010倍 / 残20件 1.010倍 / 残0件 1.010倍 / 残0件 5.0% 1.000倍 / 残10000件 1.050倍 / 残491件 1.053倍 / 残28件 1.053倍 / 残1件 20.0% 1.000倍 / 残39909件 1.202倍 / 残7986件 1.240倍 / 残1590件 1.248倍 / 残62件
20%が失敗する条件でも、5回まで試して呼び出しは1.248倍です。残る失敗は39,909件から62件になります。
費用は24.8%増、失敗は644分の1です。効き目のほうがずっと大きく出ました。
この計測は、失敗が互いに関係なく起きると置いています。上限に達したことによる失敗は、やり直しても同じように失敗します。
最初の節で見たとおり、上限に達した宛先は外れます。やり直す前に、別の宛先へ回すかどうかが先になります。
3つの計測はいずれも手元で書いた模型で、実際のLiteLLMを動かしたものではありません。宛先4か所・毎分600件といった値は置いたものです。外した宛先を次の1分だけ戻すという扱いも、実際の待ち時間とは違います。割り振り方の比較は、宛先の空き具合を遅れなく知れる前提での計算で、複数の呼び出し元がある場合は成り立ちません。ここで見せているのは、上限ちょうどまで使うと連鎖して崩れるという点と、やり直しの費用は小さく効き目は大きいという点の2つです。
For both async + sync functions, we support retrying failed requests.原文LiteLLM 公式ドキュメント「Router - Load Balancing」 この内容の有効期限2027-02-18
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る