15 年前為雙11“渡劫”的技術，卻打通了AI的任督二脈

淺友們好~我是史中，我的日常生活是開撩五湖四海的科技大牛，我會嘗試用各種姿勢，把他們的無邊腦洞和溫情故事講給你聽。如果你想和我做朋友，不妨加微信（shizhongmax）。

15 年前為雙11“渡劫”的技術，

卻打通了AI的任督二脈

文 | 史中

快來吧奔騰電腦 就讓它們代替我來思考

1999 年，樸樹唱出了這句歌詞。

而后，時光把你我綁在刀尖，猛地刺穿新世紀的四分之一。無數孩子眼中的遙遠未知，眨眼已坍縮為大人的細碎回憶。

2025，我們短暫停靠在了 AI 站臺，回望迷霧，一顆子彈正中眉心：當年歌者的無心呢喃，竟是呼嘯而來的預言。

（一）困在船上的師傅

“10、9、8、7。。。”

隨著零點讀秒，又一年雙11開始沖刺，紅包如瀑宣泄，直播間吶喊起伏，快遞車連夜奔忙。

此刻誰也不會記起，15 年前，這群工程師曾經做過的另一次讀秒——淘寶的“爆炸”倒計時。

那是 2010 年“雙11”，眼看淘寶系統就要被 3 億剁手黨沖垮。在只剩 4 秒的時候，殺掉了一個數據庫，才保護淘寶這艘巨輪沒有被浪頭吞沒。

這就是很多人都聽說過的“驚魂 4 秒”的故事。

之所以要提起這個往事，是因為它不止代表阿里，也不止代表中國師傅，而是代表了整個人類在 15 年前面臨的技術困境。

話說，人類發展有一個穩固的底層邏輯：犯懶——總想用能源驅動工具來替代自己的勞動。

具體到計算機這個工具，主要是用來替代人類的“腦力勞動”。比如最早在軍事上替代人類彈道計算員，后來在能源勘探上替代人類地質計算員。

這是美國第一顆人造衛星“探險者 1 號”使用的計算員，是真正意義上的 Computer。根據圖靈的定義，計算員是“遵循固定規則，無權在任何細節上偏離這些規則的人”。

那在當時的淘寶系統呢？主要替代兩類人：

一類是前臺“售貨員”，剁手黨點什么商品，就給 TA 看什么商品，再推個購物車跟著。

一類是后臺“會計員”，負責把下單的價格、數量、型號都記錄清楚，后續好給人家發貨。

在 2010 那個時間點上，它倆代表了兩種經典計算架構：

這“售貨員”跑在小巧的 x86 服務器上。救它相對還容易，因為服務器有點兒像隔斷船艙，這個船艙塞滿了，可以找另一個稍空的船艙借點兒地方。

可即便如此，騰挪還得靠人。這邊嘴上吼，那邊手上敲，稍微手慢一點就會掛掉。

這“會計員”就更難救了，它跑在一整套*專用*的軟硬件系統，由 IBM 小型機、 Oracle 數據庫和 EMC 存儲系統組成——這就是大名鼎鼎的“IOE”。

“IOE”好比輪船的輪機室，總共就這么大的功率，商品庫、交易庫、用戶庫，所有庫擠在里面一同施壓，要想不爆炸，只能關掉一些系統。

直說吧：彼時這倆“賽博牛馬”，都已經不太稱職了，這對人類這個老板來說是災難。

你也許沒當過老板，但肯定打過游戲，用上一關的武器對付下一關的 BOSS，會極其吃力，甚至完全失效——BOSS 的毒打會逼迫你尋找新的武器。

就在歷史的巨大縫隙面前，一支敢死隊出發了，他們的任務就是：從虛空中悟出一種新武器，能夠打敗“雙11”這個大 BOSS。

這個新武器，絕不能再像孤懸海上的船，有沉重的輪廓阻擋擴容；而是要飄在云端，像金箍棒一樣收放自如。

它就是阿里云的基礎技術——彈性計算。

注意，這個彈，絕不能是“人肉彈”，而是要在賽博空間建立一套*工業流水線級*穩定可靠的系統，自動感知及反應微小的顫動，毫秒級就把計算力調度得纖毫不差的彈！

阿里云的第一行代碼

敢死隊手握一紙計算獨立宣言：

不僅要讓計算從（美國定義的）傳統軟件時代的 IOE 體系里獨立出來；還要從（中美共同定義的）互聯網時代造就的“軟件直懟硬件”的框架里獨立出來！

“一次跨兩代”，相當于從封建社會直接邁入社會主義。難度有多炸裂，簡直不敢想。

