速報！Nvidia、CUDAにネイティブPythonサポート追加！GPUプログラミングが超簡単になる！？

ブラックボックスなアクセラレータとしてCUDAを使う場合の正しい計測方法を説明したつもりなんだけど。

好きなようにメトリクスを作ればいいじゃん！
でもCUDAは単なるブラックボックスの数学アクセラレータじゃないよ。そう扱うのは勝手だけど、そうじゃない。ドライバーやコンテキスト、ライフサイクルを持つエコシステム全体なんだ。すべてが同期してるとか、関係ないコストを含んでも気にしないなら、time.time()でも良いけど、それならもっと大きな問題があるかもね。

「もっと大きな問題がある」って言うのは簡単だよね。いつでももっと大きな問題はあるし。
でも、Fortranの数値計算コードは50年分くらいあるし、RCIを使ってるものも多い…もし既存のライブラリでCUDAを試したいなら、RCIに戻る前にベクトルを取り戻す必要があると思う。

今週読んだ中で一番賢明なことの一つだ。
GraphQLサーバーのベンチマークツールを作ったんだけど、Coordinated Omissionの問題やHDR Histogramsのようなフォーマットについて学んだよ。
ベンチマークは正しく行うのが難しいだけでなく、次のような免責事項をつけるべきだと思ったよ。「これらはXマシンで、Y時間に、Zリソースで得られた結果です」

CUDAは使ったことないけど、graphics APIsのタイムスタンプクエリと同じようなものだと思うけど、どう？

状況によっては使えるけどね。でもevent APIsの方がベターだよ。

たぶんそうだよ。元のコードはこんな感じだよ：
＞print（”Adding matrices using GPU…”）
＞start_time = time.time()
＞gpu_result = add_matrices(gpu_matrices)
＞cp.cuda.get_current_stream().synchronize() # Not 100% sure what this does
＞elapsed_time = time.time() - start_time

聞きたいんだけど、CUDAのプロって、Pythonの人が知っておくべきことを教えてくれないかな？

CUDAのメソッド呼ぶと非同期で実行されるんだって。関数はGPUでの実行をキューに入れて、すぐに戻ってくる感じ。
だから、処理が終わるのを待つ必要があるなら、synchronizeが必要。
get_current_streamは、キューがCUDAではストリームって呼ばれてるから。
複数の処理を同時に実行したいなら、複数のストリームを使うといいよ。
ベンチマークとか、別々のストリームで実行した処理の結果を組み合わせたいときとかに使うね。
pytorch使ってるなら、GPUで処理するときバックグラウンドで実行されるから、ベンチマークするならsync API使うといいよ。

PythonでGPU使うときasyncio使わないのって変だなってずっと思ってたんだよねー。Python-on-GPUがasyncioより前からあったからかなって思ってたけど。
新しいライブラリでそこらへん改善されるかなって期待してたけど、そうでもないみたい。
他の言語ってGPUの非同期性を言語レベルのasyncで扱ってて、synchronizeみたいなの避けてたりするのかな？

GPUの場合はCoroutineベースのasyncとは使い方が全然違うからだよ。
GPUでは、できるだけ多くの非同期処理をキューに入れて、最後にsynchronizeするんだ。
＞b ＝ foo(a)
＞c ＝ bar(b)
＞d ＝ baz(c)
＞synchronize()
Coroutineだと、
＞b ＝ await foo(a)
＞c ＝ await bar(b)
＞d ＝ await baz(c)
みたいに、毎回synchronizeしちゃうから効率悪い。

GPUに限らず、基本的には最初のやり方(非同期処理をまとめてキューに入れる)がいいと思うよ！

非同期ストリームを扱ってるか、単一の非同期の結果を次の関数の入力として扱ってるかで変わってくるよね。もしaがリソースbにアクセスするために必要なアクセストークンなら、aとbに同時にアクセスできないから、処理を直列化する必要がある。

複数のCoroutine/タスクを作って、それをgatherすればいいじゃん。CUDAをネットワーク呼び出しに置き換えても、全く同じ問題だよ。asyncioとは関係ない。

