即時聽寫定上載檔案：延遲、計費、準確度三條數點揀

「你哋支援即時聽寫嗎？」

呢條問題答「支援」或者「唔支援」，兩邊都會誤導。

即時同批次唔係兩個功能，係兩條產品線。接口、計費、失敗模式、準確度上限，四樣都唔同。

揀錯嘅代價唔止貴。你會發現接入層寫錯方向：原本一個 POST 嘅流程，變成要開 socket、管重連、處理 partial 覆寫。

反過來，用串流做存檔稿，你會永遠差最後一步：冇人保證你手上嗰版係最終版。

本文唔講接口點寫（WebSocket 實作指南 已經寫得細），只講決策：三條數，五個場景，一個混合做法。

重點摘要

• 延遲唔係一個數，係三段相加：收音緩衝、模型處理、網絡回傳。你控制得到嘅通常只有第二段。
• 我哋兩條線都按音頻小時計：實時 HK$1.40、批次 HK$0.80。差 1.75 倍，唔係「免費送」。
• 有平台按連線時長收費，空轉都算錢；長開熱線嘅成本差距，通常在呢一項爆出嚟。
• 串流冇「未來」可以參考，講到句尾前只能靠猜；批次可以整句重讀，標點同數字格式穩定啲。
• 正式稿最穩陣嘅做法係混合：會中出實時字幕，會後用批次重跑同一段音檔，以批次版為準。

先問一個問題：遲三秒，你會唔會做錯決定

延遲預算 係指「你嘅流程容忍幾多秒誤差」，唔係「引擎幾快」。

同一個 3 秒延遲，喺三個場景有兩種命運：

• 客服即時提示：3 秒 = 客已經講完下一句，提示永遠慢半拍。容忍度大約 1 秒。
• 會議即時字幕：3 秒 = 觀眾讀到上一句，剛剛好。容忍度 2 至 5 秒。
• 訪問逐字稿：3 秒同 3 分鐘冇分別。容忍度等於「你幾時要交」。

所以「夠唔夠快」唔可以抽象答。先寫低你嘅容忍秒數，再揀路線。

寫唔出數字，就代表你未想清楚個流程。

延遲：三段相加，你只控制得到一段

首字延遲 係指「對方開口，到你見到第一個字」嘅時間。

拆開係三段：

大部分團隊只調第一段，然後投訴第三段。

實際做法係反過來：先量三段，再決定邊段值得改。

例如一條 8 秒嘅查詢句，收音緩衝收細一半，畫面快咗 0.2 秒，但每次只出兩三個字。使用者會覺得「窒」，唔會覺得「快」。真正令佢覺得順嘅，係句子完整先刷新。

【實測】把收音緩衝由 500 毫秒降到 100 毫秒，畫面更新快咗，但文字反而跳得更厲害，因為每次只夠講半個字。使用者觀感係「窒」，唔係「快」。

呢個就係串流嘅本質取捨：更新越密，猜錯越多。

想知實際數字，就要喺你嘅網絡、你嘅裝置上量。冇一份通用 benchmark 可以代你量。

計費：實時按音頻小時，但差距唔止單價

我哋嘅公開費率：批次 HK$0.80、實時 HK$1.40，兩者都按音頻小時、按秒計、只扣成功。

換句話講，實時貴 75%。呢個溢價買嘅係「唔使等」。

用一條實例計。假設一間客服中心 8 條線，每日在線 8 小時，一個月 22 日：

• 音頻時數：8 × 8 × 22 = 1,408 小時
• 批次月費：1,408 × 0.80 = HK$1,126
• 實時月費：1,408 × 1.40 = HK$1,971

差 HK$845。對一間 call centre 嚟講唔算多，但呢個數只計「全部錄音都轉」。

真正嘅分歧在另一種計費方式。

連線時長計費 係指「socket 開住幾久就收幾久」，唔理中間有冇人講話。

有供應商採呢種模式。你嘅線開足 8 小時，講話時間可能只有 3 小時，但收費按 8 小時。

同一間公司如果行連線時計費，月費會用 1,408 小時計，而唔係實際語音時數。差距就唔止 75%。

判斷方法：問一句「如果我開住條線但冇人講話，會唔會收錢」。答案會直接決定你要唔要做語音活動偵測去開關連線。

語音活動偵測（VAD） 係指「只喺偵測到人聲時才送音頻」。開源方案例如 Silero VAD（2026-10-31 查閱）就係常用嘅一個。用佢省連線費嘅前提，係對方真係按連線時長收費；如果按音頻秒計，咁做只係省頻寬，唔會省錢。

準確度：串流冇「未來」，批次可以重讀

二次解碼 係指「同一段音頻，用完整上下文再跑一次」。

串流做唔到呢件事。原因係結構性，唔係調參數可以解決：

• 模型只睇到已到達嘅音頻。句尾未講完，佢就要先出字。
• 出咗嘅字可以改，但改嘅動作要你自己處理；畫面已經跳過，觀眾已經讀過。
• 遇到人名、數字、中英夾雜，前文越少，猜錯機會越大。

批次唔同。整句話喺手上，標點、斷句、數字寫法可以一次算清。

所以同一條錄音，串流版同批次版一定唔完全一樣。差異有幾大，要你自己量；量法見 廣東話 ASR 實測方法，本文唔重複測試協議。

