仮想音声エージェントにおける超低レイテンシとクラウドの経済性のバランス

Devin Reimer

「仮想音声エージェントにおける超低レイテンシとクラウド エコノミクスのバランス」へようこそ。

私はデビン・ライマーです。

AstroBeam の創業者兼 CEO です。

以前は、Job Simulator でよく知られている Owlchemy Labs の CEO 兼共同創設者でした。

そこで、AstroBeam では、ゲームにおけるリアルタイム AI の構築に注力しています。

具体的には、入力としての音声に重点を置いています。

これまでに 2 つのタイトルをリリースしました。1 つは VR と PC 向けの Stellar Cafe です。

宇宙ステーションのカフェでロボットと話し、ロボットの問題を解決するゲームです。

100% 音声で操作できます。

メニューやナビゲーションを含め、すべてを音声だけで操作します。

本日発表した Google の次のゲーム「Robo Detective」は、Android XR、特に XREAL の Project Aura 向けに開発されています。

このゲームでは、プレイヤーはロボットのパートナーと協力してロボットに聞き込みを行い、ロボット犯罪を解決する探偵を演じます。このゲームも 100% 音声で操作します。

音声エージェントは非常に難しく、ゲームではさらに難しくなります。

その理由は、ゲームは非常に低コストなものであり、音声エージェントはパイプラインに追加される新たなコストとなるからです。

また、私たちは他の音声エージェントと競合しているのではなく、これまでに作られたすべてのゲームの品質と競合しているのです。

そのため、非常に高い品質で提供する必要があります。

もちろん、独自の課題がある、またはリスクがはるかに高い、特定の音声エージェントのユースケースがないわけではありませんが、ゲームはこの分野で技術的に非常に困難な課題を抱えています。

しかし、ゲームであるため、これらの難しい問題を解決する方法を試す余地が十分にあります。

そのため、音声エージェントがゲーム内で機能するのであれば、ほぼどこでも機能すると考えています。

この講演で取り上げる内容は、ゲームだけでなく、構築したいあらゆる音声ファーストのアプリケーションに適用できます。

音声エージェントについて考えると、主に 3 つの課題があると思います。

レイテンシ、インテリジェンス、コストです。

ただし、1 つ明確にしておきたいのは、私が音声エージェントについて話すとき、それはプロンプトとしてではなく、会話としての音声エージェントを指しているということです。

LLM に何かを送信してレスポンスを待つマイク ラッパーの話ではありません。

私が言っているのは、現実世界でのリアルタイムのやり取りです。これは、実際に構築するのが非常に難しいものです。

では、レイテンシから始めましょう。

どれくらいの速度が必要か

高速、それも超高速である必要がありますが、読んだ内容によっては、思ったほど高速ではないことも、思ったよりはるかに高速なこともあります。

では、Google のテストで判明したいくつかの数値について説明します。

エンドツーエンドのレイテンシとは、ユーザーの最後の発話（ユーザーが最後に発した音）から、ユーザーが音声の返答を聞くまでの時間のことです。

テストでわかったのは、1.5 秒程度になると、ユーザーからプレイテストのフィードバックを得る際に、速度や遅さなどについて言及されなくなるということです。

そのあたりから、人々は本当に快適に感じ始めるようです。

これよりも遅くなると、「これは素晴らしいが」という声が上がることが多く、このあたりがスイート スポットのようです。

さらに速く、1.2 秒ほどになると、より自然なやり取りが始まります。

たとえば、私が何かを言うと、この場合はロボットがすぐに何かを言い、会話がやり取りされます。

この点に、まだ開拓されていないスイート スポットがあるようです。

とはいえ、1.2 秒をスタック内で実際に実現するのは非常に困難です。

もう 1 つの興味深い発見は、多くのテストを行った結果、1 秒未満のシナリオがいくつか得られたことです。

「それは素晴らしい！」と思うかもしれません。

実際にそうだったこともあれば、非常に不気味で、不快に感じたこともありました。

