原文地址： http://petuum.github.io/papers/eric_bdtc2014_transcript.rtf
Slide地址： http://petuum.github.io/papers/eric_bdtc2014.pdf

2014-12-14 CSDN
【CSDN 現(xiàn)場報道】2014年12月12-14日，由中國計算機(jī)學(xué)會（CCF）主辦，CCF大數(shù)據(jù)專家委員會承辦，中科院計算所與CSDN共同協(xié)辦，以推進(jìn)大數(shù)據(jù) 科研、應(yīng)用與產(chǎn)業(yè)發(fā)展為主旨的 2014中國大數(shù)據(jù)技術(shù)大會 （Big Data Technology Conference 2014，BDTC 2014）暨第二屆CCF大數(shù)據(jù)學(xué)術(shù)會議在北京新云南皇冠假日酒店盛大開幕。

2014中國大數(shù)據(jù) 技術(shù)大會首日全體會議中，卡耐基梅隆大學(xué)教授、ICML 2014程序主席邢波帶來了名為“A New Platform for Cloud-based Distributed Machine Learning on Big Data”的主題演講。期間，邢波表示，著眼當(dāng)下大數(shù)據(jù)處理平臺，大量資源都都浪費(fèi)在集群的通訊同步上。即使比較優(yōu)秀的平臺，計算時間也只有20%，通訊時間 占到80%，就比如Hadoop的通訊時間占到90%甚至更高。

卡耐基梅隆大學(xué)教授、ICML 2014程序主席 邢波

以下為演講實(shí)錄：

我首先感謝大會組委會邀請我來給這兒做一個報告。我這個報告風(fēng)格可能跟以前幾個不一樣，干貨比較多，比較枯燥，有一些正規(guī)的實(shí)驗(yàn)結(jié)果，甚至有一些數(shù)學(xué)公式，另外我也很樂意分享一下剛剛從學(xué)生那得出的結(jié)果。

我想討論一下用于大數(shù)據(jù)的分布式機(jī)器學(xué)習(xí)運(yùn)算的平臺。當(dāng)我們面對大數(shù)據(jù)，大家首先問到的問題通常是，我們從大數(shù)據(jù)里面能挖到什么東西，大數(shù)據(jù)到底有什么用？這個問題大家已經(jīng)看到了很多展示，這塊就不再重復(fù)或者追加。

我 這兒希望能夠講一個更加看似無趣但是基本的問題，如何來進(jìn)行大規(guī)模的大數(shù)據(jù)運(yùn)算，如何把它做對。這個原因是？現(xiàn)在數(shù)據(jù)量如此之大，隨之而來關(guān)鍵的問題會是對數(shù)據(jù)的 正確理解，而這里邊的工具到底是什么呢？至少在我們計算機(jī)學(xué)家目前的經(jīng)歷來看，很多人同意機(jī)器學(xué)習(xí)和它代表的統(tǒng)計學(xué)習(xí)的算法可能是一個對數(shù)據(jù)進(jìn)行有效挖掘 的途徑。

我這里就要探討一下如何把這個工具過渡到大數(shù)據(jù)的平臺上，而這個“大”字對以前的研究產(chǎn)生什么影響？有必要強(qiáng)調(diào) 一下這個問題的重要性。 現(xiàn)在有很多對大數(shù)據(jù)的忽悠，很多文章都會說數(shù)據(jù)就是金錢，有很多數(shù)據(jù)的話你就變得很有財富，甚至你變得非常聰明。但如果沒有一個很好有效體系對這個數(shù)據(jù)作分 析，其實(shí)數(shù)據(jù)不等于知識：就像森林里面倒下一棵樹，你沒看到的話，它倒沒倒下，你并不知道。今天我就講這些技術(shù)型的問題。

為什么大數(shù)據(jù)的機(jī)器學(xué)習(xí)挖掘比較困難，首先數(shù)據(jù)量變大，挑戰(zhàn)了存儲、通訊，甚至處理的極限，所以你要把它分布到一個大的多機(jī)的數(shù)據(jù)中心去而不再僅是單機(jī)上。但是其實(shí)挑戰(zhàn)不僅僅是這一些，當(dāng)數(shù)據(jù)變得很大的時候，你的問題變得很復(fù)雜，需要聰明大腦和聰明的模型理解。