有一點要講清楚：呢個差異唔代表串流「唔準」。對字幕、即時提示，串流完全夠用。問題只在於你係唔係要用同一份輸出做存檔。

用同一份輸出做兩件事，就係大部分團隊踩嘅坑。

五個場景，五個答案

呢張表有個規律：越接近「即時決策」，越要實時；越接近「存檔責任」，越要批次。

中間嗰格（會議字幕）最尷尬。你既想即時，又想事後有一份正式稿。

答案就係下面嘅混合路線。

混合路線：即時出字幕，會後批次重做

做法好簡單，三步：

1. 會中開串流，出即時字幕，與會者跟得上。
2. 會後把同一段錄音交去批次路線，重新轉一次。
3. 以批次版為正式稿，串流版只留作過程紀錄。

代價係同一條音頻收兩次費。一場 45 分鐘會議，兩條線合計約 HK$1.65。

換嚟嘅係：正式稿穩定、可重跑、可對帳，而且唔會因為中途斷線而少一段。

【獨家觀察】混合路線嘅真正好處唔係「兩份稿」，係「兩份責任分開」。即時字幕出錯，影響係當刻體驗；正式稿出錯，影響係存檔同法律風險。呢兩件事唔應該用同一份輸出。

如果連 HK$1.65 都要省，直接只行批次，會後 10 分鐘交稿。大部分內部會議都夠用。

唔好嘅做法係：只行串流，然後把串流稿當正式稿交出去。呢個做法省錢，但你要接受「永遠唔知漏咗幾多字」。

決策清單：五條問題，答完就有答案

按次序問，唔使跳：

1. 延遲預算幾秒？ 寫具體數字，唔好寫「要快」。
2. 同一份輸出會唔會做存檔？ 會 → 批次，或者混合。
3. 你嘅用量係「事件式」定「長開」？ 長開 → 先確認對方點計連線空轉。
4. 失敗要唔要重跑？ 要 → 揀可以整段重跑而唔會亂帳嘅路線。
5. 有冇時間碼需求？ 要 SRT/VTT → 兩條線都唔會直接給你，要另做對齊，見 逐字稿交付格式。

答完第 1、2 條，答案基本上已經定型。

第 3 條係最容易被忽略、亦最容易令預算爆嘅一條。

我哋自己嘅限制，講明白

我哋實時路線用 WebSocket，逐段推結果；批次路線係提交任務再輪詢。

兩條線嘅輸出都係 json 同 text。冇 SRT、冇逐句時間戳。

批次路線單次上限 200MB 或 4 小時；同步單次 4.5MB 或 8 分鐘。長檔要分段，見 四小時會議錄音流程。

如果你要嘅係「一條錄音、一份 SRT、跟住上 YouTube」，我哋唔係最順嘅工具。要另配對齊工具。

如果你要嘅係「大量會議錄音，穩定出文字，可以對帳」，批次路線會比串流實在。

規格對照可以睇 ASR API 選型五個規格位；成本要同人手打字比，見 轉文字 vs 請人打字。

常見問題

即時聽寫係唔係一定比批次唔準？

唔一定「唔準」，係「唔同」。串流冇後文可以修正，句尾同專名較易出錯；批次有整句上下文，輸出穩定啲。差異有幾大要自己量，唔好信任何通用百分比。

我可以只用實時，事後唔重跑嗎？

可以，如果輸出只作即時參考。要交存檔、要對外、要簽核，就唔好。重跑一次成本很低，錯一次成本很高。

實時路線係唔係一定要開住條線？

視乎你嘅用法。要即時提示，線要開住；只係偶爾查詢，用批次更平。若供應商按連線時長收費，空轉時間要另外計。

同一條音檔，兩條線都跑，會唔會出兩個唔同結果？

會。呢個係預期行為，唔係 bug。做法係指定一份為準，另一份標明用途，唔好兩份撈住用。

八分鐘以上可唔可以用實時？

我哋嘅同步路線有 8 分鐘上限，超過會回 audio_too_long 並附 duration_seconds 同非同步入口。實時串流係另一條線，按連線長度計，唔受同一個上限約束，但長會議要自己管重連。

關於呢篇文

本文由港嘢內容團隊整理。費率取自我哋公開定價（2026-10-31 查閱）；上限數字取自公開 API 文件（2026-10-31 查閱）。延遲三段嘅拆法同混合路線建議，來自我哋處理會議同客服錄音嘅實務經驗。想睇接口實作，讀 WebSocket 教學；想睇專名點救，讀 粵語熱詞辨識。有問題歡迎 聯絡我們，公司背景見 關於港嘢。

資料來源：港嘢公開 API 文件（同步 4.5MB／8 分鐘、非同步 200MB／4 小時、按音頻秒計費、實時與批次費率）；Deepgram 預錄音檔文件（2GB 上限、超過 10 分鐘回 504，2026-10-31 查閱）；AssemblyAI 提交介面（純非同步、回 transcript id，2026-10-31 查閱）；ElevenLabs 語音轉文字文件（3GB、標準模式 10 小時，2026-10-31 查閱）；Whisper 論文（arXiv 2212.04356，固定窗口切段、無未來上下文）。本文由港嘢內容團隊編輯及覆核。