分享方式：

Azure Databricks 上深度學習的最佳做法

  • 文章

本文包含 Azure Databricks 上的深度學習秘訣，以及專為優化深度學習工作負載而設計的內建工具和媒體櫃的相關資訊，例如下列：

Databricks Mosaic AI 透過用於機器學習的 Databricks Runtime 提供預先建置的深度學習基礎結構，其中包括最常見的深度學習媒體櫃，例如 TensorFlow、PyTorch 和 Keras。 它也具有內建、預先設定的 GPU 支援，包括驅動程式和支援媒體櫃。

Databricks Runtime ML 也包含 Azure Databricks 工作區的所有功能，例如叢集建立和管理、媒體櫃和環境管理、使用 Databricks Git 資料夾進行程式代碼管理、自動化支援，包括 Databricks 工作和 API，以及用於模型開發追蹤和模型部署與服務的整合 MLflow。

資源和環境管理

Azure Databricks 可協助您自訂深度學習環境，並讓整個使用者的環境保持一致。

自訂開發環境

使用 Databricks Runtime，您可以在筆記本、叢集和工作層級自訂開發環境。

使用叢集原則

您可以建立叢集原則來引導資料科學家選擇正確的選擇，例如使用單一節點叢集進行開發，以及針對大型工作使用自動調整叢集。

請考慮將 A100 GPU 用於深度學習工作負載

A100 GPU 是許多深度學習工作的有效選擇，例如訓練和調整大型語言模型、自然語言處理、物件偵測和分類，以及建議引擎。

  • Databricks 支援所有雲端上的 A100 GPU。 如需支援之 GPU 類型的完整清單，請參閱支援的執行個體類型。
  • A100 GPU 通常可用性有限。 請連絡您的雲端提供者取得資源分派，或考慮事先保留容量。

GPU 排程

若要將 GPU 最大化，以便進行分散式深度學習訓練和推斷，請將 GPU 排程優化。 請參閱 GPU 排程。

載入資料的最佳做法

雲端資料儲存體通常不會針對 I/O 進行最佳化，這對於需要大型資料集的深度學習模型而言可能是一項挑戰。 Databricks Runtime ML 包含 Delta Lake 和 Mosaic Streaming，以最佳化深度學習應用程式的資料輸送量。

Databricks 建議使用 Delta Lake 資料表來儲存資料。 Delta Lake 簡化了 ETL，並可讓您高效地存取資料。 特別是針對影像，Delta Lake 有助於最佳化訓練和推斷的擷取。 影像應用程式的參考解決方案提供使用 Delta Lake 最佳化影像 ETL 的範例。

Databricks 建議在 PyTorch 或 Mosaic Composer 上載入資料，特別是涉及分散式工作負載時。 提供的 StreamingDataset 和 StreamingDataLoader API 可協助簡化大型資料集的訓練，同時最大化分散式環境中的正確性保證、效能、彈性和易於使用。 如需詳細資訊，請參閱使用 Mosaic Streaming 載入資料。

訓練深度學習模型的最佳做法

Databricks 建議針對所有模型訓練使用 Databricks Runtime 進行機器學習、MLflow 追蹤和自動記錄。

從單一節點叢集開始

單一節點 (僅限驅動程式) GPU 叢集通常是最快速且最符合成本效益的深度學習模型開發。 一個具有 4 個 GPU 的節點可能會更快進行深度學習訓練，其中 4 個背景工作角色節點各有 1 個 GPU。 這是因為分散式訓練會產生網路通訊額外負荷。

單一節點叢集是快速、反覆開發和中小型資料訓練模型的絕佳選項。 如果資料集夠大，會讓單一電腦上的訓練變慢，請考慮移至多 GPU，甚至分散式運算。

使用 TensorBoard 和叢集計量來監視訓練程式

TensorBoard 已預先安裝於 Databricks Runtime ML 中。 您可以在筆記本或個別索引標籤內使用。如需詳細資訊，請參閱 TensorBoard。

叢集計量適用於所有 Databricks Runtime。 可以檢查網路、處理器和記憶體使用量，以檢查瓶頸。 如需詳細資訊，請參閱叢集計量。

將深度學習的效能最佳化

您可以且應該在 Databricks 上使用深度學習效能最佳化技術。

早期停止

