在對最先進的視覺語言模型 BridgeTower 進行微調(diào)時，使用 Optimum Habana v1.6， Habana Gaudi2 可以達到 近 3 倍于 A100 的速度。硬件加速的數(shù)據(jù)加載以及 fast DDP 這兩個新特性對性能提高貢獻最大。

這些技術(shù)適用于任何性能瓶頸在數(shù)據(jù)加載上的其他工作負載，很多視覺模型的性能瓶頸在數(shù)據(jù)加載。 本文將帶你了解我們用于比較 Habana Gaudi2 和英偉達 A100 80GB 上的 BridgeTower 微調(diào)性能的流程及測試基準。通過我們的演示，你會發(fā)現(xiàn)在基于 transformers 的模型上使用 Gaudi2 以及這些新特性是多么容易！

BridgeTower

最近，視覺語言 (Vision-Language，VL) 模型 的重要性與日俱增，它們開始在各種 VL 任務(wù)中占據(jù)主導(dǎo)地位。在處理多模態(tài)數(shù)據(jù)時，最常見的做法是使用單模態(tài)編碼器從各模態(tài)數(shù)據(jù)中提取各自的數(shù)據(jù)表征。然后，抑或是將這些表征融合在一起，抑或是將它們輸入給跨模態(tài)編碼器。為了有效解除傳統(tǒng) VL 表征學(xué)習(xí)的算法局限性及其性能限制，BridgeTower 引入了多個 橋接層 ，在單模態(tài)編碼器的頂部若干層建立與跨模態(tài)編碼器的逐層連接，這使得跨模態(tài)編碼器中不同語義級別的視覺和文本表征之間能夠?qū)崿F(xiàn)有效的、自底而上的跨模態(tài)對齊和融合。

