从GFS到GPT，AI Infra的激荡20年

​导读

最近AIGC和LLM的浪潮层层迭起，大有把AI行业过去十年画的饼，一夜之间完全变现的势头。而 AI Infra （构建AI所需的基础设施），也成了讨论的焦点之一。大众对AI Infra的关注点，往往放在AI算力上——比如A100/H100的芯片封锁；比如马斯克又买了一万张GPU，等等。

算力无疑是AI浪潮中至关重要的一环，然而AI Infra并不只与算力相关。冰冻三尺非一日之寒，正如GPT并不是突然的成功一样，AI Infra行业其实也经历了漫长的积累与迭代。笔者最近跟同事、朋友不断地在讨论AI的各种发展，每每聊到AI Infra，心里总会涌出千言万语却又难以言表，于是今天决定动手把想说的都写下来。

如标题所说，整个AI的发展离不开大数据，而大数据的开端，自然是谷歌的三大件：Google File System、MapReduce和BigTable。其中GFS论文发表于2003年，距今刚好整整20年。这20年，也是大数据、AI、互联网发展突飞猛进的20年。

本文试图去梳理这20年间AI Infra的一个个里程碑事件 。因为当我们身处其中时，往往分不清炒作与干货，也看不清局部领先和最终取胜的架构之争。只有当回顾历史，观察长周期的变革时，一些规律才会涌现。话不多说，让我们就此开始！

目录索引

【2003/2004年】【框架】：Google File System & MapReduce

【2005年】【数据】：Amazon Mechanical Turk

【2007年】【算力】：CUDA 1.0

【2012/2014年】【研发工具】：Conda/Jupyter

【2012年】【框架】：Spark

【2013/2015/2016年】【框架】：Caffe/Tensorflow/Pytorch

【2014年】【框架/算力/研发工具】：Parameter Server & Production Level Deep learning

【2017年】【算力】：TVM/XLA

【2020年】【数据/算力】：Tesla FSD

【2022年】【数据】：Unreal Engine 5.0

【2022年】【数据/研发工具】：HuggingFace融资1亿美元

【当下】OpenAI有什么AI Infra？

【2003/2004年】【框架】：Google File System & MapReduce

2003年谷歌发布的GFS论文，可谓是掀开了这场20年大戏的序幕，宣告人类社会正式进入互联网大数据的时代。一个小插曲是谷歌虽然开放了论文，却没有开源实现，导致后来的Apache Hadoop以「一言难尽」的性能占领了开源生态（也为Spark日后横空出世埋下伏笔），而开源社区爆发式的发展想必也影响了后来谷歌对开源系统的态度。

GFS和MapReduce可以说是开启了分布式计算的时代，同时也在传统单机操作系统、编译器、数据库这些领域之外，让「 Infrastructure 」这个词开始逐步深入人心。关于GFS这里不多说，重点想讨论下 MapReduce的「问题和缺点」 。不知道有没有人在第一次学习MapReduce编程模式后，也跟笔者一样在心里犯嘀咕：这个Map和Reduce是有什么特殊之处嘛？为什么是它们而不是别的接口？为啥一定要用这个范式编程呢？是倒排索引必须用MR才能建么？种种疑问即便是后来通读了Paper也未能完全理解。

而且后来发现，吐槽的还不止笔者一个。2008年，当时还没获得图灵奖的数据库大牛Michael Stonebraker 就撰文狠批《MapReduce: A major step backwards》，还直接点名批评西海岸某学校：“Berkeley has gone so far as to plan on teaching their freshman how to program using the MapReduce framework.” 。而Stonebraker教授主要抨击的点，便是MR缺失了传统数据库的一大堆Feature，尤其是Schema & 高阶SQL语言、Indexing查询加速等等。咱阿里的同学看到这想必心里乐了：“嘿嘿，您老说的这些Feature，咱MaxCompute的湖仓一体/SQL查询/自动加速，现在全都有啦！MR也可以棒棒滴”。

