中国のMoore Threads社は、NVIDIAのCUDAスタックに代わるMUSA SDKの新しいアップグレードをリリースしたため、AI市場でのシェアを望んでいるようだ。
Moore Threads MUSA SDKがIntelとARMプロセッサをサポート、NVIDIAのCUDAスタックからのコード移植も可能に
ソフトウェアの機能に関しては、NVIDIAはそのCUDAエコシステムで業界を支配することに成功しており、ハイエンドのサポートだけでなく、迅速なアップデートも提供している。
チーム・グリーンは、競合他社が息つく暇もないことを保証している。
しかし、進化する地政学的状況により、中国のハイテク企業がNVIDIAだけに依存することは難しくなっており、これを念頭に置いて、国内GPUメーカーのMoore Threadsは、MUSA SDKの採用を増やそうと、MUSA SDKに新たな進歩をもたらしました。
Moore ThreadsのAIソフトウェア・スタックは、同社のGPU専用に設計されている。
これにより、さまざまなプラットフォームで並列コンピューティングとAIワークロードが可能になる。
ランタイムライブラリ、ドライバ、命令セットを備えており、既存のシステムでこの環境を使用できる。
MUSA SDKは、専用のツールキットからアプリケーション固有のライブラリまで、複数のコンポーネントに分かれている。
すべてのランタイム・ライブラリとは別に、MUSA SDKの興味深い事実は、開発者がCUDAベースのコードをMUSAのエコシステムに移植し、シームレスな採用を可能にするMUSIFYと呼ばれる「コード・ポーティング」ツールが含まれていることです。
これとともに、MUSA SDKはmuBLAS、muFFT、muThrustのようなライブラリをサポートしており、これらは数学演算や加速コンピューティングのような特定のアプリケーションを対象としています。
MUSA SDKの最新バージョン4.0.1では、スタックはIntelプロセッサに加え、従来のワークロードで採用されている国産のHygon、Kylin、Loongson CPUもサポートするようになった。
Moore ThreadsはNVIDIAのCUDAのようなものとは全く比較にならないが、国産のソリューションを提供することで、小規模な開発者はNVIDIAの代替品にあまりお金をかけることなく、社内GPUのライブラリにアクセスすることができる。
解説：
CUDAの互換性ソフトウェアとしてはAMDのROCmとIntelのoneAPIがあるわけですが、中国のMoor Threadsがこの度MUSA SDKというものを発表したようです。
もちろんCUDAへの互換性が目的でしょう。
CUDAのコードを自動的に変換する仕組みもあるようです。
ただし、似たようなものはoneAPIにもありますし、ROCmはHIPを通じてCUDAのコードがそのまま動作するといわれています。
このMUDA SDKは中国の国策SDKなのでしょう。
ですからかなりの投資を長期にわたって受けられると思います。
しかし、これが流行るかと言われればMoor ThreadsのGPU製品を見ると難しいと言わざるを得ないです。
あくまでも中国が国内の技術でCUDAの互換性を完結にするためのものという位置づけでよいと思います。
HIP SDKもCUDAとの互換性があるといわれています。
実際にZLUDAではWrapperのように動作してHIP SDKにCUDAの処理を飛ばしています。
しかし、ROCmは自力でコンパイルが必要になり、いくつかのソースコードは書き換えねばなりません。
pytorchもそうでした。
おそらく大部分は書き換え不要ですが、それでも16コア32スレッドのCPUで30分から1時間ほどコンパイルに時間がかかる巨大なコードの必要部分を書き換えるというのは素人には難しい処理です。
実際にROCm5.5が出た時に(Nightlyでない)最新のpytorchのpatchを公開していた方もそれ以上過去の分のpytorchに関しては「わたくしの技術では不可能」と言っていましたし、日曜プログラマーのレベルでは難しいのではないかと思います。
何より、修正を行うほどの需要がないのでしょう。
pytorchのNightlyはCUDAではcu118、cu124、cu126、cu128が毎日ビルドされています。
一方でROCmは現在はROCm6.3とROCm6.2.4の最新の2つのバージョンだけになります。
※ ちなみに6.4がビルドされるようになれば6.2.4は落とされます。
CUDAのcu118とかcu124というのはROCmで言えば5.x、6.xなどにあたります。
つまりNightlyで毎日ビルドされるバイナリに関してもこれだけの差があるということになります。
ROCmがCUDAの互換性があるといっても実際にかけられるマンパワーは等価ではないということになります。
ちょうどよいのでROCmの過去のバージョンの互換性についても少し書いておくと、HIPのライブラリにあるrocblasというモジュールが処理のターゲットを決定し、rocblas\libraryの中にあるライブラリファイルが処理を行うという形になっています。
オープンソースですから、わたくしが配布しているスクリプトの中に含まれているファイルのようにユーザーが野良でビルドすることも可能です。
しかし、例えばgfx803=polarisだとROCm4.x相当までの機能セットしか使えません。
メンテナンスモードに入ったもしくはサポート外になったGPUはより進んだバージョンのROCmの機能セットには対応していません。
あくまでもそのGPUが対応していた時点の機能セットまでということになります。
ROCmがCUDAとの互換性を謡っていてもCUDAと等価ではないということはこの説明だけでもうかがえるのではないかと思います。
私ごときに言われなくても重々承知とは思いますが、AMDさんにはもうちょっと頑張ってほしいところです(苦笑。
Intel GPU用のpytorchはすでにWindowsとLinux用の両方がNightlyで毎日ビルドされています。
Intel GPUに関してはこれから世代が進んでいけば、機能セットも進歩して特にAシリーズはサポート外になるタイミングが出てくると思います。
どこまでサポートするかによって価値も変わってくるでしょう。
幸い、RadeonのHIP SDKに関してはオープンソースですから、ユーザーが勝手にビルドして野良バイナリとして公開してくれています。
あとはどれだけ開発元がマンパワーに投資できるかになってきます。
今回のMoor Threadsも素晴らしい話のように聞こえますが、CUDAを超えるような対応状況にするのは難しいでしょう。
これは覚えておいた方が良いです。
ソフトの対応状況=マンパワーで、投資する資金での殴り合いということになります。