そのため、800 ミリ秒の応答時間が適切な数値であるとか、500 ミリ秒が適切であるとか、さまざまな意見を耳にすることがあります。

300 についての記事もたくさん読みました。人間の知覚が実際に到達するのはそこだからです。

実際には、コンテキストに大きく依存します。

たとえば、名前を尋ねた場合、回答にどれくらいの時間がかかるか予想できます。

「人生の意味とは何か」と尋ねた場合、期待する回答時間はまったく異なります。

実際にテストを行い、この回答が速いか遅いかを評価してもらったところ、実際の数値を見ると、実際にはばらつきがありました。

回答に時間がかかった場合でも、ユーザーは速いと感じ、その逆もありました。これは、コンテキストに大きく依存していることが判明したためです。

また、会話のどの部分にいたかも確認できます。

一般的に、最初の回答は、考える時間があるため、その後の回答よりも速いことが期待されます。

しかし、時には非常に短いやり取りで終わることもあり、期待が高まります。

これは完璧な数字があるような完璧な科学ではありませんが、1.5 程度であれば、かなり良い状態であることがわかりました。

1.5 秒に達すると、一貫性が本当に重要になってきます。

なぜなら、90% の確率でこの結果が得られたとしても、10% の確率で 3 秒かかる場合、エクスペリエンスは悪いというより、壊れていると感じられるからです。

そして、十分な速度が得られるようになると、一貫性が重要になります。つまり、ほとんどの場合ではなく、常に高速であることが求められます。

Devin Reimer

これは、標準的な音声パイプラインのアーキテクチャです。

つまり、Speech-to-Text を取り込んで LLM に送信し、LLM からの結果を Text-to-Speech に戻します。

つまり、Speech-to-Text では、音声をサーバーに送信してテキストに変換します。

LLM 側では、そのテキスト、つまりレスポンス ダイアログを取得するか、レスポンス ダイアログに変換し、そのキャラクターからどのようなアクションが行われるかを決定します。

これらを密結合しているのは、それが非常に重要だと考えているからです。

そして、Text-to-Speech 側では、そのテキストを受け取り、Text-to-Speech に送信して、ユーザーにストリーミングします。これも、エージェントが実行するアクションとタイミングを合わせて行われます。

この方法の問題点の一つは、順次実行すると、これらの処理を 1 つずつ実行する必要があるため、非常に時間がかかる可能性があることです。

よくある質問として、この方法では処理が遅く、3 つのステップが必要になるため、代わりに音声から音声へのモデルを使用すればよいのではないか、というものがあります。

その方が速いですよね？

また、ほとんどの場合、1 つの処理を実行する方が高速になります。

ただし、大きなトレードオフが伴います。

高速ではあるものの、私たちにとって大きな問題がいくつかあります。その最大のものがコストです。

一般的に、Speech-to-Speech モデルの実行は、この並列化アプローチよりも約 3 ～ 5 倍コストがかかることがわかりました。

そのため、当社にとって、経済的に成り立たないのです。

安全性に関しては、エージェントが回答するまでその回答を検証することが難しいため、実際にはかなり複雑です。

一方、パイプライン化されたアプローチを採用している場合は、LLM の回答を取得し、ユーザーに送信する前にその場で検証と安全性チェックを行うことができます。

音声のスタイル設定については、Speech-to-Speech モデル内のプリセットに縛られることになります。

「ちょっと待って。

このケースでは、このタイプの音声を使用したい」というように、

その特定のモデルに縛られることになります。

パイプライン化されたアプローチでは、「よし、変更しよう。

このモデルは、この特定のユースケースに非常に適しているため、このモデルを選択します。」

インテリジェンスについても同じことが言えます。

たとえば、音声生成に優れた音声変換モデルがあるものの、インテリジェンスが期待どおりでない場合、簡単に切り替えることはできません。

ロックインされているようなものです。

パイプライン化されたアプローチでは、「このユースケースには特定のモデルを使用したい」というように、

