Azure Databricks 上深度學習的最佳做法
本文包含 Azure Databricks 上的深度學習秘訣,以及專為 optimize 深度學習工作負載所設計之內建工具和連結庫的相關信息,例如:
- Delta 和 馬賽克串流,用於載入資料
- Optuna,用於平行處理訓練
- Pandas UDF,用於推斷
Databricks Mosaic AI 透過用於機器學習的 Databricks Runtime 提供預先建置的深度學習基礎結構,其中包括最常見的深度學習媒體櫃,例如 TensorFlow、PyTorch 和 Keras。 它也具有內建、預先設定的 GPU 支援,包括驅動程式和支援媒體櫃。
Databricks Runtime ML 也包含 Azure Databricks 工作區的所有功能,例如叢集建立和管理、媒體櫃和環境管理、使用 Databricks Git 資料夾進行程式代碼管理、自動化支援,包括 Databricks 工作和 API,以及用於模型開發追蹤和模型部署與服務的整合 MLflow。
資源和環境管理
Azure Databricks 可協助您自訂深度學習環境,並讓整個使用者的環境保持一致。
自訂開發環境
使用 Databricks Runtime,您可以在筆記本、叢集和工作層級自訂開發環境。
- 使用 筆記本範圍的 Python 函式庫 或 筆記本範圍的 R 函式庫,使您可以使用特定 set 或特定版本的函式庫,而不會影響其他叢集使用者的函式庫。
- 在叢集層級安裝媒體櫃,以標準化團隊或專案的版本。
- Set Azure Databricks 作業,以確保重複的工作會在一致且不變的環境中執行。
使用叢集原則
您可以建立叢集原則來引導資料科學家選擇正確的選擇,例如使用單一節點叢集進行開發,以及針對大型工作使用自動調整叢集。
請考慮將 A100 GPU 用於深度學習工作負載
A100 GPU 是許多深度學習工作的有效選擇,例如訓練和調整大型語言模型、自然語言處理、物件偵測和分類,以及建議引擎。
- Databricks 支援所有雲端上的 A100 GPU。 如需支援 GPU 類型的完整
,請參閱 支援的實例類型。 - A100 GPU 通常可用性有限。 請連絡您的雲端提供者取得資源分派,或考慮事先保留容量。
GPU 排程
若要最佳化您的 GPU,以便進行分散式深度學習訓練和推論,請使用 optimize GPU 排程。 請參閱 GPU 排程。
載入資料的最佳做法
雲端資料儲存體通常不會針對 I/O 進行最佳化,這對於需要大型資料集的深度學習模型而言可能是一項挑戰。 Databricks Runtime ML 包含 Delta Lake 和 馬賽克串流,以 optimize 深度學習應用程式的數據輸送量。
Databricks 建議針對數據記憶體使用 Delta Lake tables。 Delta Lake 簡化了 ETL,並可讓您高效地存取資料。 特別是針對影像,Delta Lake 有助於 optimize 數據導入,用於訓練和推斷。 影像應用程式的參考解決方案提供使用 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。 可以檢查網路、處理器和記憶體使用量,以檢查瓶頸。 如需詳細資訊,請參閱叢集計量。
Optimize 深度學習效能
您可以且應該在 Databricks 上使用深度學習效能最佳化技術。
早期停止
早期停止會監控根據驗證 set 計算的指標值,並在指標停止改善時停止訓練。 這是比猜測要完成的大量 Epoch 更好的方法。 每個深度學習媒體櫃都會提供原生 API 以供早期停止;例如,請參閱 TensorFlow/Keras 和 PyTorch Lightning 的 EarlyStopping 回撥 API。 如需範例筆記本,請參閱 TensorFlow Keras 範例筆記本。
批次大小調整
調整批次大小有助於提升 optimize GPU 使用率。 如果批次大小太小,計算就無法完全使用 GPU 功能。 您可以使用叢集計量來檢視 GPU 計量。
配合學習速率調整批次大小。 不錯的經驗法則是,將批次大小增加 n 時,依 sqrt(n) 增加學習速率。 手動調整時,請嘗試將批次大小變更為 2 或 0.5。 然後,請繼續調整 optimize 的效能,可以手動進行,或使用像 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。
在線推斷的其他常見受控服務包括:
批次和串流推斷
批次和串流評分支援高輸送量、低成本的評分,延遲低至幾分鐘。 如需詳細資訊,請參閱 部署批次推斷和預測的模型。
- 如果您預期要多次存取資料以進行推斷,請考慮建立一個前處理作業,將資料經 ETL 處理後放入 Delta Lake table,然後再執行推斷作業。 如此一來,擷取和準備資料的成本會分散到資料的多次讀取。 將前置處理與推斷分開也可讓您 select 每個作業的不同硬體,以 optimize 成本和效能。 例如,您可以使用 ETL 的 CPU 和 GPU 進行推斷。
- 使用 Spark Pandas UDF 來調整叢集之間的批次和串流推斷。
- 從 Azure Databricks 記錄模型時,MLflow 會自動提供推斷程式碼,以將模型套用為 pandas UDF。
- 您也可以進一步 optimize 推斷管線,特別是針對大型深度學習模型。 有關範例,請參閱影像 ETL 的參考解決方案。