返回文章列表
玄貓（BlackCat）

Azure Machine Learning 與 Kubeflow 深度學習系統整合

本文探討 Microsoft Azure Machine Learning 的核心功能，包含資料集管理、模型訓練、佈署與服務、後設資料儲存及工作流程協調，並與 Kubeflow 的各個元件進行比較，分析兩者在深度學習系統建置上的異同。文章同時比較了 Amazon SageMaker、Google Vertex AI

機器學習 雲端運算
Azure Machine Learning Kubeflow 深度學習 模型訓練 模型佈署 工作流程協調

Azure Machine Learning 提供完整的機器學習服務，涵蓋資料處理、模型訓練、佈署到線上推理等環節。其資料集管理功能以後設資料連結底層儲存，提供統一的 API 介面。模型訓練支援自定義容器，並提供預建環境簡化開發流程。模型佈署則支援多種方式，包含自定義容器和整合 Triton 推理伺服器，提升 GPU 使用效率。此外，Azure Machine Learning 也提供後設資料管理和工作流程協調功能，方便追蹤實驗和管理模型版本。Kubeflow 作為開源機器學習工具套件，則著重於提供根據 Kubernetes 的深度學習系統建置方案。Kubeflow 並未直接提供資料集管理功能，而是鼓勵整合其他開源方案。其模型訓練仰賴 Kubernetes 的資源排程能力，需要使用者自行建置訓練容器。模型佈署則透過 KServe 元件支援多種推理框架。Kubeflow 也提供後設資料管理、工作流程協調和實驗管理功能，方便使用者管理整個機器學習生命週期。

B.3 Microsoft Azure Machine Learning 深度解析

Microsoft Azure Machine Learning 是微軟推出的新一代機器學習工具和服務套件，不同於傳統的 ML Studio 圖形介面操作，它支援廣泛的客製化需求，結合程式碼與開源框架，提供更彈性的使用方式。本文將探討 Azure Machine Learning 的各項核心功能，並與本文所介紹的關鍵元件進行對比，幫助讀者瞭解哪些功能可以直接使用、哪些可以擴充套件，以及哪些需要從零開始建置，以滿足特定的業務需求。

B.3.1 資料集管理

在 Azure Machine Learning 中，資料集（Dataset）是作為輸入和輸出的第一類別物件，用於資料處理和訓練任務。資料集被定義為一組與原始資料相關聯的後設資料，並透過 URI 參照底層的資料儲存。一旦資料集被建立，它就變得不可變（Immutable），但底層資料的不可變性則需要使用者自行管理。

資料存取模式

定義好的資料集可以透過統一的客戶端 API 進行存取，資料既可以下載到本地使用，也可以掛載為網路儲存進行直接存取。讀者可在閱讀第 2 章後，瞭解 Azure Machine Learning 資料集管理的運作模式，並學習如何擴充套件現有功能以滿足特定需求。

B.3.2 模型訓練

Azure Machine Learning 提供預先構建的容器，內含 Python 發行版，並允許使用者自定義基礎映像（Base Image）以滿足特定需求。目前僅支援 Python 語言進行自定義訓練程式碼的開發。要啟動訓練任務，使用者需指定執行時容器和符合特定規範的訓練程式碼參照。

程式碼範例：自定義訓練環境

from azureml.core import Experiment, ScriptRunConfig

# 定義實驗
experiment = Experiment(workspace=ws, name='my-experiment')

# 組態訓練指令碼
src = ScriptRunConfig(source_directory='./src',
                      script='train.py',
                      compute_target='my-compute')

# 提交實驗
run = experiment.submit(src)

內容解密：

  1. Experiment 物件用於定義和管理實驗，workspace=ws 指定所屬的工作區。
  2. ScriptRunConfig 用於組態訓練指令碼，source_directory 指定程式碼目錄，script 指定主訓練指令碼。
  3. compute_target 指定執行訓練任務的計算資源。
  4. 提交實驗後，Azure Machine Learning 會自動執行訓練任務，並記錄執行日誌和結果。

閱讀第 3 章和第 4 章後，讀者將深入瞭解訓練服務的核心原理，並可根據範例建立自定義的訓練服務。

