Ray Tune 分散式超引數最佳化實踐

Ray Tune 建立於 Ray 之上，提供簡潔的 API 進行分散式應用程式開發，並支援大規模超引數最佳化。其相容於 PyTorch、XGBoost 等主流機器學習框架，並整合了 PBT、BayesOptSearch 等 HPO 演算法。Ray Tune 自動處理程式碼分發、分散式運算管理及容錯，簡化多節點 HPO 實驗的啟動流程。使用者只需定義目標函式、超引數搜尋空間，即可透過 tune.run 啟動 HPO 任務，並使用 ASHA 等排程器提升效率。相較於 Optuna 和 Hyperopt，Ray Tune 的分散式執行能力更為突出，無需手動設定分散式環境。然而，在分享 HPO 系統中，Ray Tune 仍面臨計算隔離的挑戰，可能導致套件版本衝突及資源分配問題。

5.4 開源超引數最佳化函式庫

當Optuna面對大型資料科學團隊或多個超引數最佳化（HPO）專案時，由於需要手動管理分散式運算，Optuna的限制便顯現出來。為了以自動化和程式化的方式管理分散式運算任務，我們可以使用Kubeflow Katib或Ray Tune。

5.4.3 Ray Tune

Ray（https://docs.ray.io/en/latest/index.html）提供了一個簡單、通用的API，用於構建分散式應用程式。Ray Tune（https://docs.ray.io/en/latest/tune/index.html）是一個根據Ray構建的Python函式庫，用於支援任意規模的超引數最佳化。

Ray Tune函式庫支援幾乎所有機器學習框架，包括PyTorch、XGBoost、MXNet和Keras。它還支援最先進的HPO演算法，如Population Based Training（PBT）、BayesOptSearch和HyperBand/ASHA。此外，Tune提供了一種機制，可以整合來自其他HPO函式庫的HPO演算法，例如Hyperopt整合。

透過使用Ray作為其分散式執行支援，我們可以透過幾行程式碼啟動多節點HPO實驗。Ray將負責程式碼分發、分散式運算管理和容錯。

如何使用

使用Ray Tune執行HPO任務非常簡單。首先，定義一個目標函式。在函式中，從config變數讀取超引數值，開始模型訓練，並傳回評估分數。其次，定義超引數及其值搜尋空間。第三，透過將目標函式和搜尋空間連結在一起來啟動HPO執行。清單5.3實作了上述三個步驟。

# 步驟1：定義目標函式
def objective_function(config):
    model = ConvNet()
    model.to(device)
    optimizer = optim.SGD(
        model.parameters(), lr=config["lr"],
        momentum=config["momentum"])
    for i in range(10):
        train(model, optimizer, train_loader)
    acc = test(model, test_loader)
    tune.report(mean_accuracy=acc)

# 步驟2：定義每個超引數的搜尋空間
search_space = {
    "lr": tune.sample_from(lambda spec:
        10**(-10 * np.random.rand())),
    "momentum": tune.uniform(0.1, 0.9)
}

# 取消註解以啟用分散式執行
# `ray.init(address="auto")`

# 步驟3：啟動HPO執行
analysis = tune.run(
    objective_function,
    num_samples=20,
    scheduler=ASHAScheduler(metric="mean_accuracy", mode="max"),
    config=search_space)

# 檢查HPO進度和結果
# 從所有執行試驗中取得試驗DataFrame
dfs = analysis.trial_dataframes

內容解密：

1. 目標函式定義：objective_function是HPO的核心，它接收一個包含超引數的config字典，使用這些超引數訓練模型，並傳回模型的準確率。
2. 超引數搜尋空間定義：search_space字典定義了超引數的搜尋範圍，例如學習率lr和動量momentum。
3. 啟動HPO執行：tune.run函式將目標函式和搜尋空間結合，開始HPO過程。它使用ASHAScheduler來提前終止不具前景的試驗，從而提高搜尋效率。
4. 結果分析：透過analysis.trial_dataframes可以取得所有試驗的結果，便於進一步分析和最佳化。

平行化

Ray Tune相比Optuna的最大優勢在於其分散式執行能力。Ray Tune允許在多個GPU和多個節點上透明地平行化HPO任務，甚至具有無縫的容錯和雲端支援。不像Optuna和Hyperopt，我們不需要手動設定分散式環境並逐一執行工作指令碼。Ray Tune自動處理這些步驟。圖5.12展示了Ray Tune如何在機器叢集上分佈HPO Python程式碼。

何時使用

