對話式 AI 應用的降本增效實踐

分享嘉賓｜劉川 NVIDIA 資深解決方案架構師

編輯整理｜李瑜亮

出品社群｜DataFun

Conversational AI 場景總覽

在對話式 AI 工作流中，主要有三個演算法相關模組。ASR 將使用者的語音轉換成文字，NLU（自然語言理解）會針對識別的內容給出文字回復，TTS 會將回復內容轉換為音訊，作為整個鏈路的返回。NVIDIA 在這三個領域都有豐富的演算法與加速技術，本文重點放在 ASR 和 TTS。

2. 痛點與挑戰

語音 AI 工作流的部署面臨著諸多挑戰，主要包括：

① 語音識別準確率難以提升，語音合成音質不佳；

② 涉及到多個模型及前後端，工作管線複雜，對於流式任務排程管理更加複雜，開發難度大，排程不夠高效；

③ 因為沒有高效利用 GPU 資源，導致服務延時高，併發路數低，部署成本居高不下。

我們主要利用 Triton Inference Server 和 TensorRT 解決以上問題。

02

ASR GPU 部署最佳實踐

1. Triton Inference Server 介紹

Triton 是一個開源的推理服務的部署框架，可以將訓練好的模型部署成一個微服務。該框架會排程請求，管理模型，推理請求並返回結果。這個框架支援 GPU 與 CPU 推理，相容 Pytorch，Tensorflow 等多種深度學習框架。

2. ASR 工作流一覽

NVIDIA 提供了一種基於 Triton Inference Server 部署在雲端 GPU 上的 ASR 雲服務的工作流，整個流程分為三部分：

① 使用 Kaldifeat 的 Fbank 特徵提取器，在 GPU 上高效提取多個音訊的特徵；

② Conformer Encoder，根據音訊特徵推理解碼需要的輸入；

③ CTC Prefix Beam Search 的解碼，我們引入 N-Gram 語言模型，並使用 Conformer Decoder 結合 Encoder 的輸出對 N-Best 重新打分。

之所以利用 Triton Inference Server 來部署 WeNet ASR 工作流，讓這三個模組能夠有序地組合在一起，使資料流能夠有條不紊地在三個模組上流動。

3. 使用 Triton 排程模型與請求

Triton 提供的 Ensemble Model 功能允許我們配置各模組之間的依賴關係，上述三個模型就能夠部署成為一個工作流。並且三個模型都是獨立部署的，能夠並行執行，當後置模型在處理上一個請求時，前置模型可以同時推理下一個請求。所以，一方面做到了三個模型的組合，同時也做到了 pipeline 流水線並行和模型推理的解耦。

此外，在上述第三個模組中，涉及到 CTC 和 Decoder Rescoring 的配合，這就存在一個邏輯操作，如果推理到最後一個 chunk 則需要重打分。Triton 的 Business Logic Scripting 功能可以解決這個問題，這是一個簡單的 Python 指令碼，可以透過簡單的程式碼呼叫其它模型，可以便捷地實現各種邏輯操作，控制模型間的資料流。

此外，在請求側的排程上，Triton 提供的 Dynamic Batching Scheduler 透過將多個客戶端同時傳送來的請求合併為一個大的 batch，充分利用了硬體資源，實現了高併發高吞吐。

4. Triton 的流式推理機制

前面我們討論了非流式計算的最佳化。在實際場景中 ASR 服務需要同時處理多個語音資料流，如同個使用者會傳送多段語音。Triton 提供了 Streaming API 針對有前後依賴的流式計算進行最佳化，主要包括以下功能：

① 對每一個 chunk 加上四個標籤：Start - 是否是流的起始 chunk，Ready - 是否有資料需要進行推理，End - 是否是流的結束 chunk，Corrid - 該 chunk 屬於哪個流。

② 合併多個流上的 chunk 進行推理。Triton 上以模型例項的方式做推理，在一個 GPU 上可以啟動多個例項，每個例項又分為 N 個 Slot，意味該例項同時可進行 N 個資料流的推理。資料流首先會在 Sequence Batcher 的 Candidates 佇列中等待處理，當有空閒 Slot 時即可開始處理。為了維護資料流的狀態，一個資料流的所有 chunk 只會在同一個例項上推理以維持每個流的狀態。同時因為依賴關係，同一個時間步的所有 Slot 中的 chunk 只允許來自不同的流。

