在虛擬語音代理中平衡超低延遲和雲端經濟效益

Devin Reimer

歡迎參加「在虛擬語音代理中平衡超低延遲和雲端經濟效益」課程。

我是 Devin Reimer。

我是 AstroBeam 的創辦人兼執行長。

我曾擔任 Owlchemy Labs 的執行長和共同創辦人，該公司最知名的作品可能是《Job Simulator》。

因此，AstroBeam 致力於在遊戲中建構即時 AI。

具體來說，我們非常重視語音輸入。

目前我們已推出兩款遊戲，其中《Stellar Cafe》支援 VR 和電腦。

在這款遊戲中，玩家會在太空站咖啡廳與機器人交談，協助他們解決問題。

100% 語音控制。

你可以只用聲音玩完整款遊戲，包括選單和導覽。

我們今天剛宣布的新遊戲《Robo Detective》是專為 Android XR 打造，特別是 XREAL 的 Project Aura。

在這款遊戲中，你將扮演偵探，與機器人夥伴合作，透過訪談機器人來偵破機器人犯罪案件，同樣完全由語音驅動。

因此，語音代理非常難開發，在遊戲中更是如此。

因為遊戲的成本非常低，而語音代理是這項流程中新增的成本。

此外，我們不是要與其他語音代理競爭，而是要與所有遊戲的品質競爭，對吧？

因此，我們必須提供高品質的服務。

這並非表示語音代理沒有獨特挑戰或風險較高的特定用途，但遊戲在這個領域確實面臨極大的技術挑戰。

不過，正因為是遊戲，我們有很大的空間可以實驗如何解決這些難題。

因此，我相信如果語音代理能在遊戲中運作，幾乎在任何地方都能運作。

因此，我在這場演講中談到的應用程式，不只適用於遊戲，也適用於您想建構的任何語音優先應用程式。

因此，在思考語音代理時，我認為有三大核心挑戰。

因此，我們有延遲時間、智慧和成本。

不過，我想先釐清一件事：我說的語音代理是指對話式語音代理，而非提示詞。

我指的不是將內容傳送至 LLM，然後等待回覆的麥克風包裝函式。

我指的是現實世界中的即時來回互動，這其實相當難以建構。

首先，我們來談談延遲時間。

需要多快？

答案是：必須很快，非常快。不過，根據你讀過的資料，這個速度可能不如你想像的快，也可能比你想像的快得多。

接下來，我們來談談在許多測試中發現的一些數據。

因此，我所說的端對端延遲時間，是指從使用者最後一次說話 (使用者發出的最後一個聲音)，到他們聽到音訊回傳的時間。

我們在測試中發現，當我們從使用者那裡取得遊戲測試意見回饋時，大約 1.5 秒是他們開始不提及速度或緩慢或任何其他問題的時間點。

這似乎是人們開始感到舒適的點。

如果速度比這個慢，使用者通常會說：「這很棒，但…」，因此這似乎是最佳平衡點。

當速度加快到 1.2 秒左右時，我們發現一些更自然的互動，例如來回對話。

例如，我說了某句話，機器人就會很快回覆，然後你來我往。

這似乎是個尚未開發的絕佳機會。

不過，在堆疊中實際達到 1.2 秒相當困難。

另一項有趣的發現是，我們進行了大量測試，最後在某些情境下，延遲時間甚至不到一秒。

你可能會想：「太棒了！」

有時確實如此，但有時感覺很糟，非常詭異。

因此，你可能會聽到有人說 800 毫秒的回應時間是正確的數字，或 500 毫秒。

我甚至讀了許多關於 300 的文章，因為這才是人類感知真正著陸的地方。

事實上，這完全取決於情境。

舉例來說，如果我問你叫什麼名字，我會預期你多久會回答。

如果我問你生命的意義是什麼，我預期會得到截然不同的回覆時間。

我們實際進行測試，請使用者評估回覆速度是快還是慢，但從實際數據來看，結果其實非常分散。

有些回覆需要較長時間，但使用者認為很快，反之亦然，因為這完全取決於情境。

以及對話進行到哪裡。

一般來說，使用者會預期第一個回覆比後續回覆更快，因為後續回覆需要思考時間。

但有時你可能只會得到簡短的回覆，因此期望值會提高。

所以這不是一門完美的科學，沒有完美的數字，但我們發現大約 1.5，如果你在這個位置，你就是你，你做得很好。

