Parakeet Unified 0.6B 納入為新 backend（#110 子項 B）

[kiki830621]

Problem

Original text（父 issue #110）：
「Parakeet Unified 0.6B：新後端，原生 Swift mel 前端、詞級時間戳；英文批次 WER/吞吐優於 TDT v3。」

FluidAudio 0.15.5 帶來 Parakeet Unified 0.6B —— 父 issue 明指為新後端（不是既有
fluid-parakeet 上的新模型 row），有原生 Swift mel 前端與詞級時間戳。

Type

feature

Expected

評估並（若可行）接成新 backend：BackendID 新 case + ModelGrid rows + ModelRegistry
記憶體估計 + engine 實作 + 測試，納入 benchmark 矩陣與 en 語料的比較。

Impact

• Sources/BestASRKit/Models/DataModels.swift（BackendID）、ModelGrid.swift、
  ModelRegistry、Sources/BestASRKit/Engines/（可能新 engine 或擴充 ParakeetEngine）、測試
• Engine protocol 只需 id / isAvailable() / transcribeRaw()（Engines/Engine.swift:61），
  接線成本可控；不確定性在 Unified 的 API 面是否與既有 AsrModels/AsrManager 路徑一致

依賴

Blocked by #122（pin bump 0.15.5）—— 0.15.4 沒有這個後端。

待 diagnose 釐清

1. Unified 是否沿用 AsrModels.download/load + AsrManager，還是另一套 API 面（決定 scope）
2. 詞級時間戳如何映射到 bestASR 的 segment 模型（ParakeetEngine.swift:26 現有的
   token-timing → segment 整形邏輯可否重用）
3. 與既有 fluid-parakeet（tdt-0.6b-v3）並存時，ModelGrid 的 family/size 軸怎麼區分

Source: decomposed from #110（2026-08-01）。

[kiki830621]

Diagnose — 三個待釐清問題都有答案了，而且第 2 個改變 scope

方法：git clone FluidAudio 至 tag v0.15.5，讀原始碼。是「讀」不是「跑」——下面每一條都能指到檔案行號，但沒有任何一條是實際執行過的行為觀察。真正接線前該補一次 spike。

---

Q1 — Unified 沿用 AsrModels.download/load + AsrManager 嗎？不。是另一套 API 面。

	既有 fluid-parakeet	Parakeet Unified
型別	AsrManager（class）	public actor UnifiedAsrManager / public actor StreamingUnifiedAsrManager
模型取得	AsrModels.downloadAndLoad(version: .v3)	ModelHub.download(...) + MLModel.load(...)，名稱來自 ModelNames.ParakeetUnified
前端	CoreML preprocessor bundle	原生 Swift mel（UnifiedMelExtractor / AudioMelSpectrogram + NeMo per-feature normalization），preprocessor bundle 「neither downloaded nor loaded」

Sources/FluidAudio/ASR/Parakeet/Unified/UnifiedAsrManager.swift:49, 88, 133, 157、Sources/FluidAudio/ModelNames.swift:555-577。

連帶影響 #122 的一句 CHANGELOG：那裡寫 DownloadUtils → ModelHub 「is not [breaking] for this repo: … this repo has zero references to it」。對 pin 本身成立，但 Unified 強制經過 ModelHub，所以一旦接上 #123，那個「零引用」前提就消失。#122 的敘述不需要改（它描述的是 pin 當下的事實），但 #123 的 PR 應該明說它引入了那個依賴。

---

Q2 — 詞級時間戳怎麼映射？offline 那條路拿不到時間戳。

這是最重要的一條。UnifiedAsrManager.transcribe() 回傳裸 String：

public func transcribe(_ samples: [Float]) async throws -> String      // :172
public func transcribe(_ buffer: AVAudioPCMBuffer) async throws -> String  // :207

沒有 ASRResult、沒有 tokenTimings。時間戳只在 streaming manager 上：

public func consumeTokenTimings() -> [TokenTiming]   // StreamingUnifiedAsrManager.swift:195
public func consumeWordTimings()  -> [WordTiming]    // :205

好消息：TokenTiming 是同一個 public 型別，ParakeetEngine 現在就在映射它（ParakeetEngine.swift:17, 87 — ASRResult.tokenTimings: [TokenTiming]? → ParakeetOutput.tokenTimings）。所以既有的 token-timing → segment 整形邏輯可以重用，改變的是取得方式，不是型別。

壞消息：取得方式差很多。既有 engine 把 URL 交給 AsrManager 拿一個 ASRResult；Unified 要驅動一個 streaming 迴圈：

loadModels → appendAudio(buffer) → processBufferedAudio() → finish() -> String
                                                          → consumeWordTimings()

