TensorFlow と同様に、NVIDIA の CUDA 独占は崩れるのでしょうか?

過去 10 年間で、機械学習ソフトウェア開発の状況は大きく変化しました。多くのフレームワークが登場していますが、そのほとんどは NVIDIA の CUDA に大きく依存しており、NVIDIA の GPU で最高のパフォーマンスを実現します。しかし、PyTorch 2.0 と OpenAI Triton の登場により、この分野における Nvidia の優位性は崩れつつあります。

Google は初期の頃、機械学習モデルのアーキテクチャ、トレーニング、モデルの最適化において大きな利点を持っていましたが、現在ではこれらの利点を十分に活用することが困難になっています。ハードウェア面では、他の AI ハードウェア企業が Nvidia の優位性を弱めることは困難でしょう。 PyTorch 2.0 と OpenAI Triton が登場するまで、機械学習モデルのデフォルトのソフトウェア スタックは Nvidia のクローズドソース CUDA ではなくなります。

TensorFlow 対 PyTorch

同様の競争が機械学習フレームワークでも発生します。数年前、フレームワーク エコシステムはかなり細分化されていましたが、TensorFlow が最有力候補でした。表面的には、Google は機械学習フレームワーク業界にしっかりと参入しているように見えますが、TensorFlow を使用して AI アプリケーション固有のアクセラレータ TPU を設計し、先行者利益を獲得しました。

しかしながら、現在では PyTorch が勝利し、Google はその最初の利点を活かすことができなかったようです。推進者の利点 新興 ML 業界で支配的な地位を確立します。 Google は、PyTorch と GPU を使用せず、代わりに独自のソフトウェア スタックとハードウェアを使用しているため、最近の機械学習コミュニティではやや孤立しているようです。実際、Google は TensorFlow と直接競合する 2 番目の機械学習フレームワーク JAX を開発しました。これは典型的な「Google の動作」です。

大規模言語モデル、特に OpenAI の大規模言語モデルや OpenAI API を使用して構築されたさまざまな言語モデルの台頭により、Google の検索と自然言語処理の優位性は高まっていると考える人もいます。衰退する。おそらく、この見方は悲観的すぎるでしょう。結局のところ、ほとんどの現行モデルのインフラストラクチャは依然として Google によって開発された変圧器です。

では、なぜ PyTorch が大きな勝者なのでしょうか?その主な理由は、PyTorch が TensorFlow に比べて柔軟性と使いやすさが高いためです。 PyTorch と TensorFlow の主な違いは、Graph モードの代わりに Eager モードを使用することです。

Eager モードは、通常の Python コードと何ら変わらない標準的なスクリプト実行方法と言えます。これにより、ユーザーは中間操作の結果とモデルがどのように実行されているかを確認できるため、コードのデバッグと理解が容易になります。

対照的に、グラフ パターンは 2 つのフェーズに分かれています。最初のステージは、操作が実行される計算グラフを表します。ノードは操作または変数を表し、ノード間のエッジはノード間のデータ フローを表します。第 2 段階は、計算グラフの最適化されたバージョンの遅延実行です。

この 2 段階のアプローチでは、グラフの実行が終了するまでユーザーは何が起こっているかを見ることができないため、コードの理解とデバッグがより困難になります。これは、Python と C など、「インタープリタ型」言語と「コンパイル済み」言語の比較に似ています。Python はインタープリタ型言語であるため、デバッグが簡単です。

TensorFlow もデフォルトで Eager モードを使用するようになりましたが、研究コミュニティとほとんどの大手テクノロジー企業は PyTorch の使用を選択しています。

機械学習トレーニング コンポーネント

機械学習モデルのトレーニングを最も単純な形に単純化すると、機械学習モデルのトレーニングに影響を与える主な要素は次のとおりです。 : 2 つのポイント:

計算 (FLOPS): 各層内で密な行列の乗算を実行する;
• メモリ帯域幅。

