OpenAI把實時轉(zhuǎn)寫延遲壓到300毫秒，3行代碼就能抄作業(yè)

去年開會還要手動記筆記的人，今年已經(jīng)被同事當成數(shù)字難民了。

2024年，實時字幕還是Zoom的付費彩蛋；2026年，它成了所有會議工具的入場券。用戶要的不是錄音回放，是話音剛落文字已現(xiàn)的零摩擦體驗。Whisper、Deepgram、AssemblyAI三家把流式音頻延遲卷進了300毫秒以內(nèi)，瀏覽器API也終于松口——不用裝插件，直接抓標簽頁音軌。

技術(shù)債務清零的時刻到了。

但別急著寫代碼。先看清數(shù)據(jù)怎么流：瀏覽器標簽音頻 → MediaStream → AudioWorklet → WebSocket → 語音識別API → 轉(zhuǎn)寫文本。 raw PCM音頻從瀏覽器出來，切成100-250毫秒的小塊，WebSocket送到流式識別端點，部分結(jié)果和最終結(jié)果交替返回。難點不在單點，在整條管道的延遲控制，以及網(wǎng)絡抖動、說話人切換、音頻重采樣這些邊緣場景的兜底。

第一個坑在這里：既要抓會議音（系統(tǒng)/標簽頁音頻），又要抓自己的麥克風，得把兩條MediaStream軌道混到一起。

混流代碼：比想象中臟，比文檔中少

大部分開發(fā)者第一次調(diào)用getDisplayMedia時都會愣住——這API設計的時候顯然沒考慮過"只要音頻不要畫面"的場景。視頻參數(shù)設false，音頻參數(shù)卻要展開一堆布爾值：回聲消除關(guān)、降噪關(guān)、采樣率鎖死16kHz。麥克風那邊相反，回聲消除和降噪全開。兩個流進AudioContext，createMediaStreamDestination打混，出來就是16kHz單聲道PCM——所有主流語音識別API的母語格式。

瀏覽器里做重采樣，比服務端做便宜一個數(shù)量級。這個細節(jié)能省下的服務器賬單，夠你多招一個后端。

別碰ScriptProcessorNode。它 deprecated 了，還跑在主線程上。AudioWorklet才是正解：

processor.js里注冊一個PCMProcessor，process方法把inputs[0][0]的buffer丟給port.postMessage，帶轉(zhuǎn)移所有權(quán)。主線程await audioContext.audioWorklet.addModule加載這個模塊，后面就能穩(wěn)定收音頻幀。主線程不卡，音頻不丟，這是能上線和不能上線的分界線。

WebSocket的隱形天花板：不是帶寬，是隊頭阻塞

音頻幀100毫秒一發(fā)，WebSocket看起來綽綽有余。直到某個用戶的Wi-Fi從5GHz跳到2.4GHz，延遲從30毫秒漲到300毫秒，你的緩沖策略如果沒做，整句轉(zhuǎn)寫會突然快進式吐出，用戶體驗直接崩盤。

Deepgram的流式API有個細節(jié)：它返回的partial transcript是"正在說的"，final transcript是"說完的"。你的UI要同時處理兩種狀態(tài)——partial用來實時滾動，final用來落庫和生成待辦。很多開發(fā)者只接final，結(jié)果用戶看著字幕比說話慢兩拍，罵聲比延遲還高。

AssemblyAI的做法更細：它區(qū)分utterance（說話人一段完整發(fā)言）和word-level timing。做會議紀要時，utterance用來切分說話人；做實時字幕時，word-level timing能讓高亮詞和音頻精準對齊。選型時先問自己：產(chǎn)品核心場景是"看懂"還是"搜到"？

Whisper的陷阱：本地跑還是云端調(diào)？

OpenAI把Whisper API的價格打到每分鐘0.006美元，但延遲在500毫秒左右徘徊。本地跑Whisper.cpp，M1 Mac上能壓到200毫秒以內(nèi)，代價是模型體積和首次加載的卡頓。瀏覽器里跑ONNX Runtime + Whisper Web，適合隱私敏感場景，但wasm的性能天花板明擺著。