而 Engine.transcribeRaw(audioPath:options:) 是一次性呼叫，所以 engine 內部要自己把整個檔案餵進去再 drain。可行，但這是新的整合形狀，不是既有 engine 加一個 model row。

consumeTokenTimings() 的 doc 自己記了一個會影響 segment 整形的細節：

The final token of a drained batch may carry a provisional one-frame endTime (the next emission's start is not yet known).

consumeWordTimings() 依 ▁ / leading-space 邊界分組，且與 consumeTokenTimings() 共用同一個 buffer（「call one or the other per cycle」）——兩個都叫會拿到空的。

---

Q3 — ModelGrid 怎麼跟既有 fluid-parakeet（tdt-0.6b-v3）區分？

Unified 的身分不只是 model 名稱，還有兩個軸（ModelNames.swift:559-577）：

1. 精度：offlineEncoderInt8File / offlineEncoderFp16File。int8 是預設，upstream 報 test-clean WER 1.83%/2.14% vs fp16 1.82%/2.15%，「same ANE latency, half the download」。
2. offline vs streaming，且 streaming encoder 把 [left, chunk, right] attention context 烤進檔名（70_13_13 = 2.08 s），每個 latency tier 是不同檔案。

所以 grid 至少要能表達「Unified · offline · int8」。若之後要接 streaming，latency tier 是第三個軸——建議 #123 只做 offline，streaming 另開。

---

Scope 建議（未定案，等討論）

Engine protocol 只要 id / isAvailable() / transcribeRaw()，接線成本本身可控。真正的成本在：

• 新 BackendID case = 跨 repo 的 wire contract（DataModels.swift:209-217 明寫 bench 端舊 client 對未知值會拒絕），所以要有 migration 說法，不是加一行 enum。
• streaming 迴圈 + drain 語意（共用 buffer、provisional endTime）需要自己的測試。
• ModelHub 依賴要在 PR 裡說明。

---

目前被什麼擋著（兩層，第二層是我造成的）

1. FluidAudio pin 0.15.4 → 0.15.5（#110 子項 A，B/C 的 blocker） #122 尚未 merge。PR chore: pin FluidAudio 0.15.4 → 0.15.5 (#122) #142 在 9172f4b、MERGEABLE、CI 綠，但我自己的 round-2 報告設了閘：「Re-verify at 9172f4b before merge」，理由是當時 Codex quota 掛掉、缺跨模型那條腿。Codex 現在可用。
2. idd/123-parakeet-unified 這條 branch 上的 pin commit 是空殼。0b736de 的 message 寫「pin 0.15.4 → 0.15.5」，但 Package.swift:16 仍是 exact: "0.15.4"。這是 chore: pin FluidAudio 0.15.4 → 0.15.5 (#122) #142 round-2 那次 branch surgery（把 Package.* 從 fix: regression gate reported exit 0 on real regressions (#134) #140 搬到 chore: pin FluidAudio 0.15.4 → 0.15.5 (#122) #142）的後果——這條 branch 從更早的狀態長出來，沒收到修正後的 pin。要接 Parakeet Unified 0.6B 納入為新 backend（#110 子項 B） #123 得先把它重建在 chore: pin FluidAudio 0.15.4 → 0.15.5 (#122) #142 之上。

上面的 diagnose 不受這兩點影響（直接讀 upstream tag），但實作要等。

[kiki830621]

偵察補充：Parakeet Unified 的 repo 與 pinned sha（來自 #183 discuss 期間的 /asr-model-scout 掃描）

掃 FluidInference 的 ASR 目錄時掃到本 issue 的對象，順手把 supply-chain 紀律要的 sha 探了：

repo id	FluidInference/parakeet-unified-en-0.6b-coreml
revision	4252711f6f06
語言（model card 實查）	en
license	cc-by-4.0

以及一個本 issue 可能還沒記的事實：同一個模型另有 OpenVINO 版 —
FluidInference/parakeet-unified-en-0.6b-ov（未探 sha）。若之後 backend 要支援非 CoreML 執行路徑，
這是同一模型的第二個 runtime。

來源：https://huggingface.co/FluidInference/models 第 1 頁（59 個 repo 中的 30 個）+
https://huggingface.co/api/models/FluidInference/parakeet-unified-en-0.6b-coreml。
repo id 實查、非憑記憶；完整偵察表在 docs/model-catalog-candidates.csv。

尚未做：weights digest 未抓、est_memory_gb 未量。兩者都是納入前必要。

相關：#185 收其餘 8 筆已 pin sha 的候選（blocked by #183）；本 issue 的 parakeet-unified 刻意
排除在 #185 之外，因為它是新 backend 而非既有 backend 上的新 row。