これまで、機械学習のトレーニング時間に影響を与える主な要因は、システムが行列乗算を実行するのを待つ計算時間でした。 Nvidia GPU が進化し続けるにつれて、これはすぐに大きな問題ではなくなります。

NVIDIA はムーアの法則を活用して FLOPS を桁違いに改善しましたが、主なアーキテクチャ上の変更はテンソル コアと低精度浮動小数点形式でした。比較すると、ストレージの面では大きな変化はありません。

2018 年、最新モデルは BERT であり、NVIDIA V100 が最新の GPU でした。乗算はすでにモデルのパフォーマンスを向上させる主な要素ではなくなりました。その後、モデルのパラメータ数は 3 ～ 4 桁増加し、最速の GPU では FLOPS が 1 桁増加しました。

2018 年であっても、純粋なコンピューティング依存のワークロードは FLOPS の 99.8% を占めましたが、実行時間のわずか 61% でした。行列乗算と比較すると、正規化およびポイントワイズ演算は行列乗算の FLOPS の 1/250 および 1/700 のみを使用しますが、モデル実行時間のほぼ 40% を消費します。

##記憶の壁

モデルの規模が高騰を続ける中、大規模言語モデル (LLM) は、モデルの重みだけで 100 GB を超えるメモリを必要とします。 Baidu と Meta が展開する製品推奨ネットワークは、大規模な埋め込みテーブルを保存するために数十テラバイトのメモリを必要とします。大規模なモデルのトレーニング/推論におけるほとんどの時間は、行列の乗算の計算に費やされるのではなく、データが転送されるのを待つのに費やされます。明らかに問題は、アーキテクトがなぜメモリをコンピューティングの近くに配置しないのかということですが、答えは明白です - コストです。

#通常、最も近い共有メモリ プールは、同じチップ上の SRAM です。一部の機械学習 ASIC は、モデルの重みを保持するために巨大な SRAM プールを活用しようとします。しかし、Cerebrasの約500万ドルのウェハスケールチップでさえ、SRAMは40GBしか搭載していない。メモリ容量が 100B パラメータ モデルの重みに対応するには不十分です。

NVIDIA は、オンチップ メモリを大幅に削減してチップを設計しました (A100 では 40 MB、H100 では 50 MB)。 TSMC 5nm チップ上の 1GB SRAM には約 200 平方ミリメートルのシリコンが必要で、関連する制御ロジック/構造の実装には 400 平方ミリメートルを超えるシリコンが必要になります。 A100 GPU の価格が 10,000 ドルを超え、H100 の価格が 20,000 ドル近くであることを考えると、このアプローチは財務上の観点から現実的ではありません。 Nvidia のデータセンター GPU での利益率が約 75% であることを無視しても、SRAM メモリの完全生産製品のコストは依然として 1 GB あたり約 100 ドルです。

さらに、従来のムーアの法則プロセス技術が縮小しても、オンチップ SRAM メモリのコストはあまり下がらないでしょう。同じ1GBメモリでもTSMCの次世代3nmプロセス技術が使用されていますが、コストは高くなります。 3D SRAM は SRAM コストをある程度削減するのに役立ちますが、これは一時的なものにすぎません。

メモリ階層の次のステップは、密結合オフチップ メモリ DRAM です。 DRAM は SRAM よりもレイテンシーが 1 桁高くなります (約 100 ナノ秒対 10 ナノ秒) が、はるかに安価でもあります。 DRAM は何十年もムーアの法則に従っています。ゴードン・ムーアがこの用語を作ったとき、インテルの主な事業は DRAM でした。トランジスタ密度とコストに関する彼の予測は、2009 年以前の DRAM については概ね当てはまっていました。しかし、DRAMのコストは2012年以来ほとんど改善していない。

しかし、人々の記憶に対する需要は高まるばかりです。現在、DRAM はサーバーの総コストの 50% を占めており、いわゆる「メモリの壁」が徐々に形成されています。 NVIDIA の 2016 P100 GPU と最新の H100 GPU を比較すると、メモリ容量が 5 倍 (16GB → 80GB)、FP16 パフォーマンスが 46 倍 (21.2 TFLOPS → 989.5 TFLOPS) に向上していることがわかります。

