AWSでの速度（金額あたりの処理数）を測定したい

内容

VOICEVOXのクラウド版が実現が可能かを調べたいです。いったんAWS Lambdaを検討中なのでですが、どれくらい速度が出るのかを測定するIsuseです。

テキストを投げて、音声合成結果を返すのを１処理とし、金額あたりの処理数を知りたいです。

クラウドは全然詳しくないので僕だと非力です、もし詳しい方がいらっしゃったらお力をお借りしたいです。

Pros 良くなる点

クラウド版ができるかもしれない

Cons 悪くなる点

測定方法がわからない

実現方法

AWS Lamdaにlinux版VOICEVOX ENGINEバイナリをダウンロードして、lambda内でwebサーバーを起動し、lambdaでリクエストを受け取ってwebサーバーにリクエストする･･･とか？音声合成は簡単で、こんな感じでリクエストすれば結果が帰ってきます。

おそらくlambdaは起動数などがスケールして、そのたびにバイナリダウンロードするため速度測定に影響がありそうな気がしています。なので測定時は、lambdaにテキストを投げた後、レスポンスが返ってきてからまたリクエストを投げる、というのが良いのかなと思ってます。（これでも勝手にスケールしますかね。。）

文章はLorem JPsum 自然な日本語ダミーテキストなどで作成するのを考えてます。とりあえずこんな感じでどうでしょう（２００文）

