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

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

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

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

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

實際改變了甚麼

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

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

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

而且趨勢未見放緩：7 月最後一個星期是 Subanana 歷來最快的一個星期，一小時影片的中位數是 5.5 分鐘。

令我意外的部分

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

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

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

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

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

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

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

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

抄捷徑抄不到的部分

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

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

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

沒有改變的部分

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

檔案上限反而放寬了：2026 年 7 月底起，所有計劃每個檔案 30 GB、8 小時。

拿一段長錄音試試

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

AI 會議轉錄 和 AI 字幕 都運行在這些數字背後的同一條管線上。想全面了解收費和適用情況，可以看創辦人親自寫的 Subanana 評測。

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