メモリ容量は重要なボトルネックですが、別のボトルネックであるメモリ帯域幅も非常に重要です。メモリ帯域幅の増加は、多くの場合、並列処理によって実現されます。現在、標準的な DRAM のコストは GB あたりわずか数ドルですが、機械学習に必要な大規模な帯域幅を得るために、Nvidia は HBM メモリを使用しています。HBM メモリは、より高価なパッケージを必要とする 3D 積層 DRAM 層で構成されるデバイスです。 HBM の費用は、パッケージングとボリュームのコストを含めて、GB あたり約 10 ～ 20 ドルです。

メモリ帯域幅と容量に関するコストの制約の問題は、Nvidia の A100 GPU で特に顕著です。広範な最適化を行わないと、A100 の FLOPS 使用率は非常に低くなります。

研究者が多くの最適化を行ったとしても、大規模な言語モデルの FLOPS 使用率は約 60% に達することしかできません。時間の大部分は、別のコンピューティング/メモリからのデータを待機するか、メモリのボトルネックを軽減するために適時に結果を再計算することに費やされます。

A100 から H100 まで、FLOPS は 6 倍以上に増加しますが、メモリ帯域幅は 1.65 倍までしか増加しません。このため、多くの人が H100 の使用率が低いのではないかと心配しています。 A100 ではメモリの壁を回避するために多くのコツが必要でしたが、H100 ではさらに多くのコツが必要でした。

H100 は、分散共有メモリと L2 マルチキャストをホッパー アーキテクチャにもたらします。このアイデアは、ある SM のデータを別の SM の SRAM (共有メモリ/L1 キャッシュ) に直接書き込むことができるようにすることです。これにより、キャッシュ サイズが効果的に増加し、DRAM の読み取り/書き込みに必要な帯域幅が減少します。将来のアーキテクチャでは、メモリの壁の影響を最小限に抑えるために、メモリに送信される操作の数が削減されます。 FLOPS はパラメーター数の 3 乗としてスケールする必要があるのに対し、メモリ帯域幅と容量の要件は 2 次としてスケールする傾向があるため、モデルが大きくなるほど使用率が高くなる傾向があることに注意してください。

オペレーターフュージョン

すべての時間がメモリ転送に費やされている場合 (つまり、メモリ帯域幅が制限されている場合)、GPU の FLOPS を増やしても役に立ちません。一方、大規模な matmul の実行にすべての時間が費やされている場合は、オーバーヘッドを削減するためにモデル ロジックを C に書き換えても役に立ちません。

PyTorch が TensorFlow よりも優れたパフォーマンスを発揮できる理由は、Eager モードにより柔軟性と使いやすさが向上するためですが、Eager モードへの移行だけが利点ではありません。 Eager モードで実行している場合、各操作はメモリから読み取られて計算され、次の操作を処理する前にメモリに送信されます。大規模な最適化を行わないと、メモリ帯域幅の要件が大幅に増加する可能性があります。

したがって、Eager モードで実行されるモデルの場合、主な最適化方法の 1 つは演算子融合です。 Fusion 操作は、各中間結果をメモリに書き込むのではなく、単一パスで複数の関数を計算してメモリの読み取り/書き込みを最小限に抑えます。オペレーターの融合により、オペレーターのスケジューリング、メモリ帯域幅、およびメモリ サイズのコストが改善されます。

この種の最適化には通常、カスタム CUDA カーネルの作成が含まれますが、これはそれよりも優れています。単純な Python スクリプトを使用するのははるかに困難です。時間が経つにつれて、ますます多くの演算子が PyTorch に着実に実装されてきました。その多くは、複数の一般的な演算を単純に組み合わせて、より複雑な関数を作成しています。

演算子の追加により、PyTorch でのモデルの作成が容易になり、メモリの読み取り/書き込みが少なくなるため、Eager モードの実行が高速になります。欠点は、PyTorch が数年以内に 2000 オペレーターを超えるように爆発的に増加したことです。

