기본 지표
| 지표 | 의미 |
|---|---|
| width | 필요한 큐비트 수 |
| depth | 병렬화를 고려한 시간 단계 수 |
| gate count | 전체 게이트 수 |
| 2Q count | CX/CZ 같은 2큐비트 게이트 수 |
| T-count | fault-tolerant 비용 추정에서 중요한 non-Clifford 비용 |
| shots | 확률분포 추정을 위한 반복 실행 횟수 |
깊이 계산
서로 다른 큐비트에 작용하는 게이트는 같은 layer에 놓을 수 있습니다. 같은 큐비트를 공유하면 순차 실행입니다.
$$
\text{runtime} \approx \sum_{\text{layers}} \max_{g\in layer} t_g
$$하드웨어에서는 게이트 duration이 다르므로 단순 depth보다 scheduled duration이 더 정확할 수 있습니다.
오류 누적 감각
각 게이트 오류율이 작고 독립이라고 아주 거칠게 보면 성공확률은 아래처럼 근사할 수 있습니다.
$$
P_{\mathrm{success}}
\approx
\prod_g (1-p_g)
\approx
e^{-\sum_g p_g}
$$그래서 작은 오류율이라도 게이트 수가 많으면 전체 회로 품질이 빠르게 떨어집니다.
Ancilla tradeoff
ancilla를 쓰면 중간값 저장과 병렬화가 쉬워져 depth를 줄일 수 있습니다. 대신 width가 늘고, ancilla 초기화와 uncompute가 필요합니다.
$$
\text{less depth} \quad\leftrightarrow\quad \text{more qubits}
$$Shots와 통계 오차
확률 p를 shots S번으로 추정하면 표준오차는 대략 아래입니다.
$$
\mathrm{SE}\approx \sqrt{p(1-p)\over S}
$$shots를 4배 늘려야 표준오차가 절반이 됩니다.
보고서에 남길 것
- logical qubits / physical qubits
- depth before/after transpilation
- 2Q gate count
- backend topology
- shots and confidence interval
- noise model or calibration date
logical qubit과 physical qubit
NISQ 문맥에서 말하는 큐비트 수는 보통 physical qubit입니다. 알고리즘 문맥에서 말하는 큐비트 수는 보통 logical qubit입니다. 오류정정이 들어가면 logical qubit 하나를 만들기 위해 많은 physical qubit이 필요합니다.
$$
\text{physical qubits}
\gg
\text{logical qubits}
$$따라서 “알고리즘이 1000 logical qubits를 요구한다”와 “장비에 1000 physical qubits가 있다”는 완전히 다른 말입니다. 회로설계 문서에서는 이 둘을 분리해서 써야 오해가 없습니다.
2큐비트 게이트가 특히 비싼 이유
단일 큐비트 게이트는 비교적 정확하고 빠른 편입니다. 반면 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 전후를 따로 기록하기
회로 리소스는 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 예산과 희귀 이벤트
확률이 큰 결과를 대충 확인할 때는 shots가 적어도 됩니다. 하지만 작은 확률 차이를 비교하거나 tail event를 보려면 shots가 급격히 늘어납니다.
확률 p인 사건을 한 번이라도 볼 확률은 shots S에 대해 아래입니다.
$$
1-(1-p)^S
$$예를 들어 p=0.001인 사건을 95% 확률로 한 번 이상 보려면 대략 S\approx3000 shots가 필요합니다. 따라서 “회로 한 번 실행”과 “통계적으로 의미 있는 실행”은 다릅니다.
오류 예산을 나눠 보기
전체 실패확률을 대충이라도 보려면 게이트 오류, 측정 오류, decoherence, crosstalk을 분리해 생각합니다.
| 오류원 | 회로설계에서 보는 지점 |
|---|---|
| 1Q gate error | 단일 회전 수, calibration 품질 |
| 2Q gate error | CX/CZ 수, routing 후 증가량 |
| readout error | 측정 큐비트 수, readout mitigation 필요성 |
| decoherence | scheduled duration과 idle time |
| crosstalk | 동시에 실행되는 게이트 배치 |
문서에는 완벽한 물리 모델까지 적지 않아도 됩니다. 대신 어떤 오류가 회로 성능을 가장 많이 깎을 가능성이 있는지 숫자와 함께 남겨야 합니다.
NISQ 설계 감각
NISQ에서는 이상적인 거대한 유니터리를 그대로 구현하기보다, 많은 큐비트 기반 연산을 가능한 한 짧은 1Q/2Q 게이트 조합으로 근사합니다. 완벽한 변환보다 “오차가 조금 있어도 장비가 버틸 만큼 짧은 회로”가 더 유리할 때가 많습니다.
비전공자에게 설명하듯 말하면, 고급 수학 연산 하나를 장비가 직접 알아듣는 것이 아닙니다. 장비는 결국 짧은 기본 동작들의 나열을 실행합니다. 너무 긴 나열은 중간에 잡음이 쌓여 결과가 흐려집니다. 그래서 회로설계의 핵심은 “원하는 수학을 얼마나 적은 기본 동작으로 근사할 수 있는가”입니다.