因此，一旦達到 1.5 秒，就必須開始重視一致性，對吧？

因為如果 90% 的時間都是這樣，但 10% 的時間需要 3 秒，使用者體驗就會感覺不佳，甚至會覺得壞掉了。

因此，當速度夠快時，我們就會開始追求一致性，也就是隨時保持快速，而非大部分時間。

Devin Reimer

以下是標準語音管道架構。

因此，我們會將語音轉文字的結果傳送至 LLM，然後將 LLM 的結果傳回文字轉語音。

也就是說，語音轉文字功能會將音訊傳送到伺服器，然後轉換成文字。

在 LLM 方面，我們會擷取文字、回覆對話，或將其轉換為回覆對話，然後決定該角色要採取哪些行動。

我們認為這點非常重要，因此會緊密結合這兩者。

接著在文字轉語音方面，我們會將文字傳送至文字轉語音服務，並串流傳送給使用者，同時配合代理要執行的動作。

這種做法的問題之一是，依序執行可能會相當緩慢，因為您最終必須逐步執行這些操作。

因此，我常被問到一個問題：如果這種做法很慢，而且必須執行三個步驟，為什麼不直接使用語音轉語音模型呢？

因為這樣比較快，對吧？

而且，是的，大多數情況下，這樣會更快，因為您正在執行一件事。

但也有一些重大缺點。

因此，雖然速度很快，但有一些重大缺點，其中最大的缺點是成本。

因此，我們發現執行語音轉語音模型的費用，通常比這種平行處理方法高出約 3 到 5 倍。

因此，對我們來說，這在經濟上根本行不通。

在安全方面，這其實更棘手，因為在代理說出回覆之前，很難驗證回覆內容。

不過，如果採用管道式方法，您可以在 LLM 生成回覆時，立即驗證並檢查安全性，不必等到回覆即將傳送給使用者時才進行。

在語音風格方面，你只能使用語音轉語音模型中的預設設定。

你不能說：「你知道嗎？

For this case, I really want to use this type of voice."

只能使用該特定版本。

在管道方法中，您可以像這樣：「噢，我要改變一下。

我要選取這個模型，因為這個模型非常適合這個特定用途。」

智慧也是如此，對吧？

如果語音轉語音模型很優秀，能生成優質語音，但智慧程度不符合需求，你無法直接更換模型，對吧？

你有點被困住了。

在管道方法中，您會想：「噢，針對這個用途，我想使用特定模型。」

語音對語音模型絕對勝出的領域，就是理解使用者的語氣。

例如諷刺等。

目前，語音轉文字轉錄稿通常不包含這類資訊，但我認為這種情況會隨著時間改變。

這絕對是 Speech-to-Speech 的一大優勢。

因此，語音轉語音在速度方面絕對有優勢，但在可設定性和高成本方面，確實有一些挑戰，尤其是對我們來說，這就是一個決定性的因素。

那麼，是否有其他方法？

是。

我們應該盡可能平行處理管道。

因此，我們採取的做法之一，是在語音轉文字功能尚未完全確定之前，就先執行 LLM。

這裡的信心是指對轉錄稿中生成的字詞，以及對話結束時機的信心。

因此，只要我們認為使用者可能已停止說話，且這就是他們說的話，就會繼續執行。

因此，最糟的情況就是我們判斷錯誤，對吧？

使用者繼續說話。

不過，即使在這種情況下，我們也只會取消 LLM，然後再次執行。

由於脈絡可能會快取，而且我們尚未生成那麼多詞元，因此實際成本並不高，好處是使用者最終能更快聽到內容，不必等到完全確定。

我們也不會等到 LLM 生成完整回覆，才開始將回覆傳送至 Text-to-Speech。

我們等待的是第一個可朗讀的區塊。

在大多數情況下，這會是一個句子。

有時可能會有其他設定，但只要有第一個句子區塊，就會傳送至 Text-to-Speech。

接著，如果我們有良好的文字轉語音功能，只要準備好串流，就能傳送給使用者。

我們也十分謹慎地控制需要生成的權杖數量。

因此，我們不會使用 JSON 包裝函式等可能增加額外權杖的項目。

我們會盡可能簡化結構，以最快的速度回應。

如果我們事先知道代理會產生的第一組詞元，也會使用助理預填等功能。

因此，文字轉語音功能最終會分成這兩個區塊，對吧？

因此，第一個可朗讀區塊會先傳入，然後我們再執行其他所有內容。

