速い用途と遅い用途を同じ入れ物に置くと、速いほうの待ちが62,968.2msになりました。
遅い用途を別の入れ物へ出せば0.0msです。同じ受け口を使うかどうかで決まります。
1つの単位に複数のAPIを置けます。ただし受け口を共有するので、遅いほうに引きずられます。
BentoMLでは、1つの単位に複数のAPIを置けます。公式はServiceの中の各APIは、Pythonの関数として指定する形で定義されると述べています。
置いた用途の速さが違うとどうなるのか。実際に流して数えました。
1つの入れ物に「速い用途（25ms）」と「遅い用途（900ms）」を置く
受け口は 4 本。速い用途は毎秒 20件で固定し、遅い用途の件数を変える
遅い用途の件数 速い用途の平均待ち 95%点 遅い用途だけ別にした場合の速い用途
0.2件/秒 0.0 ms 0.0 ms 0.0 ms（95%点 0.0 ms）
1件/秒 4.7 ms 5.9 ms 0.0 ms（95%点 0.0 ms）
2件/秒 52.8 ms 384.2 ms 0.0 ms（95%点 0.0 ms）
4件/秒 62968.2 ms 95547.9 ms 0.0 ms（95%点 0.0 ms）
遅い用途が毎秒0.2件なら、速い用途の待ちは0.0msです。同居しても気づきません。
毎秒4件になると62,968.2msです。63秒待たされます。速い用途の件数は変えていません。
毎秒2件では52.8msでした。そこから4件で1,200倍に跳ねます。
受け口4本に対し、遅い用途が毎秒4件×0.9秒で3.6本ぶんを占めるからです。速い用途に残るのは0.4本です。
右端を見ると、別の入れ物へ出せばどの行も0.0msです。分けるかどうかだけの差でした。
受け口が埋まった瞬間に、待ちが桁で跳ねる。
Each API within the Service is defined using the @bentoml.api decorator, specifying it as a Python function.原文BentoML 公式ドキュメント「Hello world」 この内容の有効期限2027-02-18
配置の単位はServiceです。分ける数がそのまま必要な枚数になり、余りが積み上がります。
BentoMLでは、Serviceが配置の単位です。公式はBentoMLにおいてServiceとは、配置でき大きさを変えられる単位であり、Pythonのクラスとして定義されると述べています。
分ける数で枚数がどう変わるのか。実際に数えて比べました。
4つの用途を載せる。1枚 16GB・1枚がさばけるのは毎秒 60件 用途 重み 毎秒の件数 分けた場合に必要な枚数 余る容量 余る処理力 要約 2.4 GB 6件 1枚 13.6 GB 54件 分類 0.9 GB 40件 1枚 15.1 GB 20件 埋め込み 1.3 GB 90件 2枚 30.7 GB 30件 翻訳 3.1 GB 2件 1枚 12.9 GB 58件 まとめ方 必要な枚数 使った容量 使った処理力 余りの割合 用途ごとに分ける 5枚 7.7/80 GB 138/300件 90.4% 1つにまとめる 3枚 7.7/48 GB 138/180件 84.0%
分けると5枚、まとめると3枚です。使う容量は同じ7.7GBで、変わったのは枚数だけでした。
翻訳は毎秒2件しか来ないのに1枚を占めます。12.9GBと58件が余ります。
余りの割合は90.4%と84.0%です。まとめても8割以上が余ります。1枚が大きすぎるためです。
つまり枚数を減らす手は、まとめるより小さい機材を選ぶほうが効きます。
ただし前の節で見たとおり、まとめると巻き添えが起きます。Kubernetesの記事で扱った同居の判断と同じ形です。
In BentoML, a Service is a deployable and scalable unit, defined as a Python class using the @bentoml.service decorator.原文BentoML 公式ドキュメント「Hello world」 この内容の有効期限2027-02-18
状態と一生を扱えます。入れ替えのときは、重みの読み込みがそのまま所要になります。
BentoMLのServiceは、状態とその一生を扱えます。公式は状態とその一生を管理でき、HTTPを通じて到達できる1つまたは複数のAPIを外へ出せると述べています。
入れ替えのときに何が効くのか。実際に計算して数えました。
重みを読み込む速さを 毎秒 900MB、それ以外の準備を 12秒として計算する
同じものを 6 本立てている場合の、入れ替え中に減る処理力を見る
重み 読み込み 起動まで 1本ずつ入れ替え 半分ずつ入れ替え 全部同時
0.5 GB 0.6秒 12.6秒 75秒 / 減 17% 25秒 / 減 50% 13秒 / 減 100%
2 GB 2.3秒 14.3秒 86秒 / 減 17% 29秒 / 減 50% 14秒 / 減 100%
8 GB 9.1秒 21.1秒 127秒 / 減 17% 42秒 / 減 50% 21秒 / 減 100%
30 GB 34.1秒 46.1秒 277秒 / 減 17% 92秒 / 減 50% 46秒 / 減 100%
0.5GBなら起動まで12.6秒で、そのうち読み込みは0.6秒だけです。準備の12秒が大半を占めます。
30GBだと読み込みが34.1秒になり、逆転します。ここから先は重みが効いてきます。
30GBを1本ずつ入れ替えると277秒、半分ずつなら92秒です。3倍の差があります。
そのかわり落ちる処理力が17%から50%になります。時間と余力の取り替えです。
3つの計測はいずれも手元で書いた模型で、実際のBentoMLを動かしたものではありません。1枚16GB・毎秒60件、読み込み毎秒900MB、準備12秒といった値はすべて置いたものです。受け口4本という前提も置いた値で、実際の設定によって巻き添えの起きる位置は動きます。用途ごとの重みと件数も想定にすぎません。ここで見せているのは、受け口が埋まった瞬間に待ちが桁で跳ねるという点と、まとめても余りは8割以上残るという点の2つです。
It can manage states and their lifecycle, and expose one or multiple APIs accessible through HTTP.原文BentoML 公式ドキュメント「Hello world」 この内容の有効期限2027-02-18
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る