``` 男の子はまるで絹で包んだ苹果のようなくらいぼんやりしたたくさんの星の集まりか一つの小さな星に見えるのでした。今夜はみんなで烏瓜のあかりのようにまっ青な唐檜かもみの木がたって、それからしばらくしいんとしました。野原から汽車の音が聞こえて来るのでした。六時がうってしばらくたったころ、ジョバンニは思いながら訊きました。どうか、あるいは風か水や、三角点の青じろい微光の中を流れましたし、カムパネルラは、なにかたいへんさびしいようなかなしいような新しいような気がするのでした。黒曜石でできてるねえジョバンニが左手をつき出して窓から前の方を見ているというような気がするのでした。私はこんなしずかないいとこで僕はどうしても考えつきませんでしたから、ジョバンニは、ああ、そうだ。子どもらばかりのボートの中へくぐって行くのでした。カムパネルラだってあんな女の子とおもしろそうにはなししていたでしょう。すこしたべてごらんなさい二人は眼をひらきました。こんなにむなしく命をすてず、どうか小さな人たちをだいて、それからぼうっとしたと思うと、もうたくさんの小さな星に見えるのでした。けれどもあやしいその銀河の水はちらちら小さな波をたてて灰いろにしずかに流れていたのです。燈台看守はやっと両腕があいたので、カムパネルラが川へはいったよどうしてこんなにひとりさびしいのだろう。もうじき白鳥の停車場だねえああ、ここは厚い立派な地層で、百二十万年ぐらい前のくるみだよ。おっかさんが、ほんとうにすきだ。それはね、鷺をたべるには鳥捕りは、すっかりトパーズの正面になり、さっきの入口から暗い牛舎の前へまた来ました。きみのおっかさんはどんなに永く待っていらっしゃったのよ。銀河ステーションそしてジョバンニはすぐ入口から三番目の高い卓子にすわったばかりの男の子は顔を変にしてください青年がみんなに言いました。町かどを曲がるとき、ふりかえって見ましたら、そのなかにカムパネルラがいたのです。ぼくはカムパネルラの行った方を、窓から頭を出して、そっちを見あげました。まっ白な、あのさっきの北の十字架のように赤く光りました。ジョバンニはもういろいろなことで胸がいっぱいで、なんにもひどいことないじゃないのジョバンニはびっくりしたような音が川下の方から、あの聞きなれた三〇六番の声が、ジョバンニの汗でぬれたシャツもつめたく冷やされました。つまりその星はみな、乳の流れと考えるなら、その一つのあかりに黒い甲虫がとまって、その火は燃えているのでした。どこでできるのですかさっきの燈台看守がやっと少しわかったように、いよいよ光って立っていました。眼をつぶってるねカムパネルラは、ありがとうといってね、わたしたちはこちらのお父さんが黒い服を着た、せいの高い青年がいっぱいになり、さっきの入口から暗い牛舎の前へまた来ました。林の中を大股にまっすぐに行こうと言ったとたん、がらんとしたから来たんじゃないんですよ青年はいまどこにいるか忘れたというの。網棚の上にひろがり、しばらくは鳥の形が、砂に三、四日うずめなけぁと言いながら、まるではね上がりたいくらい愉快になって床へ落ちるまでの間にいっぱい日光を吸った金剛石のようになっております。川まではよほどありましょうかねえええ、ええ、ありがとうと言いました。僕たちしっかりやろうねえジョバンニが言いました。そらの孔だよカムパネルラはにわかに顔いろがよくなって威勢よくおじぎをすると扉をあけました。その小さな列車の窓は一列小さく赤く見え、その手首にぶっつかってできた波は、うつくしい燐光を出す、いちめんのかわらははこぐさの上にひろがり、しばらくは鳥の形が、砂に三、四日うずめなけぁよかったなあ。わたくしはあなた方がいまにそのほんとうの神さまがほんとうの神さまですほんとうの神さまうその神さまよそうじゃないわよ。隣りには黒い洋服をきちんと着たせいの高い車掌が、いつかまっすぐに立っているのかと思って渡しましたら、カムパネルラは、まるい板のようなものがあるよカムパネルラがすぐ飛びこんだんだ。ジョバンニはもうどぎまぎしてまっ赤になって、まもなくジョバンニは走りだして黒い丘の方へ急ぐのでした。そうだ、ぼくたちはぼくたちの心がいいとかわるいとか議論するだろう。ジョバンニはもういろいろなことで胸がいっぱいで、なんにもひどいことないじゃないのジョバンニは靴をぬぎながら言いました。さそりは一生けん命で甲板の格子になったわ、もうどうしても気持ちがなおりませんでした。ぼくが行くと鼻を鳴らしてついてくることもあるよ。と思ったらもうここへ来たとでも思ったものですか、それとも鷺ですか鷺ですジョバンニは、まるで一度に叫んで、そっちの方へ行きました。ええ、ボートはきっと助かったにちがいありませんかおかしいねえカムパネルラが首をかしげました。ジョバンニはその人の卓子の人へ持って行くよそうだ。鳥が飛んで行くなジョバンニが窓から顔を引っ込めて向こう側の窓を見ると、そのとき出ている。汽車はもう、しずかに永久に立っているのでしょうジョバンニは勢いよく立ちあがりました。白い服を着た、せいの高い子供が、窓の外をのぞきながら、もうすっかりまわりと同じいろになってしまいました。いいかそのひとは指を一本あげてしずかにくるくるとまわって、さっきの十字架はすっかり小さくなってしまい、ほんとうにそのまっ赤なうつくしい火になってしまいました。わたしたちは天へ行くのジョバンニがまだそう言ってしまうかしまわないうち、次のりんどうの花が咲いている。それから元気よく口笛を吹きながら一生けん命延びあがって、その影が大きく天井にうつっていたいろいろのことを考えながら、牛乳屋の方へ行きました。走って来るわ、あら、走って来るわ、あら、走って行くのでした。もう涼しいからねジョバンニは立って窓をしめておこうかああ、どうか。あなた方は、どちらへいらっしゃるんですかジョバンニが、なんだか苹果のにおいがする。カムパネルラがきのどくそうにしました。女の子はいかにもつらそうに眼をこすってしまいました。そして二人がそのあかしの前を通るのですから、大将さっそく親牛のところへ来なかったのですか。カムパネルラがきのどくそうに、だまってこらえてそのまま立って口笛を吹いたり笑ったりして、あすこから、いっぺんにここへ来ていたよ。そこに学生たちや町の人たちに囲まれた、小さな広場に出ました。ジョバンニはまっ赤になって毛あなからちらけてしまうのでした。鷺の方はガラスが厚いので、光る粒すなわち星しか見えないでしょう。女の子はいかにもつらそうに眼を大きくして、頭をやけに振りました。なんせこんどは一ぺんに化石させて、こっちを見ていました。車掌が手をのばしていました。隣りには黒い洋服をきちんと着たせいの高い車掌が、いつかまっすぐに立ってまた叫びました。ああ、遠くからですね鳥捕りは、それを二つにわかれました。けれどもだんだん気をつけていましたら、車掌はまっすぐに立っていたのでした。そしてわたしたちの代わりにボートへ乗れた人たちが、何か大きなたたんだ紙きれにあたりました。姉さんはいつ帰ったのああ、三時ころになります車掌は紙をジョバンニのポケットにでも着いて立っていました。するとジョバンニも、なんだかその中へ吸い込まれてしまうような気がして、少しひらべったくなって、足をあげたり手を振って町を通って、それからしばらくしいんとしました。けれどもジョバンニは、すっかりトパーズの正面になり、インデアンはぴたっと立ちどまって、岩から黒い細長いさきのとがったくるみの実だよ。川下の向こう岸に青く茂った大きな林が見え、その手首にぶっつかって船が沈みましてね、ぼくの方を見ていました。ジョバンニはおじぎをすると、台の下に置いた鞄をもって行きますと、もういちもくさんに河原を街の方へ歩き出しました。けれどもジョバンニは手を大きく振ってどしどし学校の門を出るとき、同じ組の七、八人ぐらいずつ集まって橋の方を見ました。標本ですか標本じゃありませんでした。その葉はぐるぐるに縮れ葉の下に大きな一つの、ほんとうの天上なんだか鼻が変になりました。ほんとうにこんなような蠍だの勇士だのそらにぼんやり立っていました。カムパネルラのうちへもつれて行った烏瓜のあかりのようだ。そうら、こんどは自分で一つずつ二人に送ってよこしましたので、カムパネルラが川へはいったよどうしても見ているのでした。みんなほんとうに別れが惜しそうで、そのマジェランの星雲をのぞんで立ちました。ぼくはもう、しずかによこたわったのですが、その光はなんだかわかりません。と思ったら、もうそこでとって来たらしく、さっきなかった一つのちりのように流れていたのです。それからにわかにお母さんの牛乳のことを考えていたよ。けれども見つからないんだから小さいのもいるんでしょういいえ、汽車を追ってるんじゃないんですそうそうここはコロラドの高原じゃなかったろうか。ジョバンニはあぶなく声をあげて、ちらちらと燃えるように、尋ねました。わたしはずうっとぐあいがいいよジョバンニはまったくその大きな火の向こうにさめざめと光りながらだんだんうしろの方に見えました。ハレルヤ、ハレルヤ明るくたのしくみんなの声はひびき、みんなはてんでに口笛を吹き、男の子はまるで絹で包んだ苹果のような声が、銀河ステーション、銀河ステーションと言う声がしたんだ。双子のお星さまのお宮ってなんだい、ザネリとジョバンニはいきなりさっきカムパネルラといっしょに苹果をたべたり汽車に乗ったりした人がすぐ出て来ました。そしてほんとうに、風のように通りや店の前に立ってお祈りをはじめました。銀河だから光るんだよジョバンニは叫んでまた走りはじめました。ここらではこんな苹果ができるのですか青年は笑いながら言いました。あしたにして、だまって口をむすんでそらを見あげてくつくつ笑いました。ええ、三十疋ぐらいはたしかになにか黒いつるつるした変なものがあるというような気がするのでした。蠍の火ってなんだい、ザネリとジョバンニは思いながら訊きました。先生は意外なようにしばらくじっとカムパネルラを見ているのでした。誰がいったいここらで鷺なんぞたべるだろうとジョバンニは高く叫び返しましたが、その光はなんだかわけもわからず、急いで行きすぎようとしましたら、そのいままでカムパネルラのすわっていたのです。そしてしばらく木のある町を通って行きました。鳥捕りは、こっちに五つの三角標が、ちょうどさっきのような声が、ジョバンニの隣りにしましたが、眼を細くしたり首をまげたりしながら、それを二つにわかれました。そしてその見えない天の川の向こうに三つの三角標が立っていました。おまえはもうカムパネルラをさがしてから、さっき見たようにまっ黒な上着を着た巡査も出ていないねえジョバンニが言いましたけれどもやっぱりジョバンニたちとわかれたくないような気がして、たのしそうに遊んでいるのです。君もらわなかったのです。こっちの方はレンズが薄いのでわずかの光る粒すなわち星がたくさん集まって見え、したがって白くぼんやり見えるのです。押し葉にするだけです鷺を押し葉にするだけです鷺を押し葉にするんですか。ジョバンニは、思わずジョバンニもカムパネルラもあわれなような気がして、も一度こっちをふりかえって、それからぼうっとしたという証拠もいろいろあがるけれども、もしおまえがほんとうに川だと言われたり、乳の流れと考えるなら、その一つが一冊の地歴の本にあたるんだ。走るときはまるで鼠のようなものが鳴りました。その人は、ひげの中で見たあの図よりはずうっと小さかったのです。そのとき汽車のずうっとうしろの方に不思議なものをひろいました。時計屋の店には明るくネオン燈がついて、赤や緑やきらきら燃えて光っている星だとジョバンニは思いました。そして誰にも聞こえないように、しずかにうごいていました。ジョバンニは、もうなんとも言えずさびしい気がして、さびしくなり風がいっぱいに吹き込みました。汽車が小さな小屋の前を通って行きました。ボスといってね、ぼくの方を見ていました。ではいただいて行きますと、二人の横の方へ走りました。あなたくじら見たことのあるような気がする。けれども、ジョバンニは、思わずジョバンニもカムパネルラもあわれなような気がして、めいめい烏瓜の燈火を持ってやって来るのでした。すると博士はジョバンニがあいさつに来たジョバンニは言いながら、まるであんな女の子とばかり談しているらしいのでした。ジョバンニさんそうでしょうジョバンニは勢いよく立ちあがりました。するとしばらくたってから来てくださいねそう言いながら、一枚の紙切れを渡しました。けれどもにわかにカムパネルラのお父さんも来た。そんならこのレンズの中を通って行きました。きっと何か掘ってるから二人は、もとの車室の席にすわったばかりの男の子が向こうの窓を見ました。銀河ステーションで、もらったんだカムパネルラは、窓から外をのぞきながら、もうすっかりまわりと同じいろになってしまいました。なんだかその地図をどこかで待っていようかと言いました。あれが名高いアルビレオの観測所です窓の外から光りました。そしていきなり近くの人たちが、何か歌うように読んだり数えたりしながら、それでもたしかに流れて来るのでした。そのとき汽車のずうっとうしろの方からお持ちになったのですか青年は笑いながら言いました。ジョバンニは、いつから乗っていたのか、それと同時にぴしゃあんというつぶれたようなふうにして水の中へ通っていました。室中のひとたちは半分うしろの方に不思議なものをひろいました。おりるしたくをして、じっとそらを見てくすっとわらいました。こいつをお持ちになったねえ、どこまででも行けるはずでさあ、あなた方たいしたもんですぜ。またこれを巨きな乳の流れたあとだと言われたり、乳の流れと考えるなら、もっと天の川とよく似ていますかいますとも、さっきから、ごとごとごとごと、その小さなみちが、まっすぐにすきっと立ったのです。川まではよほどありましょうかねえええ、ええ、ありがとうと言いました。ところが先生は早くもそれをもとめたらいいでしょうああわたくしもそれを見つけたのでした。この汽車は、じっさい、どこまででも行けるはずでさあ、あなた方たいしたもんですぜ。ごとごと音をたてていると考えます。そうら、こんどは向こうのひばの植わった家の中へくぐって行くのでした。いや、さよなら大学士は、また別の方の窓を見ました。いるんでしょういいえ、汽車を追ってるんじゃないんでしょういるかは海にいるときまっていないねえジョバンニが胸いっぱいに思いだされたので、だまって席へ戻りました。どうしてわたしはわたしのからだをおつかいください。すこしたべてごらんなさい二人は眼をひらきました。ああぼくいまお母さんの夢をみていたかとおもいながら、やっぱりぽくぽくそれをたべていました。ジョバンニは、走って来るわ。けれども、ジョバンニは思わずかけよって博士の前を通るのですから、みなさんは夜にこのまん中に立ってこのレンズの中を流れましたし、カムパネルラはわけもないというような、あまの川のまん中に、黒い鳥がたくさんたくさんいっぱいに列になってしまうのを見ました。そのうちもうあっちでもこっちでも、みんな何べんもおまえといっしょに歩いていたのですかいいえいまでも燃えてるって、あたし何べんもおまえといっしょに歩いて行かなければいけない。青い胸あてをしたカムパネルラのお父さんがきっぱり言いました。お母さんがね、立派な眼もさめるような、あたりまえでないような気がするのでした。カムパネルラだってあんな女の子とばかり談しているのなんだから小さいのもいるんでしょうか女の子が言いました。そしてジョバンニは青い琴の星がずうっと西の方へ歩いて行きました。つまりその星はみな、乳のなかに棲んでいるわけです。あら、蠍の火だなカムパネルラがまた何気なくしかるように叫びました。僕もう少し汽車へ乗ってから行くんだよう腰掛けたばかりの青い鋼の板のように赤く光りました。けれどもあやしいその銀河のお祭りだねえうん。お母さんがね、舟の上から烏うりのあかりを川へながしに行くんだって。ケンタウル祭の夜ジョバンニは、せわしくいろいろのことを思いだしてジョバンニはその人の卓子の人へ持って来たのでした。さあ、もうじきですから元気を出して外を見ながら言いました。その牛乳屋の黒い門をはいり、牛のにおいのするはずはないとジョバンニは、走って来るわ、あら、走ってその渚に行って、水に手をあてて、それから硫黄のほのおのようなくらいぼんやりしたたくさんの星の集まりか一つの街燈が、青白く立派に光って立ったのですがあ、済みませんでした。ここでおりなけぁいけないって僕の先生が言ってたよそうかねえいまも毎朝新聞をまわしに行くよ。きみのおっかさんは、なんにもかなしいことないのです。けれどもいっしょに行こうねえジョバンニが胸いっぱいに思いだされたのです。二人もそっちを見ますと、青白く光る銀河の岸に星のかたちとつるはしを書いた旗がたって、その影が大きく天井にうつっていた地理と歴史が書いてある。そのとき舟がゆれたもんだから水へくぐるのがたくさん見えてきました。この汽車は、スティームや電気でうごいていたのです。いえ、氷山にぶっつかって船が沈みましてね……その人はしばらく棚をさがしてもむだだああ、どうか。天の川の水や、がらんとしてごらん。カムパネルラ、また僕たち二人きりになったのでもいいと思いながら、大股にその街燈の下を、実に何万という小さな鳥どもが、まっ黒にかたまって、あかしの前を通り、汽車はだんだんゆるやかになってしずかにくるくるとまわっていました。それはね、ずいぶん走ったけれども遅れてしまったのでした。いるか、魚じゃありませんからな。いきなりこっちも窓から顔を引っ込めて、こっちを見ました。ジョバンニはいっさんに丘を走っていましたから前にいる子供らを押しのけようとしましたら、こんどは自分で一つずつ重ね直しているのでした。川下の向こう岸に青く茂った大きな林が見え、その手首にぶっつかって船が沈みましてね……その人は、なにかほんとうに決心しているらしいのでした。ところがその人はすぐ奥へ行っておじぎをしました。眼をつぶってるねカムパネルラは、そのきれいな水は、水素よりももっとすきとおっていたのでした。チョコレートよりも、もっとおいしいけれども、ね、ちょっとこの本をごらん、いいかい、そしてこの中に書いてある。ジョバンニは、ちょっとたべてみて、なんだか苹果のにおいがする。ぼくお父さんはきっとまもなく二つのすきとおった球が、輪になって、その中には、真鍮の大きなぼたんが二つ光っているのが見え、その中にはたくさんのたくさんの豆電燈がついて、ほんとうにこの方たちのお母さんは一昨年没くなられました。ずうっと町の角までついてくることもあるよ。苹果だってお菓子だって、林の中や川で、何べんもおまえといっしょにまっすぐに行こうと言ったんですああ、そんなんでなしに、たったひとりのほんとうのさいわいをさがしに行く。まあ、おかしな魚だわ、たあちゃん、そうじゃないよ。けれども、ジョバンニは思いましたけれども、いったいどんなことが、おっかさんは、そういうふうに川だと考えるなら、もっと天の川とよく似ていますかいますとも、さっきから鳴いてまさあ。そうだ、ぼくたちはそらへ来たんじゃない。お前の言ったように立ちあがりました。ジョバンニは何べんも聞いたごとごとごとごと、その小さなみちが、まっすぐに銀河の青光の中へはなしてやって来るのでした。あれはほんとうにつらいジョバンニはこんなへんてこな気もちは、ほんとうにすきだ。くじらと同じようにじぶんで光っているのなんだ。気がついて、ほんとうにもうそのまま胸にもつるされそうになり、天の川もまるで遠くへ行ったのだろう。そのときあのやぐらの上の槍のようなかたちに進んで、また水の中から、セロのような、あたりまえでないような、白い十字架がたって、それからしばらくしいんとしました。ところがその人はしばらく棚をさがしてもむだだああ、どうしてもっと愉快になれないだろう。それは、茶いろの少しぼろぼろの外套を着て赤い帽子をかぶった男が立ってこっちを見てあわてたように思われました。まったくインデアンは半分は踊っているように見えるのでした。たちまちみんなはいろいろな国語で一ぺんにおりて、車室の中はすっかり明るくなりました。ですからもしもこの天の川がほんとうに勉強しなけぁいけないって僕の先生が言ってたよそうかねえいまも毎朝新聞をまわしに行くよ。ジョバンニはばねのようにふりうごかしました。家ジョバンニが勢いよく帰って来たねえいやだわ、たあちゃん、そうじゃないよあなたの神さまですほんとうの神さまを信ずる人たちのしたことない。ぼくたちも降りて見ようかジョバンニが、どんどん電燈の方へ歩き出しました。おまえはもうカムパネルラをさがしてもむだだああ、どうかこの次には、真鍮の大きなぼたんが二つ光っているのを見ました。わたくしたちは神さまに召されているけやきの木のような音がしましたが、霧が非常に深かったのですか。カムパネルラのとなりの男の子が向こうの窓のそとを見つめていました。ジョバンニはにわかになんとも言えずに博士の前を通るのですからしかたありませんからな。ああ、遠くからですね鳥捕りは、何か用かと口の中で見たようになった水は見えなくなりました。ここでおりなけぁいけないんだ。先生は意外なようにしばらくじっとカムパネルラを見ているのでした。いま川の流れているのでした。ジョバンニは何べんも聞いたごとごとごとごと、ジョバンニの横の方へ行きました。つりがねそうか野ぎくかの花が咲いている。 ```