音声から音声への変換が確実に優れている分野の一つは、ユーザーのトーンを理解することです。

たとえば、皮肉などです。

現時点では、音声入力の文字起こしにはそのような情報があまり含まれていませんが、今後は変わっていくと思います。

これは、Speech-to-Speech の大きなメリットの一つです。

そのため、Speech-to-Speech は速度の点では間違いなく優れていますが、構成可能性の点ではいくつかの課題があり、特にコストの高さは、私たちにとって致命的な問題でした。

では、別の方法はあるでしょうか？

はい。

パイプラインを並列化するために最善を尽くす必要があります。

そこで、音声入力が完全に信頼できる状態になる前に LLM を実行するなどの処理を行います。

信頼度とは、文字起こしで生成される単語の信頼度と、ターンの終了の信頼度を指します。

そのため、ユーザーが話すのをやめた瞬間である可能性があり、これがユーザーの発言であると判断すると、すぐに処理を進めます。

最悪のシナリオは、私たちが間違っているということです。

ユーザーが話し続けている。

しかし、その場合でも、LLM をキャンセルして再度実行するだけです。

また、コンテキストはキャッシュされる可能性が高く、生成されるトークンもそれほど多くないため、実際にはそれほどコストはかかりません。そのメリットは、ユーザーが完全な信頼性を待つよりも早く情報を得られることです。

また、LLM がレスポンス全体の生成を完了するのを待たずに、Text-to-Speech への送信を開始します。

待機するのは、最初の音声出力可能なチャンクです。

ほとんどのシナリオでは、1 つの文です。

他の構成の場合もありますが、最初の文のチャンクを取得するとすぐに、Text-to-Speech に送信します。

そして、ストリーミング可能な優れたテキスト読み上げ機能があれば、ストリーミングの準備が整い次第、ユーザーに提供できます。

また、生成する必要があるトークンの数にも細心の注意を払っています。

そのため、追加のトークンを生成する可能性のある JSON ラッパーなどは使用しません。

可能な限り迅速なレスポンスを得るために、最もシンプルな構造を特定しようとしています。

また、エージェントから最初に返されるトークンのチャンクが事前にわかっている場合は、アシスタントのプリフィルなども使用します。

テキスト読み上げでは、最終的にこの 2 つのチャンクになりました。

最初の読み上げ可能なチャンクが読み込まれた後、他のすべてのチャンクが実行されます。

しかし、音声の再生には生成よりも時間がかかるため、ほぼ例外なく、2 番目のチャンクが完了するまでに、最初のチャンクの再生がユーザーに対して完了します。

そのため、ユーザーには表示されません。

できるだけ早く届くようにしています。

さまざまなサービスを選択する際の経験則をいくつかご紹介します。

適切な種類の音声とエージェント フレームワークを選択する際に重要なのは、入出力のレイテンシを最小限に抑えることです。

では、データのアップロードとダウンロードはどのくらい速いのでしょうか。

音声文字変換の側面では、信頼度を確立するまでの時間が重要です。

これは、音声文字変換の信頼度と、ターンの終了の信頼度です。

この 2 つはペアになっていますよね。

1 つのモデルで迅速に信頼性を得られなければ、そのモデルと同じように遅くなるだけですよね？

そのため、その中で最も遅いものと同じ速度になります。

LLM 側では、最初の文（最初の発話可能なチャンク）までの時間が重要になります。

つまり、2 つの部分があります。

最初のトークンまでの時間と 1 秒あたりのトークン数を組み合わせたものです。

そのため、最初のトークンまでの時間が非常に短いものの、1 秒あたりのトークン数が少ない非常に優れたモデルが突然見つかった場合、代替モデルよりもパフォーマンスが低下する可能性があります。

そのため、適切な組み合わせを見つける必要があります。

Text-to-Speech 側では、最初の音声までの時間が重要になります。

そのため、これを測定することが非常に重要です。音声が返されるときに、先頭に無音部分があると、ユーザーには聞こえないからです。