不過，由於播放音訊所需的時間比生成音訊長，因此在第二個區塊完成時，第一個區塊幾乎都已播放完畢。

因此使用者實際上看不到。

會以最快速度抵達。

因此，在考慮選擇不同服務時，以下是一些經驗法則。

選擇合適的音訊和代理架構時，最重要的是盡可能降低輸入和輸出的延遲時間。

那麼，上傳和下載資料的速度有多快？

在語音轉文字方面，我們重視的是達到可信度所需的時間。

也就是轉錄稿和語音結束偵測的信心水準。

這兩個是配對的，對吧？

如果無法快速對某個模型產生信心，速度就會像這樣慢，對吧？

因此，速度取決於其中最慢的。

在 LLM 方面，我們關注的是「首句生成時間」，也就是第一個可朗讀的語音片段。

這分為兩個部分，對吧？

也就是第一個詞元生成時間，加上每秒生成的詞元數量。

因此，如果突然發現某個模型的第一個詞元生成時間很短，但每秒詞元生成速度很慢，那麼這個模型可能比其他模型更不理想。

因此，請找出合適的組合。

在文字轉語音方面，您需要留意的是首次音訊時間。

因此，測量這項指標非常重要，因為有時音訊會先出現靜音，使用者聽不到。

因此，您實際上必須測量到使用者聽到聲音的時間點。

正如我先前所說，最重要的是穩定性，而非最高速度或最佳情況。

這個完整堆疊的延遲時間是否穩定？

Devin Reimer

目前我們使用 LiveKit 做為音訊代理框架。

語音轉文字方面，我們使用 Deepgram。

我們使用 Gemma 4 31B 做為大型語言模型，並託管於 LiveKit。

在文字轉語音方面，我們使用的是 Inworld AI 文字轉語音 2。

此外，我們還建構了整個 AstroBeam AI 代理駕馭系統，不僅能將所有功能整合在一起，還能加入所有必要元素，打造出真正優質的語音代理，特別是像我們這樣高度互動的遊戲代理。

有一點我還沒提到，那就是安全模型。

因此，傳統上安全模型是 LLM 傳遞作業的一部分，但這會增加延遲時間，並增加額外步驟。

如果改為自行執行，會怎麼樣？

所以，這實際上更像是我們的堆疊。

因此，當我們收到第一段文字時，會將這段可朗讀的文字傳送至 Text-to-Speech，同時傳送至安全模型。

由於安全模型較小，執行速度比語音轉文字快，因此幾乎一律會提前完成。

這表示新增安全模型不會增加堆疊的延遲時間，更棒的是，這個模型夠大，我們實際上可以執行比大多數人想像中更大的安全模型。

這對我們來說非常重要，尤其是我們正在開發遊戲。

那個世界有許多非常重要的背景資訊。

舉例來說，假設您正在開發一款中世紀遊戲，其中有個 NPC 會大喊「衝啊！

砍掉他們的頭！」，對吧？

傳統的安全模型可能會說：「哇，這不太好。

你不該這麼說。」

但就這款遊戲而言，這完全合理。

為此，我們採用更強大的安全模型，並提供更多世界現況的背景資訊，讓模型能發揮作用。

您可能會注意到，我們實際上執行了兩次安全模型，因此最終會在第一個區塊上執行，然後在我們將最後一個區塊全部放在一起時，再次在整個區塊上執行。

同樣地，我們必須執行兩次，但不會增加堆疊的延遲時間。

現在速度夠快了，但如果我們不夠聰明，速度再快也沒用。

Devin Reimer

那麼，智慧程度需要多高？

這項技術必須夠聰明，才能滿足使用者需求，但更重要的是，它必須夠聰明，才能讓您用來開發。

而這通常是人們在選擇情報需求時，不會考慮到的事情。

我們開發語音代理約三年了，舉例來說，早期我們使用一些早期的 LLaMA 模型，雖然能讓使用者使用，但開發成本非常高，因為所有東西都很脆弱。

模型很容易生成不理想或不合理的回覆，因此我們投入大量工程心力，確保模型能正常運作。

因此，我們會優先處理這項工作，因為如果無法快速建構這些內容，就無法向使用者提供。

因此，請務必同時考量這兩者。

因此，人們談到智慧時，通常會想到 LLM，對吧？

但這只是其中一部分。

談到情報，我們必須考慮到每個環節。

接著來談談語音轉文字智慧功能。

因此，我們希望字詞錯誤率越低越好。