B.3.3 模型佈署與服務

Azure Machine Learning v2 版本支援建立端點（Endpoint）以處理線上推理請求。使用者可以組態端點載入特定模型並使用 Python 指令碼生成推理結果，或使用自定義容器映像（如 TensorFlow Serving）來提供推理服務。此外，Azure Machine Learning 還與 NVIDIA Triton Inference Server 整合，在使用 GPU 時可進一步提升推理效能。

模型佈署流程

此圖示展示了從模型註冊到上線推理的完整流程。

圖表解說：

  1. 首先需要將訓練好的模型註冊到 Azure Machine Learning。
  2. 建立一個端點，用於接收線上推理請求。
  3. 組態推理環境，包括選擇適當的計算資源和容器映像。
  4. 將模型佈署到端點上，並提供穩定的線上推理服務。

若需要將多個模型佈署至單一端點，或管理邊緣裝置上的模型推理，則需建立自定義的模型服務方案。第 6 章和第 7 章將探討模型服務的相關技術與實踐。

B.3.4 後設資料與工件儲存

Azure Machine Learning 允許在多個物件（如模型、訓練任務等）上附加後設資料（Metadata），以標籤（Tags）形式存在。模型註冊功能支援在註冊過程中同時上傳模型檔案和相關後設資料，簡化了操作流程。目前，預覽功能「Registry」可用於集中管理機器學習相關的後設資料。

使用場景：後設資料管理

若需要追蹤不同工件之間的關聯性，可能需要建立自定義解決方案。閱讀第 8 章後，讀者將全面瞭解後設資料與工件儲存的核心概念，並能夠快速搭建符合需求的系統。

B.3.5 工作流程協調

Azure Machine Learning 提供名為 ML Pipelines 的功能，使用者可以透過程式設計方式將資料處理、訓練等任務定義為步驟（Steps），並組合成可執行的 Pipeline。這些 Pipeline 可以按排程或觸發器定期執行，或手動啟動。計算資源、執行環境和存取許可權均可在定義 Pipeline 時進行組態。

程式碼範例：Pipeline 定義

from azureml.pipeline.steps import PythonScriptStep
from azureml.pipeline.core import Pipeline

# 定義步驟
step1 = PythonScriptStep(name='data_prep',
                         script_name='data_prep.py',
                         source_directory='./src')

step2 = PythonScriptStep(name='model_training',
                         script_name='train.py',
                         source_directory='./src')

# 建立 Pipeline
pipeline = Pipeline(workspace=ws, steps=[step1, step2])

內容解密：

  1. PythonScriptStep 用於定義執行 Python 指令碼的步驟，可指定指令碼名稱和來源目錄。
  2. 將多個步驟組合形成 Pipeline，並在工作區中註冊。
  3. 可組態 Pipeline 的執行排程和計算資源，以實作自動化的工作流程管理。

第 9 章將詳細介紹如何利用工作流程管理器來實作不同模式的訓練任務。讀者將深入理解工作流程管理器在深度學習系統中的設計原理及其在企業環境中的重要角色。

Kubeflow 與深度學習系統元件比較

Kubeflow 簡介

Kubeflow 是開放原始碼的工具套件，提供多種元件幫助建立深度學習系統，且不被特定雲端供應商繫結。本文將介紹 Kubeflow 的主要元件，並與書中提到的元件進行比較。

資料集管理

Kubeflow 並未提供內建的資料管理元件，因為其設計理念是不重複造輪子。開放原始碼的資料管理方案，如在第二章中討論的，可以被用來實作所需的資料管理功能。

模型訓練

由於 Kubeflow 根據 Kubernetes，其具備強大的資源排程能力。與雲端供應商提供的預建訓練容器不同，使用者需要自行建立訓練容器並管理其執行。在第三章和第四章中，我們將探討訓練服務的原理，以及如何根據需求建立自己的訓練服務。

模型佈署

