Jeff Dean「催生」了阿里第一代大模型

“Jeff Dean，与阿里搜广推、千问不为人知的故事。”

作者丨覃倩雯

编辑丨刘伟

前言：

雷峰网此前在《曾讲述Jeff Dean如何影响腾讯早期技术决策，并在阿里系列第一篇《中，挖掘了MapReduce如何沿两条路径进入阿里、最终影响ODPS。本文是阿里系列第二篇，讲述TensorFlow如何影响阿里的AI系统，并沿着搜广推一路走到M6大模型。下一篇，我们将把视线转向百度，继续讲述Jeff Dean与百度技术体系之间那些鲜为人知的故事。

Jeff Dean的技术思想为什么能启发阿里大模型M6？而作为千问前身的M6，又为何是国内第一款真正意义上的大模型？

答案，要回溯至一段跌宕的阿里往事：搜索事业部与阿里妈妈的技术博弈。

01

从博弈中孕育的阿里大模型

据多位原阿里人向雷峰网回忆，2016年前后，周靖人、林伟、关涛、徐晟等微软大数据骨干来到阿里，一开始是来给阿里云升级大数据平台，但他们却无意参与到甚至主导了淘宝的流量分配之战。

早期阿里搜索事业部和阿里妈妈的技术团队，由于算法和流量分配机制的天然交叉性，双方矛盾频频。

矛盾上升到高层后，内部决定让两支团队来一次正面PK，让双方同时做一部分信息流和广告推荐，通过分桶测试看谁效果更好。谁赢了部分业务就归谁。

阿里妈妈这边派出了盖坤（现快手可灵负责人），搜索事业部则由王晓博（现小红书技术副总裁）带队，一场针尖对麦芒的PK就此开始。

戏剧的是，搜索事业部有个员工，为了增加己方的胜算，在产品设计上动了点小心思。

她在信息流页面的右下角设计了一个小助手的按钮，用户如果不喜欢前面的内容，一点这个按钮就可以跳到自己喜欢的位置。

这个按钮可以通过算法来控制出现的频率，这位员工便在这个环节动起了手脚，使得盖坤所在的测试桶出现小助手按钮的频率要更低一些。

没想到，这个作弊行为被阿里妈妈抓住了把柄，还直接捅到了廉政部。

廉政部调查过程中，作为搜索事业部负责人的谷雪梅（后为零一万物联创）据理力争，认为这次作弊行为对结果的实际影响非常小，实测结果只有3‰，不值得大动干戈。

但不管怎么说，在PK中作弊，搜索事业部总是理亏在先。

最后高层一讨论，觉得既然谷雪梅这么喜欢做广告，甚至为此跟阿里妈妈吵得不可开交，就干脆让她去阿里妈妈好了。

就这样，谷雪梅带着搜索事业部中的推荐算法团队加入阿里妈妈，成为了技术总负责人。代价是，失去了对搜索团队的掌控。

2017年，逍遥子重新启用一批干部，接替谷雪梅在搜索事业部的工作，同时计划开启搜索和广告技术体系的融合战略。

他们便是阿里云的周靖人以及他从微软Bing带过来的团队：这群阿里少数既懂大规模系统、又真正做过搜索和广告的极客。

据参与者回忆，此前阿里内部也有人尝试推动搜广推的整合，但都以失败告终。几套业务各有自己的团队、数据和系统，直接把谁并进谁，阻力太大。

新班子到位后，他们换了一种办法：谁也先别合并谁，青峰继续做搜索算法，盖坤继续做广告算法，只是在下面做一套共同的智能引擎，把搜索、推荐、广告原本分散的数据和计算能力接到一起。巧合的是，多年后的今天，周靖人与青峰团队的郑波、盖坤团队的张迪，组成了阿里的大模型三驾马车。

这件事很快从业务整合，变成了一项必须往前推的infra升级。

据阿里员工回忆，当时拼多多已经“杀疯了”，淘天增长遇到瓶颈，如若搜索、推荐、广告再各自为战，与拼多多的竞争会愈加有挑战。

很快，周靖人、林伟、徐晟等人，在战火中临危受命，开始啃这套智能引擎。

与此同时，人事层面的整合也在推进，郑波从搜索事业部调至阿里妈妈，搜索工程负责人五福逐渐统管搜广推的所有工程开发。

阿里最开始只是想解决搜索、推荐和广告各自为阵的问题。可系统真正往一起做以后，他们发现了一个更深层的规律：搜索、推荐、广告三套业务优化目标不同，但底层其实是在一套学习用户行为与商品文字、图片、视频之间的多模态理解和推理框架。

2019年前后，阿里开始进一步为搜广推探索一套底层“认知系统”，这也成为后来阿里通义千问第一代大模型M6最早的雏形。

据多位参与人士透露，当时唐杰也参与了M6的工作，M6第一版就是两拨团队一起写的。后来唐杰创办了智谱，阿里则继续沿着M6这条路走。

一场最初为了合并搜广推而启动的系统工程，就这样意外走向了大模型。

这是国内最早从大规模数据和商用场景中孕育而出的大模型，而非诞生于理想数据集中的实验室项目。