不过这已经是现代了，让我们先回到2004年，看看为什么在没有日后这些高级Feature的情况下，谷歌依然要推出MapReduce并定义了整个开源大数据生态的模式。这里想说是：「 了解成功架构的缺点，才能真正理解其优点到底带来多大的收益，以至于可以抹杀掉所有的不足 」。MapReduce并不见得是一个好的编程范式（后来的发展也证明有各种更好的范式），它让算法实现变得复杂&教条，它只能实现很少一部分算法，它的性能可能比原问题的最优实现差之甚远。但是它在2004年的时候，让普通程序员使用大规模分布式计算变得非常简单！不需要了解Mpi，不需要了解分布式通信同步原理，写完Mapper和Reducer，你就能在上千台服务器的集群上运行程序，关键是还不用担心出现机器故障等等各种异常问题。

归根结底，MapReduce是一个妥协

MR牺牲了灵活性，牺牲了性能，却让用户获得了稳定可靠的分布式计算能力。而各种各样的「妥协」，在后面一代代的AI Infra中，已然就是主旋律。不过我们也能惊喜地看到，随着现代工程技术的发展，在灵活性、性能、稳定性三个维度均得高分的系统比比皆是。当然，新的妥协点依旧会存在，这也是AI Infra或者说Large-Scale Computer System这个领域令人着迷的原因之一。

关于GFS和MR要说的还有最后一点，那便是「 面向Workload的设计 」，谷歌在论文里也说了，整个大数据系统的设计与他们的搜索引擎业务息息相关：文件系统只会Append写而不会删除，读取主要是顺序读而不是随机读，需要MR的任务也以扫库建索引为主。而传统数据库、文件系统对于其他通用需求的支持，必然也导致它们在大数据处理这个任务下，不会是最优解。

好了，读到这有读者可能会问，光一个20年前的GFS你就讲这么多，我关心的GPT在哪里？怎么才能造出GPT？别急，太阳底下无新事，20年前对框架的设计思考，与最新的AI Infra相比未必有什么本质不同。

【2005年】【数据】：Amazon Mechanical Turk

时间来到2005，让我们从系统领域抽出来，看看AMT给世界带来了什么样的惊喜。其实Web1.0刚开始的时候，也是互联网泡沫期嘛，可能跟咱们现在的感觉也差不多，整个社会在一个癫狂的状态。也不知道是谁在亚马逊突发奇想，基于互联网搞了这么个众包平台，但这可乐坏了在学校研究所里依靠学生、人工招募对象来标注数据的老师们。于是乎，Stanford的Fei-Fei Li团队，开始基于AMT来标注了CV有史以来最大的一个Image Classification数据集：ImageNet，并从2010年开始举办比赛，最终在2012年AlexNet技惊四座，引发了第一次深度学习革命。

关于AMT和ImageNet这里想说3个点：

1.事后看关于「数据」方面的历次革命，特点就很明显了，每一次要么是极大地降低了获取数据标注的成本，要么是极大地提高了数据的规模量。正是AMT或者说互联网，让人类第一次可以很方便地，为了研究AI而大规模地获取标注数据。而到了2023年的LLM，大家对这个问题其实也想得很清楚了：『 原来根本不用什么众包平台，每个在互联网上说过话的人，以及之前写过书的古人，其实都是在帮AI标数据 』。

2.很多同学不知道为什么ImageNet有个Net，或者以为ImageNet的Net和AlexNet的Net一样都指神经网络，其实根本不是。这里可以参考ImageNet的原始论文，主要是因为之前有另一个项目WordNet，是类似知识图谱或者大词典的一个工作，将各种范畴和概念都进行了记录和网状关联。ImageNet在WordNet的基础上，选择性地构造了1000类物体类别，对视觉分类任务进行了设计。从现代来看，这叫图文多模态，但其实这是很早就有的一个范式：「 借用NLP的Taxonomy，对CV的分类任务进行定义 」。

