借助 NVIDIA NeMo 實現出色的 ASR 模型 10 倍加速

這些可將語音轉錄為文本的 NVIDIA NeMo ASR 模型提供了一系列旨在優化速度和準確性的架構：

• CTC 模型 ( NVIDIA/parakeet-ctc-1.1b )：此模型具有 FastConformer 編碼器和 softmax 預測頭。它是非自回歸的，這意味著未來的預測不依賴于之前的預測，從而實現快速高效的推理。
• RNN-T 模型 ( NVIDIA/parakeet-rnnt-1.1b )：此傳感器模型向 FastConformer 編碼器添加了預測和聯合網絡，使其成為自回歸模型 – 每個預測都取決于先前的預測歷史。由于此屬性，人們普遍認為 RNN-T 模型的 GPU 推理速度較慢，更適合 CPU。

• TDT 模型 ( NVIDIA/parakeet-tdt-1.1b )：另一個傳感器模型，但使用名為 token-and-duration 傳感器 (TDT) 的改進傳感器目標進行訓練。雖然仍然是自回歸模型，但它可以在每個步驟中執行多個預測，從而加快推理速度。
• TDT-CTC 模型 ( parakeet-tdt_ctc-110m )：這是傳感器和 CTC 解碼器的混合變體，可同時引入兩個解碼器，從而在訓練期間加快收斂速度。它只需訓練一個模型即可訓練兩個解碼器。
• AED 模型 ( NVIDIA/canary-1b )：Attention-encoder-decoder (AED) 模型也基于 FastConformer，具有自回歸性，能夠以額外計算為代價提供更高的準確性（更低的 詞錯誤率或 WER ）。

以前，這些模型面臨速度性能瓶頸，例如投射開銷、低計算強度和發散性能問題。

在本文中，您將了解 NVIDIA 如何通過將張量自動投射到 bfloat16、創新的標簽循環算法以及引入 NeMo 2.0.0 中可用的 CUDA Graphs 等關鍵增強功能，將 NeMo ASR 模型的推理速度提升高達 10 倍（圖 1）。

克服速度性能瓶頸?

本節將深入探討 NVIDIA 自動語音識別（ASR）模型如何克服各種速度性能瓶頸，包括投射開銷、批量處理優化、低計算強度和發散性能問題。

自動混合精度會產生額外開銷?

從 NeMo 的早期開始，便一直在 torch.amp.autocast 上下文管理器中 執行推理。這將在矩陣乘法之前自動將 float32 權重投射到 float16 或 bfloat16，從而實現半精度張量核心運算的使用。在幕后，自動混合精度（AMP）維護一個“投射緩存”，用于存儲這些轉換，通常會加快訓練速度。然而，會出現以下問題：

• 過時的自動投射行為 ：自動投射是在 softmax 和 layer norm 等運算較為罕見時開發的。在像 Conformers 和 Transformers 這樣的現代模型中，這些運算很常見，會 將float16或bfloat16 輸入投射回 float32 ，從而在每次矩陣乘法之前導致額外的投射。
• 參數處理： 要使 AMP Cast 緩存有效，參數需要 requires_grad=True。遺憾的是，在 NeMo 轉錄 API 中，此標志設置為 False（ requires_grad=False ），從而阻止緩存工作，并導致不必要的 Cast 開銷。
• 頻繁的緩存清除 ：每次退出 torch.amp.autocast 上下文管理器時，都會清除轉換緩存。用戶通常會在上下文管理器中包裝單個推理調用，從而無法有效利用緩存。

這些額外投射的開銷非常高。圖 2 顯示了 Parakeet CTC 1.1B 模型中矩陣乘法之前的投射如何增加 200 微秒的開銷，而矩陣乘法本身僅需 200 微秒，這意味著一半的運行時間用于投射。這由 NVIDIA Nsight Systems 捕獲，NVIDIA Nsight Systems 是一種分析工具，可在時間軸上可視化工作負載指標，以實現性能調優。

在圖 2 的 CUDA 硬件行中：

• 前兩個淺藍色部分表示處理從 float32 到 bfloat16 的投射的內核。
• 空白區域表示投射開銷占總運行時間 400 微秒中的 200 微秒。

借助全半精度推理解決 AMP 開銷問題

為了應對與 AMP 相關的挑戰，我們通過完全以半精度（float16 或 bfloat16）執行推理來實施最佳實踐。這種方法如 NVIDIA/NeMo 在 GitHub 上的拉取請求中所述，可在不影響準確性的情況下消除不必要的投射開銷，因為像 softmax 和 layer norm 這樣的精度敏感型操作在后臺仍使用 float32，即使指定了半精度輸入也是如此。請參閱 AccumulateType 和 SoftMax 示例。

