GFS から GPT まで、AI インフラにおける 20 年間の興奮

導入

昨今、AIGCやLLMの波が次々と押し寄せており、AI業界が過去10年間に築き上げたパイを一夜にして完全に実現してしまう傾向が強い。AI インフラ(AI を構築するために必要なインフラストラクチャ) も議論の焦点の 1 つになっています。AI インフラに対する一般の注目は、A100/H100 のチップ封鎖など、AI のコンピューティング能力に集中することが多く、たとえば、マスク氏はさらに 10,000 個の GPU を購入しました。

コンピューティング能力が AI の波の重要な部分であることは間違いありませんが、AI インフラはコンピューティング能力だけに関係しているわけではありません。GPT が突然の成功ではなかったのと同様に、AI インフラ業界も長い期間の蓄積と反復を経験してきました。筆者は最近、同僚や友人たちと AI のさまざまな発展について話し合っていますが、AI インフラについて話すたびに、いつも頭の中に何千もの言葉が浮かんできますが、言葉にするのは難しいので、今日はすべてを書き留めることにしました。言いたい。

タイトルにもあるように、AI全体の開発はビッグデータと切り離せないものであり、ビッグデータの始まりは当然Googleの3大要素であるGoogle File System、MapReduce、BigTableです。GFS の論文は 2003 年、ちょうど 20 年前に発表されました。この20年は、ビッグデータ、AI、インターネットが急速に発展した20年でもありました。

この記事では、過去 20 年間の AI インフラのマイルストーンとなる出来事を整理してみます。なぜなら、私たちがその中にいると、誇大宣伝と実際的な情報を区別できないことが多く、また、地元のリーダーシップと最終的な勝利の間の構造的な戦いを明確に見ることができないからです。歴史を振り返り、長期的な変化を観察して初めて、いくつかのパターンが浮かび上がります。さっそく始めましょう!

ディレクトリインデックス

【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】【フレームワーク/計算能力/研究開発ツール】: パラメータサーバーとプロダクションレベルの深層学習

【2017】【計算能力】: TVM/XLA

【2020】【データ/コンピューティングパワー】: テスラ FSD

【2022】【データ】：Unreal Engine 5.0

[2022] [データ/R&D ツール]: HuggingFace が 1 億米ドルを調達

【現在】OpenAIにはどのようなAIインフラがあるのでしょうか？

【結論】

【2003/2004】【フレームワーク】: Google File System & MapReduce

2003 年に Google が発表した GFS 論文は、人類社会が正式にインターネットビッグデータの時代に突入したことを告げる、この 20 年間のドラマの始まりと言えます。小さなエピソードとしては、Google がこの論文を公開したにもかかわらず、オープンソースの実装がなかったということです。その結果、後に Apache Hadoop が「説明しにくい」パフォーマンスでオープンソースエコシステムを占拠しました (これは Spark の出現への道も開いた)オープンソースコミュニティは爆発的に発展し、その後のGoogleのオープンソースシステムに対する姿勢にも影響を与えたに違いありません。

GFS と MapReduce は分散コンピューティングの時代を切り開いたと言えますが、同時に従来のスタンドアロンのオペレーティングシステム、コンパイラ、データベースに加えて、「インフラストラクチャ」という言葉も徐々に一般的になりつつあります。ここでは GFS については多くは言いませんが、MapReduce の「問題と欠点」について説明することに焦点を当てたいと思います。初めて MapReduce プログラミングモデルを学んだ後、著者と同じように「この Map と Reduce の何がそんなに特別なのか?」と疑問に思った人がいるかどうかはわかりません。他のインターフェイスではなく、なぜそれらを使用するのでしょうか? なぜプログラミングにこのパラダイムを使用しなければならないのでしょうか? 転置インデックスは MR を使用して構築する必要がありますか? 論文を読んだ後でも、すべての質問を完全には理解できませんでした。

そして後で、不平を言っているのは私だけではなかったことに気づきました。2008年、まだチューリング賞を受賞していなかったデータベースの第一人者マイケル・ストーンブレイカーは、「MapReduce：大きな後退」を厳しく批判する記事を書き、西海岸の学校を名指しで直接批判した。新入生に MapReduce フレームワークを使用したプログラミング方法を教える予定です。」Stonebraker 教授の主な批判は、MR には従来のデータベースの多くの機能、特にスキーマと高レベル SQL 言語、インデックスクエリの高速化などが欠けているということです。私たちの Alibaba のクラスメートは、これを見てとても喜んだに違いありません。「おい、いつも言っていたこれらの機能、MaxCompute のレイクとウェアハウスの統合/SQL クエリ/自動アクセラレーションがすべて利用できるようになった! MR も素晴らしいものだ。」

