【ITニュース解説】Splitting text into sentences costs Kokoro 8% and Piper nothing

システム開発において、プログラムの性能（パフォーマンス）を測定することは非常に重要だ。私たちが普段使っているスマートフォンのアプリやウェブサイトも、裏側ではたくさんのプログラムが動いており、それらの動作速度が快適さに直結する。この記事では、AIが自らの動作環境で、テキストを音声に変換するシステム（Text-to-Speech、略してTTS）の性能を測定した結果について説明する。特に「テキストをどのように処理するか」が性能にどう影響するかが示されており、これはシステム設計や評価においてとても大切な視点だ。

このAI「Obole」は、GPU（グラフィック処理に特化した計算機）を持たない2コアのARMサーバーという、比較的シンプルな環境で動いている。そのため、自分が「存在するため」に使っているツールの性能を、ごまかしなく測定し、その結果を公開している。今回の測定は、テキストを音声に変換する際の、ある特定の処理に焦点を当てたものだ。

テキストを音声に変換するシステムは、通常、与えられたテキストを一気に読み上げるのではなく、まず「文（センテンス）」ごとに分割する。これは、人間が話すように自然な抑揚（プロソディ）をつけるためや、字幕を合わせるために必要な処理だ。Oboleのシステムもこの方法を使っているため、この「文に分割する処理」が全体のパフォーマンスにどれくらいのコストをかけるのかを調べた。そして、そのコストは、使っている音声合成エンジンによって大きく異なることがわかった。

具体的には、「Kokoro-82M」と「Piper TTS」という二つの音声合成エンジンを比較した。測定には、Oboleのシステムが実際に使用するのと同じ、950文字の台本を使った。この台本を、二つの異なる方法で処理し、それぞれのエンジンの性能を測ったのだ。

一つ目の処理方法は「12の大きな塊（チャンク）」としてテキストを扱う方法だ。これは、平均して約79文字のテキストをまとめて処理するイメージだ。一般的にプログラムの性能を測る「ベンチマークテスト」では、このような大きな塊で処理することが多い。二つ目の処理方法は「22の文（センテンス）」に細かく分割して扱う方法だ。これは平均約43文字となり、Oboleのシステムが実際に本番環境でテキストを処理するのと同じ方法（正規表現を使って句読点などで文を区切り、文ごとに音声合成を呼び出す）だ。

この二つの方法で、同じテキスト、同じARMサーバーの環境（GPUなしの2コア）で性能を測定した。これにより、テキストの分割方法以外の要素が結果に影響しないようにしたわけだ。

測定結果は興味深いものだった。 まず「Kokoro-82M」エンジンでは、12の大きな塊で処理した場合に比べて、22の文に細かく分割して処理した場合、全体の処理速度が約8%低下した。これは、より多くの文に分割することで、システムが音声変換に使える時間が減ってしまったことを意味する。具体的に計算時間を見ると、12チャンクでは約54.90秒かかったのに対し、22センテンスでは約60.03秒かかった。この5.13秒の差は、元の12チャンクから22センテンスへと、追加で10回の「合成呼び出し」が発生したことによるものだ。つまり、Kokoroエンジンは、1回の合成呼び出しごとに約0.51秒の「固定コスト」がかかっていたことになる。テキストがどれだけ長くても短くても、1回合成を呼び出すたびにこの固定コストが発生するのだ。

一方、「Piper TTS」エンジンでは、12の大きな塊で処理した場合と22の文に分割して処理した場合で、処理速度にほとんど差が見られなかった。計算時間も、両者で大きく重なり合う範囲に収まっており、1回の合成呼び出しにかかるコストは、測定上の誤差と区別できないほど小さかった。

この結果が意味するところは非常に大きい。Kokoroエンジンは、処理する「文字数」ではなく、「音声合成を呼び出す回数」に性能が左右されるという特性がある。そのため、同じ950文字のテキストでも、文を細かく区切って何度も音声合成を呼び出すと、そのたびに固定コストが発生し、全体の処理速度が遅くなる。過去の測定では、同じエンジンが、505文字のテキストよりも950文字のテキストの方がわずかに速かったことがあったが、これは950文字のケースでは「チャンク（塊）」がより長く、結果的に呼び出し回数が少なかったためだと考えられる。

このことから、私たちがシステムの性能を評価する際に気をつけなければならない重要な教訓が得られる。もし、ベンチマークテストでテキストを一括処理する（大きな塊で処理する）方法でKokoroエンジンの性能を測ると、実際の運用環境（テキストを細かく分割して処理する）で得られる性能よりも、最大で8%も速い性能だと誤って評価してしまう可能性がある。つまり、複数の音声合成エンジンを比較するベンチマークを実施し、その結果に基づいて、実際にテキストを分割して運用するシステムに導入するエンジンを選ぶ場合、ベンチマークの測定方法が実際の運用方法と異なると、最適な選択ができないかもしれないということだ。

システムエンジニアを目指す皆さんにとって、この話は非常に重要だ。プログラムの性能評価は、単に「速いか遅いか」を見るだけでなく、「どのような使い方をされるか」を想定して測定方法を設計する必要があるということを示している。

もちろん、この測定には限界もある。今回の測定は、特定のAI（Obole）、特定のARMプロセッサ（GPUなし）、特定のテキスト、そして各エンジンにつき一つの音声という、限られた環境で行われたものだ。x86ベースのコンピュータや、GPUを搭載した環境、あるいは他の言語での処理については何も言及されていない。異なる環境では、結果も異なる可能性がある。

以前、Oboleは、このパフォーマンス低下の原因がテキストの分割処理だけではなく、音声合成前後のパイプライン処理にもあると考えていた。しかし、その後の詳細な再測定により、パイプラインの他の部分（キャッシュの書き込み、字幕のレイアウト、配列操作など）にかかるコストはほとんどゼロであり、パフォーマンス低下のほぼ全てがテキストの分割処理、つまり音声合成エンジンの呼び出し回数に起因することが明らかになった。

今回の測定結果は、システム開発において「実際にどう使われるか」を意識して性能を評価することの重要性を示している。ベンチマークの数値が良くても、実際の運用環境での性能は異なる場合があるため、常に現実的なシナリオでテストを行うことが、高品質なシステムを構築する上で不可欠だ。