截至目前，Kubeflow 提供 KServe 元件，用於將訓練好的模型佈署為可接受網路推論請求的服務。KServe 是建構於現有佈署框架（如 TensorFlow Serving、PyTorch TorchServe 和 NVIDIA Triton Inference Server）之上的介面。其主要優勢在於簡化了諸如自動擴充套件、健康檢查和自動還原等操作複雜性。由於 KServe 是開放原始碼的，因此可以在同一個端點上佈署單一或多個模型。在第六章和第七章中，我們將探討模型佈署的原理，以幫助讀者理解熱門佈署介面的設計理念，以及如何根據自身需求進行客製化。

中繼資料與成品儲存

從 Kubeflow 1.3 版本開始，中繼資料和成品（artifacts）成為 Kubeflow Pipelines 的核心部分。Kubeflow Pipelines 由一系列 pipeline 元件組成，各元件之間可以傳遞引數和成品。成品封裝了深度學習系統中的任何資料，例如模型本身、訓練指標和資料分佈指標等。中繼資料則是描述 pipeline 元件和成品的資料。透過這些結構，可以推斷出輸入訓練資料集、訓練好的模型、實驗結果和已佈署推論之間的關聯性。在第八章中，我們將討論建立中繼資料和成品儲存的關鍵考量。

工作流程協調

如同前一節所述，Kubeflow Pipelines 可以用來管理深度學習的資料準備和訓練工作流程。其內建了中繼資料和版本控制功能，並且可以利用 Kubernetes 的原生使用者和存取許可權來限制存取。在第九章中，我們將探討工作流程管理器如何支援不同模式的訓練。

實驗管理

Kubeflow Pipelines 提供了 Experiment 結構，用於將多個訓練執行組織成一個邏輯群組，並提供了額外的視覺化工具來比較不同實驗執行的結果。這非常適合離線實驗。若需要進行線上實驗，則需要自行開發解決方案。

現有解決方案比較

元件Amazon SageMakerGoogle Vertex AIMicrosoft Azure Machine LearningKubeflow
資料集管理使用 AWS 元件（如 S3、Glue Data Catalog 和 Glue ETL）建立資料集管理方案。需分別進行資料內容上傳和中繼資料標記。資料集為第一級物件，一旦建立便不可變。提供統一的客戶端 API 供訓練作業存取訓練資料集。-不提供內建的資料集管理方案，可使用其他開放原始碼方案。

詳細比較與分析

資料集管理
  • Amazon SageMaker：利用 AWS 的元件（如 S3、Glue Data Catalog 和 Glue ETL）來構建資料集管理方案，但資料內容的上傳和後設資料標籤是分開的操作。
  • Google Vertex AI：將資料集視為第一級物件，一旦建立便不可更改，並提供統一的客戶端 API 供訓練任務存取。
  • Microsoft Azure Machine Learning：未提供明確的資料集管理元件描述。
  • Kubeflow：不內建資料管理元件，鼓勵使用其他開源解決方案。

內容解密：

  1. Amazon SageMaker 的靈活性：雖然需要手動處理資料上傳和後設資料標記，但提供了高度的靈活性。
  2. Google Vertex AI 的嚴謹性：透過將資料集設為不可變物件，確保了資料的一致性和可靠性。
  3. Kubeflow 的開放性：允許使用者根據需求選擇合適的開源資料管理工具。

主流機器學習平台比較分析

在當今的機器學習領域，各大雲端服務供應商與開源社群提供了多種不同的解決方案。以下將針對Amazon SageMaker、Google Vertex AI、Microsoft Azure Machine Learning和Kubeflow進行全面比較，涵蓋模型訓練、模型佈署、後設資料管理、工作流程協調和實驗追蹤等五大導向。

模型訓練解決方案比較

各平台在模型訓練方面均提供不同的支援方案：

  • Amazon SageMaker支援內建演算法、外部自定義程式碼和自定義容器進行訓練，並提供預建訓練容器。
  • Google Vertex AI同樣支援自定義訓練容器，並提供API以支援在多節點上啟動訓練任務。
  • Microsoft Azure Machine Learning提供可自定義的預建訓練容器，但要求訓練容器遵循特定規範。
  • Kubeflow則直接利用Kubernetes的排程能力，但不提供預建訓練容器。

程式碼解析：Kubeflow 訓練工作流程

from kubeflow import dsl