しかし、これはすでに現代であり、2004 年に戻って、なぜ Google が依然として MapReduce を立ち上げ、将来これらの高度な機能を持たずにオープンソースのビッグデータエコシステム全体のモデルを定義したのかを見てみましょう。ここで私が言いたいのは、「成功したアーキテクチャの欠点を理解することによってのみ、その利点がどれほどの利益をもたらすかを真に理解できるので、すべての欠点を解消できる」ということです。MapReduce は、必ずしも優れたプログラミングパラダイムではありません (後の開発により、さまざまなより良いパラダイムがあることも証明されました)。アルゴリズムの実装が複雑かつ独断的になります。アルゴリズムのごく一部しか実装できず、そのパフォーマンスは元のパラダイムよりも優れている可能性があります。問題の最適な実装は、最適とは程遠いものです。しかし 2004 年には、一般のプログラマーが大規模分散コンピューティングを非常に簡単に使用できるようになりました。MPI や分散通信同期の原理を理解する必要はありません。Mapper と Reducer を作成した後は、数千台のサーバーからなるクラスター上でプログラムを実行できます。重要なのは、マシンの故障や障害を心配する必要がないことです。その他の異常な問題。

結局のところ、MapReduce は妥協です

MR は柔軟性とパフォーマンスを犠牲にしますが、ユーザーは安定した信頼性の高い分散コンピューティング機能を得ることができます。そして、その後の世代の AI インフラでは、さまざまな「妥協」が主要なテーマとなっています。しかし、現代のエンジニアリング技術の発展により、柔軟性、パフォーマンス、安定性の 3 つの側面で高いスコアを獲得するシステムが数多く存在することにも驚くべきことです。もちろん、新たな妥協点は依然として存在しますが、それが AI インフラまたは大規模コンピュータシステムの分野が魅力的な理由の 1 つです。

GFS と MR について最後に言うべきことが 1 つあり、それは「ワークロード指向の設計」です。Google も論文の中で、ビッグデータシステム全体の設計は自社の検索エンジンビジネスと密接に関連していると述べています。ファイルシステムは、追加書き込み削除されません。読み取りは、ランダム読み取りではなく、主に順次読み取りです。MR が必要なタスクは、主にデータベースのスキャンとインデックスの構築です。他の一般的なニーズに対する従来のデータベースやファイルシステムのサポートは、ビッグデータ処理のタスクにとって最適なソリューションではなくなることは避けられません。

さて、これを読んだ読者の中には、20 年前の GFS についてたくさん話してきたのに、私が気にかけている GPT はどこにあるのかと疑問に思う人もいるかもしれません。GPTを作成するにはどうすればよいですか? 20 年前のフレームワークの設計思想は、最新の AI インフラと根本的には変わらないかもしれません。

【2005年】【データ】: Amazon Mechanical Turk

時は 2005 年になりました。システム分野から離れて、AMT が世界にどのような驚きをもたらしたのかを見てみましょう。実は、Web1.0が始まった頃はインターネットバブル期でもあり、今の私たちの感覚と似ているのかもしれませんが、社会全体が狂った状態にありました。インターネットをベースにしたこのようなクラウドソーシングプラットフォームを構築するという突然のアイデアをアマゾンで誰が思いついたのかはわかりませんが、生徒に頼ってデータにラベルを付ける被験者を手作業で募集していた学校の研究機関の教師にとっては、これは大惨事でした。それ以来、スタンフォード大学の Fei-Fei Li チームは、AMT: ImageNet に基づいて CV 史上最大の画像分類データセットに注釈を付け始め、2010 年にコンテストを開催し始めました。ついに 2012 年に、AlexNet テクノロジーはすべての人に衝撃を与え、最初の A Deep を引き起こしました。学習革命。

AMT と ImageNet については次の 3 つのポイントがあります。

これまでの「データ」革命を振り返ってみると、その特徴は明らかで、そのたびに、データのアノテーションを取得するコストが大幅に削減されたり、データの規模が大幅に増大したりしてきました。人間がAIを研究するためにラベル付きデータを初めて簡単に大規模に入手できるようにしたのがAMT、つまりインターネットです。そして、2023 年の LLM までに、誰もがこの問題について実際に非常に明確に考えるようになりました。「クラウドソーシングプラットフォームはまったく必要ないことがわかりました。インターネット上で発言したことのあるすべての人、そして以前に本を書いた古代の人たちも同様です」、実際にはインターネット上にあります。「AI によるデータのラベル付けを支援します。」
多くの学生は、ImageNet に Net がある理由を知らないか、ImageNet の Net と AlexNet の Net が両方ともニューラルネットワークを指していると考えていますが、実際にはまったく知りません。ImageNet の元の論文はここで参照できますが、主に以前に WordNet という別のプロジェクトがあったためです。WordNet は、ナレッジグラフや大きな辞書に似た作品で、さまざまなカテゴリや概念が記録され、ネットワークに接続されています。ImageNet は、WordNet に基づいて 1000 のオブジェクトカテゴリを選択的に構築し、視覚的な分類タスクを設計します。現代の観点から、これはマルチモーダルグラフィックスとテキストと呼ばれますが、実際には、これは非常に初期から存在していたパラダイムです。「NLP から分類法を借用して CV の分類タスクを定義する」。
Fei-Fei Li には非常に興味深い履歴書が数多くありますが、その入り口がユニークであることが多いため、引用数は一般的にそれほど高くありません。また、Fei-Fei Li の弟子である Andrej Karpathy は誰にとってもよく知られているはずです。誰もが AK の論文を覚えていないかもしれませんが (彼が ImageNet の著者リストに載っていることすら知りません)、AK のブログと Github は非常に人気があります。初期の「ニューラルネットワークへのハッカーガイド」から最近の nanoGPT までの影響、AK の博士論文のタイトルは「画像と自然言語の接続」です。