你或許不知道，從起草計算獨立宣言，到彈性計算的旗幟高高飄揚，中間已經歷了漫長的 5000 多個日夜求索。

你或許不知道，“獨立”并非終點，計算系統對智能的模擬越來越深刻，竟然創造出了智能本身——AI。

但阿里云這群瘋子早就知道，從出發的那一刻就知道。

今天，中哥就借著彈性計算團隊的故事，科普一下這段中國師傅的十五載硬核征程。

（二）彈性計算就像炒菜

講故事之前，咱們不妨先來點兒暴力——撬開機箱蓋子看看里面。

都說治大國如烹小鮮，依我看，彈性計算也如廚師炒菜。

每一個機箱里，都有一個廚師，他就是廚房的靈魂，CPU； 廚師切墩、炒菜的過程，就是計算； 廚師炒菜用到的爐灶、鍋盆、調料，就是軟件； 不時有食材送進來，也有炒好的菜送出去，這些都是數據； 而傳菜的窗口，就是網卡； 當然廚師還會把一些食材、半成品放進冰箱儲存，這個冰箱就是硬盤；

這樣幾百萬、幾千萬個廚房組織在一起，所形成的巨大的“炒菜能力”，就叫——計算力！

了解了如上的比喻，你自然會得出結論：

所謂宏觀上的計算彈性，其實就是微觀上廚師聽話的程度。

想想看，如果你有辦法在*短時間內*精準改變*每個廚師*的任務狀態：

例如，讓某幾百萬廚師從待命變成顛勺，讓某幾十萬廚師從炒菜變成往冰箱儲存，讓某幾萬廚師從做魚香肉絲改成做法式蝸牛，讓某幾個廚師從切絲變成切條，不就等于能讓計算力瞬間變大變小，隨意調度了嗎？

這里有大難題！

廚師一直待命，但它不能憑空炒菜，需要很多“家伙事兒”，這些就是操作系統和軟件。而且根據炒的菜系不同，家伙事兒也不同。

但給電腦裝過系統的都知道，安裝不僅慢，而且還得根據硬件不同選擇版本，不可能在短時間內完成。

誒，那時業界老師傅已經想出一個方法——在廚房里再做一個廚房。

具體分三步：

1、根據任務不同，把需要的設施都打包裝修在一個個“小樣板間”里； 2、樣板間是一個隔絕的小世界，可以隨意挪動，也可以快速克隆； 3、炒菜任務來臨時，只要提前一兩分鐘把一堆樣板間 Ctrl+V+V+V... 放進無數廚房里，就可以開干了！

沒錯，這個樣板間就是“虛擬機”。

有了虛擬機，大廚們再也不能以“廚具沒備好”為理由摸魚了，來活兒就得乖乖接。

別急，大廚們的“好日子”才剛來。

由于虛擬廚房很小，一個廚房里可以塞進很多個虛擬廚房，這意味著一個廚師可以*同時*照顧很多道菜：在這邊炒兩下青菜，去那邊翻一下烙餅，再去那邊拍一拍黃瓜。

把不同的任務穿插起來，完美壓榨廚師的時間，真是牛馬看了會落淚啊！

正因有了虛擬化技術，計算這件事被成功推上了工業流水線：廚房（在調度層面上）被連在一起，組成*中央廚房*！

這就是“彈性計算”最初的模樣。

手握錘子，趕緊砸釘子：老師傅開始大規模使用彈性計算替代“前臺的售貨員”，果然效果拔群。

同樣的硬件設備，因為“廚師”空閑更少了，相當于模擬出更多的售貨員。（你品一下）

就像這樣↓↓↓

然而！他們比劃了半天，發現這“后臺的會計員”還是沒辦法彈。。。

原因跟“工種”有關。會計員負責算數，哪怕算錯了一分錢，記錯了一筆訂單，都是重大事故。

這個活兒相當于讓廚師們做滿漢全席給老佛爺吃，但凡有地方鹽多了、醋少了，都是掉腦袋的罪過。

當時虛擬化加持的彈性計算系統，根本做不到這么穩定。（至于原因，我們在下一章詳解。）

好不容易研發了彈性計算，卻不能一把實現“計算獨立”，未免有些沮喪。。。

不過羅馬不是一天建成的，眼前至少還有個好消息：

就在這個階段，互聯網行業崛起了一個新的“工種”——數據研究員。數據研究員負責從海量的數據里提煉特征，為不同類型的用戶和商品都打上標簽，以備后續推薦。

沒錯，這就是：大數據系統。

