3. 量子比特与门级原语
量子线路最终会被编译成一串门级原语。理解这些原语的矩阵表示、线路符号以及它们在真实硬件上的实现方式,是判断线路能否正确执行、资源开销是否合理的基础。本节从单量子比特门出发,逐步扩展到受控门与多量子比特门,并给出常见门集在工程实现中的关键约束。
一、单量子比特门:矩阵与线路符号
单量子比特门是作用在一个量子比特上的酉变换,在计算基 {|0⟩, |1⟩} 下写成 2×2 酉矩阵。最基础的是泡利门:
X = [[0,1],[1,0]] Y = [[0,-i],[i,0]] Z = [[1,0],[0,-1]]
H = (1/√2)[[1,1],[1,-1]] S = [[1,0],[0,i]] T = [[1,0],[0,e^{iπ/4}]]
X 门实现比特翻转,Z 门实现相位翻转,H 门把计算基映射到叠加基。S 与 T 是相位门,T 门是通用量子计算中实现非 Clifford 操作的关键资源。线路符号上,X、Y、Z、H、S、T 都画成作用在单根量子线上的方框,方框内写门名;测量则画成带指针的仪表符号,输出为经典比特。
任意单量子比特门都可以分解为绕 Bloch 球三个轴的旋转:Rz(γ)Ry(β)Rz(α),再乘一个全局相位。工程上常把任意单比特门编译成若干固定原语,例如在某些超导平台上,原生单比特门是绕 X 轴和 Z 轴的旋转,任意门需要拆成 2~3 个原生门。判断编译质量时,应关注门数、总时长以及是否引入额外相位。
二、受控门:控制位与目标位
受控门由控制量子比特和目标量子比特组成。以 CNOT 为例,当控制位为 |1⟩ 时对目标位施加 X,否则不变。其 4×4 矩阵在基序 |00⟩,|01⟩,|10⟩,|11⟩ 下为:
CNOT = [[1,0,0,0],
[0,1,0,0],
[0,0,0,1],
[0,0,1,0]]
线路符号是一条竖线连接控制位(实心圆点)与目标位(⊕)。受控 Z、受控 S、受控 T 的符号类似,只是目标位方框内换成对应门名。受控门的关键工程问题是:控制位与目标位在物理拓扑上是否相邻。若不相邻,需要插入 SWAP 链或使用远程 CNOT 方案,这会显著增加门数和错误率。
三、多量子比特门与门集
三量子比特门以 Toffoli(CCX)和 Fredkin(CSWAP)为代表。Toffoli 在 8×8 矩阵中,仅当两个控制位都为 |1⟩ 时翻转目标位。它可分解为若干 CNOT 与单比特门,典型分解需要 6 个 CNOT 加若干 T、H 门。多量子比特门的线路符号是多个控制圆点连到目标位方框。
常见门集分为两类:Clifford 门集 {H, S, CNOT} 可被经典计算机高效模拟,但单独不具通用性;加入 T 门后形成通用门集。工程实现中,不同平台的原生门集不同:超导平台原生单比特门为 Rx、Rz,两比特门为 iSWAP 或 CZ;离子阱平台原生门为任意单比特旋转加 Mølmer-Sørensen 两比特门;光量子平台常用后选择 CNOT。编译器的任务就是把逻辑门集映射到目标平台的原生门集。
四、工程实现中的门集映射与资源判断
把逻辑线路落到硬件,核心是门集映射。假设目标平台原生门集为 {Rx(θ), Rz(θ), CZ},而逻辑线路里出现 H 门和 CNOT。映射过程如下:H 门可写成 Rz(π/2)Rx(π/2)Rz(π/2) 的形式,CNOT 可用 CZ 加目标位前后的 H 门实现。若线路中有 10 个 H 门和 5 个 CNOT,映射后大约得到 30 个单比特旋转和 5 个 CZ,外加 10 个 H 分解产生的额外旋转。这个数量级直接决定线路深度和保真度。
实际判断时,可以按以下顺序检查:第一,统计逻辑门数与两比特门数,两比特门通常是错误率的主要来源;第二,检查每个两比特门的控制位与目标位在耦合图上是否相邻,不相邻则插入 SWAP,SWAP 本身由 3 个 CNOT 构成;第三,检查 T 门数量,T 门在表面码纠错中需要魔法态蒸馏,开销远大于 Clifford 门;第四,核对最终线路的深度是否超过硬件相干时间允许的范围。
五、一个可复用的检查清单
下面给出一个门级原语落地前的检查清单,可直接用于线路评审:
| 检查项 | 判断依据 | 不通过时的处理 |
|---|---|---|
| 单比特门是否已映射到原生旋转 | 目标平台原生门集清单 | 用 Rz-Ry-Rz 或平台指定分解替换 |
| 两比特门控制-目标是否相邻 | 硬件耦合图 | 插入 SWAP 链或改用远程门方案 |
| CNOT 方向是否匹配 | 耦合图方向标注 | 目标位前后各加 H 门反向 |
| T 门数量是否可接受 | 纠错方案与蒸馏开销 | 合并相邻 T 门或改用旋转角度 |
| 线路深度是否在相干时间内 | 映射后深度 × 单门时长 | 重排门序或增加并行度 |
掌握这些原语的矩阵、符号与实现约束后,后续讨论线路优化、错误缓解和编译策略时,就能把抽象线路与真实硬件资源对应起来,而不是停留在符号层面。