【2007】【計算能力】: CUDA 1.0

2007 年、ゲーマーが Crysis を実行するためにどのグラフィックスカードを購入すればよいかまだ悩んでいたとき、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 はまったく考慮されていませんでした。インテルは高性能分野でも絶対的な支配力を持っています。

さらに、かつてインテルに大きな期待を寄せられた主人公、Xeon Phi を紹介したいと思います。Xeon Phi チップは 2010 年に初めてリリースされ、CUDA と競合するために開発されたメニーコアアーキテクチャです。著者が 2013 年に ASC スーパーコンピューティングコンペティションに参加したとき、インテルは多数の Phi を無料でスポンサーし、誰もが Phi を試すための質問を直接提供しました。誰もが使ったことがあるような気がします... 便利は本当に便利です結局のところ、重要なのはコンパイラがすべてを行うということです元の高パフォーマンスな分散コードを 1 行で変更する必要はなく、直接メニーコアアーキテクチャに適応しています。これは、CISC アーキテクチャの CPU とコンパイラに対するインテルの長年のアプローチでもあります。「最下層は複雑な命令セットを実装し、コンパイラはすべての変換と最適化を完了します。」上位レベルのユーザーはまったく無関心であり、ムーアの恩恵を享受できます。毎年支払うことで法律を適用できます (それだけの価値があります)。Intel の Icc 高性能コンパイラと MKL ライブラリには追加の支払いが必要であることに注意してください)。残念ながら、Phi の目標とビジョンは非常に優れていますが、そのコンパイラとメニーコアアーキテクチャはその主張に応えておらず、ワンクリックで切り替えるとパフォーマンスが大幅に向上しました。Phi プロジェクトは多くのユーザーを獲得することはなく、最終的に 2020 年に閉鎖されました。

一方で、CUDA は連勝を収めてきました。SIMD モードで高性能アプリケーションを作成する場合、実際には CUDA の方が CPU よりも優れていることがわかりました。その理由はまさに「コンパイラの処理が少ない」からです。CUDA を作成する場合、書いたものがそのまま得られるため、高性能 CPU アプリケーションを作成する場合とは異なり、ベクトル化が有効かどうか、ループの展開が正しいかどうかを確認するためにアセンブリコードをコンパイルする必要はもうありません。CPU キャッシュは直接管理できないため、現在のキャッシュ割り当てを理解するには経験と実際の測定に頼るしかありません。これはまた、「コンパイラと言語設計はすべての人のニーズを満たさなければなりませんか?」という疑問も生じますが、おそらくそうではありません。この言語の実際のユーザー (高性能エンジニア) を見つけることが鍵になるかもしれません。

この記事に最も関連するのは、CUDA が AI のような魔法の顧客を見つけたことです。AIアルゴリズムは本当に「数値解析」の先生を驚かせ、「凸最適化」の先生は血を吐くので、魔法だと言われています。なぜ？このような大規模な数値計算アプリケーションの場合、実際には、「精度は重要ではない」、「CUDA が最も得意とするのはすべての基本的な行列演算である」と言われています。機械学習には倍精度は必要なく、単精度浮動小数点数で直接学習できます。推論時には単精度でも十分ではなく、半精度、int8、int4 を使用できます。最適化の観点から見ると、これは凸最適化に対する従来の認識をすべて打ち破るものです。これは、さまざまな従来のアルゴリズムでは必要とされない非凸最適化問題です。さらに、データ全体の最適化は効果的ではなく、SGD のミニバッチには独自のノイズが含まれますが、そのノイズはトレーニングには有益です。その結果、GPU のもう 1 つの弱点であるビデオメモリの制限は、ミニバッチアルゴリズムの下ではそれほど問題ではなくなりました。

つまり、CUDA と GPU は AI のために生まれたようで、その欠点が最終的に機能となり、Huang をキッチンの大君主、そして核爆弾の王へと変えたのです。そして現在、国を挙げて自社開発チップの開発に取り組んでいる私たち人間は、CUDA がリリースされてから 16 年間で、基礎となるチップに加えて、ソフトウェア層のツールチェーンやユーザーの習慣、ユーザーエコロジーが進化したことを忘れてはなりません。 0から1まで一歩ずつ。将来的には GPU は 1 社だけになるのでしょうか? TPU/NPU/PPU はコーナーで追い越しますか? 待ってみましょう。

【2012/2014】【研究開発ツール】: Conda/Jupyter

フレームワーク、データ、コンピューティング能力について話した後、AI 研究開発ツールについて見てみましょう。ここで議論しなければならない疑問は、なぜ AI の主流言語が Python なのかということです。実はAIだけでなくPythonの人気も年々高まっています。オープンソースコミュニティは、プロジェクトに Python インターフェイスを提供すると、ユーザーの使用量が大幅に増加し、誰もが Python インターフェイスを使用する傾向が高まることを長い間認識していました。なぜなら、コンパイル不要の動的スクリプト言語の魅力は本当に大きいからです。ここで多くを語る必要はありません。結局のところ、誰もが知っています。

人生は短い、私は Python を使っています