早期停止會監視在驗證集上計算的計量值，並在計量停止改善時停止訓練。 這是比猜測要完成的大量 Epoch 更好的方法。 每個深度學習媒體櫃都會提供原生 API 以供早期停止;例如，請參閱 TensorFlow/Keras 和 PyTorch Lightning 的 EarlyStopping 回撥 API。 如需範例筆記本，請參閱 TensorFlow Keras 範例筆記本。

批次大小調整

批次大小調整有助於最佳化 GPU 使用率。 如果批次大小太小，計算就無法完全使用 GPU 功能。 您可以使用叢集計量來檢視 GPU 計量。

配合學習速率調整批次大小。 不錯的經驗法則是，將批次大小增加 n 時，依 sqrt(n) 增加學習速率。 手動調整時，請嘗試將批次大小變更為 2 或 0.5。 然後，繼續微調以手動方式最佳化效能，或使用 Optuna 之類的自動化工具測試各種超參數。

傳輸學習

透過傳輸學習，您可以從先前訓練的模型開始，並視需要修改應用程式。 傳輸學習可大幅縮短訓練和調整新模型所需的時間。 如需詳細資訊和範例，請參閱傳輸學習特徵化。

移至分散式訓練

Databricks Runtime ML 包含 TorchDistributor、DeepSpeed 和 Ray，以利從單一節點移至分散式訓練。

TorchDistributor

TorchDistributor 是 PySpark 中的開放原始碼模組，可協助使用者在其 Spark 叢集上使用 PyTorch 進行分散式訓練，因此，可讓您以 Spark 工作的形式啟動 PyTorch 訓練工作。 請參閱使用 TorchDistributor 的分散式訓練。

Optuna

Optuna 提供機器學習的自適性超參數微調。

推斷的最佳做法

本節包含搭配 Azure Databricks 使用模型進行推斷的一般秘訣。

  • 若要將成本降至最低，請考慮 CPU 和推斷最佳化的 GPU，例如 NC T4_v3 系列。 沒有明確的建議，因為最佳選擇取決於模型大小、資料維度和其他變數。

  • 使用 MLflow 簡化部署和模型服務。 MLflow 可以記錄任何深度學習模型，包括自訂前處理和後處理邏輯。 Unity Catalog 中的模型或工作區模型登錄中註冊的模型可以部署批次、串流或在線推斷。

在線服務

低延遲服務的最佳選項是在 REST API 後面提供在線服務。 Databricks 提供用於在線推斷的模型服務。 模型服務提供整合介面，可用來部署、控管及查詢 AI 模型並支援服務以下：

  • 自訂模型。 這些是以 MLflow 格式封裝的自訂 Python 模型。 範例包括 Scikit-learn、XGBoost、PyTorch 和 Hugging Face 轉換器模型。
  • 基礎模型 API 所提供的最先進的開放式模型。 這些模型是精心策劃的基礎模型架構，可支援最佳化的推斷。 例如，基本模型，例如 Llama-2-70B-chat、BGE-Large 和 Mistral-7B，可立即與按權杖付費定價搭配使用。 對於需要效能保證和微調模型變體的工作負載，可以使用佈建的輸送量進行部署。
  • 外部模型。 這些是託管在 Databricks 外部的模型。 例如，生成式 AI 模型，像 OpenAI 的 GPT-4、Anthropic 的 Claude 以及其他。 服務於這些模型的端點可以集中管理，客戶可以為其建立速率限制與存取控制。

或者，MLflow 提供 API 用於部署至各種受控服務以進行在線推斷，以及為自訂服務解決方案建立 Docker 容器的 API。

在線推斷的其他常見受控服務包括：

批次和串流推斷

批次和串流評分支援高輸送量、低成本的評分，延遲低至幾分鐘。 如需詳細資訊，請參閱使用 MLflow 進行模型推斷。

  • 如果您預期要存取資料以進行一次以上的推斷，請考慮在執行推斷工作之前，先建立前處理工作，以將資料 ETL 到 Delta Lake 資料表。 如此一來，擷取和準備資料的成本會分散到資料的多次讀取。 將前處理與推斷分開也可讓您為每個工作選取不同的硬體，以將成本和效能最佳化。 例如，您可以使用 ETL 的 CPU 和 GPU 進行推斷。
  • 使用 Spark Pandas UDF 來調整叢集之間的批次和串流推斷。