大 家在大型公司里面用到的模型有幾百幾千個億的參數(shù)，從單機(jī)里面溢出需要并行處理，想把這步做對并不是簡單的問題，這就涉及到第三個問題，這些軟件包工具到底在哪兒？你可能看 到剛才講解者展示IBM的系統(tǒng)，余凱先生下面會展示百度的系統(tǒng)，大數(shù)據(jù)的問題目前都是大型企業(yè)他們專屬權(quán)利，而比較屌絲級別的公司或非IT公司就沒有辦法處理，是不是這樣的局面無法撼動？我想大數(shù)據(jù)工具庫普及變得非常好用情況就會改觀。

大數(shù)據(jù)工具庫不能僅包括簡單的工具諸如決策樹，kNN，這些工具都有20、30年的歷史還在用但并不是很有效；我們要的高大上的工具，深度學(xué)習(xí)、話題模型、協(xié)同過濾這些東西在很現(xiàn)代的文獻(xiàn)里面出現(xiàn)，開始被很高級的公司積極使用，他們到底有什么樣的一些技術(shù)上的挑戰(zhàn)，防止普通人或者更多大公司使用？

我這里要提出一個問題：當(dāng)你這個數(shù)據(jù)或者是模型大到了從一個機(jī)器內(nèi)存里面溢出，大家希望顯然是這么一張曲線：我不斷加機(jī)器，越加越多能力越高，這是大家的期 望。如果各位開發(fā)人員尤其工程人員有實(shí)際經(jīng)歷，我想你會告訴我，當(dāng)我給你一千臺機(jī)器后你的能力并沒有增加一千倍；機(jī)器有很多的時候，你的資源中各種各樣的時間浪費(fèi)在沒有用處計算上，比如說通訊、等待、協(xié)調(diào)這些方面。因此我們看到的一個曲線是這樣的一個曲線－－我們實(shí)際收獲的計算能力并不隨機(jī)器增加而增加，而是很快封頂了，甚至跌落了。對于計算機(jī)學(xué)家來說，固然去拿大數(shù)據(jù)來做挖掘，提供信息，親自做一個數(shù)據(jù)挖掘選手很重要，但是我覺得 計算機(jī)學(xué)家另外一個很重要的任務(wù)是提供方法論和工具，把這個曲線從這兒提到這兒，這就是我待會講話中心內(nèi)容。

我為什么說現(xiàn)在已有的系統(tǒng)不足以實(shí)現(xiàn)我們剛才所希望的功能呢？這塊我舉幾個例子。比如說有很多機(jī)器學(xué)習(xí)的學(xué)者，他們顯然對大數(shù)據(jù)很感興趣，由于本身訓(xùn)練局限或者是 習(xí)慣思維緣故，他們對系統(tǒng)知識通常并不了解，他們看到一百個機(jī)器跟一臺機(jī)器的差別只不過乘了一百，中間的代價或者是機(jī)器的失效幾率他們可以都不太考慮，所以他 們的算法主要是針對數(shù)學(xué)上的正確性或者是迭代算法迭代次數(shù)減少性，但是他們不會鉆研這個算法到底在一個真實(shí)的機(jī)器群上怎么運(yùn)作；他們會寫這么一個程序，中間 有一句話：“并行運(yùn)算”，然后就天真的假設(shè)這個就開始發(fā)生了，把這些算法程序放在很多機(jī)器上它們就能算好。

實(shí)際過程中，我至少看到是這樣一個情況，你去做一個小實(shí)驗(yàn)，去測量用在計算上的時間和用在通訊上的時間，最好結(jié)果也無非如此：至少20%的時間花在機(jī)器上面，80%的時間花在等待，經(jīng)常更糟，上面提到那種理想狀態(tài)不存在，所以這些算法實(shí)際上通常無法應(yīng)用。

另一方面，系統(tǒng)工程師對機(jī)器學(xué)習(xí)或者統(tǒng)計學(xué)習(xí)原理或者技術(shù)并不見得非常精通，他們所需要實(shí)現(xiàn)的目標(biāo)是盡可能實(shí)現(xiàn)極高的迭代的輸出，修正由于機(jī)器造成的一些損耗，所以他們會發(fā)展 一些非常可靠、非常高通的技術(shù)。但是他們對于機(jī)器學(xué)習(xí)的算法通常是做了一個非常簡單的假設(shè)：我只要把它能夠跑起來，它肯定能跑對，肯定會收斂。如果系統(tǒng)中還有一 個特殊編程模型，比如Spark里面有一個RDD，GraphLab中有一個節(jié)點(diǎn)模型（Gather-Apply-Scatter），他們就會假設(shè)，無論什么機(jī)器學(xué)習(xí)的算法都可以轉(zhuǎn)換成這么一個模型，這是工程師的任務(wù)。我就不知道各位工程師有沒有試過把話題模型變成RDD或節(jié)點(diǎn)模型，這是很困難的，需要對機(jī)器學(xué)習(xí)原理有深刻掌握才能做到。因此你看不到復(fù)雜機(jī)器學(xué)習(xí)在這些系統(tǒng)上的普及應(yīng)用。

所以系統(tǒng)方面的工作通常簡化了在機(jī)器學(xué)習(xí)理論上的工作，把它變得理想化，最起 碼會造成一些資源上的浪費(fèi)，但更嚴(yán)重會造成算法本身的失敗會發(fā)散，你得到結(jié)果并沒有用處。所以總結(jié)一下，由于兩方面領(lǐng)域間的隔閡，通常我們在開發(fā)已知系統(tǒng) 對對方的框架都產(chǎn)生了比較簡單化的假設(shè)，實(shí)際工作中你喪失了很多機(jī)會，也造成了很多錯誤。

理想狀況下有這么一個途徑， 你有很多任務(wù)和各種硬件設(shè)備，咱們中間有一個普世的算法或者框架，然后這個框架上能夠來支持所有這些機(jī)器學(xué)習(xí)的軟件，然后使用所有已知的硬件，中間這層機(jī)器之間的協(xié)調(diào)、通訊或者是錯誤處理應(yīng)該是被抽象化被自動化，作為一個程序員我們不應(yīng)該掌握去觸碰這些東西。

這個問題到底是在 什么層面上能夠獲得解決呢？我首先想指出這絕對不是一個軟件的問題，在設(shè)計打造這樣的一個界面的過程中，你不僅要懂得系統(tǒng)設(shè)計也要懂得機(jī)器學(xué)習(xí)的理論，而且還要懂得算法的設(shè)計，所以整個需要的技能是相當(dāng)龐大的一個技術(shù)支持。所以這也就造成了這種問題的困難性，而且它就說明并不是所有人去碰這個問題，風(fēng)險很大，回報率并不是很高，但總有人在做這樣的事情，有人開發(fā)類似的操作平臺或者框架。我們CMU的團(tuán)隊正在開展這樣的工作，我待會想跟大家分享一下開發(fā)框架中比較有意思的思路和得到的經(jīng)驗(yàn)教訓(xùn)。

這里首先要研究設(shè)計分布式的策略，怎么做分布。當(dāng)你有多臺機(jī)器的時候，顯然把任務(wù)分布到每個機(jī)器上去，每個機(jī)器往前走，把中間結(jié)果存在局部的存儲空間，他們完成的時間并不是一樣，保證程序正確性你需要設(shè)置等待集合點(diǎn)，每一臺端點(diǎn)工作機(jī)和那個叫做服務(wù)器頭領(lǐng)機(jī)握手協(xié)同后可以接著往下走。機(jī)器學(xué)習(xí)算 法有這么一個特點(diǎn)，不是一次性，需要反復(fù)進(jìn)行迭代，這樣就造成困難，在你選擇對于系統(tǒng)的行為采取不同的措施的時候，它會產(chǎn)生不同的結(jié)果，有些結(jié)果就是像這樣，很多時間浪費(fèi)在通訊上面，或等待所有端點(diǎn)完成協(xié)同，這能保證你的結(jié)果很對，它很慢，但是對。另一種方法我把通訊協(xié)議可以簡單化，讓它不必等待彼此，有時候會得到一個很快的結(jié)果，但 這種結(jié)果經(jīng)常是一個發(fā)散的不正確的一個結(jié)果。

Hadoop，在過去被大家認(rèn)為是一個適合寫并行程序的平臺，但是 Hadoop對機(jī)器學(xué)習(xí)的算法是不是真正適合呢？我不知道各位在自己開發(fā)過程中有這樣的經(jīng)歷，我自己在學(xué)校里面或者Facebook做訪問教授的這方面的經(jīng)歷是相當(dāng)悲慘：你在Hadoop掌握了一千臺機(jī)器，你來寫一個Hadoop的項(xiàng)目，但中間硬盤讀取等等的瓶頸會極大程度限制了程序有效性，當(dāng)你有很多機(jī)器的時候， 彼此之間很難同步，大部分時間發(fā)生在等待里面。硬盤讀取是相當(dāng)昂貴的操作所以會耗費(fèi)大量時間，經(jīng)常造成程序相當(dāng)難往前推進(jìn)。

我們從這個地方出發(fā)，怎么來解決這個問題，是相當(dāng)有意思的一個問題。這塊為了表達(dá)我們的思路，有必要稍微展示一下到底機(jī)器學(xué)習(xí)的神秘性或者它的特點(diǎn)在 哪兒？跟普通的程序有什么區(qū)別？我嘗試了一下做了比較。通常寫計算機(jī)程序希望是一個精密的執(zhí)行，就像我搭一個樓，把一個藍(lán)圖精密到按步驟進(jìn)行實(shí)現(xiàn)，這樣保證這個樓能搭起來，錯一步都不行。機(jī)器學(xué)習(xí)不是精密實(shí)現(xiàn)以前設(shè)定好的計劃，而是通常實(shí)現(xiàn)一個數(shù)學(xué)優(yōu)化問題，就像在體操里面有一個規(guī)定動作一個自選動作，爬這個山頂你可以從這條路爬， 也可以從那條路爬，所以有一種容錯性，有容錯性就給了新的機(jī)會。而且機(jī)器學(xué)習(xí)可以寫出這么個數(shù)學(xué)公式，達(dá)到最高點(diǎn)你可以用數(shù)學(xué)公式進(jìn)行評估，解決途徑通常可執(zhí)行迭代程序，迭代程序本身有自動收斂性的特點(diǎn)。

當(dāng)你在一定情況下進(jìn)行迭代，不管你迭代精度是特別高還是比較高，它都有可能收斂，這就造成了機(jī)器學(xué)習(xí)算法既難又簡單，關(guān)鍵看你從哪個角度解決。這里用容錯性做一個比較 ：比如說你在做一個排序，我們知道這個東西是不能容錯的，這塊如果錯了以后不改，最后結(jié)果是錯的。這是傳統(tǒng)計算機(jī)程序的普遍特點(diǎn)，一旦在某個結(jié)骨眼出了錯，你必須改。 機(jī)器學(xué)習(xí)算法的運(yùn)行，就像這個有點(diǎn)喝醉的家伙在爬山，雖然醉了，但知道山頂在哪兒，他看得見，腳還能走，多多少少還是能爬上去，不見得爬得那么快，或者每一步都向上，走錯了以后不一定要走回 去，還要重走，這個地方和傳統(tǒng)計算機(jī)程序是不一樣的。

還有數(shù)據(jù)和模型的兩相性，對于系統(tǒng)工程師，數(shù)據(jù)和模型并沒有什么區(qū)別，它都是在內(nèi)存里邊的一些數(shù)字而已，把它分割沒有問題，比如我有數(shù)據(jù)分在某一個機(jī)器上。我這兒有模型，模型指里面參數(shù)，比如神經(jīng)網(wǎng)絡(luò)參數(shù)可以把它分割，大了以后也可以做所謂的數(shù)據(jù)和模型并行。

在通常經(jīng)典的系統(tǒng)設(shè)計里面，這兩種并行沒有區(qū)別，有時候你會看到Hadoop和Spark不相區(qū)分的并行處理。但是如果你仔細(xì)觀察機(jī)器學(xué)習(xí)程序特點(diǎn)，你發(fā)現(xiàn)這兩種并行的結(jié)果很不一樣，當(dāng)數(shù)據(jù)被并行的時候，他們之間是不相關(guān)的，所以你不需要對他們之間進(jìn)行協(xié)調(diào)，需要對算出的分布的子結(jié)果進(jìn)行一定的協(xié)調(diào)，但在他們算的過程中你不需要進(jìn)行協(xié)調(diào)。

當(dāng)模型被并行的時候，它中間實(shí)際是相關(guān)的，所以你不在過程中進(jìn)行協(xié)調(diào)，最后結(jié)果就會出錯，所以這種情況下你會發(fā)現(xiàn)，你對數(shù)據(jù)并行對模型并行需要做不同的通訊和系統(tǒng)設(shè)計，還有其它一些東西我就不多討論。

我做一個總結(jié)，機(jī)器學(xué)習(xí)算法有它的獨(dú)特性，基于優(yōu)化的算法，而且用（遞歸）來實(shí)現(xiàn)，有一些容錯的能力，有一些動態(tài)結(jié)構(gòu)，然后它還是非同質(zhì)的，有一些參數(shù)會回歸很快，有些收斂很慢，你可以對收斂快做完停下來把資源另外使用，這都是要求編程員或者程序?qū)C(jī)器學(xué)習(xí)算法有一定的了解，這樣有一定的機(jī)會來進(jìn)行加速。而這種東西在傳統(tǒng)程序里面不存在，通常對于指令級的一個完全正確執(zhí)行，造成這樣很多技術(shù)上更多的措施，但在機(jī)器學(xué)習(xí)不見得很有必要。

看看已知的系統(tǒng)怎樣解決這個挑戰(zhàn)，大家都知道Spark實(shí)質(zhì)上是Hadoop的升級版本，一開始需要把程序，模型，數(shù)據(jù)轉(zhuǎn)換成一個叫做RDD的特殊數(shù)據(jù)結(jié)構(gòu)，它是在內(nèi)存中的，因而讀寫很快，后面迭代非常好。RDD保持一個過程樹，所以在運(yùn)算中如果出現(xiàn)問題很快找出問題所在，這都是RDD和Spark非常優(yōu)異的特點(diǎn)，特別在數(shù)據(jù)庫的處理或者非迭代的數(shù)據(jù)并行處理里面是非常有效的。

做模型并行要求全局性的一個協(xié)調(diào)，這樣就會產(chǎn)生一些很大的代價，Spark上沒有特別的機(jī)制來應(yīng)對這種需要。Graphlab，用節(jié)點(diǎn)圖來表示模型，數(shù)據(jù)，圖上的邊表示相關(guān)度的強(qiáng)弱，你可以依此寫成一個節(jié)點(diǎn)程序自動做一個非同步的通訊， 仍然保持這個程序最后能夠正確收斂。這也是一個很好的思路，在很多情況下都產(chǎn)生了比較好的結(jié)果，甚至比Spark還要好。但它也有一些問題，數(shù)據(jù)量變得非常大，程序會變得非常沉重，效率不是很高。

我們組正在開發(fā)這么一個平臺，叫Petuum，包含數(shù)據(jù)和模型并行兩套功能，也對機(jī)器學(xué)習(xí)的特點(diǎn)做了比較深入的一個研究，對他們做了一些針對性的使用，所以我們系統(tǒng)對機(jī)器學(xué)習(xí)內(nèi)部特點(diǎn)比較有針對性，他們有一些非常有意思的特性和功能，這塊我可以總結(jié)一下。

大致結(jié)構(gòu)是這樣，它包含一個參數(shù)服務(wù)器，大家都知道參數(shù)服務(wù)器，給你提供很好編程的一個共享虛擬分布內(nèi)存，大家在編程的時候不用對每個機(jī)器進(jìn)行單獨(dú)通訊；我們還有一個叫做調(diào)度器，它是能夠?qū)δＰ瓦M(jìn)行有效的分割，甚至是動態(tài)分割，然后做一個分布化和載量平衡。運(yùn)行原理就跟機(jī)器學(xué)習(xí)的工程師寫機(jī)器學(xué)習(xí)的算法基本一個思路，用迭代加上對公式的更新量的隨機(jī)性而不是確定性的反復(fù)刷新，跟傳統(tǒng)的是不一樣的。

這個參數(shù)服務(wù)器有這樣一個編程界面，你在寫內(nèi)存讀取內(nèi)存不需要對每一個機(jī)器做一個特殊的指令，而是用和單機(jī)讀寫形式上相似的通用指令。它使用了比較巧妙的所謂半同步的協(xié)調(diào)機(jī)制，這樣可以顯著降低使用在通訊上的時間，而加強(qiáng)在計算上的時間，所以你可以看到隨著我們半同步參數(shù)的調(diào)整，我們這個通訊時間會顯著下降，降到了以至于比計算時間還要少，這樣使計算機(jī)的資源得到最大量的利用。

在調(diào)度器方面我們也用了基于機(jī)器學(xué)習(xí)考量的設(shè)計，調(diào)度機(jī)自動發(fā)現(xiàn)機(jī)器學(xué)習(xí)模型里面的一些結(jié)構(gòu)，找出哪些參數(shù)是相關(guān)，哪些參數(shù)是不相關(guān)，然后對它們做相應(yīng)分布，他們在分布運(yùn)行的時候并不違反正確性、約束性，這樣也會造成更快的收斂。

為什么這樣做產(chǎn)生這樣好的結(jié)果？這里邊有一些比較深層的技術(shù)和科學(xué)原理，時間允許，我可以再講幾分鐘。并行系統(tǒng)是沒有理想的，我們當(dāng)有好幾臺機(jī)器，顯然不能希望它同步運(yùn)算同步通訊，即使相同的多臺機(jī)器放在機(jī)房里面溫度不一樣，行為都是不一樣的，最后結(jié)果就是我們看到這樣的情形。我們怎么來協(xié)調(diào)這樣的一個缺陷呢？ 通常對編程高手，當(dāng)然這不是問題，他可以對每一臺機(jī)器做深層操作，可以避開所有的陷阱，對于普通程序員和低端用戶，這種非常昂貴而且耗時開發(fā)過程并不見得能負(fù)擔(dān)得起，我們需要還是非常簡單的界面，讓界面下面的支持框架做了通訊上的決定，這個決定在數(shù)據(jù)并行過程中可以被總結(jié)成一個所謂的叫做協(xié)調(diào)或者是同步協(xié)議。這個同步協(xié)議我們大家都知道，這一端包括Spark或者Hadoop協(xié)議完全協(xié)同，然后往下走，這個東西在數(shù)學(xué)上可證明是對的，但是造成有效性的損失。

另外一種比較骯臟的結(jié)果，我不同步了，讓自己跑，對程序收斂性和正確性沒有任何保障。我們采取的方法是走一個中間路線，做一個半同步，讓機(jī)器在有限的窗口里做局部的運(yùn)算，用參數(shù)值的局部版本做一個運(yùn)算，不跟其它東西通訊，當(dāng)這個窗口被突破的時候，我就必須停下來等，每一個線程到達(dá)窗口邊界的時間是隨機(jī)的，所以最后結(jié)果是所有線程都可以在最大程度上使用窗口做運(yùn)算。我們關(guān)心的是，這東西顯然變得更快，就像非同步的東西，但能不能保證正確性？結(jié)果是這樣的，因?yàn)槲覀兪怯邢薜姆峭交蛘甙胪剑憧梢援a(chǎn)生一個證明，產(chǎn)生的收斂結(jié)果跟同步結(jié)果是一樣的。這是我目前知道的第一個對于這類操作系統(tǒng)做一個理論證明正確性的結(jié)果，這個系統(tǒng)有一定的理論價值甚至也是一個好的應(yīng)用價值。

然后它的編程界面是相當(dāng)普通的界面，你把不同的機(jī)器學(xué)習(xí)算法，像話題模型、矩陣分割或者是像線性或者邏輯回歸都表示成參數(shù)服務(wù)器這樣的表示，用這樣一個很簡單的高級語言來進(jìn)行操作。結(jié)果如何呢？我們發(fā)現(xiàn)在不同的程序上面我們都獲得了比這個同步或者是完全非同步 的方法更好更快和更佳的收斂結(jié)果。

再講模型并行，在數(shù)學(xué)上有一個更強(qiáng)烈的所謂的協(xié)調(diào)性的要求，這塊我想用一個線性回歸做一個簡單的闡述。通常我們做線性回歸需要估計參數(shù)，這個參數(shù)矢量是很高維的，也許100億維，在普通存儲機(jī)器里面放不下，或者放下以后用串行的方法來算很慢，所以你需要并行，那亂放行不行？最后發(fā)覺不行。在數(shù)學(xué)上可以獲得這樣一個形式：當(dāng)你隨機(jī)取兩個參數(shù)，當(dāng)你動用了其中一個參數(shù)，另一個參數(shù)，它的值和前面那個值相關(guān)，所以有一前一后要求，當(dāng)你把這兩個東西做并行，相關(guān)性就被破壞，而且無法收斂，這兩個相關(guān)度在數(shù)據(jù)上有關(guān)系所以可以做定量計算，所以當(dāng)兩個參數(shù)非常相關(guān)我們需把它們放在同一個機(jī)器上面，這是相當(dāng)昂貴的操作，理論上可通過畫出一個節(jié)點(diǎn)圖我們對每一對參數(shù)對做這樣的預(yù)估，100億維是很大的圖，是不可操作的。

我們在這兩種選擇里面，純粹圖分割或者隨機(jī)分割采取中間路線，我們可以想像參數(shù)里邊并不是所有參數(shù)都是同樣重要，有些東西重要，有些東西不重要，有些東西快收 斂了，我們采用一種方法對參數(shù)進(jìn)行大致評估，只對重要的東西進(jìn)行處理，這是基于結(jié)構(gòu)的并行化叫SAP，也可以用簡單的編程界面。這是一個操作，從某一個方程里面取樣，取一部分重要參數(shù)，對它結(jié)構(gòu)進(jìn)行分析，把它們向各個機(jī)器上做分布。

在第二個迭代里面，有可能結(jié)構(gòu)會出現(xiàn)變化，可以再重新做這一步，這是用戶之間的選擇。分布策略有很多可能性，剛才說優(yōu)先度的考量，哪些參數(shù)重要哪些參數(shù)不重要，你也可以做模塊化考量，把參數(shù)分成幾個塊，也可以做有保障的同步。

實(shí)驗(yàn)結(jié)果，我們做了良好動態(tài)并行實(shí)現(xiàn)很快良性收斂，不然如果用隨機(jī)并行就是不收斂或很慢的收斂，我們也有理論和實(shí)驗(yàn)證明，不光在均值，在方差上都有很好的收斂的保障。時間正好讓我講完了科學(xué)原理，我們也見到了結(jié)果，在不同算法上得到了很大的提升。我最后用幾張圖總結(jié)一下，現(xiàn)在大規(guī)模機(jī)器學(xué)習(xí)平臺整個環(huán)境地貌，這是相當(dāng)挑戰(zhàn)但是相當(dāng)讓人激 動的領(lǐng)域，有很多家在玩，我們是后來者。

現(xiàn)在在講大數(shù)據(jù)大模型你要是沒有幾十個億的參數(shù)就不用再談的。看看最近達(dá)到了什么結(jié)果，你可以看到有人用一萬臺機(jī)器達(dá)到一百億參數(shù)，做了話題模型的估計，你會看到其它的數(shù)據(jù)、神經(jīng)網(wǎng)絡(luò)或者對于話題模型都達(dá)到了類似的量級，大家的目標(biāo)是，我的機(jī)器越來越多，把模型可以做得越來越大，這是一個趨勢，有所投入有所收獲。把大量機(jī)器協(xié)同起來跑一個分布程序，是很了不起的成果。但同時你也希望把效率進(jìn)一步提高，這是我們匯報的結(jié)果，我們在最近做了話題模型和矩陣分解和卷積神經(jīng)網(wǎng)絡(luò)，看到他們的大小都已經(jīng)超過了現(xiàn)在目前在文獻(xiàn)里邊所匯報最大的結(jié)果，但是所使用的機(jī)器比現(xiàn)在的機(jī)器少一個數(shù)量級。下面還有展示速度上的提升。

我們跟微軟做了一個合作，他們用了24臺比較高端的機(jī)器，實(shí)現(xiàn)了10的12次方參數(shù)的話題模型，有一百萬個話題，每一個話題有一百萬個詞，這是目前所知道最大的話題模型，比非常有名的騰訊的那個peacock還要大了大概10到50倍，但我們用的機(jī)器比他們少很多。

最后總結(jié)：對于平臺或框架設(shè)計如果既考慮了操作系統(tǒng)原理，也考慮機(jī)器學(xué)習(xí)原理，你會得到很好的收獲。Petuum是開源項(xiàng)目，基于目前的觀察可以說，它不光可以達(dá)到很龐大的模型體積，基本上等價或優(yōu)于現(xiàn)在最好的系 統(tǒng)，而且在對機(jī)器集群大小和硬件指標(biāo)的要求，我們極大的降低了要求。講話前，剛剛收到學(xué)生最新從NIPS大會送來的結(jié)果，很讓我們驚喜：還有一個組知道了我們的系統(tǒng)，用這個系統(tǒng)跟Spark和GraphLab做了獨(dú)立比較，我很高興看到我們的收斂曲線達(dá)到最低最快，我想用這個結(jié)果來結(jié)束我的講座。最后大家可能會希望知道，到底Petuum系統(tǒng)到了什么程度，我們愿景既包含上層軟件，底層軟件，和生態(tài)界面的支持，成為目前在 Hadoop生態(tài)系統(tǒng)一個分子，你們可以把它下載以后做自己的開發(fā)，也可以使用我們庫中的軟件。

這個項(xiàng)目我最后要感謝我的同事和學(xué)生們在這兩年里面的支持，也感謝各位的關(guān)注，謝謝！