有個中間路線：用Transformers.js在瀏覽器里跑distil-whisper，模型壓縮到原來1/6，精度損失不到2%。適合企業(yè)內(nèi)部部署，數(shù)據(jù)不出域。代碼量從"調(diào)API三行"變成"搭流水線三百行"，產(chǎn)品經(jīng)理聽到這里通常會沉默。

說話人分離（diarization）是另一個深坑。Whisper本身不做這個，Deepgram和AssemblyAI內(nèi)置了，但準確率依賴訓練數(shù)據(jù)分布。中文會議里中英夾雜、同音字人名、突然插話的"對對對"，都是現(xiàn)成模型的盲區(qū)。自研的話，ecapa-tdnn + spectral clustering的鏈路，標注成本能讓你重新評估這個功能優(yōu)先級。

一個被低估的API：getDisplayMedia的音頻陷阱

Chrome 104之后，getDisplayMedia的音頻捕獲才穩(wěn)定可用。但macOS上有個詭異bug：如果用戶選了"整個屏幕"而不是"Chrome標簽頁"，系統(tǒng)音頻可能混不進MediaStream。解決方案是強制約束audio: { suppressLocalAudioPlayback: false }，或者在UI層引導用戶只分享標簽頁。

Windows更麻煩。某些聲卡驅(qū)動會把系統(tǒng)音頻和麥克風混成單一流，你拿到的數(shù)據(jù)已經(jīng)是"臟"的，后端做說話人分離基本無解。這時候只能降級方案：提示用戶戴耳機，或者干脆放棄系統(tǒng)音頻，只轉(zhuǎn)寫麥克風——也就是只記錄用戶自己說了什么。

Edge case的密度，決定了這個功能從demo到生產(chǎn)環(huán)境的距離。

成本賬：別只算API調(diào)用費

Deepgram Nova-2，每分鐘0.0043美元；AssemblyAI Universal，每分鐘0.0037美元；Whisper API，每分鐘0.006美元?？雌饋聿罹嗖淮?？月活10萬用戶、平均每周3小時會議，一年下來Deepgram比Whisper省4萬美元。

但這只是明賬。隱形成本在：WebSocket連接?；睢⒁纛l緩沖區(qū)的內(nèi)存占用、轉(zhuǎn)寫結(jié)果的存儲和索引、合規(guī)審計的日志留存。一個沒做流控的客戶端，能把服務器連接池打穿，賬單比API調(diào)用費高十倍。

有個取巧方案：用VAD（語音活動檢測）前置過濾。沒聲音的時候不發(fā)包，能省30-50%的流量。WebRTC的VAD太保守，Silero VAD在wasm里跑，精度高一個檔次，延遲增加不到20毫秒。

2026年的新變量：瀏覽器原生AI

Chrome 128開始內(nèi)測Web Speech API的流式識別，完全本地跑，零網(wǎng)絡延遲。但語言支持有限，中文準確率比Whisper差一截，且沒有說話人分離。適合對延遲極度敏感、對準確率容忍度高的場景——比如實時字幕，而非會議紀要。

更激進的方案是WebGPU跑Llama 3.1 8B，端到端語音轉(zhuǎn)寫+摘要+待辦提取。但顯存占用和首次加載時間，目前只適合桌面端重度用戶。移動端？等2027年吧。

技術(shù)選型沒有銀彈，只有場景適配。內(nèi)部工具可以容忍300毫秒延遲換準確率，客服場景要的是200毫秒以內(nèi)的即時反饋，合規(guī)場景寧愿本地跑慢模型也不讓數(shù)據(jù)出域。

最后說一個細節(jié)。某團隊上線實時轉(zhuǎn)寫三個月后，用戶反饋里最高頻的詞不是"準"或"快"，是"能不能關(guān)掉"——有些人就是不想被機器記錄。他們在設置里加了一個顯眼的"暫停轉(zhuǎn)寫"按鈕，點擊率比預期高17%。

技術(shù)解決了能不能錄的問題，產(chǎn)品還要回答應不應該錄的問題。你的會議工具，準備好面對這個17%了嗎？