在 2015 年以前，很多國民應用的爆火，最大的功臣都是大數據加持的“猜你喜歡”系統。比如手機淘寶、今日頭條、微博，不斷推給你感興趣的商品或內容，才牢牢抓住你。

多說一句，別看“大數據”和“數據庫”都帶“數據”，實際上大數據系統的只是做定性分析，偶爾算錯一個數，或者算得慢一些，都無妨大局。

就以當時最主流的大數據系統 Hadoop 為例，你可以極簡理解為：它就是用一套公式，把數據庫里所有的數都算一遍。

而 Hadoop 的創新在于，它能把這種計算拆分成無數獨立的小計算。小計算的結果捏合起來，就能得到最終結果。

這，不正適合新生的彈性計算系統么？

每一個小計算，都能放在一個（大廚房里的）虛擬廚房里。

每天人類下班以后，“賽博廚師們”就上班，把這一整天新增的數據都給“炒熟”。

就像醬↓↓↓

那幾年，阿里巴巴內部的各個業務線，愛嘗鮮的老師傅都用“中央廚房”搭建了各自的大數據系統，這些師傅，后來好多也成了阿里云的悍將。

之所以要說“后來”，是因為有個歷史原因：最早阿里巴巴的底層技術團隊和阿里云的技術團隊分屬兩邊，后來慢慢合并的。（詳見）

那么，當時的阿里云團隊在忙啥呢？

他們忙著把彈性計算包裝成產品（ECS），系上蝴蝶結，滿世界尋找客戶，準備大庇天下寒士！

最初一批“寒士”，就是阿里巴巴收購萬網之后繼承過來的中小網站們。

中小網站，和淘寶這種網站比起來，那簡直是螞蟻 VS 大象。

很多小網站全部代碼只需要一個虛擬機就能跑起來，而且一天也沒幾個人訪問，相當于廚師們都閑著，就算底層的彈性計算的架構“不結實”，也不至于出問題嘛。

阿里云的師傅們開始樂觀了，小網站行的話，那大網站行不行？網游行不行？政企行不行？

現實的毒打馬上就來了。

（三）煩惱的源頭：“打擾稅”

話說，在轟轟烈烈的“計算獨立運動”中，涌現了一批掃地僧，專門負責“搬家”，也就是協助各個業務搬到彈性計算上。

楊曦就是其中一員。

他有點像老中醫，一個系統擺在面前，他把把脈，就知道目前的彈性計算的能力夠不夠支撐，從而決定是現在上還是等等上。

在他和同事的努力下，每一年“雙 11”都有更多的淘寶模塊被搬上彈性計算，不再忍受“人肉云計算”的煎熬。

阿里云彈性計算產品解決方案負責人 楊曦

2014年，組織上看中了他的醫術，調他來阿里云幫一幫外部大客戶上云。

楊曦一來，才發現這是個坑。。。

外部客戶不像阿里同事那樣，把自己的業務系統全都拆開摸索著上。人家手里的是售貨員、觀察員、各種員長在一起的“連體系統”，要上就一起上！

這樣的系統在彈性計算上能跑明白嗎？

兩個字：看命。

楊曦記得，當時手游剛剛開始火爆，有很多游戲廠商面臨和“雙11”類似的難題，一做推廣促銷，服務器擴容就跟不上，結果浪費金錢、浪費大好機會。

他們聽說阿里云這個老中醫專治“雙11”，滿懷期待用了彈性計算。結果計算力倒是有彈性，可負載一重，系統就*隨緣*出 Bug。。。

Bug 不怕，怕的是隨緣——老師傅就像原始人看見雷公電母那樣無助。

所有故障都指向一個地方：虛擬化系統。

上一章我答應你，要講講不穩定的具體原因。現在咱們開始：

一個廚師，面對眼前的五個虛擬廚房里，最難的是啥？當然是掌握每一個廚房的進度，在各個任務里精準地*切換*。

為了切換，他得有個日程表，而日程要靠“規矩”來定。

我隨便編幾個規矩你感受下：1）某個灶上的水開了，就要趕緊中斷其他任務，跑過來下餃子；2）某個爐灶里的菜冒煙了，就要趕緊中斷其他任務，過來翻炒。

像這樣的規矩有好多條，它們編成了一個厚厚的“操作手冊”，這個手冊就是“虛擬化架構”，它放在一個桌子上，也就是“宿主操作系統”。

廚師每炒幾下菜，都得坐回到桌子前面，對照手冊算一下，確定接下來該操作哪個爐灶。

這種情況，其實無法保證菜不糊，因為“確定下一步”這個動作本身，就會占用廚師的時間和精力。

