OSDI 2022 | 速來圍觀！微軟亞洲研究院計算機系統領域最新論文！
加入技術交流群
01
Roller: 快速高效的深度學習算子編譯器論文鏈接：https://www.usenix.org/conference/osdi22/presentation/zhu代碼地址：https://github.com/microsoft/nnfusion/
隨著模型規模的不斷增長，深度學習對算力的需求也與日俱增。當前，深度學習硬件加速器（如 GPU、TPU 等）主要依賴算子加速庫來支持深度學習應用。然而，隨著不斷出現的新模型和新硬件類型，業界對快速、高效地開發新算子有了更高的要求。算子編譯器（Tensor Compiler）作為一種新途徑，提供了將算子自動編譯成對應加速器內核代碼的能力。
目前，深度學習模型的算子通常被實現成為多重循環嵌套的計算。為了實現對這種算子程序性能的進一步提升，研究員們通常需要對已實現的多重循環計算進行循環展開、合并、分塊、緩存使用、改變并行度等調整。這實質上是一個組合優化問題，搜索空間巨大，所以主流的算子編譯器往往不得不借助機器學習的方法在這個巨大的搜索空間中找出較優的程序實現。而這種搜索過程往往需要數千甚至上萬步的探索，導致編譯一個模型經常需要耗費數小時甚至數天的時間。這種問題在新型的硬件和計算量巨大的算子上特別嚴重。因此，目前主流的基于機器學習的算子程序優化方法極大地影響了深度學習在實際場景中的部署效率。隨著近年來深度學習模型規模的快速增長，預計這種情況將進一步惡化。
微軟亞洲研究院聯合多倫多大學等多所高校在對深度學習計算中用到的大量算子進行編譯、優化和性能分析后，發現了一個有意思的現象：盡管每個算子的優化選項成千上萬，但能達到最大性能的程序，其配置往往與硬件參數匹配，從而能夠更充分地利用硬件資源?；谶@樣的觀察，研究員們提出了一個新的算子編譯器 Roller。為了更好地匹配硬件參數，Roller 將算子的計算過程建模成基于數據塊（tile）的“數據處理流水線”，即將不同大小的數據塊從多級內存結構中搬運到計算核心處理并逐級寫回。為了使整個流水線的吞吐最大化，Roller 要求每一級中數據塊的設置都必須充分匹配硬件的參數設置，比如內存的訪問寬度、計算核的并行度等等。這樣的約束不僅保證了計算程序在整個流水線中的每一級都充分發揮了硬件的最大性能，同時也簡化了對算子程序的性能建模，大大減小了搜索空間，從而避免了在實際硬件加速器上耗時地進行大量嘗試和性能測量。因此，這樣一種“白盒”的內核程序構建方法從本質上可以大大縮減算子編譯時間。
更重要的是，Roller 的整個設計是構建在一套通用硬件抽象上的，它可以很好地適配到多種主流加速器設備上。通過在 NVIDIA GPU、AMD GPU 和 Graphcore IPU 上進行實驗評測，研究員們發現相比于當前算子編譯器（如 TVM 和 Ansor）和算子庫（如 cuBLAS、cuDNN 等），Roller 的編譯方法可以生成性能相近，甚至更好的內核代碼。例如，研究員們在對不同類型的模型中常用到的一百多個算子進行編譯后，Roller 產生的內核代碼中分別有59.7%和73.1%的代碼要優于 NVIDIA 和 AMD 的算子庫，有54.6%和58.8%的代碼優于 TVM 或 Ansor 在這兩種 GPU 上生成程序的性能。值得注意的是，Roller 的算子編譯時間也從小時級別降低到了秒級別，編譯時間減少了三個數量級！
研究員們認為 Roller 這樣的系統可以給硬件加速器提供更高效快速的軟件生態支持。對于缺少成熟算子庫的新型硬件廠商，Roller 還提供了一個可以快速生成算子庫的機會，從而獲得以較快速度趕上領先硬件廠商的機會。Roller 的“白盒”編譯方法也給針對特定硬件快速進行深度學習模型優化和部署帶來了新的機遇。微軟亞洲研究院正在基于 Roller 進一步完善深度學習模型編譯棧，并展開更多關于模型優化、場景部署和新型硬件支持的研究。
02
RESIN: 一種處理云服務中內存泄漏的整體方案論文鏈接：https://www.usenix.org/conference/osdi22/presentation/lou-chang-resin
云計算的基礎設施包含許多復雜的軟件組件，因此會遇到內存泄漏的問題。在云服務中，一旦某個進程發生內存泄露，就會使得其部署的大量機器內存不足以及無辜進程被殺，最終導致大量用戶的虛擬機性能下降、崩潰及重啟，嚴重影響用戶的體驗并可能給用戶造成重大經濟損失。
然而，在云系統中，內存泄漏問題很難處理，現有解決方案或是準確性不高，或是會產生很高的開銷。其原因，一方面是由于許多內存泄漏在極少數情況下才會被緩慢觸發，因此在開發部署過程中很容易躲過測試和檢測；另一方面，在檢測到內存泄漏后，相關問題很難離線復現，這會使得開發人員很難找到泄漏的根本原因。為了解決上述問題，微軟亞洲研究院與微軟 Azure 團隊以及霍普金斯大學的科研人員，一起提出了一種處理云服務中內存泄漏的整體方案 RESIN。
RESIN 采用集中式方法，無需訪問組件的源代碼，也不需要大量的檢測或重新編譯。RESIN 對每個主機都使用了一個監控代理（Monitor Agent），該代理通過利用底層操作系統功能來收集內存使用數據，因此它支持包括內核（Kernel）在內的所有組件。收集好的數據隨后會被加載到遠程服務用于進一步的數據分析，從而最大限度地減少主機的開銷。通過聚合來自不同主機的數據，RESIN 可以運行更復雜的分析來捕獲復雜的泄漏。對于內存泄漏問題，RESIN 進行了多級分解和處理。它會首先執行輕量級泄漏檢測，并在需要確認和診斷時觸發更深入的動態檢查。這種分治法（Divide-and-Conquer）使 RESIN 能夠同時實現低開銷、高精度和可擴展性。
目前，RESIN 已經在微軟 Azure 中運行3年，具有高準確性與低開銷等優勢。由于內存不足導致的虛擬機重啟有效地減少了41倍。
03
SparTA: 基于張量稀疏屬性的深度學習模型稀疏化編譯框架論文鏈接：https://www.usenix.org/conference/osdi22/presentation/zheng-ningxin項目代碼地址：https://github.com/microsoft/SparTA.git論文結果復現代碼地址：https://github.com/microsoft/nni/tree/sparta_artifact/sparta
隨著深度學習的快速發展，深度學習模型的規模呈現出指數級增長的態勢。單個模型具有高達萬億級別的參數量，這遠遠超出了硬件加速器運算能力的增長速度。同時，端側設備由于其運算能力和功耗的限制，對深度學習模型大小和推理延遲有近乎嚴苛的要求。因此，探索深度學習模型中的稀疏性以及對稀疏模型做有效的加速成為深度學習模型發展和落地的關鍵因素。然而，目前稀疏模型在系統支持方面還存在諸多不足，阻礙了模型在稀疏化上的探索。
這些不足具體表現為（i）由于針對特殊的模型稀疏模式構建高效的代碼非常困難，通常需要系統程序員的深度參與，深度學習研究員在模型稀疏化的研究過程中通常使用代理指標（Proxy metrics，如 FLOPs、位寬）來估算加速效果。可是代理指標并不能準確反映模型稀疏化帶來的加速效果，其預測的效果有時甚至和實際情況相去甚遠；（ii）當前稀疏優化的大多工作都只集中在單個算子，忽視了一個稀疏化算子在整個深度學習模型中可能產生的連帶影響，可將稀疏化傳導到模型中的其他算子；（iii）當前針對某個具體模型的稀疏化優化方案很難被重用，難以和其它相關技術組合起來遷移到其他深度學習模型上去，例如，在被剪枝的算子和被量化的算子上做的優化技術很難直接遷移到一個既被剪枝又被量化的算子上。
為了解決模型稀疏化過程中遇到的上述挑戰，微軟亞洲研究院提出了 SparTA——一個專門優化稀疏深度學習模型的端到端編譯框架。SparTA 將深度學習模型中張量的稀疏屬性（由剪枝和量化產生）作為整個編譯框架中的核心抽象 TeSA (Tensor with Sparsity Attribute) ，并圍繞 TeSA 構建出面向稀疏模型的全套編譯優化技術。
在使用 SparTA 時，用戶先使用 TeSA 來標注深度學習模型中某些張量的稀疏樣式（Sparsity pattern），然后通過 SparTA 提出的三個核心技術來對模型進行端到端地優化：一是張量的稀疏屬性在整個數據流圖中的傳播，由 Tensor Algebra 和 Tensor Scrambling 技術自動完成；二是對稀疏算子進行優化變換（Transformation），變換為更易于加速、計算效率更高的稀疏樣式，這種變換使得不同的優化技術可以被有機地結合起來；三是做針對稀疏張量的代碼特化（Code Specialization），將稀疏樣式硬編碼到算子的代碼中，刪除死代碼（Dead Code），并且針對給定加速器特化使用其專有硬件（如 sparse tensor core）。
通過全面的測試，SparTA 展示出了相比于已有工具高達平均8.4倍的加速效果。SparTA 不但可以對稠密模型稀疏化以后進行優化，而且還能用來加速一開始就采用特定稀疏樣式設計的大型預訓練模型。在這方面，SparTA 已經被用來優化微軟亞洲研究院研發的 NUWA 預訓練視頻生成模型。SparTA 對 NUWA 模型中提出的 3DNA 稀疏化注意力機制達到了2倍以上的加速。微軟亞洲研究院目前正在對 SparTA 進行代碼重整和優化，提高易用性，并將盡快開源，以促進深度學習模型稀疏化的研究和實用化。
*博客內容為網友個人發布，僅代表博主個人觀點，如有侵權請聯系工作人員刪除。