いや、それは違うシナリオだよ。僕が言ってるのは、リクエスト間に依存関係がある場合。gatherを使うと、ネットワークリクエストは並列に実行される。依存関係がある場合は、後のリクエストが前のリクエストの値に依存するから、本質的に順番に実行される必要がある。
CUDAのトリックは、値の代わりにバッファを入力/出力として宣言し、CUDAのストリーム機構によって自動的に順序が強制されること。それをCoroutine機構と組み合わせても、意味がない。

ライブラリの実装によると思うけど、PythonからのGPU呼び出しは、実際にはC＋＋で処理されてるんじゃないかな。で、ライブラリ内部でsynchronizeが使われてたりするのかも。

どうもありがとう！

ありがとうございます。コード例がないか記事を何度も見返しちゃいました。

マジ助かるー。Pytorchがここまで勢いつけた後にCUDAのPythonサポートとかマジありえん。
これでプラットフォームに依存しない、ある程度標準化された並列計算環境が手に入るじゃん。NVIDIAの独自仕様に縛られなくて済むー。
PytorchのNVIDIAバックエンド部分がPythonで直接実装できるのはマジでかいけど、エンドユーザーとか開発者にはあんま関係ないかもね。
でも、この新しいプラットフォームでGPUを使ったPython計算がゲームとか他の分野にも広がるかも。RustのゲームがPython経由でGPU上で爆速で動くとか想像してみ？

これでGPUで数値計算するのめっちゃ楽になるじゃん。マジありがたい。
Pytorchみたいに抽象化されてる方がいいって意見もわかるけど、個人的には時間があれば触ってみたい。
色々できること増えそう。

CuTileはOpenAIのTritonの後継って感じだよね。Tile/blockレベルのプリミティブとかTileIRだけじゃなくて、CuPyでちゃんとしたSIMTプログラミングモデルが使えるのもマジですごい。
GTCであんま注目されてないけど。
Grace CPUに関する発表がほとんどなかったのは気になる。NvidiaのCPUとGPUでシームレスに動く抽象化はまだ先かな。
並列アルゴリズムを毎日書いてる身としては、NSightとかCUDA-GDBでのデバッグはGDBと違うし、CPUでアルゴリズム設計してからGPUに移植する方が楽なんだよね。
ModularはLLMに夢中になってない数少ないチームの一つで、複数プラットフォームをカバーする抽象化とか言語を開発してる。Mojoに期待したい。CPU-GPU間のギャップを埋めてくれるかも！

＞And not only are we getting tile/block-level primitives and TileIR
＞タイル/ブロックレベルのプリミティブとTileIRが手に入るだけじゃないってマジ？
グラフィックスプログラミングしてる身としては、AI向けのGPU APIにばかり投資されて、レンダリング向けのGPU APIにはほとんど投資されないのがマジ不満。
ブロックレベルのプリミティブはグラフィックスにマジで役立つ！PyTorchみたいなCPUからプログラムできるJITカーネルもグラフィックスにマジで役立つ！
…でも金にならないから誰もやらないんだよね。
しかも、AI向けのGPU APIとレンダリング向けのGPU APIが別物扱いなのも意味不明。

統合するのは無理があると思う。CPUとGPUって性能特性が全然違うし、設計思想も違うじゃん。そこそこ良いインターフェースでそこそこ良い感じに動く共通基盤を作ることはできるけど（PyTorchがそうだと思う）、CPUで無駄に性能が出ないアルゴリズムを書くのはナンセンス。だって、CPUはGPUみたいにコンテキスト間の同期が超遅いわけじゃないし。

マジでかい。AMD + ROCmをNVIDIAの代替として考えてた人も、もう考えなくなるんじゃない？
GPUでコード書くためにC++をガッツリ勉強したくない（できない）人からすると、PythonからGPUに直接アクセスできるのはマジありがたい。
効率化の影響はPyTorchみたいなPythonライブラリだけじゃなくて、NVIDIA GPUで動くもの全部に影響する。
OpenAIとかGoogleがGPU動かすために原子力発電所をどれだけ必要とするかみたいな話を聞くから、効率が上がるのはマジ嬉しい。