その他

なんとなくの概算ですが･･･仮に１００リクエスト１円とかであれば、広告を１回見るだけで５分ほどは作業できそうなので成り立ちそうな気がします。仮に１リクエスト１円とかであれば、調整するたびに広告がリロードされる最高のアプリが出来上がる気がします。

構成

LambdaバックエンドのAPI Gateway が一般的な構成になるかと思います。
webサーバー部分をAPI Gatewayが担って、サーバーが返すresponseをLambda上で計算する形です。
AWS Lambdaページの「カスタムバックエンドサービスの構築」の部分ですね。

全体構成は

http request ----> 
                   API Gateway <---> VV on Lambda
http response <---

になります。

速度計測

バイナリダウンロード云々は「cold start での速度バラツキ」でしょうか？
その場合はReq-Res-Req-...の形で基本的にはいいかと思います。また、たしか設定値で同時実行数制限がかけられたはずです（公式docsにそれっぽいもの（Lambda の予約済み同時実行数の管理）はありましたが、私はこの機能触った事ないです）。

その他

GPU推論？

（※私が現在のVoiceVox開発状況をフォローできてない & AWSをゴリゴリ使ってたのが2年ほど前なので、頓珍漢な内容でしたらすみません）

合成はGPUで行なう予定でしょうか?
Lambdaは（少なくとも数年前まで）CPU前提のシステムだったと記憶しています。