3.Fei-Fei Li有很多非常有意思的CV论文，Citation量一般都不高，因为其切入点经常与众不同。另外Fei-Fei Li的高徒Andrej Karpathy想必大家都非常熟悉，虽然AK的论文大家倒是不一定记得（甚至不知道他也在ImageNet的author list里），但AK的博客和Github却是有极高的影响力，从最早的《Hacker's guide to Neural Networks》到最近的nanoGPT，而且AK的博士论文题目就是：《Connecting Images and Natural Language》

【2007年】【算力】：CUDA 1.0

2007年，当游戏玩家们还在纠结买啥显卡能跑孤岛危机时，NVIDIA悄然发布了第一代CUDA。之所以用悄然一词，是因为估计当时没激起什么水花。因为几年后笔者听到做图像处理的师兄对CUDA的评价无一例外都是：「 真难用 」。是啊，毕竟已经被编译器和高级语言惯坏了这么多年了，突然跟你说写个程序还得思考GPU硬件是怎么运行的，还得手动管理高速缓存，稍微一不注意程序反而会变得死慢死慢，谁能喜欢得起来呢？而且更要命的是CUDA的浮点数精度问题。当年笔者第一次用CUDA，兴冲冲写完一个矩阵乘法后，一对比发现，咦？怎么结果差这么多，难道哪里写错了？排查半天无果，毕竟「 用CPU的时候，结果有错从来都是我的错不会是硬件的错 」。后来经同学指点，原来是CUDA的浮点数精度不够，需要用上Kahan Summation.就是下面这段代码：

float kahanSum(vector<float> nums) {
    float sum = 0.0f;
    float c = 0.0f;
    for (auto num : nums) {
        float y = num - c;
        float t = sum + y;
        c = (t - sum) - y;
        sum = t;
    }
    return sum;
}

加上后结果就神奇地对了。而如今每天用着V100/A100，然后吐槽NPU/PPU这不好那不能适配的同学可能未必知道，当年CUDA刚推广的时候，也好不到哪里去。尤其在高性能计算领域，由于大客户都是各种跑偏微分方程的科研机构，常年使用科学家们写的上古Fortran代码，而硬件上从来都是CPU双精度浮点数保平安。所以相当长一段时间，CUDA压根不在考虑范围内。Intel在高性能领域也成为绝对的霸主。

另外，在此还要介绍一位曾经被Intel寄予厚望的主角： Xeon Phi。 Xeon Phi芯片最早发布于2010年，就是为了对抗CUDA而研发的众核架构。笔者在13年参加ASC超算比赛时，当年Intel免费赞助了一大批Phi并直接出了一道题让大家试用Phi。大家用完的体感嘛......方便是真方便，毕竟主打的是编译器包办所有事情，原有的高性能分布式代码一行不用改，直接适配众核架构。这也是Intel一直以来做CISC架构CPU和编译器的思路：「 底层实现复杂的指令集，编译器完成所有转译和优化 」，上层用户完全无感，每年付费即可享受摩尔定律的红利（值得一提的是，Intel的Icc高性能编译器和MKL库都是要额外付费的）。可惜的是，Phi的目标和愿景虽然很美好，但它的编译器和众核架构没有做到标称所说的，一键切换后，性能得到极大提升。Phi项目始终没有积累大量用户，也在2020最终关停。

另一方面，CUDA却取得了节节胜利：人们发现，写SIMD模式的高性能应用时，CUDA其实比CPU更好用。原因恰恰是「 编译器做得少 」。写CUDA时，所写即所得，不用再像写CPU高性能应用那样，时常需要编译出汇编码去检查向量化有没有生效、循环展开对不对。由于无法对CPU Cache进行直接管理，更是只能靠经验和实测来了解当前Cache的分配情况。这里也引出一个问题：「 编译器和语言设计一定要满足所有人的需求么？ 」想必不是的，找准这个语言的真正用户（高性能工程师）可能才是关键。

