Subanana 處理速度比一年前快最多 7 倍

2025 年 7 月，一段一小時的會議錄音要 26.8 分鐘 才處理完。

這個月，同樣的工作只需要 4.9 分鐘。

這不是為了好看而設計的測試。這是我們兩個 7 月各自「一小時會議」的處理時間中位數 — 不是精選的示範檔案 — 失敗的工作兩邊都已剔除。同一個月份、同樣的檔案長度、同一套量測方法。大約快了五倍半 — 更長的檔案進步幅度還要大。

沒有人推出過一個「提速大版本」。這是一年來在管線裡那些沒有人會寫部落格的部分持續改進的結果，日積月累而成。

實際改變了什麼

2025 年 7 月對 2026 年 7 月的處理時間中位數。每格的第二個數字是最慢的一成 — 十件工作裡最慢那件的水準。中位數會讓數字好看；尾端才告訴你最差的一天是什麼樣子。

尾端的進步比中位數更大，而且更重要。一年前，每十段一小時會議就有一段要超過一小時才回來；現在最慢的一成從七分鐘起算 — 今天一件慢的工作，比當年一件平常的工作還要快好幾倍。最差情況的一小時影片從超過兩小時變成 21 分鐘。如果你一直默默在行事曆裡為 Subanana 預留緩衝時間，可以停了。

越長的檔案進步越大 — 7 倍就在「2 小時會議」那一列。這跟一般管線只針對短示範片調校的結果剛好相反，而這個差別會改變使用習慣：等一個半小時是「吃完飯再回來」的工作；等七分鐘是「坐著等」的工作。

而且趨勢沒有放緩：7 月最後一週是 Subanana 歷來最快的一週，一小時影片的中位數是 5.5 分鐘。

令我意外的部分

以下是今天一段一小時影片的等候時間分布。各階段互有重疊，所以請當作大致比例看，而不是嚴格的先後順序。

轉錄 — AI 那部分 — 大約只佔等候時間的五分之一。

AI 從來都不是瓶頸。大家都以為語音轉文字是最慢的一環，因為那是有模型的一環。其實不是，而且已經好一段時間不是。你等候的時間大約五分之四花在後勤：解碼檔案、抽出乾淨的音軌、產生波形、算繪編輯器需要的預覽，讓你之後可以拖曳檢視結果。

這正好解釋了進步來自哪裡。單是把檔案送進管線這一步，6 月至今已經快了超過 90%；媒體準備時間大約減半。轉錄本身沒有多少可以再贏的空間，其餘一切卻有很多。

從上表可以帶出三件值得知道的事：

會議回來得最快。 會議工作完全跳過影片預覽算繪那一步，這是同樣長度之下會議列總是快過影片列的主因。

加翻譯不會拖慢你的結果。 翻譯以非同步方式進行 — 原文的逐字稿和字幕照樣最快到手，翻譯好的字幕軌隨後自動出現。如果你一直為了保住處理速度而不加翻譯目標，其實不需要。字幕模式下一件工作可以加入多個翻譯目標。

上傳時間不在這些數字之內。 計時從處理開始起算，也就是檔案送達之後。網路慢的話，上傳可能佔你等候的一大半。如果影片本身是公開的，貼上 YouTube、Instagram 或 Facebook 連結就可以跳過上傳 — Subanana 會直接擷取。

抄捷徑抄不到的部分

任何人都可以租用一個好的語音轉文字模型。這是這個類別的公開祕密 — AI，最有神祕感的那部分，任何人申請一組 API key 都用得到，所以每週都有新的轉錄應用程式出現。

但模型只佔你等候時間的五分之一。其餘五分之四是圍繞著它的機器：接收、解碼、抽音軌、建立字幕、算繪預覽、排隊。這些統統租不到，只能自己打造、用真實工作負載量測、再重新打造 — 而它要變快，唯一的方法是把工程時間花在示範裡永遠看不到的問題上。

這一年實際發生的就是這件事。不是一個大版本，也不是幸運換了個模型：提速在過去一年半幾乎每個月都在累積。一個週末拼出來的套殼應用程式可以用到跟我們一樣的轉錄；那五分之四它拿不到，而每次你上傳長檔案，感受到的正是那五分之四。

沒有改變的部分

重試仍然免費。當轉錄結果看起來有問題，系統會在底層自動把受影響的段落交給另一個模型重新處理，不會通知你。第二次處理不會收費 — 一個檔案只收一次錢，無論內部重試了多少次。一年前如此，現在如此，只是發生得更快。

限制也沒有變：付費方案每個檔案 3 小時、15 GB。實際上大家先碰到的是 3 小時上限。

拿一段長錄音試試

如果你一直因為不想花一小時等而擱置一段兩小時的錄音，這筆帳已經改變了。現在大約是 11 分鐘。

AI 會議轉錄 和 AI 字幕 都運行在這些數字背後的同一條管線上。

所有數字均為處理時間中位數 — 2025 年 7 月（整月）對 2026 年 7 月 1 至 27 日 — 依來源長度分組，剔除失敗工作，從處理開始起算。「2 小時」的列涵蓋 90 分鐘至 3 小時的檔案。實際時間會因檔案大小、編碼與負載而異。