common.title

Docs
Quantum Circuit
TYTAN CLOUD

QUANTUM GAMING


Overview
Contact
Event
Project
Research

Terms of service (Web service)

Terms of service (Quantum and ML Cloud service)

Privacy policy


Sign in
Sign up
common.title

NVIDIA cuTensorNetの和訳説明その1(全体概要)

Yuichiro Minato

2022/05/15 07:35

1

こんにちは、NVIDIAの新しいライブラリを使いたいですよね。状態ベクトルシミュレータは開発者が日本人ですので、NVIDIAの森野さんが解説してもらうのが分かりやすいと思います。ここではもう一つのテンソルネットワークライブラリについて解説したいと思います。

https://docs.nvidia.com/cuda/cuquantum/cutensornet/overview.html#description-of-tensor-networks

翻訳を交えて紹介します。

「テンソルネットワークは、量子回路シミュレーション、量子多体系物理学、量子化学、機械学習など、多くの数学的・科学的領域で登場する。ネットワークの規模が指数関数的に増大するにつれ、テンソルネットワークの収縮を効率的に行うための高性能なテンソルネットワークライブラリの必要性が高まっており、cuTensorNetはその役割を果たすことを目指しています。」

ということで、今回はおもにテンソルネットワークの中でも縮約の効率化を行っているようです。

「テンソルネットワークとは、任意のランクのテンソルを収縮させた集合体である。構成テンソル間の縮約はネットワークのトポロジーを完全に決定する。例えば、以下のテンソルは、テンソルを縮約したものである。」

面倒なので以下DeepLです。

ここで、同じラベルはアインシュタインの縮約記法に則って縮約されます。この例では, モードラベル(インデックス)iはテンソルAとDを、 モードラベルjはテンソルAとBを、モードラベルkはテンソルBとCを、モードラベルlはテンソルCとDを接続している。ラベルがabcdの4つの未縮約モードは、自由モード(外部モードとも呼ばれる)を意味し、結果として得られるテンソルはランク4であることを示している。

cuTensorNetライブラリでは、cuTensorライブラリの命名法に従っている。

・ランクNのテンソルはNモードある。

・それぞれのモードは、サイズをもっている。3*3行列では、2つのモードで、それぞれサイズが3となっている。

・各モードは、そのモードに沿った論理的に連続する2つの要素間の物理メモリ上の距離を、要素単位で表すストライドを持つ。

NumPy/CuPyのユーザーにとっては、rank/orderはndim属性に、extentsのシーケンスはshapeに、stridesのシーケンスはstridesと同じ意味を持ちます。

cuTensorNet ライブラリのテンソルネットワークは cutensornetNetworkDescriptor_t 記述子によって表現され、ネットワークのトポロジーとデータタイプを効果的にエンコードする。具体的には、入力テンソルの数を numInputs に、各テンソルのモード数を numModesIn に、各テンソルのモード、エクステント、ストライドをそれぞれ modesIn, extentsIn, stridesIn のポインタ配列に指定する。

同様に、出力テンソルについても同様の情報(例えば numModesOut, modesOut, extentsOut, stridesOut)を保持する。なお、出力テンソルはネットワークごとに1つだけなので、numOutputsを設定する必要はなく、対応する引数は単なる配列である。

これらのネットワークメタデータはすべてホスト上に存在することが可能である。なぜなら、テンソルネットワークを構築する際にはそのトポロジーとデータアクセスパターンのみが問題となり、ネットワーク記述子作成時に入力テンソルの実際の内容を知る必要はないからである。

内部的には、cuTensorNetはcuTENSORを利用してテンソルオブジェクトを生成し、ペアワイズテンソル収縮を行う。cuTensorNetのAPIは、ユーザがそのような「低レベル」の詳細を自分で管理せずにネットワーク記述の作成だけに集中できるような設計になっている。テンソル収縮は cutensornetComputeType_t 定数によって与えられるデータ型とは異なる精度で計算することができる。

有効なテンソルネットワークが作成されると、以下のことが可能になる。

1.低コストの収縮パスを見つける(場合によってはスライスと追加制約を伴う)

