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

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

‍

「100万qubitを持つ新しい量子システムを発表しました！」という誇大広告に踊らされたプレスリリースは、その全貌を語ってはいません。誤差が非常に大きく、コヒーレンス（量子状態が保存される時間の長さ）が低い100万qubitは、100個の理想的なqubitほども有用ではありません。誰もが後者を選びたいと思うでしょう。 

‍

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

‍

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

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

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

‍

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

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

量子ベンチマークは、システムの能力の詳細な理解の手助けになる必要があります： 

‍

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

量子ベンチマークの種類

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

‍

量子ベンチマークの主な種類をいくつか挙げます：

ランダム化ベンチマーク

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

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

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

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

量子プロセストモグラフィは、異なる入力状態を用意し、量子プロセスを適用し、出力状態を測定することで、量子プロセスや量子ゲートの振る舞いを再構築するために使用されます。この技法は、少数のqubitに対しては非常に正確であるものの、多数のqubitのシステムに対しては、困難でリソースを大量に消費するようになります。 

量子状態トモグラフィ

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

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

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

サイクルベンチマーク

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

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

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

‍

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

信頼しながら検証する：ベンチマークへの挑戦  

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

‍

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

‍

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

‍

コード全文はこちらをご覧ください。 

‍

ライブラリのインポート  

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

‍

from typing import Dict
import asyncio
from itertools import product

from classiq import (
    Model,
    Preferences,
    synthesize_async,
    execute_async,
    set_quantum_program_execution_preferences,
    GeneratedCircuit,
)
from classiq.builtin_functions import RandomizedBenchmarking
from classiq.execution import (
    ExecutionDetails,
    ExecutionPreferences,
    IBMBackendPreferences,
)
from classiq.analyzer.rb import RBAnalysis, order_executor_data_by_hardware

‍

非同期メイン関数

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

‍

モデルオブジェクトのリストが設定項目とともに作成されます。

‍

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

‍

async def main():
    num_of_qubits = 2
    numbers_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をここに追加してください。 

‍

    # Synthesize all quantum programs asynchronously
    quantum_programs = await asyncio.gather(
        *[synthesize_async(model.get_model()) for model in models]
    )

    # Create each program with each backend preferences
    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)
        )

‍

実行

    # Execute all quantum programs asynchronously
    results = await asyncio.gather(
        *[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を使えば、自分でベンチマークを取ることが可能です！ 

‍