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