量子连接性如何决定你的量子计算机实际上能够执行哪些计算任务
假设你的量子程序需要对编号为 0 和 50 的两个量子比特执行某种操作。 从编程者的角度来看，这似乎是一件很简单的事情。 你有两个量子比特，也有一个可以同时作用于这两个量子比特的门电路。那么，为什么量子计算机不能直接执行这个操作呢？ 因为在真实的量子处理器中，各个量子比特并不一定彼此相连。 量子处理器并不是由一系列可以随意互换的量子比特组成的系统，在这种系统中，每个量子比特都能立即与其他所有量子比特发生相互作用。这些量子比特的实际排列方式非常重要，连接装置、控制电路、门电路的种类、错误率以及它们之间的通信路径也同样重要。 这些因素就导致了你编写的量子程序与实际执行该程序的量子计算机之间存在本质
假设你的量子程序需要对编号为0和50的两个量子比特执行某种操作。
从编程者的角度来看，这似乎是一件很简单的事情。
你有两个量子比特，也有一个可以同时作用于这两个量子比特的门电路。那么，为什么量子计算机不能直接执行这个操作呢？
因为在真实的量子处理器中，各个量子比特并不一定彼此相连。
量子处理器并不是由一系列可以随意互换的量子比特组成的系统，在这种系统中，每个量子比特都能立即与其他所有量子比特发生相互作用。这些量子比特的实际排列方式非常重要，连接装置、控制电路、门电路的种类、错误率以及它们之间的通信路径也同样重要。
这些因素就导致了你编写的量子程序与实际执行该程序的量子计算机之间存在本质上的区别。
本文适用于那些已经掌握了量子电路基础知识，但想要了解这些电路在遇到真实的量子硬件时会发生什么变化的开发者、学生和量子计算爱好者。通过阅读本文，你将了解到量子比特之间的连接方式如何影响电路的执行过程，为什么编译器有时会插入SWAP门电路，路由机制是如何增加电路的复杂度并导致错误的出现的，以及像IBM的Heron、Nighthawk和ZuriQ的可重构离子阱系统这类架构又是如何解决连接问题的。
目录
从逻辑量子比特到物理量子比特
你的电路可能描述了如下所示的逻辑量子比特之间的相互作用：
q0 ─────●────
│
q1 ─────┼────
│
q2─────-┼────
│
q3────-─x────
但是，物理量子处理器通常只允许相邻的量子比特直接进行相互作用。
如果你的算法中需要的两个量子比特在物理上并没有连接在一起，编译器就必须另寻方法来实现它们之间的相互作用。
这通常意味着需要将逻辑量子比特映射到物理量子比特上，调整操作顺序以符合硬件的连接结构，有时还需要添加额外的SWAP门来传递量子信息。IBM Quantum在其转译器阶段指南中详细解释了这些步骤。
这些额外的操作并非你最初编写的算法的一部分，它们是由于量子计算机的物理架构所导致的额外开销。
正因为如此，量子连接性不仅仅是一个硬件规格参数；它实际上会影响到以下几个方面：
量子电路的编译方式
最终电路中包含多少个逻辑门
电路的复杂程度
计算过程中会产生多少噪声
哪些算法是可行的
以及硬件最终能够执行哪些有用的计算任务
IBM Quantum最近的硬件发展路线图为这一问题提供了一个很好的例证。IBM的Heron处理器采用六边形拓扑结构，而其新型Nighthawk处理器则采用了方形晶格结构，在这种结构中每个量子比特最多可以与四个相邻量子比特进行连接。IBM明确指出，这种更高的连接性有助于减少路由开销，并支持更复杂的电路设计。
另一种解决这个问题的方法是利用ZuriQ的技术。他们正在开发一种基于囚禁离子的架构，在这种架构中，通过动态改变施加在电极上的电压，可以重新排列和移动离子。该公司的技术允许根据需要将离子在芯片上移动。
这就引出了一个有趣的问题：当一个量子程序所需的量子比特在物理上并没有连接在一起时，这个程序会如何运行呢？
要回答这个问题，我们首先需要了解“连接性”到底意味着什么。
量子连接性究竟意味着什么？
在量子计算机中，连接性指的是哪些物理量子比特对能够直接参与两量子比特之间的操作。
你可以把处理器想象成一个图结构：每个量子比特都对应一个节点，而所有允许发生的两量子比特相互作用则对应一条边。
例如，假设我们有五个物理量子比特：
q0 ─── q1 ─── q2
│
q3 ─── q4这张图告诉我们，这些量子比特是直接相连的：
q0 → q1
q1 → q2
q0 → q3
q3 → q4
尽管q0和q4并没有直接相连，但这并不意味着它们永远无法相互作用。实际上，这意味着编译器并不一定能直接实现它们之间的两量子比特操作。
我们需要一种策略，将量子信息调整到某种状态，使得所需的操作在物理层面上成为可能。
IBM的Qiskit文档将这种硬件描述称为耦合映射。耦合映射说明了哪些物理量子比特能够支持两量子比特门操作；而量子电路则是由逻辑量子比特构成的，这些逻辑量子比特需要被映射到相应的物理量子比特上。
在学习量子编程时，很容易忽略这一区别。
你可能会写出这样的代码：
qc.cx(0, 4)并认为自己只是对0和4这两个量子比特应用了CNOT门操作。
在抽象的电路层面来看，这种理解是正确的；但在硬件层面上，实际的处理器可能会告诉你：
量子比特0和物理量子比特4无法直接执行这个操作。
这时，编译器就面临一个需要解决的问题。
一个现实世界的类比：道路与城市
想象一下道路网络。
如果你想从A城开车前往D城，
如果它们之间有直接的公路连接，那么这段旅程就会非常简单。
A ───────── D但假如道路网络的连接方式是这样的：
A ─ B ─ C ─ D你仍然可以到达D城，只是需要经过B城和C城而已。
量子路由的原理也是类似的。
不同之处在于，传输量子信息所需的成本要高得多。
经典计算机可以将信息复制到内存中，在不同的位置之间进行传输，而且能够承受大量的通信开销；
但量子信息则要脆弱得多。
量子处理器在执行任何操作时，都必须保持量子状态的完整性。
这就是SWAP门发挥作用的地方了。
当两个量子比特没有直接连接时会发生什么？
假设你的算法需要在逻辑量子比特q0和q3之间执行两量子比特门操作。
但你的硬件配置却是这样的：
q0 ─── q1 ─── q2 ─── q3这些量子比特是按线性顺序排列的，q0和q3之间并没有直接的连接。
你不能直接要求硬件执行这样的操作：
qc.cx(0, 3)人们原本期望这些物理设备能够直接实现交互。
但实际上，编译器可以负责调整量子态的位置。
举个例子：
初始状态：
q0 ─── q1 ─── q2 ─── q3
A B C D
假设我们希望让 A 与 D 发生交互。
编译器可能会执行一系列交换操作：
q0 ─── q1 ─── q2 ─── q3
A B C D
交换操作
↓
q0 ─── q1 ─── q2 ─── q3
B A C D
交换操作
↓
q0 ─── q1 ─── q2 ─── q3
B C A D
现在 A 和 D 已经相邻了。
这样就可以执行所需的两个量子比特操作了。
问题在于，这些交换操作本身也是量子门。它们需要消耗时间，还可能引入错误，同时也会增加电路的复杂度。
IBM 的 Qiskit 文档中明确提到了这种路由方式：
当电路中需要的两个量子比特在目标设备上并没有直接连接时，转译器可以通过插入
交换操作来调整量子态的位置，直到这两个量子比特变得相邻。
为什么交换操作会消耗大量资源？
交换操作会将两个量子比特的量子态互换。
从数学上来说，我们可以这样表示：
|a⟩|b⟩ → |b⟩|a⟩
但是许多量子处理器并不会将交换操作作为单一的原生功能来实现。
实际上，它可以通过三个 CNOT 操作来分解：
SWAP(a, b) = CX(a, b)
CX(b, a)
CX(a, b)
在 Qiskit 中，我们可以演示这种分解过程：
from qiskit import QuantumCircuit
qc = QuantumCircuit(2)
qc.swap(0, 1)
print(qc)
这段代码创建了一个两个量子比特的电路，并应用了交换操作来改变量子比特 0 和 1 的量子态。尽管在 Qiskit 中这被表示为一次 swap(0, 1) 操作。
从概念上来说，这个过程可以理解为：
q0: ──X──●──X──
│
q1: ──●──X──●──
从这个图可以看出，交换操作实际上需要通过三个 CNOT 操作来完成，这意味着在量子比特之间传递信息可能需要多个物理门。
关键在于，让量子比特通过量子处理器进行处理会增加额外的操作步骤，从而增加电路的复杂度，并提高出错的风险。
IBM 的文档指出，插入的交换操作会带来较大的误差，因为这些操作本身既耗时又容易产生干扰。
电路复杂度：连接性不佳所带来的隐性成本
门的数量只是问题的一部分，另一个重要的指标是电路复杂度。
电路的深度大致指的是必须依次执行的操作层数。
来看这两个电路：
电路A：
q0 ──H────●────────
│
q1 ───────X────────
以及：
电路B：
q0 ──H──SWAP──SWAP──●────
│
q1 ─────────────────X────
电路B包含额外的操作步骤。
更重要的是，其中一些操作必须在期望的结果产生之前完成。
这就意味着量子状态需要维持更长的时间才能完成这些操作。
这一点很重要，因为物理量子比特存在噪声干扰。
计算过程越长、层次越深，出现错误的可能性就越大。
IBM最近的研究说明了连接性、路由机制、电路深度与实际计算效果之间的关系。2026年5月，IBM报告称，在使用基于奇偶性的电路结构、避免显式使用SWAP操作的情况下，他们在Heron处理器上成功实现了对52个量子比特的傅里叶变换运算。IBM指出，路由开销、电路深度以及累积的噪声是扩展这类量子计算电路所面临的主要挑战。
这个例子说明了一个重要的道理：
如果硬件无法轻松地执行你的算法，那么你有两个选择：要么调整量子比特的排列方式以适应算法需求，要么重新设计算法使其适合当前的硬件结构。
当重新设计算法能够显著减少路由开销时，这种做法往往会更加高效。
IBM Heron：优化一种强大但结构化的拓扑架构
IBM的Heron系列是一个很好的研究起点，因为它们代表了IBM在超导量子硬件开发领域取得的重大进展。
根据IBM目前的文档，Heron处理器配备了133个或156个可编程量子比特以及可调谐的连接组件。IBM将Heron视为其System Two架构的核心组成部分。
Heron采用了“重型六边形拓扑结构”。简化后的示意图如下所示：
q1────q2
/ \
q0 q3
\ /
q4────q5
实际的物理布局更为复杂，但关键在于：并非所有的量子比特都直接相互连接。
这种拓扑结构是经过精心设计的。
量子硬件设计师需要在多个相互冲突的要求之间找到平衡点：
量子比特的密度
控制的复杂性
量子比特之间的干扰现象
制造工艺的限制
门操作的精确度
线路连接方式整体连接性
提高连接性并非没有代价。增加更多的物理连接组件会使得处理器的制造和操控变得更加复杂。
因此，硬件设计师必须找到一种可行的折中方案。
Heron所采用的“重型六边形拓扑结构”正是这样的一个折中方案。IBM在2024年发布的声明中将Heron R2描述为一种拥有156个量子比特的处理器，其拓扑结构采用“重型六边形布局”，并且配备了可调节的耦合器，这些设计旨在有效抑制量子比特之间的串扰现象。
这种设计为程序员带来了一些特殊的挑战：尽管该处理器拥有超过100个量子比特，但程序员仍然无法将这些量子比特视为一个完全互连的网络来处理。
因此，拓扑结构本身成为了编程环境的重要组成部分。
Nighthawk改变了量子电路的连接方式
IBM的Nighthawk采用了不同的设计思路。
与继续使用“重型六边形拓扑”不同，Nighthawk采用了正方形晶格结构。
目前IBM称Nighthawk拥有120个可编程量子比特，每个量子比特最多可以与4个相邻的量子比特进行交互。
一个简化的正方形晶格结构如下所示：
q0 ─── q1 ─── q2
│ │ │
q3 ─── q4 ─── q5
│ │ │
q6 ─── q7 ─── q8
这种设计上的差异看似微小，但实际上却可能产生重要影响。
因为每个量子比特最多可以与4个相邻量子比特进行交互，而而在传统的拓扑结构中，这个数字通常要小得多。
对于量子电路来说，这一点确实非常重要。想象一下，如果某个算法需要这样的交互操作：
q0 ↔ q1
q1 ↔ q4
q4 ↔ q7
q7 ↔ q8
正方形晶格结构能够自然地支持这种局部的交互关系。
但如果算法只需要这样的连接：
q0 ↔ q8这些量子比特仍然不是直接相连的。
因此，Nighthawk并没有完全消除路由的需求，而是减少了许多电路中所需的路由步骤。
IBM表示，正方形晶格结构比“重型六边形架构”提供了更高的连接能力，这使得使用较少SWAP门的量子电路也成为可能。在IBM2025年的开发者大会上，相关资料指出Nighthawk配备了218个耦合器，而Heron只有176个；这种更高的连接能力使得开发人员可以用更少的SWAP门来设计结构更为复杂的量子电路，其复杂度可以提高大约30%。
IBM在2026年的发展计划中进一步阐述了Nighthawk的潜力，称其为实现量子计算优势的关键平台，并计划推出具有更大电路容量以及多个120量子比特模块的产品。
这里蕴含着一个更深刻的道理：增加量子比特的数量只是提升量子处理器性能的一种方式，而提高其连接能力同样至关重要。
编译器成为硬件设计的重要组成部分
正是这一点，使得量子计算对软件开发者来说变得尤为有趣。
在传统的编程中，人们往往可以在不了解CPU晶体管具体物理布局的情况下编写代码。
但量子编程却不同——编译器必须了解目标处理器的详细结构信息。
例如，在设计一个量子电路时，编译器需要考虑以下问题：
逻辑电路
↓
应该使用哪些物理量子比特？
↓
哪些量子比特可以相互交互？
↓
处理器支持哪些类型的门操作？
↓
这些操作的噪声水平如何？
↓
电路应该如何进行路由连接？
↓
最终应该执行哪些具体的物理指令？
IBM的Qiskit文档明确指出，转译的目标是获取诸如量子处理器的耦合映射、支持的基门类型以及错误率等信息。
这意味着，量子编译器并不是简单地将一种编程语言转换成另一种编程语言，而是在解决一个受硬件限制的优化问题。
编译器需要回答以下这些问题：
哪些物理量子比特应该用来表示我的逻辑量子比特？
哪种映射方式能够最小化信号传输所需的路径长度？
哪些可用的量子比特具有更精确的校准结果？
SWAP操作应该放在什么位置进行？
能否通过重新设计电路来减少两量子比特操作的数量？
不同的布局方案是否能够完全消除信号传输所需的路径长度？
正因为如此，编译过程会直接影响量子计算的质量。
映射：将正确的量子比特放置在正确的位置
假设你的算法经常使用这样的操作：
q0 → q1
q0 → q2
q0 → q3你希望这些逻辑量子比特在物理上彼此靠近。
如果编译器将它们映射到如下位置：
q0 → 物理位置0
q1 → 物理位置1
q2 → 物理位置2
q3 → 物理位置3那么电路可能几乎不需要进行任何信号传输路径的调整。
但假如编译器选择将它们映射到如下位置：
q0 → 物理位置0
q1 → 物理位置25
q2 → 物理位置70
q3 → 物理位置110那么每个量子比特之间的交互都可能需要经过复杂的路径调整。
算法本身并没有改变，逻辑量子比特的数量也没有变化，但物理执行过程可能会产生巨大的差异。
因此，Qiskit会努力寻找能够减少信号传输路径长度的布局方案。其文档中也提到，找到最优的SWAP映射方式在计算上非常困难，所以Qiskit会采用诸如SabreSwap这样的启发式方法来寻找合适的映射方案，而无需穷举所有可能性。
令人惊讶的事实：你的算法可以根据硬件架构进行重新设计
还有一种策略。
与其试图让算法适应现有的硬件拓扑结构，不如先思考：
我能否以一种能够自然适配这种硬件结构的方式来表达我的算法？
IBM最近的研究就提供了一个很好的例子。
量子傅里叶变换是量子算法中非常重要的基础操作，但随着量子比特数量的增加，它所要求的信号传输路径可能会变得非常复杂。
2026年5月，研究人员在IBM的Heron处理器上使用基于奇偶性的电路构造方法实现了一个52量子比特的量子傅里叶变换实验。根据IBM的说法，这种设计方式通过改变量子信息的表示和传播方式，从而完全避免了依赖SWAP操作进行路径调整的需要。
这是一个非常有力的想法。
对于连接能力有限的情况，至少有三种解决办法：
改进编译器——从而实现更高效的映射/路由功能
提升硬件性能——增加物理连接点
优化算法设计——减少对远距离交互的需求
量子计算的未来发展很可能会同时运用这三种方法。
为什么IBM要突破“最近邻连接”这一限制？
Nighthawk所采用的方形晶格结构并非IBM在连接技术方面的终极目标。他们还在研究其他能够实现超越“直接相邻节点”连接的技術。
例如，IBM的路线图中提到了可以用来连接芯片上相距较远量子比特的c型耦合器。据IBM称，其Loon处理器已经实现了最高六级的连接能力，而这种设计需求在很大程度上是受其量子纠错架构的要求所驱动的。
IBM还在研发用于不同量子模块之间通信的l型耦合器。
这一点非常重要，因为当量子计算机的规模不断扩大时，连接问题最终会演变成一个系统级挑战。
我们不应该只考虑单个巨大的量子芯片，而应该这样来看待这个问题：
QPU ─── QPU ─── QPU
│ │ │
└───────┴───────┘
通信连接IBM将其长期发展目标描述为构建模块化架构，而l型耦合器正是为实现芯片、模块及系统之间的量子通信而设计的。
根据IBM的路线图，他们计划将多个Nighthawk模块连接起来；到2026年，这一技术将能够支持最多三个120量子比特模块的组合配置。
这种设计思路确实改变了我们思考问题的方式。
我们不再仅仅问：“这个芯片上哪些量子比特是相互连接的？”而是开始思考：“量子信息应该在处理器之间如何传输？”
这其实是一个更为复杂的架构级问题。
另一种不同的方法：可重构的囚禁离子量子计算机
像IBM的Heron和Nighthawk这样的超导处理器并不是构建可扩展量子计算机的唯一途径。
另一种方法是利用囚禁离子技术。
与在芯片上制造超导量子比特不同，囚禁离子系统使用的是被电磁陷阱固定住的单个离子。
关键在于，这些离子的物理排列方式是可以改变的。
ZuriQ正在开发一种基于可重构离子陷阱的量子计算机架构。
根据ZuriQ的说法，通过随时间变化电极电压，他们能够使离子陷阱阵列在三个维度上进行重新配置，从而在需要时重新安排离子的位置，并让它们在芯片内部移动。
这种设计理念从根本上改变了我们对连接问题的理解方式。
对于那些拓扑结构固定的处理器来说，我们可能会认为物理连接关系就是这样的：
A ─ B ─ C ─ D如果A需要与D进行交互，编译器就必须找到一种方法，让量子信息通过现有的网络结构进行传输。
在可重构架构中，物理连接方式本身是可以发生变化的。
从概念上来说，变化前的状态是：
A ─ B ─ C ─ D变化后的状态是：
A ─ D ─ B ─ C现在，A和D可以在物理上更加接近。
重要的是，这种机制并不是简单的路由算法——硬件本身也会参与改变连接方式。
正因为如此，从量子编译的角度来看，可重构的囚禁离子架构才显得非常有趣。
可重构连接性是否意味着无需进行编译？
并不是的。这一点非常重要。
认为可重构量子计算机意味着编译器不再重要，这种观点是错误的。
编译器仍然需要决定以下事项：
- 哪些离子应该进行交互；
- 它们应该在何时移动；
- 它们的排列方式应该是怎样的；
- 哪些操作应该并行执行；
- 移动过程会如何影响整体运行时间；
- 如何避免不必要的相互作用；
- 如何确保操作的精确性。
换句话说，编译器的职责确实发生了变化。
它不再只是问：“这个逻辑门应该在什么位置执行？”
而是会思考：“应该如何配置硬件，才能让这个逻辑门高效地运行？”
这种区别非常重要。
ZuriQ将其架构描述为“动态可重构的”，它通过根据需求在芯片上移动离子，来实现囚禁离子量子计算机的扩展。
由此引发了一个更广泛的哲学问题：是量子硬件应该适应算法，还是算法应该适应硬件？
最终的答案可能是：两者都需要适应对方。
固定连接性与可重构连接性
我们可以这样简化这两者之间的区别：
| 架构类型 | 连接模型 | 主要策略 |
|---|---|---|
| 传统固定拓扑的量子处理器 | 连接方式基本固定 | 由编译器负责信息路由 |
| IBM Nighthawk | 采用正方形晶格结构，最多与四个相邻离子交互 | 增强局部连接性 |
| IBM的长距离/模块化研究方案 | 增加额外的耦合器及模块链接 | 扩展连接范围，超越最近邻关系 |
| 可重构的囚禁离子架构 | 动态改变离子的排列方式 | 通过移动离子来创造所需的交互效果 |
这并不意味着某种方案就一定更优越。每种架构都存在需要权衡的地方。
超导处理器可以利用半导体的制造技术和快速控制技术，但其运行环境必须处于极其严苛的低温条件下（温度通常低于-150摄氏度）。
囚禁离子架构能够提供出色的量子比特性能以及可重构的连接能力，但物理上移动这些离子也会带来工程实现和控制方面的挑战。
而是：什么样的硬件组合、连接方式、编译机制以及错误校正技术，才能让大规模计算成为可能？
连接性对量子错误校正同样至关重要
错误校正需要大量的量子比特按照特定的模式进行相互作用。
你不能简单地增加数千个量子比特，就认为系统会自动具备扩展性。
这些量子比特必须以能够支持所需错误校正操作的拓扑结构进行连接。
IBM的容错技术路线图清楚地说明了这一点。
IBM提出了一种基于双变量自行车码的模块化架构，并指出，要实现所需的量子低密度奇偶校验结构，就需要让相距较远的量子比特之间建立连接。他们的路线图中包含了c耦合器和l耦合器等技术，就是为了满足这些连接需求而设计的。
连接性不仅仅是为了提高算法的执行速度，它还能决定某种错误校正架构是否具有实际应用价值。
连接性会影响你选择的算法
算法A需要大量的远距离相互作用；
而算法B则主要依赖局部相互作用。
在理想情况下，这两种算法看起来都很有吸引力；
但在实际拥有有限连接能力的量子计算机上，算法B可能会更容易执行。
正因为如此，考虑硬件特性来进行算法设计变得越来越重要。
这对量子程序员来说是一个非常重要的启示：理论上最好的量子算法，并不一定适合你在当前使用的处理器上运行。一个实用的算法，必须是考虑到它实际将在哪种硬件环境下运行的算法。
你可以将连接关系可视化为图表
理解这一切的一个有用方法是借助图论。
假设你的量子电路包含以下这些交互作用：
逻辑电路图：
q0 ───── q1
│ \ │
│ \ │
q2 ───── q3
这就是你算法的交互关系图。
现在假设硬件结构如下：
物理硬件结构：
p0 ─── p1 ─── p2
│
p3 ─── p4 ─── p5
编译器的任务本质上就是在这两张图之间找到一种合适的对应关系。
你可以这样理解这个过程：
算法图
↓
对应关系图
↓
硬件结构图
↓
路由配置图
↓
可执行电路图
这两张图越吻合，编译器需要做的工作就越少；反之，它们之间的差异越大，所需的路由配置就会越多。
这就是为什么量子硬件的拓扑结构与量子编译不能被看作是两个独立的领域——它们其实是同一个问题的不同方面。
一个简单的Qiskit实验
让我们把这个概念具体化一下吧。
创建一个电路，让相距较远的量子比特反复进行交互：
from qiskit import QuantumCircuit
qc = QuantumCircuit(6)
for _ in range(3):
qc.cx(0, 5)
qc.cx(1, 4)
qc.cx(2, 3)
print(qc)
接下来定义一个简单的线性硬件拓扑结构：
from qiskit.transpiler import CouplingMap
from qiskit.transpiler import generate_preset_pass_manager
coupling_map = CouplingMap([
[0, 1],
[1, 2],
[2, 3],
[3, 4],
[4, 5]
])
然后对这个电路进行编译：
pm = generate_preset_pass_manager(
optimization_level=0,
coupling_map=coupling_map
)
compiled = pm.run(qc)
print("原始电路的层级结构:", qc.depth())
print("编译后的电路的层级结构:", compiled.depth())
print("原始电路中包含的门的数量:", len(qc.data))
print("编译后的电路中包含的门的数量:", len(compiled.data))
具体的数字会取决于所使用的编译器版本及优化设置，但这个实验确实证明了这样一个重要原理：即使逻辑算法保持不变，硬件拓扑结构的不同也会导致物理电路的结构发生变化。
你可以尝试使用具有不同连接方式的硬件拓扑结构，然后比较生成出的电路结果。
对于那些正在学习量子编程的人来说，这样的实验正是让“连接关系”这一概念变得直观易懂的好方法。
为什么较少的SWAP门如此重要
假设电路A需要：
100个两量子比特门而电路B则需要：
100个用于实现算法逻辑的两量子比特门
+
40个SWAP门如果将每个SWAP操作分解为三个两量子比特门，那么这40个SWAP操作实际上可以完成大量的额外两量子比特计算工作。
这意味着处理器并不会把所有时间都用来执行算法本身，它还会花费时间来重新排列量子信息，以便算法能够顺利运行。
从量子计算的角度来看，这就相当于在程序运行过程中，将部分时间用于在内存位置之间传输数据，而不是进行真正的计算操作。
但还有一个问题：这些额外的门操作会增加出现错误的可能性。
正因如此，路由开销不仅会影响计算性能，还会影响最终结果的准确性，从而影响其实际效用。
IBM的Qiskit文档明确指出，在电路布局和路由设计中，减少SWAP操作是一个重要的目标；而IBM最近进行的量子傅里叶变换演示也强调了路由开销和累积的噪声对量子电路扩展能力的限制。
更多的量子比特并不一定意味着更强的计算能力
这就引出了量子硬件领域一个非常重要的概念：拥有更多量子比特的量子计算机，并不一定就是一台性能更强大的计算机。
想象一下有两种处理器：
处理器A：
1,000个量子比特
- 连接性有限
- 路由开销较高
处理器B：
500个量子比特
- 连接性更好
- 路由开销较低
哪一种处理器更实用呢？
这个问题并没有统一的答案，因为它取决于具体的应用场景。
如果算法主要需要局部的量子比特相互作用，那么处理器A可能会表现得更好。
但如果算法需要频繁地让远距离的量子比特之间进行交互，那么处理器B的连接性就会使其运行起来更加高效。
正因为如此，现代量子硬件的发展路线图才会同时考虑多个方面：
量子比特的数量
门操作的精确度
电路的复杂程度
连接性
吞吐量
错误校正能力
模块化设计
配套软件
IBM目前的硬件发展路线图正是体现了这种全面的考虑，它将Heron、Nighthawk、模块化系统、模块间的通信以及可扩展的基础设施都视为同一发展路径中的组成部分。
未来，可编程连接性可能会成为关键因素
最有趣的一点是，连接性本身也可能变得越来越可编程。
硬件架构
↓
编译器根据算法调整电路结构
算法
↓
编译器
↓
硬件配置
↓
连接性设置
↓
最终执行结果
编译器不会仅仅选择特定的门电路，它还能帮助确定这些门电路所需的物理布局或通信结构。
IBM正在通过日益紧密连接的芯片架构及模块化设计来探索这一理念，而ZuriQ所采用的囚禁离子技术则提供了另一种实现方式——在这种技术中，离子的位置可以被动态重新配置。
但这并不意味着量子计算机会变得完全互联互通。物理规律和工程限制依然存在。
然而，这表明连接性可能会成为系统主动管理的一个方面，而不仅仅是程序员被动接受的因素。
这对量子程序员意味着什么
如果你正在学习Qiskit或其他量子软件开发工具包，你可能会认为量子电路就是最终的执行程序。但实际上并非如此。
量子电路更像是你对量子计算机期望执行的任务的高级描述而已。
实际的执行过程通常如下所示：
你的量子算法
↓
逻辑电路
↓
量子比特映射
↓
路由选择
↓
门电路分解
↓
优化处理
↓
时间调度
↓
硬件执行
在实际运行过程中，物理处理器会带来各种限制。
因此，量子开发者最终应该学会思考以下这些问题：
硬件拓扑结构：哪些量子比特可以直接相互交互？
逻辑电路与物理硬件的映射关系：每个逻辑量子比特应该被放置在哪里？
路由机制：如何实现非局域性相互作用？
电路复杂度：需要执行多少顺序操作才能完成计算？
门电路的数量：该量子电路需要进行多少次耗时的纠缠操作？
针对硬件的优化：能否重新设计电路以使其更适配当前的处理器？
整体架构：不同的量子硬件设计是否能够从根本上简化问题？
这些问题使得量子编程不再仅仅局限于编写门电路，而是朝着量子系统工程的方向发展。
IBM和ZuriQ带来的更深层次启示
IBM的Heron和Nighthawk处理器展示了两个重要的概念。
首先，连接性实际上是一种设计上的权衡因素。
Heron采用的重六边形拓扑结构为高性能超导量子比特提供了良好的运行环境，而Nighthawk则将拓扑结构改为正方形格子布局，每个量子比特最多可以与四个相邻节点进行交互，从而减少了许多工作负载在路由方面的开销。
其次，IBM的发展路线图表明，局部连接性可能并不总是解决问题的关键。该公司正在探索更长距离的信号传输机制以及模块化通信技术，以此来实现更可靠的系统架构。
ZuriQ从另一个角度来解决这个问题。
它的囚禁离子架构利用动态控制的电极，在三维空间中对离子进行重新排列和传输。这种架构并没有将连接性视为完全固定的因素，而是着眼于能够重新配置离子的物理排列方式。
这两种设计理念代表着不同的工程思路。
一种思路是：
我们如何构建一个连接性更强的固定架构？
另一种思路则是：
我们如何让物理架构具备可重新配置的能力？
目前，对于这两个问题还没有普遍适用的正确答案。
但它们都指向同一个根本性问题：要实现可扩展的量子计算，就必须找到一种方法来传输量子信息，或者让相关的量子信息发生相互作用，同时确保连接成本不会压倒整个计算过程本身。
结论
当你编写如下代码时：
qc.cx(0, 50)
你其实是在描述一个逻辑运算过程。
但这并不能说明物理层面的量子计算机为了执行这个操作需要完成的所有步骤。
如果量子比特0和50是直接相连的，硬件可能能够高效地完成这种相互作用；
但如果它们之间没有直接的连接关系，编译器可能就需要通过额外的操作来重新组织量子信息。
这些额外操作会增加门电路的数量和电路的复杂度，同时也可能增加出错的风险。
因此，连接性成为影响量子计算性能的重要因素之一。
IBM从Heron的重六边形架构发展到Nighthawk的正方形晶格架构，这一演变过程充分说明了硬件拓扑结构的变化能够有效降低路由开销，并使更复杂的电路成为可能。IBM在长距离耦合器及模块化通信技术方面的研究也表明：当量子处理器的规模超越单个芯片的范畴时，连接性问题会变得更加重要。
与此同时，ZuriQ的可重新配置囚禁离子架构则展示了另一种可能性：
我们不必要求编译器去适应完全固定的硬件拓扑结构，而是可以直接改变离子的物理排列方式，从而创造出有用的配置方案。
这种思路为我们思考量子计算的未来发展提供了新的视角：
更优秀的算法
+
更高效的编译器
+
更好的连接性
+
可重新配置的架构
+
更先进的错误校正技术
=
从而打造出功能更强大的量子计算机
下次当你看到一台拥有120个或156个量子比特的量子处理器时，不要只问：“它有多少个量子比特？”
它到底能进行哪些计算操作？
因为这个问题的答案会让你更清楚地了解这台机器的实际性能。
相关文章
为什么你的量子电路在模拟器中能够正常运行，但在真实的硬件设备上却会失败？[完整指南]
如果完全相同的量子电路在模拟器中能够完美运行，那么为什么在实际的量子计算机上却常常会产生不同的结果呢？ 这个问题几乎让每一位量子开发者都感到困惑。如果你打算开发更大规模、更可靠的量子应用，理解这个现象就至关重要。 本教程假设你已经熟悉如何在 Qiskit 中创建和执行基本的量子电路。 当你第一次在真实硬件上运行一个量子电路时，你可能会认为其输出结果应该与模拟器中的结果一致。毕竟，代码、算法和编译器都是相同的。然而实际情况往往并非如此。 有时候这种差异几乎难以察觉；而有时，那些在模拟器中运行得非常完美的电路，在实际设备上却会产生令人费解的输出结果。当你的量子电路结构变得更加复杂，涉及的量子比特数
阅读全文
构建者设计模式：构建复杂对象的一种更有效的方法
有些对象非常简单，比如字符串、数字或布尔值。你可以用一行代码创建它们，然后继续进行其他操作。 而另一些对象则完全不简单。例如，一个轮播组件就需要包含项目数量、项目生成函数、控制器、高度、视图窗口比例、自动播放设置、页面切换回调函数以及无限滚动配置等信息。再比如，一个HTTP请求需要URL地址、请求头信息、认证令牌、请求体内容、超时时间以及重试逻辑。又或者，一条通知消息需要标题、正文、图标、发送渠道、优先级、声音效果、振动功能以及操作按钮等等。 当你需要构建这类对象时，一种常见的方法是使用带有大量参数的构造函数。这种方法虽然可行，但随着对象结构变得越来越复杂，就会带来一系列问题：这些参数很难区分
阅读全文
Uber开发了GitFarm，旨在为大规模的单仓库项目提供基于云的Git管理服务。
Uber的GitFarm将Git相关操作整合为一项集中式服务，从而避免了在大规模的单代码库项目中进行本地仓库克隆的操作。该平台通过使用预先准备好的下载资源、临时沙箱环境、仓库同步机制以及gRPC流式传输技术，有效降低了那些需要管理数千个仓库的自动化系统所消耗的资源量，并缩短了其启动延迟。 作者：Leela Kumili
阅读全文
在修改现有的代码库之前，如何利用人工智能来理解这些代码的含义
许多工程师在继承现有的代码库时，首先想要做的就是修改这些代码。我完全理解这种冲动。 当你打开一个长达1500行的类文件时，你会看到其中混杂着数据库调用、业务规则、分散在各处的配置值、根本没人愿意去修改的方法，以及那些提到早已被淘汰的系统的注释。 这时，一款人工智能编码助手主动提出可以帮助你理解整个代码库的结构。 于是你就会问： 请重构这个类。 但通常来说，现在还不是进行重构的时候。 从处理遗留系统的经验中，我认识到：代码虽然可能写得很糟糕，但却可能蕴含着重要的信息。 某个奇怪的条件实际上可能代表着某种业务规则；重复出现的计算逻辑可能是由于两个看似相同的流程其实并不完全相同所致；一个命名很糟糕的
阅读全文