而与本文最相关的是，CUDA找到了AI这样一个神奇的客户。说它神奇，因为AI算法真的要让《数值分析》的老师拍案叫绝，让《凸优化》老师吐血。为什么呢？这么大规模的一个数值计算应用，居然说「 精度不重要 」，而且「 全是CUDA最擅长的基本矩阵运算 」。机器学习不需要双精度，直接单精度浮点数搞定，甚至在推理时连单精度都嫌多，半精度、int8、int4都能用。而在优化角度，也是打破了凸优化的所有传统认知：一个非凸优化问题，传统各种算法通通不需要。而且搞全量数据优化反而效果不好，SGD的mini-batch虽然会自带噪音，但噪音反而对训练有益。于是乎，GPU另一个软肋：显存受限，在mini-batch的算法下，也变得不是问题了。

总之，CUDA和GPU似乎就是为AI而生，缺点最终全变成了Feature，也让老黄变成了厨房霸主，核弹之王。而目前集举国之力攻坚自研芯片的我们也不要忘了，CUDA发布这16年以来，除了底层的芯片之外，软件层工具链和用户习惯用户生态是怎样从0到1一步步演进的。GPU未来是不是一定就一家独大？TPU/NPU/PPU会不会弯道超车？让我们静观其变。

【2012/2014年】【研发工具】：Conda/Jupyter

聊完了框架、数据和算力，我们再来看看AI的研发工具是什么情况。而这里不得不讨论的问题便是：为什么AI的主流语言是Python？其实，不只是AI，Python的普及率本来就在逐年上升。开源社区很早就发现为一个项目提供Python接口后，用户使用量会大增，而且大家更倾向于使用Python接口。究其原因，无需编译的动态脚本语言的魅力实在是太大了。在这里无需多言，毕竟大家都知道：

人生苦短，我用Python

而Python的生态本身也在不断的完善，基于Pip的包管理本来就很方便，2012年推出Conda之后，更是让「 虚拟环境管理 」变得极为容易。要知道，对于一个频繁需要复用开源软件包的开发领域，这绝对是一个Killer Feature。

除了包管理，Python的另一大突破便是基于IPython的Jupyter 。它把Python本来就好用的交互功能提升到了新的标杆，并且打造了大家喜闻乐见的Jupyter Notebook。至于说Notebook算不算AI Infra，看看谷歌的Colab，看看目前各种AI开源项目的导引教程、以及咱们自己的PAI-DSW就能知道，Notebook已经是AI研发和知识分享中不可或缺的一环。其隔离后端集群的Web端的研发体验，让用户一站式操控海量算力资源，再也不用只能用Vim或是远程同步代码了。

而对于笔者来说，写Data相关Python实验代码的第一选择也早已不是IDE，而是Jupyter Notebook.原因很简单：处理图像、Dataframe、Json这样的数据，并且需要频繁「 迭代不同的算法策略 」时，「 代码怎么写取决于其内在数据格式和前面的算法结果 」。而数据和算法结果都是在运行时才能看到其具体形式，所以，「 一边运行代码一边写代码 」是数据处理、AI算法工程师的家常便饭。很多不理解这一点的Infra工程师，设计出来的框架或者工具，难免让人一言难尽。后面我们也会看到，在交互性和动态性上开倒车的Tensorflow，用户也在一点点的流失。

【小结】

通过前面这4个板块代表性工作的介绍，我们不难看到AI Infra全貌的雏形：

1. 算力 ：需要强大的CPU/GPU为各种数值计算任务提供算力支持，同时编译器需要为高性能工程师提供良好的编程接口。

2. 框架 ：针对特定的Workload抽象出一个既有通用性，又满足一定约束的编程范式。使得执行引擎可以一站式提供诸如分布式计算、容灾容错、以及各种运维监控的能力。

3. 研发工具 ：AI和数据算法研发期望在代码编写时是能实时交互反馈的；开源社区要求代码和其他生产资料能够被很容易地打包、发布、集成、以及版本管理。

4. 数据 ：需要一个提供AI训练所需海量数据的工具或模式。

带着这些思路，其实就很容易能看清后来AI Infra发展的基本脉络了，让我们继续来看看。

【2012年】【框架】：Spark