③ Triton 提供了 Implicit State Management，透過在配置檔案中定義模型的狀態輸入與狀態輸出即可對進行狀態 Tensor 進行管理、更新。此外當資料流進行切換時，也可切換到對應資料流的狀態。極大的簡化了流式計算中狀態管理的工作。

5.  效能提升

我們在 A10 GPU 上測試了 WeNet 模型流式 ASR 的效能，在有 attention rescoring 的情況下，往前看 5 個 chunk，每個 chunk 長度為 640ms，能夠在 400-500 併發路數下實時推理（注：此處測試並未模擬使用者真實流式地說話，而是將每個流的所有 chunk 不停頓地非同步傳送給服務端）。

非流式場景下，我們測試了 ONNX 與 TensorRT 兩種後端。ONNX 能每秒吞吐 180 個 8 秒音訊的請求。另外，我們還提供了 TensorRT 加速方案，針對使用原生 TensorRT 存在的如某些層資料溢位、某些 OP 不支援以及精度和速度下降等問題進行了解決。TensorRT 每秒吞吐能達到 280，進一步高於 ONNX。

6. 進一步的擴充套件

我們的最佳實踐可以進一步進行擴充套件。比如在 ASR 基礎上，加入了 VAD 模組，以及音訊切割模組。這樣整個 pipeline 包括：音訊特徵提取，VAD 的端點檢測，音訊切割，之後是 ASR 推理，這些模組透過前面提到的 Business Logic Scripting 進行串聯。還可以根據需要加入說話人識別、情感分析、標點預測等更多模組。

另外，Triton 還解決了一個問題，一個音訊切成多段後，可以獨立推理，推理完後可以再拼回去，不同客戶端不同請求切完後的所有音訊小段可以打成一個 batch 一齊推理，最後也可以認出每個音訊小段是屬於哪個音訊請求的。

整個 Triton Inference Server 可以作為一個 Docker 容器，可以部署在 K8S 叢集中作為一個 pod，在不同節點上可以部署多個 Triton pod，更可以透過 Triton 提供的 Metrics 來進行彈性擴縮容，形成分散式部署，線性提升吞吐量，從而適應更大流量的業務場景。

03

TTS GPU 部署最佳實踐

1. 流式 TTS 的部署實踐

相對於 ASR，TTS 缺乏較好的開源社群，這也是 TTS 的挑戰之一。我們實現了一個Triton C++ Custom Backend 用於管理和排程客戶端送來的文字請求，並進行 Padding， Batching 等預處理。然後這個 Backend 會呼叫兩個使用 Triton Ensemble 整合的模組：

① Frontend-Encoder 模組包括兩個元件，文字預處理前端（我們使用 Python Backend）和聲學模型 Encoder（我們用的是 FastPitch 及 TensorRT Backend）。一段文字只經過這兩個元件一次，所以將他們整合在一起。

② Decoder-Vocoder 模組包含了Decoder（我們使用 FastPitch 及 TensorRT Backend）和 Vocoder（我們使用 HiFi-GAN 及 TensorRT Backend），因為這兩個元件在流式計算中都需要多次呼叫，所以將它們組合在一個 Ensemble 內。

在這個過程中，Triton Custom Backend 功能允許我們用 C++ 或 Python 開發邏輯模組，這些自定義模組也可以當作模型進行部署。對於聲學模型我們使用 Triton 自帶的 TensorRT 作為 backend 進行部署，對模型推理速度有較好提升。

TTS 的輸入有時為大段文字，為了降低首包延時，我們的實踐採用 Triton 給出流式的，由多個 chunk 組成的輸出。Triton 提供的 Decoupled Response 可以將模型的多個輸出與原始輸入的 request 繫結，幫助我們對每一個 chunk 定位其對應的文字和使用者。

2. 推理效能

我們在 A10 上測試了這套部署方案對不同長度文字（Short 為 15 個字，Middle 為 20 個字，Long 為 30 個字）的推理效能。在 QPS（每秒請求數）為 200 的情況下，這套部署方案的首包延時可以控制在 100ms 以下。

04

結語

Nvidia 在語音領域主要產出了以下有幫助的最佳實踐。

ASR 領域中：

① 我們有基於 Triton 部署流式和非流式 WeNet 的實踐，並且我們對非流式的 WeNet 使用 TensorRT 進行加速；

② 這套方案支援在 K8S 叢集上進行多機多卡的分散式部署；

