谷歌Gemini語音延遲壓到500毫秒內，開發者卻栽在回聲消除上

500毫秒，這是人類對話中"自然感"的生死線。超過它，你會感覺對面是個機器人；低于它，用戶幾乎察覺不到延遲。谷歌Gemini 2.5 Flash Live API把語音交互壓進了這個區間，但一位開發者花了500多場真實對話才發現——真正的殺手不是推理速度，是回聲。

GoNoGo.team的創始人最初以為最難的是多智能體編排、40多個函數調用工具。結果上線后，AI面試代理頻繁打斷自己說話，像個人在空曠房間里聽到回音后愣住。問題的根源：瀏覽器自帶的回聲消除（Acoustic Echo Cancellation，AEC）在新型語音架構里完全失效。

為什么傳統方案會"失明"

傳統語音AI走"語音→文字→語音"的拼接路線，延遲通常在1-3秒。Gemini Flash Live API是原生語音到語音（speech-to-speech），音頻進、音頻出，沒有中間文本層。這意味著客戶端處理的是原始PCM數據：16kHz麥克風輸入，24kHz代理語音輸出，Base64編碼后走WebSocket傳輸。

瀏覽器端的AEC有個底層假設——"遠端音頻"必須通過``元素或Web Audio API播放，這樣瀏覽器才能追蹤參考信號。但GoNoGo的實現是手動解碼WebSocket傳來的24kHz PCM塊，用AudioContext緩沖區調度播放。瀏覽器看不到這個音頻流，自然無法消除它。

后果很荒誕：AI開口說話，筆記本揚聲器出聲，麥克風收進去，AI以為用戶在打斷自己。最優情況是它重復半句話；最差情況——作者說" constantly happened"——對話徹底崩掉。

500場對話磨出的野路子方案

開發者試過讓AI忽略自己的聲音，但語音活動檢測（Voice Activity Detection，VAD）閾值調再高也攔不住物理層面的聲波耦合。最終方案是在客戶端建立"自引用消除"：把即將播放的音頻幀緩存為參考信號，與麥克風輸入做實時對齊抵消。

這相當于在瀏覽器里重寫半個AEC。對齊精度要控制在樣本級別——24kHz意味著每幀約21微秒的偏差都會漏出殘差。作者用512樣本塊（約32毫秒）處理，RMS能量檢測閾值設在0.05，低于此值直接丟棄。

更麻煩的是采樣率不匹配。輸入16kHz，輸出24kHz，重采樣本身引入延遲。GoNoGo的做法是統一在客戶端升到48kHz處理，再降回各自目標，把額外開銷壓到10毫秒以內。

被忽視的工程暗角

這個案例暴露了一個行業盲區：當語音AI從"文本中介"轉向"端到端音頻"，大量瀏覽器層面的音頻基礎設施需要重建。AEC、噪聲抑制、自動增益控制（AGC）這些曾經開箱即用的功能，在WebSocket+手動解碼的架構里全部需要自研。

作者提到一個細節：測試時發現某些筆記本的揚聲器-麥克風物理隔離太差，即使軟件層面完美消除，機械振動仍會漏音。最終被迫在檢測到AI說話時，動態壓低麥克風增益——用信噪比換穩定性，這是硬件層面的妥協。

500毫秒延遲的目標達成了，但代價是團隊把一半精力花在"讓AI聽不到自己"這種基礎問題上。語音AI的競賽正在從模型能力轉向工程整合——誰能把端到端延遲、回聲消除、網絡抖動緩沖這些臟活累活打包好，誰才能讓用戶覺得"對面像個真人"。

GoNoGo現在每天處理數百場創始人面試，回聲問題基本解決。但作者留下一個未回答的疑問：當多模態模型開始同時處理語音、視覺、實時環境音，現有的音頻處理棧還有多少能復用？下一代開發者會不會在同樣的坑里再栽一次？