因此无论是时间维度，还是业务价值，均领先于字节、腾讯、百度以及一众创业公司。

那么，这件事与Jeff Dean有何关联？

02

Jeff Dean的系统派思想

如何被阿里引进“搜广推”的？

搭建这套AI引擎期间，阿里很快把注意力放到了一个他们都很熟悉的问题上：分布式系统。

那时行业内做深度学习框架的其实分两波，一波是算法派，一波是系统派。

算法派的人，更关心模型写起来是否方便、算法能不能快速迭代，后来出现的PyTorch就是这条路线最典型的代表。

而系统出身的那派人，首先考虑的是一旦模型被铺到几百、几千台服务器上，计算怎么拆、任务怎么调度、机器坏了怎么办，以及未来系统需要大规模升级时，怎么保证整套集群还能平滑往前演进。

当时一批阿里“系统派”工程师，与Jeff Dean的技术思路非常接近。

对当时大部分的阿里人来说，登月计划刚结束不久，最严重时业务需要停下来等数据迁移的惨痛代价仍历历在目。

因此在技术规划上，阿里不可能再让所有业务同时停下来，配合底层系统完成一次“大搬家”。所以，做AI系统的第一天就要考虑扩展性，尽量避免未来出现推倒重来的时刻。

据微软员工透露，早在微软时期，周靖人、林伟等人对深度学习框架的设想也是如此。

当时微软内部已经在做深度学习框架CNTK，但那时的CNTK一直只能在单机上运行，没法满足大规模深度学习任务的需求。

那时候，他们注意到Jeff Dean团队正在Google内部秘密推进TensorFlow。

TensorFlow的核心设计是，把一个机器学习任务抽象成一张巨大的计算图，哪一步先算、哪一步后算、谁依赖谁，都被放进这张图里；再由系统负责Placement和分图，根据不同机器、CPU和GPU的情况，决定每一部分究竟放在哪里执行。过去需要工程师自己处理的大量分布式依赖关系，开始被交给系统。

于是，他们迅速意识到需要开发一个类似于Tensorflow的工具，具备分布式计算的能力，来满足微软在深度学习方面的需求。但后来，因为内部架构调整，计划随即中止。

当得知阿里要做AI系统时，这群从微软带着遗憾来到杭州的极客们一拍即合，决定沿着TensorFlow这条技术路线往前走。

据多位参与阿里早期AI系统建设的人士向雷峰网回忆，Pytorch开始很火时，大家都觉得Tensorflow要完蛋了。但事实上，PyTorch更加灵活，尤其适合算法研究和快速原型开发，而TensorFlow从设计之初就为大规模、复杂的分布式执行留下了更多系统空间。

在大量图像、语音等稠密计算场景里，PyTorch配合GPU和数据并行的方式非常自然，算法工程师也更容易上手。但到了搜广推里面，在某些特定的计算任务中，PyTorch的性能不如TensorFlow。

搜索、推荐和广告背后有用户ID、商品ID、店铺ID、广告ID，以及搜索、点击、收藏、加购、购买等海量行为。单个用户真正接触过的商品可能只有几百、几千件，但把整个淘宝的人、商品和行为摊开以后，特征规模很快就会膨胀到百亿级。

这类参数有一个典型特点：大，而且极其稀疏，大量参数根本塞不进一台机器。这时就需要Parameter Server，也就是参数服务器。

简单来说，一张巨大的参数表被切成很多份，分散到不同服务器。Worker训练到哪部分，就去相应的Parameter Server读取参数，计算完成以后再写回去。

相比大量稠密模型只需要做数据并行，这类超大规模稀疏模型面对的分布式参数存储和更新问题要复杂得多，这也正是TensorFlow这类系统化框架能够发挥作用的地方。

虽然和Jeff Dean思路一致，但阿里最初并没有完全按照TensorFlow原生方式去做。

最开始，阿里团队尝试过一种相对解耦的方案：把Parameter Server放在深度学习框架外面。这样，TensorFlow只负责上面的模型，下面再用一套独立系统管理淘宝特有的海量稀疏参数，两套东西可以各自演进。

但做了一段时间以后，这种解耦的缺点也暴露出来：Parameter Server在外面，TensorFlow在里面，两边各自只能看到系统的一部分。

模型计算是一套调度逻辑，参数读写又是另一套逻辑，系统想根据整张计算图统一安排通信、计算和资源时，很多优化做不下去。

这和原本希望的方向正好相反。据早期参与的人士透露，当时林伟团队更希望把编译、调度和执行放在一起，让系统拥有更完整的全局视野。

于是，技术路线又重新往TensorFlow本身的Graph和Runtime靠。

但这一次，不是把Google原来的实现照搬过来。而是保留TensorFlow计算图和分布式执行的思路，再把真正不适合淘宝的部分换掉。

第一个被“大改”的地方，是原生TensorFlow的Parameter Server架构。

据参与者回忆，阿里妈妈和PAI团队当时对TensorFlow做过一轮系统级性能剖析（Profiling），很快发现原生TF-PS在大规模稀疏参数场景下存在明显瓶颈。