假設：同時五個廚房都在進行步驟很復雜的菜，廚師為了搞清楚下一步該給哪個廚房做，要在桌前算很長時間，這邊剛搞清楚，那邊的菜已經糊了。。。

這下你知道，為啥負載一重，虛擬化系統就愛崩，而且還隨緣崩了吧？

阿里云趕緊滿世界貼告示“重金求子”，如今的阿里云彈性計算通用虛擬化負責人，大神沈益斌就是這個當口加入團隊的。

沈益斌還記得，當時他們幾個師傅使出畢生絕學，把各種能想到的情況都做成精巧的補丁，打在系統里，給虛擬化架構續命。

到后來補丁摞補丁，也摞不動了，他們只好采取“惹不起，躲得起”的六字方針：主動幫客戶定時釋放內存，或者監測到哪個地方負載高了，趕緊把一部分“虛擬廚房”遷到提前準備的“備用服務器”上。

就這樣，云計算又硬生生退回到了“人計算”。

人是最不靠譜的動物了。

即便用人來填，到后來也不好使了：移動互聯網方興未艾，不到半年，客戶負載密度又提高了十倍。這時你要保證不出事兒，就得準備十倍的服務器放在那準備騰挪。這么多服務器，用裸機都能支撐業務峰值了，還“彈”個毛線啊。

老師傅被逼到了懸崖邊。

2015年，團隊下定決心，玩命跳向對岸，重構所有的虛擬化代碼，從 Xen 架構到 KVM 架構。

他們跳過去了：KVM 這個新的操作手冊輕巧多了，廚師不用每次都跑回桌子前面，而是可以帶在身上，隨時拿出來算一算下一步該干啥。

這一下，一般的重負載，彈性計算都能繃住，絕對不抽了。

眼看阿里云上外部客戶罵聲能歇一歇，淘寶也能再挑出一部分負載較重的系統上云了。

老師傅擦著汗，給自己偷偷點了個贊。

之所以偷偷，是因為他們心里都清楚，更換虛擬化引擎，最多能頂個三年五載，但絕不會是終點。

因為搬家師傅楊曦已經幫他們試過了，即便最新的 KVM 引擎能承擔很多重載，卻仍舊沒辦法支撐“雙11”狀態下滿負荷工作的會計員（數據庫）。

這到底是為啥呢？因為數據庫在滿載時有個缺德的特點：“高 I/O”。

還用廚房舉例吧。數據庫的基本功能可以抽象為兩件事：存一個數（I），取一個數（O）。這就相當于讓廚師把食物放冰箱，以及從冰箱里取食物。

在“雙11”這種情況下，它存取的頻率極高。

指令是發給五個虛擬廚房的，但實際只有一個廚師干活。。。

而且別忘了，這么多請求同時過來，他還得照手里的小本本算，先搞那個后搞那個。

每次“低頭+算一算+抬頭”的時間，就和它放一件東西在冰箱的耗時差不多長了。原本就緊張的時間，這下徹底不夠了！

你看到了沒，這里出現了一個死結：

要想實現彈性，就得有虛擬化；要想虛擬化，就會出現一個廚師對多個虛擬廚房的情況；只要廚師一對多，就涉及到日程切換；一旦編排日程，就得來回看本本；一旦看本本次數多，廚師的工作效率就直線下降。

這個死結有一個名字：虛擬化損耗。

而虛擬化損耗的本質，就是廚師“被打擾”產生的精力開銷。虛擬化損耗的本質就是“打擾稅”。

越是小而多的任務，打擾就越頻繁，打擾稅就越重。

別說沈益斌，就是天王老子來了，他也得交這個“稅”。可只要有稅，數據庫就交不起！

“計算獨立宣言”言猶在耳，難道說，彈性計算永遠無法一統山河，永遠要在土地上給傳統計算留一塊扎眼的“租界”嗎？

孔子曰：面對死結，最好的方法不是去解，而是找一把刀，把丫劈了！

（四）金箍棒鑄成！

我問你：有誰規定，編排廚師日程這個活兒，必須得廚師自己干？

當時老師傅被逼急了，也問出了一毛一樣的話。。。

你給廚師配個秘書，能死嗎？

這個秘書，就是后來救了所有人一命的神龍 CIPU。

秘書守在窗戶前面，舉著小本本，每每從窗口傳進來原料，他就直接幫廚師算好了日程。 廚師下一步要干啥，完全不用自己操心，可以兩耳不聞窗外事，一心只顧顛大勺。

這樣一來，打擾稅直接降到了“0”！