此外，不只是錯誤率低，當錯誤發生時，我們生成的內容會非常接近實際內容，因為如果非常接近，LLM 通常可以透過上下文，很好地理解它是什麼。

如果錯誤率低，但失誤率很高，LLM 就會更難判斷實際意圖。

另一個要考量的因素是目標平台。

舉例來說，如果我正在建構 XR 應用程式，且麥克風非常靠近使用者的嘴巴，我就能取得非常優質的高品質麥克風音訊資料，這可能非常適合某些模型。

但如果我突然要為手機開發應用程式，讓使用者在繁忙的街道上使用，就會產生許多不同的影響，而且不同的模型會有不同的行為，並能以不同的方式智慧地理解所說的內容。

因此，請務必考量這點，確保選擇正確的平台。

接著，我們來看看智慧方程式的文字轉語音部分。

聽起來很自然，對吧？

我們的目標是向使用者傳達他們能理解的內容。

但這只是其中一部分，對吧？

代理的表達能力也非常重要，因為表達能力能傳達資訊。在遊戲測試中，我們發現代理的表達能力越強，使用者就覺得代理越聰明，這很合理。

接著，速度夠快嗎？

雖然我在上一節談到的是延遲時間，但這對感知智慧也相當重要。

使用者會直接將回應速度與智慧程度連結。

如果我能快速回應，聽起來可能更聰明。

因此，這些因素對使用者的體驗感受和沉浸感有很大的影響。

接下來，我們來看看 LLM 方面的智慧。

到目前為止，這是最難平衡的部分，因為這裡有許多不同的需求，對吧？

因此，我們有語音理解、上下文和基準。

在遊戲中，這非常棘手，因為你必須立足於整個世界和宇宙，對吧？

這不是文字方塊，無法捏造正在發生的事情。

如果遊戲中的代理說「桌上有顆蘋果」，但桌上其實沒有蘋果，就會破壞使用者體驗。

我們也需要嚴格遵守規則。

遊戲非常講求規則。

大型語言模型可以處理這種情況嗎？

可以降低幻覺率嗎？

當你反覆與同一個代理互動時，能否保持一致的角色設定？

是否感覺像同一個代理？

最後，您可能會遇到一個問題，雖然在開發初期不會發生，但仍需注意：模型能否處理越來越大的提示？

因為隨著開發作業持續進行，您勢必會在提示中加入更多內容。

不過，隨著使用者繼續玩遊戲，提示中的對話記錄也會增加。

那麼，提示詞能處理這種成長嗎？

因為有時某些模型會隨著提示長度增加，而降低回覆品質，因此您必須瞭解實際需求，才能決定每次要輸入多少提示。

不過，這些只是冰山一角，實際情況仍取決於您要建構的內容。

因此，你必須仔細思考要建構什麼，以及想達成什麼目標。

現在我們夠快也夠聰明，但如果成本太高，一切都是枉然。

Devin Reimer

那麼，這項技術要多便宜才行？

很遺憾，實際情況比這更複雜。

因此，我們必須思考正在建構的應用程式或遊戲的經濟效益，對吧？

因此，您需要思考幾個問題。

使用者與語音代理互動的時間有多長？

每位使用者帶來的收益是多少？

每小時的執行成本是多少？

我們把這些資訊拼湊起來，試著找出答案，看看是否合理。

以下是我們第一款遊戲《Stellar Cafe》的經濟模型。

因此，Stellar Cafe 的遊玩時間介於 1.5 到 3.5 小時之間，平均約為 2 小時。

我們運行語音代理的成本約為每位用戶每小時 1.20 美元，用戶 100% 的時間都在與它互動。

這是一款完全由語音驅動的遊戲。

我們對遊戲收取 $10 美元的固定費用，這是傳統做法。

我們不採用訂閱模式，因為這在遊戲中很難實行，而且我堅信我們必須以固定成本運作，否則就無法運作，也無法擴大規模。

我們之前收費 $15 美元，但我們一直在努力降低這些伺服器成本，所以現在我們實際上已經降到 $10 美元。

$1.20 美元是我們目前的價格。

這不是通用的費用。

我見過這類產品的價格範圍很廣，有時甚至更貴。

因此，您也必須瞭解自己在成本方面的狀況。

我們也可以降低價格，但我們希望盡可能維持高品質。

因此，如果將這些因素全部納入考量，這表示在 2 小時的遊戲時間內，每位使用者的語音堆疊費用約為 $2.40 美元。