@dsl.pipeline(
    name='mnist-train-pipeline',
    description='A pipeline for training MNIST model'
)
def mnist_train_pipeline(
    epochs: int = dsl.PipelineParam(name='epochs', default=10)
):
    # 定義訓練任務
    train_task = dsl.ContainerOp(
        name='train',
        image='gcr.io/my-project/mnist-train:latest',
        arguments=[
            '--epochs', epochs
        ]
    )

內容解密：

此段程式碼展示瞭如何使用Kubeflow定義一個簡單的MNIST模型訓練pipeline。其中：

  1. 使用@dsl.pipeline裝飾器定義pipeline名稱和描述。
  2. dsl.ContainerOp用於建立容器化訓練任務。
  3. arguments引數傳遞訓練所需的超引數（如epoch數）。
  4. 這種宣告式的工作流程定義方式簡化了複雜的機器學習工作流程管理。

模型佈署解決方案比較

在模型佈署方面，不同平台有各自的特點：

  • Amazon SageMaker允許多個模型佈署到同一個端點以提高利用率，但在GPU使用上有一定限制。
  • Google Vertex AI支援自定義推理容器，並主要使用多模型佈署來進行新版本模型的灰度發布。
  • Microsoft Azure Machine Learning支援透過自定義Python指令碼進行模型推理，並整合了NVIDIA Triton Inference Server。
  • Kubeflow透過KServe元件提供無伺服器推理抽象，支援多種流行的推理框架。

Plantuml模型佈署流程

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title Azure Machine Learning 與 Kubeflow 深度學習系統整合

package "機器學習流程" {
    package "資料處理" {
        component [資料收集] as collect
        component [資料清洗] as clean
        component [特徵工程] as feature
    }

    package "模型訓練" {
        component [模型選擇] as select
        component [超參數調優] as tune
        component [交叉驗證] as cv
    }

    package "評估部署" {
        component [模型評估] as eval
        component [模型部署] as deploy
        component [監控維護] as monitor
    }
}

collect --> clean : 原始資料
clean --> feature : 乾淨資料
feature --> select : 特徵向量
select --> tune : 基礎模型
tune --> cv : 最佳參數
cv --> eval : 訓練模型
eval --> deploy : 驗證模型
deploy --> monitor : 生產模型

note right of feature
  特徵工程包含：
  - 特徵選擇
  - 特徵轉換
  - 降維處理
end note

note right of eval
  評估指標：
  - 準確率/召回率
  - F1 Score
  - AUC-ROC
end note

@enduml

此圖示展示了模型從訓練完成到佈署上線並提供推理服務的完整流程。透過這種視覺化的方式，可以清晰地理解模型佈署的各個階段及其相互關係。

後設資料與工件管理比較

各平台在後設資料管理方面採用了不同策略：

  • Amazon SageMaker使用Model Registry作為集中式後設資料儲存方案。
  • Google Vertex AI的ML Metadata提供圖形化的後設資料儲存，能夠描述複雜關係。
  • Microsoft Azure Machine Learning透過不同物件的標籤來管理後設資料。
  • Kubeflow Pipelines將後設資料和工件作為Pipeline的一部分進行跟蹤。

工作流程協調能力比較

在工作流程協調方面：

  • Amazon SageMaker使用Model Building Pipelines。
  • Google Vertex AI同樣利用ML Metadata進行工作流程管理。
  • Microsoft Azure Machine Learning提供實驗跟蹤和管理功能。
  • Kubeflow則透過Kubeflow Pipelines實作工作流程的定義和執行。

實驗追蹤功能比較

各平台均提供實驗追蹤功能：

  • Amazon SageMaker的Experiments功能用於分組和跟蹤訓練執行。
  • Google Vertex AI提供Vertex AI Experiments進行實驗設定和結果視覺化。
  • Microsoft Azure Machine Learning允許定義和跟蹤實驗，並支援視覺化。
  • Kubeflow提供Experiment構件來對Pipeline執行進行邏輯分組。

使用Kubeflow Katib建立超引數最佳化服務

Katib是一個Kubernetes原生的超引數最佳化（HPO）服務，提供三種使用者介面：網頁介面、Python SDK和API。使用者可以透過網頁、Jupyter筆記本、Kubernetes命令和HTTP請求來執行HPO。

Katib運作原理