你可能會說：不對吧？這個活兒還在，只是換了個牛馬干啊。。。

誒，讓驢拉磨和讓狗拉磨，那效率可是天差地別。

CIPU 的總架構師楊航告訴我，CIPU 這個秘書生下來就是為了分配任務“定向培養”的芯片，它（在這個特定任務上）的計算密度是廚師的千倍萬倍。

2017 年云棲大會上推出這個專用芯片的時候，楊航完全沒想到一個月后世界云計算的公認領導者 AWS 也發布了同樣的玩意兒，他更沒想到，CIPU 的用處居然比他之前的設想更廣泛，更激進。。。

激進到啥程度呢？

激進到連“虛擬廚房”都可以拆了！

回憶一下，當初之所以要設立虛擬廚房，是因為啥？因為鍋碗瓢盆很難快速備齊對吧？

現在，老師傅掌握了另一套方案：

1）每個廚房都先安裝好基礎的爐灶、油煙機。（這不夠對付所有菜系）； 2）使用一種筐，把當前這道菜所需的專用工具和食材打包放在里面，從窗口biu~biu~biu~遞進去； 3）廚師不用挪地方，只管站在操作臺前，秘書把哪個筐遞到他面前，他就干哪個活兒！

這個筐，就是大名鼎鼎的“容器”。

當然為了復制和移動方便，最好別一次性把一道大菜的所有工具都裝一個筐里。你可以分在不同的筐里，相當于把一道菜的工序切碎，變成“微服務”。

就像生產線上打螺絲：每個廚師只做一小步，然后就傳給下一個廚師。他甚至不用知道自己在做啥菜，讓你切蘿卜就切蘿卜，讓你給鍋里放蒜就放蒜。

分布式炒菜，妥妥的。

既然廚師們在廣大的網絡中協作，秘書們就沒辦法自掃門前雪，而是要拉一個“秘書群”：任何一個秘書都要準確知道眼前這個筐里的食材從哪來，下一步要送到哪去。

換句話說，在云上協作體系中，秘書變成了和廚師一樣重要的角色，它成了云計算的基礎設施計算芯片，沒錯，CIPU 的全稱 Cloud Infrastructure Processing Unit 就是這個意思。

云霧中，“金箍棒”雛形初現：

1）有了容器，中央廚房具備了收放自如的彈性，瞬間變大變小； 2）有了 CIPU，廚師們可以在收放自如的前提下擺脫“打擾稅”，聚精會神在自己最擅長的炒菜上。此刻他們的效率，和在最早的“實體廚房”里是一樣的。

看著以上這倆特點，你意識到了什么沒？

沒錯，十年艱苦戰役，打擾稅降為 0，終于可以敲鑼打鼓把“會計員”（數據庫）請上彈性計算了。。。

更準確的說法是：終于可以把賬目交給云上的會計員去管理了！

就在 2020 年前后，阿里巴巴集團核心數據庫陸續搬上 PolarDB 等等自研云數據庫。

征服“會計員”之后，彈性計算徹底殺瘋了，已經沒什么“員”不能被計算力替代了。

比如現場促銷員，就是當時已經流行的“實時計算大數據系統”。它會把用戶的每一次點按拿回去立刻計算，幾毫秒之內就要調整推薦策略——彈性計算可以支持。

比如找貨員，就是你熟悉的“搜索引擎”，這是一個和數據庫類似的高 I/O 系統，還涉及全球范圍內的信息傳輸——彈性計算也可以支持。

湊齊這一套“賽博牛馬”盲盒后，阿里云上的“大遷徙”已經勢不可擋。

容器服務負責人易立回憶，智聯招聘前兩年特別頭疼的就是招聘季突然會有大量的畢業生涌入平臺，算力需求暴增。為了服務不掛，他們只能按照峰值準備廚師（服務器）。

可一過旺季，很多廚師就閑著了，每天摸魚，實在浪費。后來他們索性遷徙到了阿里云的容器計算上，每秒用幾個廚師就付幾個廚師的工資。

這樣精細切分，綜合成本比之前降低了恐怖的 40%。

同樣搬遷上來的還有 OPPO、得物、小紅書。。。數不勝數。

相當于阿里云準備了一套極其高效的中央廚房，你們這些大酒樓小飯店只管拉客，菜我給你炒！

看到這兒，估計你產生了另一個疑問：

別人用你幾秒鐘廚房就付幾秒鐘的錢，人家倒是沒損失了，你阿里云的中央廚房不就承擔了閑置的損失嗎？

這個問題，恰恰是我最早有意略過的，也是彈性計算的最精彩一塊拼圖。