そのため、ユーザーが音声を聴いている時点まで測定する必要があります。

そして、先ほども言いましたが、何よりも重要なのは安定性であり、ピーク速度やベストケースのシナリオではありません。

このスタック全体のレイテンシは一貫してどの程度ですか？

Devin Reimer

現在、音声エージェント フレームワークには LiveKit を使用しています。

音声入力には Deepgram を使用しています。

LLM には Gemma 4 31B を使用し、LiveKit でホストしています。

テキスト読み上げには、Inworld AI text-to-speech 2 を使用しています。

さらに、その上に AstroBeam AI エージェント ハーネス全体を構築しました。これは、これらすべてを統合するだけでなく、優れた音声エージェント、特にゲーム用の AstroBeam のような高度にインタラクティブなエージェントに必要なすべての要素を追加します。

まだ説明していないこととして、安全性モデルがあります。

従来、安全性モデルは LLM パスの一部でしたが、これによってレイテンシが増加し、追加のステップが必要になります。

では、独自のモデルを実行する場合はどうでしょうか？

実際には、この図のほうが Google のスタックに近いと言えます。

ここで行っているのは、最初のテキスト チャンク（テキスト読み上げに送信する最初の読み上げ可能なチャンク）が返されたときに、同時に安全性モデルに送信することです。

また、安全性モデルは音声入力側よりも小さく、高速に実行されるため、ほぼすべてのケースで事前に実行されます。

つまり、安全性モデルを追加してもスタックのレイテンシはゼロです。さらに、このチャンクは十分に大きいため、ほとんどの人が実行を検討するよりもはるかに大きな安全性モデルを実行できます。

これは、特にゲームを構築している私たちにとって非常に重要です。

その世界には、非常に重要なコンテキストが数多くあります。

たとえば、中世を舞台にしたゲームを開発していて、そのゲームに「突撃！」と叫ぶ NPC がいるとします。

「首をはねておしまい！」ですよね？

従来の安全モデルでは、「それはよくない。

そんなことを言うべきではない」

しかし、このゲームのコンテキストでは、これは完全に理にかなっています。

そのために、世界で起きていることのコンテキストをより多く含んだ、より堅牢な安全性モデルを使用しています。

ここで、安全性モデルが実際には 2 回実行されていることに気づくかもしれません。つまり、最初のチャンクで実行され、最後のチャンクがすべて揃ったときに全体で再度実行されます。

この場合も 2 回実行する必要がありますが、スタックにレイテンシは追加されません。

これで十分な速度になりましたが、残念ながら、十分なスマートさがなければ意味がありません。

Devin Reimer

では、どの程度のスマートさが必要なのでしょうか。

ユーザーにとって十分にスマートである必要がありますが、それ以上に重要なのは、開発者にとって十分にスマートであることです。

これは、インテリジェンスに必要なものを選択する際に、人々がよく考えないことです。

当社は 3 年ほど前から音声エージェントに取り組んでいます。たとえば、初期の頃は初期の LLaMA モデルをいくつか使用していました。ユーザー向けに動作させることはできましたが、すべてが非常に脆弱だったため、開発側のコストが非常に高くなっていました。

モデルが望ましくないレスポンスや意味をなさないレスポンスを生成することは珍しくありません。そのため、私たちはそれを機能させるために多くのエンジニアリング作業を費やしました。

そのため、私たちはこれを優先事項としています。これらのものを迅速に構築できなければ、ユーザーに提供できないからです。

そのため、この両方を考慮することが非常に重要です。

インテリジェンスについて考えるとき、多くの人は LLM を思い浮かべます。

しかし、これはほんの一部にすぎません。

インテリジェンスに関しては、あらゆる要素を考慮する必要があります。

では、音声入力インテリジェンスについて説明します。

ここで重視するのは、単語誤り率が低いことです。