还是2012年，这一年Berkeley的Matei Zaharia发表了著名的Resilient Distributed Datasets 论文，并且开源了Spark框架。Spark彻底改变了Hadoop生态「慢」和「难用」的问题，借助Scala和Pyspark/Spark SQL的普及，将很多编程语言领域的最新进展引入了大数据开源社区。其实目前来看，RDD是不是In Memory可能都不是最重要的，毕竟大部分Job并不是Iterative的。但是，光是借助Scala interactive shell实现的Spark shell，对于动辄启动任务就要分钟级别的Hadoop，本身就是颠覆性的（想想你告诉一个天天写Java based MR接口的同学，你现在可以在Python命令行里搞大数据计算了是什么感受）。更别提Scala的各种语法糖，以及对海量算子的支持了。

总而言之： Spark 用Scala、Python、SQL语言的极好交互式体验对笨重的Java实现了降维打击，并提供了更优的系统性能。 而人们也看到，只要「 用户体验 」足够好，即便是一个成熟的开源生态也是可以被颠覆的。开源大数据生态也因此进入了百花齐放的阶段。

【2013/2015/2016年】【框架】：Caffe/Tensorflow/Pytorch

2013年，最接近大众认为的AI Infra工作来啦。那就是贾扬清大牛开源的Caffe，自此Deep Learning的门槛被大大降低，通过模型配置文件，就能搭建网络，完成训练，利用GPU的算力。一时间模型创新开启了大爆发时代。其实同一时期开源框架还有Theano，以及基于Lua的Torch，不过使用方式各有差异。随后，大公司纷纷入局，谷歌和FB分别在15和16年发布了Tensorflow和PyTorch，再加上日后Amazon背书的MxNet，以及百度的PaddlePaddle，机器学习框架迎来了百家争鸣的时代。关于机器学习框架可以讨论的点太多了，公开的资料也很多，这里只讨论其中的两个点：

一个是从框架设计方面的「 Symbolic vs. Imperative 」。这个讨论最早可以追溯到MxNet的技术博客 Deep Learning Programming Paradigm 。而MxNet也是最早两种模式均支持的框架，并在博客里点明了：Imperative更灵活易用，Symbolic性能更好。再看看其他框架早期的版本，则专一到其中一种范式：Tensorflow是Symbolic，PyTorch是Imperative。而后面的事情大家也都知道了，Pytorch完整继承了Python语言的优点，一向以灵活、适合科研使用著称；TF则在工程化部署时更友好，但牺牲了交互性。而后经过漫长的迭代，两种范式也基本走向了融合。TF也支持Eager模式，后面还直接推出了新框架Jax；Pytorch也可以把Symbolic Graph进行导出和操作，比如TorchScript、Torch.fx。如同MapReduce是一种妥协，各个机器学习框架也都在「 易用性 」和「 性能 」上做着某种妥协。但整体看，主打Imperative，保持与Python使用习惯吻合的Pytorch还是在用户量上逐渐占据上峰。当然，现在下任何结论都还为时尚早。机器学习框架的发展和迭代远没有结束。

另一个可讨论的点是「 机器学习框架演进和算法演进 」之间的关系，之所以要讨论这个点，是因为很多算法研发团队和工程框架团队习惯于甲方乙方的工作模式。把框架研发和框架升级理解为：算法科学家为了实现某个模型或者想法，发现现有框架无法支持，于是给工程团队提一些关于算子Op实现、新的分布式计算范式、性能优化方面的新需求。这样的模式有很多弊端，比如只能支持局部的小创新，而且创新的周期可能会很长，甚至会出现经常被工程团队吐槽的：「 上一个需求还没实现完，算法侧又换了新想法 」。所以如何打磨好算法团队和工程团队的协作模式，是很重要的课题：比如 Co-Design 的方法论，双方都要换位思考，提前预判技术路径。比如工程团队不能把日常工作变成帮科学家实现功能代码，而是要提供一个灵活的上层接口让科学家自行探索，框架层重点解决卡脖子的工程技术问题。而且最重要的是：双方一定要意识到：「 目前的模型结构和框架实现，可能只是历史演讲过程中的一个偶然 」，而「 模型设计和框架实现，会不断地互相影响着对方的演进路线 」

