리소스 추정

회로가 수학적으로 맞는 것과 실행 가능한 것은 다릅니다. 리소스 추정은 큐비트 수, 깊이, 2큐비트 게이트, T-count, shots를 숫자로 보는 작업입니다.

## 기본 지표 {#metrics}

| 지표 | 의미 |
| --- | --- |
| width | 필요한 큐비트 수 |
| depth | 병렬화를 고려한 시간 단계 수 |
| gate count | 전체 게이트 수 |
| 2Q count | CX/CZ 같은 2큐비트 게이트 수 |
| T-count | fault-tolerant 비용 추정에서 중요한 non-Clifford 비용 |
| shots | 확률분포 추정을 위한 반복 실행 횟수 |

## 깊이 계산 {#depth}

서로 다른 큐비트에 작용하는 게이트는 같은 layer에 놓을 수 있습니다. 같은 큐비트를 공유하면 순차 실행입니다.

$$
\text{runtime} \approx \sum_{\text{layers}} \max_{g\in layer} t_g
$$

하드웨어에서는 게이트 duration이 다르므로 단순 depth보다 scheduled duration이 더 정확할 수 있습니다.

## 오류 누적 감각 {#error}

각 게이트 오류율이 작고 독립이라고 아주 거칠게 보면 성공확률은 아래처럼 근사할 수 있습니다.

$$
P_{\mathrm{success}}
\approx
\prod_g (1-p_g)
\approx
e^{-\sum_g p_g}
$$

그래서 작은 오류율이라도 게이트 수가 많으면 전체 회로 품질이 빠르게 떨어집니다.

## Ancilla tradeoff {#ancilla}

ancilla를 쓰면 중간값 저장과 병렬화가 쉬워져 depth를 줄일 수 있습니다. 대신 width가 늘고, ancilla 초기화와 uncompute가 필요합니다.

$$
\text{less depth} \quad\leftrightarrow\quad \text{more qubits}
$$

## Shots와 통계 오차 {#shots}

확률 $p$를 shots $S$번으로 추정하면 표준오차는 대략 아래입니다.

$$
\mathrm{SE}\approx \sqrt{p(1-p)\over S}
$$

shots를 4배 늘려야 표준오차가 절반이 됩니다.

## 보고서에 남길 것 {#checklist}

1. logical qubits / physical qubits
2. depth before/after transpilation
3. 2Q gate count
4. backend topology
5. shots and confidence interval
6. noise model or calibration date

## logical qubit과 physical qubit {#logical-physical}

NISQ 문맥에서 말하는 큐비트 수는 보통 physical qubit입니다. 알고리즘 문맥에서 말하는 큐비트 수는 보통 logical qubit입니다. 오류정정이 들어가면 logical qubit 하나를 만들기 위해 많은 physical qubit이 필요합니다.

$$
\text{physical qubits}
\gg
\text{logical qubits}
$$

따라서 “알고리즘이 1000 logical qubits를 요구한다”와 “장비에 1000 physical qubits가 있다”는 완전히 다른 말입니다. 회로설계 문서에서는 이 둘을 분리해서 써야 오해가 없습니다.

## 2큐비트 게이트가 특히 비싼 이유 {#two-qubit-cost}

단일 큐비트 게이트는 비교적 정확하고 빠른 편입니다. 반면 CX, CZ 같은 2큐비트 게이트는 보통 오류율이 더 높고, 하드웨어 연결성 제약도 받습니다. 회로가 수학적으로는 인접하지 않은 큐비트 사이의 CX를 요구해도, 실제 장비에서는 SWAP을 넣어 두 큐비트를 가깝게 만들어야 할 수 있습니다.

$$
\mathrm{CX}(q_0,q_7)
\quad\Rightarrow\quad
\text{routing SWAPs}+\mathrm{CX}+\text{routing SWAPs}
$$

그래서 transpilation 후 2Q count가 원래 회로보다 크게 늘어날 수 있습니다. 알고리즘 수준에서 “CX 100개”였던 회로가 특정 backend에서는 routing 때문에 “CX 300개”가 되는 식입니다.

## transpilation 전후를 따로 기록하기 {#transpilation}

회로 리소스는 ideal circuit과 transpiled circuit을 나눠 봐야 합니다.

| 단계 | 의미 |
| --- | --- |
| logical circuit | 알고리즘 설명에 가까운 추상 회로 |
| basis translated | 장비 native gate set으로 바꾼 회로 |
| routed | 장비 coupling map에 맞게 SWAP이 들어간 회로 |
| scheduled | 게이트 시간과 병렬성을 고려해 배치한 회로 |

특히 NISQ 실험 결과를 적을 때는 transpilation seed나 optimization level에 따라 결과가 달라질 수 있습니다. 실험 재현성을 위해 backend 이름, calibration 날짜, transpiler 설정을 같이 남기는 것이 좋습니다.

## shots 예산과 희귀 이벤트 {#shot-budget}

확률이 큰 결과를 대충 확인할 때는 shots가 적어도 됩니다. 하지만 작은 확률 차이를 비교하거나 tail event를 보려면 shots가 급격히 늘어납니다.

확률 $p$인 사건을 한 번이라도 볼 확률은 shots $S$에 대해 아래입니다.

$$
1-(1-p)^S
$$

예를 들어 $p=0.001$인 사건을 95% 확률로 한 번 이상 보려면 대략 $S\approx3000$ shots가 필요합니다. 따라서 “회로 한 번 실행”과 “통계적으로 의미 있는 실행”은 다릅니다.

## 오류 예산을 나눠 보기 {#error-budget}

전체 실패확률을 대충이라도 보려면 게이트 오류, 측정 오류, decoherence, crosstalk을 분리해 생각합니다.

| 오류원 | 회로설계에서 보는 지점 |
| --- | --- |
| 1Q gate error | 단일 회전 수, calibration 품질 |
| 2Q gate error | CX/CZ 수, routing 후 증가량 |
| readout error | 측정 큐비트 수, readout mitigation 필요성 |
| decoherence | scheduled duration과 idle time |
| crosstalk | 동시에 실행되는 게이트 배치 |

문서에는 완벽한 물리 모델까지 적지 않아도 됩니다. 대신 어떤 오류가 회로 성능을 가장 많이 깎을 가능성이 있는지 숫자와 함께 남겨야 합니다.

## NISQ 설계 감각 {#nisq-design-rule}

NISQ에서는 이상적인 거대한 유니터리를 그대로 구현하기보다, 많은 큐비트 기반 연산을 가능한 한 짧은 1Q/2Q 게이트 조합으로 근사합니다. 완벽한 변환보다 “오차가 조금 있어도 장비가 버틸 만큼 짧은 회로”가 더 유리할 때가 많습니다.

비전공자에게 설명하듯 말하면, 고급 수학 연산 하나를 장비가 직접 알아듣는 것이 아닙니다. 장비는 결국 짧은 기본 동작들의 나열을 실행합니다. 너무 긴 나열은 중간에 잡음이 쌓여 결과가 흐려집니다. 그래서 회로설계의 핵심은 “원하는 수학을 얼마나 적은 기본 동작으로 근사할 수 있는가”입니다.