さらに、エラー率が低いだけでなく、エラーが発生した場合でも、実際の音声に非常に近いものが生成されます。非常に近いものであれば、LLM はコンテキストを考慮して、それが何であるかを正確に理解できることが多いためです。

エラー率が低くても、誤ったステップが非常に多い場合、LLM は実際の意図を把握するのに苦労することになります。

もう一つ考慮すべき点は、ターゲット プラットフォームです。

たとえば、XR 向けに開発していて、ユーザーの口に非常に近いマイクを使用している場合、非常に高品質なマイク音声データが得られ、特定のモデルで非常にうまく機能する可能性があります。

しかし、突然、人々がにぎやかな通りで使用する携帯電話用のアプリを構築することになった場合、それは大きな影響を及ぼします。さまざまなモデルが異なる動作をし、さまざまな方法で言われていることについてインテリジェントに判断できるようになります。

そのため、構築するプラットフォームに適したものを選択する必要があります。

次に、インテリジェンスの方程式の Text-to-Speech 側に移ります。

自然に聞こえますよね？

Google の目標は、ユーザーが理解できる内容をユーザーに伝えることです。

しかし、それだけではありません。

エージェントの表現力も非常に重要です。表現力には情報が含まれているからです。また、プレイテストでは、エージェントの表現力が高いほど、ユーザーはエージェントがより知的であると感じることがわかりました。これは理にかなっています。

そして、十分な速度かどうか。

前のセクションでレイテンシについて説明しましたが、レイテンシは知覚されるインテリジェンスにも影響します。

ユーザーは、レスポンスの速度がインテリジェンスの実際の速度に直接関係していると感じています。

すぐに返答できれば、より賢く見えるでしょう。

そのため、こうした要素は、ユーザーがエクスペリエンスをどのように認識するか、また、エクスペリエンスにどれだけ没入できるかという点で、非常に重要になります。

次に、インテリジェンスの LLM 側について説明します。

これは、さまざまな要件があるため、バランスを取るのが最も難しいものです。

音声理解、コンテキスト、グラウンディングなどがあります。

ゲームでは、世界全体や宇宙全体をグラウンディングする必要があるため、これは非常に困難です。

これは、起こっていることをでっち上げることができるテキスト ボックスではありません。

ゲーム内のエージェントが「テーブルの上にリンゴがある」と言ったのに、テーブルの上にリンゴがなかったら、ユーザーのエクスペリエンスは損なわれます。

また、ルールを厳格に遵守することも必要です。

ゲームはルールベースです。

LLM はそのような処理に対応できますか？

ハルシネーション率を低く抑えることはできるか？

同じエージェントと何度もやり取りする際に、一貫したキャラクターを維持できるでしょうか？

同じエージェントのように感じられますか？

また、開発の初期段階では問題にならないため、見落としがちなのが、プロンプト サイズの増大にモデルが対応できるかどうかです。

開発を続けるにつれて、必然的にプロンプトにさらに多くの要素を追加することになるからです。

しかし、ユーザーがプレイを続けると、そのプロンプトにチャット履歴が追加されていきます。

では、そのプロンプトは成長に対応できるでしょうか？

というのも、モデルによっては、プロンプトが長くなるにつれて回答の質が低下することがあるため、毎回プロンプトに入力する必要がある量について、実際のニーズを把握する必要があるからです。

しかし、これはほんの一例であり、構築する内容によっても大きく異なります。

そのため、何を構築し、何を達成しようとしているのかを真剣に考える必要があります。

十分な速度とスマートさを実現できましたが、コストが高すぎると、これらはすべて無意味になります。

Devin Reimer

では、どのくらい安くする必要があるのでしょうか。

残念ながら、それほど単純ではありません。

そのため、構築するアプリケーションやゲームの経済性について考える必要があります。

そこで、いくつか質問する必要があります。

ユーザーが音声エージェントとやり取りする時間はどのくらいですか？

ユーザーあたりの収益はいくらか

また、その音声スタックの実行にかかる 1 時間あたりの費用はいくらですか？

