僅480塊GPU搞出萬億參數大模型！達摩院3個月打造，出手即商用_風聞

　　金磊 發自 凹非寺

　　量子位 報道 | 公眾號 QbitAI

　　不要6000張GPU！不要2000張TPU！

　　只要480，萬億參數大模型“抱回家”！

　　還沒完，更驚豔的在後邊。

　　同為萬億“體量”，能耗降低超八成，效率還能提升11倍。

　　當真有這好事？

　　沒錯，這就是阿里巴巴剛剛發佈的萬億巨模型M6。

　　用綠油油的“低碳版”來形容很是恰當了。

　　今年3月，M6作為中國首個千億多模態大模型發佈時，前OpenAI政策主管Jack Clark曾發文點讚道：

　　這個模型的規模和設計都非常驚人。

　　這次，萬億M6的問世又順利拿下了個中國第一——國內首個實現商業化落地的多模態大模型。

　　而且是離你很近的那種哦~

　　不僅是畫畫、寫作，你的支付寶、淘寶就在用！

　　自從大模型變得流行起來之後，它所具備的創意能力，一直是被世人所津津樂道。

　　例如OpenAI的DALL·E，給自家設計出來的公司門面，是這樣的：

　　風格多變、設計多樣倒是沒錯了。

　　甚至被網友們一度稱讚為“甲方剋星、乙方福音”。

　　但講真，要是拿到現實來商用，真的能hold得住嗎？

　　不見得。

　　單是從效果圖來看，字體扭曲便是一個大問題。

　　而要商用，圖片還需要一個非常硬性的要求——得夠清晰啊！

　　但DALL·E生成圖片的分辨率，卻僅為256x256。

　　那到了萬億參數規模，情況是否有所好轉？

　　直接來看下M6設計的作品效果：

　　不難看出，萬億參數大模型所生成的圖，在清晰度上有了較大的提升，分辨率直接翻倍，達到了1024x1024，放大後還能看清衣物紋理。

　　或許你會説，除了M6之外，目前國內外已經誕生了幾個萬億“體量”的大模型。

　　那阿里此次提出的大模型，又有什麼獨到的特點？

　　一大特點是，M6不僅公開了實現的詳盡細節、模型的收斂情況（詳見文末論文鏈接），而且還是國內首個實現商業落地的萬億參數多模態大模型。

　　還是以生成圖片為例，阿里已經初步將成果投入到了生產場景當中——阿里新制造平台犀牛智造。

　　目前，M6主要參與一些基礎款的設計。但可預期的是，隨着實踐經驗的豐富，M6的水平將不斷進化。

　　據瞭解，M6計劃在一年內生成上萬款高清服裝設計圖。

　　什麼概念？

　　這個數量就相當於一些快時尚品牌數百人設計團隊的年出款量。

　　再具體一些，結合大數據預測的潮流趨勢，M6可以實現快速設計和上身模擬，再經人類設計師進行篩選。

　　這麼一套流程下來，原本以月計的新款服飾開發週期，被壓縮到了以周來計算。

　　或許你會覺得這樣的商業落地，離自己太遠了。

　　不不不，M6還可能會出現在你經常用到的App哦——支付寶、淘寶。

　　懂“搜索”的人都知道，傳統的搜索過程就是，查詢語句與商品title的一個語義匹配過程。

　　但現在的年輕人搜索商品可不按照套路出牌。

　　舉個例子，他們會搜“凹凸的咖啡杯”。

　　其實他們想搜索的就是一種日式風格的咖啡杯，但商家可不會把這些細節寫進商品title中。

　　這時候，大模型就開始發揮它的看家本領了。

　　M6會根據商家提供的圖片，以及用户的查詢，做一個跨模態的搜索。

　　即使商家沒有在title中描述關鍵詞，M6可以根據圖片中的信息，然後推薦出你想要的產品。

　　這時候你又會説了，其它萬億參數大模型説不定也能做到！

　　或許可以。

　　但如果説，M6只燒了480張GPU就做到了呢？

　　而且能耗比之前已有萬億參數模型低了8成，效率還提升了11倍！

　　不僅如此，達到這種驚人效果，從千億到萬億參數規模，阿里只花了3個月時間。

　　3個月打造萬億參數模型，怎麼做到的？

　　首先要了解的一點是，3個月時間的工作，並非是一蹴而就。

　　早在今年1月份，阿里便推出了百億參數模型，而當時谷歌就已經提出來了1.6萬億參數的Switch Transformer。

　　谷歌能夠達到這個量級，所藉助的就是一個叫做MoE （Mixture of Experts）的架構。

　　於是，阿里從百億開始的“規模升級”過程中，便借鑑了這個架構，僅耗時2個月，便發佈千億參數大模型，而且只用了32個 V100 GPU。

　　不得不説，MoE這個架構確實好用。

　　它能夠做到的在擴展模型容量並提升模型效果的基礎上，不顯著增加運算FLOPs，這樣就可以實現高效訓練大規模模型的目的。

　　但阿里在卻在研究過程中發現了一個問題：

　　MoE負載不均衡。

　　簡單來説，原理是這樣的。

　　大模型常用到的Transformer分佈式訓練中，通常是各個GPU同一FFN層中，使用同一份參數。