原因也很简单，在模型创新最前沿，有一个鸡生蛋蛋生鸡的问题：算法科学家只能实现并验证那些现有框架能实现的Idea，而框架支持的功能，往往又都是以往成功过的算法架构或是科学家提出了明确需求的架构。那么 真正的系统级创新如何发生呢 ？可能还真回到了阿里的老话：

因为相信，所以看见

此外，算法与框架的共生关系，近年来也引发了大量的讨论。比如最近讨论比较多的，LLM为什么是Decoder Only架构？还有《The Hardware Lottery》一文里提出的 “ A research idea wins because it is suited to the available software and hardware ”。

总而言之，对于机器学习框架而言，「框架」的意义早已超出了MapReduce/Spark这种大数据框架帮助工程师实现各种Data ETL功能的范畴。因为算法、模型的形态本身就是在变化在革新的，框架如果限制过死，就反而会制约算法的迭代和创新。

【2014年】【框架/算力/研发工具】：Parameter Server & Production Level Deep Learning

开源社区的框架引发了AI的新浪潮，而在互联网大厂的搜推广业务里，大家也开始琢磨，Deep Learning的成功是否能在传统Ctr算法中复现呢？答案是肯定的！基本上所有大厂都开始了相关的研发。这里打个广告，以笔者熟悉的阿里妈妈展示广告业务线为例，从2013年的 MLR ，再到后来的大规模分布式训练框架 XDL ，再到 DIN 和 STAR ，搜推广的同学们应该都非常了解了。开源框架不支持大规模Embedding Table和靠谱的分布式训练，这也让自研的类Parameter Server框架迎来了发展空间。大规模分布式训练的框架也成为了这几年搜推广算法迭代的主要推手。而与上文说的一样，在模型高频迭代，大促提效常态化的背景下，算法创新和框架演进是一个复杂的共生关系，这里也推荐大家看看怀人老师写的 广告推荐技术发展周期 ，完整描述了整个算法架构的演进历程。

另一方面，训练引擎仅仅只是整个搜推广算法工程化的冰山一角。模型推理引擎，实时数据流，ABTest实验平台，容器调度平台等等都需要一整套完整的Infrastrature，这里写得最详细的当然是五福老师的 AI OS综述 。笔者也在下图大致梳理了在工业级机器学习应用中，面临的一些常见问题。

​

在这里不得不说，搜推广的Ctr模型，由于与互联网业务、营收高度相关，一直是大厂里的技术高地。经过无数人日积月累的不断打磨，可以说是把 y = f(x) 这个学习范式的每个细节都做到了极致，上图的每个小框都值得10+篇技术分享。而在GPT时代LLM、半监督学习范式以及未来前景广阔的AI应用中，阿里在这一块的积累一定可以得到迁移和复用，继续发光发热。

【2017年】【算力】：TVM/XLA

时间到了2017年，TVM和XLA都在这一年发布，而AI编译器这个话题也值得我们单独讨论一下。与机器学习框架主要解决易用性问题不同，AI编译器重点解决的是性能优化、计算芯片最优适配的问题。一般通过对单算子的底层计算代码生成，或是对计算图的重组和融合，来提升模型推理的性能。在芯片断供、自研芯片百花齐放的当下，AI编译器也成了目前AI Infra发展最为迅猛的领域之一。阿里PAI团队的杨军老师也写过关于AI编译器的综述。

既然是编译器，则又会出现我们前文所说的，编译器用户是谁以及接口约定的问题。此外还有通用编译优化 vs. 专有编译优化的问题。比如搜推广业务，由于其模型结构的特殊性，往往就会自建专有编译优化，专门总结出某些优化Pattern以支撑模型迭代带来的海量推理算力需求。而通用的编译优化算法，其实很难将这些特定的Pattern抽象整合到优化规则中去。