我們收取 $10 美元，商店會收取費用，這表示我們每位使用者可賺取約 $4.59 美元，對吧？

因此，這在經濟上是可行的，對吧？

語音是我們的賣點，也是我們想花錢投資的部分，這很有效。

所以這是一款非常小的遊戲。

我們來談談更大型的專案。

假設有一款敘事遊戲，遊玩時間約 5 到 9 小時，平均 7 小時。

實際上，大多數人 (很多人) 不會玩完整款遊戲，而是玩一小部分就放棄，但我希望選擇稍微高一點的數字，確保經濟體系仍能運作。

因此，我們將保留每小時 $1.20 美元的費用，但要做的變更是，語音元件的使用時間將占 60%，因為大型遊戲除了語音之外，還會有更多機制。

因此，這款遊戲仍會以語音為主，但會加入其他類型的功能。

因此，如果我們收取 $20 美元，再重新計算一次，每位使用者的成本約為 $5 美元，這表示最終每位使用者可賺取約 $9 美元。

因此，這項技術同樣符合經濟效益。

這不代表所有內容都適用這種經濟模式。

舉例來說，假設您想打造一款免付費玩遊戲，預期玩家的遊玩時間介於 1 小時到 100 小時以上，

因此，我們取平均值 10 小時。

這款遊戲完全由語音驅動，假設遊戲大受歡迎，每位使用者帶來約 $3 美元的收益，這對免付費玩遊戲來說相當不錯。

每位使用者會損失 $10 美元。

因此，這項技術還無法完全勝任所有工作，您必須思考目前建構的內容是否合理。

不要等到最後才試著瞭解經濟效益。

Devin Reimer

接下來的問題是，本機模型呢？

既然成本是個大問題，本機模型不就能解決這個問題嗎？

答案是肯定的。

不過，我們必須考量一些取捨。

因此，在成本方面，我們將省去伺服器費用，這將是一大優勢，並帶來更多機會。

但目前雲端可以解決許多本機難以處理的問題。

例如運算。

使用者常會說：「你看，我找到這個很棒的語音轉文字模型，而且是在這部裝置上本機執行，對吧？」

很好，但我們必須考慮到，它不是執行一個模型，而是執行多個模型，對吧？

以我們的例子來說，四個，可能同時，所以，某個東西執行一次是不夠的，它必須同時執行多次。

如果完成這項操作，遊戲或應用程式是否還有剩餘資源可供執行？

如果 GPU 效能已達上限，就無法順利轉譯電玩遊戲。

假設您已克服這些挑戰，

接下來是速度，對吧？

雖然通常可以執行，但速度會非常慢，感覺更像是在提示，而不是實際的即時對話。

因此，理論上，在本地端執行確實有未來優勢，因為您不必從網際網路來回傳輸。

目前要讓模型以適當速度運作，才能實現這項功能，這是一項挑戰。

接下來，假設您已經克服了運算和速度的問題，現在就必須考慮品質，對吧？

一般來說，由於是在本機裝置上執行，因此會使用較小的 LLM，例如較原始的文字轉語音，這在建構內容時可能會帶來一些挑戰。

如先前所述，考量 LLM 時，不只要思考是否能滿足使用者需求，還要評估是否適合用於開發。

因此，如果模型難以建構，就必須考慮這一點。

假設您已克服運算、速度和品質方面的挑戰，接下來要解決的是可攜性問題。

如果你贏了，並完成整個過程，然後在 RTX 5070 上執行這個東西，那可能就是唯一能執行的地方。

因此，如果想將遊戲移植到新平台，可能會遇到困難。

在雲端方面，您只需要網際網路。

這是一項重大突破。

可前往多個平台。

接下來，我們來談談混合式方法。

因此，我們可以在雲端執行部分作業，並在本機執行部分作業。

有點像，這樣可行嗎？

這並不像你想的那樣是個大勝利。

因此，如果最終得到的模型夠小，可以在大多數本機平台上執行，那麼在雲端執行相同模型可能只需要幾分錢。

因此，通常要等到解決整個堆疊的問題，才能獲得最大效益。

接下來，如果可以的話，在本機執行會怎麼樣？

他們有合適的硬體，如果沒有，也可以在雲端中，對吧？

您可以在雲端執行更強大的功能。

這會帶來新的挑戰，對吧？

如果最終執行的是其他模型，可能會對開發作業造成不小的影響。

