量子コンピュータのための量子ベンチマーク

11月

2023

Anastasia Marchenkova

量子コンピューティングは、材料、医療、金融など、いくつかの産業に革命をもたらすと期待されている。しかし、疑問は残る：量子コンピューターは、いつになったら現実の問題を解決できるようになるのだろうか？

‍

我々は100万量子ビットを持つ新しい量子システムを発表した！」という誇大広告に踊らされたプレスリリースは、その全貌を語ってはいない。誤差が非常に大きく、コヒーレンス（量子状態が保存される時間の長さ）が低い100万量子ビットは、100個の理想的な量子ビットほど有用ではない。

‍

しかし、このような量子マシンの有効性や性能をどうやって判断するのだろうか？古典的なコンピュータほど簡単ではない。広く受け入れられているSPECベンチマークは、整数演算や浮動小数点演算のようなCPUタスク、メモリやストレージ機能、マルチスレッディングのようなシステムレベルのオペレーション、データベースクエリやウェブサーバのスループットのようなアプリケーション固有のタスクなど、コンピュータ性能のさまざまな側面を測定する。これらのベンチマークは、異なるハードウェアやソフトウェア構成を比較するための標準化された方法を提供します。

‍

IBM主導の量子ボリュームのように、ゲートエラーや測定エラー、クロストーク、コネクティビティなどの要素を組み込んだ、新しいシングルナンバーの集計指標もある。しかし、まだ欠けているパラメータがある。ゲートの動作時間でさえ、技術文書からしばしば欠落している。従来のコンピューターがその能力を示すために性能テストやストレステストを受けるように、量子コンピューターもその影響を示すためにベンチマークが重要である。

ベンチマーキングとは何か？

ベンチマークとは、最も単純に言えば、あるシステムの性能を、ある標準や類似のシステムの性能と比較するプロセスのことである。量子コンピュータの場合、技術的ベンチマークでは、特定のゲート（量子回路の構成要素）と量子ビットのセットについて、忠実度、計算の成功度、統計量、その他のノイズを測定する。

‍

デバイスのベンチマークを行う際、私たちはそのデバイスの長所、短所、改善すべき点、システムの能力を理解します。例えば、CPUとGPUを比較すると、システム操作や一般的なコンピュータの使用ではCPUが勝っていることがわかりますが、ディープラーニングモデルのトレーニングやビットコインのマイニングをGPUで行うと、CPUの方が圧倒的に優れていることがわかります。

量子ベンチマークは何をすべきか？

量子ベンチマークは、システムの能力を詳細に理解させてくれるはずだ：

‍

精度の保証：古典的なビットとは異なり、量子ビット（qubits）は状態の重ね合わせで存在できるため、本質的に確率的である。つまり、同じ量子アルゴリズムを複数回実行しても、結果が異なる可能性がある。ベンチマークは、量子コンピューターが正しい答えを返す頻度をテストすることで、その信頼性を判断するのに役立ちます。
性能指標を測る：量子コンピュータは、古典的なコンピュータでは複雑すぎる問題を解決することが期待されている。ベンチマークを行うことで、量子コンピュータが古典的なスーパーコンピュータと比べてどれだけ速く、あるいはエネルギー効率よく問題を解決できるかを判断することができる。
エラー率の確立：量子システムは外部からの影響を受けやすいため、ゲート操作やコヒーレンスに非常に大きな誤差が生じます。ベンチマークは、システムの信頼性を理解する上で不可欠な統計値であるエラーレートの向上に役立つ。しかし、重要なのは、エラーレートは時間とともにドリフトする可能性があり、量子コンピュータはしばしば再較正されることである。また、量子コンピュータは再較正されることが多い。
量子至上主義を検証する量子至上主義とは、量子コンピューターが古典コンピューターが解決できない問題を解決できることである。

量子ベンチマーキングの種類

技術の初期段階であることを考えると、量子コンピュータの能力を決定することは、古典的なコンピュータの速度を測定するほど単純ではないし、標準化もされていない。量子ベンチマークは様々な種類に分けられ、それぞれが量子デバイスの性能特性を測定する上で特定の目的を果たす。

‍

量子ベンチマークの主な種類をいくつか紹介しよう：

無作為化ベンチマーク

最も一般的なベースライン手法の1つに、ランダム化ベンチマークがある。この方法は、量子プロセッサの量子ゲートの平均エラー率を測定するのに役立つ。ランダムに量子ゲートを適用し、その結果を測定することで、ランダム化ベンチマークは、一般的に状態準備や測定誤差の影響を受けにくいエラー率推定値を作成する。