Python エコシステム自体も常に改善されており、Pip ベースのパッケージ管理はすでに非常に便利ですが、2012 年の Conda のリリース以降、「仮想環境の管理」が非常に簡単になりました。オープンソースソフトウェアパッケージを頻繁に再利用する必要がある開発分野にとって、これは間違いなくキラー機能です。

パッケージ管理に加えて、Python におけるもう 1 つの大きな進歩は、IPython ベースの Jupyter です。これは、Python のすでに使いやすい対話型関数を新しいベンチマークに引き上げ、誰もが愛する Jupyter Notebook を作成します。Notebook が AI インフラとしてカウントされるかどうかについては、Google の Colab、現在のさまざまな AI オープンソースプロジェクトのガイダンスチュートリアル、および独自の PAI-DSW を参照すると、Notebook がすでに AI 研究開発と知識共有に不可欠な部分であることがわかります。。バックエンドクラスターを分離する Web サイドの R&D エクスペリエンスにより、ユーザーは大規模なコンピューティングリソースをワンストップで制御できるようになり、Vim を使用したり、リモートでコードを同期したりする必要がなくなります。

著者にとって、データ関連の Python 実験コードを書くための最初の選択肢は IDE ではなく、Jupyter Notebook です。理由は非常に単純です。画像、Dataframe、Json などのデータの処理には、頻繁な「異なるアルゴリズム戦略の反復」が必要です。現時点では、「コードがどのように記述されるかは、その固有のデータ形式と以前のアルゴリズムの結果によって決まります。」データの特定の形式とアルゴリズムの結果は実行時にのみ確認できるため、データ処理および AI アルゴリズムのエンジニアにとって、「コードを実行しながらコードを記述する」ことは日常的です。これを理解していない多くのインフラエンジニアは、必然的に説明が難しいフレームワークやツールを設計することになります。また、インタラクティブ性とダイナミクスの点で後退した Tensorflow も、少しずつユーザーを失いつつあることも後でわかります。

【まとめ】

これまでの 4 つの分野の代表的な研究を紹介することで、AI インフラの全体像のプロトタイプを理解することは難しくありません。

計算能力: さまざまな数値計算タスクの計算能力をサポートするには強力な CPU/GPU が必要であり、コンパイラーは高性能エンジニアに優れたプログラミングインターフェイスを提供する必要があります。
フレームワーク: 普遍的であり、特定のワークロードに対する特定の制約を満たすプログラミングパラダイムを抽象化します。実行エンジンは、分散コンピューティング、ディザスタリカバリ、フォールトトレランスなどのワンストップ機能や、さまざまな運用・保守監視機能を提供できます。
研究開発ツール: AI およびデータアルゴリズムの研究開発では、コードを記述するときにリアルタイムでインタラクティブなフィードバックが期待されます。オープンソースコミュニティでは、コードやその他の制作資料が簡単にパッケージ化、リリース、統合、バージョン管理できることが求められます。
データ: AI トレーニングに必要な大量のデータを提供するツールまたはモデルが必要です。

これらの考えを念頭に置くと、その後の AI インフラ開発の基本的な背景を明確に理解するのは実は簡単です。

【2012】【フレームワーク】：Spark

まだ 2012 年ですが、この年、バークレーの Matei Zaharia 氏が有名な Resilient Distributed Datasets の論文を発表し、Spark フレームワークをオープンソース化しました。Spark は、Hadoop エコシステムの「遅い」「使いにくい」という問題を完全に変えました。Scala と Pyspark/Spark SQL の人気により、プログラミング言語の分野における最新開発の多くが大きな言語に導入されました。データオープンソースコミュニティ。実際のところ、現時点では、RDD がインメモリであるかどうかは最も重要ではない可能性があり、結局のところ、ほとんどのジョブは反復的ではありません。ただし、Scala インタラクティブシェルの助けを借りて実装された Spark シェルは、Hadoop にとってそれ自体が破壊的であり、タスクを数分で簡単に開始できます (Java ベースの MR インターフェイスを毎日作成しているクラスメートに、Python コマンド What を使用できるようになりました、と伝えることを考えてください)業界でビッグデータコンピューティングに携わるのは似ていますか?) Scala のさまざまな構文糖や大規模な演算子のサポートは言うまでもありません。

全体として、Spark は Scala、Python、SQL 言語を使用して優れたインタラクティブなエクスペリエンスを提供し、煩雑な Java の次元を削減し、より優れたシステムパフォーマンスを提供します。そして人々はまた、「ユーザーエクスペリエンス」が十分に優れている限り、成熟したオープンソースエコシステムでさえも破壊される可能性があることを目の当たりにしました。したがって、オープンソースのビッグデータエコシステムは、百花が咲く段階に入っています。

【2013/2015/2016】【フレームワーク】: Caffe/Tensorflow/Pytorch

2013 年、一般の人々が考えていたものに最も近い AI インフラの仕事が登場します。それが Jia Yangqing と Daniu のオープンソース Caffe であり、それ以来、深層学習の敷居は大幅に下がり、モデル設定ファイルを通じてネットワークを構築し、トレーニングを完了し、GPU の計算能力を利用できるようになりました。一時は、モデルの革新が爆発的な時代を迎えました。実は同時期のオープンソースフレームワークにはTheanoやLuaベースのTorchもあったのですが、利用方法が異なっていました。その後、大手企業が続々と参入し、2015年にGoogleがTensorflow、2016年にFBがPyTorchをリリースし、将来的にはAmazonが推奨するMxNet、BaiduのPaddlePaddleと合わせて、機械学習フレームワークは百社争奪の時代を迎えた。思想の学派。機械学習フレームワークについては議論できる点が多すぎて、公開情報もたくさんありますが、ここではそのうちの 2 つについてのみ説明します。

