在 Hugging Face 上部署語音轉語音模型

?????這些都是很棒的功能，但我該如何運行 S2S 呢？
??: 很好的問題！
運行語音轉語音項目需要大量的計算資源。即使在高端筆記本電腦上，你也可能會遇到延遲問題，特別是在使用最先進的模型時。雖然強大的 GPU 可以緩解這些問題，但并不是每個人都有條件 (或意愿) 去搭建他們的硬件設備。

這正是 Hugging Face 的推理端點 (IE) 發揮作用的地方。推理端點允許您租用帶有 GPU (或其他可能需要的硬件) 的虛擬機，并僅需按系統運行時間付費，為部署如語音轉語音這類大型應用提供了理想的解決方案。

在本文中，我們將逐步指導您將 Speech-to-Speech 部署到 Hugging Face 推理端點上。以下是主要內容:

理解推理端點，并快速了解設置 IE 的不同方式，包括自定義容器鏡像 (這正是我們需要用于 S2S 的)
構建適用于 S2S 的自定義 Docker 鏡像
將自定義鏡像部署到 IE 并盡情體驗 S2S！
推理斷點
推理端點提供了一種可擴展且高效的方式部署機器學習模型。這些端點允許您在最少設置的情況下利用各種強大的硬件用模型提供服務。推理端點非常適合需要高性能和高可靠性的應用程序部署，而無需管理底層基礎設施。

以下是幾個關鍵功能，請查閱文檔獲取更多信息:

簡潔性 - 由于 IE 直接支持 Hugging Face 庫中的模型，您可以在幾分鐘內快速上手。
可擴展性 - 您無需擔心規模問題，因為 IE 可以自動擴展 (包括縮小規模到零)，以應對不同的負載并節省成本。
自定義 - 您可以根據需要自定義 IE 的設置來處理新任務。更多詳情請參見下方內容。
推理端點支持所有 Transformers 和 Sentence-Transformers 任務，也可以支持自定義任務。這些是 IE 設置選項:

預構建模型: 直接從 Hugging Face 樞紐快速部署模型。
自定義處理器: 為更復雜的流程任務自定義推理邏輯。
自定義 Docker 映像: 使用您自己的 Docker 映像封裝所有依賴項和自定義代碼。
對于簡單的模型，選項 1 和 2 是理想的選擇，并且可以使用推理端點部署變得極其簡單。然而，對于像 S2S 這樣的復雜流程任務來說，您將需要選項 3 提供的靈活性: 通過自定義 Docker 鏡像部署我們的 IE。

這種方法不僅提供了更多的靈活性，還通過優化構建過程并收集必要的數據提高了性能。如果您正在處理復雜的模型流程任務或希望優化應用程序的部署，請參考本指南以獲得有價值的見解。

在推理端點上部署語音轉語音模型
讓我們開始吧！

構建自定義 Docker 鏡像
為了開始創建一個自定義的 Docker 鏡像，我們首先克隆了 Hugging Face 的標準 Docker 鏡像倉庫。這為在推理任務中部署機器學習模型提供了一個很好的起點。

git clone https://github.com/huggingface/huggingface-inference-toolkit
為什么克隆默認鏡像倉庫？
堅實的基礎: 倉庫提供了專門為推理工作負載優化的基礎鏡像，這為可靠地開始推理任務提供了一個牢固的基礎。
兼容性: 由于該鏡像是按照與 Hugging Face 部署環境對齊的方式構建的，因此在部署您自己的自定義鏡像時可以確保無縫集成。
易于定制化: 倉庫提供了干凈且結構化的環境，使得為應用程序的具體要求定制鏡像變得容易。
您可以查看所有更改內容在這里

為語音識別應用自定義 Docker 鏡像
克隆了倉庫后，下一步是根據我們的語音識別流程需求來調整鏡像。

添加語音到語音項目
為了無縫集成該項目，我們添加了語音轉語音識別的代碼庫以及所需的任何數據集作為子模塊。這種方法提供了更好的版本控制能力，在構建 Docker 鏡像時可以確保始終使用正確的代碼和數據版本。

