會議逐字稿，我實測了七種本地模型
如果你也會把開會錄音丟給 AI 轉逐字稿，這篇可能幫你少走一段冤枉路。我想找一個能在自己電腦上跑的語音辨識模型（STT，把講話轉成文字），把線上會議錄音變成逐字稿。難在我開會是台灣腔中文夾英文技術詞，一句話裡中英文混著講（code-switching）——這對辨識模型最折磨。我實測的其中一個，就把我們在討論的「trunk-based」聽成「Trump-based」，整段在討論 git 分支策略，硬是變成在講川普。
我前後測了幾個本地模型，想挑出最適合做會議逐字稿的那一個——更精確說，是要換掉 Vexa 背後跑的那個辨識模型。（Vexa 是開源的線上會議記錄工具，我在 Day 141 介紹過：https://dawsonwang.com/day/141）測完最有用的一條結論其實跟 Vexa 無關：研究榜單幫你挑的模型，很可能在你自己的錄音裡最爛——榜單公認最強的那個，我實測直接墊底；而真正跑得上線的那個，又不是最準的那個。這篇講怎麼測、排名長怎樣，最後才是我幫 Vexa 換上哪個。
先講結論
- 純比準度、在 Mac 上自己跑：mlx-whisper 的 large-v3 最準，中英混講幾乎不出錯。
- 要塞進 Vexa 這種服務（Linux 容器、只能吃 CPU）：faster-whisper 的 large-v3。
- 反而是榜單（研究者拿公開資料集打的排行榜）最推、規格上主打中英混講的那兩個（SenseVoice、Qwen3-ASR），實測都在中後段——榜單越推的，越容易在你的錄音裡翻車，等一下講為什麼。
說白了：挑模型別看榜單，看你自己的錄音、還有你實際跑得動什麼。
怎麼測的
我從一場 63 分鐘的真實會議裡，剪出中英夾雜最密集的 5 分鐘——剛好是我跟同事在討論 git 要用 trunk-based 還是 release branch，台灣腔、講很快、術語全是英文。這種片段最能看出一個模型的真本事。
一口氣跑了七種：老牌的 Whisper 系列（mlx-whisper 的 large-v3 跟 turbo、faster-whisper）、阿里巴巴的 SenseVoice 跟 Paraformer、今年 1 月底最新、主打中英混講的 Qwen3-ASR，再加上 Vexa 現在跑出來的版本當對照。評分不只我自己看，還找了 5 個 AI 各自獨立打分數，看每個把哪些中英文詞聽對、哪些聽歪，免得只憑我一個人的偏好。
排名，跟它們怎麼出包
mlx-whisper-large-v3 第一，5 個評審一致選它，9.12 分，而且快——整場 63 分鐘只花 320 秒，大概是即時的 12 倍速。
掉最慘的，全是榜單跟規格上最被看好的。被研究捧最高的 SenseVoice，3.66 分墊底：英文詞吃掉一半，commit 變成「bucomit」、sync 變成「think」、share 直接變「血」。Paraformer 也一樣，tag 聽成 tiger、「收束」變「手術」。那個把 trunk-based 聽成 Trump-based 的，就是這批。
最新、主打中英混講的 Qwen3-ASR 也沒躲過。它其實比同門的 SenseVoice、Paraformer 強，常見英文詞 main、branch、release、commit 都聽得乾淨——但整場在討論的主角 trunk-based，它聽成「雙倍」；每一句「打 tag」都變「打 take」，一段錯十幾次，而且一樣會跑出簡體，最後只落在中段。
Vexa 自己的現況（faster-whisper medium）卡在中間，能用，但常常漏詞，連我們在討論的 trunk-based 都聽成「川貝斯」。
七個模型一次看：
| 模型 | 評審分（/10） | 簡/繁 | 怎麼出包 / 備註 |
|---|---|---|---|
| mlx-whisper large-v3（Mac / Metal） | 9.12（第一，5 評審一致） | 繁 | trunk-based ✓、sync ✓、tag ✓，沒有重複迴圈，只把 main 聽成「man」；63 分鐘只花 320 秒（約即時 12 倍速）。最準，但跑在 Metal、進不去 Linux 容器 |
| mlx-whisper turbo | 7.24 | 繁 | 速度最快（RTF 0.22），但 trunk-based →「Trump-based」、主軸 →「詛咒」 |
| faster-whisper large-v3（CPU） | 6.48 | 簡 | 術語大致對，但有嚴重重複迴圈、ship →「shoot」；換進 Vexa 後實際上線排第 2（RTF 0.44，2 倍餘裕撐即時） |
| faster-whisper medium（Vexa 原本） | 5.22 | 繁 | 串流打亂順序、漏內容；trunk-based →「川貝斯」、Hotfix →「Halfix」 |
| Qwen3-ASR（阿里巴巴，今年最新） | 4.75 | 簡 | 常見英文詞乾淨，但 trunk-based →「雙倍」、打 tag → 打 take、會跑簡體 |
| Paraformer（阿里巴巴） | 3.76 | 簡 | tag →「tiger」、release branch →「redesprain」、收束 →「手術」 |
| SenseVoice（阿里巴巴） | 3.66 | 簡 | 英文詞吃掉一半：commit →「bu」、tag →「配个」、sync →「think」、share →「血」 |
為什麼榜單越推的，越容易翻車
兩種出包的方式不一樣，但病根是同一個。SenseVoice 是 non-autoregressive（一次把整段吐出來，不是一個字接一個字慢慢預測），換來速度，碰到沒把握的英文 token 就吃掉、拼錯；它榜單上會贏，是因為那些評測用的是日常對話、簡體中文的資料集，沒有「一句話塞滿英文工程術語」這種場景，也沒測繁體。Qwen 反過來，英文聽得很準，卻把 trunk-based、tag 這些它沒十足把握的詞，換成「雙倍」「take」這些它更熟的——它規格上主打中英混講，但「混的是哪個領域的詞」沒人替你保證。
說穿了，榜單跟規格都是拿別人的資料測出來的。二十幾篇論文、再響亮的賣點，測的都不是你的會議。一段我自己的錄音，5 分鐘就把榜單第一變成最後一名。
最準的那個，塞不進 Vexa
事情還沒完。mlx-whisper 是跑在 Apple 晶片的 Metal（蘋果晶片的 GPU 運算層）上的，而 Vexa 的辨識服務跑在 Linux 的 Docker 容器裡，Metal 進不去那個容器。實測最準的那個，沒辦法直接塞進 Vexa——倒不是完全不能用——想要最準，可以在 Mac 上另外起一個 mlx-whisper server、讓 Vexa 連過去，代價是多接一層、原生 Vexa 不支援。
所以「Vexa 能用的最準」是另一個問題：在 CPU 上、faster-whisper 這個實作裡挑。我把同一段拿 large-v3 跟 turbo 在 CPU 上比 RTF（real-time factor，處理時間除以音檔長度，小於 1 就代表比即時還快）：large-v3 是 0.44，turbo 0.22。turbo 快一倍，但 large-v3 的 0.44 還有 2 倍多的餘裕撐即時串流，又準很多。換 large-v3。
換完之後
改一行設定（MODEL_SIZE 從 medium 改成 large-v3），把 Vexa 的辨識服務重啟，確認 log 印出 large-v3。再把那段重新跑一次：原本 9 個詞對、6 個錯，變成 15 個對、0 個錯，Vexa 自己的排名從第 4 升到第 2。
那個「川貝斯」——Vexa 之前把 trunk-based 聽成的——也修好了。
還沒解乾淨的
老實講，這結論有但書。
我只測了一段 5 分鐘、兩個男生、講 git 的錄音，沒有人工逐字稿當標準答案，所謂「準」是幾個模型互相對照出來的共識，方向對，但不是精密測量。
還有一個真沒解掉的：簡體繁體會飄。模型本身夠準，但 Vexa 的 bot 送辨識請求時沒帶「請用繁體」的提示，所以同一個模型有時吐簡體、有時吐繁體。這個之後得從 pipeline 那層補，今天還沒動。
其實這也接回 Day 145 講的（https://dawsonwang.com/day/145）——逐字稿本來就是半成品，辨識錯字、同音異字、人名亂跳，本來就得再過一層 AI 才好用。選對模型不是讓你跳過那一層，是讓那一層要清的髒東西少一大半。
一句話總結：要找「最適合會議逐字稿的模型」，答案不在任何榜單上，在你自己那段最難的錄音裡——前提是你的機器還跑得動它。
你最難搞的那段錄音是什麼場景？中英文混講、重口音，還是一堆專有名詞？