與其他HPO函式庫相比，Ray Tune是否是在HPO領域的最佳選擇？暫時來說，是的。截至目前，Ray提供了底層訓練框架（如TensorFlow和PyTorch）與最先進的HPO演算法（如貝葉斯搜尋和TPE）之間的整合，以及提前停止（ASHA）。它允許我們以直接和可靠的方式分散式執行HPO搜尋。

對於大多數不願意擁有自己的HPO服務的資料科學團隊來說，Ray Tune是建議的方法。它使用簡單，滿足了幾乎所有模型訓練專案的HPO需求：優秀的檔案、最先進的HPO演算法，以及高效和簡單的分散式執行管理。

Ray Tune的限制

當我們需要在一個分享的HPO系統中支援不同的團隊和不同的深度學習專案時，Ray Tune和其他HPO函式庫都會達到其極限。Ray Tune缺乏計算隔離，這導致了兩個大問題。

首先，不同訓練程式碼的套件版本可能導致Ray工作節點之間的衝突。在Ray Tune中執行分散式HPO時，我們將HPO程式碼提交到Ray叢集的主伺服器，然後在叢集工作節點中平行執行此程式碼。這意味著每個Ray工作節點伺服器都需要為其需要執行的每個訓練程式碼安裝依賴函式庫。想像一下，當你需要在一個Ray叢集中執行10個不同的HPO任務時，工作機器需要為這10個不同的訓練程式碼安裝數百個套件並解決其版本衝突。其次，Ray Tune不強制使用者隔離。在Ray Tune中，很難為不同的資料科學團隊建立虛擬邊界以限制其計算資源使用。

圖示說明：

此圖示展示了Ray Tune如何在一個機器叢集上分佈HPO Python程式碼，實作分散式超引數最佳化。

內容解密：

• 此圖示展示了Ray Tune的分散式執行架構，其中tune.py是主控指令碼，負責將HPO任務分發到多個工作節點（HPO Process）。
• 每個工作節點獨立執行HPO任務，並將結果傳回給主控節點。
• 這種架構使得Ray Tune能夠有效地利用多個計算資源，大大加快了HPO的速度。

模型服務設計

模型服務是使用使用者輸入資料執行模型的過程。在深度學習系統的所有活動中，模型服務與最終客戶最為接近。經過資料集準備、訓練演算法開發、超引數調優和測試後，模型透過模型服務呈現給客戶。

以語音翻譯為例，訓練好一個序列到序列的語音翻譯模型後，團隊準備將其呈現給世界各地的使用者。為了讓人們能夠遠端使用這個模型，通常將其託管在網頁服務中，並透過網頁API暴露出來。然後，使用者可以透過網頁API傳送語音音訊檔案，並接收翻譯後的語音音訊檔案。所有模型載入和執行的過程都在網頁服務後端進行。這個使用者工作流程中涉及的所有內容，包括服務、模型檔案和模型執行，都被稱為模型服務。

本章涵蓋以下內容：

• 定義模型服務
• 常見的模型服務挑戰和方法
• 為不同使用者場景設計模型服務系統

6.1 解釋模型服務

在模型服務的工程領域中，術語是一個大問題。例如，模型、模型架構、推理圖、預測和推理都是人們在未明確定義的情況下使用的術語，因此它們可能具有相同的含義，也可能根據上下文（模型服務或模型訓練）指代不同的概念。在模型服務的背景下，這些術語的使用可能會造成混淆。

常見的模型服務挑戰

在生產環境中提供模型服務可能會面臨多種挑戰，因為模型是由不同的框架和演算法訓練出來的，因此執行模型的方法和函式庫各不相同。此外，模型服務領域使用的術語令人混淆，有太多聽起來不同但在服務上下文中含義相同的術語，如模型預測和模型推理。

面對眾多的模型服務選項，很難選擇一個適合自己的。我們有一方面有像TensorFlow Serving、TorchServe和NVIDIA Triton Inference Server這樣的黑盒解決方案，另一方面也有像建立自己的預測服務或直接將模型嵌入到應用程式中的自定義方法。這些方法看起來都很相似且功能強大，因此很難選擇其中之一。

設計模型服務系統

我們的目標是幫助您找到適合自己的模型服務解決方案。我們希望賦予您設計和建立最適合您情況的模型服務解決方案的能力。為了實作這一目標，我們將涵蓋從對模型服務的概念理解和服務設計考慮到具體範例和模型佈署工作流程的大量內容。

設計原則

設計模型服務系統時，需要考慮多個原則，包括但不限於：