一切紅利都來自宇宙的基礎特性：時間！

小紅書的峰值，和 OPPO 的峰值，和智聯招聘的峰值，和阿里云上千行百業的峰值會同一分鐘到來嗎？會同一秒到來嗎？會同一毫秒到來嗎？

觀察的時間顆粒度越小，越不會。

要知道，微觀上的廚師根據“CPU 時鐘”作息，本就比我們感知的顆粒小很多。

推到極端來說，只要這些客戶的峰值不撞進同一個調度時間片之內，哪怕只差幾微秒，就不算“同時”！廚師就可以先炒 A 客戶的菜，后炒 B 客戶的菜。

對“時間紅利”運用越深刻，就需要“廚師調度系統”越敏銳：如果你的最小調動能力僅是分鐘級，當然就沒辦法讓客戶們“秒級復用”你的廚師。

復用有一個前提：所有彈性計算的客戶，必須在（邏輯上的）同一套中央廚房里！

而當時的阿里云上，有人已經在用筐（容器），有人還在用虛擬廚房（虛擬機）。

對于楊航來說，任務非常明確：秘書（CIPU）必須升級，所有形式的彈性計算，它全理解，全支持，全安排，才能把客戶們容納在同一個中央廚房里。

這件事兒，就叫“并池”。

但并池又加劇了一個副作用，那就是所有飯館兒都在一個中央廚房里大鍋炒，萬一有人食材不干凈，污染了其他家的菜品，或者干脆有人惡意下毒怎么辦？

易立和沈益斌兩支團隊合作，把虛擬化上的一些關鍵隔離能力移植到容器上，雖然我炒的是百家飯，但是相互之間絕對不會滲漏。

同時，楊航團隊又升級了 CIPU，讓這個秘書經手的數據完全默認加密。

這些技術組合在一起，就做出了“安全容器”。

宜將剩勇追窮寇！搞完這些，技術大牛們驀然回首，那面“技術獨立”的旗幟已經高高飄揚。

他們恍然大悟，原來“獨立”從來不是一個時間節點，而是分布在漫長的時光中一串無盡的腳印。

在這面旗幟下，所有的算力第一次團結為一朵云。

這朵云的每一處都是均勻的，沒有任何特例，可以稱之為“純粹的算力”。

它就像電，你用電的時候，絕對不會糾結它是水電還是火電，它就是電！你清楚地知道，每一度電，都是完完全全等價的。

而歷史告訴我們：電力誕生的那一刻，并非結束，甚至并非結束的開始，而只是開始的結束。

1893 年芝加哥世博會是人類第一次大規模使用交流電照明，西屋電氣公司讓二十萬只燈泡齊明，夜空亮如白晝。

（五）AI 奇點

閃回到 2014 年夏天，淘寶低調地上線了一個功能：拍立淘。

從某個角度理解，這個功能對后來阿里云的意義，甚至大于它對淘寶的意義。

拍立淘的功能是通過對圖片的理解從商品庫里幫你找出對應商品，是一個“找貨員”。

那我問你：同樣是找貨員，“拍立淘”和“搜索引擎”有啥不同？

表面上的感覺是：一個用圖搜，一個用字搜。這沒錯。

深一點兒的認識是：一個用了 AI，一個沒用 AI。這就更對了。

但我有一個有趣的角度：他們替代人腦的工作是不同的。

搜索引擎模擬的人腦工作是一個——規則執行； 拍立淘模擬的人腦工作是兩個——規則建立+規則執行。

也就是說：拍立淘在搜索前，必須先建立一套規則，用以判斷兩個圖片處于相似“模式”。這就是 AI 的經典能力：模式識別。

這厲害在哪？

阿里云加速計算的產品技術負責人王超一語道破天機：

規則執行，例如大數據，大規模計算一旦停止，價值輸出就隨之停止。 規則建立，例如大模型，即便大規模計算停止了，它仍能繼續噴涌價值。

你上班干的具體工作，手停嘴就停；但你從工作中學習的技能，卻受用終生。

拍立淘后，歷史陡然加速。

越來越多的業務開始附加 AI 功能，邊干邊學。

旺盛的需求催生了達摩院老師傅的熱情，他們開始訓練能建立更深層模式的模型，比如（通義大模型的前身）M6 大模型。

底層的硬件，也從拍立淘的 384 張 V100 計算卡變成了 512 張 A100。

訓練大模型的計算強度，如舞會的音樂逐漸推高，烈焰一般炙烤著底層的算力平臺。