金額

AWSの料金は転送量が意外と重いです。
音声はレスポンスサイズが結構デカくなるので、Lambdaの動作時間に基づく課金と共に、転送料金の測定をおこなうのがベターかと思います。

ありがとうございます！！

最終的にはAPI Gatewayを挟む構成にすると良さそうに思いました！！とりあえず一旦Lambdaのみにして計測するのが最短･･･？（よくわかってないです）

同時実行オプションや転送料金も勉強になります！！場合によってはflacなどに変換したあとにレスポンス返したほうが良いかもですね。。

ご助言、助かります🙇🙇🙇

確かに、計測目的の最短ステップはLambdaオンリーですね。
いっそ、webサーバー部分もとっぱらって、例文textと実行コードを一緒にして、httpとか関係なくただLambda関数をAWSコンソールから叩くのが1番手軽かもです。
10回くらい手で叩いたら大まかな速度はわかるので、Go判断ならAPI Gateway含めたE2E測定、というイメージです。

おおなるほど！！たしかにコンソールから叩いちゃうのも手っ取り早い気がしました。とりあえず何度か実行してみて、いろんな条件で測定したくなったら自動化･･･みたいな！

そういえば答えられていなかったのですが、CPUでの利用を想定していました。おそらくEC2のスポットインスタンス？なりにGPUサーバー建てちゃうのが一番安そうなのですが、スケールとかロードバランス？の問題もありそうなので、手っ取り早くLambdaでできないかなーと思った次第です！

LambdaはAPI Gatewayを挟まなくても直接外に出せるようになったので、課金的にそちらのほうがいいかと。 SaaSを使うのは楽でいいのですが、課金の変動が怖いですね。

AWSはトラフィック課金もあるので、さくらのクラウドでIaaSではじめると固定費で運用できると思います。ただし、オートスケールはしないので時間あたりくらいのアクセス制限は必要になるかと。さくらだと、実験公開したいのだけどという相談を持ちかけると、課金免除してくれる可能性もあると思います。

API GateWayを置くかどうかは公開範囲によるとして、バックエンドに関しての話をします。実現可能性に関しては「できそうだけど・・・」という気持ちですが、Lambdaの性質上、インスタンス内がステートレスであるほうがとても好ましいので、webサーバーを立てた状態にする、というのが非常に相性が悪いです。

私が予想するコード順序としては

Lambdaリクエストを受け取る
インスタンス内にwebサーバーが起動していないなら起動する
webサーバーがリクエスト可能になるまで待機する
webサーバーにリクエストを飛ばして結果を取得する
webサーバー結果をLambda結果として返す

という形にする必要があります。

なお、バイナリを取得してwebサーバーを起動する形にすると結構な頻度でそのサーバー起動のオーバーヘッドがランダムにLambdaのレスポンス時間に加算されますので、使う側からは速度的に非常に不安定に感じるでしょう。(Lambdaはイベント実行中に次のイベントが来た場合、順次新しいインスタンスを作成するので)

個人的なおすすめはSageMakerのサーバーレス推論機能を使用するのが良いと思います。

SageMakerサーバーレス推論公式案内ページ SageMakerサーバーレス推論公式ドキュメント英語 [SageMakerサーバーレス推論Python SDK ドキュメント英語]()

SageMakerを触る必要がありますが、ボイボエンジン側のコードの推論部分をラップする形にすれば使えるんじゃないかと思います。(私は実際にSDKを使って組んだことはないのですが・・・) ボイボエンジンの進捗も把握してないのでよくわかってませんが、ONNX化が済んでいるのであればwebサーバーを立てたりすることなく、modelからの推論を直接実行できたりするかもですね。 Amazon Elastic Inference を使用して ONNX モデルを実行する

EC2インスタンスを立てたりすることと金額的に比べてLambdaを選びたい、という場合は確かに金額的に良い結果になると思いますが、レスポンス時間まで考えると少し現実味が薄いかもしれません。バイナリからのサーバー起動がどれくらいかかるのかがネックになるかもしれません。

横から失礼いたします。実現可能性的にはできそうではあるが、現実的に使い物になるかは微妙な感じがします。

なお、バイナリを取得してwebサーバーを起動する形にすると結構な頻度でそのサーバー起動のオーバーヘッドがランダムにLambdaのレスポンス時間に加算されますので、使う側からは速度的に非常に不安定に感じるでしょう。(Lambdaはイベント実行中に次のイベントが来た場合、順次新しいインスタンスを作成するので)

同意です。

どうにかして全体のサイズを250MB以下に抑えられるなら、Lambda Layerであらかじめインストールしておくこともできますが、その辺実現性が分からないです。(キャラクター毎の部分であるVOICEVOX コアライブラリもサイズがかなりかさみそうに見えます)

個人的には、エンジン部分のDocker化が進んでいるので、少し修正してECSに乗せてしまうのがいいように感じました。 https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/Welcome.html

ECSはDockerコンテナをタスク的に起動することもできるし、サービスとして常駐することもできるサービスです。今回は、ECSのサービスとしてVOICEVOXエンジンを常駐させるイメージです。 https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/ecs_services.html

ECSのサービスはある程度スケーリング・ロードバランシングもやってくれるし、EC2バックエンドにGPUインスタンスを選べばGPUも利用できる、そこまで性能が必要でない場合はFARGATEバックエンドを選んでEC2インスタンス無しの起動もできるなど、メリットがかなりあると感じました。

半面、値段的にはやさしくないのも事実です。 https://aws.amazon.com/jp/fargate/pricing/ 試しにFARGATEバックエンドを選択した場合、Linux(x86)で4vCPU/RAM8GBで1か月起動し続けたの場合のコストを概算すると、177.46 USDになりました。ここまでくると、弱めのEC2インスタンスをバックエンドにしたほうがよさそうですね。EC2インスタンスバックエンドの場合、ECSの料金はインスタンスを借りた分だけになるので。(さらに言うと、EC2インスタンスは複数の割引プランがある)

コメントありがとうございます！！！！！！とても心強いです！！！

@kinneko さん

さくらのクラウドでIaaSではじめる

さくらさん、なるほどです！！VOICEVOXの規模感にもよりますが、もしかしたらお借りできるかもですね･･･！ただおそらくGPUマシンを借りることになりますが、VOICEVOXは処理が軽いため、GPUの性能をフルに活かすには複数のリクエストをまとめてバッチ処理（バルク処理）する必要があると思っています。そのバルク処理用のコードを書くのがなかなか大変そうだなーーーと。。。。

@YUzushio さん VOICEVOXエンジンの起動はだいたい５秒くらいです。音声合成はおそらく１秒未満で完了するので、Lambdaで行く場合運が悪いと５倍ほど待たされることになりそうです。訂正：エンジンのダウンロードもあるので、おそらく数十秒かかります。。仮に２０回音声合成するたびに１回出くわするとすると･･･すっごく微妙なところですが、我慢できなくはないけどたしかにストレスになりそうだなと思いました。 Lambdaはなるべく避けたい気がします。

SageMaker････････････････････。使いこなせると便利そうですが、ランニングコストが凄まじそうな第一印象があります･･･。せめて妥当な価格でできうるのか最初に知りたいかもしれません･･･。

あ、↑のコメントでも書いているのですが、リクエストを束にして推論する処理（バッチ処理？）って可能だったりするかご存知でしょうか 👀 （テキスト→音声なので、入力は可変長データになります。）