僅基于 400 萬張圖像預(yù)訓(xùn)練而得的 BridgeTower 模型就能在各種下游視覺語言任務(wù)上取得最先進的性能 (詳見 [下文](# 基準測試))。特別地，BridgeTower 在使用相同的預(yù)訓(xùn)練數(shù)據(jù)和幾乎可以忽略不計的額外參數(shù)和計算成本的條件下，在 VQAV2 的 test-std 子集上取得了 78.73% 的準確率，比之前最先進的模型 (METER) 的準確率提高了 1.09%。值得一提的是，當(dāng)進一步增加模型參數(shù)量，BridgeTower 的準確率可達 81.15%，超過了那些基于大得多的數(shù)據(jù)集預(yù)訓(xùn)練出來的模型。

硬件

英偉達 A100 張量核 GPU 內(nèi)含第三代 張量核技術(shù)。盡管最近新一代 H100 已發(fā)布，但目前來講 A100 仍然是大多數(shù)云服務(wù)上最快的 GPU。這里，我們使用顯存為 80GB 的卡，它的顯存容量和帶寬都比 40GB 版本更高。

Habana Gaudi2 是 Habana Labs 設(shè)計的第二代 AI 硬件加速卡。一臺服務(wù)器包含 8 個稱為 HPU 的加速卡，每張加速卡有 96GB 內(nèi)存。你可查閱 我們之前的博文，以了解 Gaudi2 的更多信息以及如何在 英特爾開發(fā)者云 (Intel Developer Cloud，IDC) ?上獲取 Gaudi2 實例。與市面上許多其他 AI 加速器不同，用戶很容易通過 Optimum Habana 使用到 Gaudi2 的高級特性。有了 Optimum Habana，用戶僅需更改 2 行 代碼即可將基于 transformers 的模型腳本移植到 Gaudi 上。

基準測試

為了評測訓(xùn)練性能，我們準備微調(diào) BridgeTower 的 large checkpoint，其參數(shù)量為 866M。該 checkpoint 在預(yù)訓(xùn)練時使用了掩碼語言模型、圖像文本匹配以及圖像文本對比損失，其預(yù)訓(xùn)練數(shù)據(jù)集為 Conceptual Captions、SBU Captions、MSCOCO Captions 以及 Visual Genome。

我們將在 紐約客配文競賽數(shù)據(jù)集 上進一步微調(diào)此 checkpoint，該數(shù)據(jù)集包含《紐約客》雜志上的漫畫及每個漫畫對應(yīng)的投票最多的配文。

除了 batch size 之外，兩種加速卡的其他微調(diào)超參數(shù)都是相同的: Gaudi2 單卡可放下 40 個樣本，而 A100 只能放得下 32 個樣本。你可以在 這兒 找到 Gaudi2 使用的訓(xùn)練超參，A100 使用的超參見 這兒。

在處理涉及圖像的數(shù)據(jù)集時，數(shù)據(jù)加載通常是性能瓶頸之一，這是因為一般情況下很多預(yù)處理操作都是在 CPU 上完成的 (如圖像解碼、圖像增強等)，然后再將預(yù)處理后的圖像發(fā)送至訓(xùn)練卡。這里帶來一個優(yōu)化點，理想情況下， 我們可以直接將原數(shù)據(jù)發(fā)送到設(shè)備，并在設(shè)備上執(zhí)行解碼和各種圖像變換 。但在此之前，我們先看看能不能簡單地通過分配更多 CPU 資源來加速數(shù)據(jù)加載。

利用 dataloader_num_workers

如果圖像加載是在 CPU 上完成的，一個簡單地加速方法就是分配更多的子進程來加載數(shù)據(jù)。使用 transformers 的 TrainingArguments (或 Optimum Habana 中相應(yīng)的 GaudiTrainingArguments ) 可以很容易地做到這一點: 你可以用 dataloader_num_workers=N 參數(shù)來設(shè)置 CPU 上用于數(shù)據(jù)加載的子進程的數(shù)目 ( N )。

dataloader_num_workers 參數(shù)的默認值為 0，表示僅在主進程中加載數(shù)據(jù)。這個設(shè)置很多情況下并不是最佳的，因為主進程有很多事情需要做。我們可以將其設(shè)置為 1，這樣就會有一個專有的子進程來加載數(shù)據(jù)。當(dāng)分配多個子進程時，每個子進程將負責(zé)準備一個 batch。這意味著內(nèi)存消耗將隨著工作進程數(shù)的增加而增加。一個簡單的方法是將其設(shè)置為 CPU 核數(shù)，但有時候有些核可能在做別的事情，因此需要嘗試找到一個最佳配置。

下面，我們跑兩組實驗:

• 8 卡分布式混合精度 ( bfloat16 / float ) 訓(xùn)練，其中數(shù)據(jù)加載由各 rank 的主進程執(zhí)行 (即 dataloader_num_workers=0 )

• 8 卡分布式混合精度 ( bfloat16 / float ) 訓(xùn)練，且每 rank 各有 1 個用于數(shù)據(jù)加載的專用子進程 (即 dataloader_num_workers=1 )

以下是這兩組實驗在 Gaudi2 和 A100 上分別測得的吞吐量: dataloader_num_workers=0``dataloader_num_workers=1

首先，我們看到 dataloader_num_workers=1 時 Gaudi2 的速度是 A100 的 2.16 倍，在 dataloader_num_workers=0 時是 A100 的 2.53 倍，這與我們之前 報告的數(shù)據(jù) 相當(dāng)！

其次，我們還看到 為數(shù)據(jù)加載分配更多資源可以輕松實現(xiàn)加速: Gaudi2 上加速比為 1.20，A100 上加速比為 1.41。

我們嘗試了將數(shù)據(jù)加載子進程增加到數(shù)個，但實驗表明其 在 Gaudi2 和 A100 上的性能均沒有比 dataloader_num_workers=1 更好。 因此， 使用 dataloader_num_workers=1 通常是加速涉及到圖像的工作負載時首先嘗試的方法！

你可以在 這兒 找到可視化的 Gaudi2 Tensorboard 日志，A100 的在 這兒。

Optimum Habana 的 fast DDP

在深入研究硬件加速的數(shù)據(jù)加載之前，我們來看一下另一個非常簡單的 Gaudi 分布式運行的加速方法。新發(fā)布的 Optimum Habana 1.6.0 版引入了一個新功能，允許用戶選擇分布式策略:

• distribution_strategy="ddp" 使用 PyTorch 的 DistributedDataParallel (DDP) 實現(xiàn)

• distribution_strategy="fast_ddp" 使用 Gaudi 自有的更輕量級且一般來講更快的實現(xiàn)

Optimum Habana 的 fast DDP 不會像 DDP 那樣將參數(shù)梯度分割到存儲桶 (bucket) 中。它還會使用 HPU 圖 (graph) ?來收集所有進程的梯度，并以最小的主機開銷來對它們進行更新 (在 all_reduce 操作之后)。你可以在 這兒 找到其實現(xiàn)。

只需在 Gaudi2 上使用 distribution_strategy="fast_ddp" (并保持 dataloader_num_workers=1 ) 即可將每秒吞吐提高到 705.9， 比 DDP 快 1.10 倍，比 A100 快 2.38 倍！

因此，僅添加兩個訓(xùn)練參數(shù) ( dataloader_num_workers=1 及 distribution_strategy="fast_ddp" )，我們即可在 Gaudi2 上實現(xiàn) 1.33 倍的加速，與使用 dataloader_num_workers=1 的 A100 相比，加速比達到 2.38 倍。

使用 Optimum Habana 實現(xiàn)硬件加速的數(shù)據(jù)加載

為了獲得更多的加速，我們可以將盡可能多的數(shù)據(jù)加載操作從 CPU 上移到加速卡上 (即 Gaudi2 上的 HPU 或 A100 上的 GPU)。在 Gaudi2 上，我們可以使用 Habana 的 媒體流水線 (media pipeline) ?來達到這一目的。

給定一個數(shù)據(jù)集，大多數(shù)的數(shù)據(jù)加載器會做如下操作:

1. 獲取數(shù)據(jù) (例如，存儲在磁盤上的 JPEG 文件)

2. CPU 讀取編碼圖像

3. CPU 對圖像進行解碼

4. CPU 對圖像進行變換來增強圖像

5. 最后，將圖像發(fā)送至設(shè)備 (盡管這通常不是由數(shù)據(jù)加載器本身完成的)

與在 CPU 上完成整個過程后再把準備好訓(xùn)練的數(shù)據(jù)發(fā)送到加速卡相比，更高效的工作流程是先將編碼圖像發(fā)送到加速卡，然后由加速卡執(zhí)行圖像解碼和增強:

1. 同上

2. 同上

3. 將編碼圖像發(fā)送至加速卡

4. 加速卡對圖像進行解碼

5. 加速卡對圖像進行變換來增強圖像

這樣我們就可以利用加速卡強大的計算能力來加速圖像解碼和變換。請注意，執(zhí)行此操作時需要注意兩個問題:

• 設(shè)備內(nèi)存消耗將會增加，因此如果沒有足夠的可用內(nèi)存，你需要減小 batch size。這可能會降低該方法帶來的加速。

• 如果在使用 CPU 數(shù)據(jù)加載方案時，加速卡的利用率已經(jīng)很高 (100% 或接近 100%) 了，那就不要指望把這些操作卸載到加速卡會獲得加速，因為它們已經(jīng)忙得不可開交了。

我們還提供了一個示例，以幫助你在 Gaudi2 上實現(xiàn)這一優(yōu)化: Optimum Habana 中的 對比圖像文本示例 提供了一個可直接使用的媒體流水線 (media pipe)，你可以將其直接用于類似于 COCO 那樣的包含文本和圖像的數(shù)據(jù)集！只需在命令中加一個 --mediapipe_dataloader 即可使能它。

感興趣的讀者可以參閱 Gaudi 的 文檔，該文檔對這一機制的底層實現(xiàn)給出了一些概述。讀者還可以參考 這個文檔，它給出了目前支持的所有算子的列表。

We are now going to benchmark a run with dataloader_num_workers=1 , distribution_strategy="fast_ddp" and mediapipe_dataloader since all these optimizations are compatible with each other:

現(xiàn)在我們測試一下 dataloader_num_workers=1 、 distribution_strategy="fast_ddp" 和 mediapipe_dataloader 在不同組合時的性能，所有這些優(yōu)化都是相互兼容的: dataloader_num_workers=0``dataloader_num_workers=1``dataloader_num_workers=1 + distribution_strategy="fast_ddp"``dataloader_num_workers=1 + distribution_strategy="fast_ddp" + mediapipe_dataloader

與之前基于 dataloader_num_workers=1 和 distribution_strategy="fast_ddp" 的性能數(shù)據(jù)相比，我們又額外獲得了 1.14 倍的加速。

因此，Gaudi2 上的最終結(jié)果比最開始快了 1.51 倍，而且 僅需增加 3 個簡單的訓(xùn)練參數(shù)。 這個結(jié)果 也比使用 dataloader_num_workers=1 的 A100 快 2.70 倍！

如何復(fù)現(xiàn)我們的基準測試

要復(fù)現(xiàn)我們的基準測試，你首先需要能夠訪問 英特爾開發(fā)者云 (Intel Developer Cloud，IDC) ?上的 Gaudi2 實例 (更多信息，請參閱 本指南)。

然后，你需要安裝最新版本的 Optimum Habana 并運行 run_bridgetower.py ，您可以在 此處 找到這個腳本。具體操作命令如下:

運行腳本時使用的基本命令行如下:

上述命令行對應(yīng)于 --dataloader_num_workers 0 。如果要運行其他配置，你可以視情況添加 --dataloader_num_workers 1 、 --distribution_strategy fast_ddp 及 --mediapipe_dataloader 。

如要將模型和 Tensorboard 日志推送到 Hugging Face Hub，你必須事先登錄自己的帳戶:

huggingface-cli?login


在 A100 上運行的話，你可以使用相同的 run_bridgetower.py 腳本，但需要做一些小更改:

• 將 GaudiTrainer 和 GaudiTrainingArguments 替換為 transformers 的 Trainer 和 TrainingArguments

• 刪除 GaudiConfig 、gaudi_config 和 HabanaDataloaderTrainer 的相關(guān)代碼

• 直接從 transformers 導(dǎo)入 set_seed : from transformers import set_seed

本文中有關(guān) A100 的數(shù)據(jù)是在一個含 8 張 GPU 的 Nvidia A100 80GB GCP 實例上測試而得。

請注意， --distribution_strategy fast_ddp 和 --mediapipe_dataloader 僅適用于 Gaudi2，不適用于 A100。

總結(jié)

在處理圖像時，我們提出了兩個用于加速訓(xùn)練工作流的解決方案: 1) 分配更多的 CPU 資源給數(shù)據(jù)加載器，2) 直接在加速卡上而不是 CPU 上解碼和變換圖像。

