16,625 文字
おおきに。生成AIへの関心が高まるにつれて、NVIDIAのGPUへの需要も急増して、一時的にNVIDIAが世界で最も価値のある企業になりましてん。NVIDIAの成功の大きな要因は、長年にわたって他社に対する巨大な障壁となってきたCUDAエコシステムやったんですわ。
しかし、その優位性が失われつつあって、GPU市場にはNVIDIAだけやないんです。もっと詳しゅう知りたいなら、見続けてくださいな。
この動画は3つの部分で構成されてます。NVIDIAのCUDA障壁、競合他社の見方、そしてNVIDIAは心配せなアカンのかどうかです。
第1部: NVIDIAのCUDA障壁
AIモデルに関わっとる人やったら、ほとんどすべてのディープラーニングがNVIDIAのGPUで行われてるいうことはもうご存知やと思います。これには、トレーニングと推論の両方が含まれます。
この事実が、最近NVIDIAの株価が天井知らずに上がった理由で、一時はNVIDIAを世界で最も価値のある企業にしたんです。この動画の時点では、世界で3番目に価値のある企業ですが、それでもすごいもんですわ。
もちろん、NVIDIAは素晴らしいGPUを作っとるんですけど、彼らのハードウェアだけが支配的な地位を占めとる理由やないんです。
NVIDIAには、人々が「AIソフトウェアの障壁」と呼んでるものがあります。基本的に、NVIDIAはAIソフトウェアエコシステムの十分な部分を支配しとるので、競合他社を締め出すことができるんです。
このソフトウェアスタックって一体何なんでしょうか。ちょっとGPUの歴史から始めましょか。
元々、GPUはグラフィックス専用やったんです。だからGraphics Processing Unitいう名前がついとるんですわ。GPUにはハードウェアで定義された固定機能パイプラインがあって、エンドユーザーが変更することはできませんでした。
やがて、シェーダープログラミングが登場して、GPUは少し柔軟になり始めました。OpenGLのGLSLやDirectXのHLSLみたいなシェーダー言語によって、グラフィックスパイプラインの一部をプログラムで変更できるようになったんです。
これらの言語は事実上GPUアセンブリコードにコンパイルされたので、GPUはより汎用的になり始めました。そして、GPU企業は完全に汎用的で完全にプログラム可能なインターフェースを公開できることに気づいたんです。
そこで、GPGPU（General Purpose GPU）プログラミング言語が導入されました。技術の世界でよくあることですが、市場リーダーは独自のプロプライエタリなソリューションを定義して、それをクローズドソースに保ちました。一方、他の企業はオープンスタンダードを定義しようとしましたが、あんまり普及しませんでした。
オープンスタンダードはOpenCLで、プロプライエタリなソリューションはNVIDIAのCUDAでした。NVIDIAはゲーミングGPU市場で最初に持っとった優位性を活かして、それ以来その優位性を構築し、維持し続けてきたんです。
CUDAをそんなに強力にしたものは何やったんでしょうか。いくつかの重要な設計要素があります。
まず、GPUの実際の動作に関する低レベルの詳細を明らかにするように設計されとります。特に、メモリ階層と計算構造です。CPUと同じように、GPUにもメモリの異なる層がピラミッド状に配置されとって、最小のものが最速です。
GPUの全メモリを使おうとすると、めっちゃ遅くなります。でも、GPUは特にメモリの使い方に敏感で、異なる階層レベルの使い方にも敏感なんです。
例えば、ミスして非常に非効率なパターンでメモリにアクセスしてしまうと、システムのパフォーマンスが大幅に低下する可能性があります。そやから、CUDAはこの異なるタイプのメモリのピラミッドを明示的に公開して、ユーザーが必要に応じて適切な部分にアクセスできるようにしとるんです。
計算構造に関しては、CPUは基本的にスレッドしかありませんが、CUDAではグリッド、ブロック、スレッドを扱います。GPUの実行環境はもっと複雑やからです。
対照的に、OpenCLスタンダードの進化は非常に遅かったです。OpenCLコードは一度書いたらGPUでもCPUでも実行できるように設計されとるので、必然的にGPUの実際の動作方法の多くの側面を隠すことになります。
これは、OpenCLを使うときにハードウェアから最高のパフォーマンスを引き出すのを非常に難しくしています。でも、これは多くの異なる企業が集まって妥協点を見つけ、スタンダードを決めようとする際には避けられへんかったかもしれません。
ほんまは、CPUとGPU部分を完全に分離しとくべきやったと思います。最近では、OpenCL 2.0や3.0みたいな新しいバージョンのOpenCLはオプショナルになっとります。もうGPU企業の間で支持されへんようになったからです。
CUDAの成功のもう一つの要因は、PTXいうアウトプットするマシンコードです。NVIDIAは変化を恐れへんので、NVIDIAのGPUがサポートするPTXマシンコードはかなり変化してきました。これまでに12か22くらいの異なるバージョンがあったと思います。
これは基本的に、CUDAが複数の異なるバイナリAPIをターゲットにできるいうことです。これは、AndroidのSDKの仕組みとよく似とります。Androidアプリを作ったことがある人なら、18、25、30くらいの異なるバージョンのAndroid APIがあることを知っとるはずです。
これは、ARMアセンブリコードにも似とります。ARMは、AndroidやiPhone、そして最近ではAppleのラップトップも含めて、事実上すべての携帯電話を動かしとるCPUアーキテクチャです。
CUDAがもっとる優れたコンパイラインフラを前提とすれば、これは急速なイノベーションを可能にする正しいモデルやと思います。NVIDIAがPTXマシンコードとの後方互換性を維持しようとしたら、将来のGPU世代の最適化方法に多くの制約がかかってしまいます。
この方法では、新しいバージョンのCUDAが出るたびにコードを再コンパイルする必要がありますが、市場リーダーやったらそれを強制できるんです。
CUDAはめっちゃ人気になったので、他のフレームワークがCUDAをターゲットにするのは自然なことでした。つまり、他のフレームワークや他のプログラミング言語がCUDAを出力して、それからCUDAコンパイラによってGPUで実際に実行できるPTXにコンパイルされるんです。
もちろん、何かがCUDAをターゲットにするいうことは、NVIDIAのGPUでしか動かへんいうことです。競合他社にとって2つの主な問題があるからです。
まず、CUDAはクローズドソースで、NVIDIAは誰かがそれをコピーしようとするのを本当に嫌がります。そして、たとえコピーしようとしても、CUDAには長年にわたって多くの機能が追加されてきたので、CUDAを再実装しようとするのは本当に大変な仕事なんです。
PTX言語は変化し続けとります。NVIDIAは新しいコンパイラを作るだけでええんですが、CUDAそのものは変わりません。少なくとも後方互換性を壊すような変更はありません。
これがNVIDIAが顧客に新しい世代のために常にコードを変更せなアカンようなことがないようにする方法です。CUDAはめっちゃ大きな市場シェアを持っとって、めっちゃ複雑やから、実装にバグや癖があっても、それが人々が頼りにするものになってしまうんです。
これがCUDAを再現しようとする人にとってさらに難しくなる理由です。文字通りすべてのバグも再現せなアカンからです。
例えば、PyTorch（最も人気のある機械学習フレームワーク）は、以前はCUDAだけをターゲットにしとりました。そやから、NVIDIAはPyTorchを支配してへんけど（元々はMetaによって作られた）、事実上PyTorchのベンダーロックインを保証したんです。
つまり、Google以外のほぼ全ての機械学習コミュニティがNVIDIAに縛られることになったんです。これが、競合他社が変えるのは難しいと想像するような大きな勢いを生み出しとるんです。
また、人間の性質として単純な事実もあります。前のクラスターが完全にNVIDIAのGPUで構築されとったら、次のクラスターもおそらくそうなるでしょう。
第2部: 競合他社の見方
ちょっとNVIDIAの競合他社の視点から見てみましょか。GPU市場、特に機械学習の部分に参入するのはめっちゃ難しいです。NVIDIAはソフトウェアスタックを確実に支配するために、反競争的な慣行とも言えるようなことをしてきました。
そやから、AMDやIntel、あるいは他のハードウェアアクセラレータの製造業者やったら、この問題にどうアプローチするでしょうか。
実際、NVIDIA以外は誰もCUDA独占を好んでいません。PyTorchさえも、他に良い選択肢がなかったから自分をCUDAに限定したんです。
企業は主要なプロバイダー以外にも選択肢を持ちたがります。例えば、GoogleはオンラインゲームプラットフォームのStadia（結局失敗しましたが）を構築する際に、完全にAMDのGPUを使うことにしました。
これは完全に理にかなっとります。Googleはドル当たりのパフォーマンスが向上し、NVIDIAよりもドライバーの動作の詳細を共有する意欲のあるパートナーを得られたんです。
企業はまた、単一の企業に依存することを嫌がります。それを単一障害点と見なすからです。その企業がミスを犯したり、生産目標を達成できへんかったりしたら、他に頼るところがないんです。
そやから、たとえハードウェアがそれほど良くなくても、このCUDAの問題さえ解決できれば、NVIDIAの競合他社にも確実に市場があるんです。
じゃあ、企業がこの問題に対処する4つの異なる方法について話しましょか。
まず、企業はハードウェアの互換性を持たせようとすることができます。これは確かに最も単純なアプローチです。例えば、AMDのCPUはIntelのプロセッサとハードウェア互換性があります。
これは、AMDがCPU市場で完全に孤立することなく、Intelの CPU用にコンパイルされたプログラムがAMDのCPUでそのまま動くいうことです。
理論的には、これはIntelが一種のオープンスタンダードを持っとったからこそ可能やったんです。彼らはアーキテクチャの動作の詳細を公開しました。
これは裏目に出る可能性もあります。例えば、AMDが最初に64ビットのIntel互換プロセッサを生産したので、多くの場合、AMDの名前が使われることになりました。
64ビットIntelプロセッサの公式名称はx86-64ですが、Debian Linuxは今でもこのアーキテクチャをamd64と呼んでいます。
とにかく、これが機能したのは、Intelが非常に安定したアーキテクチャを持っとるからです。彼らは実際には、マシン命令を下層のマイクロコードで実装しとります。マイクロコードは常に変更できますが、命令は変更されません。
理論的には、元の8ビットプログラム（8080用に設計されたもの）を今日の64ビットプロセッサで実行できます。実際にはもうちょっと複雑なんですけどね。でも、考え方は大事やと思います。
そやから、AMDは同じ安定したアーキテクチャをターゲットにすることができたんです。でも、前に言うたように、PTXはめっちゃ不安定です。そやから、NVIDIAとのハードウェア互換性を維持するのはほぼ不可能やと思います。
この場合、安定したAPI（基本的にはCUDA）をターゲットにしようとせなアカンでしょうね。
2つ目の方法は、ライブラリの互換性を持たせることです。すべてのCUDA関数を取って、自分のバージョンを書き直すんです。
これは確かに実現可能ですが、ユーザーが書いたCUDAコードがたくさんあるいう問題は解決できません。また、APIが本当に大きい場合（CUDAはそうです）は非常に難しいです。
言うたように、彼らは常に機能を追加し続けとるんです。例えば、IBMがデータベースのDB2をOracleと互換性を持たせようとしたとき、それができたのは、APIの違いが比較的小さかったからです。
そして、彼らはOracleのすべての顧客を引き込むことができました。MicrosoftがLinuxをWindowsで動くようにポートしようとしたとき、彼らは成功しました。
これが今のWSL（Windows Subsystem for Linux）です。これは、Linuxのシステムコールの数が比較的少ない（約300くらい）からできたんです。
でも、逆方向、つまりWineプロジェクトがWindowsをLinuxで動かそうとしたのは、ほぼ絶望的です。Windowsカーネルには2,000以上のシステムコールがあって、安定したAPIでもないからです。
だから、Wineは「Wine Is Not an Emulator（Wineはエミュレータではない）」の略なんです。これはライブラリ互換性レイヤーなんです。
3つ目の選択肢はバイナリ翻訳です。あるプロセッサアーキテクチャ用に書かれたプログラムを、別のプロセッサアーキテクチャで動かしたい場合、技術的にはすべての命令を翻訳して、新しいアーキテクチャで適切に動作するようにできます。
これは技術的にめっちゃ難しくて、PTXが安定したAPIやないいうこともあって、メンテナンスにもかなりの労力が必要です。
でも、成功しとるバイナリトランスレータの例もあります。例えば、AppleがすべてのラップトップでARMプロセッサ（Appleシリコン）を使い始めたとき、彼らは問題に直面しました。
既存のすべてのMacプログラムがARMプロセッサではなく、Intel互換プロセッサ用にコンパイルされとったんです。Appleは、WindowsやIntelほど後方互換性を恐れへんけど、それでも何かせなアカンかったんです。
新しいラップトップがどんなプログラムも実行できへんようになってしまうからです。そこで彼らはRosettaを作りました。これは、x86コード（Intelコード）とARMコードの間の完全なバイナリ翻訳フレームワークです。
エッジケースは確かにありますが、多くのプログラムが最初からそのまま動きます。これは、実際に達成しとることの技術的な詳細を考えると、単純に驚くべきことです。
最後に、4つ目の、おそらく最も難しい方法は、完全に新しいコンパイラを作ることです。これも難しい仕事です。すべてのCUDAライブラリを実装せなアカンし、基本的にすべての癖も一致させる必要があります。
そして、NVIDIAが常に言語に追加し続けとる新しいアップデートにも追いつかなアカンのです。
また、別のコンパイラを書くのは、法的トラブルに巻き込まれるのにめっちゃ簡単な方法です。コピーしとるコンパイラが訴訟を起こしそうな企業のものやったら（NVIDIAは間違いなくそうです）、完全にクリーンルームで再実装せなアカンのです。
これは、他の企業が著作権を持つ可能性のあるコードを一切参照せずにコンパイラを作るいうことです。つまり、どう動くかを見るために他社のコンパイラを見たり、実行したりしてはいけません。
完全にウェブサイトのドキュメントだけを頼りに作業せなアカンのです。
有名な例があります。Googleが upcoming Androidスマートフォン用の言語を探しとって、Javaが完璧やと思ったんです。でも、OracleがJavaコンパイラのすべての権利を持っとって、Googleに使わせたくなかったんです。
そこでGoogleは完全にクリーンルームで再実装しました。めっちゃ時間がかかりました。残念なことに、Googleのコンパイラはオープンソースで、Oracleの誰かがそのソースコードを見て、「ここのちっちゃな関数、うちのコードからコピーされたんと違うか」って言うたんです。
OracleはGoogleを訴えて、Googleは負けたと思います。本当に短い関数、数行のコードのために、Oracleにかなりの金額を払うことになりました。
その関数が実際に再作成されたのか、本当にどこかのOracleのコードからコピーされたのかについて合理的な疑いがあったからです。これで大変なトラブルに巻き込まれました。
また、ソースからソースへの翻訳いう軽量版もできます。基本的に、CUDAのソースコードを入力として受け取り、自分のハードウェアで動く別の言語のソースコードを出力するツールを持つことができます。
現在、AMDとIntelの両方がこの種のツールを自社のフレームワークに持っとります。
では、NVIDIAの直接の競合他社、つまりハードウェア製造業者が、これら4つの異なる技術をどのように使ってCUDAと互換性を持たせようとしとるか話しましょか。
まずIntelです。Arcデバイスの生産を開始して以来、専用GPUも製造しとります。IntelのCUDA相当品はOpenAPIと呼ばれとって、前に言うたように、CUDAプログラムをOpenAPIコードに翻訳する能力をある程度持っとります。
また、Intelのエンジニアが自分の時間で、ZCAいうシステムを作りました。これは、IntelのGPUで動くCUDAの再実装を目指したものです。
プロジェクトはしばらく中断されて、Intelがこのソフトウェアのビジネスケースを評価することにしました。結局、彼らは「いや、オープンソースで公開しよう。この方向性は追求したくない」って言うたんです。
そこで、この開発者はAMD（現在もう一つの主要なGPU生産者）に行って、AMDのGPUへのポートを始めました。そしたら、AMDもやって来て「このビジネスケースを評価させてくれ」って言うて、結局彼らもCUDAの完全な再実装の機会を断ったんです。
基本的に、両社ともNVIDIAが法的に追及してくる可能性（ほぼ間違いなくそうなる）を認識して、大きな法的トラブルに巻き込まれる可能性があることに気づいたんです。
でも、AMDとIntelだけがGPU生産者やないんです。聞いたことがないかもしれませんが、More Threadsいう会社があります。ええ名前やと思います。
これは2020年に設立された中国の会社で、2022年に最初のGPU製品をリリースしました。どうやらこれらのGPUはあんまり速くないらしいです。
でも、中国にいる場合を考えてください。アメリカ政府はNVIDIAが最高性能のGPUを中国に売ることを禁止してます。そやから、More Threadsにとってはハードルが低いんです。かなり遅いNVIDIAのGPUとだけ競争すればええんです。
More Threadsがコストを下げることができれば、魅力的に見え始めるでしょうね。
とにかく、この会社にはMufiいうツールがあって、CUDAコードを自社のGPUアーキテクチャ（Musaと呼ばれとる）で動作させるように設計されとります。
英語のインターネットではこのシステムの詳細があんまりないんですが、More Threadsの製品のアーキテクチャ図によると、ほとんどのCUDAコンポーネントを再実装しとるようです。
Musfiは、CUDAソースコードの完全なコンパイラか、おそらくバイナリ翻訳フレームワークのどちらかやと思います。私の推測では、両方を試みとるんやないかな。
すでにCUDAスタイルのライブラリをすべて再実装しとるなら、おそらく修正されてへんCUDAコードを大した困難なく
コンパイルできるはずです。
でも、中国の消費者にとっては、バイナリ翻訳ツールを持つのが理想的やと思います。ソフトウェアの提供者に連絡して「More ThreadsのGPU用にコンパイルしてくれへんか」って言うことができへんかもしれません。More Threadsのこと聞いたことがないかもしれへんからです。
彼らがバイナリ翻訳もやっとると思う、もう一つの理由はNVIDIAの対応です。NVIDIAはCUDAとリンクされたコードの逆アセンブルを禁止しました。
ちょっと解説させてもらいます。通常、コードを逆アセンブルして、アセンブリレベルで命令が何をしとるかを理解するのは、技術的には常に可能です。
でも、法的には禁止されとることが多いです。企業はクローズドソースの独自ソフトウェアが解読されて複製されるのを望まへんからです。
もちろん、中国にいる場合、このような禁止にはあんまり注意を払わへんでしょうし、競合他社のコードを喜んで逆アセンブルするでしょう。
でも、NVIDIAはさらに一歩踏み込みました。自社のコード（例えばCUDAライブラリ）の逆アセンブルを禁止するんやなくて（これは理解できるし、西洋の法的環境では先例もあります）、文字通り、CUDAライブラリとリンクしとる場合、コンパイル後の自分のコードの逆アセンブルを禁止したんです。
これは奇妙で、法的に通用するかどうかわかりません。でも、おそらく彼らがそうしたのは、例えばMufiのようなバイナリ翻訳ツールを人々が実行するのを望んでへんからです。
企業がMore ThreadsのGPUと互換性を持たせるために使える可能性があるからです。もちろん、中国の誰か、例えばMore Threads自身がコードの逆アセンブルを実行して、ソフトウェアを翻訳するのを防ぐのにはあんまり役立ちません。
NVIDIAが何を言おうと、中国では実質的に強制力がないからです。これは、CUDAという知的財産を本気で守る気やいうことを市場に示すためのジェスチャーに過ぎへんと思います。
結局のところ、あるコメンテーターが言うたように、既存のCUDAプログラムを再コンパイルするのは完全に合法なままです。
そやから、More Threadsや他の誰かが実際にCUDAコンパイラのクリーンルームバージョンを実装することに成功したら、NVIDIAにはあんまりできることがないんです。
では、新しいコンパイラについて話しましょか。驚くべきことに、イギリスを拠点とするSpectral Computeいう会社が、CUDAコンパイラの完全なクリーンルーム再実装を出しました。
彼らのコンパイラはScaleと呼ばれとって、現在はAMDのGPUをターゲットにしとります。でも、将来的にはさらに多くのタイプのGPUをサポートする予定です。おそらくIntelのGPUのことを言っとると思います。More ThreadsのGPUやないでしょうね。
さらに驚くべきことに、このコンパイラは現在無料です。ベータ版って呼んでるので、無料のままかどうかは不明です。オープンソースではなく、クローズドソースです。
でも、クリーンルームコンパイラの再実装をする場合、それは理にかなっとります。ここのちっちゃな関数がインターネットからコピーされてへんことを証明せなアカンようになりたくないですからね。
また、このコンパイラを作るのに7年かかりました。そうです、CUDAコンパイラのクリーンルーム再実装を作るのに7年もかかったんです。
Spectral Computeはかなり小さな会社で、LinkedInによると従業員は50人未満です。他のこともやっとるんですが、それでもCUDAみたいな巨大なものをクローンするには、めっちゃ多くの労力が必要なんです。
彼らの意図はわかりませんが、もし私やったら、このソフトウェアの使用に対する興味と支援を集めようとするでしょう。多くの人に興味を持ってもらい、AMDにも本気で興味を持ってもらって、それからコンパイラの使用料を取り始めるんです。
そして、NVIDIAに買収してもらって、コンパイラを再び無料にして、みんなが引き続き彼らのGPUを使い続けるようにするんです。
とにかく、AMDは基本的に別の方法でそれをすでにやっとります。AMDにはROCmいうコンパイラがあって、これが基本的にCUDAへの彼らの回答です。多くの同じユースケースをサポートすることになっとるんですが、過去にはかなりスポッティやったんです。
基本的に、AMDはNVIDIAがしたような汎用コンピューティングエンジンを作ろうとはしませんでした。その代わりに、最大の顧客が必要とする機能をROCmに追加しただけでした。
そやから、趣味の人や機械学習開発者がそれを使おうとすると、大きな穴があることに気づいたんです。もちろん、機械学習に対する彼らの態度は最近急速に変わりました。
2023年10月、AMDはNod.を買収しました。Nod.は独自の最適化コンパイラを持っとって、すでにAMDのGPUをターゲットにしとりました。完全なCUDAオールインワンではなかったですが、AMDを実際に動作するCUDAコンパイラに一歩近づけました。
今では、それらをすべてROCmにマージして、そこで開発を続けとるんやと思います。AMDはこのプロジェクトの背後に多くのリソースを投入し続けとるように見えます。
この動画の調査の一部として、実際にこれらすべての作業をしとるAMDのコンパイラエンジニアと話しました。詳細は得られませんでした。NDAs（機密保持契約）は破られてへんかったんです。
でも、彼らがやっとる作業はすべてオープンソースやって言うてました。実際、ROCmのほとんどはオープンソースです。これは、遅れとる場合の典型的な戦略です。
私がいつも言うように、遅れとる場合はオープンソースにして、コミュニティを活用して競合他社に追いつこうとするんです。でも、これはAMDにとってはめっちゃ健全な計画やと思います。うまくいかへんかったら、いつでもScaleを買収できますからね。
第3部: NVIDIAは心配せなアカンのか
まず、この節も、実際にこの動画全体も、投資アドバイスやありません。ここで見たことに基づいて投資したり、投資せんかったりせんでください。
一方では、我々が話したこれらのテクニックはすべて、基本的にキャッチアップのテクニックです。他の企業が市場リーダー（明らかにNVIDIA）をコピーしようとする方法で、NVIDIAが自分のために構築したソフトウェアの障壁を突破しようとする方法です。
NVIDIAが依然として最高のGPUを作っとることを忘れんでください。
他方で、AMDはすでに、特に低価格帯で、使ったドルあたりのパフォーマンスがより良いと言えるかもしれません。そやから、競合他社が同じ土俵で戦えるようになったら、NVIDIAは価格に大きな下押し圧力を受けるでしょうね。
そやから、NVIDIAにとって存在を脅かすリスクではないですが、それでも可能な限り長くCUDAの独占を維持したいと思うでしょう。また、もちろん、めっちゃ高い評価額もあります。
でも、私の見方では、実際にはCUDAは大きすぎて複雑すぎて、効果的にエミュレートするのは難しいんです。NVIDIAはフレームワークに機能を追加し続けとります。
ScaleやROCmやったら、常に後手に回って、常に1世代か半世代遅れることになるでしょう。NVIDIAは今や非常に裕福で、多くの異なる方法で自社の障壁を強化できます。
入札戦になったら、NVIDIAは簡単にAMDを上回ってScaleを購入できるでしょう。
しかし、そうは言うても、CUDAさえも実際には汎用GPUプログラミングに最も理想的なフレームワークやないんです。なぜかって？ コピーするのを本当に難しくする同じ理由です。めっちゃ複雑なんです。
つまり、より単純な言語とより単純なフレームワークの方が、実際にはパフォーマンスが良くなる可能性があるんです。ARMプロセッサがx86プロセッサを電力消費やその他のさまざまな指標で上回れるのと似とります。
x86プロセッサは30年か40年分の baggage（重荷）を背負っとるからです。
そやから、実は我々がまだ話してへん追加の次元があって、NVIDIAが最も心配せなアカンのはそれです。競合他社がより魅力的なスタックを導入したらどうなるでしょうか。
これは非常に難しいでしょう。競合他社は少なくとも1つの分野で大きな優位性を持つ必要があります。そうせんと、みんな慣れ親しんだNVIDIAのハードウェアとNVIDIAのスタックを使い続けるだけです。
また、想像できるように、このようなスタック全体を再作成するのは、めっちゃ資本集約的で、かなりの時間がかかります。そやから、それを試みる企業は、すでに成功しとる他の事業から資本を調達せなアカんでしょう。
AMDはこれを afford（余裕がある）できるかもしれません。かなり成功しとるCPUを持っとるからです。
興味深いことに、実際にこれが起こっとるかどうか、いつ起こっとるかについて、かなり良い idea（考え）を得ることができます。
というのも、また、競合他社が後れを取っとる場合、彼らは often（しばしば）製品をオープンソースでリリースして、その extra little bit（ちょっとした追加の）努力のためにコミュニティの関与を leverage（活用）しようとするからです。
実際、新しいスタックは常に静かに作られとります。ほとんどは本当に特殊目的ですが、すべてがそうやないんです。
この情報はSemi Analysisの記事からのもので、下のリンクで確認できます。基本的に、彼らはOpenAI TritonとPyTorch 2.0を highlight（強調）しとります。
PyTorchは、覚えとると思いますが、歴史的にCUDAだけをバックエンドとしてサポートしてきました。その一部は、PyTorchに異なる operator（演算子）と異なる feature（機能）が層upon層と追加されて、維持せなアカん巨大なAPIができるまでになったからです。
でも、彼らは戻ってPyTorchのグラフプランニングの側面の多くを書き直しました。それをPyTorch 2.0って呼んでます。そして、それが起こったように、他のGPUがやりたいやり方とずっと互換性が高くなったんです。
突然、PyTorch（NVIDIAが支配してへんスタックのこの側面）は、他のGPUともっと互換性を持つようになりました。これはNVIDIAが望んでへんことです。
でも、ここで本当に興味深い展開はOpenAIのTritonです。基本的に、OpenAIには多くの機械学習の専門家がいますが、GPU プログラミングの専門家はあんまりいないんです。少なくとも私はそう gather（推測）しました。
そこで彼らはTritonを作りました。これはドメイン固有言語で、Pythonの上に実装されとります。このような言語ではよくあることです。
Pythonの関数を書いて、前にちょっとした annotation（注釈）を追加するだけです。基本的には「Triton、これに注目して」って言うとるんです。
これは、毎日PyTorchを書いとる同じ人々（そやからPythonにめっちゃ慣れとる）が、実際にTritonコードを書こうと try their hand（試す）ことができるいうことです。
これは確かにCUDAの場合とは違います。CUDAは書くのがめっちゃ複雑なコードで、本当にそれについてよく考える必要があって、専門的なスキルが必要です。
TritonはCUDAのより高レベルなバージョンで、それでもかなり似たようなパフォーマンスを達成します。Tritonはこれを、プログラマーが書いたPythonベースのコードを、LLVMコンパイラフレームワークと互換性のある中間表現に変換することで実現しとります。
後でそれについてもっと話しますが、基本的にはコンパイラの中に存在するものです。そして、PTXコード（NVIDIAのGPUのアセンブリ言語またはGPUマシン言語の名前を覚えとると思います）を出力するための既存のLLVMサポートを使います。
言い換えると、TritonはCUDAを完全にスキップしとるんです。TritonコードからCUDAを経由してPTXに行って、それを実行するんやなくて、TritonコードからPTXに直接行って、それを実行するんです。
これはNVIDIAにとってめっちゃ危険です。なぜなら、CUDAを方程式から外してて、他のアーキテクチャへのポートをずっと簡単にしとるからです。
LLVMについてもうちょっと説明させてください。そうすれば、もっと理解しやすくなると思います。
LLVMを知らへん場合、これは基本的にコンパイラ技術のあらゆる側面を徐々に革新してきた研究用コンパイラです。これは、高レベルの情報と低レベルの情報の両方を扱うのに十分な柔軟性を持つコードの中間表現を持つ最初のシステムです。
今では、ウェブブラウザのJavaScriptを高速化するV8エンジンで使われとります。従来のCとC++のコンパイラでも使われとります。Appleから出たSwiftプログラミング言語みたいな新しいコンパイラでも使われとります。
ヘック、GoogleやMetaのデータセンターで動いとるLinuxカーネルでさえ、LLVMでコンパイルされとります。基本的に、最適化の研究をしとるすべての研究者が、自分のコードがLLVMで動作することを確認します。
そやから、LLVMベースの技術の改善ループが速くなります。LLVMのコード生成の改善は、すぐにこの技術の他のすべての使用に波及します。
そして、中間表現が1つしかないので、新しいソース言語や新しい出力言語を書くのがめっちゃ簡単です。例えば、PTXの新しいバージョンや、AMDのGPUもサポートしたり、IntelのGPUもサポートしたりするなどです。
そやから、NVIDIAがLLVMベースのシステムを自分で開発せんかぎり、長期的には恐らく負けるでしょう。でも残念ながら、LLVMベースのシステムを持つということは、独自のプロプライエタリなコンパイラやプロプライエタリなフレームワークを持つのがめっちゃ難しくなるんです。
そこに価値を付加するのがずっと難しくなります。そやから、LLVMの存在自体が実際にこの障壁をめっちゃ縮小させとるんです。そして、人々がすでにそれを使ってPTXをターゲットにしとるいう事実が、さらにその障壁を縮小させとるんです。
一方で、これらの種類の技術に投資しとるすべての企業は、投資先を選ばなアカンのです。例えば、Tritonでさえ、OpenAIが必要とするものだけをサポートしとります。例えば、Linuxだけをサポートしとります。でも、これはほとんどのクラスターにとってはめっちゃええマッチやと思います。多分、Linuxの変種を実行しとると思いますからね。
そして、前に言うたように、CUDAにはまだかなりの勢いがあります。例えば、Tritonは3年前に最初にリリースされましたが、NVIDIAはまだ元気です。
しかし、AMDのGPUのサポート、特にROCm 5.3の出力のサポートが、Tritonに追加されたのは今年の7月12日です。それまでは、OpenAIにはそれを使う必要がなかったんです。おそらくNVIDIAのGPUしか持ってへんかったからやと思います。
また、OpenAIがAMDのGPUのサポートを追加し始めたのはめっちゃ興味深いです。おそらく代替のサプライヤーを検討しとるんやないでしょうか。あるいは、Sam Altmanが自分のチップ会社を立ち上げたときに、OpenAIが最小限の摩擦でそのGPUを使えるようにしたいんかもしれません。
そやから、はい、NVIDIAは間違いなく心配せなアカンでしょう。彼らの障壁は、LLVMみたいな新しい技術によって侵食されとるように見えます。Tritonみたいな新しいプロジェクトや、以前はCUDAだけに焦点を当ててたPyTorchみたいなプロジェクトによっても侵食されとるんです。
PyTorchは今では理論的にはCUDA以外のアーキテクチャもサポートしとります。CUDAそのものも、このクリーンルームコンパイラや、AMDがROCmを改善して実際にCUDAのものをもっとうまく実行できるレベルにする可能性によって攻撃を受けとります。
確かにNVIDIAには大きな勢いがあって、銀行口座を潤す数ヶ月か数年分の予約注文もあります。でも、最近Redditでこのトピックを見たことがあれば、PyTorch 2で基本的にAMDのGPUを動かせるようになったって言うとる人がたくさんいるのがわかると思います。
彼らはまだたくさんの小さな問題を予想しとります。結局のところ、ディープラーニングは、その始まり以来、あるいは少なくともPyTorchが発明されて以来、本質的に同じスタックで動いてきましたからね。
そやから、機械学習コミュニティの一般的な知恵では、NVIDIAが唯一の実行可能な方法やって言うとります。私でさえ、機械学習用にNVIDIAのGPUを買いました。
企業がどうするか想像できますよね。彼らは単に一般的な知恵に従うでしょう。もちろん、ちょっとした技術的な障害を乗り越えるだけで大金を節約できる可能性がある場合は別ですけどね。
きっとそれらの問題は簡単に解決できるはずです。結局のところ、誰かが最初に10億ドルのAMDクラスターを構築せなアカンのです。
最後に結論として、我々はNVIDIAが競合他社から身を守るために構築した障壁について話しました。そして、なぜソフトウェアスタックの部分であるCUDAがその障壁の大きな要素なのかについても話しました。
CUDAは、プログラマーがハードウェアから最大限のパフォーマンスを引き出すことができる低レベルの詳細を明らかにします。そして、NVIDIAのGPUが最高やったので、みんなただCUDAをターゲットにして、それが自己実現的な予言になったんです。
一方で、他のほぼすべての企業が、この独占を壊したいと本当に思っとります。我々は、企業がこれを試みる可能性のある4つの異なる方法を特定しました。
最初の3つの方法は実際に法的な困難がある可能性があります。それは、ハードウェアの互換性、ライブラリの互換性、バイナリ翻訳です。
3つ目の方法、すべてのコードを再コンパイルするための新しいコンパイラを作ることも、めっちゃ難しいです。でも、少なくとも1つの企業が成功しとります。Spectral Computeは、Scaleと呼ばれるクリーンルームコンパイラを作りました。
また、OpenAI Tritonみたいなプロジェクトもあって、これは実際にCUDAを完全にバイパスしとります。新しいコンパイラ技術を使って重い作業をするんです。
LLVMコンパイラフレームワークを使うことで、CUDAを完全にバイパスして、それでも最適化を得て、NVIDIAのマシンコードを直接出力できます。そして、おそらくAMDやIntelのGPUマシンコードのサポートを追加するのもそれほど難しくないはずです。
NVIDIAにはめっちゃ大きな勢いがあるので、短期的には心配せんでもええと思います。でも、中期的には、もっと多くの競合他社が現れ始める可能性が高いと思います。
そうすると、NVIDIAがGPUに請求できる価格に下押し圧力がかかり始めるでしょう。そうすると、NVIDIAの株価がめっちゃ悪くなって、それが彼らにとってちょっとしたネガティブなサイクルになる可能性があります。
大企業には、単にNVIDIAが求める金額を払うんやなくて、別のアプローチを見つける大きなインセンティブがあります。はっきり言うて、彼らは製品に対してめっちゃ高いマージンを請求しとります。今、約75%の粗利益率があるんです。
そやから、価格が下がる余地はめっちゃあるんです。
この動画が気に入ったら、ええから「いいね」押してチャンネル登録してな。DiscordチャンネルにもぜひJOINしてください。コミュニティや私と直接話せますよ。
この動画が気に入ったなら、前に作ったGPUの進化について話しとる動画もチェックしてみてください。ちょっと技術的ですが、今見た動画と似とるので、気に入ってもらえると思います。
今日はこれくらいにしときます。見てくれてありがとうございました。ほな、また！
コメント