另一方面，AI编译器的图优化算法往往对普通算法同学不太友好，原因在于很可能稍微对模型进行一些改动，就会导致原有优化规则无法命中。而无法命中的原因，往往也不会给出提示。这就又回到了前文所说的CPU高性能编译器的问题，虽然编译器看似很强大很通用，可以隐藏硬件细节。但 实际能写出高性能代码的用户，一般还是需要对硬件的底层逻辑有充分的了解 ，并且了解编译器的实现逻辑以进行检查和验证。

所以AI编译器到底是像torch.compile那样帮助小白用户一键提升性能，还是仅作为一个自动化工具，为具备底层认知的高性能模型工程师提高研发效率呢？目前来看两者均有，比如OpenAI也在2021年发布了Triton，可以用Python的语法更加方便地进行类CUDA GPU编程。像Triton这样的工作就是既需要程序员大致了解GPU多线程模型的原理，又大幅降低了入门门槛。而TVM也同样在不断升级，比如可以看看天奇大神写的 《新一代深度学习编译技术变革和展望》 。未来的AI编译器会如何发展，让我们拭目以待！

【2020年】【数据/算力】：Tesla FSD

时间来到21世纪的第三个10年，此时公众感知到的AI领域稍微会有点沉闷。因为上一波AlphaGo带起的RL革命还没有在实际场景中取得大量收益，L4无人驾驶也陷入瓶颈，其他AI之前画的饼都还在纸上。搜推广的工程架构也从3.0做到了4.0再到5.0，6.0，7.0......

正当大家还在思考，AI有什么搞头时，这一年Andrej Karpathy带队的的Tesla突然放了大招，发布了纯视觉架构的Full Self-Driving无人驾驶方案，还直接在随后每年的Tesla AI Day上公布完整的技术方案：BEV感知、数据闭环Data Engine、端上FSD芯片，云端Dojo超大规模训练引擎等。一石激起千层浪，Tesla一下改变了行业的认知，在国内大部分自动驾驶公司的PR稿里，都能看到其影子。

配图来自Tesla AI day

可以说，Tesla把监督学习的工程架构又拔到了一个新高度：大规模的半自动标注引擎、大规模的主动难例数据收集、大规模的分布式训练和模型验证，底层的AI Infra支撑着几十个感知规控模型的持续迭代。

【2022年】【数据】：Unreal Engine 5

时间来到2022年4月，ChatGPT还有8个月到达战场，而这个月UE5正式发布。关注的同学想必都知道，效果那是无比的惊艳：Nanite的超大规模三角面片实时渲染，Lumen的动态全局光照。在官方DEMO《The Matrix Awakens》里我们也能看到现今实时渲染到底能做到什么水平。

配图来自Unreal Engine官网

那UE 5是不是AI Infra呢？答案也是肯定的。首先，基于UE4的各种开源仿真渲染工具比如AirSim，CARLA早就在无人机、无人驾驶上被大规模用来生成训练数据。而在GTA里面训练无人车，在MuJoCo训练小人跑步(MuJoCo已在2021年被Deepmind收购)也都不是新鲜事了。UE5如此革命性的更新，外加整个材质构建、3D模型产线的发展，也必然会让实时渲染仿真的效果一步步逼近真实的物理世界。

恩，DeepMind + MuJoCo + UE5会不会在未来某天放大招？让我们拭目以待。

【2022年】【数据/研发工具】：HuggingFace融资1亿美元

关注AI、GPT的同学最近肯定经常看到这个笑脸，可是Hugging Face到底做了什么，为什么也能成为AI Infra的关键一环并在2022年成功融资一个亿呢？如果你知道OpenCrawl、Pile、Bigscience、Bigcode、PubMed这些项目，那你一定也是在研究LLM训练数据的老兄。而你会惊奇地发现，原来很多语料库数据，都已经被整理好放在Hugging Face上了。他们还整了个Python包，名字就叫Datasets！