幸虧，阿里云的師傅們已經把彈性計算煉成了金箍棒，能接住 AI 時代的第一波“潑天富貴”。

2022年，王超他們拜訪客戶小鵬汽車，無意中聽到了他們的“絕密計劃”。

阿里云加速計算產品技術負責人 王超

當時，特斯拉已經開始用計算力模擬“人類駕駛員”——把 10000 張計算卡連在一起，端到端地訓練自己的“自動駕駛 AI”。

小鵬也看好這個方向，只是自己嘗試了半天，很難建起這么龐大又穩定的計算集群。

王超樂了：您說的這玩意兒，灑家恰好能干！你來我阿里云上用如何？

說干就干，王超申請了天價預算，準備啟動萬卡集群建設。

當時采購同學看到這個單子都慌了：“超哥，你可別沖動啊，一個客戶你敢買這么多卡？萬一將來沒有別的客戶續上，可就廢了。。。”

但王超心里篤定，AI 浪潮將會席卷，這次不是演習，無數企業很快會來阿里云上訓練他們的 AI！

一萬張卡可能都買少了。

“彈性計算 AI 版”，就這樣摸黑上路了。

這就是——靈駿集群。

后來的故事證明，王超簡直神預測。就在小鵬上靈駿之后幾個月，ChatGPT 橫空出世，大模型的潮水席卷而來，成千上萬的團隊涌上阿里云來訓練他們的 AI。

之前的一萬張卡，果然買少了。。。

和潑天富貴一起來的，是兇猛的技術挑戰：

隨著訓練模型的規模擴大到千億-萬億參數，底層的算力平臺又開始顫抖了。

這是為啥呢？

眾所周知，AI 訓練的核心負載從 CPU 轉移到了 GPU，相當于原來的廚師還在，只是炒菜的主要任務交給了一位新廚師。

廚師變化其實問題不大，關鍵是這群廚師要做的菜完全變了。

打個比方：

過去 CPU 廚師們做菜，有點像婚宴。一個廚師做十個菜，每盤之間沒有關系。你炒糊了一盤菜，是不會影響其他菜的。大不了我把這盤重做一下就是了。

現在 GPU 的廚師們做菜，一萬個廚師只做一盤菜，任何一個廚師手抖一下，對不起，剩下九千九百九十九個廚師都白干了。。。

可人無完人，每個廚師都有一定概率出問題：

足夠多的廚師×足夠長的時間=必然出問題

王超回憶，當時被阿里全集團寄予厚望的通義千問大模型剛剛在靈駿上做訓練時，在內部論壇直接吐槽：講個笑話，靈駿集群能穩定運行八小時，哈哈哈哈。。。

可在那個烈火烹油的當口，全世界都在追趕 ChatGPT，老板們天天盯著靈駿團隊，讓他們搞快些，哪怕多給撥些人也行。

王超氣得頂嘴：一個人生孩子要 10 個月，兩個人 5 個月就能生出來嗎？？

逼到瘋癲，他們只好使出了阿里云的傳統藝能：人計算。

一群 P8、P9 的老師傅夜里輪流值班，手動救火；白天再把昨天救火的經驗總結成GPU巡檢、網絡優化的代碼組件，固定到系統里。

就這樣連軸轉了三個月，每個 GPU 身背的出錯概率終于緩緩下降，系統總體的穩定性穩步爬升。

說到這里，有個普遍誤區。

很多人覺得 AI 計算是 GPU 的天下， CPU 在這里打醬油。

其實，GPU 廚師主要負責炒菜，但是炒菜的同時，大量洗菜（數據清洗）、放冰箱（數據存儲）之類的任務，還是得交給 CPU 來“幫廚”。

幫廚師傅一點兒不比主廚閑，具體來說，它需要多核心來并行任務，超高主頻來思考，還要大內存帶寬來保證同時處理大量數據。

找來找去，阿里云找到了 AMD，他們的 EPYC 系列 CPU 就是專門為 AI 計算設計的。

這個 CPU 的技能簡單說就是：無論是數據預處理，還是調度任務，都比 GPU 需要得節奏更快。

這樣，幫廚師傅永遠等著主廚，主廚不用等幫廚，就能全速炒菜了。

用戶的腳是投票器：最瘋狂的時候，全國一半左右的大模型都在靈駿集群上全速訓練，一個個“賽博大腦”自流水線噴涌而出。

可嘆十幾年前，阿里師傅還在“雙11”驚恐地大口嗆水；如今，隱天蔽日的“云上廚房”，已成智能的肥沃土壤。