AMDとAppleがKhronosと一緒にOpenCLっていう競合製品を作ったって言えるかもね。でも業界全体でサポートしなかったから、結局主要な関係者はみんなOpenCLを見捨てちゃった。
その10年間、Nvidiaはソフトウェアを改善したり、GPUアーキテクチャをAI向けに最適化したりしてた。AppleとAMDはラスタライズ性能を最適化しようとしてた。
Nvidiaは独自のアーキテクチャとSDK、業界の支持、市場のニーズを持ってる。AMDが同じレベルになるには、優先順位を見直して、アーキテクチャを刷新する必要がある。

AppleがKhronosにマジ切れしたせいかもね。AMDとIntelはCUDAみたいなIDE統合、グラフィカルデバッガ、ライブラリのエコシステムを提供しなかった。
KhronosはC++とかFortranとか、GPUで使いたい言語をサポートする必要性を感じてなかった。
KhronosがC++サポートとSPIRを追加したけど、IntelとAMDは対応できなくて、OpenCL 3.0はOpenCL 1.0のリブランドになった。
SYCLもIntelしか気にしてないみたいで、DPC++っていう拡張機能も追加してる。Codeplayを買収して初めてSYCLツールを提供した。
AMDと違って、Intelはみんながソフトウェアスタックを使えるようにしないと誰も使ってくれないってことを理解してる。

Appleは標準規格を捨てたのに、代替品を何も作らなかったんだよね。独自の代替案も競争力のある位置にできなくて、TSMCのチップ（めっちゃ高い）をトレーニングに使えないとかマジ？
https://www.eteknix.com/apple-set-to-invest-1-billion-in-nvi…
業界がCUDAに抵抗しなかったとは言えないよね。関係者がメキシカンスタンドオフみたいになって、Nvidiaは鼻歌まじりでウハウハ。OpenCLがVulkanみたいに扱われてたら、今とは全然違う市場になってたかもね。

いやいや、Metal Computeがあるじゃん。Apple製品使ってる人はみんな使ってるし。
Vulkan？
GNU/LinuxとAndroidだけじゃん。Googleが推してるからって、ほとんどの人はOpenGL ES使ってるし。誰も気にしないし、OpenGLみたいにぐちゃぐちゃになってるから、Vulkanised 2025で整理方法を話し合うとか。
NVidiaとAMDはMicrosoftとDirectXを最初に設計して、Vulkanは後回し。

＞NVidiaとAMDはMicrosoftとDirectXを最初に設計して、Vulkanは後回し。”
マジ？例えば、NVIDIAは新しいレイトレーシングとニューラルネット技術のために、Vulkan拡張機能をリリースしたじゃん(VK_NV_cluster_acceleration_structure, VK_NV_partitioned_tlas, VK_NV_cooperative_vector)。DirectX12用のNVAPI拡張機能もあるし。DirectX12はNVAPIが必要で、DXCのプレリリース版に頼らないといけないから、Vulkanより技術的には劣るけどね。
APIは表面的にも、ドライバーの実装もほぼ同じ。NVIDIAはVulkan/DirectX12のラッパーであるnvrhiプロジェクトを持ってるから、1つのAPIで複数のプラットフォームで実行できる。

例外じゃん。DirectXニューラルシェーダーとRTXキットのVulkan拡張機能はどこ？
DirectX 8シェーダーモデルの導入以降、NVidiaとの協力でCgがHLSLの基礎になった例もあるし。
独自のAPIはKhronos APIみたいに拡張機能がスパゲッティにならないから。KhronosはGoogleとSamsungがVulkanを採用したのがラッキーだっただけ。ValveのSteam Deckとか、IoTディスプレイとか。
他の場所では、主要な3D APIをすべてサポートするミドルウェアエンジンがあるし、WebGPUもVulkanのせいでブラウザの外でミドルウェアになってる。

＞例外じゃん。DirectXニューラルシェーダーとRTXキットのVulkan拡張機能はどこ？”
DirectXの”ニューラルシェーダー”は、さっき言ったVK_NV_cooperative_vector拡張機能じゃん。カスタムのプレリリース版DXCが必要ないから、Vulkanの方が使いやすいし。RTXキットも同じ。例えば、https://github.com/NVIDIA-RTX/RTXGI はVKとDX12の両方をサポートしてる。