1 つは、フレームワーク設計の観点から見た「象徴的 vs. 命令的」です。この議論は、MxNet のテクノロジーブログ「Deep Learning Programming Paradigm」にまで遡ることができます。MxNet は両方のモードをサポートする最初のフレームワークでもあり、ブログで指摘されています。Imperative はより柔軟で使いやすく、Symbolic はパフォーマンスが優れています。他のフレームワークの初期バージョンを見て、Tensorflow はシンボリック、PyTorch は命令型というパラダイムの 1 つに焦点を当てます。以下の内容については誰もが知っているように、Pytorch は Python 言語の利点を完全に継承しており、その柔軟性と科学研究への適合性で常に知られています。TF はエンジニアリングの導入に適していますが、対話性が犠牲になっています。長い期間の反復を経て、2 つのパラダイムは基本的に収束しました。TF は Eager モードもサポートしており、後に新しいフレームワーク Jax を直接起動しました。Pytorch は、TorchScript や Torch.fx などのシンボリックグラフをエクスポートして操作することもできます。MapReduce が妥協であるのと同様に、各機械学習フレームワークも「使いやすさ」と「パフォーマンス」に関してある程度の妥協をしています。しかし全体としては、Imperative に重点を置き、Python の使用習慣と一致している Pytorch が、ユーザー数の点で依然として徐々にピークを占めています。もちろん、結論を出すには時期尚早です。機械学習フレームワークの開発と反復はまだ終わっていません。

もう 1 つ議論できる点は、「機械学習フレームワークの進化とアルゴリズムの進化」の関係です。この点を議論する理由は、多くのアルゴリズム開発チームとエンジニアリングフレームワークチームが甲と乙の作業モデルに慣れているためです。フレームワーク開発とフレームワークのアップグレードは次のように理解されます: 特定のモデルやアイデアを実装するために、アルゴリズム科学者は既存のフレームワークがそれをサポートできないことに気づき、オペレーター Op の実装、新しい分散コンピューティングパラダイム、パフォーマンスの最適化が必要です。このモデルには多くの欠点があります。たとえば、局所的な小規模なイノベーションしかサポートできず、イノベーションサイクルが非常に長くなる可能性があります。エンジニアリングチームからよく不満を漏らされる可能性さえあります。「最後の要件は完了していませんが、アルゴリズム側も新しいものに置き換えられた「アイデア」。したがって、アルゴリズムチームとエンジニアリングチームの間のコラボレーションモデルをどのように磨くかは、非常に重要なテーマです。たとえば、共同設計方法論では、双方が自分自身を視野に入れ、技術的なパスを事前に予測する必要があります。たとえば、エンジニアリングチームは、科学者が機能コードを実装するのを支援することに日々の仕事を回すことはできません。代わりに、科学者が自分で探索できるように、柔軟な上位層のインターフェイスを提供する必要があります。フレームワーク層は、行き詰まったエンジニアリングおよび技術的な問題の解決に重点を置いています。そして最も重要なことは、両者が次のことを認識する必要があるということです。「現在のモデル構造とフレームワークの実装は、歴史的な音声プロセスにおける単なる偶然である可能性がある」、そして「モデルの設計とフレームワークの実装は、今後も互いの進化の過程に影響を与え続けるだろう」ということです。

その理由も非常に単純で、モデル革新の最前線には鶏が先か卵が先かという問題があり、アルゴリズム科学者は既存のフレームワークで実装できるアイデアしか実装して検証できず、フレームワークでサポートされている機能は多くの場合成功します。アルゴリズムアーキテクチャが通過したか、科学者が明確な要件を提示したアーキテクチャ。では、真のシステムレベルのイノベーションはどのようにして起こるのでしょうか? おそらくそれはアリの古い格言に戻っているのかもしれません。

信じるから分かる

さらに、アルゴリズムとフレームワークの共生関係も、近年多くの議論を引き起こしています。たとえば、最近よく議論されているのは、なぜ LLM が Decoder Only アーキテクチャなのかということです。また、「利用可能なソフトウェアとハードウェアに適合する研究アイデアが勝つ」という記事「ハードウェア宝くじ」もあります。

全体として、機械学習フレームワークにとって、「フレームワーク」の意味は、エンジニアがさまざまな Data ETL 機能を実現するのに役立つ、MapReduce/Spark などのビッグデータフレームワークの範囲をはるかに超えています。アルゴリズムとモデル自体の形式は変化し、革新されているため、フレームワークが制限的すぎると、アルゴリズムの反復と革新が制限されてしまいます。

【2014】【フレームワーク/計算能力/研究開発ツール】: パラメータサーバーとプロダクションレベルの深層学習