1. 訓練程式碼無關性：模型服務應該與訓練模型的程式碼無關，這樣可以提高模型的通用性和可移植性。
2. 高擴充套件性：系統應該能夠根據需求進行擴充套件，以支援大量的使用者請求。
3. 高用性：系統應該設計為高用性，以確保使用者可以隨時存取模型服務。
4. 資源管理：系統應該能夠有效地管理計算資源，以支援模型的執行。
5. 可移植性：系統應該設計為可移植的，以便於在不同的環境中佈署。

常見的模型服務策略

1. 黑盒解決方案：使用像TensorFlow Serving、TorchServe等預先構建的解決方案，可以快速佈署模型。
2. 自定義預測服務：建立自己的預測服務，可以根據特定的需求進行定製。
3. 嵌入式模型：直接將模型嵌入到應用程式中，可以提高效能和效率。

每種策略都有其優缺點，需要根據具體的使用場景進行選擇。

模型服務設計的核心概念解析

在與資料科學家合作建立模型服務解決方案的過程中，模型服務相關術語的混淆常常導致溝通上的誤解。本文將闡述模型服務的核心概念，並從工程角度解釋常用的術語，避免陷入術語陷阱。

6.1.1 什麼是機器學習模型？

學術界對機器學習模型有多種定義，從資料集的精煉表示到用於識別特定模式或根據之前未見的資訊做出決策的數學表示。然而，作為模型服務開發人員，我們可以簡單地將模型理解為訓練過程中產生的檔案集合。

模型的理念很簡單，但很多人誤解模型只是靜態檔案。儘管模型以檔案形式儲存，但它們並非靜態；它們本質上是可執行的程式。

讓我們探討這一陳述並確定其含義。模型由機器學習演算法、模型資料和模型執行器組成。模型執行器是機器學習演算法的包裝程式碼；它接收使用者輸入並執行演算法以計算和傳回預測結果。機器學習演算法是指在模型訓練中使用的演算法，有時也稱為模型架構。以語音翻譯為例，如果翻譯模型是透過序列到序列網路作為其訓練演算法進行訓練的，那麼模型中的機器學習演算法就是相同的序列到序列網路。模型資料是執行機器學習演算法所需的資料，例如神經網路的學習引數（權重和偏差）、嵌入和標籤類別。圖6.1展示了一個通用的模型結構。

圖6.1 模型的組成

內容解密：

• 模型由三個主要部分組成：機器學習演算法、模型資料和模型執行器。
• 機器學習演算法是指用於訓練模型的演算法，例如序列到序列網路。
• 模型資料包括權重、偏差、文字、字典和類別等，用於執行機器學習演算法。
• 模型執行器是包裝機器學習演算法的程式碼，負責接收輸入並傳回預測結果。

6.1.2 模型預測與推斷

從學術角度來看，模型推斷和預測被視為兩個不同的概念。模型推斷可能指的是瞭解資料是如何生成的並理解其因果關係，而模型預測可能指的是預測未來的事件。

然而，從工程角度來看，模型預測和模型推斷意味著相同的事物。在模型服務的背景下，兩者都指使用給定的資料點執行模型以獲得一組輸出值。圖6.2展示了預測模型和推斷模型的模型服務工作流程；正如你所看到的，它們之間沒有區別。

圖6.2 模型預測與推斷

內容解密：

• 在模型服務中，模型預測和推斷是相同的，指使用給定資料執行模型以獲得輸出值。
• 圖6.2展示了預測和推斷的工作流程，兩者在本質上是相同的。

6.1.3 什麼是模型服務？

模型服務簡單來說就是使用輸入資料執行模型以進行預測，這包括擷取所需的模型、設定模型的執行環境、執行模型以使用給定的資料點進行預測，並傳回預測結果。最常用的模型服務方法是將模型託管在網頁服務中，並透過網頁API公開模型的預測功能。

假設我們建立了一個物件偵測模型來偵測海邊圖片中的鯊魚；我們可以建立一個網頁服務來託管這個模型，並公開一個鯊魚偵測網頁API。這個網頁API可以被世界各地的海灘飯店用來偵測他們自己的海岸圖片中的鯊魚。通常，我們稱這個模型服務網頁服務為預測服務。

典型的預測服務中的模型預測工作流程有四個步驟：接收使用者請求；從成品儲存函式庫載入模型到記憶體或GPU；執行模型的演算法；最後，傳回預測結果。圖6.3展示了這個工作流程。

圖6.3 典型的預測服務工作流程

內容解密：