通過將數據直接包含在 Docker 容器中，我們避免了每次實例化端點時都需要下載數據，這顯著減少了啟動時間并確保系統可重復。這些數據被存儲在一個 Hugging Face 倉庫中，提供了易于跟蹤和版本控制的功能。

git submodule add https://github.com/huggingface/speech-to-speech.git
git submodule add https://huggingface.co/andito/fast-unidic
優化 Docker 鏡像
接下來，我們修改了 Dockerfile 文件來滿足我們的需求:

精簡鏡像: 移除了與用例無關的軟件包和依賴項。這減少了鏡像大小，并在推理過程中降低了不必要的消耗。
安裝依賴項: 我們將requirements.txt 的安裝從入口點移動到了 Dockerfile 本身。這樣，當構建 Docker 鏡像時會安裝這些依賴項，從而加快部署速度，因為運行時將不需要再次安裝這些包。
部署自定義鏡像
完成修改后，我們構建并推送了自定義鏡像到 Docker Hub:

DOCKER_DEFAULT_PLATFORM=“linux/amd64” docker build -t speech-to-speech -f dockerfiles/pytorch/Dockerfile .
docker tag speech-to-speech andito/speech-to-speech:latest
docker push andito/speech-to-speech:latest
Docker 鏡像構建并推送后，就可以在 Hugging Face 推理端點中使用了。通過使用這個預構建的鏡像，端點可以更快地啟動并且運行得更高效，因為所有依賴項和數據都已預先打包在鏡像中。

設置推理端點
使用自定義 Docker 鏡像只需稍微不同的配置，您可以點擊并查看文檔。我們將通過圖形界面和 API 調用兩種方式來介紹如何做到這一點。

前置步驟

登錄: https://huggingface.co/login
請求訪問 meta-llama/Meta-Llama-3.1-8B-Instruct
創建細粒度令牌: https://huggingface.co/settings/tokens/new?tokenType=fineGrained
Fine-Grained Token

選擇訪問受限制的倉庫權限
如果您正在使用 API，請確保選擇管理推理端點的權限
推斷端點 GUI
訪問 https://ui.endpoints.huggingface.co/new
填寫相關信息:
模型倉庫 - andito/s2s
模型名稱 - 如果不喜歡生成的名稱，可以自由重命名
例如: speech-to-speech-demo
保持小寫字母且簡短
選擇您偏好的云和硬件配置 - 我們使用了 AWS GPU L4
只需每小時 $0.80，足夠用來處理模型
高級配置 (點擊展開箭頭 ?)
容器類型 - Custom
容器端口 - 80
容器 URL - andito/speech-to-speech:latest
密鑰 – HF_TOKEN |<您的令牌在這里>
點擊展示圖片步驟
點擊創建終端節點
[!NOTE] 實際上模型倉庫并不重要，因為模型會在容器創建時指定和下載。但是推理終端節點需要一個模型，所以你可以選擇你喜歡的一個較輕量級的。

[!NOTE] 你需要指定 HF_TOKEN 因為我們需要在容器創建階段下載受限制訪問的模型。如果你使用的是未受限或私有的模型，則不需要這樣做。

[!WARNING] 當前 huggingface-inference-toolkit 入口點默認使用的是端口 5000，但推理終端節點期望的端口號是 80。你應該在容器端口中匹配這一點。我們已經在 Dockerfile 中設置了這個值，但如果從零開始構建，請務必注意！

推理端點 API
在這里，我們將逐步介紹創建帶有 API 的端點步驟。只需在您選擇的 Python 環境中使用以下代碼。

確保使用版本 0.25.1 或更高版本

pip install huggingface_hub>=0.25.1
使用一個可以寫入端點 (Write 或細粒度權限) 的 Hugging Face 令牌

from huggingface_hub import login
login()
from huggingface_hub import create_inference_endpoint, get_token
endpoint = create_inference_endpoint(
# Model Configuration
“speech-to-speech-demo”,
repository=“andito/s2s”,
framework=“custom”,
task=“custom”,
# Security
type=“protected”,
# Hardware
vendor=“aws”,
accelerator=“gpu”,
region=“us-east-1”,
instance_size=“x1”,
instance_type=“nvidia-l4”,
# Image Configuration
custom_image={
“health_route”: “/health”,
“url”: “andito/speech-to-speech:latest”, # Pulls from DockerHub
“port”: 80
},
secrets={‘HF_TOKEN’: get_token()}
)

