AI Infra （构建AI所需的基础设施），也成了讨论的焦点之一。大众对AI Infra的关注点，往往放在AI算力上——比如A100/H100的芯片封锁；比如马斯克又买了一万张GPU，等等。
如标题所说，整个AI的发展离不开大数据，而大数据的开端，自然是谷歌的三大件：Google File System、MapReduce和BigTable。其中GFS论文发表于2003年，距今刚好整整20年。这20年，也是大数据、AI、互联网发展突飞猛进的20年。
本文试图去梳理这20年间AI Infra的一个个里程碑事件 。因为当我们身处其中时，往往分不清炒作与干货，也看不清局部领先和最终取胜的架构之争。只有当回顾历史，观察长周期的变革时，一些规律才会涌现。话不多说，让我们就此开始！
目录索引
【2005年】【数据】：Amazon Mechanical Turk
【2012/2014年】【研发工具】：Conda/Jupyter
【2012年】【框架】：Spark
【2014年】【框架/算力/研发工具】：Parameter Server & Production Level Deep learning
【2020年】【数据/算力】：Tesla FSD
【2022年】【数据/研发工具】：HuggingFace融资1亿美元
【结语】
【2003/2004年】【框架】：Google File System & MapReduce
GFS和MapReduce可以说是开启了分布式计算的时代，同时也在传统单机操作系统、编译器、数据库这些领域之外，让「 Infrastructure 」这个词开始逐步深入人心。关于GFS这里不多说，重点想讨论下 MapReduce的「问题和缺点」 。不知道有没有人在第一次学习MapReduce编程模式后，也跟笔者一样在心里犯嘀咕：这个Map和Reduce是有什么特殊之处嘛？为什么是它们而不是别的接口？为啥一定要用这个范式编程呢？是倒排索引必须用MR才能建么？种种疑问即便是后来通读了Paper也未能完全理解。
不过这已经是现代了，让我们先回到2004年，看看为什么在没有日后这些高级Feature的情况下，谷歌依然要推出MapReduce并定义了整个开源大数据生态的模式。这里想说是：「 了解成功架构的缺点，才能真正理解其优点到底带来多大的收益，以至于可以抹杀掉所有的不足 」。MapReduce并不见得是一个好的编程范式（后来的发展也证明有各种更好的范式），它让算法实现变得复杂&教条，它只能实现很少一部分算法，它的性能可能比原问题的最优实现差之甚远。但是它在2004年的时候，让普通程序员使用大规模分布式计算变得非常简单！不需要了解Mpi，不需要了解分布式通信同步原理，写完Mapper和Reducer，你就能在上千台服务器的集群上运行程序，关键是还不用担心出现机器故障等等各种异常问题。
归根结底，MapReduce是一个妥协
关于GFS和MR要说的还有最后一点，那便是「 面向Workload的设计 」，谷歌在论文里也说了，整个大数据系统的设计与他们的搜索引擎业务息息相关：文件系统只会Append写而不会删除，读取主要是顺序读而不是随机读，需要MR的任务也以扫库建索引为主。而传统数据库、文件系统对于其他通用需求的支持，必然也导致它们在大数据处理这个任务下，不会是最优解。
【2005年】【数据】：Amazon Mechanical Turk
关于AMT和ImageNet这里想说3个点：
原来根本不用什么众包平台，每个在互联网上说过话的人，以及之前写过书的古人，其实都是在帮AI标数据 』。
借用NLP的Taxonomy，对CV的分类任务进行定义 」。
【2007年】【算力】：CUDA 1.0
真难用 」。是啊，毕竟已经被编译器和高级语言惯坏了这么多年了，突然跟你说写个程序还得思考GPU硬件是怎么运行的，还得手动管理高速缓存，稍微一不注意程序反而会变得死慢死慢，谁能喜欢得起来呢？而且更要命的是CUDA的浮点数精度问题。当年笔者第一次用CUDA，兴冲冲写完一个矩阵乘法后，一对比发现，咦？怎么结果差这么多，难道哪里写错了？排查半天无果，毕竟「 用CPU的时候，结果有错从来都是我的错不会是硬件的错 」。后来经同学指点，原来是CUDA的浮点数精度不够，需要用上Kahan Summation.就是下面这段代码：
另外，在此还要介绍一位曾经被Intel寄予厚望的主角： Xeon Phi。 Xeon Phi芯片最早发布于2010年，就是为了对抗CUDA而研发的众核架构。笔者在13年参加ASC超算比赛时，当年Intel免费赞助了一大批Phi并直接出了一道题让大家试用Phi。大家用完的体感嘛......方便是真方便，毕竟主打的是编译器包办所有事情，原有的高性能分布式代码一行不用改，直接适配众核架构。这也是Intel一直以来做CISC架构CPU和编译器的思路：「 底层实现复杂的指令集，编译器完成所有转译和优化 」，上层用户完全无感，每年付费即可享受摩尔定律的红利（值得一提的是，Intel的Icc高性能编译器和MKL库都是要额外付费的）。可惜的是，Phi的目标和愿景虽然很美好，但它的编译器和众核架构没有做到标称所说的，一键切换后，性能得到极大提升。Phi项目始终没有积累大量用户，也在2020最终关停。
编译器做得少 」。写CUDA时，所写即所得，不用再像写CPU高性能应用那样，时常需要编译出汇编码去检查向量化有没有生效、循环展开对不对。由于无法对CPU Cache进行直接管理，更是只能靠经验和实测来了解当前Cache的分配情况。这里也引出一个问题：「 编译器和语言设计一定要满足所有人的需求么？ 」想必不是的，找准这个语言的真正用户（高性能工程师）可能才是关键。
精度不重要 」，而且「 全是CUDA最擅长的基本矩阵运算 」。机器学习不需要双精度，直接单精度浮点数搞定，甚至在推理时连单精度都嫌多，半精度、int8、int4都能用。而在优化角度，也是打破了凸优化的所有传统认知：一个非凸优化问题，传统各种算法通通不需要。而且搞全量数据优化反而效果不好，SGD的mini-batch虽然会自带噪音，但噪音反而对训练有益。于是乎，GPU另一个软肋：显存受限，在mini-batch的算法下，也变得不是问题了。
【2012/2014年】【研发工具】：Conda/Jupyter
人生苦短，我用Python
虚拟环境管理 」变得极为容易。要知道，对于一个频繁需要复用开源软件包的开发领域，这绝对是一个Killer Feature。
而对于笔者来说，写Data相关Python实验代码的第一选择也早已不是IDE，而是Jupyter Notebook.原因很简单：处理图像、Dataframe、Json这样的数据，并且需要频繁「 迭代不同的算法策略 」时，「 代码怎么写取决于其内在数据格式和前面的算法结果 」。而数据和算法结果都是在运行时才能看到其具体形式，所以，「 一边运行代码一边写代码 」是数据处理、AI算法工程师的家常便饭。很多不理解这一点的Infra工程师，设计出来的框架或者工具，难免让人一言难尽。后面我们也会看到，在交互性和动态性上开倒车的Tensorflow，用户也在一点点的流失。
【小结】
-
框架 ：针对特定的Workload抽象出一个既有通用性，又满足一定约束的编程范式。使得执行引擎可以一站式提供诸如分布式计算、容灾容错、以及各种运维监控的能力。
-
研发工具 ：AI和数据算法研发期望在代码编写时是能实时交互反馈的；开源社区要求代码和其他生产资料能够被很容易地打包、发布、集成、以及版本管理。
-
数据 ：需要一个提供AI训练所需海量数据的工具或模式。
算力 ：需要强大的CPU/GPU为各种数值计算任务提供算力支持，同时编译器需要为高性能工程师提供良好的编程接口。
【2012年】【框架】：Spark
总而言之： Spark 用Scala、Python、SQL语言的极好交互式体验对笨重的Java实现了降维打击，并提供了更优的系统性能。 而人们也看到，只要「 用户体验 」足够好，即便是一个成熟的开源生态也是可以被颠覆的。开源大数据生态也因此进入了百花齐放的阶段。
【2013/2015/2016年】【框架】：Caffe/Tensorflow/Pytorch
一个是从框架设计方面的「 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，而框架支持的功能，往往又都是以往成功过的算法架构或是科学家提出了明确需求的架构。那么 真正的系统级创新如何发生呢 ？可能还真回到了阿里的老话：
因为相信，所以看见
A research idea wins because it is suited to the available software and hardware ”。
【2014年】【框架/算力/研发工具】：Parameter Server & Production Level Deep Learning
另一方面，训练引擎仅仅只是整个搜推广算法工程化的冰山一角。模型推理引擎，实时数据流，ABTest实验平台，容器调度平台等等都需要一整套完整的Infrastrature，这里写得最详细的当然是五福老师的 AI OS综述 。笔者也在下图大致梳理了在工业级机器学习应用中，面临的一些常见问题。
y = f(x 这个学习范式的每个细节都做到了极致，上图的每个小框都值得10+篇技术分享。而在GPT时代LLM、半监督学习范式以及未来前景广阔的AI应用中，阿里在这一块的积累一定可以得到迁移和复用，继续发光发热。
【2017年】【算力】：TVM/XLA
既然是编译器，则又会出现我们前文所说的，编译器用户是谁以及接口约定的问题。此外还有通用编译优化 vs. 专有编译优化的问题。比如搜推广业务，由于其模型结构的特殊性，往往就会自建专有编译优化，专门总结出某些优化Pattern以支撑模型迭代带来的海量推理算力需求。而通用的编译优化算法，其实很难将这些特定的Pattern抽象整合到优化规则中去。
实际能写出高性能代码的用户，一般还是需要对硬件的底层逻辑有充分的了解，并且了解编译器的实现逻辑以进行检查和验证。
【2020年】【数据/算力】：Tesla FSD
正当大家还在思考，AI有什么搞头时，这一年Andrej Karpathy带队的的Tesla突然放了大招，发布了纯视觉架构的Full Self-Driving无人驾驶方案，还直接在随后每年的Tesla AI Day上公布完整的技术方案：BEV感知、数据闭环Data Engine、端上FSD芯片，云端Dojo超大规模训练引擎等。一石激起千层浪，Tesla一下改变了行业的认知，在国内大部分自动驾驶公司的PR稿里，都能看到其影子。
可以说，Tesla把监督学习的工程架构又拔到了一个新高度：大规模的半自动标注引擎、大规模的主动难例数据收集、大规模的分布式训练和模型验证，底层的AI Infra支撑着几十个感知规控模型的持续迭代。
【2022年】【数据】：Unreal Engine 5
那UE 5是不是AI Infra呢？答案也是肯定的。首先，基于UE4的各种开源仿真渲染工具比如AirSim，CARLA早就在无人机、无人驾驶上被大规模用来生成训练数据。而在GTA里面训练无人车，在MuJoCo训练小人跑步(MuJoCo已在2021年被Deepmind收购也都不是新鲜事了。UE5如此革命性的更新，外加整个材质构建、3D模型产线的发展，也必然会让实时渲染仿真的效果一步步逼近真实的物理世界。
【2022年】【数据/研发工具】：HuggingFace融资1亿美元
不知不觉中，Hugging Face已经成为了AI（至少NLP）领域的Github for Data & Model。看到这里有同学要问了，搞了这么多年AI的人脸识别、搜推广、自动驾驶公司，从来都说数据就是最强壁垒，没听说过谁家会把最珍贵的数据和模型开源放到网上呀。但事情到了LLM、到了GPT这，却发生了本质性的改观。目前多模态大模型使用的这些数据，天然就是存在于互联网上的，本身就是Open的，获取比较容易（版权问题除外）。所以现在的模式变成了大家一点点地帮忙收集、整理数据，最终制作出了大量高质量的原始语料库（比如LAION组织的创始人就是一位 高中老师 ）。
【当下】：OpenAI有什么AI Infra？
不难看出，最大限度地让算法研发用上用好海量的算力资源，是OpenAI Infra的头号目的。另一方面，从AI and Compute和AI and Efficiency两篇文章中能看到，OpenAI花了不少精力在分析随着时间的演进，最强模型所需算力的增量曲线，以及由于算法改进而导致的算力效率变化曲线。而类似这样的分析，也在GPT-4的 Predictable scaling 中得到了体现。也就是说，给定训练算法，所消耗的算力与所能达到的智能程度是可被预测的 。这种「 算力算法Co-Design 」的指标就能很好地去指导算法研发 vs. 工程架构升级的节奏和方向。
【结语】
底层的算力层和底层的系统依然会是算法研发的基石 。
话都说到这里了，不发广告怎么行呢？我们是 高德视觉技术中心的训练工程平台团队，负责支持数据闭环、大规模训练、算法服务化等各种算法工程化需求。我们力求在AI2.0时代打造有技术差异性的 端云协同一体AI Infra，一方面会复用集团和阿里云大量的中间件，一方面会自建很多专用AI工具链。而 高德视觉，目前也成为了集团最大的视觉算法团队之一，支持高精地图、车道级导航、智能出行等多种业务，涉及感知识别、视觉定位、三维重建和渲染等多个技术栈。