随着Worker不断增加，单个Worker能够处理的样本QPS反而开始下降。机器堆到一定规模以后，再继续增加服务器，集群吞吐已经不再增长，甚至会往下掉。

也就是说，规模上去了，但系统没有等比例变快。

同样的，故障切换（Failover机制）也是当时分布式训练里非常棘手的问题。

在早期实验环境中，一台机器失败后重新启动任务通常还能接受，但随着搜广推训练逐步走向成百上千台机器的规模，任何一个节点的异常都可能影响整轮训练进度。

当时的检查点机制（checkpoint）与恢复机制还不够成熟，长时间运行的任务一旦被中断，就需要较高成本的回滚或重跑，这在工程上带来了明显压力，也暴露出系统在容错与稳定性设计上的不足。

于是，阿里替换掉了原来的TF-PS，重新做出一套高性能Parameter Server：PS-Plus，再把它接回TensorFlow。

TensorFlow继续负责上层模型和Graph，PS-Plus则接管海量稀疏参数的存储、读取和交换。算法工程师继续按照TensorFlow的方式开发模型，但下面真正决定搜广推训练效率的Parameter Server，已经换成了阿里自己的东西。

这套体系后来被称为TensorFlowRS。阿里妈妈也继续沿着类似的架构继续往前走：开源了算法框架XDL。XDL当时的主创，正是当今阿里最火的视频模型Happyhorse算法负责人，张迪。

与此同时，PAI也不断增强自己的分布式机器学习能力，再往后又出现了DeepRec。

这些系统背后逐渐形成了一条共同的思路：

TensorFlow提供骨架，阿里再根据搜广推的真实规模，把稀疏参数、分布式训练、可靠性、编译和调度能力重新补进去。

03

搜广推合到最后，M6雏形初现

随着底层Infra和数据平台逐一打通后，搜广推的整合开始往更上层走。

据参与过这轮技术整合的人士回忆，团队研究了一段时间后发现，搜索、推荐、广告虽然优化目标不同，底层做的其实是同一件事：理解人，理解商品，再理解人与商品之间的关系。

搜索更关心用户此刻明确表达出来的需求，推荐要判断一个人接下来可能喜欢什么，广告广告则要在兴趣匹配之外再考虑商业化效率。

目标不同，但它们需要的“认知”高度重合。而且这种认知并不是单维的，而是一套能够把文字、图片、视频和用户行为放到一起理解的多维认知能力。

这成为搜广推技术融合的一个关键转折。

此前，这套系统推动的更多还是数据、计算和AI系统层面的打通。到了这时，融合还要继续往上走：从共用一套系统，走向共用一套认知。

与此同时，团队还发现了一层更复杂的问题。

搜索和推荐首先考虑用户体验，广告则天然承担着商业化目标。真正把三套体系放到一起以后，不能只朝其中一个方向优化。

据参与者回忆，当时团队开始尝试把用户体验和商业化放到同一套体系里考虑，在不同场景和时间点，对两类目标做不同组合和权衡。

这意味着，底层模型不能再只为某一个固定任务服务。它需要先获得一套更加通用的能力，再根据搜索、推荐、广告不同的目标往上适配。

到2019年前后，周靖人在内部推动一套面向搜广推的底层认知系统。彼时，周靖人身上恰好有一个非常特殊的双重身份。

一边，他负责阿里的搜索AI中台和效果广告业务，直接站在搜广推一线；另一边，他又负责达摩院智能计算实验室，手里连接着阿里的AI研究和计算体系。

这时，搜广推每天产生的数据、目标和算法需求，可以直接进入周靖人负责的智能计算体系；而实验室里做出来的新模型，又可以重新回到搜索、推荐和广告里验证。

这种组织关系，直接缩短了从业务问题到模型研究之间的距离。

杨红霞团队也正是在这一体系中，开始承接并向下推进“统一认知”的模型化落地工作。

他们把商品文字、图片、视频以及用户行为逐渐放到一起，不再围绕某一个单独业务训练模型，而是先训练一套更通用的表示，再让不同任务去使用。

2020年前后，InterBERT已经开始在淘宝真实商品数据上做图文联合预训练，并进入推荐业务。阿里也逐渐意识到，过去分别服务搜索、推荐和广告的商品认知能力，可以往同一套底层模型里收。

原本分散在不同业务里的文本理解、商品理解、用户意图和转化建模，不再各自演进，而是开始共享同一套表征和预训练能力。搜广推的融合，也由系统和业务层进一步下沉到了模型层。

M6就是在这个基础上继续往前迭代。

到2021年，文字、图片等多种模态，以及不同业务任务，被进一步纳入统一的预训练体系。此前为搜广推搭建的底层认知系统，也开始从一套业务能力，演变成真正意义上的大模型。

回头看，阿里几代技术人的很多关键选择，都曾在不同时间里，与Jeff Dean发生过交汇。

从MapReduce到TensorFlow，他留下的两套技术思路，先后进入了阿里的大数据体系和AI体系。

前一次，影响的是阿里怎么计算海量数据；后一次，是怎么搭一套能支撑海量机器学习任务的AI系统，而这套技术思路，沿着搜广推，一路走到了大模型。