2.収縮パスに関する情報にアクセスする

3.中間テンソルを収容するために必要なワークスペースの大きさを取得する

4.上記で収集した情報に基づき、縮約計画を作成する

5.ネットワーク収縮の実行時間を最適化するために収縮計画を自動調整する

6.出力テンソルを取得するために実際の収縮を実行する

ワークスペース(Step3)と入出力テンソル(Step5)のデバイスメモリ管理はユーザの責任で行う。cuTensorNet APIのAPIリファレンス(section Workspace Management API)を参照のこと。また、ワークスペースのメモリ割り当てを容易にするために、ユーザはライブラリにストリーム順のメモリプールを提供することができる。詳細はメモリ管理APIを参照。

収縮パスファインダ

収縮パスは、numpy.einsum_path() フォーマットで表現されるペアワイズ収縮のシーケンスである。パスオプティマイザの役割は、テンソルネットワークの縮約コストを最小にする縮約パスを見つけることである。cuTensorNetのパスファインダはグラフ分割アプローチ(フェーズ1と呼ぶ)に基づき、その後スライスと再構成(フェーズ2と呼ぶ)を行う。実際、経験上、最適な収縮経路を見つけることは、設定パラメータの選択に敏感であることが分かっている。したがって、これらの多くは cutensornetContractionOptimizerConfigSetAttribute() を介して設定することが可能である。

スライシング

workspaceSizeConstraintで指定された利用可能なデバイスメモリにテンソルネットワークの収縮を適合させるために、スライス(可変投影またはボンドカットとしても知られている)を使用することが必要な場合がある。各スライスは他のスライスとは独立して計算することができる。したがって、並列計算を行う場合、スライスは各デバイスに独立した作業を作成するため、最適な手法の1つでもあります。同様に、利用可能なすべてのノードに対して仕事を作成するために、スライスされた収縮を使用することもあります。スライスとは、あるモード(またはモードの組み合わせ)の特定の1つの位置のみについて収縮を計算し、スライスされたモードの範囲の積に等しい数のスライスを作成することを意味します。そして、個別に計算された値を合計することで、完全なテンソルネットワークの収縮を再現することができる。このような手法は、大規模なテンソルネットワーク、特に量子回路において、縮約を行うためのメモリフットプリントが既存のメモリストレージを超える可能性がある場合に有効である。上記のテンソルを例にとると、モードiをスライスすると以下のようになる。

ここで、スライスされたモードはもはやテンソル収縮の一部として暗黙的に合計されるのではなく、代わりに明示的に合計されます(潜在的に並列で)。スライスはメモリフットプリントを減らしますが、通常は収縮のフロップ数を悪化させ、どのスライスモードのセットが最高の性能をもたらすかを決定する簡単な方法はありません。

cuTensorNetライブラリはスライス探索アルゴリズムに影響を与えるいくつかの制御を提供します。

CUTENSORNET_CONTRACTION_OPTIMIZER_CONFIG_SLICER_DISABLE_SLICING: 1に設定すると、利用可能なメモリに関係なく、スライスは考慮されない。デフォルトは 0 です。

CUTENSORNET_CONTRACTION_OPTIMIZER_CONFIG_SLICER_MEMORY_MODEL: ワークスペースのサイズを決定するために使用するメモリモデルを指定します、 cutensornetMemoryModel_tをご覧ください。デフォルトは cuTENSOR と互換性のあるメモリモデル (CUTENSORNET_MEMORY_MODEL_HEURISTIC) を使用します。

CUTENSORNET_CONTRACTION_OPTIMIZER_CONFIG_SLICER_MEMORY_FACTOR: ワークスペースサイズに対する割合として、最初のスライス探索反復のメモリ制限値です。デフォルトは、メモリモデルにCUTENSORNET_MEMORY_MODEL_CUTENSORを使用する場合は80、CUTENSORNET_MEMORY_MODEL_HEURISTICを使用する場合は100です。

CUTENSORNET_CONTRACTION_OPTIMIZER_CONFIG_SLICER_MIN_SLICES: 生成するスライスの最小数を指定します (例: 並列化可能な作業を作成するため)。デフォルトは1です。