@youku-s さん

確かにECSに乗っけちゃうのが良いのかなと感じました。。 GPUインスタンスだと↑のコメントにもあるようにバッチ処理しないと性能が出せなさそうなので、やるとしたらいったんCPUインスタンス･･･かなぁ･･･

FARGATEのことや、複数EC2で割引など全く知りませんでした。ありがとうございます。

皆様本当にありがとうございます。いろいろ加味した感じ、

LambdaはUXが低下するのでやめた方がいい
GPUインスタンス／サーバー使う系はバッチ処理のノウハウが無いので避けたい
SageMakerは初期学習コストが高そう（偏見）
ECSとCPU EC2を用意するのがなんだかんだ簡単そう？

という気持ちになりました。 EC2+ECS、価格感的にいけそう感わかる方っていらっしゃいますか。。。

自分のPCの感じ、16vCPU（16論理プロセッサ）で、1リクエスト0.5sという感じです（本当はもう少し早そう）。１００リクエストで何円かを見積もりたい･･････。

転送料金に関してのメモ。 EC2からのデータ転送の価格を見て、１音声200kBとすると、ちょっと大目に見つもって、１００クエリが0.002ドル（0.2円）くらいでした。１００クエリ１円だと嬉しい状況なので、たしかにちょっと高めな印象があります。

EC2バックエンドのECSは借りているEC2インスタンスの値段しかかかりません。他サービスを利用されている場合は、それらも加算されますが、ECS単体では、そんな感じです。以下ページのAmazon EC2 起動タイプモデルの記述をご参照ください。 https://aws.amazon.com/jp/ecs/pricing/

ちょっと外れた話になりますが、EC2の割引プランについて。大きく分けて、リザーブドインスタンス(RI)とSavings Planがあります。どちらもコミットメント期間（1年、3年）と支払い方法（すべて前払い、一部前払い、前払いなし）を定めてEC2インスタンスを注文すること(1台からでも可能！)で、割引を利かせるプランです。 RIの方がやや柔軟性には欠ける(途中でインスタンスタイプを変更できないなど)ものの、あまり計算がいらず、継続的な利用が見込まれる初心者にはこちらの方がおすすめです。 SPは手動で計算を行わなければならない部分がありますが、より細やかな調整が効きます。

詳細は以下記事をご覧ください。 https://dev.classmethod.jp/articles/ec2-reserved-instances-savings-plans-comparison/

あ、↑のコメントでも書いているのですが、リクエストを束にして推論する処理（バッチ処理？）って可能だったりするかご存知でしょうか 👀

バッチ処理を行うなら(リクエストを即時に返す必要がないなら)、リクエストはLambdaで受け付けて、その結果をAWS SQSなどのジョブキューにため、ECSのタスクとして消化していく非同期実行モデルが向いていると思います。(AI系の実案件でもよくつかわれるアーキテクチャです) このモデルですと、ECSの起動時間も抑えられ、非常にリーズナブルになります。FARGATE実行でもかなりお安く上がるので、EC2インスタンスを確保する必要がないかもしれません。

FARGATE実行モデルECSの料金計算機置いておきます。 https://calculator.aws/#/createCalculator/Fargate

複数タスクをバッチ処理で処理するのは、SQSからECSにつなぎこむ部分にやや工夫が必要かもしれません。単純な仕組みの場合、問題が発生してUXが低下しやすいため、複数件溜めてのバッチ処理には非機能要件・想定ユースケースをしっかり詰める必要があると思いました。

タスクが一定個数溜まるまで処理しない：タスクが溜まるまで遅延する
一定時間ごとにSQSを確認する：時間間隔によっては、UXはそれほど悪化しない？時間間隔が短いと、バッチ化の恩恵を受けにくい。長いと、処理の遅延が顕著になる。

タスクが一定個数溜まるまで処理しない方法

以下記事では1つSQSにメッセージがたまった段階でApplication Auto ScalingによりECSのタスクを起動していますが、ここを任意のメッセージ数にすることも可能です。(この方法には上記の問題点があります！) https://dev.classmethod.jp/articles/sqs-to/

ありがとうございます！！EC2の割安情報助かります。

FARGATE+ECS

見積もりしてみたのですが、4vCPUで1日1個起動しっぱなしだと月144ドルという感じでした。 4vCPUがMAXなのが若干不安ですが、もし平均２台くらいでさばききれるなら割と現実的かも？と感じました！！

FARGATEってスポットインスタンス？みたいなのもあるんですね！！更に安く済ませられそう･･･？

（2022/07/13 0:22　追記）料金計算してみた感じ、Fargateを使うとEC2の２倍くらいの価格感でした！

バッチ処理

SQSにキューイングするの、なるほどです。さすがにユーザーが永久に待機する可能性がある設計は避けたいので、N個キューされるまで絵待機というのは難しそうに思いました！まあでも、そういうことをしないといけないんだなぁという所感になりました。ありがとうございます！！

EC2でスピードテストしてみました！

t2.xlarge（vCPU 4）だと、１回の音声合成処理時間は平均2.708sでした。 t2.xlargeのオンデマンドは月135.49USDなので、１回辺り135.49USD / (60*60*24*30) * 2.708 = 0.00014ドル　≒　0.019円でした。

（VV_CPU_NUM_THREADS=4で起動） ```csv query_time synthesis_time 0.02676677703857422 3.3489484786987305 0.026238441467285156 3.1128158569335938 0.011199712753295898 1.338841199874878 0.013654232025146484 1.9541845321655273 0.03174781799316406 5.014699459075928 0.022674083709716797 2.9320244789123535 0.018500328063964844 3.205775022506714 0.011795759201049805 1.5339958667755127 0.015993356704711914 1.9789862632751465 0.012011528015136719 1.469980001449585 0.02405834197998047 3.9043123722076416 0.018651723861694336 2.699089765548706 0.022199153900146484 3.108752489089966 0.019413471221923828 3.190329074859619 0.008539438247680664 1.188549280166626 0.026212692260742188 3.7211062908172607 0.0119171142578125 1.6862218379974365 0.025763511657714844 3.9573657512664795 0.01607656478881836 2.4853434562683105 0.015218973159790039 2.343737840652466 0.003171682357788086 0.3137171268463135 ``` （最後の行は空テキストを与えた時の計算時間）

t2.2xlarge（vCPU 8）だと、１回の平均1.6323sでした。 t2.xlargeのオンデマンドは月270.98USDなので、１回辺り270.98USD / (60*60*24*30) * 1.6323 = 0.00017ドル　≒　0.023円でした。 CPU数が増えるとなぜかonnxruntimeの最高パフォーマンスが遅くなるっぽい･･･？

（VV_CPU_NUM_THREADS=7で起動）（8で起動すると←より10%ほど遅くなる） ```csv query_time synthesis_time 0.023202180862426758 2.029160737991333 0.02099299430847168 1.8475663661956787 0.011090278625488281 0.8057591915130615 0.01415562629699707 1.1745893955230713 0.02927255630493164 2.991987705230713 0.020611047744750977 1.7857275009155273 0.01872992515563965 1.9678220748901367 0.011901140213012695 0.9097409248352051 0.014342784881591797 1.1767327785491943 0.011874914169311523 0.8868343830108643 0.029228687286376953 2.3697938919067383 0.018753528594970703 1.6219322681427002 0.01948094367980957 1.8175034523010254 0.019681453704833984 1.9602651596069336 0.008608818054199219 0.6869752407073975 0.030355215072631836 2.262911081314087 0.011705398559570312 0.9971189498901367 0.025743484497070312 2.4498775005340576 0.016227245330810547 1.487729787826538 0.01522970199584961 1.4178199768066406 0.003202676773071289 0.18476152420043945 ```

スポットインスタンスとか使えば価格的にはなんとかなりそうということがわかりました！ちなみにメモリ消費はdocker上で動かしても1GBとかでした。（bufferが＋2GBほど）