オープンソースコミュニティの枠組みは AI の新たな波を引き起こし、大手インターネット企業の検索およびプロモーションビジネスでは、ディープラーニングの成功を従来の Ctr アルゴリズムで再現できるかどうかを誰もが疑問に思い始めています。答えは「はい」です！基本的にすべての大手メーカーが関連する研究開発を開始しています。ここで広告を作成しましょう。私がよく知っている Alimama のディスプレイ広告ビジネスラインを例に挙げます。2013年のMLRから、その後の大規模分散トレーニングフレームワークXDL、DINおよびSTARに至るまで、プロモーションを求める学生は非常に興味を持っているはずです。よく知っています、理解しています。オープンソースフレームワークは、大規模な埋め込みテーブルや信頼性の高い分散トレーニングをサポートしていません。これにより、独自開発のパラメーターサーバーのようなフレームワークを開発する余地も与えられます。大規模な分散トレーニングフレームワークも、近年の検索プロモーションアルゴリズムの反復の主な推進力となっています。上で述べたように、モデルの高頻度反復と大規模なプロモーションの正規化と効率向上の文脈では、アルゴリズムの革新とフレームワークの進化は複雑な共生関係にあります。また、Huai 先生が書いた広告レコメンデーションテクノロジーを読むことをお勧めします。 Ren . 開発サイクルは、アルゴリズムアーキテクチャ全体の進化を完全に表します。

一方、トレーニングエンジンは、検索プロモーションアルゴリズム全体を設計する上での氷山の一角にすぎません。モデル推論エンジン、リアルタイムデータフロー、ABTest 実験プラットフォーム、コンテナスケジューリングプラットフォームなどはすべて、完全なインフラストラクチャセットを必要とします。ここで最も詳細に書かれているものは、もちろん Wufu 先生の AI OS 概要です。著者はまた、産業レベルの機械学習アプリケーションで直面する一般的な問題のいくつかを次の図に大まかに整理しています。

ここで言わなければならないのは、Sou が推進する Ctr モデルは、インターネットビジネスと収益に密接に関係しているため、常に大手メーカーの技術的高地であり続けているということです。無数の人々が時間をかけて継続的に磨きをかけてきた結果、 y = f(x)の学習パラダイムのあらゆる詳細が極限まで達成されたと言えます。上の写真の小さなボックスのそれぞれは、10 以上の技術共有記事に相当します。GPT 時代、LLM、半教師あり学習パラダイム、および幅広い将来性を備えた AI アプリケーションにおいて、この分野におけるアリババの蓄積は間違いなく移行および再利用され、輝き続けることができます。

【2017】【計算能力】: TVM/XLA

2017 年が到来し、TVM と XLA の両方が今年リリースされました。AI コンパイラーのトピックは個別に議論する価値があります。主に使いやすさの問題を解決する機械学習フレームワークとは異なり、AI コンパイラーはパフォーマンスの最適化とコンピューティングチップの最適な適応の問題の解決に焦点を当てています。一般に、モデル推論のパフォーマンスは、単一の演算子の基礎となる計算コードを生成するか、計算グラフを再編成および結合することによって向上します。チップの供給が途絶え、自社開発チップが全盛となっている現在、AI コンパイラーは AI インフラの中で最も急速に成長している分野の 1 つとなっています。アリババの PAI チームのヤンジュン先生も、AI コンパイラーに関するレビューを書きました。

コンパイラーなので、コンパイラーのユーザーが誰であるか、先ほど述べたインターフェースの取り決めなどの問題が発生します。さらに、一般的なコンパイルの最適化と独自のコンパイルの最適化という問題もあります。たとえば、検索およびプロモーションビジネスでは、そのモデル構造の特殊性により、多くの場合、独自のコンパイルと最適化を構築し、モデルの反復によってもたらされる膨大な推論コンピューティング能力要件をサポートするために、特定の最適化パターンを具体的に要約します。一般的なコンパイル最適化アルゴリズムと同様に、これらの特定のパターンの抽象化を最適化ルールに統合することは実際には困難です。

一方で、AI コンパイラーのグラフ最適化アルゴリズムは、モデルを少し変更すると元の最適化ルールが当てられなくなる可能性があるため、一般のアルゴリズム学習者にとっては使いにくいことが多いです。打てない理由は明らかにされないことが多い。これは、前述の CPU 高性能コンパイラの問題に戻りますが、このコンパイラは非常に強力で多機能であるように見えますが、ハードウェアの詳細が隠蔽される可能性があります。ただし、実際に高性能のコードを作成できるユーザーは、通常、ハードウェアの基礎となるロジックを完全に理解し、検査および検証のためにコンパイラーの実装ロジックを理解している必要があります。

では、AI コンパイラーは、torch.compile のように初心者ユーザーがワンクリックでパフォーマンスを向上させるのに役立つのでしょうか、それとも基礎的な認識力を持つ高性能モデルエンジニアの研究開発効率を向上させる単なる自動ツールなのでしょうか? たとえば、OpenAI は 2021 年に、Python 構文を使用して CUDA のような GPU プログラミングをより便利に実行できる Triton もリリースしました。Triton のような作業では、プログラマーが GPU マルチスレッドモデルの原理を一般的に理解している必要があるだけでなく、参入障壁も大幅に低くなります。TVM も常にアップグレードされており、たとえば、 Tianqi 著の「新世代深層学習コンパイル技術の変更点と展望」を参照してください。AI コンパイラーが今後どのように発展していくのか、注目してみましょう。