ソフトウェア開発者は怠け者すぎると言えますが、正直に言うと、怠け者ではない人はいないでしょう。 PyTorch の新しい演算子に慣れると、それを使い続けます。開発者は、パフォーマンスが向上していることにさえ気づかないかもしれませんが、追加のコードを記述する必要がなくなるため、演算子を使い続けることがあります。

さらに、すべての演算子を融合できるわけではありません。どの操作を組み合わせるか、どの操作を特定のコンピューティング リソースに割り当てるかをチップ レベルとクラスター レベルで決定するには、多くの時間がかかります。演算子が融合される場所に関する戦略は一般に似ていますが、アーキテクチャが異なるため大きく異なる場合があります。

NVIDIA は王者でした

各オペレーターがターゲットをターゲットにしているため、オペレーターの成長とデフォルトの地位は NVIDIA にとって有利ですそのアーキテクチャは速度のために最適化されています、ただし、他のハードウェア用に最適化されていません。 AI ハードウェアのスタートアップ企業が PyTorch を完全に実装したい場合は、増え続ける 2,000 人のオペレーターのリストを高いパフォーマンスでサポートすることを意味します。

最大のパフォーマンスを引き出すには非常に多くのスキルが必要となるため、GPU で FLOPS 使用率が高い大規模モデルをトレーニングするには、ますます高度な才能が必要になります。加算的オペレーター フュージョンのイーガー モード実行は、開発されたソフトウェア、技術、モデルが、現行世代の GPU が持つコンピューティングとメモリの比率に対応するために常に推進されていることを意味します。

機械学習チップを開発する人は皆、同じメモリの壁に制約されます。 ASIC は、最も一般的に使用されるフレームワーク、デフォルトの開発方法、GPU に最適化された PyTorch コード、および NVIDIA と外部ライブラリの組み合わせをサポートすることによって制限されます。この場合、より多くの FLOPS とより厳密なプログラミング モデルを優先して、GPU のさまざまな非計算負荷を回避するアーキテクチャを持つことはほとんど意味がありません。

ただし、使いやすさが最優先されます。悪循環を断ち切る唯一の方法は、Nvidia の GPU でモデルを実行するソフトウェアをできるだけ簡単に、他のハードウェアにシームレスに移行できるようにすることです。モデル アーキテクチャが安定し、PyTorch 2.0、OpenAI Triton、MosaicML などの MLOps 企業からの抽象化がデフォルトになるにつれて、Nvidia の高度なソフトウェア セックスによって提供される使いやすさよりも、チップ ソリューションのアーキテクチャと経済性が購入の最大の推進要因になり始めています。 。

PyTorch 2.0

数か月前、PyTorch Foundation が設立され、Meta から分離されました。オープン開発およびガバナンス モデルへの変更に加えて、2.0 は初期ベータ版としてリリースされ、3 月に一般公開されました。 PyTorch 2.0 には多くの変更が加えられていますが、主な違いは、グラフィカル実行モデルをサポートするコンパイル ソリューションが追加されていることです。この移行により、さまざまなハードウェア リソースを適切に活用しやすくなります。

PyTorch 2.0 は、NVIDIA A100 でのトレーニング パフォーマンスを 86% 向上させ、CPU での推論パフォーマンスを 26% 向上させます。これにより、モデルのトレーニングに必要な計算時間とコストが大幅に削減されます。これらの利点は、AMD、Intel、Tenstorrent、Luminous Computing、Tesla、Google、Amazon、Microsoft、Marvell、Meta、Graphcore、Cerebras、SambaNova などの他の GPU やアクセラレータにも拡張されます。

現在最適化されていないハードウェアの場合、PyTorch 2.0 にはパフォーマンスを向上させる余地が大きくあります。 Meta やその他の企業が PyTorch に多大な貢献をしているのは、数十億ドル規模の GPU トレーニング クラスターでより少ない労力でより高い FLOPS 使用率を達成したいと考えているからです。このようにして、ソフトウェア スタックを他のハードウェアに移植しやすくするインセンティブも得られ、機械学習分野に競争が導入されます。