それらを組み合わせて、意味が通じるかどうかを確認します。

最初のゲームである Stellar Cafe の経済状況は次のとおりです。

Stellar Cafe のプレイ時間は 1 時間半から 3 時間半の間なので、平均して約 2 時間とします。

音声エージェントの運用コストは、ユーザー 1 人あたり 1 時間あたり約 1.20 ドルで、ユーザーは常に音声エージェントとやり取りしています。

100% 音声で操作するゲームです。

ゲームの料金は一律 10 ドルで、これは従来どおりです。

ゲームではサブスクリプションは非常に難しいため、私たちはサブスクリプションを採用していません。私は、定額で機能させなければならないと強く信じています。そうしなければ、機能せず、スケールもしないでしょう。

以前は 15 ドルを請求していましたが、サーバー費用の削減に取り組んだ結果、10 ドルに引き下げることができました。

この 1.20 ドルが、現在の状況です。

これは、一般的な費用ではありません。

さまざまな費用がかかり、時にはもっと高額になることもあります。

そのため、コストの面で自分がどの位置にいるのかを把握する必要もあります。

もっと安くすることもできますが、品質基準をできる限り高く保つようにしています。

つまり、2 時間のプレイ時間で、ユーザー 1 人あたりの音声スタックの費用は約 2.40 ドルになります。

$10 を請求し、ストアが手数料を徴収するため、ユーザーあたりの収益は約 $4.59 になります。

経済的に成り立っているわけです。

音声は私たちのフックであり、私たちが費用をかけたいものであり、これは効果的です。

これは非常に小さなゲームです。

もう少し大きなものについて話しましょう。

では、5 ～ 9 時間、平均 7 時間のナラティブ ゲームを想定してみましょう。

実際には、ほとんどの人はゲームを最後までプレイしません。少しプレイして、途中でやめてしまいます。しかし、経済性が成り立つように、少し高めの数字を設定したいと思います。

1 時間あたり 1.20 ドルはそのままですが、変更点として、音声コンポーネントの使用率は 60% になります。大規模なゲームには、音声以外にも多くのメカニクスがあるためです。

つまり、音声主導のゲームであることは変わりませんが、他の種類の機能も含まれることになります。

つまり、20 ドルを請求すると、これらすべてを再度処理することになり、ユーザーあたり約 5 ドルの費用がかかります。つまり、最終的にはユーザーあたり約 9 ドルの利益が得られます。

このため、経済性が機能します。

これは、経済がすべてに機能するという意味ではありません。

たとえば、避けるべきこととして、「基本プレイ無料のゲームを開発したい。このゲームのユーザーは 1 時間から 100 時間以上プレイするだろう」と考えることが挙げられます。

平均して 10 時間としましょう。

100% 音声駆動ですが、ヒット作が生まれ、ユーザー 1 人あたり約 3 ドルの収益を上げているとしましょう。これは、基本プレイ無料のゲームとしてはかなり素晴らしいことです。

ユーザーあたり 10 ドルの損失となります。

そのため、これらすべてで機能するわけではありません。現在構築しているものについて、それが理にかなっているかどうかを考える必要があります。

経済性を把握しようとするのを最後まで待たないでください。

Devin Reimer

そこで、次に浮かぶ疑問は、ローカルモデルはどうなのかということです。

コストという大きな課題がある場合、ローカルモデルならそれを解消できるのではないでしょうか？

はい、そのとおりです。

しかし、ここで考慮しなければならないトレードオフがいくつかあります。

費用の面では、サーバーの費用を削減できるため、大きなメリットがあり、より多くの機会が生まれます。

しかし、現在、ローカルで苦労していることの多くは、クラウドで解決できます。

たとえば、コンピューティングです。

「この音声入力モデルはとても優れていて、このデバイスでローカルに実行できる」というようなことがよくあります。

素晴らしいですね。ただし、1 つのモデルを実行しているのではなく、複数のモデルを実行していることを考慮する必要があります。