您可以通過設置 compute_dtype=float16 或 compute_dtype=bfloat16 在 examples/asr/transcribe_speech.py 中啟用此功能，同時確保未設置 amp=True (默認值為 amp=False)。同時設置 amp=True 和 compute_dtype 值將導致 錯誤 。如果您正在編寫自己的 Python 代碼，只需調用 model.to(torch.bfloat16) 或 model.to(torch.float16) 即可實現此優化，如 NeMo/examples/asr/transcribe_speech.py 所示。

優化批處理以提升性能

在 NeMo 中，某些操作最初是依次執行的，一次處理一個迷你批量的一個元素。這種方法導致速度減慢，因為每個內核操作在批量大小為 1 時運行得很快，但為每個元素啟動 CUDA 內核的開銷會導致效率低下。通過切換到全批量處理，我們充分利用了 GPU 流多處理器資源。

兩個特定操作（ CTC 貪婪解碼 和 特征歸一化 ）受到此問題的影響。通過從順序處理轉向完全批量處理，我們將每次操作的吞吐量提高了 10%，總體速度提高了約 20%。

在解決了類似問題后， SpecAugment 的速度提高了 8-10 倍。（此操作僅在訓練期間運行，因此這里不是重點。）

RNN-T 和 TDT 預測網絡中的低計算強度

RNN-T 和 TDT 模型長期以來一直被認為不適合服務器端 GPU 推理，因為它們具有自回歸預測和聯合網絡。例如，在 Parakeet RNN-T 1.1B 模型中，貪婪解碼占用了總運行時間的 67%，盡管預測和聯合網絡僅占模型參數的不到 1%。

原因是？這些內核執行的任務很少，因此其性能完全受內核啟動開銷的限制，因此在大部分時間內 GPU 都處于空閑狀態。例如，執行 CUDA 內核可能只需 1 到 3 微秒，而啟動 CUDA 內核可能需要 5 到 10 微秒。在實踐中，我們發現 GPU 空閑時間約為 80%，這表明消除這一空閑時間可以將推理速度提高 5 倍。

圖 3 顯示了 RNN-T 貪婪解碼算法的幾個“外部時間步長”的快照。CUDA HW 行包含多個空白（非藍色）區域，表示沒有執行 CUDA 代碼的時間。由于算法中的每個外部時間步長對應于處理單個 80 毫秒的輸入幀，因此運行 1.5 到 4.3 毫秒的速度慢得令人無法接受。

在圖 3 的 CUDA 硬件行中，非藍色區域表示何時未執行 CUDA 代碼（GPU 處于空閑狀態）。

通過 CUDA 圖形條件節點中的動態控制流消除低計算強度

傳統上，CUDA 圖形用于消除內核啟動開銷。然而，它們不支持動態控制流，例如 if-else 循環，使得它們不適合直接用于貪婪解碼。 CUDA 工具包 12.4 引入了 CUDA 圖形條件節點 ，可啟用動態控制流。

我們使用這些節點對 RNN-T 和 TDT 模型實施貪婪解碼，有效消除了以下文件中的所有內核啟動開銷：

• cuda_graph_rnnt_greedy_decoding.py
• nt_loop_labels_computer.py
• tdt_loop_labels_computer.py

后兩個文件實現了貪婪解碼的標簽循環變體，這將在下一節中討論。

有關該問題和我們的解決方案的詳細說明，請參閱我們的論文 《Speed of Light Exact Greedy Decoding for RNN-T Speech Recognition Models on GPU》。此外，我們還 向 PyTorch 提交了一個拉取請求 ，以支持在純 PyTorch 中使用其新的 torch.cond 和 torch.while_loop 控制流 API 的條件節點，而無需與 CUDA API 進行任何直接交互。

RNN-T 和 TDT 預測網絡的差異?

執行批量 RNN-T 和 TDT 推理的一個重要問題是 vanilla 貪婪搜索算法的分歧。這種分歧會導致一些輸入進展緩慢，而另一些則停滯不前，從而導致在使用更大批量大小時增加延遲。因此，許多實現選擇批量大小為 1 的推理來避免此問題。但是，使用批量大小為 1 會導致硬件利用率不充分，這既低效又不經濟。

常用于傳感器解碼的傳統解碼算法（圖 4）采用了嵌套循環設計：

• 外循環：對幀（編碼器輸出）進行迭代。
• 內循環：逐個檢索標簽，直到遇到特殊的空白符號。

對于每個非空白符號，應更新自回歸預測網絡的隱藏狀態和輸出。在批量推理期間，內循環可以為批量中的不同發音生成不同數量的標簽。因此，對于每幀，預測網絡的調用次數由所有發音的非空白標簽的最大數量決定，這是次優的。

圖 4 展示了傳統幀循環解碼算法的示例，該算法分批處理兩個詞，每個詞 4 幀，并進行 CAT 和 DOG 轉錄。? 表示批量解碼中不必要的計算。

使用高效的新解碼算法解決分歧

為了解決傳統的幀循環解碼算法問題，我們推出了一個新的標簽循環算法 ，該算法仍使用嵌套循環，但區別在于循環的角色發生了交換（圖 5）。