最後還是得花很多時間處理最低規格。

而且模型的行為可能大不相同。

因此，除非您使用完全相同的模型，否則可能會增加許多開發時間和成本。

因此，請務必思考要達成的目標。假設你已找出解決方法，並在需要時使用本機，不需要時使用雲端，但雲端模式仍須符合經濟效益。

因為如果突然間所有使用者都轉移到雲端，而你沒有從經濟角度考慮到這一點，就會蒙受損失。

因此，就本機模型而言，這絕對是經濟上的重大勝利，但目前仍處於早期階段。

對於遊戲等價格敏感的應用程式，我認為這項技術最終可能會勝出。

目前，除了更具體的用途 (尤其是指令式操作) 之外，這項功能有點難以使用。

因此，我們希望現在就能提供最佳體驗。

這就是我們使用雲端的原因。

不過，這個領域瞬息萬變，情況變化相當快速。

接下來，我們來想想使用的模型。

接下來的問題是，開放權重和封閉權重有何差異？

我們應該怎麼做？

討論這個問題時，我想著重在 LLM，因為我們發現這個領域最容易受到開放與封閉問題的影響。

因此，這兩種方法各有優缺點。

因此，封閉式權重模型通常是尖端智慧，對吧？

因此，如果您需要最完整的情報，通常必須前往此處。

相較之下，開放原始碼模型通常落後一代。

因此，這可能需要實際權衡。

在速度方面，我提到過我們非常重視「首句生成時間」。

我們發現，封閉式模型在生命週期內，速度往往會下降。

造成這種情況的原因有很多。

可能是因為使用模型的人變多，或是硬體已改用較新的型號。

但這是我們注意到的其中一點。

因此，你必須小心，因為這可能會導致問題，如果你推出某個產品，而且效果很好，隨著時間過去，它可能會變得無法使用。

接下來是尖峰。

您非常重視這類一致性，因此封閉式模型通常是圍繞非同步任務中的批次處理建構，而不是 P99 延遲時間。在開放式模型方面，您可以選擇重視您所重視的特定事物的供應商，為您提供最終所需的信心、速度和延遲時間。

其次是模型本身的生命週期。

因此，封閉式模型通常會在一年左右後停用。

也就是說，如果您花了一年開發某個項目，並預期該項目會在正式環境中運作 3 年，那麼您可能會經歷 3 次以上的模型變更。

此外，模型較好不代表更適合您。

過去 3 年來，我們經歷了許多模型變更，通常需要數週、有時甚至數月的工作才能重新調整所有內容，而在開放端，只要有人願意託管該模型，或者您願意自己託管，您就可以繼續執行該模型。

最後是成本。

隨著時間推移，這些封閉式模型推出新版本時，往往會比舊版更昂貴。

因此，在經濟效益方面，另一個需要注意的地方是，您的經濟效益可能在推出時有效，但隨著模型遷移而失效。

在開放端，您可以靈活移動模型，而且由於模型完全相同，成本不太可能大幅增加。

因此，我們採用 Gemma 4 31B，這對我們來說是一大突破，因為這是速度、智慧和成本的最佳組合。

這也讓我們能快速行動。

與我們之前用過的一些工具相比，這項工具更容易開發。

這不代表我們只使用這項技術。

我們結合了許多不同的開放和封閉模型。

例如記憶生成、安全性和自訂功能。

因此，請務必根據特定需求，選擇最合適的模型。

不過，Gemma 4 31B 才是語音代理的主力。

因此，就這兩者的差異而言，開放原始碼模型絕對能提供更高的控制權，只要能以更可預測的成本託管模型，就能保留模型。

也不會因為模型停用而影響排程。

Devin Reimer

總結來說，這三者之間必須取得平衡，對吧？

延遲時間：我們試著在串流、平行處理、速度和一致性之間取得平衡。

在智慧方面，Gemini 1.5 Pro 夠聰明，能滿足使用者需求，也夠聰明，能用於建構。

在成本方面，我們需要知道每位使用者的成本和收益，確保經濟效益。

不要先建構，再考慮經濟效益。

從一開始就必須將評估列入考量。

雖然目前仍處於早期階段，但經濟效益已開始顯現。

因此，更便宜、更智慧的模型絕對會更出色。

但從今天起，我們就能開始著手解決真正棘手的難題，讓語音代理普及到各個角落。

因此，我非常期待能將這些強大的語音代理功能帶給所有人。

感謝您！