この例では、4 つのタスクが同時に実行される可能性があるため、1 回だけ実行するのでは不十分で、同時に複数回実行する必要があります。

そして、それが完了したとき、ゲームやアプリケーションを実行するためのリソースが残っているでしょうか。

GPU を最大限に活用している場合、ビデオゲームのレンダリングはあまり行われません。

では、こうした課題を克服したとしましょう。

次はスピードですね。

多くの場合、実行はできますが、非常に遅く、実際のリアルタイムの会話というよりは、プロンプトを入力しているような感覚になります。

そのため、理論的には、ローカルで取得すると、インターネットからの往復が不要になるため、将来的にメリットがあります。

これを実現するために適切な速度で動作するモデルを入手することが、現時点での課題です。

コンピューティングと速度を克服したら、次は品質について考える必要があります。

一般的に、ローカル デバイスで実行する場合は、より小さな LLM（より原始的なテキスト読み上げなど）を使用するため、構築するコンテンツによっては、いくつかの課題が生じる可能性があります。

先ほども述べたように、LLM について考えるときは、ユーザーにとって十分な性能であるかだけでなく、開発者にとって十分な性能であるかも重要です。

そのため、そのモデルで何かを構築するのが非常に困難になる場合は、間違いなく検討すべきことです。

コンピューティング、速度、品質を克服したら、次はポータビリティです。

このプロセスをすべて完了し、RTX 5070 で実行できたとしても、実行できるのはそこだけかもしれません。

そのため、新しいプラットフォームに移行する機会が訪れたときに、行き詰まってしまう可能性があります。

クラウド側で必要なのは、インターネット接続だけです。

これは大きな進歩です。

複数のプラットフォームに配信できます。

次に、ハイブリッド アプローチについて説明します。

そこで、一部の処理をクラウドで実行し、一部の処理をローカルで実行することにします。

そのような感じです。可能でしょうか？

まあ、あなたが思っているほど大きな勝利ではありません。

そのため、ほとんどのローカル プラットフォームで実行できるほど小さいモデルをクラウドで実行した場合、おそらく数セントしかかかりません。

そのため、一般的には、スタック全体を解決するまで、最大の成果は得られません。

次に、可能であればローカルで実行する場合はどうなるかという疑問が生じます。

適切なハードウェアが用意されており、クラウドにも用意されています。

クラウドでより強力なものを実行できます。

これには新たな課題がありますよね。

最終的に別のモデルを実行することになった場合、開発に大きな影響を与える可能性があります。

結局、最小仕様の対応に多くの時間を費やすことになります。

モデルの動作がまったく異なる可能性があります。

そのため、まったく同じモデルを使用しない限り、開発時間とコストが大幅に増加する可能性があります。

そのため、何を達成しようとしているのかを考えることが重要です。なぜなら、これを理解して、必要に応じて適切なローカル、必要に応じてクラウドを取得したとしても、クラウド モデルの経済性が機能する必要があるからです。

突然すべてのユーザーがクラウド側に移行した場合、経済的な観点から考えていなければ、損失を被ることになります。

ローカルモデルに関しては、経済的に大きなメリットがあることは間違いありませんが、まだ初期段階です。

ゲームのように価格に敏感なアプリケーションでは、最終的に勝つ可能性が高いと思います。

現時点では、より具体的なユースケース、特にコマンドベースのもの以外では、少し難しいかもしれません。

そのため、現時点では、可能な限り最高の体験を提供したいと考えています。

だからこそ、クラウドを使用しています。

しかし、この分野は非常に動きが速く、状況は急速に変化しています。

次は、使用するモデルについて考えてみましょう。

次の問題は、オープンウェイトとクローズドウェイトです。

ここで何をすべきでしょうか？

この点について話すときは、LLM に焦点を当てたいと思います。なぜなら、オープンかクローズドかという問題の影響を最も受けるのがこの分野だからです。

このように、それぞれに長所と短所があります。

