與整個技術行業一樣，我們也一直在關注微軟如何運用AI基礎模型轉變其服務和軟體產品組合。雖然不敢妄下斷言，但從微軟在數十個區域部署的幾十萬個GPU來看，軟體巨頭可能已經積累起地球上規模最大的AI訓練基礎設施池。
從某種程度上講，這種規模的AI訓練是個只有超大規模服務商和雲服務提供才有資格下場的遊戲。相比之下，其他領域只能對預訓練模型做微調，或者運行體量較小的新模型。
而作為基礎模型的最大消費者之一兼基礎模型生產基礎設施的最大提供商之一，微軟算是兩邊押寶，意味著無論市場走向何方、如何發展，微軟都永遠不虧。與其說這是精明的商業算盤，倒不如說這是經濟體系中規模化資本的天然優勢。其實微軟之前的路走得並不順，沒能抓住2008年經濟衰退的機會及時擴大規模，差點因此斷送了跟亞馬遜雲科技正面抗衡的機會。但值得慶幸的是，微軟的股東知恥而後勇，從十年前開始認真投資Azure。Windows Server堆棧和它的數千萬客戶也給微軟提供了Azure發展所必需的資金和受眾群體，後發者微軟終於也擁有了前景光明的雲業務。
所有這一切的關鍵，是將正確的超級計算基礎設施投入其中，而這項工作的執行者就是微軟Azure HPC與AI總經理Nidhi Chappell。Chappell的團隊負責Azure全部工作負載優化型計算、存儲和網路任務的落地，具體包括HPC模擬和建模、AI訓練與推理，還有SAP HANA、自動駕駛、可視化和機密計算等。
Chappell於2019年6月加入微軟，此前曾擔任英特爾數據中心企業與HPC業務高級總監，還管理過英特爾的AI產品線及入門級伺服器與定製化至強SoC業務。她非常了解微軟的客戶群體，努力保證Azure的基礎設施能夠幫助不同規模、各行各業的公司參與到AI革命中來。在日前開幕的英偉達GPU技術大會（GTC）之前，Chappell接受了The Next Platform的採訪，探討微軟與英偉達的合作關係以及微軟如何建立自己的AI基礎設施。
主持人：我們開門見山，從微軟的超大規模廠商和雲提供商這雙重身份說起。在運行Prometheus或者OpenAI訓練這類服務時，微軟用的就是自家Azure嗎？更確切地說，微軟會像普通客戶一樣使用Azure實例，還是說設立了單獨的基礎設施，克隆了Azure體系但專門只為微軟自己服務？
Nidhi Chappell: 我們的基礎設施完全來自Azure公有雲，所以面向所有用戶。無論是內部團隊運行的Bing、ChatGPT還是其他負載，一切都完全依託於Azure公共基礎設施。
主持人： 那微軟的內部團隊會提前試用嗎？用這種方式確保基礎設施在面向公眾發布時能運行良好？
Nidhi Chappell: 不不，當然不會。我們用的是完全相同的基礎設施，同時面向內部和外部開放。我們從業務建立之初就在朝這個方向努力。我們希望確保自己能建立起靈活縮放的構建塊。因為你知道，客戶的規模不同，他們的實際要求會有所不同，所訓練的模型大小也有差別。我們的架構具有極強的可擴展性，既能支持低端訓練也能承載高端訓練。但其中使用的都是完全相同的構建塊。我們不會根據業務規模改變構建方式，只會根據業務規模改變交付方式。
主持人： 說到規模，我還有另一個問題。微軟與英偉達在合作倡議中公布了「Hopper」GPU系統，那這到底是通過NVLink Switch結構把256個GPU粘合到同一個內存地址空間內，還是說用獨立的PCI-Express版Hopper或者帶NVSwitch互連的Hopper HGX系統把八塊基板整合在一起？如果微軟確實用到了NVSwitch，那當然很棒；但如果沒用，我其實對這種架構並不太看好。
Nidhi Chappell: NVLink擴展仍處於開發階段。我們非常關注NVLink的未來擴展，但歸根結底，我們真正需要提GPU之間能夠相互通信。所以通信能力才是關鍵，具體技術選擇不要妨礙通信就好。
現在，有了我們自己和整個行業已經及正在開發的各種模型，尤其是各種專家模型，接下來的任務就是保證一定水平的通信吞吐量。經過分析，我們發現最新一代InfiniBand已經能為GPU的相互通信提供良好性能。這已經符合我們的既定目標，就是保證獲得可擴展的充足性能。當然，展望未來，我們也將繼續關注NVLink擴展並逐步嘗試引入。如果效果不錯，我們就會全面使用。這裡還有個區別，如果選擇NVLink，用戶必須清楚NVLink域有多大，但InfiniBand就沒這個必要——只需編寫代碼，各個GPU之間就能順利實現通信。
主持人： 那底層可能會使用支持MPI的GPUDirect？
Nidhi Chappell: 沒錯，基本就是MPI。
主持人： 這就是我提這個問題的初衷。我本人比較守舊，記得2000年初那會就出現過搭載128甚至256個CPU的大型NUMA設備，記得微軟還為這機器編寫了一些早期作業系統。雖然讓128或者256個CPU一起共享內存確實方便，但NUMA域管理起來要比很多人以為的麻煩得多。而且跟20年前的內存速度相比，互連速度也要慢得多。這個我們有一說一。NVSwitch架構也會增加成本，所以除非真能增加價值，否則很多大規模廠商和雲服務商並不喜歡。
Nidhi Chappell: 另外我還想強調一點，這種架構會將GPU互連量限制在256個。我無法公開OpenAI訓練中所使用的GPU規模，但肯定要比256個GPU大上一個數量級。
主持人： 哈哈，我猜可能會在10000到12500個節點中使用80000到100000個GPU吧，這應該是微軟這樣的技術巨頭能夠建立的最大實例了。
Nidhi Chappell: 我不能說得更多，但確實是個相當大的數字。
主持人： 這個數字非常重要，因為大家應該了解如今的基礎模型到底對應著怎樣的AI訓練規模。十年前，Hot Chips大會上大家都在爭相討論，因為當時谷歌估計是在用8000個GPU進行AI訓練。現在，這樣的規模的集群實例在各大公有雲服務商那裡都能租到了。
Nidhi Chappell: 總之，我覺得在AI訓練和NVLink擴展方面，成本其實沒那麼重要，畢竟它基本就固定在那裡。更重要的是，小域之內的256個GPU之間將擁有更快的通信速度，而這個規模之外的GPU通信速度就要差得多。
目前，大家可以在Azure上通過InfiniBand架構直接租用4000個GPU，我們以公共實例的形式對外開放。但就在兩年之前，我還覺得這樣的規模根本就不可能。所以如果客戶是一家剛剛成立的初創公司，初步著手構建AI模型，那根本不會馬上用到幾萬個GPU，這4000個GPU就足夠起步了。我們還擴展了InfiniBand架構，在其上添加了更多GPU，希望服務於少數「胃口更大」的客戶。所以我們在4000個GPU之外，還有6000個GPU的實例選項，都對客戶公開可用。我們還將為需求更複雜的客戶提供規模更大的選項，相信從事基礎模型開發的客戶很快就會超越這樣的上限。
主持人： 這樣規模的服務要怎麼使用啊？客戶肯定得跟雲服務商建立某種程度的協作。我猜如果真要一口氣用4000甚至6000個GPU，那肯定得單獨打電話聯繫……
Nidhi Chappell: 在構建大語言模型時，過程中肯定需要瘋狂吞噬計算資源。所以客戶必須搞清楚自己對資源的擴容需求，我們也會在這方面跟客戶合作，討論未來計劃要走多遠，再據此為他們整合基礎設施。但我們提供的具體方案很多，不只是把基礎設施粘合在一起，而是投入了很多精力來保證客戶能夠運行起規模如此龐大的基礎設施。
相信你的知道，AI訓練其實是一項同步工作，要求把同一項工作內容分發給那麼多的GPU。我曾經開玩笑說，我的工作就是指揮芝加哥交響樂團和紐約愛樂樂園一同演奏。基礎設施編排真的跟樂園指揮很像，一個GPU出了故障都會引發大問題。所以我們才建立起現在的系統，保證運行永遠不會失敗。流程內置了彈性空間，基礎設施也內置了彈性空間，這樣才能對模型做線性擴展、始終保證穩定的算力供應。
主持人： 無論是從自主運行大規模AI訓練的用戶角度，還是從為大量客戶提供訓練後AI模型的雲平台的角度，微軟都必須藉助英偉達的GPU資源。那微軟和英偉達之間，保持著怎樣的密切合作關係？
Nidhi Chappell: 我們採購的是英偉達的標準部件，也會在某些方面與英偉達共同開展工程設計。我們會預計考慮未來幾代產品的實際情況，包括交流微軟將以怎樣的節奏升級數據中心冷卻、需要怎樣的可靠性，或者需要達到怎樣的精度標準等……
主持人： FP0威力無窮，所以這個問題應該不難找到答案……
Nidhi Chappell: 哈哈，真是那樣就好了。但嚴肅來講，我們在大規模AI方面經驗豐富，可以在這方面提供很多反饋。我們還提供了很多關於英偉達產品質量的反饋。他們想要打造的是迅如閃電般的產品，但這樣的硬體並不一定是規模化應用下的最優方案。而我們的需求就是大規模部署，所以只能邊測試邊實際部署。就這樣，我們實際上成了英偉達的規模化應用測試夥伴。
主持人： 所以英偉達才開始構建DGX伺服器，之後開始在內部構建「Saturn-V」和「Selene」超級電腦，並嘗試用Grace-Hopper構建Eos設備。他們不單要考慮如何把各個部分組合起來，還得探索如何在自己的工作負載上大規模運行。
Nidhi Chappell: 你知道英偉達正把所有開發負載都轉向Azure嗎？
主持人：不知道，但這個很重要，能不能多講講？
Nidhi Chappell: 這個確實很重要，他們也沒有公開發布，但多少也提到過。英偉達其實已經把所有工作負載都遷移到了Azure上，包括內部應用開發、軟體堆棧、企業堆棧等等……
他們在文章中委婉地表達過這方面消息，所以現在回頭看，大家會意識到「哦，原來是這麼個意思。」是的，他們已經把所有開發負載遷往Azure公共基礎設施，於是英偉達現在既是我們的合作夥伴、也是我們的客戶。他們知道我們正在以怎樣的規模發現問題，我們的運行規模比任何業內同行都要大。
主持人： 明白，這事我會繼續跟進。
那我們再聊下一個問題。我很好奇，您在Azure AI項目底層的InfiniBand網路採取了怎樣的拓撲設計？應該有很多不同的方法可以實現計算聚合吧？
Nidhi Chappell: 我們沒有透過關於拓撲結構的細節消息，我只能說：這是個胖樹拓撲。
主持人： 有意思。這跟我想像得不太一樣，但胖樹拓撲確實是HPC模擬和建模負載領域比較常見的結構。
Nidhi Chappell: 這也是我們跟客戶聯合設計之後的結果，雙方會討論新模型將面對怎樣的流量，特別是在專家模型運行起來之後，這裡會有大量通信，所以我們的結構後端有一個完整的胖樹InfiniBand拓撲。
主持人：說起新東西，你們正在用400 Gb/秒的Quantum 2 InfinBand；如果1.6 Tb/秒的Quantum 4來了，你會立刻向英偉達下單嗎？
Nidhi Chappell:
我覺得最重要的是在系統中尋求平衡吧。沒錯，想要保證GPU得到正確饋送，就必須確保內存架構和內存帶寬不斷擴展。絕對不能讓GPU的網路成為樞軸點或者性能瓶頸。所以我們才會與英偉達等供應商密切合作，確保內存帶寬和內存容量始終隨模型大小的變化而伸縮。
主持人： 但Hopper GPU擴展了顯存帶寬，顯存容量卻沒有提高。
Nidhi Chappell: 這確實是個挑戰。所以英偉達也在努力嘗試增加內存容量。否則用戶就會將目光投向CPU內存容量，嘗試把部分負載交給CPU處理，所以系統的均衡性是最重要的。
主持人： 我一直開玩笑說，Grace Arm CPU是一款非常有用的可編程控制器，負責操控Hooper GPU的480 GB DDR5內存塊。這一容量要遠高於速率為3 TB/秒的80 GB HBM3，但HBM內存的價格是普通LPDDR5X內存的3倍。我覺得在Hooper GPU上引入5 TB/秒的傳輸帶寬應該會很有趣，比如採用512 GB甚至是1 TB的堆疊HBM3內存。我知道這樣的組合成本會高出天際，但這應該也能省下一些GPU吧？
Nidhi Chappell: 有趣的是，在某些情況下，模型是可以適應內存的，所以內存並不是瓶頸。我還是覺得增加GPU數量更有意義，因為這樣能加快處理速度。我們可以降低精度、觀察稀疏性、尋求將模型引入GPU的不同方式，藉此摸清自己到底需要多大的內存帶寬。
但可以肯定的是，模型訓練的時間越長、所使用的數據集越大，模型的精確度就越高。所以真正的目標就是用更大的數據集進行更長時間的訓練，結合大量參數來改善收斂效果，讓最終成果能夠更加精確。正因為如此，我們才需要更多的GPU，這樣基礎設施就能適應更大的模型、更大的模型又能帶來更精確的結果。
主持人： 在運行OpenAI GPT-3或GPT-4的時候，你觀察過GPU的資源利用率嗎？雖然微軟不一定要買，但Hopper GPU的售價確實定在了2萬到3萬美元之間，用戶肯定希望儘量提高資源利用率、讓它物有所值。
Nidhi Chappell: 您確實非常了解HPC領域啊。我來打個比方，在HPC中執行同步作業時，會大量占用CPU。AI也是如此，這是一項高度要求同步的工作，每個GPU都會得到充分利用。這又回到了系統架構問題，只要系統架構能保證網路不成為瓶頸，那麼GPU的利用率就會非常高。現在的情況也確實如此，它的工作非常協調，所以這些昂貴的資源維持著很高的利用率。我們當然不能讓它閒著，對吧？我們也在確保維持很高的利用率。
主持人： 再來比較H100和A100，它們的差別就是用2到2.5倍的成本來購買3倍的性能。對於沒有大規模負載需求的用戶來說，A100就足夠了。A100 GPU也做了自己的設計取捨，犧牲的就是一部分速度。換言之，只要願意花更長的時間來訓練模型，那整個成本就會更低。類似於整個訓練周期要持續3個月，但訓練成本只相當於原先的一半。
Nidhi Chappell: 所以微軟才會提供一系列產品組合。有些客戶在開發基礎模型時對性能更加敏感，他們就更適合使用Hopper、享受微軟提供的規模化基礎設施資源。但也有些客戶更適合用A100進行微調或小規模訓練/推理。A100不會過時，它只會被重新投入其他工作，因為它會落入新的價格點、再次找到適合自己的對應市場區間。