PyTorch 2.0 は、より優れた API の助けを借りて、データ並列処理、シャーディング、パイプライン並列処理、テンソル並列処理もサポートし、分散トレーニングに進歩をもたらします。さらに、スタック全体で動的シェイプをネイティブにサポートしており、他の多くの例の中でも、LLM のさまざまなシーケンス長のサポートが容易になります。以下の図は、主要なコンパイラがトレーニングから推論までダイナミック シェイプを初めてサポートしたものです。

PrimTorch

NVIDIA GPU を除くすべての機械学習 ASIC にとって、2000 以上の演算子をすべて完全にサポートする PyTorch 用の高性能バックエンドを作成することは簡単な作業ではありません。 PrimTorch は、PyTorch エンド ユーザーにとって同じ使いやすさを維持しながら、オペレーターの数を約 250 の元のオペレーターに削減します。 PrimTorch を使用すると、PyTorch のさまざまな非 NVIDIA バックエンドの実装がよりシンプルになり、アクセスしやすくなります。カスタム ハードウェアおよびシステム ベンダーは、ソフトウェア スタックをより簡単に展開できるようになります。

TorchDynamo

グラフ パターンに目を向けるには、信頼性の高いグラフ定義が必要です。 Meta と PyTorch は約 5 年間この移行を試みてきましたが、彼らが思いついたソリューションにはいずれも重大な欠点がありました。最後に、TorchDynamo を使用して問題を解決しました。 TorchDynamo は、外部のサードパーティ ライブラリを呼び出すスクリプトを含む、あらゆる PyTorch ユーザー スクリプトを取り込み、FX グラフを生成します。

Dynamo は、すべての複雑な演算子を PrimTorch の約 250 個の原始演算子に削減します。グラフが形成されると、未使用の演算子は破棄され、グラフはどの中間演算子を保存またはメモリに書き込む必要があるか、およびどの中間演算子を融合できるかを決定します。これにより、ユーザーにとっては「シームレス」でありながら、モデル内のオーバーヘッドが大幅に削減されます。

テストされた 7000 の PyTorch モデルのうち、TorchDynamo は、OpenAI、HuggingFace、Meta、NVIDIA、Stability.AI などのモデルを含む 99% 以上のモデルに適用されています。元のコードを変更する必要はありません。テストされた 7000 のモデルは、GitHub 上の PyTorch を使用する最も人気のあるプロジェクトからランダムに選択されました。

Google の TensorFlow/Jax やその他のグラフ モード実行パイプラインでは、多くの場合、ユーザーがモデルがコンパイラ アーキテクチャに適合していることを確認する必要があります。写真が撮れるように。 Dynamo は、部分グラフ キャプチャ、保護されたグラフ キャプチャ、インスタント再キャプチャを有効にすることでこれを変更します。

部分グラフ キャプチャにより、サポートされていない/非 Python 構造をモデルに含めることができます。モデル パーツのグラフを生成できない場合、グラフ ブレークが挿入され、サポートされていない構築がパーツ グラフ間でイーガー モードで実行されます。

保護されたグラフ キャプチャでは、キャプチャされたグラフが実行に有効かどうかを確認します。 「保護」とは、再コンパイルを必要とする変更を意味します。同じコードを複数回実行しても再コンパイルは何度も行われないため、これは重要です。オンザフライ再キャプチャでは、キャプチャされたグラフが実行に有効でない場合にグラフを再キャプチャできます。

PyTorch の目標は、スムーズな UX を備えた統合フロントエンドを作成することです。 Dynamo Generate グラフを活用します。ソリューションのユーザー エクスペリエンスは変わりませんが、パフォーマンスは大幅に向上します。キャプチャ グラフは、大量のコンピューティング リソース上でより効率的に並列実行できます。