我們證明，在訓(xùn)練像 BridgeTower 這樣的 SOTA 視覺語言模型時，它會帶來顯著的加速: 基于 Optimum Habana 的 Habana Gaudi2 幾乎比基于 Transformers 的英偉達 A100 80GB 快 3 倍！。而為了獲得這些加速，你只需在訓(xùn)練腳本中額外加幾個參數(shù)即可，相當(dāng)容易！

后面，我們期待能使用 HPU 圖進一步加速訓(xùn)練，我們還想向大家展示如何在 Gaudi2 上使用 DeepSpeed ZeRO-3 來加速 LLM 的訓(xùn)練。敬請關(guān)注！

如果你對使用最新的 AI 硬件加速卡和軟件庫加速機器學(xué)習(xí)訓(xùn)練和推理工作流感興趣，可以移步我們的 專家加速計劃。如果你想了解有關(guān) Habana 解決方案的更多信息，可以在 此處 了解我們相關(guān)信息并聯(lián)系他們。要詳細了解 Hugging Face 為讓 AI 硬件加速卡更易于使用而做的努力，請查閱我們的 硬件合作伙伴計劃。

相關(guān)話題

• 更快的訓(xùn)練和推理: 對比 Habana Gaudi2 和英偉達 A100 80GB

• 大語言模型快速推理: 在 Habana Gaudi2 上推理 BLOOMZ

英文原文: https://hf.co/blog/bridgetower

原文作者: Régis Pierrard，Anahita Bhiwandiwalla

譯者: Matrix Yao (姚偉峰)，英特爾深度學(xué)習(xí)工程師，工作方向為 transformer-family 模型在各模態(tài)數(shù)據(jù)上的應(yīng)用及大規(guī)模模型的訓(xùn)練推理。

審校/排版: zhongdongy (阿東)