.svg)
量子回路の最適化は重要です。何が難しいのか？
なぜ最適化する必要があるのか？
量子回路を最適化することで、与えられた量子ハードウェアから最大の価値を引き出すことができる。最適化が特定のプロジェクトにとって重要な理由は数多く考えられる。例えば
- 必要な量子リソース（量子ビットの数や2量子ビットのゲート数など）を減らす最適化は、より大きな問題を与えられたコンピュータに適合させるのに役立つ。競合他社がより大きな量子コンピュータを導入するのに1年待たなければならないのに対し、あなたの組織が今日、ある回路を実行できるのであれば、あなたの組織は優位に立ったことになる。
- 量子コンピューターは不完全であるため、より浅い回路を作ることで結果の精度を上げることができる。
- 最適化された回路は、クラウドコンピュータでの実行コストを削減できる可能性がある。実行コストは、例えばマルチ量子ビットのゲート数に依存することがよくあるので、この数を減らすことはコスト削減に役立つ。
最適化が重要だとすれば、量子回路を最適化するにはどうすればいいのか？
ゲートレベルでの最適化
ゲートレベルで行える便利な最適化がいくつかある。これらは、量子アセンブリ言語コードを受け取り、特定のタイプのハードウェアに適したものにするトランスパイラやその他のツールによって実行される。
そのような最適化のひとつが、量子ビットのスワップかもしれない。スワップ最適化では、どの量子ビットが隣り合っているかという、特定のハードウェアのトポロジーを考慮する。例えば、ある量子回路において、量子ビット4と5が関係する演算（例えばCNOT）がいくつかあるが、実際には量子ビット2と5の方が2量子ビット演算に適している場合、最適化によって量子ビット4と2を入れ替えることが決定されるかもしれない。
別のタイプの最適化は、2つの連続するハダマードゲートや2つの連続するXゲートなど、互いに打ち消し合う演算を取り除くことかもしれない。この場合、最適化は次のようになる：
これにはもっと洗練されたバージョンもある。例えば、こんな例がある：
便利ではあるが、ゲートレベルの最適化には限界がある。なぜなら、より高度な最適化を行うには、設計者の意図を理解する必要があったり、本質的に回路を自動的にリバースエンジニアリングする必要があったりするからだ。例えば、トランスパイラーは連続する2つのハダマード・ゲートを打ち消すことはできても、その直後に逆QFTが続くQFTを検出して打ち消すことはできないかもしれない。加算器の代替実装を提案したり、追加の量子ビットがある場合にそれを使用するためのより良い方法を提案したりすることもできません。トランスパイラーは、設計者が回路の深さを最小にしたいとか、可能な最小数の量子ビットを使いたいとか考えていることを知らないかもしれません。
何をすべきか？機能レベルの最適化を見てみよう。
機能モデルレベルでの最適化
機能レベルの最適化では、設計を相互に接続された機能の集合として捉えるため、回路を「リバース・エンジニアリング」する必要はない。そして、設計者が最適化の目標として定義したものに基づいて回路を生成する。機能モデル・オプティマイザは、ゲートレベル・オプティマイザにはできない多くのことを行うことができる。以下にいくつかの例を挙げる：
機能ブロックの代替実装を探る
量子加算器や状態準備ブロックのような機能ブロックについて考えるとき、そのようなブロックにはいくつかの実装方法が考えられる。例えば、加算器はQFT加算器として実装されるかもしれないし、リップル加算器として実装されるかもしれない。機能モデルのオプティマイザは、システム全体の制約に従って最適なものを選択できます。システム全体の制約に関するこの点は重要である。どの単一ブロックにも最適な実装があるかもしれませんが、あるブロックを一見効率の悪い方法で実装しても、その方法がシステムの他の部分に利益をもたらすのであれば、その方が得になることがあります。例えば、より少ない量子ビットを使用することで、並列実行可能な別のブロックのためにリソースを解放できるかもしれません。
補助量子ビットを増やすか減らすか
MCX（マルチ制御トフォリ）ゲートを想像してほしい。多かれ少なかれ補助量子ビットが与えられた場合、それを実装する方法はたくさんあります。例として、この議論を参照してください。機能レベルのオプティマイザは、システムリソースの最適な割り当てに基づいて、正しい実装を選択することができます。
余談だが、Classiq Coding Competitionでは、MCXゲートのさまざまな実装方法が紹介された。
必要なときに量子ビットを再利用する。
機能モデル・オプティマイザは、各機能ブロックの入力と出力を理解し、出力を担う出力量子ビットと、計算されずに再利用可能な補助量子ビットを区別します。例えば、関数Fが2つの有用な出力と1つの補助量子ビットを持つ場合、その補助量子ビットは再利用することができます。下のバージョン "A "では、関数Fの3つのインスタンスに対して合計9つの量子ビットを使いますが、8つしか使えない場合（バージョン "B"）、2つ目のインスタンスの補助量子ビットを再利用します。バージョン "C "では、さらに少ない量子ビットが使用されるため、補助量子ビットがカスケード的に使用されます。ゲートレベルモデルを使用する場合、これを検出し実装することは非常に困難です。
可換演算の順序の変更
以下のバージョン "A "は4つのハミルトニアン項を示している。バージョン "B "は、これらの項を整流することによって最適化したものである。これがハミルトニアンであることを理解すれば、関数モデルでこのような最適化を行うことができる。ところで、ハミルトニアンの指数化問題を最適化する例は他にもたくさんあります。
概要
これらは多くの可能性のある例のほんの一部です。その他にも、ターゲット・プラットフォームのノイズ・モデルや、希望する精度、その他多くのバリエーションに基づいて回路を変更することも含まれるかもしれない。
これらやその他多くのことを踏まえて、私は次のように言うのが妥当だと思う。
より高い抽象度（例えば機能レベル）で最適化する方が、より低いレベルで最適化するよりも数学的に優れていることは自明である。
要するに、最適化が重要なのだ。質の高い最適化をゲートレベルで行うのは非常に難しいが、機能レベルで作業し、適切なプラットフォームを使用すれば、もはや難しいことではない。
Classiqプラットフォームがどのように最適化されたハードウェアを考慮した回路を簡単に作成できるかをご覧いただくには、デモをご予約ください。
なぜ最適化する必要があるのか？
量子回路を最適化することで、与えられた量子ハードウェアから最大の価値を引き出すことができる。最適化が特定のプロジェクトにとって重要な理由は数多く考えられる。例えば
- 必要な量子リソース（量子ビットの数や2量子ビットのゲート数など）を減らす最適化は、より大きな問題を与えられたコンピュータに適合させるのに役立つ。競合他社がより大きな量子コンピュータを導入するのに1年待たなければならないのに対し、あなたの組織が今日、ある回路を実行できるのであれば、あなたの組織は優位に立ったことになる。
- 量子コンピューターは不完全であるため、より浅い回路を作ることで結果の精度を上げることができる。
- 最適化された回路は、クラウドコンピュータでの実行コストを削減できる可能性がある。実行コストは、例えばマルチ量子ビットのゲート数に依存することがよくあるので、この数を減らすことはコスト削減に役立つ。
最適化が重要だとすれば、量子回路を最適化するにはどうすればいいのか？
ゲートレベルでの最適化
ゲートレベルで行える便利な最適化がいくつかある。これらは、量子アセンブリ言語コードを受け取り、特定のタイプのハードウェアに適したものにするトランスパイラやその他のツールによって実行される。
そのような最適化のひとつが、量子ビットのスワップかもしれない。スワップ最適化では、どの量子ビットが隣り合っているかという、特定のハードウェアのトポロジーを考慮する。例えば、ある量子回路において、量子ビット4と5が関係する演算（例えばCNOT）がいくつかあるが、実際には量子ビット2と5の方が2量子ビット演算に適している場合、最適化によって量子ビット4と2を入れ替えることが決定されるかもしれない。
別のタイプの最適化は、2つの連続するハダマードゲートや2つの連続するXゲートなど、互いに打ち消し合う演算を取り除くことかもしれない。この場合、最適化は次のようになる：
これにはもっと洗練されたバージョンもある。例えば、こんな例がある：
便利ではあるが、ゲートレベルの最適化には限界がある。なぜなら、より高度な最適化を行うには、設計者の意図を理解する必要があったり、本質的に回路を自動的にリバースエンジニアリングする必要があったりするからだ。例えば、トランスパイラーは連続する2つのハダマード・ゲートを打ち消すことはできても、その直後に逆QFTが続くQFTを検出して打ち消すことはできないかもしれない。加算器の代替実装を提案したり、追加の量子ビットがある場合にそれを使用するためのより良い方法を提案したりすることもできません。トランスパイラーは、設計者が回路の深さを最小にしたいとか、可能な最小数の量子ビットを使いたいとか考えていることを知らないかもしれません。
何をすべきか？機能レベルの最適化を見てみよう。
機能モデルレベルでの最適化
機能レベルの最適化では、設計を相互に接続された機能の集合として捉えるため、回路を「リバース・エンジニアリング」する必要はない。そして、設計者が最適化の目標として定義したものに基づいて回路を生成する。機能モデル・オプティマイザは、ゲートレベル・オプティマイザにはできない多くのことを行うことができる。以下にいくつかの例を挙げる：
機能ブロックの代替実装を探る
量子加算器や状態準備ブロックのような機能ブロックについて考えるとき、そのようなブロックにはいくつかの実装方法が考えられる。例えば、加算器はQFT加算器として実装されるかもしれないし、リップル加算器として実装されるかもしれない。機能モデルのオプティマイザは、システム全体の制約に従って最適なものを選択できます。システム全体の制約に関するこの点は重要である。どの単一ブロックにも最適な実装があるかもしれませんが、あるブロックを一見効率の悪い方法で実装しても、その方法がシステムの他の部分に利益をもたらすのであれば、その方が得になることがあります。例えば、より少ない量子ビットを使用することで、並列実行可能な別のブロックのためにリソースを解放できるかもしれません。
補助量子ビットを増やすか減らすか
MCX（マルチ制御トフォリ）ゲートを想像してほしい。多かれ少なかれ補助量子ビットが与えられた場合、それを実装する方法はたくさんあります。例として、この議論を参照してください。機能レベルのオプティマイザは、システムリソースの最適な割り当てに基づいて、正しい実装を選択することができます。
余談だが、Classiq Coding Competitionでは、MCXゲートのさまざまな実装方法が紹介された。
必要なときに量子ビットを再利用する。
機能モデル・オプティマイザは、各機能ブロックの入力と出力を理解し、出力を担う出力量子ビットと、計算されずに再利用可能な補助量子ビットを区別します。例えば、関数Fが2つの有用な出力と1つの補助量子ビットを持つ場合、その補助量子ビットは再利用することができます。下のバージョン "A "では、関数Fの3つのインスタンスに対して合計9つの量子ビットを使いますが、8つしか使えない場合（バージョン "B"）、2つ目のインスタンスの補助量子ビットを再利用します。バージョン "C "では、さらに少ない量子ビットが使用されるため、補助量子ビットがカスケード的に使用されます。ゲートレベルモデルを使用する場合、これを検出し実装することは非常に困難です。
可換演算の順序の変更
以下のバージョン "A "は4つのハミルトニアン項を示している。バージョン "B "は、これらの項を整流することによって最適化したものである。これがハミルトニアンであることを理解すれば、関数モデルでこのような最適化を行うことができる。ところで、ハミルトニアンの指数化問題を最適化する例は他にもたくさんあります。
概要
これらは多くの可能性のある例のほんの一部です。その他にも、ターゲット・プラットフォームのノイズ・モデルや、希望する精度、その他多くのバリエーションに基づいて回路を変更することも含まれるかもしれない。
これらやその他多くのことを踏まえて、私は次のように言うのが妥当だと思う。
より高い抽象度（例えば機能レベル）で最適化する方が、より低いレベルで最適化するよりも数学的に優れていることは自明である。
要するに、最適化が重要なのだ。質の高い最適化をゲートレベルで行うのは非常に難しいが、機能レベルで作業し、適切なプラットフォームを使用すれば、もはや難しいことではない。
Classiqプラットフォームがどのように最適化されたハードウェアを考慮した回路を簡単に作成できるかをご覧いただくには、デモをご予約ください。