CUTENSORNET_CONTRACTION_OPTIMIZER_CONFIG_SLICER_SLICE_FACTOR: スライス探索の反復ごとにスライス数を増加させる係数を指定します。た と えば、 前の反復でNスライスがあったとしてスライス係数sを指定すると、 次の反復では少なくともsNスライスが生成されます。スライス探索の各反復の後に再構成(下記参照)が行われるので、この値を増やすと再構成の量が減り、その結果、かかる時間が減りますが、おそらく収縮木の品質が悪化します。デフォルトは32です。最低でも2でなければなりません。

再構成

各スライス探索の反復が終了した時点で、スライスによって縮約木の品質が低下している。この段階で再構成を行うことで、縮約木を改善することができる。再構成は、全体の収縮木の中のいくつかの小さなサブツリーを考慮し、その品質を改善しようとするものである。このプロセスは計算コストがかかるが、再構成されないスライスされた収縮木の実行コストは予想より数桁高くなる可能性がある。cuTensorNetライブラリは再構成アルゴリズムに影響を与えるためのいくつかの制御を提供する。

CUTENSORNET_CONTRACTION_OPTIMIZER_CONFIG_RECONFIG_NUM_ITERATIONS: 各再構成時に考慮するサブツリーの数を指定する。通常パスファインダーの実行時間を支配する再構成に費やす時間は、この値に直線的に比例する。我々の実験によると、500から1000の間の値が非常に良い結果をもたらす。デフォルトは500です。0に設定すると、再構成が無効になる。

CUTENSORNET_CONTRACTION_OPTIMIZER_CONFIG_RECONFIG_NUM_LEAVES: 再構成によって考慮される各サブツリーのリーフノードの最大数を指定する。最適なサブツリーの再構成に要する時間はこの量に対して指数関数的であるため、大きな値を選択すると、より高速な非最適化アルゴリズムが呼び出される。それにもかかわらず、この量を増やすと、再構成に費やす時間が非常に速くなる。デフォルトは8で、最低でも2でなければなりません。 通常、デフォルト値を使用すると最適なフロップ数が得られますが、6に設定すると、多くの問題でフロップ数を大幅に増加させずにパスファインダーの実行を高速化することができます。

繰延べランク簡略化

経路探索アルゴリズムにかかる時間はテンソル数の増加に伴い急速に増加するため、可能であればテンソル数を最小にすることが有利である。ランク簡略化では、性能向上のため、ネットワークから些細なテンソル収縮を除去する。これらの縮約とは、テンソルが最大2つの近傍としか縮約されず、事実上、行列の乗算を行うようなものである。簡略化を行うために必要な収縮はすぐに行われるのではなく、返される収縮パスの前に追加される。何らかの理由でこのような簡略化が必要ない場合は、これを無効にすることができます。

CUTENSORNET_CONTRACTION_OPTIMIZER_CONFIG_SIMPLIFICATION_DISABLE_DR: 1に設定すると、簡略化はスキップされます。これにより、経路探索アルゴリズムが完全なテンソルネットワークで実行され、必要な時間が増加する。デフォルトは0である。

単純化はほとんどの場合FLOPカウントを下げるのに役立ちますが、時には(ネットワークのトポロジーや他の要因に依存して)FLOPカウントがより高いパスを導くことがあります。簡略化をオフにする(上記のオプションを使用する)と、計算されたパスにどのような影響があるか、ユーザーが実験することをお勧めします。

ハイパーオプティマイザ

cuTensorNetは、収縮パスの多数のインスタンスを自動的に生成し、総フロップ数の点でそれらのうち最良のものを返すことができるパスファインダーのハイパーオプティマイザーを提供する。インスタンスの数はCUTENSORNET_CONTRACTION_OPTIMIZER_CONFIG_HYPER_NUM_SAMPLESでユーザーがコントロールでき、デフォルトでは0に設定されています。ハイパーオプティマイザーはCUTENSORNET_CONTRACTION_OPTIMIZER_CONFIG_HYPER_NUM_SAMPLESインスタンスを作成し、それぞれがパスファインダーアルゴリズムの異なるパラメータを持つということです。各インスタンスは、再構成とスライシング(要求された場合)を含む完全なパスファインダーアルゴリズムを実行します。ハイパーオプティマイザーのループが終了すると、(フロップ数で)最適なパスが返されます。