ゲートセット・トモグラフィ

ゲートセット・トモグラフィは2012年頃に登場し、その後改良が加えられ、ランダム化ベンチマークの問題点を克服するために多くの実験に利用されている。ゲート集合トモグラフィは、量子プロセッサが実行可能な論理演算を、系統誤差を含めて完全に特徴付けることができる。この方法は、ランダム化ベンチマークよりもかなり多くのリソースを必要とするが、量子ゲートセットの詳細なエラーモデルを出力する。

量子プロセス・トモグラフィ

量子プロセストモグラフィは、異なる入力状態を用意し、量子プロセスを適用し、出力状態を測定することで、量子プロセスや量子ゲートの振る舞いを再構成するために使用される。この技法は、少数の量子ビットに対しては非常に正確であるが、多量量子ビットのシステムに対しては、困難で資源集約的になる。

量子状態トモグラフィ

量子状態トモグラフィは、量子プロセストモグラフィと似ているが、プロセスではなく量子状態の特徴付けに焦点を当てている。また、リソースを大量に消費し、量子ビットの数が増えるにつれて難しくなる。

クロストークのベンチマーク

クロストークは、ある量子ビットのゲート操作が他の量子ビットに影響を与えるような大きな量子システムで問題となる。ランダム化されたベンチマークではこの情報を捉えることができないため、クロストーク・ベンチマークではこれらの不要な相互作用を測定する。この測定は、量子ゲートを並列化する必要があるアルゴリズムにとって重要になる。

サイクル・ベンチマーク

サイクルベンチマークは、個々のゲートではなく、量子ゲートのサイクル（またはレイヤー）全体の誤差を測定するように設計された新しい技術であり、量子ビット間のクロストークや、マルチ量子ビット・プロセッサ全体のその他のローカルおよびグローバル誤差から生じる誤差を捕捉する。

クロスエントロピー・ベンチマーキング

クロスエントロピー・ベンチマーク（XEB）は、量子回路の出力分布を理想分布や目標分布と比較することで、量子プロセッサの性能を評価するために用いられる。出力指標は、量子ゲートの精度と量子計算の忠実度を計算し、量子プロセッサーがどれだけ理想的な量子演算に近いかを比較する。グーグルのSycamoreプロセッサーは、XEBを使用して量子的優位性の主張を実証した。

‍

これらのベンチマークにはそれぞれ利点と弱点があり、量子プロセッサの能力の全体像を理解するためには、これらを組み合わせることが多い。量子ハードウェアの種類やシステムの能力が増えるにつれ、新しい量子ベンチマークの方法が提案されるでしょう。

信頼する、しかし検証する：ベンチマーキングへの挑戦

新しい量子チップがリリースされ、そのデバイスのパワーについて並外れた主張があるとしよう。ベンチマークの統計が公表されていなかったり、キャリブレーションの統計が古かったりしても、独自にベンチマークコードを実行することができます。Classiqはワンストップのプラットフォームを提供し、様々なベンダーの実際の量子ハードウェアシステムや、理想化された比較のためのシミュレータでベンチマークテストを実行することができます。

‍

Classiqのプラットフォームを使って、様々な量子ハードウェア上でランダムなベンチマーク実験を行い、シミュレータと比較することが課題です。Classiq Python SDKの使い方はこちらをご覧ください。

‍

与えられたコードはPythonの例で、Classiqライブラリを使用してランダム化ベンチマークを実行し、IBMの "Nairobi "デバイスとIBM Aerの "ideal "量子シミュレータで2量子ビットのクリフォード忠実度を比較します。

‍

コード全文はこちら。

‍

ライブラリのインポート

このブロックは、プログラムに必要な様々なライブラリやモジュールをインポートする。asyncioやitertoolsのようなライブラリは標準的なPythonライブラリで、classiqライブラリは量子コンピューティングの拡張のための関数やクラスを提供する。

‍


from typing import Dict
インポート asyncio
from itertools import product

from classiq import (
    モデル、
    環境設定、
    synthesize_async、
    execute_async、
    set_quantum_program_execution_preferences、
    GeneratedCircuit、
)
from classiq.builtin_functions import RandomizedBenchmarking
from classiq.execution import (
    実行詳細、
    実行環境設定、
    IBMBackendPreferences、
)
from classiq.analyzer.rb import RBAnalysis, order_executor_data_by_hardware

‍