GPUインスタンスのg4ad.xlarge（月 276.33 USD）でも速度測定したかったのですが、AWSのvCPU制限に引っかかってEC2を借りれませんでした。スピードテスト用コードがあるので、よかったらどなたか試していただけると嬉しいです🙇 （上の方のdocker起動時にGPUなのかCPUなのかを気をつける必要があります）

↓スピードテスト用コード

```bash 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などで速度を試してみたいところですが、暇つぶし遊んだ結果、有名所のクラウドサービスは無料クレジット使い切ってしまっているのですよね。。。

というわけであくまで素人意見なので申し訳ございませんが、クラウドサービス化して実現したいことを何にフォーカスするかというのが費用耐効果に非常に重要になってくると思います。クラウド維持はけして安くないので、誰に何をさせたいかが重要になってくるかと。（例えばクラウド化でPCなどを持っていないスマホユーザやタブレットユーザなどを対象とするなど。）

そして費用対効果やレイテンシ（例えば九州地方からの通信は東日本DCのAWSに対してレイテンシが当然悪くなります）などを考えると即時応答のサービスはあまり現実的ではないのかなと思っています。

例えばスマホユーザなどが利用できるサービスを構築する場合、費用対効果だけを見ると例えばスマホアプリやWEBサイトなどで読み上げる対象と文章の登録⇨一定時間時間後に出来上がったものをダウンロードなどが現実的かなと。

また、クラウド維持費などを考えるとあまりオープンソースに対して言いたくはないのですが、課金、広告要素なども入れる必要が出てくるかと。

これはある程度までクラウド費用を抑えるためでもあります。課金要素などがなく無制限に利用できる場合、大量に使われた結果非常に大きな費用などがかかりサービスの継続不可に繋がる可能性もあるので。（ちなみに私はプライベートクラウドを運用したときに課金要素を入れずに大失敗しました。） 1日○文字までなら無料で、それ以上は課金してねでもある程度抑えは効くかと

コメントありがとうございます！

スマホでVOICEVOX動画を作れると最高に嬉しい、という感じです。 UX的には、音声合成リクエストを投げて１秒後にレスポンスが返ってくればギリギリOKかなーと思っています。

「音声合成リクエストを投げて、１秒後にレスポンスが返ってくるシステムを、リクエスト辺り0.01円くらいで手軽に作れるか」が気になっています。この価格にできるなら資金回収は頑張ればできそうという所感です。

で、今はサービスをどうするかというより、どう実現するか（そもそも実現するのか）困っている、という感じです！！！

連投すみません。 1秒後のレスポンスとなるとやはりネックになるのはCPU（GPU）パワーですね。ただ当然そうなるとローコストはかなり苦しいと思っています。

あくまで案ですが、例えば思いっきりローコスト（ただしバースト時にはある程度速度が早くなるように）、に振り切るのであればこういったサイトの形式も選択肢に入るかもしれません。（AIに文章を書かせるサイト） ai-novel.com/index.php

要はユーザが応答がなくて不快に思うのが問題の本質であって（当然レスポンスがいいにこしたことはありませんが）、ユーザには処理してますよと最低限の応答を返し、普段利用されていない（一定期間要求がない）ときはサーバを停止、利用者が多いときはサーバを常時起動、などにすれば一度否定されていますがローコストとバースト時の対応に向いているLambdaなど（もちろんAWSに限らずAzureやGCPなども比較する必要はありますが）のサーバレスも選択肢に入れれるかなと？

かなり苦しい

t2.2xlargeだと、１回辺り平均1.6323sの0.023円なので、結構惜しいラインまで来てる感覚ですね！！（目標は1sの0.01円）

かなりいい感じですね。ちなみにちょっと暇つぶしこちらを使ってGCPのRUNで立ててみました。（むやみにサーバレスを押しているわけではなく比較材料として） https://hub.docker.com/r/voicevox/voicevox_engine スクリーンショット 2022-07-13 194237 スクリーンショット 2022-07-13 194252

今のところアクセスは以下のVoiceLink_VoiceVoxTestのexeから。 https://github.com/AquavitKisaragi/VoiceLink/tree/main/VoiceLink_VoiceVox 怖い人は自分でデプロイと言いたいところですが、悪用されると怖いのでアドレスを消しています。アドレスが必要な人は私のツイッターにDM（フォローの必要はありません）ください。

※お金かかると怖いのであまりむやみに使わないでくださいm( )m

ツールはEXE　の後ろにtest.json　のフルパス＋拡張子を消したものを引数にすれば使えます。リクエストが有ればこちらで（いいのですかね？）

GCP Run、なるほどです。AWSにおけるFargateみたいな･･･？ Fargateと同じく最大vCPUが4なんですねー

おそらくですが、python3が入っている環境で↑の「スピードテスト用コード」のbase_urlの中身を変更して実行すると、スピードテストできると思います･･･！！

せっかくなので色々試してみました。東京リージョン（asia-northeast1） CloudRun-cpu4-mem2 CloudRun-cpu4-mem2.txt

CloudRun-cpu4-mem8 CloudRun-cpu4-mem8.txt

CloudRun-cpu8-mem8 CloudRun-cpu8-mem8.txt CPUが多いほうが当然一番早いのですがAVG：2.578025675、MIN：1.185620308、MAX：4.750459194という微妙な結果ただ、コンピュートノード無料のものがなくなっていたため、（ケチって）仕方なく私の自宅からしたので距離の問題もあるかなと（九州島の人間なのでレイテンシはお察し・・・） ※vCPU8コアはプレビューただ色々とプレビュー版の機能もたくさんあるので将来に期待でしょうか？

おお！！！お試しいただきありがとうございます！！！！ vCPU8があるんですね！！

結果見てみました、たしかに同じスペックっぽいAWS EC2に比べてなぜか遅めですね･･･２列ある結果テキストのうち、左側も通信を挟んでるのですが、そちらの遅延が大きくても0.15秒とかなので、ネット通信の遅延というより、純粋に計算に時間がかかってるっぽい印象を受けました。

もしかしたらvCPU8で起動する際に、環境変数VV_CPU_NUM_THREADS=8を与えると速くなるかもです！！（AWS実験した感じ、1つ減らしたVV_CPU_NUM_THREADS=7の方がなぜか速くなったので、7の方が良いかも？）

仮にCloudRunのvCPU8で運用した時、spotインスタンスはなしで、1リクエスト1.5sかかるとすると、値段は（起動しっぱなしで）0.000216ドルでした。EC2と一緒ぐらいだけど、spotが無い分高めになりそうな予感がしました！

環境変数＋実行環境を第2世代（プレビュー）にした結果です。（通信込み）

AVG:1.476187217 MIN:0.7141757011 MAX:2.61952734 CloudRun-cpu8-mem4-pre.txt

AWSの無料枠がある人にAWSのこういったサービス試してもらいたいところですね。

おーーー！！！CloudRun、良いですね！！！！！

AWSの無料枠は弱いマシンしか借りれない印象があります･･･。あと類似サービスはFargateやApp Runnerだと思うのですが、どっちもvCPU 4までしか選択できなそうでした･･･。

ソースコードから自前でビルドしたvoicevox_coreをLambda上で動かすことができました。同梱されているテスト用(?)の音声モデルのみです。元々が雑音入っているため正常に動いているのかは不明です。 Lambdaのプラットフォームが初期のAmazon Linux2であるため、GLIBC2.6が必要です。GLIBC2.6環境でビルドされている製品版バージョンはありますか？

@sutekyara 良い質問だと思うのですが、issueの中身とかなり内容が異なっているので新しくissueを作成してください！

個人的にはGoogle Kubernetes Engineで動かすのがベストかと？何故ならGKEでロードバランサーなどやりやすいと思います。あと他のサービスですが、 GPU Sorobanなどもいいかもしれません。

GPU Sorobanに関してはGpuなので、ある程度早くなると期待が可能だと思われます。あとはrailwayとかどうなんですかね、、、

一応日本において良さそうなホスト業者書いときます。 Akamai Connected Cloud(Linode) Vultr AWS GCP 上記四つは通信速度が速いですね。 Xserver VPS (あまり使ったことないので、わからない)

Xserver VPSは元10Gbps回線ですが各VPSの回線が100Mbpsに制限されてるのであまりよくない。海外の大きいVPS販売者のところは大体回線が強いのでGood

通信速度って問題になりそうですか･･･？（ファイルサイズをちゃんと測定して無いのですが）100Mbpsでもかなり十分なのでは･･･？と思いました。

別に問題はないかと？

1インスタンスに複数人使用となると難しいかもしれないって思いましたけど自分の環境でも30Mbps以下だから別に大丈夫なのか

AWSのGPUインスタンスでスピードテストしました。

テスト結果

2種類のインスタンスでdockerを用いて検証しました。スクリプトやテスト用のテキストはHiroshibaさんが実施されたものと同じものを使用しています。
OSはAmazon Linux 2(CentOS系)で、AWS Deep Learning AMIを使用しています。これはCUDA driverの環境整備等を簡便にするためで、強いこだわりはありません。
リージョンは東京リージョンを使用していますが、コストに拘るなら海外リージョン利用も検討する価値があると思います。(後述) sudo docker run -d --gpus all --rm -p 50021:50021 voicevox/voicevox_engine:nvidia-0.12.3
g4dn.xlarge

スペック詳細

NVIDIA T4 GPU を搭載した G4dn インスタンスは、機械学習の推論と小規模トレーニングのためのクラウドで最も低コストの GPU をベースとしたインスタンスです。また、高性能を提供し、CUDA、CuDNN、NVENC などの NVIDIA ライブラリを使用して NVIDIA GPU 用に最適化されたグラフィックアプリケーションに向けて提供する、費用対効果の高いソリューションです。最大 8 つの NVIDIA T4 GPU、96 の vCPU、100 Gbps ネットワーキング、および 1.8 TB のローカル NVMe ベースの SSD ストレージを提供し、ベアメタルインスタンスとしても利用できます AWS公式の説明より

結果

１回の音声合成処理時間は平均0.884sでした。

g4dn.xlargeの東京リージョンのオンデマンド料金は1時間0.71USDなので、１回辺り0.71USD / 60 / 60 * 0.884 = 0.0001743444ドル ≒ 0.024円でした。(USDJPYレート=135.74の場合) なお、同インスタンスに東京リージョンでリザーブドインスタンスの最も安価になるオプションを適用した場合、1年コミットで1時間0.452USD, 3年コミットで1時間0.314USDになります。SPOTインスタンスの場合は20230514現在1時間0.213USDです。(SPOTインスタンスの価格は需給により変動します)

g4シリーズ価格表(当該ページの記載はバージニアリージョンに準拠) リージョン別の価格はこちらで検索してください

測定結果詳細

``` query_time synthesis_time 0.02489638328552246 1.6001534461975098 0.020208120346069336 0.9578239917755127 0.010573863983154297 0.5661759376525879 0.013429403305053711 0.6297307014465332 0.02842569351196289 1.4706385135650635 0.020006656646728516 0.9023582935333252 0.01765131950378418 0.980482816696167 0.010052204132080078 0.6290700435638428 0.013236045837402344 0.6285145282745361 0.0108184814453125 0.6137146949768066 0.025052547454833984 1.182499885559082 0.018476009368896484 0.8425748348236084 0.018871307373046875 0.9392788410186768 0.016358137130737305 0.9756553173065186 0.0072345733642578125 0.5238518714904785 0.02105093002319336 1.1320126056671143 0.011236906051635742 0.6883666515350342 0.02654743194580078 1.2006776332855225 0.015472412109375 0.77787184715271 0.01444101333618164 0.7395973205566406 0.002521038055419922 0.25136709213256836 total_avg 0.884713 query_avg 0.0165029 synth_avg 0.86821 ```

同一テキストの2回目以降の実行(キャッシュが効いた状態)

コンテナ起動後に、同一テキストを2回以上投入したところ、キャッシュにより劇的に高速になりました。 VOICEVOXのキャッシュ機構を理解できていませんが、もしよく使われるフレーズなどを効率的にキャッシュしておけるなら、実際のスピード/1クエリあたりの実行コストはもっと良くなりそうです。

2回目以降の音声合成処理時間は平均0.253sでした。

測定結果詳細

``` query_time synthesis_time 0.0180666446685791 0.3117506504058838 0.01740741729736328 0.2893500328063965 0.009058475494384766 0.09670352935791016 0.016122102737426758 0.18062114715576172 0.026584863662719727 0.47591495513916016 0.019753694534301758 0.2731199264526367 0.016834497451782227 0.29792189598083496 0.009781837463378906 0.11121034622192383 0.012862205505371094 0.18574190139770508 0.011049747467041016 0.10868000984191895 0.022388935089111328 0.3699069023132324 0.01770472526550293 0.25125837326049805 0.018823862075805664 0.2839834690093994 0.044114112854003906 0.30092501640319824 0.008030414581298828 0.086395263671875 0.023666858673095703 0.35489988327026367 0.011051177978515625 0.13717961311340332 0.021181106567382812 0.3755514621734619 0.015175580978393555 0.2317805290222168 0.014408588409423828 0.21953344345092773 0.0024313926696777344 0.02729344367980957 total_avg 0.25363 query_avg 0.0169761 synth_avg 0.236653 ```

g5.xlarge

g4dn.xlarge(GPU メモリ:16GiB)との比較のため、g5.xlarge(GPU メモリ:24GiB)でも試してみました。インスタンスタイプ別のGPUメモリ搭載量はこちらを参照

スペック詳細

> Amazon EC2 G5 インスタンスは、最新世代の NVIDIA GPU ベースインスタンスで、グラフィック集約型のユースケースや機械学習のユースケースに幅広く使用することができます。 Amazon EC2 G4dn インスタンスと比較して、グラフィックス集約型アプリケーションや機械学習の推論において最大 3 倍のパフォーマンスを、機械学習のトレーニングでは最大 3.3 倍のパフォーマンスを発揮します。 > [AWS公式の説明より](https://aws.amazon.com/jp/ec2/instance-types/g5)

結果

１回の音声合成処理時間は平均0.451sでした。

g5.xlargeの東京リージョンのオンデマンド料金は1時間1.459USDなので、１回辺り1.459USD / 60 / 60* 0.451 = 0.0001827802ドル ≒ 0.025円でした。(USDJPYレート=135.74の場合) なお、同インスタンスに東京リージョンでリザーブドインスタンスの最も安価になるオプションを適用した場合、1年コミットで1時間0.592USD, 3年コミットで1時間0.378USDになります。SPOTインスタンスの場合は20230514現在1時間0.4473USDです。(SPOTインスタンスの価格は需給により変動します)

インスタンス１つの時間あたりの利用料金はg4dn.xlargeの方がg5.xlargeよりも安い一方で、性能を勘案すると1クエリ辺りの料金は実はそれ程変わらないことがわかります。

g5シリーズ価格表(当該ページの記載はバージニアリージョンに準拠) リージョン別の価格はこちらで検索してください

測定結果詳細

``` query_time synthesis_time 0.02126288414001465 1.3500041961669922 0.019745349884033203 0.40387606620788574 0.009683847427368164 0.3476693630218506 0.012989521026611328 0.3098595142364502 0.029577016830444336 0.5685467720031738 0.020060062408447266 0.39247822761535645 0.017429590225219727 0.4195210933685303 0.010463237762451172 0.3631887435913086 0.013083219528198242 0.31838035583496094 0.01094198226928711 0.375002384185791 0.02302074432373047 0.48241591453552246 0.017675399780273438 0.3754544258117676 0.021733522415161133 0.4077765941619873 0.020613431930541992 0.4085204601287842 0.0078125 0.31346654891967773 0.020931720733642578 0.46436166763305664 0.010401010513305664 0.3770442008972168 0.02327418327331543 0.47772932052612305 0.015021085739135742 0.3643345832824707 0.014336347579956055 0.3510587215423584 0.0025496482849121094 0.2578768730163574 total_avg 0.451008 query_avg 0.0163146 synth_avg 0.434694 ```

同一テキストの2回目以降の実行(キャッシュが効いた状態)

2回目以降の音声合成処理時間は平均0.116sでした。キャッシュ有効時の処理速度はg4dn.xlargeの約半分になりました。

測定結果詳細

``` query_time synthesis_time 0.022134065628051758 0.1322472095489502 0.018279552459716797 0.1192317008972168 0.010023117065429688 0.05084872245788574 0.012526988983154297 0.07489228248596191 0.027322053909301758 0.1862034797668457 0.019718170166015625 0.11498093605041504 0.017476558685302734 0.12293243408203125 0.013038396835327148 0.055144309997558594 0.01268768310546875 0.07970023155212402 0.010151863098144531 0.05316805839538574 0.02222156524658203 0.15048933029174805 0.019756555557250977 0.10412144660949707 0.01896047592163086 0.11864757537841797 0.04525446891784668 0.12287712097167969 0.007552623748779297 0.047019004821777344 0.01999807357788086 0.14373230934143066 0.010019779205322266 0.06034588813781738 0.023107290267944336 0.15113615989685059 0.014737844467163086 0.09851574897766113 0.01396489143371582 0.09216952323913574 0.0025713443756103516 0.014553546905517578 total_avg 0.116879 query_avg 0.0172144 synth_avg 0.0996646 ```

その他のGPUインスタンスの選択肢

その他の有力そうなAWSのGPUインスタンスとして以下が挙げられますが、VOICEVOXが動くかどうか(どうすれば動かせるか)が不明であったため検証できていません。もしこの辺りが使えるなら、より安く&速くなる可能性があります。 GPUインスタンスの一覧はこちらを参照ください

g4ad.xlarge

AMD製GPU搭載インスタンスです。東京リージョンの1時間辺りの料金は0.51082USDなので、g4dn.xlargeに比べて安価です。 AMD製GPU * linuxの組合せでVOICEVOXが動くのかが不明であったため検証できていません。 g4シリーズ価格表(当該ページの記載はバージニアリージョンに準拠)

inf2.xlarge

AWS社の独自機械学習推論用プロセッサのInferentiaを積んだ、推論に特化したインスタンスです。AWSの発表によれば、推論系の処理に関して全てのインスタンスで最もコスパが良い(速くて安い)とのことなので、有望かもしれません。参考:Inf2公式ページ参考:AWSの推論用インスタンスInf1について参考:AWS Inf1上でBERTモデルの推論を走らせる―モデルコンパイルから速度比較まで InferentiaでVOICEVOXが動くのかが不明であったため検証できていません。なお、今年初頭リリースした最新式のInf2インスタンスは現状バージニアリージョンとオハイオリージョンのみで提供されています。Inf1インスタンスであれば東京リージョンでも提供されています。

使用リージョンについて

上記の価格は東京リージョンの価格をベースに計算していますが、インスタンス辺りの利用料金は北米のリージョン、特にバージニアリージョンの方がずっと安いです。例えば、東京リージョンで1時間0.71USDのg4dn.xlargeは、バージニアリージョンでは0.526USDです。東京リージョンで1時間1.459USDのg5.xlargeは、バージニアリージョンでは1.006USDです。この傾向はリザーブドインスタンス、Savings Plan、SPOTインスタンスの場合でも同様です。料金の差について公式な理由は説明されていませんが、一般論としては北米のリージョンの方が利用ボリュームが大きいため、規模の経済により安価で提供できるためと言われています。また、SPOTインスタンスの在庫量についても、一般に東京よりも北米のリージョンの方が潤沢な傾向にあると言われています。(=安価になりやすい&中断されづらい) 加えて、最新機能やハードウェアが他リージョンに比べて比較的速くリリースされます。(バージニアリージョンでリリースされて数週間～数年経ってから東京リージョンでもリリースされる、といったことが起きます) 従って、地理的な距離によるNWレイテンシとのトレードオフは発生するものの、東京以外のリージョンを利用する選択肢も検討する余地があると考えます。リージョンとデータサイズごとのNWレイテンシの計測にはAWS公式のツールが利用できます。 https://speedtest.globalaccelerator.aws/#/ また、AWSのバックボーンの通信経路を間借りすることで、地理的な距離を跨いだ通信のユーザ向けのNWレイテンシを改善するGlobal Acceleratorという仕組みもあります。 https://aws.amazon.com/jp/global-accelerator/#:~:text=AWS%20Global%20Accelerator

備考:SPOTインスタンスの留意事項

ご存知かと思いますが、SPOTインスタンスは利用中にAWS側の都合で中断される(2分の猶予期間を経てシャットダウンされる)仕様があります。これはSPOTインスタンスが本質的にAWSインフラの余剰リソースを一時的に安価で貸出すサービスであるためです。従って、SPOTを使ってサービスをデザインする場合は、複数のSPOTインスタンスのクラスターを組んで一部がダウンしてもサービスが継続できるようにするなどの独自の設計が必要になります。(きちんと認識した上で設計すれば普通に使えると思います！) スポットインスタンスの中断 EC2スポットインスタンスのすべて

@lawofcycles 詳細ありがとうございます、とても参考になります！！

キャッシュが効いた状態

VOICEVOXエンジンは特にキャッシュ機構を意図して用意してなかったりします。 FastAPIサーバーが気を利かせてキャッシュしているとか･･････？あるいは内部で使っているonnxruntimeに実はキャッシュ機構があるとか･･･。ちょっと全くわからないですが、知らないテキストが来る方が圧倒的に多いはずなので、遅い方を検証するのが目的にかなっていそうだなと思いました！（何かよくわからないけど避ける）

SPOTインスタンス

あ、そんなに価格変わるんですね！！ g4dn.xlargeだと１リクエスト0.0071円、g5.xlargeだと0.0076円。更にリージョンを変えるともしかしたら更に3/4倍くらいの価格感なんですね！

最初のなんとなく考えたのが１リクエスト0.01円ならという感じなので、その値を下回れそうというのがとてもよくわかりました、ありがとうございます！！

ここまで来るとaws cdk使って使いやすいクラウドVOICEVOX APIを作るコードをOSSで作るとかも面白そうに思いました！！（いわゆるIaC）

ちなみにVOICEVOX APIの見えてる需要はこんな感じです。

VOICEVOX公式スマホアプリからの利用（未定）
web上で使えるVOICEVOXデモ（未定）
有料VOICEVOX APIの提供（未定）
VOICEVOX APIサーバーを建てる（音声合成を使いたいアプリ開発者など）

このあたりに役立つような最大公約数的な機能があると良さそうかも。とりあえず動けばいい感じだと、スポットインスタンスを使うとか、ユーザーごとの実行頻度スロットリング機能（認証？IPアドレス？）とか。より進んだ機能だと、オートスケールとか、混み具合返すとか･･･！そしてそれらが動くためのインフラ一式があるとすごく楽しいかもとか思いました！

Spotは確かに安いのですが、ホストサーバーのリソースがフルに近づくと、勝手に止められる恐れが。。。

AWSだしさすがにないのでは？ (Spotに関しては触ったことないので分かりませんが...)

いや、spotって確かホストで余ったリソースがある限り運用できるサービス逆に余らなくなると、vm消す必要が出てくる

CPU100%になったら別料金じゃないっけ自分の記憶違いかな

いや、停止だったはず

多くの方々の貢献により、クラウドでの費用感が明確化できたと考えています。
また、示された発展の方向性も #682 で個別 issue 化されています。

@Hiroshiba
本 issue は役割を果たしたと考えます、更なる論点がありそうでしょうか？（close可能？）

そうですね、計測して温度感が掴めたので完了だと思います！皆様ありがとうございました！！！

VOICEVOX / voicevox_engine