＞Metal Computeがあるじゃん。Apple製品使ってる人はみんな使ってるし。”
競争が激しいサブマーケットみたいじゃん。Metal ComputeとApple Accelerate FrameworkとMLXが同じ場所にあるって！Appleは文字通りの意味で頑張ってるね。
＞It is only relevant on GNU/Linux and Android
あれ… 悲しみの第一段階ってなんだっけ？忘れちゃった。

OpenAIのTritonコンパイラに貢献してるよ。実行モデルが似てる。

＞But to have a direct pipeline to the GPU via Python
GPU API (CUDA, OpenCL, OpenGL, Vulkanとか)をスクリプト言語で使ったことある？
Nvidiaがエコシステムを作ったのはすごいけど、C++やFortranには勝てないし、普通のPythonコードをそのままGPUで実行できないよ。CUDAはやっぱりCUDAだよ。
CUDAバインディングは15年以上前からあるし。ほとんどの人はTorchとか高レベルのものを使うと思う。
NvidiaのPythonに関する広告と説明書もあるし。
https://developer.nvidia.com/cuda-python
https://developer.nvidia.com/how-to-cuda-python
現実はつまらないし、この記事はクリックベイト。

＞It’s cool that Nvidia made a bit of an ecosystem around it but it won’t replace C++ or Fortran and you can’t simply drop in ”normal” Python code and have it run on the GPU.”
厳密には普通のPythonコードじゃないけど、GPUカーネルを内部DSLで書けるPythonライブラリがあるよ。NumbaとかTaichiとか。
NvidiaはCUDA Pythonで同じことをやろうとしてるみたい。CUDAコードの新しいパラダイム（CuTile）をC++より先にPythonで導入するかも。Taichiみたいなものより先に行こうとしてるのかもね。
＞Also, here’s Nvidia’s own advertisement for Python on their GPUs
これはGTCで発表された新しいネイティブ機能の話じゃないよ。既存のCUDA PythonはC++で書かれたカーネルをインライン文字列で使う。

OpenCLとかOpenGLって、Cコンパイラに入力するスクリプト言語みたいなもんだよね。CUDAの強みは、Vulkanみたいな面倒な準備なしに、意味のある型とコンパイルエラーがあったこと。でもこれって、ちょっと違うカッコの書き方が好きな人向けの、GPU上のpython-for-CUDA-Cの完全な代替品って感じ。

＞But this is 100% a python-for-CUDA-C replacement on the GPU”って言ってるけど、うーん。Nvidia製のPythonの数学ライブラリ、eDSL、キュレーションされたライブラリの集まりって感じかな。NumpyとかTritonとかと大差ないと思うんだよね。Nvidia製でツールにバンドルされてるって点を除けば。

パフォーマンスへの影響が一番気になるんだよね。ハードウェアとの間に余計なものが少ないほど、理論的にはパフォーマンスは向上するはず。NVIDIA GPUデータセンターに電力を供給するために原発を建てようとしてる企業があるくらいだから、できる限りコードを最適化する必要があると思う。

そうそう、シェーディング言語はもっと生産性が高くて、変な落とし穴もない方がいいよね。だって、コンピューティングデバイスのためにゼロから設計されたんだから。CUDAの多言語性は、OpenCLの時代遅れな「C99方言しか認めない」っていう姿勢に対する強みだったんだよね。

NVIDIAのカードはどこにでもあるよ。AMDとの最大の違いは、うちのポンコツノートPCのGeForceカードでもCUDAが使えるってこと。CUDAプログラミングを学んだり始めたりするのに、RTXなんて必要ないんだよね。

確かに。CUDA 12.xでサポートされてる一番古いアーキテクチャはMaxwellだったはず。Maxwell（GTX 980とか）は2013年頃に出たんだっけ。ROCmが3つくらいしかコンシューマー向けのAMD GPUをサポートしてないことを考えると、10年以上のサポートは悪くないよね。だから、君のポンコツノートPCのGTX 750TiはCUDAには使えないかも。でも、君のポンコツ1050Ti Max-Qなら大丈夫！