　　而MoE就不同了，上述的這部分參數會在GPU之間共享，一份FFN參數被稱為1個“專家”（expert），每個GPU上將存放若干份參數不同的“專家”。

　　（如下圖中標紅框部分所示）

　　但阿里卻發現，在原來MoE的訓練過程中，非常容易只選擇top的幾位“專家”，這就使得頭部效應非常嚴重。

　　於是乎，阿里便對MoE的這個問題進行了改良。

　　研究人員對“專家”做了一個分組工作，即expert prototyping。

　　具體而言，先是把“專家”分成k個組，在每組中再進行top-k的操作（通常採用top-1，便於理解）。然後再將k組的結果進行組合，也稱之為k top-1。

　　這種方式實現上更直接簡便，並且允許組和組之間並行做top-k操作，更加高效。

　　例如在百億模型下游image captioning任務上，甚至能觀察到優於top-k的表現：

　　而且在阿里與谷歌交流過程中，谷歌的研究人員也認可了這種改良思路，他們認為非常精巧。

　　除此之外，算子精度也是阿里此次改良的工作之一。

　　谷歌在做Switch Transformer時，為了將模型體積壓下來，選擇了BF16。

　　但精度的降低會帶來非常大的技術挑戰，就是如何保證模型收斂的問題。

　　而且阿里還要做到“低碳版”，不能燒太多的GPU，因此相比谷歌在算子精度方面的工作，阿里可謂走了一條更加“極端”的路線。

　　具體而言，XLA優化、混合精度訓練、半精度通信等訓練效率優化技術，並採用了Adafactor優化器，成功在480張NVIDIA V100-32GB上完成萬億模型的訓練。

　　並且在訓練中，他們採用絕對值更小的初始化，適當減小學習率，保證了訓練的穩定性，實現正常的模型收斂，而訓練速度也達到了約480samples/s。

　　以上便是阿里“低碳版”萬億參數大模型的核心奧秘了。

　　而拋開技術本身，細品阿里在大模型的規劃路線，不免讓人產生另一個問題：

　　阿里為什麼這麼“急”？

　　從百億參數到千億參數，用了2個月。

　　從千億參數到萬億參數，用了3個月。

　　而且不同於其它大模型堆TPU、GPU，阿里選擇的還是一條極端的“低碳”路線：

　　千億參數模型僅需32張GPU，萬億參數模型只要480張GPU。

　　“急”，確實有點“急”。

　　但縱觀全球大模型的發展，阿里的這種“急”也就不難理解了。

　　谷歌1月份提出1.6萬億參數大模型Switch Transformer

　　英偉達的“威震天”4月份也對萬億參數模型進行了訓練

　　智源研究院於本月初發布1.75萬億參數大模型悟道2.0

　　……

　　除了萬億規模，這期間還穿插着像阿里、華為等大廠發佈的百億、千億參數大模型。

　　而更早的，谷歌的BERT、OpenAI的GPT-3等，可以説是開啓了大模型了一股熱潮。

　　好一副**“百家爭鳴”**之勢。

　　為什麼會這樣？

　　因為這是必然，是大勢所趨。

　　就好比十幾年前深度學習的崛起一樣，國內外各大廠商看到了這個技術的正確性。

　　於是紛紛前赴後繼地入局於此，各式各樣的深度學習模型不斷湧現。

　　現如今大模型的這種盛世，就與深度學習時代極其相似。

　　而且比起深度學習，大模型的迭代速度只會更快。

　　因為深度學習時代之下，並沒有出現很多應用場景。

　　但現如今，單是面向C端用户羣裏的大流量場景便應接不暇，搜索、推薦、廣告等等。

　　因此，在大模型的研發上，不僅僅是阿里“急”，可以説全球各大廠商和研究機構，都很“急”。

　　而從技術本身來看，大模型還逐漸浮現出了無限的創造價值。

　　簡而言之，就是在模型參數越發巨量的趨勢之下，模型可能會做到更多“意想不到”的事情。

　　還是以M6生成圖片為例，很多人會有一個質疑：

　　這些生成的圖片，會不會是拼接的，而不是真正意義上的生成。

　　據阿里內部人士透露，還真不是這樣：

　　它是真的有了認知和創造力。

　　最簡單的驗證方式，就是拿這些圖片去各種搜索引擎搜一下，結果定然是完全找不到。

　　除此之外，技術應當有益於人類的發展。

　　在這一點上，M6大模型還有計劃“上崗”助農扶貧的工作了。

　　具體而言，它將參與到幫助農民賣貨的一個環節，可以幫助他們快速設計包裝的logo以及各種IP衍生品。

　　而在此之前，這些環節的人力成本相對來説還是較高的。

　　綜上來看，大模型的發展迭代、落地，確實是一個很“急”，但又正確的大趨勢了。

　　……

　　最後一個問題，既然萬億規模參數已來，按照如此迭代速度，更大量級的大模型，還會遠嗎？

　　按現在的趨勢，答案是肯定的，只是時間問題。

　　但據阿里的介紹，接下來在大模型的研究工作中，不僅是要追求參數規模的迭代，更要追求通用性和商業落地。

　　那麼對於接下來的大模型，你期待了嗎？

　　論文地址：

　　https://arxiv.org/abs/2105.15082