Dynamo と AOT Autograd は、最適化された FX グラフを PyTorch ネイティブ コンパイラ レベルの TorchInductor に渡します。ハードウェア会社は、このグラフを自社のバックエンド コンパイラにフィードすることもできます。

TorchInductor

TorchInductor は、複数のアクセラレータとバックエンド用の高速コードを生成できる Python ネイティブの深層学習コンパイラーです。 Inductor は、約 250 のオペレーターを含む FX グラフを取得し、約 50 のオペレーターに削減します。次に、インダクタはスケジューリング フェーズに入り、オペレータが融合され、メモリ プランニングが決定されます。

次に、Inductor は「Wrapper Codegen」に入り、CPU、GPU、またはその他の AI アクセラレータで実行されるコードを生成します。ラッパー Codegen はコンパイラー スタックのインタープリター部分を置き換え、カーネルを呼び出してメモリを割り当てることができます。バックエンド コード生成部分は、GPU 用の OpenAI Triton を活用し、PTX コードを出力します。 CPU の場合、Intel コンパイラは C を生成します (Intel 以外の CPU でも動作します)。

将来的にはさらに多くのハードウェアがサポートされる予定ですが、重要なのは、Inductor によって、AI ハードウェア アクセラレータ用のコンパイラを作成する際にコンパイラ チームが実行しなければならない作業量が大幅に削減されるということです。さらに、コードのパフォーマンスがさらに最適化され、メモリ帯域幅と容量の要件が大幅に軽減されます。

研究者が必要としているのは、GPU のみをサポートするコンパイラだけではなく、さまざまなハードウェア バックエンドをサポートするコンパイラです。

OpenAI Triton

OpenAI Triton は、Nvidia のクローズドソース機械学習ソフトウェアにとって破壊的な存在です。 Triton は、Python から直接、または PyTorch Inductor スタックを通じてデータを取得します。後者が最も一般的な使用法です。 Triton は、入力を LLVM 中間表現に変換し、コードを生成します。 NVIDIA GPU は、NVIDIA のクローズドソース CUDA ライブラリ (cuBLAS など) をスキップし、代わりにオープンソース ライブラリ (cutlass など) を使用して、PTX コードを直接生成します。

CUDA はアクセラレーテッド コンピューティングの世界では人気がありますが、機械学習の研究者やデータ サイエンティストの間ではほとんど知られていません。 CUDA の使用には課題​​があり、ハードウェア アーキテクチャを深く理解する必要があるため、開発プロセスが遅くなる可能性があります。その結果、機械学習の専門家は、コードの変更、最適化、並列化を CUDA の専門家に依存する可能性があります。

Triton はこの欠点を補い、高水準言語が低水準言語と同等のパフォーマンスを達成できるようにします。 Triton カーネル自体は、一般的な ML 研究者にとって非常に明確であり、使いやすさにとって非常に重要です。 Triton は、SM でのメモリ結合、共有メモリ管理、およびスケジューリングを自動化します。 Triton は要素ごとの行列の乗算には特に役立ちませんが、行列の乗算はすでに非常に効率的に行うことができます。 Triton は、コストのかかるポイントごとの操作や、複雑な操作のオーバーヘッドを削減する場合に役立ちます。

OpenAI Triton は現在、NVIDIA GPU のみを正式にサポートしていますが、これは近い将来変更され、他の複数のハードウェア ベンダーをサポートする予定です。他のハードウェア アクセラレータは Triton の LLVM IR に直接統合できるため、新しいハードウェア用の AI コンパイラ スタックを構築する時間が大幅に短縮されます。

Nvidia の巨大なソフトウェア システムには先見性が欠けており、ML ハードウェアとソフトウェアにおける大きな利点を活用できず、機械学習のデフォルトのコンパイラーになることができませんでした。 OpenAI と Meta が他のハードウェアに移植可能なソフトウェア スタックを作成できるようにするユーザビリティへの焦点が欠けています。

元のリンク: https://www.semianaracy.com/p/nvidiaopenaitritonpytorch

以上がTensorFlow と同様に、NVIDIA の CUDA 独占は崩れるのでしょうか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。