最近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全貌的雛形：
-
算力 ：需要強大的CPU/GPU爲各種數值計算任務提供算力支持，同時編譯器需要爲高性能工程師提供良好的編程接口。
-
框架 ：針對特定的Workload抽象出一個既有通用性，又滿足一定約束的編程範式。使得執行引擎可以一站式提供諸如分佈式計算、容災容錯、以及各種運維監控的能力。
-
研發工具 ：AI和數據算法研發期望在代碼編寫時是能實時交互反饋的；開源社區要求代碼和其他生產資料能夠被很容易地打包、發佈、集成、以及版本管理。
-
數據 ：需要一個提供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工具鏈。而 高德視覺，目前也成爲了集團最大的視覺算法團隊之一，支持高精地圖、車道級導航、智能出行等多種業務 ，涉及感知識別、視覺定位、三維重建和渲染等多個技術棧。