ハイパーオプティマイザーはそのインスタンスを並列に実行します。スレッド数はCUTENSORNET_CONTRACTION_OPTIMIZER_CONFIG_HYPER_NUM_THREADSで設定でき、デフォルトでは利用可能な論理コアの半分に設定されます。スレッド数を利用可能な論理コアの数に制限することで、不必要に多くのスレッドを使用した場合に発生する可能性のあるリソース競合を回避することができます。

現在、ハイパーオプティマイザーのマルチスレッドは、OpenMPとによって実装されています。

OpenMP環境変数(例:OMP_NUM_THREADS)は使用されません。

OpenMPの内部構成/設定は影響を受けません。つまり、omp_set_*()関数は呼び出されません。

ハイパーオプティマイザーによって変化する設定パラメーターは以下のとおりです。

CUTENSORNET_CONTRACTION_OPTIMIZER_CONFIG_GRAPH_NUM_PARTITIONS: cutoffより大きなサイズのネットワークはnum_partitionsのパーティションに分割される。この処理は、各パーティションのサイズがcutoffの値以下になるまで再帰的に繰り返される。num_partitionsの許容範囲は[2, 30]である。ハイパーオプティマイザーが無効の場合、デフォルト値は8である。

CUTENSORNET_CONTRACTION_OPTIMIZER_CONFIG_GRAPH_CUTOFF_SIZE: ネットワークは、各パーティションのサイズがこのカットオフ値以下になるまで num_partitions で再帰的に分割されます。cutoff_sizeの許容範囲は[4, 50]である。ハイパーオプティマイザーが無効の場合、デフォルト値は8である。

CUTENSORNET_CONTRACTION_OPTIMIZER_CONFIG_GRAPH_ALGORITHM: グラフ分割に使用するグラフアルゴリズムです。利用可能な選択肢は cutensornetGraphAlgo_t enum に記載されています。

CUTENSORNET_CONTRACTION_OPTIMIZER_CONFIG_GRAPH_IMBALANCE_FACTOR: パーティション間のサイズ不均衡の最大許容値を指定する。許容範囲[30, 2000]。ハイパーオプティマイザーが無効の場合、デフォルト値は200です。

CUTENSORNET_CONTRACTION_OPTIMIZER_CONFIG_GRAPH_NUM_ITERATIONS: グラフパーティショナーのアンコースニング処理の各段階における、洗練アルゴリズムの反復回数を指定する。許容範囲 [1, 500]. ハイパーオプティマイザーが無効の場合、デフォルト値は60である。

CUTENSORNET_CONTRACTION_OPTIMIZER_CONFIG_GRAPH_NUM_CUTS: グラフパーティショナーが計算する異なるパーティショニングの数を指定する。最終的なパーティショニングは、最良のエッジカットまたは通信量を達成するものである。許容範囲 [1, 40]. ハイパーオプティマイザーが無効の場合、デフォルト値は10である。

これらのパラメータのいくつかは、(cutensornetContractionOptimizerConfigSetAttribute()によって)与えられた値に固定することができます。パラメータが固定されている場合、ハイパーオプティマイザーはそのパラメータをランダム化しない。CUTENSORNET_CONTRACTION_OPTIMIZER_CONFIG_SEED 属性で種を設定することにより、ランダム性を固定することができる。

サポートされるデータ型

テンソルネットワーク縮約のためのデータ型と計算型の有効な組み合わせは、cuTENSORのそれをそのまま受け継ぐ。詳細はcutensornetCreateNetworkDescriptor()と cuTENSOR のユーザーズガイドを参照されたい。

References

For a technical introduction to cuTensorNet, please refer to the NVIDIA blog:

For further information about general tensor networks, please refer to the following:

For the application of tensor networks to quantum circuit simulations, please see:

For citing cuQuantum, please see:

© 2025, blueqat Inc. All rights reserved