• 預測服務的工作流程包括接收請求、載入模型、執行模型和傳回結果四個步驟。
• 預測服務依賴於模型成品儲存函式庫來取得所需的模型。
• 網頁API用於接收預測請求並傳回結果。

模型服務設計挑戰與關鍵概念

在前面的章節中，我們討論了模型訓練和超引數調優服務。現在，我們將重點放在模型服務（model serving）上，這是將訓練好的模型佈署到生產環境中並提供預測服務的過程。

模型服務的挑戰

將模型佈署為Web服務並提供成本效益高的預測服務，比在本地執行模型要複雜得多。以下是模型服務中常見的六大挑戰：

1. 模型預測API的多樣性：不同的深度學習演算法需要不同的輸入資料格式和輸出格式。設計一個統一的Web API來滿足所有模型演算法的需求是一個挑戰。
2. 模型執行環境的多樣性：模型可以在不同的框架（如TensorFlow和PyTorch）中訓練，每個框架都有其特殊的設定和組態。預測服務需要在後端封裝模型執行環境的設定，以便客戶可以專注於使用模型預測API。
3. 選擇合適的模型服務工具：有多達20多種不同的模型服務工具、函式庫和系統可供選擇，如TorchServe、TensorFlow Serving、NVIDIA Triton Inference Server、Seldon Core和KFServing。選擇最適合自己情況的工具是一個挑戰。
4. 沒有通用、成本效益最高的模型服務設計：與模型訓練和超引數調優服務不同，預測服務設計嚴重依賴於具體的使用者場景。例如，設計一個支援單一模型的預測服務與設計一個支援多種型別模型的預測服務是非常不同的。
5. 降低模型預測延遲同時保持資源飽和：從成本效益的角度來看，希望計算資源能夠被模型預測工作負載充分利用。同時，也希望為客戶提供實時的模型預測體驗，因此需要創新地降低預測工作流程中的每個步驟的時間成本。
6. 模型佈署和佈署後監控：模型佈署是成功開發模型的關鍵，需要快速將模型推進到生產環境，並支援多個版本的模型，以便快速評估不同的訓練演算法並選擇最佳模型。佈署後模型監控可以幫助檢測模型效能迴歸。

模型服務的關鍵概念

在討論模型服務時，需要了解一些關鍵概念：

• 模型服務（Model Serving）、模型評分（Model Scoring）、模型推斷（Model Inference） 和 模型預測（Model Prediction） 是可互換的術語，指使用給定的資料點執行模型。
• 預測服務（Prediction Service）、評分服務（Scoring Service）、推斷服務（Inference Service） 和 模型服務（Model Serving Service） 是可互換的，指允許遠端執行模型的Web服務。
• 預測（Predict） 和 推斷（Inference） 在模型服務上下文中是可互換的，指執行模型演算法的入口函式。
• 預測請求（Prediction Request）、評分請求（Scoring Request） 和 推斷請求（Inference Request） 是可互換的，指執行模型以進行預測的Web API請求。

內容解密：

本文主要介紹了模型服務的概念、挑戰和關鍵術語。瞭解這些內容對於設計和實作有效的模型服務至關重要。接下來，我們將討論如何應對這些挑戰並設計出高效的模型服務。

設計高效的模型服務

為了應對上述挑戰，需要設計出高效的模型服務。這包括：

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title Ray Tune 分散式超引數最佳化實踐

package "系統架構" {
    package "前端層" {
        component [使用者介面] as ui
        component [API 客戶端] as client
    }

    package "後端層" {
        component [API 服務] as api
        component [業務邏輯] as logic
        component [資料存取] as dao
    }

    package "資料層" {
        database [主資料庫] as db
        database [快取] as cache
    }
}

ui --> client : 使用者操作
client --> api : HTTP 請求
api --> logic : 處理邏輯
logic --> dao : 資料操作
dao --> db : 持久化
dao --> cache : 快取

note right of api
  RESTful API
  或 GraphQL
end note

@enduml

此圖示展示了設計高效模型服務的關鍵步驟。

內容解密：

1. 統一API設計：設計一個統一的API來滿足不同模型的輸入輸出需求。
2. 封裝模型執行環境：在後端封裝不同框架模型的執行環境。
3. 選擇合適的工具：根據具體需求選擇最合適的模型服務工具。
4. 定製化設計：根據具體使用者場景進行定製化設計。
5. 最佳化預測延遲：透過創新方法降低預測工作流程中的時間成本。
6. 佈署和監控：快速佈署模型並進行佈署後監控，以檢測效能迴歸。

透過遵循這些步驟，可以設計出高效且成本效益高的模型服務，從而更好地支援業務需求。