從使用者的角度來看，Katib是一個遠端系統。使用者向Katib提交實驗請求，Katib執行HPO實驗。使用者需要做兩件事：將訓練程式碼封裝成Docker映像，並將要最佳化的超引數暴露為外部變數；建立實驗物件，定義HPO實驗的規格，例如HPO演算法、試驗預算、超引數及其值搜尋空間。

Katib安裝與操作

步驟1：安裝Katib

如果已經安裝了Kubeflow系統，那麼Katib已經包含在內。如果只對HPO感興趣，可以單獨安裝Katib。由於Katib正在積極發展和維護，請檢視其官方安裝檔案以取得最新的安裝提示。

步驟2：瞭解Katib術語

對於Katib使用者來說，實驗（Experiment）、建議（Suggestion）和試驗（Trial）是三個最重要的概念。

  • 實驗：一個單一的最佳化執行，是端對端的HPO過程。實驗組態包含以下主要元件：訓練程式碼的Docker映像、目標指標（即目標值）、要調整的超引數及其值搜尋空間和HPO演算法。
  • 建議：HPO演算法提出的一組超引數值。Katib建立一個試驗作業來評估建議的值。
  • 試驗：實驗的一次迭代。試驗接受一個建議，執行訓練過程（試驗作業）以產生模型，並評估模型效能。

步驟3：將訓練程式碼封裝成Docker映像

與HPO函式庫方法相比，HPO服務方法需要將模型訓練程式碼封裝成Docker映像。這是因為HPO服務需要在遠端叢集中執行HPO訓練實驗，而Docker映像是遠端執行模型訓練程式碼的理想方法。

在準備Docker映像時，需要注意兩件事：將超引數定義為訓練程式碼的命令列引數，以及向Katib報告訓練指標。

首先，將需要最佳化的超引數定義為訓練程式碼中的命令列引數。因為Katib需要為不同的超引數值執行訓練程式碼作為Docker容器，所以訓練程式碼需要從命令列引數中取得超引數值。

def main():
    parser = argparse.ArgumentParser(description="PyTorch MNIST Example")
    parser.add_argument("--batch-size", type=int, default=64, metavar="N", help="input batch size for training (default: 64)")
    parser.add_argument("--lr", type=float, default=0.01, metavar="LR", help="learning rate (default: 0.01)")

內容解密：

  1. argparse 是一個用於解析命令列引數的 Python 模組。
  2. ArgumentParser 是 argparse 中的一個類別，用於建立解析器。
  3. add_argument 方法用於新增命令列引數。在這個例子中，我們定義了兩個超引數：batch-size 和 lr。
  4. type 引數指定了引數的型別，default 引數指定了預設值，metavar 引數指定了引數在幫助訊息中的顯示名稱，help 引數指定了引數的幫助訊息。

其次，讓訓練程式碼向Katib報告訓練指標，尤其是目標指標，以便Katib跟蹤每個試驗執行的進度和結果。Katib可以從以下三個地方收集指標：stdout（作業系統標準輸出位置）、任意檔案和TensorFlow事件。

最簡單的方法是將評估（目標）指標列印到stdout，並使用Katib的標準指標收集器收集。例如，如果我們將目標指標定義為Validation-accuracy，並希望HPO過程找到最佳的超引數以最小化這個值，我們可以將以下日誌寫入stdout。

2022-01-23T05:19:53Z INFO Epoch[5] Train-accuracy=0.932769
2022-01-23T05:19:53Z INFO Epoch[5] Time cost=31.698
2022-01-23T05:19:54Z INFO Epoch[5] Validation-accuracy=0.924463
2022-01-23T05:19:58Z INFO Epoch[6] Batch [0-100] Speed: 1749.16 ..

內容解密：

  1. Katib 的標準指標收集器會從 stdout 中解析出目標指標的值。
  2. 在這個例子中，Validation-accuracy=0.924463 是目標指標的值。
  3. Katib 使用預設的正則運算式格式來解析目標指標的值，該格式為 ([\w|-]+)\s*=\s*([+-]?\d*(\.\d+)?([Ee][+-]?\d+)?)。
  4. 使用者也可以在實驗組態檔案中定義自己的正則運算式格式。