③ 我們在這套實踐的基礎上給出了整合 VAD 的參考方案；

④ 對 WeNet 的 WeSpeaker 說話人識別功能的支援。

TTS 方面：

① 流式雙語基於 FastPitch+HiFiGAN 部署最佳實踐；

② 我們正在研究多說話人 TTS。

NLU 方面我們還做了 INT8 量化的最佳化，這方面沒有介紹，大家可以參考我們的半開源 Github 專案 CISI (github.com/nvidia-china-sae/CISI) ， 可以發郵件獲取許可權，歡迎大家關注。

05

問答環節

Q1：模型和模型間是否用佇列進行銜接？是否會導致高延遲？

A1：Triton 對於模型的連線非常高效。若多個模組都在 GPU 上，Triton 會避免 GPU 和Memory 之間的複製。Ensemble 方式下，工作流中的多個模型可以並行。基於這些特性，Triton 能減少不必要的 overhead，提高效率。

Q2：流式推理中，如果例項中起了兩個 Slots，但只有一個資料流，效率會低嗎？

A2：會的。這種情況下說明 GPU 效能超過需求，建議做 GPU 的切分（MIG）。或者在同個 GPU 上部署另外多個模型，充分利用資源。

Q3：等待請求打 batch 過程中會有延時嗎？

A3：可以配置等待時間，如果時間設定的很短，只會將同時收到的請求打 batch。

Q4：千分之幾的實時率很快了，如果算上 WST 會不會成為瓶頸？

A4：WST 最大的問題並不是效能，在於 LM 的圖非常的大，對於視訊記憶體的消耗非常大。我們也在考慮有沒有其他方式來解決。

06

劉川：WeNet 社群正在擴充套件其覆蓋的領域，請問彬彬老師是怎麼設計和規劃 WeNet 的發展，希望 WeNet 最終的形態是怎樣？

張彬彬：這也是我們在思考的問題像 Transducer 和識別相關的，我們直接做在 WeNet 的專案裡。比如和說話人相關的 diarization，我們放在單獨的專案 WeSpeaker 裡。TTS 的功能我們也是這樣。橫向整合還是縱向整合是很多開源專案設計之初就要思考的。我們 WeNet 社群是以生產力，輕量級，可維護性為標準。所以社群中會有較多橫向的專案。

劉川：您既是 WeNet 的負責人，也是地平線的研究員。您是怎樣平衡開源專案開發者與企業工程師的工作呢？您是怎樣將開源社和工業落地相結合的？

張彬彬：首先看公司是否支援開源。我之前的公司相對支援開源。另外一點現在的公司對於開源的看法有著不一樣的高度。地平線和開源社群相互輸出，達到雙贏。我目前在地平線承擔了較多的開發工作，願意投入工作外的時間和精力，在開源社群一起討論和解決問題。對於第二個問題，因為我們社群的定位就是關注和解決工業界的痛點，所以能很好平衡開源和工程化。

劉川：我們觀察到 WeNet 逐漸成為語音行業最受歡迎的社群，您是否考慮開設課程分享語音領域的知識和經驗？

張彬彬：我們有過考慮。我們目前和語音之家一起做了一份實戰收費課程。最早我們社群的成員希望做免費課程，但商業化更可以保證產品的質量。未來我們可能會在公眾號，影片號，直接投放一些其他專案的課程。

劉川：英偉達自身在做一些開源專案。包括也支援了像 WeNet 的一些開源專案。未來英偉達在語音方面會有哪些開源的工作呢？

張彬彬：一方面我們有 Triton，NeMo 這些開源產品，我們的產品團隊會不斷收集工業界的反饋打磨這些產品。另一方面，我們鼓勵我們的工程師參與到開源社群裡。透過這種方式我們能將英偉達的加速技術最佳化這些開源專案。未來我們具體會關注訓練方面的最佳化，支援更多模型與解碼器，比如 Transducer，CTC 等。

劉川：人工智慧依賴算力支援，而對於個人開發者算力較為昂貴，英偉達未來有考慮為開源社群提供算力支援嗎？

張彬彬：在我們參與到開源專案的過程中，我們利用內部的 GPU 算力做了很多加速最佳化的工作，一定程度上緩解了 GPU 的缺乏。另一方面英偉達有 Inception 初創加速計劃，為願意貢獻開源社群的公司給與算力優惠。此外，對於高效學生我們會和公有云廠商做一些合作，提供算力支援。