-
Notifications
You must be signed in to change notification settings - Fork 205
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AWSでの速度(金額あたりの処理数)を測定したい #434
Comments
構成LambdaバックエンドのAPI Gateway が一般的な構成になるかと思います。 全体構成は
になります。 速度計測バイナリダウンロード云々は「cold start での速度バラツキ」でしょうか? その他GPU推論?(※私が現在のVoiceVox開発状況をフォローできてない & AWSをゴリゴリ使ってたのが2年ほど前なので、頓珍漢な内容でしたらすみません) 合成はGPUで行なう予定でしょうか? 金額AWSの料金は転送量が意外と重いです。 |
ありがとうございます!! 最終的にはAPI Gatewayを挟む構成にすると良さそうに思いました!! 同時実行オプションや転送料金も勉強になります!! ご助言、助かります🙇🙇🙇 |
確かに、計測目的の最短ステップはLambdaオンリーですね。 |
おおなるほど!!たしかにコンソールから叩いちゃうのも手っ取り早い気がしました。 そういえば答えられていなかったのですが、CPUでの利用を想定していました。 |
LambdaはAPI Gatewayを挟まなくても直接外に出せるようになったので、課金的にそちらのほうがいいかと。 AWSはトラフィック課金もあるので、さくらのクラウドでIaaSではじめると固定費で運用できると思います。 |
API GateWayを置くかどうかは公開範囲によるとして、バックエンドに関しての話をします。 私が予想するコード順序としては
という形にする必要があります。 なお、バイナリを取得してwebサーバーを起動する形にすると結構な頻度でそのサーバー起動のオーバーヘッドがランダムにLambdaのレスポンス時間に加算されますので、使う側からは速度的に非常に不安定に感じるでしょう。(Lambdaはイベント実行中に次のイベントが来た場合、順次新しいインスタンスを作成するので) 個人的なおすすめはSageMakerのサーバーレス推論機能を使用するのが良いと思います。 SageMakerサーバーレス推論公式案内ページ SageMakerを触る必要がありますが、ボイボエンジン側のコードの推論部分をラップする形にすれば使えるんじゃないかと思います。(私は実際にSDKを使って組んだことはないのですが・・・) EC2インスタンスを立てたりすることと金額的に比べてLambdaを選びたい、という場合は確かに金額的に良い結果になると思いますが、レスポンス時間まで考えると少し現実味が薄いかもしれません。 |
横から失礼いたします。
同意です。 どうにかして全体のサイズを250MB以下に抑えられるなら、Lambda Layerであらかじめインストールしておくこともできますが、その辺実現性が分からないです。(キャラクター毎の部分であるVOICEVOX コアライブラリもサイズがかなりかさみそうに見えます) 個人的には、エンジン部分のDocker化が進んでいるので、少し修正してECSに乗せてしまうのがいいように感じました。 ECSはDockerコンテナをタスク的に起動することもできるし、サービスとして常駐することもできるサービスです。 ECSのサービスはある程度スケーリング・ロードバランシングもやってくれるし、EC2バックエンドにGPUインスタンスを選べばGPUも利用できる、そこまで性能が必要でない場合はFARGATEバックエンドを選んでEC2インスタンス無しの起動もできるなど、メリットがかなりあると感じました。 半面、値段的にはやさしくないのも事実です。 |
コメントありがとうございます!!!!!!とても心強いです!!! @kinneko さん
さくらさん、なるほどです!!VOICEVOXの規模感にもよりますが、もしかしたらお借りできるかもですね・・・! @YUzushio さん SageMaker・・・・・・・・・・・・・・・・・・・・。 あ、↑のコメントでも書いているのですが、リクエストを束にして推論する処理(バッチ処理?)って可能だったりするかご存知でしょうか 👀 @youku-s さん 確かにECSに乗っけちゃうのが良いのかなと感じました。。 FARGATEのことや、複数EC2で割引など全く知りませんでした。ありがとうございます。 皆様本当にありがとうございます。
という気持ちになりました。 自分のPCの感じ、16vCPU(16論理プロセッサ)で、1リクエスト0.5sという感じです(本当はもう少し早そう)。 |
転送料金に関してのメモ。 |
EC2バックエンドのECSは借りているEC2インスタンスの値段しかかかりません。他サービスを利用されている場合は、それらも加算されますが、ECS単体では、そんな感じです。 ちょっと外れた話になりますが、EC2の割引プランについて。 詳細は以下記事をご覧ください。 |
バッチ処理を行うなら(リクエストを即時に返す必要がないなら)、リクエストはLambdaで受け付けて、その結果をAWS SQSなどのジョブキューにため、ECSのタスクとして消化していく非同期実行モデルが向いていると思います。(AI系の実案件でもよくつかわれるアーキテクチャです) FARGATE実行モデルECSの料金計算機置いておきます。 |
複数タスクをバッチ処理で処理するのは、SQSからECSにつなぎこむ部分にやや工夫が必要かもしれません。
タスクが一定個数溜まるまで処理しない方法以下記事では1つSQSにメッセージがたまった段階でApplication Auto ScalingによりECSのタスクを起動していますが、ここを任意のメッセージ数にすることも可能です。(この方法には上記の問題点があります!) |
ありがとうございます!!EC2の割安情報助かります。
見積もりしてみたのですが、4vCPUで1日1個起動しっぱなしだと月144ドルという感じでした。 FARGATEってスポットインスタンス?みたいなのもあるんですね!! (2022/07/13 0:22 追記)料金計算してみた感じ、Fargateを使うとEC2の2倍くらいの価格感でした!
SQSにキューイングするの、なるほどです。 |
EC2でスピードテストしてみました! t2.xlarge(vCPU 4)だと、1回の音声合成処理時間は平均2.708sでした。 (VV_CPU_NUM_THREADS=4で起動)
(最後の行は空テキストを与えた時の計算時間) t2.2xlarge(vCPU 8)だと、1回の平均1.6323sでした。 (VV_CPU_NUM_THREADS=7で起動)(8で起動すると←より10%ほど遅くなる)
スポットインスタンスとか使えば価格的にはなんとかなりそうということがわかりました! GPUインスタンスのg4ad.xlarge(月 276.33 USD)でも速度測定したかったのですが、AWSのvCPU制限に引っかかってEC2を借りれませんでした。 ↓スピードテスト用コード sudo yum install -y docker
sudo systemctl start docker
sudo usermod -a -G docker ec2-user
# CPU4つを全稼働する場合
name=$(sudo docker run -d --rm -p 50021:50021 -e VV_CPU_NUM_THREADS=4 voicevox/voicevox_engine:cpu-0.12.3)
# GPUを使う場合
name=$(sudo docker run -d --rm -p 50021:50021 voicevox/voicevox_engine:nvidia-0.12.3)
sleep 5
cat <<'EOF' >text.txt
男の子はまるで絹で包んだ苹果のようなくらいぼんやりしたたくさんの星の集まりか一つの小さな星に見えるのでした。
今夜はみんなで烏瓜のあかりのようにまっ青な唐檜かもみの木がたって、それからしばらくしいんとしました。
野原から汽車の音が聞こえて来るのでした。
六時がうってしばらくたったころ、ジョバンニは思いながら訊きました。
どうか、あるいは風か水や、三角点の青じろい微光の中を流れましたし、カムパネルラは、なにかたいへんさびしいようなかなしいような新しいような気がするのでした。
黒曜石でできてるねえジョバンニが左手をつき出して窓から前の方を見ているというような気がするのでした。
私はこんなしずかないいとこで僕はどうしても考えつきませんでしたから、ジョバンニは、ああ、そうだ。
子どもらばかりのボートの中へくぐって行くのでした。
カムパネルラだってあんな女の子とおもしろそうにはなししていたでしょう。
すこしたべてごらんなさい二人は眼をひらきました。
こんなにむなしく命をすてず、どうか小さな人たちをだいて、それからぼうっとしたと思うと、もうたくさんの小さな星に見えるのでした。
けれどもあやしいその銀河の水はちらちら小さな波をたてて灰いろにしずかに流れていたのです。
燈台看守はやっと両腕があいたので、カムパネルラが川へはいったよどうしてこんなにひとりさびしいのだろう。
もうじき白鳥の停車場だねえああ、ここは厚い立派な地層で、百二十万年ぐらい前のくるみだよ。
おっかさんが、ほんとうにすきだ。
それはね、鷺をたべるには鳥捕りは、すっかりトパーズの正面になり、さっきの入口から暗い牛舎の前へまた来ました。
きみのおっかさんはどんなに永く待っていらっしゃったのよ。
銀河ステーションそしてジョバンニはすぐ入口から三番目の高い卓子にすわったばかりの男の子は顔を変にしてください青年がみんなに言いました。
町かどを曲がるとき、ふりかえって見ましたら、そのなかにカムパネルラがいたのです。
ぼくはカムパネルラの行った方を、窓から頭を出して、そっちを見あげました。
EOF
cat <<'EOF' >test.py
import json
from pathlib import Path
from time import time
from urllib.parse import urlencode
from urllib.request import Request, urlopen
base_url = "http://localhost:50021/"
# バージョン取得テスト
req = Request(base_url + "version")
with urlopen(req) as res:
print(res.read())
# 初回起動
text = "こんにちは、音声合成の世界へようこそ"
req = Request(
base_url + "audio_query?" + urlencode({"speaker": "1", "text": text}),
method="POST",
)
with urlopen(req) as res:
query = json.loads(res.read().decode("utf-8"))
print("query", query)
print("query_time synthesis_time")
for text in Path("text.txt").read_text().split("\n"):
start_time = time()
# テキスト -> クエリ
req = Request(
base_url + "audio_query?" + urlencode({"speaker": "1", "text": text}),
method="POST",
)
with urlopen(req) as res:
query = json.loads(res.read().decode("utf-8"))
query_time = time()
# クエリ -> 音声
req = Request(base_url + "synthesis?speaker=1", method="POST")
req.add_header("Content-Type", "application/json")
req.data = json.dumps(query).encode("utf-8")
with urlopen(req) as res:
wave = res.read()
synthesis_time = time()
print(f"{query_time - start_time} {synthesis_time - query_time}")
EOF
python3 test.py |
自分もAWSなどで速度を試してみたいところですが、暇つぶし遊んだ結果、有名所のクラウドサービスは無料クレジット使い切ってしまっているのですよね。。。 というわけであくまで素人意見なので申し訳ございませんが、クラウドサービス化して実現したいことを何にフォーカスするかというのが費用耐効果に非常に重要になってくると思います。 そして費用対効果やレイテンシ(例えば九州地方からの通信は東日本DCのAWSに対してレイテンシが当然悪くなります)などを考えると即時応答のサービスはあまり現実的ではないのかなと思っています。 例えばスマホユーザなどが利用できるサービスを構築する場合、費用対効果だけを見ると例えばスマホアプリやWEBサイトなどで読み上げる対象と文章の登録⇨一定時間時間後に出来上がったものをダウンロードなどが現実的かなと。 また、クラウド維持費などを考えるとあまりオープンソースに対して言いたくはないのですが、課金、広告要素なども入れる必要が出てくるかと。 これはある程度までクラウド費用を抑えるためでもあります。 |
コメントありがとうございます! スマホでVOICEVOX動画を作れると最高に嬉しい、という感じです。 「音声合成リクエストを投げて、1秒後にレスポンスが返ってくるシステムを、リクエスト辺り0.01円くらいで手軽に作れるか」が気になっています。 で、今はサービスをどうするかというより、どう実現するか(そもそも実現するのか)困っている、という感じです!!! |
連投すみません。 あくまで案ですが、例えば思いっきりローコスト(ただしバースト時にはある程度速度が早くなるように)、に振り切るのであればこういったサイトの形式も選択肢に入るかもしれません。 要はユーザが応答がなくて不快に思うのが問題の本質であって(当然レスポンスがいいにこしたことはありませんが)、ユーザには処理してますよと最低限の応答を返し、普段利用されていない(一定期間要求がない)ときはサーバを停止、利用者が多いときはサーバを常時起動、などにすれば一度否定されていますがローコストとバースト時の対応に向いているLambdaなど(もちろんAWSに限らずAzureやGCPなども比較する必要はありますが)のサーバレスも選択肢に入れれるかなと? |
t2.2xlargeだと、1回辺り平均1.6323sの0.023円なので、結構惜しいラインまで来てる感覚ですね!! |
かなりいい感じですね。 今のところアクセスは以下のVoiceLink_VoiceVoxTestのexeから。 ※お金かかると怖いのであまりむやみに使わないでくださいm(_ _)m ツールはEXE の後ろにtest.json のフルパス+拡張子を消したものを引数にすれば使えます。 |
GCP Run、なるほどです。AWSにおけるFargateみたいな・・・? おそらくですが、python3が入っている環境で↑の「スピードテスト用コード」の |
せっかくなので色々試してみました。 CloudRun-cpu4-mem8 CloudRun-cpu8-mem8 |
おお!!!お試しいただきありがとうございます!!!! 結果見てみました、たしかに同じスペックっぽいAWS EC2に比べてなぜか遅めですね・・・ もしかしたらvCPU8で起動する際に、環境変数 |
仮にCloudRunのvCPU8で運用した時、spotインスタンスはなしで、1リクエスト1.5sかかるとすると、値段は(起動しっぱなしで) |
環境変数+実行環境を第2世代(プレビュー)にした結果です。(通信込み) AVG:1.476187217 AWSの無料枠がある人にAWSのこういったサービス試してもらいたいところですね。 |
おーーー!!!CloudRun、良いですね!!!!! AWSの無料枠は弱いマシンしか借りれない印象があります・・・。 |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as resolved.
This comment was marked as resolved.
個人的にはGoogle Kubernetes Engineで動かすのがベストかと? |
GPU Sorobanに関してはGpuなので、ある程度早くなると期待が可能だと思われます。 |
一応日本において良さそうなホスト業者書いときます。 |
Xserver VPSは元10Gbps回線ですが各VPSの回線が100Mbpsに制限されてるのであまりよくない。 |
通信速度って問題になりそうですか・・・? |
別に問題はないかと? |
1インスタンスに複数人使用となると難しいかもしれないって思いましたけど自分の環境でも30Mbps以下だから別に大丈夫なのか |
AWSのGPUインスタンスでスピードテストしました。 テスト結果
g4dn.xlargeスペック詳細
結果1回の音声合成処理時間は平均0.884sでした。 g4dn.xlargeの東京リージョンのオンデマンド料金は1時間0.71USDなので、1回辺り0.71USD / 60 / 60 * 0.884 = 0.0001743444ドル ≒ 0.024円でした。(USDJPYレート=135.74の場合) g4シリーズ価格表(当該ページの記載はバージニアリージョンに準拠) 測定結果詳細
同一テキストの2回目以降の実行(キャッシュが効いた状態)コンテナ起動後に、同一テキストを2回以上投入したところ、キャッシュにより劇的に高速になりました。 2回目以降の音声合成処理時間は平均0.253sでした。 測定結果詳細
g5.xlargeg4dn.xlarge(GPU メモリ:16GiB)との比較のため、g5.xlarge(GPU メモリ:24GiB)でも試してみました。 スペック詳細
結果1回の音声合成処理時間は平均0.451sでした。 g5.xlargeの東京リージョンのオンデマンド料金は1時間1.459USDなので、1回辺り1.459USD / 60 / 60* 0.451 = 0.0001827802ドル ≒ 0.025円でした。(USDJPYレート=135.74の場合) インスタンス1つの時間あたりの利用料金はg4dn.xlargeの方がg5.xlargeよりも安い一方で、性能を勘案すると1クエリ辺りの料金は実はそれ程変わらないことがわかります。 g5シリーズ価格表(当該ページの記載はバージニアリージョンに準拠) 測定結果詳細
同一テキストの2回目以降の実行(キャッシュが効いた状態)2回目以降の音声合成処理時間は平均0.116sでした。 測定結果詳細
その他のGPUインスタンスの選択肢その他の有力そうなAWSのGPUインスタンスとして以下が挙げられますが、VOICEVOXが動くかどうか(どうすれば動かせるか)が不明であったため検証できていません。もしこの辺りが使えるなら、より安く&速くなる可能性があります。 g4ad.xlargeAMD製GPU搭載インスタンスです。東京リージョンの1時間辺りの料金は0.51082USDなので、g4dn.xlargeに比べて安価です。 inf2.xlargeAWS社の独自機械学習推論用プロセッサのInferentiaを積んだ、推論に特化したインスタンスです。AWSの発表によれば、推論系の処理に関して全てのインスタンスで最もコスパが良い(速くて安い)とのことなので、有望かもしれません。 使用リージョンについて上記の価格は東京リージョンの価格をベースに計算していますが、インスタンス辺りの利用料金は北米のリージョン、特にバージニアリージョンの方がずっと安いです。 備考:SPOTインスタンスの留意事項ご存知かと思いますが、SPOTインスタンスは利用中にAWS側の都合で中断される(2分の猶予期間を経てシャットダウンされる)仕様があります。これはSPOTインスタンスが本質的にAWSインフラの余剰リソースを一時的に安価で貸出すサービスであるためです。 |
@lawofcycles 詳細ありがとうございます、とても参考になります!!
VOICEVOXエンジンは特にキャッシュ機構を意図して用意してなかったりします。
あ、そんなに価格変わるんですね!! 最初のなんとなく考えたのが1リクエスト0.01円ならという感じなので、その値を下回れそうというのがとてもよくわかりました、ありがとうございます!! ここまで来るとaws cdk使って使いやすいクラウドVOICEVOX APIを作るコードをOSSで作るとかも面白そうに思いました!!(いわゆるIaC) ちなみにVOICEVOX APIの見えてる需要はこんな感じです。
このあたりに役立つような最大公約数的な機能があると良さそうかも。 |
Spotは確かに安いのですが、ホストサーバーのリソースがフルに近づくと、勝手に止められる恐れが。。。 |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
多くの方々の貢献により、クラウドでの費用感が明確化できたと考えています。 @Hiroshiba |
そうですね、計測して温度感が掴めたので完了だと思います! |
内容
VOICEVOXのクラウド版が実現が可能かを調べたいです。
いったんAWS Lambdaを検討中なのでですが、どれくらい速度が出るのかを測定するIsuseです。
テキストを投げて、音声合成結果を返すのを1処理とし、金額あたりの処理数を知りたいです。
クラウドは全然詳しくないので僕だと非力です、もし詳しい方がいらっしゃったらお力をお借りしたいです。
Pros 良くなる点
クラウド版ができるかもしれない
Cons 悪くなる点
測定方法がわからない
実現方法
AWS Lamdaにlinux版VOICEVOX ENGINEバイナリをダウンロードして、lambda内でwebサーバーを起動し、lambdaでリクエストを受け取ってwebサーバーにリクエストする・・・とか?
音声合成は簡単で、こんな感じでリクエストすれば結果が帰ってきます。
おそらくlambdaは起動数などがスケールして、そのたびにバイナリダウンロードするため速度測定に影響がありそうな気がしています。
なので測定時は、lambdaにテキストを投げた後、レスポンスが返ってきてからまたリクエストを投げる、というのが良いのかなと思ってます。
(これでも勝手にスケールしますかね。。)
文章は
Lorem JPsum 自然な日本語ダミーテキスト
などで作成するのを考えてます。とりあえずこんな感じでどうでしょう(200文)
その他
なんとなくの概算ですが・・・
仮に100リクエスト1円とかであれば、広告を1回見るだけで5分ほどは作業できそうなので成り立ちそうな気がします。
仮に1リクエスト1円とかであれば、調整するたびに広告がリロードされる最高のアプリが出来上がる気がします。
The text was updated successfully, but these errors were encountered: