飄天文學 > 文娛救世主 >第165章 別人搶破頭,誠哥看不上
    “未來人工智能時代的具體實現方式,就是利用人工智能的算法,在雲端計算大數據。算法相當於工業時代的加工機牀,數據就像是被加工的原材料,而云端計算能力則是驅動機牀的能源提供者。

    我的yy網絡科技,乃至螞蟻金服,乃至我其他一切平臺,核心的目的是實現內容推送的人工智能。我的人工智能要聽得懂人話,進一步發展到哪怕主人不說,也能猜到主人想要什麼的讀心術。然後解決找到主人想要的內容,然後給他這個問題。

    聽得懂,猜得透,找得到幫全人類做到這九個字,就夠我顧某人爲之奮鬥一輩子了。至於錢,於我如浮雲,我要那麼多有什麼用這裏面,的算法和大數據,是必須我親自解決的,但是背後的基礎設施,我不一定要親自搞。所以雲計算這塊,你們誰有興趣,願意去搞,我可以提供技術服務,或者入一點股份,幫你們搞。這個錢賺得不夠輕鬆,不是從0到1從無到有的錢,我不想受這個累。”

    顧誠最後給了一番高屋建瓴的結論,把自己的志向和心態剖析得非常清楚。

    只有從0到1的錢,纔有壟斷利潤,纔有絕對的暴利。那些從1到n的錢,只是成本大戰。或許未來早期的雲計算巨頭在優化效率上能夠比同行高一點,把成本壓得更低一些,從而賺到更多的差價但那也只是一點點差價。

    顧誠是內容產業的霸主,他沒空親力親爲。他只要確保這個基礎設施短板不會拖他的後腿,到了那個時代他想從外部買雲計算資源,能夠買得到,而且以足夠便宜的價格買到,就行了。

    就跟米國人沒必要親自跑去沙特狗大戶那兒挖石油,他們只要確保石油足夠便宜、能夠滿足米國的工業體系需求、不要再爆發一次類似於1973年石油危機之類的事件就行了。雖然挖石油也有可能很賺錢

    雲計算,就相當於4.0時代的“能源”。

    當然,顧誠不在乎親自賺雲計算的錢,不代表他不需要控制和監督雲計算。

    畢竟,未來的業務形態是“在雲端用人工智能算法處理大數據”,既然是“在雲端”,那麼yy系和支付寶系的大數據肯定是要傳到雲上去算的。這時候數據安全的問題就很重要,必須防止敵人暗中備份竊取。

    後世2017年6月爆發的阿狸系菜鳥物流和順豐快遞之間爆發的數據共享大戰,按照順豐方面的口徑,就是因爲“菜鳥物流以大欺着順豐把其大數據處理服務商和虛擬服務器託管從騰雲雲改成阿狸雲”。

    這一招背後,說實話,即使順豐真換了阿狸雲,阿狸雲也賺不到幾塊錢利潤順豐不算什麼大客戶。關鍵是那個時空2017年的bt之戰已經白熱化到了無所不用其極的程度。阿狸雲害怕菜鳥系中任何一個環節的數據放在騰雲雲上處理,會被暗中竊取備份。

    顧誠可以不賺雲計算的錢,但他必須確保幫他處理大數據的雲計算供應商不會威脅到他的數據安全

    就像米國允許沙特狗大戶這些小兄弟賺石油錢,但沙特必須保證米國的能源安全。要是歐派克再想搞個73年石油危機那樣的大新聞,米國人的航母艦隊會毫不猶豫開到波斯灣的。

    幸好,顧誠在阿狸也已經有24的股權了,他可以充分行使未來對阿狸雲運作的監督權限,派駐自己的專人跟蹤,防止非法備份。

    顧誠的野心之大,終於讓馬風和丁三石徹底看清了:顧誠的眼光跟他們不是在一個位面層次上的。

    馬風當機立斷拍板:“我願意投資搞阿狸雲計算,不過你得給技術支持。反正阿狸你已經有24股份了,將來賺了你也少不了好處。剩下的細節慢慢談吧。我們先去參觀一下你們公司的分佈式編譯服務器中心。”

    丁三石猶豫了一下,表示願意稍微投資參一股,但是無意主導這個生意。

    很顯然,丁三石那股大起大落之後養成的“人活着,最重要的是開心”毛病又犯了。聽顧誠說雲計算的錢賺着很累很沒門檻壁壘,他又懶得動彈了。

    也難怪這廝後來會去養豬。

    不是丁三石本人喜歡做的事情,他都是這麼懶洋洋的。

    yy網絡科技,研發部編譯中心。

    作爲國內如今最牛逼的互聯網公司,yy網絡科技的研發部從來不缺錢買最好的編譯服務器。

    從02年到04年,每年英特爾出了新的服務器用處理器,或者ib了新的機組,顧誠都會不吝重金採購,以至於就沒見過國內哪個同行的編譯中心機子性能比顧誠的公司好的。

    yy網絡科技的程序員們都是行業精英,他們的時間非常寶貴,怎麼能因爲寫完代碼或者自測修改後等機器編譯而浪費太多時間呢

    能夠多花100萬買服務器,讓每個程序員修完一塊代碼bug之後少等哪怕20分鐘的編譯時間,顧誠都是覺得值得的。

    然而,就在這個炎炎夏季裏,一些讓程序員們覺得不可思議的事情發生了。

    公司要求按照顧誠大致描述的那個拓撲結構,結合英特爾最新的多核cpu線程任務分佈思想,弄一個聞所未聞的“分佈式編譯架構”。

    所謂“分佈式編譯”,用外行人聽得懂的話解釋,大致是這麼個原理:

    在原本的編譯模式下,每次一段代碼要被編譯成程序時,都只會調用程序員本人的電腦cpu運算資源,或者他直接樹狀結構連接的那臺代碼服務器的運算資源,來進行編譯。

    但是在同一個網段裏面,並不是所有程序員的電腦或者代碼服務器的cpu都始終處於滿負荷運轉狀態。搞了“分佈式編譯”之後,可以把同事開着的、cpu閒置的運算資源也調動起來,一起幫助編譯,從而加快編譯速度。

    要是擱在後世,這玩意兒隨便找個編譯工程師都能搞定。

    問題是眼下才05年下半年距離歷史上這種架構方法在各大互聯網公司試水,起碼早了兩年多。顧誠幾乎是卡着一切必要硬件條件的門檻佈置的任務。

    當然,歷史上分佈式編譯在08~09年才成熟,並不是說更早技術上就絕對做不到而是更早的時候,大夥兒覺得這東西沒什麼價值。犯不着爲了省這麼點編譯時間,就去浪費那麼多程序員的精力專門架構這種結構。

    而歷史上的08年,阿狸開始運作“阿里雲”這些雲計算項目,分佈式計算的基礎研究已經做了很多,設置分佈式架構所需要的操作成本也大大簡化,國內各大公司赫然發現“誒原來只要這麼幾個小步驟,就能把閒置的電腦計算能力整合起來貌似還挺方便的”。

    注:我記得我第一份工作,在一滬江一個手機研發公司當碼農的時候,09年就搞過分佈式編譯。不排除其他行業更早,應該是08年就有了。


章節報錯(免登陸)