おさらい
前回の記事では、量子エンジニアが少ない理由として
「技術成熟度の差・参入難易度の差・実行環境の差」という3つの要因で整理し、それら3要因が量子コンピュータをクラウドシステムに統合するにあたっての4つの壁につながることを書きました。
| 格差を生む3要因 | 量子×クラウドの4つの壁 |
|---|---|
| 技術成熟度の差 | ①ハイブリッド構成の複雑性 |
| 参入難易度の差 | ②プログラミングモデル / APIの分断 |
| 実行環境の差 | ③量子時代のセキュリティ問題 ④QPUスケジューリング |
そして、「技術成熟度の差」がある理由として、量子コンピュータのハードウェアそのものやソフトウェアに対して、以下のような課題や問題があることを挙げました。
- 量子コンピュータ上の計算は、ノイズの影響を受ける
- 現在の量子コンピュータは誤りを完全に訂正できない世代
- 実機精度が安定しない
- SDK の標準化が未完了
- ベンダーごとにAPIが異なる
- 開発ワークフローが確立していない
今回の記事では、上記4つの壁のうち、1つめの壁、 ハイブリッドアーキテクチャの複雑性 について、主にハードウェア(上記太字の項目)に着目して、課題を整理します。
(上記の太字でない項目については、2つめの壁「②プログラミングモデル / APIの分断」にも関連するため、次回説明します。)
ここで言う「ハイブリッド」とは、「量子コンピュータと古典コンピュータ同士がやりとりして計算結果を出す」ような構成のことです。説明の都合で一部例外もございますが、本記事では、量子コンピュータを指す単語を「QPU」、それに対をなす古典コンピュータを指す単語を「CPU」とします。
量子コンピュータは古典コンピュータと連携して計算する
量子コンピュータというと「量子コンピュータだけで、古典コンピュータよりもすごい速さで計算してくれる」と思われがちですが、実際には、量子コンピュータと古典コンピュータが連携して処理をする「ハイブリッド型」での使用が基本とされています。
イメージとしては、
- 古典コンピュータ（CPU）＝
トラック
→ どんな荷物でも、ゆっくりだけど確実に運べる - 量子コンピュータ（QPU）＝
めちゃくちゃ速いが扱いが難しいレーシングカー
→ 条件が合えば爆速だが、走れるコースや環境が限られる
という感じで、
「トラック（CPU）がメインで荷物を運びながら、特定の区間だけレーシングカー（QPU）にバトンタッチする」ような構成になっています。
「ハイブリッド型」の計算の流れだけをざっくり見てみると、以下のような流れになり、古典コンピュータが「計算の指示を出す司令塔」で、量子コンピュータが「計算担当」という構造で、この間を「行ったり来たり」で往復する特徴があります。
- CPUが「計算の仕様・設定」をつくる
- 計算の仕様・設定を元に、QPU向けの“命令”をつくる
- その命令（回路）をQPUに送る
- QPU が計算して、その結果（測定値）CPUへ返す
- CPUが計算結果を参照し、次の計算の入力を作成する
- また QPU に命令を送る
- これを何百回・何千回と繰り返す
QPUをクラウドシステムに統合しようとすると何が難しい？
ここからが本題です。
この「行ったり来たり」をクラウド上でやろうとすると何が難しくなるのかを見ていきます。
ポイントは次の2つです。
ポイント1. QPUにはノイズが多くて、同じ計算を何度もやり直す必要がある
ポイント2. 計算を最適化するために、QPUとCPUとの役割分担を決める必要がある
ポイント1. QPUにはノイズが多くて、同じ計算を何度もやり直す必要がある
現在のQPUには、まだノイズ（誤り）が多く存在します。
そのため、
- 一度計算しただけでは信頼できない
- 同じ計算を何百〜何千回も繰り返して、統計的に結果を読む
- 条件によっては、何度も再実行が必要
といったことがよく起こります。
これをクラウドシステムで動いているアプリから見ると、
アプリ側から QPU に「同じリクエストを何度も投げ直す」必要がある
ということになります。
やりとりする分だけネットワーク越しのやりとりが増え、遅くなりますし、結果が出てくるまでアプリ側の計算リソースは稼働を続けなければなりません。こうなってくると、従量課金制のサービスが主流のクラウドサービスにおいて、コストの問題が出てきます。
クラウドサービスには、リソースの使用時間帯を予約することで料金の割引を受けるプランがあります。
コスト削減のために、ジョブ実行結果をタイムリーにアプリが受け取れるよう、CPU側のリソースの使用時間帯を絞ったり、リソースを間欠的にON/OFFするといったことをしたいところですが、現在の量子コンピュータが共有リソースである以上、計算がいつ終わるのかを予測することは、QPUに溜まっているジョブの数、他人が投げたそれぞれのジョブの終了にかかる時間を考慮しなければならず、一筋縄ではいかないところがあります。
加えて、どのような順序や優先度でジョブが実行されるのかは、QPUをクラウドとして提供するベンダが仕様を握っているほか、他人の投げたジョブの内容は、QPU利用者からみれば、ブラックボックスであるため、ジョブの終了時間の予測を難しくします。
ポイント2. QPUとCPUとの役割分担を決める必要がある
成熟した技術だと、どこをCPUで処理し、何のハードウェア（GPU、TPUなど用途に特化したハードウェア）に任せるかといったパターンが明確になります。
例えば、クラウドシステムの設計パターンとして、「マイクロサービスアーキテクチャ」というものがあります。
これは、1つの大きなアプリケーションを特定の役割で分割し、複数の小さなサービスとして独立させる設計パターンです。この設計をクラウドに実装する手段の例として、「コンテナ」や「WebAPI」があります。「コンテナ」や「WebAPI」には、システム上の運用も含めて、ベストプラクティスや設計原則があり、ベストプラクティスや設計原則を参考にして、分割するサービスの粒度や、揃えるべきAPIやAPIの役割を決めることができます。
一方、量子技術におけるQPUは、計算過程のうち特定の部分だけを担当するという構造になっています。例を挙げれば、
- CPU側：パラメータ調整、データ前処理、最適化、結果の解析 など
- QPU側：計算過程のうち特定の「難しい部分」だけを担当
という役割分担になっていることが多いです。
クラウド視点で見ると、アプリのほとんどはCPU上で動いていて、必要に応じてQPUに処理を投げると言えます。
このため、
- CPU側の計算も速くないと、システム全体としてあまり速くならない
- CPUとQPUとのやりとりの効率が悪いと、逆に遅くなる
というように、計算過程においてCPUとQPUとの間にボトルネックが発生します。
QPUをクラウドシステム上で扱う場合は、
- 計算においてどの部分をQPUが担当すべきか
- 計算をQPUに任せると本当に速くなるのか(量子優位性の判断)
- QPU向き／CPU向きのタスク境界を明確にする
といったことを考慮したうえで、ボトルネックになりずらくなるようにクラウドシステムのアーキテクチャを設計する必要があります。
これに加えて、QPUには、量子ゲート型、量子アニーリング型といった具合に、ハードウェアにスタイルがあるため、「どのような計算」をさせるかによって、最適な量子コンピュータのスタイルを選ばなければなりません。
さらに、QPU上の量子ビットの精度やノイズ発生率による誤り率に違いがある、量子ビットの結合関係が違う、といったことも計算過程のボトルネックとなりうるため、クラウドシステムのアーキテクチャを設計する点での複雑性が増します。
まとめ
量子×クラウドの“第1の壁”である 「ハイブリッドアーキテクチャの複雑性」 では、
「技術が未成熟だから起きる」ことを起点として、量子コンピュータをクラウドへ統合するにあたっては、以下のような課題が潜んでいると整理できます。
- QPUでは、ノイズが多く、同じ計算を何度もやり直す必要がある
- 現在(記事執筆時点)のQPUは、CPUとの間で「行ったり来たり」を繰り返すので、ネットワーク遅延、CPU側の計算結果待ちによるコストが増える可能性がある
- QPUは共有資源のため、QPUへ自分が投げたタスクがいつ処理され、いつ終わるかの予測が困難
- QPUとCPUの役割分担を明確にする必要があるが、最適な分担手段が未確立
- その結果、QPUを統合したクラウドシステムのアーキテクチャの複雑性が高まる
クラウドのように洗練されている実行モデルやベストプラクティス、システムの設計パターンが確立されていれば、こういった複雑性に対抗できるところではあります。
しかし、量子技術は「黎明期〜実験期」にあり、確固たるベストプラクティスが見えていないこともあり、技術が未成熟であるがゆえ、現在(記事執筆時点)の量子コンピュータをクラウド上で扱う際は、これらの複雑性があることを知ったうえで扱っていく必要があります。
次回予告
次回は、量子×クラウドの“第2の壁”である プログラミングモデル / API分断の壁 について、説明いたします。
- 参考