これってJAX[1]と比べてどうなんだろう？JAXを使うと、NvidiaのGPUだけでなく、他のブランドのGPUでもPythonコードを実行できるんだよね（サポートは色々だけど）。NumPy関数のドロップインリプレースメントもあるし。これはNvidiaしかサポートしてないけど、JAXにはできないことができるのかな？使いやすい？固定サイズの配列に縛られない？一つのブランドのGPUに縛られる価値はある？
[1]https://github.com/jax-ml/jax

まあ、JAX/CUDAにまだ実装されてない処理を実装する低レベルのCUDAカーネルを書いて、既存のプロジェクトに統合するってことだよね。Numba[1]が一番近いと思う。（というか、今見てみたら、Nvidiaのこの取り組みって、実はNumbaがベースになってるみたいだね。）
[1]: https://numba.readthedocs.io/en/stable/cuda/overview.html

次はRustのサポートかな？今はカーネルとの間で、データ構造をバイト配列として手動でシリアライズ/デシリアライズしてるんだよね。CUDAがC++で提供してるような、真に共有されたデータ構造が欲しい！

CUDAが輝く分野、例えば数値計算とか線形代数とかで、Rustってまだあんまり使われてないよね？C++とかFortranで十分じゃね？メモリ管理もそんな複雑じゃないし。

数値計算のコードってめっちゃ長生きだからね（だからFORTRANが現役なんだし）。

それだけじゃないよ。Fortranは数値計算コード書くのにマジ優秀。最近のFortranは使いやすいし、簡単に自動並列化できる方法も色々あるし、新しいFortranコードも普通に作られてるよ。CERNで働いてる友達が言ってた。

新しいところだと、slangの方が採用される可能性あるかもね。

たぶんこれのことじゃないかな？https://shader-slang.org/
一見した感じ、GPGPUよりグラフィック向けっぽいけど。
編集：このプロジェクトの一部は汎用目的っぽくて、PyTorchと連携してるみたい。
https://slangpy.shader-slang.org/en/latest/

そうそれ。shader languageは全部computeもサポートしてるよ。グラフィックだけじゃなくてね。

ありがとう。でも単なる可能性じゃなくて、用途によって設計が変わるってことを言いたかったんだ。

Rust-CUDAプロジェクトが最近再始動したんだ[0]。ちょっと調べてみてるんだけど、夏は暇だから貢献したいな。[0] https://github.com/rust-gpu/rust-cuda

まだ動かないけどね！何年も前から。最近のGH issueで再起動の要望に関して、私は聞いたよ。“いくつかの異なるマシン（OS、GPU、CUDAバージョンなど）で試して、エラーなしに最新のRustCとCUDAバージョンで動作するようにしてください。“返事は“それはかなりの作業になるでしょう。“だった。一方、Cudarcは動作する…

メンテナーだけど、壊れてないしちゃんと動くよ。詳しくはhttps://rust-gpu.github.io/blog/2025/03/18/rust-cuda-updateを見てね。

ありがとう！試してみてまた報告するね。
編集：まだ最新リリースが2022年のものとして表示されてる。これはもう試してて、動かないって確認済み。

そりゃ全部動かすには時間かかるよね。ポジティブな点としては、最近Modal[0]からスポンサーシップを得て、CI/CD用のGPUを提供してもらえるようになったから、ハードウェアの対応範囲を拡大できるはず。

Burn frameworkってどう思う？（マジな質問、マジで何もわかってないんだ）

Burnで自分のミニGPTを学習させたけど、結構気に入ったよ。ジェネリクスが少ないRustのスタイルが好きなんだけど、あのプロジェクトの目標を考えると避けられないのかも。このcrateは勢いがあって、新機能、リリース、GHやDiscordでの活発なコミュニティもあるし、どんどん良くなっていくと思う。

聞いたことないな。調べてみた。関係ないんじゃない？
Cudarcを使ってる。

Rustの所有権セマンティクスがGPUプログラミングに全然合わないってことを置いといても、ML研究者は絶対にRustを学ばないから、これは絶対にありえない…

原則的には同意するけど、CUDAはAIだけじゃないってことをみんな忘れすぎ。