不知不觉中，Hugging Face已经成为了AI（至少NLP）领域的Github for Data & Model。看到这里有同学要问了，搞了这么多年AI的人脸识别、搜推广、自动驾驶公司，从来都说数据就是最强壁垒，没听说过谁家会把最珍贵的数据和模型开源放到网上呀。但事情到了LLM、到了GPT这，却发生了本质性的改观。目前多模态大模型使用的这些数据，天然就是存在于互联网上的，本身就是Open的，获取比较容易（版权问题除外）。所以现在的模式变成了大家一点点地帮忙收集、整理数据，最终制作出了大量高质量的原始语料库（比如LAION组织的创始人就是一位 高中老师 ）。

其实对于LLM和AGI，未来很可能是这样格局：数据 + 算力 + 算法这个传统AI三要素中，数据由于开源可能反而不是唯一壁垒了，在有芯片硬件的大厂里，最后比拼的就是算法和基于AI Infra打造的迭代速度了！

【当下】：OpenAI有什么AI Infra？

那么，AI Infra对于打造GPT有什么帮助呢？从OpenAI被公开的 架构 来看，上文提到的方方面面基本都有涉及。而在Compute和Software-Engineering两Topic下，也可以看到OpenAI自己发表的大量关于AI Infra的博客。其中很多是在算力-算法Co-Design的方向。比如在2021年初，OpenAI管理的K8S集群达到了7500个节点的规模(4年前是2500节点)。而后在21年7月份开源了前面提到的Trition，一个能用Python语法实现GPU高性能编程的编译器。22年的时候也花很大的篇幅介绍了他们进行大规模分布式训练的技巧。

不难看出，最大限度地让算法研发用上用好海量的算力资源，是OpenAI Infra的头号目的。另一方面，从AI and Compute和AI and Efficiency两篇文章中能看到，OpenAI花了不少精力在分析随着时间的演进，最强模型所需算力的增量曲线，以及由于算法改进而导致的算力效率变化曲线。而类似这样的分析，也在GPT-4的 Predictable scaling 中得到了体现。也就是说，给定训练算法， 所消耗的算力与所能达到的智能程度是可被预测的 。这种「 算力算法Co-Design 」的指标就能很好地去指导算法研发 vs. 工程架构升级的节奏和方向。

除了算力这条线，AI开源社区的进展也是日新月异，想必很多也为GPT的出现做出了贡献。除了Hugging Face，还有很多值得称道的AI创业公司不断涌现，在此笔者还来不及去细细分析各家公司的工作和意义。但变革已然在不断发生，新事物的出现速度已然是以周为单位。

【结语】

最近几个月AI的发展速度，确实远超笔者之前的认知。毫无疑问，AI2.0的时代已经到来，上一代基于纯监督学习的范式已然不够用。AI画的饼大家也都吃进了嘴里，而且真香！作为AI从业者，过去几个月也让笔者心潮澎湃。虽然看完了本文，你还是无法做出GPT，但想必你也看到了AI Infra这20年的发展。无论未来AI算法往哪走， 底层的算力层和底层的系统依然会是算法研发的基石 。

回望这20年的发展，从03年到13年这十年是Web1.0的时代，笔者还是个孩子；13~23年笔者全程目睹了AI1.0和Web2.0的发展浪潮，但更多时候也只是个吃瓜群众。而未来的十年，自然是AI2.0和Web3.0革命性的十年，笔者完全无法想象10年后的今天，世界会是什么样的样子。但唯一确定的是，这一次终于可以完整参与其中，跟志同道合的小伙伴们一起做出能影响行业的事情！

话都说到这里了，不发广告怎么行呢？我们是 高德视觉技术中心的训练工程平台团队 ，负责支持数据闭环、大规模训练、算法服务化等各种算法工程化需求。我们力求在AI2.0时代打造有技术差异性的 端云协同一体AI Infra ，一方面会复用集团和阿里云大量的中间件，一方面会自建很多专用AI工具链。而 高德视觉，目前也成为了集团最大的视觉算法团队之一，支持高精地图、车道级导航、智能出行等多种业务 ，涉及感知识别、视觉定位、三维重建和渲染等多个技术栈。

​