【2020】【データ/コンピューティングパワー】: テスラ FSD

21 世紀も 30 年目に入り、AI 分野に対する世間の認識はやや鈍くなっています。最後のウェーブで AlphaGo によってもたらされた RL 革命は、実際のシナリオでは多くのメリットを達成していないため、L4 無人運転もボトルネックに陥り、以前に他の AI によって描かれたケーキはまだ紙の上にあります。Sou Promotion のエンジニアリングアーキテクチャも 3.0 から 4.0、そして 5.0、6.0、7.0 と進化してきました。

AI が何をしようとしているのかについて誰もがまだ考えていたとき、今年、アンドレイカルパシー率いるテスラは突然大きな動きを見せ、純粋にビジュアルなアーキテクチャを備えた完全自動運転ドライバーレスソリューションをリリースしました。ソリューション: BEV センシング、データ閉ループデータエンジン、オンエンド FSD チップ、クラウド Dojo 超大規模トレーニングエンジンなど。テスラは業界の認識を一石で変え、その影はほとんどの国内自動運転会社の PR 草案に見られます。

テスラ AI デイの写真

Tesla は教師あり学習のエンジニアリングアーキテクチャを新しいレベルに引き上げたと言えます。大規模な半自動ラベリングエンジン、大規模なアクティブなハードケースデータ収集、大規模な分散トレーニングとモデル検証、そしてその基盤となる AI です。インフラストラクチャは、10 個の知覚制御モデルの複数の連続反復をサポートします。

【2022】【データ】：Unreal Engine 5

時は 2022 年 4 月になり、ChatGPT は 8 か月後に戦場に登場し、UE5 は今月正式にリリースされます。注意を払っている学生は、Nanite の超大規模な三角形パッチのリアルタイムレンダリングと Lumen のダイナミックなグローバルイルミネーションの効果が非常に素晴らしいことを知っているはずです。公式デモ「The Matrix Awakens」では、リアルタイムレンダリングが現在どのレベルに到達できるかを確認することもできます。

添付の画像は Unreal Engine 公式 Web サイトからのものです

では、UE 5 は AI インフラですか? 答えも「はい」です。まず、AirSim や CARLA などの UE4 ベースのさまざまなオープンソースシミュレーションレンダリングツールは、ドローンや無人運転のトレーニングデータを生成するために長年にわたって大規模に使用されてきました。GTA で無人車両を訓練したり、MuJoCo で悪役を走らせる訓練をしたりすることは、何も新しいことではありません (MuJoCo は 2021 年に Deepmind に買収されました)。UE5 のこのような革命的なアップデートは、マテリアル構造全体と 3D モデル生産ラインの開発と相まって、リアルタイムレンダリングシミュレーションの効果を現実の物理世界に徐々に近づけることは避けられません。

さて、将来的には DeepMind + MuJoCo + UE5 がさらに普及する日が来るのでしょうか? 様子を見ましょう。

[2022] [データ/R&D ツール]: HuggingFace が 1 億米ドルを調達

AI や GPT に注目している学生は、この笑顔を最近よく見たはずですが、Hugging Face は具体的に何をするのでしょうか。また、なぜこれが AI インフラの重要な部分となり、2022 年に 1 億元の資金調達に成功するのでしょうか? OpenCrawl、Pile、Bigscience、Bigcode、PubMed などのプロジェクトを知っている場合は、LLM トレーニングデータも学習している必要があります。そして、大量のコーパスデータが分類されて Hugging Face に掲載されていることに驚くでしょう。彼らはまた、Datasets と呼ばれる Python パッケージも作成しました。

無意識のうちに、Hugging Face は AI (少なくとも NLP) 分野のデータとモデルの Github になりました。「これを見て、学生の中には聞きたくなる人もいます。長年AIに取り組んでいる顔認証、検索推進、自動運転の企業は、データが最も強い障壁だと常々言ってきました。最も貴重なデータを作っている人がいるなんて聞いたことがありません」そしてオープンソースモデルをオンラインに公開します。しかし、LLM と GPT に関しては根本的な変化がありました。現在、大規模なマルチモーダルモデルで使用されているデータは、当然ながらインターネット上に存在しており、(著作権の問題を除けば) オープンで簡単に入手できます。そこで、みんなで協力して少しずつデータを収集・整理し、最終的には質の高いオリジナルコーパスを大量に生み出すというのが現在のモデルになっています（例えばLAION組織の創設者は高校教師）。

実際、LLM と AGI の将来のパターンは、データ + 計算能力 + アルゴリズムになる可能性が高く、従来の AI の 3 つの要素のうち、オープンソースによる障壁はデータだけではない可能性があります。ハードウェア、最後の競争はアルゴリズムです。そして、AI インフラに基づく反復速度が向上します。

[現在]: OpenAI にはどのような AI インフラストラクチャがありますか?

