NVIDIAはCUDA Toolkit 13.5を公開し、Vera Rubin GPUアーキテクチャの正式サポートを開始した。GPUを分割して使う開発者はリソース配分をより細かく調整でき、複数のGPUを使うチームは通信と計算を1つの実行コードにまとめられる。
1. GPUリソースの割り当てを直接調整
新バージョンは、GPUの演算単位であるストリーミングマルチプロセッサ(SM)を、局所性領域(メモリアクセスが近い単位)ごとに割り当てる方式を拡張した。既定の設定では各領域に同数のSMを保証し、余ったSMは領域外に置く。新設定を併用すると余ったSMも選択した領域に含められるが、領域ごとのSM数が異なる場合がある。
アプリケーションはリソース分割の照会機能で各領域のSM数を確認し、処理量を配分できる。そのため、各領域を同じ大きさに保って予測可能性を選ぶか、各領域で利用可能なSMをより多く活用するかを選択できる。
複数のプロセスがGPUを共有するMPS v3には、重み付き時間分割が追加された。サーバーごとに基本時間への倍率を設定して計算時間を調整する方式で、より長い計算時間が必要な処理を担うサーバーに多くの時間を割り当てられる。
SMパーティションの負荷分散機能では、余裕があるときに基本パーティション外のSMを借り、クライアントのいないパーティションはリソースを貸し出せる。借り入れと貸し出しはそれぞれ設定可能で、MPSは借りたリソースを再割り当てする前に回収する。
メモリ使用量の通知に依存しにくい環境では、リソース回収の要否を判断する際、現在の使用量と上限を直接読み取るポーリング方式を利用できる。通知の配信への依存を減らす代わりに、リソース回収の判断ごとに追加処理が発生する。
2. CUDA TileでのマルチGPU通信
GPUで実行するコードであるCUDA Tileカーネルは、複数のGPUと直接通信できるようになった。単一ターゲットポインターで、GPU間接続技術のNVLinkで接続されたGPUのメモリにアクセスする。マルチターゲットポインターと専用演算は、複数のGPUを結ぶスイッチであるNVSwitchのネットワークで、複数GPUの結果の集約やデータの保存を行う。このネットワークは、複数GPUの結果を集約する通信技術であるNVLink SHARPに対応している必要がある。
GPU群が同じメモリを参照する共有メモリマッピングを実行前に準備すれば、通信と計算をカーネル内で結合できる。例えば、行列乗算とGPU間の結果の合算を1つのカーネルにまとめる方式だ。
Tileカーネルから、従来のスレッドベースの実行方式であるSIMTのライブラリ関数を呼び出す機能も、公開プレビューとして登場した。別々のカーネル間でデータを渡す方式ではなく、カーネルが既に持つデータをそのまま処理できるようになる。対象ライブラリの対応は順次有効化される予定だ。
3. PythonとCCCLの開発の利便性
CUDA Pythonコアライブラリ1.2のバッチコピーは、複数のバッファーコピーを1回のドライバー呼び出しにまとめて投入する。実行手順を再利用するCUDA Graphも、実行するグラフを作り直さずにカーネルパラメーターやメモリコピーなどを更新できるため、アプリケーションのパラメーターが変わっても既存のグラフを再利用できる。
プログラマティック依存実行は、GPUの命令機能の世代区分を表すコンピュート能力が9.0以上のGPUで、協調するカーネルを同じストリーム内で重ねて実行できるようにする。後続のカーネルは、先行するカーネルが終了する前でも独立した処理を開始できる。
以下は原文に掲載された設定例だ。カーネルはプログラマティック依存実行の同期規約を実装する必要がある。
from cuda.core import LaunchConfig, launch
config = LaunchConfig(
grid=num_blocks,
block=256,
programmatic_stream_serialization=True,
)
# The kernel must implement the PDL synchronization protocol.
launch(stream, config, dependent_kernel, *kernel_args)GPUアルゴリズムのライブラリ群であるCCCL 3.5では、CUBの公開チューニングポリシーを使い、ブロックあたりのスレッド数など、アルゴリズムの実行設定を直接調整できる。
浮動小数点の累積和は、加算順序の固定を要求することで、同じGPU・入力・ビルド構成で繰り返し実行した結果を再現できる。
複数の区間からそれぞれ上位または下位K個の項目を取り出すバッチ選択機能も追加された。NVIDIAは、この機能が言語モデル推論ライブラリFlashInferに統合されたと発表した。
4. 数学・画像ライブラリの性能改善
cuBLASで64ビット浮動小数点(FP64)演算を直接行う対称更新の改善は、固有値の求解や行列分解などの科学計算に関わる。NVIDIAによると、一部の演算はNVIDIA B200で最大1.5倍高速化し、この演算を使うコードは修正せずに性能改善を得られる。
cuSPARSEのCSR(行単位の圧縮格納)疎行列・密行列乗算ALG3は、FP32(32ビット浮動小数点)・FP64演算を改善した。NVIDIAは、データセンターGPUでこの演算が1.65~2.27倍高速化したと発表した。
表:cuSPARSEの疎三角求解ALG2のALG1に対する性能
条件:NVIDIAの発表に基づく。疎三角求解のALG1に対するALG2の性能で、測定機器は原文に示されていない。
単位:速度倍率(倍)
| ライブラリ・演算 | 機器・演算条件 | 比較基準 | 向上幅 | 集計方式 |
|---|---|---|---|---|
| cuSPARSEの疎三角求解ALG2 | 機器は示されていない | ALG1 | 2.7倍 | 幾何平均 |
幾何平均は、複数の比率を掛け合わせて平均を求める方式だ。
疎三角システムを繰り返し解く処理では、求解時間と準備時間を分けて確認できる。ALG2は反復求解の性能を高める。NVIDIAによると、求解前の解析段階も幾何平均2.79倍高速化し、準備時間を短縮する。
NVIDIAは、cuSPARSEのグラフ彩色も幾何平均で約3倍高速化したと発表した。
nvJPEGのGPUハイブリッドデコードは、画像サイズや標準ハフマンテーブルの使用の有無に応じて、スループットが10~600%増加したとNVIDIAは発表した。
5. 実行時の負担を配布段階へ移す
nvpruneの事前コンパイルは、パッケージング中に中間デバイスコード(実行機器に合わせて変換する中間コード)をGPUが直接実行する機械語に変換し、対象アーキテクチャが決まった配布物の実行時コンパイルの負担をなくす。その代わり、配布者が対象環境に合ったアーキテクチャを選び、サポートするGPUで成果物を検証する役割を担う。
Rubin以降のGPUをWindowsで配布する際は、従来のTCCではなく、WDDMまたは計算専用のMCDMドライバーモードを使う必要がある。
cuobjdumpのシンボル出力は説明付きの4列形式に変わるため、その出力を読み取るスクリプトも修正する必要がある。
CUDA 13.5の核心は、GPUの分割や複数GPUの接続の選択肢を広げ、開発者がリソース活用と実行方式のバランスを直接調整できるようにした点にある。