Optional

endpoint.wait()
預覽
Overview

主要組件

語音轉語音
這是一個 Hugging Face 庫，我們在 inference-endpoint 分支中加入了一些特定于推理端點的文件，該分支很快將合并到主分支。
andito/s2s 或其他任何倉庫。這對我們來說不是必需的，因為我們已經在容器創建階段包含了模型，但推理端點需要一個模型，所以我們傳遞了一個瘦身后的倉庫。
andimarafioti/語音轉語音工具包
這是 huggingface/huggingface-inference-toolkit 的分支，幫助我們構建符合我們需求的自定義容器。
構建 web 服務器
為了使用端點，我們需要構建一個小的 WebService 服務。這部分代碼位于 speech_to_speech 庫中的 s2s_handler.py 以及我們用于客戶端的 speech_to_speech_inference_toolkit 工具包中的 webservice_starlette.py ，后者被用來構建 Docker 鏡像。通常情況下，你只需要為端點編寫一個自定義處理程序即可，但由于我們希望實現極低的延遲，因此還特別構建了支持 WebSocket 連接的 WebService 而不是普通的請求方式。乍一聽起來可能有些令人望而生畏，但這個 WebService 服務代碼只有 32 行！

Webservice code

這段代碼將在啟動時運行 prepare_handler ，這將初始化所有模型并預熱它們。然后，每個消息將會由 inference_handler.process_streaming_data 處理。

Process streaming code

這種方法簡單地從客戶端接收音頻數據，將其分割成小塊供 VAD 處理，并提交到隊列進行處理。然后檢查輸出處理隊列 (模型的語音響應！)，如果有內容則返回。所有的內部處理均由 Hugging Face 的 speech_to_speech 庫負責。

自定義處理程序和客戶端
WebService 接收并返回音頻，但仍然缺少一個重要的部分: 我們如何錄制和回放音頻？為此，我們創建了一個客戶端，用于連接到服務。最簡單的方法是將分析分為與 WebService 的連接以及錄音/播放音頻兩部分。

Audio client code

初始化 WebService 客戶端需要為所有消息設置一個包含我們 Hugging Face Token 的頭部。在初始化客戶端時，我們需要設定對常見消息的操作 (打開、關閉、錯誤、信息)。這將決定當服務器向我們的客戶端發送消息時，客戶端會執行什么操作。

Audio client messages code

我們可以看到，對接收到的消息的反應非常直接，只有 on_message 方法較為復雜。該方法能夠理解服務器完成響應后開始“監聽”用戶的回復。否則，它會將從服務器接收到的數據放入播放隊列中。

Client’s audio record and playback

客戶的音頻部分有 4 個任務:

錄制音頻
提交音頻錄制文件
接收服務器的音頻響應
播放音頻響應
錄音是在 audio_input_callback 方法中完成的，它只是將所有片段提交到一個隊列。然后使用 send_audio 方法將其發送給服務器。在此過程中，如果沒有要發送的音頻，則仍然提交空數組以從服務器接收響應。我們之前在博客中看到的 on_message 方法處理來自服務器的響應。隨后，音頻響應的播放由 audio_output_callback 方法處理。在這里，我們需要確保音頻處于我們預期的范圍內 (不希望因為錯誤的數據包而損上某人的耳膜！)，并確保輸出數組的大小符合播放庫的要求。

結論
在本文中，我們介紹了如何使用自定義 Docker 鏡像，在 Hugging Face 推斷端點上部署語音到語音 (S2S) 流程的步驟。我們構建了一個定制容器來處理 S2S 流程的復雜性，并展示了如何對其進行配置以實現可擴展且高效的部署。Hugging Face 推斷端點使得將如語音到語音這類性能密集型應用程序變為現實變得更加容易，無需擔心硬件或基礎設施管理的問題。

標簽

語音模型

贊

回復

舉報

回復

51CTO

51CTO博客

51CTO學堂

在 Hugging Face 上部署語音轉語音模型

Optional

目錄