非同期メイン機能

ここでは、どの量子コンピュータバックエンド（IBM Quantumとそのnaairobiマシン）を使用するかを設定する。

‍

モデルオブジェクトのリストが作成され、それぞれが指定されたプリファレンスを持つ。

‍

それぞれのモデルについて、対応するパラメータでランダム化ベンチマークを適用し、結果として得られる量子状態をサンプリングする。

‍


非同期 def main()：
    num_of_qubits = 2
    number_of_cliffords = [5, 10, 15, 20, 25］
    params_list = [ パラメータリスト
        RandomizedBenchmarking(
            num_of_qubits=num_of_qubits、
            num_of_cliffords=num_of_cliffords、
        )
        for num_of_cliffords in numbers_of_cliffords
    ]
    preferences = Preferences(
        backend_service_provider="IBM Quantum"、
        backend_name="nairobi"、
        transpilation_option="decompose"、
    )
    models = [Model(preferences=preferences) for _ in numbers_of_cliffords].
    for model, params in zip(models, params_list)：
        model.RandomizedBenchmarking(params)
        model.sample()

‍

プログラム合成

この非同期呼び出しは、高レベルのモデルを実行可能な量子コードに変換する。IBMのACCESS_TOKENをここに追加してください。

‍


    # 全ての量子プログラムを非同期に合成する
    quantum_programs = await asyncio.gather()*[synthesize_async(model.get_model() for model in models)
        *[synthesize_async(model.get_model()) for model in models](*[synthesize_async(model.get_model()) for model in models])
    )

    # 各バックエンドのプリファレンスで各プログラムを作成する
    backend_names = ("ibm_nairobi", "aer_simulator")
    backend_prefs = IBMBackendPreferences.batch_preferences(
        backend_names=backend_names、
        access_token=ACCESS_TOKEN、
    )
    qprogs_with_preferences = list()
    for qprog, backend_pref in product(quantum_programs, backend_prefs)：
        preferences = ExecutionPreferences(backend_preferences=backend_pref)
        qprogs_with_preferences.append(
            set_quantum_program_execution_preferences(qprog, preferences)
        )

‍

Execution


    # 全ての量子プログラムを非同期に実行する
    results = await asyncio.gather()
        *[execute_async(qprog) for qprog in qprogs_with_preferences] (*[execute_async(qprog) for qprog in qprogs_with_preferences])
    )

‍

結果の解析と分析

残りのコードでは、量子プログラムの結果を解析し、最終的にプロットする。ここにプロットや解析を追加することができる。

‍


    parsed_results = [ExecutionDetails.parse_obj(res[0].value) for res in results]

    parsed_programs = [
        GeneratedCircuit.parse_raw(qprog).to_program() for qprog in quantum_programs
    ]

    clifford_number_mapping: Dict[str, int] = {
        program.code: num_clifford
        for program, num_clifford in zip(parsed_programs, numbers_of_cliffords)
    }
    mixed_data = tuple(
        zip(
            backend_prefs * len(parsed_programs),
            parsed_programs * len(backend_names),
            parsed_results,
        )
    )
    rb_analysis_params = order_executor_data_by_hardware(
        mixed_data=mixed_data, clifford_numbers_per_program=clifford_number_mapping
    )
    multiple_hardware_data = RBAnalysis(experiments_data=rb_analysis_params)

    total_data = await multiple_hardware_data.show_multiple_hardware_data_async()
    fig = multiple_hardware_data.plot_multiple_hardware_results()
    fig.show()

asyncio.run(main())

‍

実験を行った後、以下の質問を評価してください：

このベンチマーク手法によって、どのような指標が得られたのだろうか？
この量子デバイスの振る舞いの全体像を理解するためには、他にどのようなベンチマークを実行すべきでしょうか？
より大きな量子チップや、異なるハードウェアタイプ（例えば超伝導とトラップされたイオン）では、この指標はどのように変わるのでしょうか？

変数backend_namesを選択したハードウェアに置き換えて、仮説を検証する！

‍

量子コンピューティングの主張が非凡になればなるほど、非凡な証拠を提供するためのベンチマークの必要性が高まる。私たちが性能テストを受けていない車を買わないのと同じように、ベンチマークを受けていない量子コンピューターに頼るべきではありません。

‍

そして、企業には、最高の数字を出すベンチマーキング手法を選択するインセンティブがあることを忘れてはならない。信頼は必要ですが、検証も必要です。Classiqを使えば、ベンチマークが可能です！

‍