向前追溯，至 1946 年第一臺電子計算機 ENIAC，甚至 1642年第一臺機械計算機“帕斯卡加法器”，人類在漫長的征程中，用計算一點點替代大腦的規則執行部分；

而今，我們終于模擬出了大腦的規則生成部分，從而湊成了大腦的“完全體”。

腳下，是萬年不遇的 AI 奇點。

我們該期待些什么呢？

ENIAC

（六）計算的銀河

阿里云創始人王堅曾給出絕佳的開示：如果說云計算是電，那么大模型就是電動機。

實際上，在電發明后，人類仍忍受了漫長的毫無想象力的生活；

而橫空出世的電動機，才真正攪動萬物，讓電動機床、卷揚機、電鉆、風扇、洗衣機、冰箱、縫紉機、電車、電梯依次誕生，歷史從此澎湃前行。

如此說來，此刻 90% 的人對 AI 的期待都可能是被局限的。

比如，受第一波浪潮 ChatGPT 的影響，很多人天然認為 AI 的形態就該是聊天機器人。

但王超告訴我：AI 真正的想象力，其實根植在具體的行業中。

千行百業都存在領域知識。而這些領域知識，過去都由具體的從業者體會、發現、傳承——這個匠人精神成本極高，而且產出不穩定。

而之前說過，AI 的本質功能就是“規則生成”，恰可以在細分的領域里替代那些匠人。

它會進入千行百業，成為比人類更資深的客服、卡車司機、機器精調師、醫生、翻譯、老師、編輯、裁縫。。。

更深刻的改變也許是——當 AI 腳踩彈性計算，它可以零成本實現“協作模式”的切換。

100年前，福特發明了流水線，讓生產效率飛躍；而彈性計算可以讓流水線根據需要每時每刻重組。

王超開腦洞舉了個例子：

將來也許會出現一種“服裝電話亭”，你站在里面，就有 AI 自動操縱掃描儀給你 3D建模，然后幫你設計衣服，做裁剪，最后產出一套成衣讓你拿走。

在你看來，自始至終都是在和一個 AI 對話，而它背后，是一套可以隨意組合、對接、改造，無遠弗屆的計算力。

如果這一天真的到來，意味著在最底層，燃燒著萬倍、億倍于今天的彈性計算。如今讓阿里云師傅們驕傲的技術，仍然需要N次迭代和升級。

“那時的計算底座會是什么樣？”我問。

“我不知道，人的想象力是有限的。就像讓你現在想象 iPhone 20，你也許只會想到更好的攝像頭，更大的屏幕。但最有可能的是，到那時，原來的思考框架已經被顛覆。”他回答。

王超很喜歡彈性計算同事們常說的話——為了永不停機的計算服務。

永不停機的計算，并不意味著我們的燈永遠亮著，而是我能永遠滿足人類旺盛的計算需求——當世界有需要，我們就在那里。

他說。

做算力基礎設施的人，很難站在聚光燈下接受獎杯。他們像是時代大廈的支柱，深埋在泥土中。

正如這些年手機芯片提升了百倍，但電池工程師的苦，似乎無人過問。

做算力基礎設施，就像是做電池，每年你都要逼迫自己把性能增加 15-20%。看上去只是日積跬步，沒有奇跡時刻，但當你走過十幾年回頭望，身后就是工程奇跡。

正如愛迪生點亮燈泡的一瞬間，只有他自己知道過去的 1000 次實驗意味著怎樣的艱難跋涉。

回望來路，一個真理不言而喻：世界從來不是某個截面，而是時光中錯綜的連線：

2010年，如果沒有彈性計算師傅趁黎明出發，用十五年鍛造出“大規模計算的組織能力”，如今像靈駿這樣的 AI 算力集群就不會成立； 2020年，如果沒有全世界 AI 研究者的反復試錯，就不會有 ChatGPT 的橫空出世； 2025年，如果沒有無數行業對大模型的熱烈擁抱，未來那個無遠弗屆的 AI 也只能是賽博傳說。

如此，我們并不活在一個確定的當下，我們活在無數可能性組成的根系中。

在任何一個時間截面上，你無法看到根系之間的聯系，他們散落在天穹，恰似遼闊的銀河。

而夢想家知道：在這條銀河中，終將有一顆新星閃耀。

計算是一場

深刻的模擬

再自我介紹一下吧。我叫史中，是一個傾心故事的科技記者。我的日常是和各路大神聊天。如果想和我做朋友，可以搜索微信：shizhongmax。

哦對了，如果喜歡文章，請別吝惜你的“在看”或“分享”。讓有趣的靈魂有機會相遇，會是一件很美好的事情。

Thx with in Beijing