面對數以億計的圖片數據，到底該用什么樣的方法才能快速搞實驗?

　　這樣的問題，或許在做機器學習研究的你，也會經常遇到。

　　而就在最近，一個國外小哥就提出了一種建議：

　　在 Pytorch lightning 基礎上，讓深度學習 pipeline 速度提升 10 倍!

　　用他自己的話來說就是 ——“爬樓時像給了你一個電梯”。

　　這般“酸爽”，到底是如何做到的呢?

　　優(yōu)化機器學習 pipeline，很重要

　　無論你是身處學術界還是工業(yè)界，時間和資源等各種因素，往往會成為你在搞實驗的枷鎖。

　　尤其是隨著數據集規(guī)模和機器學習模型，變得越發(fā)龐大和復雜，讓實驗變得既費時又耗力。

　　提速這件事，就變得至關重要。

　　例如在 2012 年的時候，訓練一個 AlexNet，要花上 5 到 6 天的時間。

　　而現如今，只需要短短幾分鐘就可以在更大的數據集上訓練更大的圖像模型。

　　這位小哥認為，從某種角度上來說，這是得益于各種各樣的“利器”的出現。

　　例如 Pytorch Lingtning，就是其中一種。

　　于是，他便“死磕”pipeline，總結了六種“閃電加速”實驗周期的方法。

　　并行數據加載

　　數據加載和增強(augmentation)往往被認為是訓練 pipeline 時的瓶頸之一。

　　一個典型的數據 pipeline 包含以下步驟：

　　從磁盤加載數據

　　在運行過程中創(chuàng)建隨機增強

　　將每個樣本分批整理

　　在這個過程中，倒是可以用多個 CPU 進程并行加載數據來優(yōu)化。

　　但與此同時，還可以通過下面的操作來加速這一過程：

　　1、將 DataLoader 中的 num_workers 參數設置為 CPU 的數量。

　　2、當與 GPU 一起工作時，將 DataLoader 中的 pin_memory 參數設置為 True。這可以將數據分配到頁鎖定的內存中，從而加快數據傳輸到 GPU 的速度。

　　使用分布式數據并行的多 GPU 訓練

　　與 CPU 相比，GPU 已經大大加速了訓練和推理時間。

　　但有沒有比一個 GPU 更好的方法?或許答案就是：

　　多個 GPU!

　　在 PyTorch 中，有幾種范式可以用多個 GPU 訓練你的模型。

　　兩個比較常見的范式是“DataParallel”和“DistributedDataParallel”。

　　而小哥采用的方法是后者，因為他認為這是一種更可擴展的方法。

　　但在 PyTorch(以及其他平臺)中修改訓練 pipeline 并非易事。

　　必須考慮以分布式方式加載數據以及權重、梯度和指標的同步等問題。

　　不過，有了 PyTorch Lightning，就可以非常容易地在多個 GPU 上訓練 PyTorch 模型，還是幾乎不需要修改代碼的那種!

　　混合精度

　　在默認情況下，輸入張量以及模型權重是以單精度(float32)定義的。

　　然而，某些數學運算可以用半精度(float16)進行。

　　這樣一來，就可以顯著提升速度，并降低了模型的內存帶寬，還不會犧牲模型的性能。

　　通過在 PyTorch Lightning 中設置混合精度標志(flag)，它會在可能的情況下自動使用半精度，而在其他地方保留單精度。

　　通過最小的代碼修改，模型訓練的速度可以提升 1.5 至 2 倍。

　　早停法

　　當我們訓練深度學習神經網絡的時候，通常希望能獲得最好的泛化性能。

　　但是所有的標準深度學習神經網絡結構，比如全連接多層感知機都很容易過擬合。

　　當網絡在訓練集上表現越來越好，錯誤率越來越低的時候，實際上在某一刻，它在測試集的表現已經開始變差。

　　因此，早停法 (Early Stopping)便在訓練過程中加入了進來。

　　具體來說，就是當驗證損失在預設的評估次數(在小哥的例子中是 10 次評估)后停止訓練。

　　這樣一來，不僅防止了過擬合的現象，而且還可以在幾十個 epoch 內找到最佳模型。

　　Sharded Training

　　Sharded Training 是基于微軟的 ZeRO 研究和 DeepSpeed 庫。

　　它顯著的效果，就是讓訓練大模型變得可擴展和容易。

　　否則，這些模型就不適合在單個 GPU 上使用了。

　　而在 Pytorch Lightning 的 1.2 版本中，便加入了對 Shared Training 的支持。

　　雖然在小哥的實驗過程中，并沒有看到訓練時間或內存占用方面有任何改善。

　　但他認為，這種方法在其它實驗中可能會提供幫助，尤其是在不使用單一 GPU 的大模型方面。

　　模型評估和推理中的優(yōu)化

　　在模型評估和推理期間，梯度不需要用于模型的前向傳遞。

　　因此，可以將評估代碼包裹在一個 torch.no_grad 上下文管理器中。

　　這可以防止在前向傳遞過程中的存儲梯度，從而減少內存占用。

　　如此一來，就可以將更大的 batch 送入模型，讓評估和推理變得更快。

　　效果如何?

　　介紹了這么多，你肯定想知道上述這些方法，具體起到了怎樣的作用。

　　小哥為此做了一張表格，詳解了方法的加速效果。

　　那么這些方法，是否對在做機器學習實驗的你有所幫助呢?

　　快去試試吧~

　　參考鏈接：

　　https://devblog.pytorchlightning.ai/how-we-used-pytorch-lightning-to-make-our-deep-learning-pipeline-10x-faster-731bd7ad318a

特別提醒：本網信息來自于互聯網，目的在于傳遞更多信息，并不代表本網贊同其觀點。其原創(chuàng)性以及文中陳述文字和內容未經本站證實，對本文以及其中全部或者部分內容、文字的真實性、完整性、及時性本站不作任何保證或承諾，并請自行核實相關內容。本站不承擔此類作品侵權行為的直接責任及連帶責任。如若本網有任何內容侵犯您的權益，請及時聯系我們，本站將會在24小時內處理完畢。