AIREITER搜尋時常會看到「3-5」這種寫法，但 Google 實際使用的模型 ID 是 gemini-3.5-transcribe 與 gemini-3.5-transcribe-live。這套 API 確實存在，價格也便宜；真正的選擇關鍵，在於你要的是讀起來順的文字、可追溯的原話，還是即時字幕。
Gemini 3.5 Transcribe API 評測結論，一張表先看懂
Gemini 3.5 Transcribe 值得拿來測試錄音檔、口述內容，以及短時間的即時字幕體驗。不過，如果你需要精確逐字稿或長時間持續的即時紀錄，它不適合直接當成預設方案：Smart transcription 會編修語音內容；即時模式沒有說話者標籤和逐字時間資訊，而且整個服務目前仍處於公開預覽階段。
| 如果你需要…… | 建議使用…… | 評測判斷 |
|---|---|---|
| 上傳會議、通話或 Podcast 後產生逐字稿 | gemini-3.5-transcribe | 可以使用；在意原話時選擇逐字模式 |
| 整理乾淨的口述內容或易讀的會議筆記 | 錄音模型搭配 Smart 模式 | 若能接受內容被編修，則可使用，但需要審閱 |
| 在對方說話時即時顯示字幕 | gemini-3.5-transcribe-live | 適合短時間互動情境的原型測試 |
| 說話者標籤和逐字時間資訊 | 錄音模型搭配逐字模式註釋 | 可以使用，但有限制；30 分鐘與 3 位以上說話者仍屬實驗性功能 |
| 法律、醫療、合規或存檔用途的正式依據 | 逐字轉錄流程搭配人工審閱 | 不要當成唯一來源 |
這是一篇以現有證據為基礎的 API 評測，不是受控環境下的 WER 基準測試。Gemini 3.5 Transcribe API 設定與價格指南已涵蓋請求流程；本篇則聚焦在完成第一次成功呼叫後，文件中列出的取捨對實際使用代表什麼。
這個模型家族，其實對應兩套 API 規格
gemini-3.5-transcribe 透過 Interactions API 處理上傳或預先錄製的音訊；gemini-3.5-transcribe-live 則透過 Live API 處理串流音訊。
錄音轉錄：gemini-3.5-transcribe
如果目標是保存成可長期使用的逐字稿，錄音路徑的能力更完整。Google 在音訊轉錄文件中列出多項功能，包括支援 85 種以上語言的自動語言偵測、自訂詞彙、Smart 或逐字輸出、說話者分離，以及逐字時間戳記。
一般音訊的上限為 1 小時。若啟用說話者分離或逐字時間戳記，上限會降至 30 分鐘；Google 也特別標示，3 位以上說話者的歸屬判定仍屬實驗性功能，儘管模型參考資料列出的說話者上限為 8 位。
這條路徑適合口述、訪談和短時間通話；如果是需要說話者歸屬與時間對齊的長時間會議，就得由應用程式負責切段和重新拼接。
即時轉錄：gemini-3.5-transcribe-live
即時路徑的設計目標是逐步產生字幕，而不是透過 WebSocket 複製錄音路徑的全部行為。Google 的即時轉錄文件說明了暫時與最終轉錄事件、自動語言偵測、自訂詞彙、Smart 模式，以及自動、混合或手動語音活動偵測。
單一持續的即時工作階段最長為 10 分鐘；即時串流不支援說話者分離或逐字時間戳記。音訊則必須是原始的 16-bit PCM、16 kHz、單聲道、little-endian 格式。這些限制很適合字幕預覽，卻意味著長時間通話錄音必須自行處理重新連線、內容拼接和暫時文字。
真正左右評測結果的功能取捨
Gemini 3.5 Transcribe 的差異化賣點是「智慧」清理，但這項功能也會改變「準確」的定義。經過潤飾的文字可能更適合口述內容，卻未必適合作為完全照錄的紀錄。
Smart 模式是在編修，不是保存原始紀錄
Google 的 Smart 模式會移除贅詞、口吃和話說到一半的停頓，修正口頭自我更正，並自動整理標點、數字、清單和段落。例如「我們星期二見，不，星期三」可能會變成「星期三」，而不是保留原本的修正過程。
對草擬電子郵件、語音備忘錄或易讀的會議筆記來說，這很方便。但如果猶豫、原本的錯誤，或實際說話順序本身具有意義，就會帶來風險。
官方轉錄指南清楚劃出了界線：Smart 模式不能與說話者分離或逐字時間戳記同時使用。換句話說，API 要你在乾淨文字和可追溯註釋之間二選一。
建議把逐字稿保留為唯一真實來源，再另外產生 Smart 版本或經後續清理的版本供讀者使用。不要試圖靠提示詞繞過這個衝突，因為這是輸出規格本身的限制。
時間戳記與說話者標籤能提升可追溯性，但也會縮小適用範圍
錄音音訊在逐字模式下完成設定後，可以回傳包含文字、偏移量與說話者識別碼的 word_info 註釋。這些資料可用於製作字幕、點擊跳轉播放、計算各說話者的發言時間，以及進行證據審查。
| 需求 | 錄音路徑 | 即時路徑 |
|---|---|---|
| 說話者分離 | 支援；文件列出最多 8 位，3 位以上屬實驗性 | 不支援 |
| 逐字時間戳記 | 支援 | 不支援 |
| 搭配註釋的 Smart 輸出 | 不支援 | 不支援搭配逐字註釋 |
| 時長限制 | 一般為 1 小時；啟用說話者分離或逐字時間戳記時為 30 分鐘 | 每個持續工作階段 10 分鐘 |
| 準確度注意事項 | Google 警告逐字時間戳記可能降低準確度 | 暫時文字在最終確定前可能變動 |
所以，「支援時間戳記」其實不是完整的採購判斷。功能確實存在，但會降低檔案時長上限，也可能犧牲語音辨識準確度。與其把文件上的最大值當成大型會議的可靠性保證，不如實際測試說話者歸屬效果。
自訂詞彙與語言偵測
兩條路徑都支援自動語言偵測與自訂詞彙。Google 文件指出支援超過 85 種語言及語言切換；如果應用程式已經知道使用中的語言，也建議提供 en-US 之類的提示。
自訂詞彙最多可加入 1,000 個詞，但 Google 的實務建議是，通常控制在 100 個以內效果最佳。清單應該用來放產品名稱、縮寫、專有名詞和技術術語，而不是一般常用字。
「支援」不代表在各種口音、方言、嘈雜環境和句中語言切換下都能維持相同品質。早期 Reddit 討論中就有人特別詢問即時路徑能否處理混合語言；這是值得納入測試的案例，但不能視為功能失敗的證據。
「如果影片可以延遲一點，讓字幕和說出的話同步，我會更喜歡。」— u/WaterObjective5107，Reddit
這則留言點出一個 WER 無法衡量的即時產品問題：字幕即使語言內容正確，只要沒有和影片中的說話節奏同步，使用者仍會覺得不對勁。
現有準確度數字，真正能證明什麼
Google 公布的數字相當亮眼，但它們來自不同的評測情境，並不是一個能代表所有情況的 Gemini 3.5 Transcribe 統一分數。這些結果足以支持認真進行試點，卻不能取代針對你的麥克風、口音、專有名詞和說話者模式所做的測試。
| 評測情境 | 公布的 WER | 這代表什麼 |
|---|---|---|
| Artificial Analysis，串流 | 4.0% | 引用的串流平均值，不代表延遲或說話者分離表現 |
| Artificial Analysis，非串流 | 2.6% | 在其測試條件下，引用的錄音音訊平均值 |
| FLEURS，串流 | 5.50% | 涵蓋特定語言環境的多語串流結果 |
| FLEURS，非串流 | 5.04% | 另一組多語錄音音訊結果 |
這些數字出現在 Google 的產品發布公告中；公告也宣稱，相較 Chirp 3，最終轉錄完成時間改善了 70%。但這是 Google 的說法，不是針對你的工作流程所做的獨立測試。
2.6% 和 5.50% 之間的差距並不矛盾，因為兩者採用的路徑、資料集、語言組成和串流條件都不同。與其只看整體 WER，不如直接檢查哪些錯誤會造成實際成本，例如姓名、訂單編號、日期、金額、產品術語和說話者切換。
早期社群回報把語言切換、說話者歸屬、時間戳記行為和長時間錄音是否完整產出列為測試重點；其中一名 X 測試者表示，20 分鐘的片段最後只回傳了 5 分鐘內容。這些只是方向性的個案，不是受控條件下的產品事實。（X 回報）
設定指南沒告訴你的生產環境摩擦
成功上傳檔案或建立 WebSocket 連線，只能證明傳輸流程正常，不能代表已經適合正式上線。真正的風險會在展示環節之後出現：即時文字會變動、不同路徑有不同限制、憑證如何管理、服務仍是預覽版，以及團隊要如何保存可信的逐字稿。
即時字幕需要自行管理狀態
即時回應有兩種用途。interim_input_transcription 是會持續變動、用於字幕預覽的暫時結果；input_transcription 則是已完成確認的片段，可以追加到持久保存的逐字稿狀態中。
可以採用以下狀態管理方式：
- 每次收到暫時更新時，替換畫面上顯示的字幕。
- 只把已完成確認的文字追加到正式逐字稿。
- 在 10 分鐘工作階段上限前更新連線或重新連線。
- 重新拼接不同工作階段時，加入明確的分界標記和去重邏輯。
- 不要讓不可逆的操作依賴暫時文字。
在瀏覽器和行動裝置用戶端中，應使用短效權杖，避免把長期 API 金鑰暴露在前端程式碼裡。你需要一個後端來簽發並限制這些權杖；如果應用程式架構適合，音訊之後就能從用戶端直接流向 Live API。同時要監控連線錯誤、最終確定延遲，以及重複片段。
錄音工作流程需要先定義唯一真實來源
先決定輸出規格，再選擇模式。需要易讀文章時使用 Smart 模式；如果重視原話、說話者或偏移量，就使用逐字模式。
保存逐字結果與相關註釋，再另外產生清理後的逐字稿，用於搜尋、摘要或提供給客戶閱讀。這會多一道處理流程，但比起事後試圖還原已刪除的贅詞或被改寫的自我修正，安全得多。
預覽版狀態會影響部署決策
Google 在 August 26, 2026 宣布 Gemini 3.5 Transcribe 模型家族進入公開預覽。Google 模型參考資料列出了功能與限制，但由於仍是預覽版，在遷移前仍應重新確認價格、配額、行為和可用性。
先用小型、非敏感的評測資料集和已保存的參考逐字稿開始。分別評估關鍵實體準確度、說話者歸屬、最終確定延遲、重新連線行為和審閱者修正率；在測試前先訂出書面通過門檻，只有每項門檻都達標後才逐步擴大使用。
別只看價格，要算「可接受逐字稿」的成本
Gemini 3.5 Transcribe 按目前顯示的估算價格來看相當便宜，但它採用的是按 Token 計費，不是保證固定的每分鐘費率。Google 官方價格表列出的估算是：錄音音訊輸入每分鐘約 $0.003，加上文字輸出每分鐘 $0.002，混合計算約為每分鐘 $0.005；Live 的混合估算則約為每分鐘 $0.009。
| 路徑 | 音訊輸入估算 | 文字輸出估算 | 混合規劃估算 | 100 小時 |
|---|---|---|---|---|
錄音 gemini-3.5-transcribe | $0.003/分鐘 | $0.002/分鐘 | $0.005/分鐘 | 約 $30 |
Live gemini-3.5-transcribe-live | 約 $0.005/分鐘 | 約 $0.004/分鐘 | $0.009/分鐘 | 約 $54 |
以此估算，100 小時錄音的第一筆預算約為 $30，即時模式則約為 $54；這還不包括重試、儲存、音訊轉檔、人工修正和後續摘要處理。輸出長度與額外提供的上下文都可能改變帳單，因此應保留使用量紀錄。
截圖擷取自 Google 公開價格頁面；在承諾大量使用前，請先確認目前的價格表。詳見官方 Gemini API 定價文件。
計算可接受逐字稿的成本時，應把 API 用量、審閱時間、審閱者費率、重試、儲存、轉檔和後續處理全部算進去。如果 Smart 模式的修正，或額外進行一次註釋處理，能降低人工校正量，那麼即使 API 單價較高，整體成本仍可能更低。
Gemini 3.5 Transcribe API 評測常見問題
Smart 轉錄能保留完全精確的原話嗎？
不能。Smart 模式會編修語助詞和自我修正，因此只要在意原話，就應該把逐字模式保留為來源。
Live API 有說話者標籤或逐字時間戳記嗎？
沒有。如果需要說話者分離或逐字時間戳記，請使用錄音路徑。
Gemini 3.5 Transcribe 能處理長時間會議嗎？
一般錄音上限為 1 小時；啟用說話者分離或逐字時間戳記時為 30 分鐘；Live 則限制為每個持續工作階段 10 分鐘。
它適合法律、醫療或合規逐字稿嗎？
只能把它當成輔助層，搭配逐字輸出、關鍵欄位檢查和人工審閱使用；不要把 Smart 輸出當成高風險紀錄的唯一版本。
結論：可以拿來做原型，但別讓它不知不覺變成正式紀錄
如果你的需求是低成本、多語言、能理解上下文的轉錄，而不是完美保留每個字，Gemini 3.5 Transcribe 值得認真考慮。建議先從錄音路徑開始，用自己的音訊比較 Smart 與逐字輸出；只有在 30 分鐘上限可以接受時，才加入相關註釋。
等到用戶端能安全串流所需的 PCM 格式，並且能把暫時文字和最終文字分開處理後，再考慮切換到 Live，用於字幕或語音介面。至於敏感紀錄，務必保留原始路徑，並把人工審閱列入驗收條件，而不是等 Smart 模式改寫來源後，才臨時補救。