では、AI インフラは GPT の構築にどのように役立つのでしょうか? OpenAI の公開されたアーキテクチャから判断すると、基本的には上記のすべての側面が関係しています。コンピューティングとソフトウェアエンジニアリングの 2 つのトピックの下には、OpenAI 自体が公開している AI インフラに関する多数のブログも表示されます。それらの多くは、コンピューティング能力とアルゴリズムの共同設計の方向にあります。たとえば、OpenAI が管理する K8S クラスターは、2021 年の初めに 7,500 ノードの規模に達しました (4 年前は 2,500 ノード)。そして 7 月 21 日、Python 構文を使用して高性能 GPU プログラミングを実装できるコンパイラーである前述の Trition がオープンソース化されました。2022 年には、大規模な分散トレーニングのテクニックを紹介するために多くの紙面を費やしました。

アルゴリズム開発のために大規模なコンピューティングリソースを最大限に活用することが OpenAI インフラストラクチャの最大の目標であることを理解するのは難しくありません。一方で、「AI とコンピューティング」および「AI と効率」の 2 つの記事からわかるように、OpenAI は、時間の経過に伴う、およびアルゴリズムの改善により、最も強力なモデルに必要なコンピューティング能力の増加曲線の分析に多大なエネルギーを費やしてきました。結果として得られるコンピューティング電力効率の変化曲線。このような分析は、 GPT-4 のPredictable Scalingにも反映されています。言い換えれば、トレーニングアルゴリズムがあれば、消費されるコンピューティングパワーと達成されるインテリジェンスのレベルを予測できます。この「コンピューティングアルゴリズムの共同設計」指標は、アルゴリズム開発とエンジニアリングアーキテクチャのアップグレードのリズムと方向性を適切に導くことができます。

コンピューティング能力に加えて、AI オープンソースコミュニティも急速に進歩しており、その多くが GPT の出現に貢献したはずです。Hugging Face 以外にも、多くの優れた AI スタートアップが出現していますが、ここでは各企業の取り組みと意義を詳細に分析する時間がありませんでした。しかし、変化はすでに起こっており、数週間のペースで新しいことが生まれています。

【結論】

ここ数カ月のAIの開発スピードは、確かに著者のこれまでの知識をはるかに超えていた。AI 2.0 の時代が到来したことは疑いの余地がなく、純粋な教師あり学習に基づく前世代のパラダイムではもはや十分ではありません。AIが描いたケーキもみんなで食べて、とても美味しかったです！AI実践者として、私もこの数カ月間、胸が高鳴りました。この記事を読んでもまだ GPT を作成することはできませんが、過去 20 年間の AI インフラの発展を見てきたはずです。AI アルゴリズムが将来どのような方向に進むとしても、基盤となるコンピューティングパワー層と基盤となるシステムは依然としてアルゴリズム開発の基礎となります。

この20年の発展を振り返ると、2003年から2013年の10年間はWeb1.0の時代であり、著者もまだ子供でしたが、13歳から23歳まではAI1.0の発展の波を目の当たりにし、 Web2.0、でもそれ以上ほとんどの場合、彼らはメロンを食べるだけの人々です。これからの10年は当然AI2.0、Web3.0の革命の10年となるが、10年後の世界は筆者には想像できない。しかし、唯一確かなことは、今度は私がついにそれに全面的に参加し、同じ志を持った友人たちと協力して業界に影響を与えることができることを行うことができるということです。

そうは言っても、広告なしでどうやってやっていけるのでしょうか？私たちはAutoNavi Vision Technology Center のトレーニングエンジニアリングプラットフォームチームであり、データクローズドループ、大規模トレーニング、アルゴリズムサービス化など、さまざまなアルゴリズムエンジニアリングニーズのサポートを担当しています。当社は、グループ内およびAlibaba Cloudの多数のミドルウェアを再利用する一方で、AI 2.0時代における技術的に差別化されたデバイス・クラウド連携型AIインフラの構築を目指します。多くの専用 AI ツールチェーン。Amap Vision は現在、グループ最大のビジュアルアルゴリズムチームの 1 つとなり、知覚認識、ビジュアルポジショニング、3 つの技術スタックなどの複数のテクノロジースタックを活用して、高精度地図、車線レベルのナビゲーション、スマートトラベルなどのさまざまなビジネスをサポートしています。 -次元の再構築とレンダリング。

具体的な採用ニーズは以下のとおりですが、この他にもJDでは言いにくいニーズも多数お待ちしております。

機械学習プラットフォーム MLOps 研究開発エンジニア: https://talent.alibaba.com/off-campus-position/980607

アルゴリズムエンジニアリングサービス R&D エンジニア: https://talent.alibaba.com/off-campus-position/980608

分散トレーニング最適化エキスパート: https://talent.alibaba.com/off-campus-position/980705

上記に共感していただける方、プログラミングが大好きな方、「週末はC++の勉強をしたい」という方には、きっとぴったりのポジションがここにあります！Amap Vision ファミリーへようこそ! また、この本を必要としている学生に推薦したり、渡したりしてくださる方も歓迎します。

フレンドリーコール

Amap、3D再構成/生成AIアルゴリズムエンジニアを緊急募集: https://talent.alibaba.com/off-campus-position/979029

Amap、SLAMアルゴリズム/知覚アルゴリズムの専門家を緊急募集: https://talent.alibaba.com/off-campus-position/973417

https://talent.alibaba.com/off-campus-position/991613

詳細については、「Amap テクノロジー」をフォローしてください