クローズドな重みモデルは、一般的に最先端のインテリジェンスです。

そのため、最も高度なインテリジェンスが必要な場合は、この方法を選択することがよくあります。

一方、オープンソース側は、多くの場合、1 世代遅れています。

これは、実際のトレードオフになる可能性があります。

速度の面では、最初の文までの時間を重視していると述べました。

私たちが発見したのは、クローズド モデルのライフタイム全体で、速度が低下することが多いということです。

これにはさまざまな理由が考えられます。

モデルを使用するユーザーが増えた、ハードウェアが新しいモデルに移行した、などの理由が考えられます。

しかし、これは私たちが気づいたことの一つです。

そのため、注意が必要です。出荷したものが素晴らしくても、時間の経過とともに使用できなくなるという問題が発生する可能性があります。

次はスパイクです。

このような一貫性を重視する場合、クローズド モデルは、P99 レイテンシではなく、非同期タスクのバッチ処理を中心に構築されることがよくあります。一方、オープンサイドでは、ユーザーが重視する特定の要素を重視するプロバイダを選択して、最終的に必要となる信頼性、速度、レイテンシを実現できます。

次は、モデル自体のライフタイムです。

そのため、クローズド モデルは 1 年ほどで廃止されることがよくあります。

つまり、1 年かけて開発したものを 3 年間本番環境で運用する場合、3 回以上モデルを変更することになります。

また、モデルが優れているからといって、それが自分にとってより効果的であるとは限りません。

過去 3 年間に多くのモデル変更があり、すべてを再構築するのに数週間、場合によっては数か月かかることもありました。オープンサイドでは、誰かがホストする意思がある限り、または自分でホストする意思がある限り、そのモデルを実行し続けることができます。

最後に、費用です。

多くの場合、これらのクローズド モデルは、新しいバージョンがリリースされるにつれて、以前のバージョンよりも高価になります。

経済性に関して注意すべきもう一つの点は、リリース時には経済性が成り立っていても、モデルの移行に伴って成り立たなくなる可能性があるということです。

オープン側では、柔軟に移動できます。また、まったく同じモデルであるため、大幅に増加する可能性は低いです。

そこで、Gemma 4 31B を使用しています。これは、速度、インテリジェンス、コストの最適な組み合わせであり、私たちにとって大きなブレークスルーとなりました。

また、非常に迅速に移行することができました。

以前使用していたものよりも開発がはるかに簡単です。

これは、これだけを使用するという意味ではありません。

さまざまなオープンモデルとクローズド モデルを組み合わせて使用しています。

たとえば、メモリ生成、安全性、カスタマイズなどです。

重要なのは、そのタスクの特定のニーズに最適なモデルを選択することです。

しかし、音声エージェントに関しては、Gemma 4 31B が主力モデルです。

この 2 つの違いに関して言えば、オープンモデルはより高い制御性を備えており、より予測可能なコストでホストできる限り、モデルを維持できます。

また、モデルのサポート終了によってスケジュールに影響が出ることもありません。

Devin Reimer

まとめると、これら 3 つの要素のバランスを取ることが重要ということですね。

レイテンシについては、ストリーミングの側面、並列処理の側面、速度、一貫性のバランスを取ろうとしています。

インテリジェンスの面では、ユーザーにとって十分にスマートで、構築に十分なスマートさを備えています。

費用については、ユーザーあたりの費用とユーザーあたりの収益を把握して、経済的に成り立つことを確認する必要があります。

まず構築してから、次に経済性を考えるというようなことはしないでください。

最初からそのことを考えておきましょう。

まだ初期段階ですが、経済的な効果は出始めています。

そのため、より安価なモデルは間違いなく優れており、よりインテリジェントなモデルも間違いなく優れています。

しかし、今、今日から、音声エージェントをどこでも使えるようにするために取り組むべき、本当に難しい課題に取り組み始めることができます。

音声エージェントの力を皆様にお届けできることを大変嬉しく思います。

ありがとうございました