• 外循環：在標簽上迭代，直到所有幀都已解碼。
• 內循環：對幀進行迭代，識別批處理中每個語句的下一幀，其標簽為非空白。這是通過推進指向當前編碼器幀的索引來完成的，這些索引因批處理中每個語句而有所不同。

圖 5 展示了新的標簽循環解碼算法的示例，該算法分批處理兩個語句，每個語句 4 幀，CAT 和 DOG 轉錄。? 表示批量解碼中不必要的計算。

在這種方法中，我們會在外循環的每個步驟上以盡可能大的批量大小評估預測網絡。這種評估的數量恰好是所有句子中最長轉錄的長度（以令牌數量表示），這使其成為所需評估的最小數量。內循環僅使用聯合網絡執行操作。為了提高效率，我們在此過程的早期應用了編碼器和預測網絡投影，從而最大限度地減少了昂貴的重新計算需求。

這種批量標簽循環算法顯著提高了 RNN-T 和 TDT 網絡的效率，即使使用純 PyTorch 代碼執行時無需額外的 GPU 特定優化，也能實現更快的解碼速度。

性能提升速度提升高達 10 倍，成本效益提升高達 4.5 倍

標簽循環和 CUDA 圖形使傳感器模型的逆實時系數（即 RTFx（生成音頻的持續時間/計算時間；越高越好）比以往更接近 CTC 模型。這種影響在較小的模型中尤為明顯，在這些模型中，減少內核啟動開銷（尤其是在涉及預測網絡權重和輸入張量等小數據大小的操作中）會帶來更大的性能提升。此外，得益于新實施的向量化特征歸一化解碼實現，CTC 模型的速度有了顯著提高。

在搭載 NeMo 2.0.0 的 NVIDIA NeMo ASR 型號中，所有這些速度提升高達 10 倍（圖 1），可提供快速且經濟高效的 CPU 替代方案。

為了更好地說明基于 ASR GPU 的推理的優勢，我們估算了使用 CPU 和 AWS 等云平臺上常見的 NVIDIA GPU 轉錄 100 萬小時語音的成本，重點是計算優化的實例。在此比較中，我們使用了 NVIDIA Parakeet RNN-T 1.1B 模型。

• 基于 CPU 的估計： 對于 CPU 估計，我們在單個固定的 CPU 核心上運行批量大小為 1 的 NeMo ASR。這是一種常見的行業實踐方法，允許跨多個核心進行線性擴展，同時保持恒定的 RTFx。我們選擇了測量 RTFx 為 4.5 的 AMD EPYC 9454 CPU，可通過 Amazon EC2 C7a 計算優化實例獲得。
• 基于 GPU 的估算： 對于 GPU ， 我們使用了 Hugging Face Open ASR 排行榜的結果，該排行榜在 NVIDIA A100 80GB 上運行。等效的 AWS 實例為 p4de.24xlarge，配備 8 個 NVIDIA A100 80GB GPU。
• 成本計算：為了計算 CPU 和 GPU 的總成本，我們：
  • 將 100 萬小時的語音除以相應的 RTFx。
  • 四舍五入到最近的一個小時。
  • 將結果乘以每小時實例成本。

如表 1 所示，從 CPU 切換到 GPU 進行 RNN-T 推理可節省高達 4.5 倍的成本。

*GPU 的 CPU 或全局批量大小

借助 NVIDIA ASR 加速轉錄?

NVIDIA NeMo 可將 ASR 模型的性能提升高達 10 倍，在 Hugging Face Open ASR 排行榜上名列前茅。這一速度飛躍由自動投射到 bfloat16 的張量、標簽循環算法和 CUDA Graphs 優化等創新提供動力支持。

這些加速性能還可顯著節省成本。例如，與基于 CPU 的替代方案相比，基于 NVIDIA A100 的 NeMo GPU 驅動的推理在轉錄 100 萬小時語音時可節省高達 4.5 倍的成本。

持續優化 NVIDIA Canary 1B 和 Whisper 等模型的努力將進一步降低運行注意力編碼器 – 解碼器和基于語音 LLM 的 ASR 模型的成本。NVIDIA 還在改進其 CUDA Graphs 條件節點，并將其與編譯器框架 TorchInductor 集成，這將進一步加快 GPU 運行速度并提高效率。有關更多詳情，請 查看我們的拉取請求，獲取 PyTorch 中的條件節點支持 。

我們還發布了更小的 Parakeet 混合傳感器-ctc 模型， Parakeet TDT CTC 10M ，可實現約 4,300 的 RTFx，并將 HF ASR 排行榜測試集的平均 WER 準確度提高到 7.5，進一步擴展了 NeMo ASR 的功能。

探索 NVIDIA NIM，用于語音和翻譯 ，以更快、更具成本效益地將多語種轉錄和翻譯集成到在云端、數據中心或工作站上運行的生產應用中。