从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刚开始的时候，也是互联网泡沫期嘛，可能跟咱们现在的感觉也差不多，整个社会在一个癫狂的状态。也不知道是谁在亚马逊突发奇想，基于互联网搞了这么个众包平