⚛️ quantum physics

NxM-Version Programming for Quantum Software: High-Level Components across Frameworks and Engines

本文介绍了 Quanifi，这是一个基于 Apache NiFi 的框架，它通过将来自多个软件框架的高层例程封装为可互换的组件，实现了 N×M 种量子程序的执行，从而促进了跨框架和跨引擎的冗余，以系统地检测并隔离量子软件与硬件中的缺陷。

原作者： Neilson Carlos Leite Ramalho, Higor Amario de Souza, Anthony Accioly, Valter Vieira de Camargo, Marcos Lordello Chaim

发布于 2026-09-29

📖 1 分钟阅读🧠 深度阅读

CC BY 4.0

原作者： Neilson Carlos Leite Ramalho, Higor Amario de Souza, Anthony Accioly, Valter Vieira de Camargo, Marcos Lordello Chaim

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

量子计算有望解决目前最强大的超级计算机也无法处理的问题，但为这些机器构建软件是一项脆弱且令人困惑的任务。与处理简单开关（开或关）信息的经典计算机不同，量子机器使用可以同时存在于多种状态中的“量子比特”（qubits）。为了让它们工作，程序员必须构建复杂的操作序列，通常需要编写直接与机器物理特性对话的代码。这需要一种罕见的技能组合：对量子力学的深刻理解、编写复杂代码的能力，以及对快速变化的各种软件工具环境的熟悉程度。每一家主要的技术公司和研究小组都构建了自己与量子硬件通信的方式，使用了不同的语言和规则。这种碎片化使得人们很难判断结果是否正确，因为错误可能出现在代码中、用于编写代码的工具中，或者机器本身。

来自巴西的一个研究小组开发了一种新的方式来应对这种复杂性，他们将量子软件视为水流通过一系列管道，而不是一段需要编写的文本墙。他们创建了一个名为 Quanifi 的系统，允许用户通过将预制的模块拖放到可视化屏幕上，来构建量子程序，就像在从未焊接过导线的条件下组装电路板一样。他们方法的高明之处在于如何测试这些程序。该系统不是在单台机器上运行单个版本的计算，而是通过三种不同的软件工具并在三台不同的量子计算机上同时运行同一个问题。这创造了一个结果网格，其中所有的可能组合都会被同时测试。如果答案不一致，系统可以精确地指出错误发生在哪里：是软件工具、计算机硬件，还是两者的特定配对？

研究人员使用这种方法运行了一个经典的搜索算法，即格罗弗算法（Grover's algorithm），该算法旨在从大型列表中找到特定的项。他们使用三种不同的软件框架——Qiskit、Cirq 和 PennyLane 构建了相同的搜索程序，并将它们发送到位于世界不同部分的三台量子计算机：一台来自 IBM，一台来自 IQM，一台来自 Quantum Inspire。通过比较这九条不同路径的结果，他们能够发现如果仅观察单一结果时会无法察觉的不一致之处。这个他们称为 N×M 执行的过程，就像是一个强大的安全网，揭示了整个量子计算生态系统中隐藏的缺陷。

这项调查发现了行业内工具和机器存在的三个真实缺陷。第一个问题是在 Quantum Inspire 的一台机器上发现的。当研究人员使用 Cirq 软件框架时，该机器始终返回错误的答案，翻转了结果的比特位。然而，同样的软件在另外两台计算机上运行完美，且其他软件框架在该特定机器上也运行正常。这种特定的失败指向了机器适配器在翻译 Cirq 指令时的问题。事实证明，该适配器使用了一种特定类型的旋转门，但方向错误，实际上是将量子比特旋转到了相反的方向。研究人员通过模拟该错误确认了这一点，并向供应商进行了报告。

第二个缺陷涉及同一台 Quantum Inspire 机器。软件适配器声称该机器可以执行某些复杂的运算，但实际上并不能。当研究人员尝试使用这些不受支持的操作时，机器在没有发出任何警报的情况下静默失败，产生了错误答案。这凸显了软件宣称的功能与机器实际能力之间的差距。第三个，或许也是最重要的发现，涉及一个名为 Open Quantum 的云服务，它作为一个中间人，允许用户通过单一接口访问不同的量子计算机。研究人员通过直接连接和通过该云服务，向机器发送了完全相同的电路文件。虽然直接连接可以正常工作，但云服务对某些类型的电路返回了错误的结果。这个错误非常微妙：该服务在不知情的情况下删除了指令中的特定旋转步骤，在没有通知用户的情况下改变了计算过程。供应商确认了这一解析错误，并在收到报告后不久对其进行了修复。

这项工作的价值不仅在于发现这些漏洞，更在于发现它们的方法。通过同时运行每种软件框架和硬件的组合，研究人员创建了一张可靠性地图，展示了系统在哪里失效。他们发现，有些工具在某些机器上表现良好，但在另一些机器上则会失败；并且，如果只看最终结果，某些云服务引入的错误是无法检测到的。这种方法不需要用户成为量子物理专家或编写复杂代码，只需组装模块并让系统比较结果即可。研究人员指出，虽然他们在某些机器上的四量子比特版本测试由于噪声过大而无法得出确切结论，但两量子比特的测试是清晰且具有决定性的。

这项研究表明，通往可靠量子计算之路不仅需要更好的硬件，还需要一种验证软件和硬件是否协同工作正确的方法。研究人员展示了通过将不同的软件框架和不同的机器视为同一个测试的独立版本，他们可以隔离那些原本会被隐藏起来的故障。他们报告了发现的所有三个缺陷，且云服务提供商已经确认并修正了其错误。关于 Quantum Inspire 适配器的另外两个问题仍在审查中。这项工作表明，随着量子计算从实验室走向现实世界，这种交叉检查对于确保我们得到的答案确实正确将至关重要。

技术摘要：用于量子软件的 N×M 版本编程

问题陈述

量子软件工程正在从低层级的电路构建向高层抽象转型，但编写量子软件仍然具有挑战性。开发者必须具备量子力学、线性代数以及特定框架 API（例如 Qiskit、Cirq、Qrisp、PennyLane、pyQuil）的专业知识。每个框架通过不同的方法签名和数据格式来暴露概念，这为经典开发者制造了障碍，并经常导致生成的代码缺乏可维护性。此外，验证量子软件非常困难，因为其输出是概率分布；一个错误的运行可能会产生一个与正确运行无法区分的分布。当预期输出未知或故障极其细微时，传统的测试方法往往难以奏效。

方法论

作者提出了 Quanifi，这是一个将高层级量子例程封装为 Apache NiFi 数据流平台中可配置组件的工具。这种方法利用低代码、可视化的数据流编程，允许用户在无需编写电路级代码的情况下组装量子流水线。

Quanifi 框架

组件库： Quanifi 提供 108 个 NiFi 处理器，这些处理器封装了来自五个主要框架（Qiskit、Cirq、Qrisp、PennyLane、pyQuil）和两个执行后端（Amazon Braket、Microsoft Q#/QDK）的例程。
互操作性： 组件使用 OpenQASM 2.0 作为桥接格式来交换电路。这使得由一个框架（如 Cirq）构建的电路可以由另一个框架（如 Qiskit 或 IQM）关联的模拟器或硬件后端执行。
执行模型： 该系统将量子人工制品（电路或测量计数）视为带有元数据属性（如 circuit.format、sim.shots）的 FlowFile。

N×M 程序执行

其核心方法论贡献是 N×M 程序执行。系统不是在单个引擎上运行单个实现，而是构建了一个“版本矩阵”，其中：

N 代表同一个算法的多个独立框架实现数量。
M 代表执行引擎（模拟器或真实量子硬件）的数量。
系统在单个 NiFi 流中执行所有的 $N \times M$ 种组合。

这种设计实现了故障归因：

若不同行之间存在分歧（相同引擎，不同构建者），则指向特定的实现。
若不同列之间存在分歧（相同构建者，不同引擎），则指向特定的引擎。
若单个单元格内存在分歧，则指向特定的构建者-引擎对。

核心贡献

Quanifi 库： 一组 108 个 NiFi 处理器，它们封装了来自五个不同框架的高层级量子例程，并通过 OpenQASM 2.0 统一在通用接口之后。
N×M 执行模型： 一种新颖的执行策略，通过跨结合多个实现和多个引擎，通过一致性和差异性分析来检测故障。
实证评估： 在真实量子硬件（IBM ibm_kingston、IQM garnet 和 Quantum Inspire Tuna-17）以及通过云服务（Open Quantum）进行的广泛评估，证明了能够检测出执行工具链中的三种不同缺陷。

结果与发现

作者在定义的矩阵中执行了 Grover 算法和各种加法器电路。N×M 方法成功识别了三个在单路径测试中可能被忽略的现实世界缺陷：

错误的门集声明（Quantum Inspire 适配器）： 该设备的适配器声称支持某些门（如 cx、cp、swap），但这些门并不在设备声明的门集中（该设备仅支持 CZ）。这导致了错误的转译。
错误的 Rx 执行（Tuna-17）： Quantum Inspire 适配器将 Rx 声明为原生门。然而，设备执行 Rx 时使用了相反的角度。这导致依赖于被转译为 Rx 的 u3 门的 Cirq 电路失败，而使用命名门的 Qiskit 和 PennyLane 电路则成功了。
电路修改（Open Quantum 云服务）： 研究发现，某云服务会静默修改分解后的电路，通过剥离 Rz 旋转门。这导致加法器电路和特定的 Grover 电路得出错误答案，且不产生任何错误信息。该缺陷被追溯到 QASM 解析函数，并由提供商确认及修复。

研究还指出，对于某些设备上的四比特电路，成功概率接近随机猜测，这使得区分构建者性能与硬件噪声变得困难。然而，两比特电路在大多数设备上表现出较高的成功率（0.91–0.96），验证了该方法在较小规模验证中的有效性。

意义与主张

论文声称 N×M 执行 为量子软件工程提供了一种稳健的机制，通过以下方式实现：

实现故障检测： 它允许开发者即使在预期输出未知的情况下，也能通过利用独立开发版本之间的一致性来检测故障。
归因错误： 它能隔离故障是源于特定的框架实现、特定的硬件引擎，还是两者特定的组合。
提高可靠性： 该方法揭示了云供应商和适配器中存在的关键缺陷，这些缺陷会返回错误答案而不报告错误，凸显了当前量子执行服务的不可靠性。
降低门槛： 它通过允许领域专家通过可视化方式组装流水线，而无需深入了解特定框架 API 或门级编码，从而降低了量子编程的门槛。

作者总结道，虽然目前的评估侧重于小型电路和特定算法，但 N×M 方法为评估量子执行服务的可靠性以及揭示软件-硬件栈中的微妙漏洞提供了一条切实可行的路径。未来的工作包括将处理器库扩展到其他语言（C++、Julia），以及集成用于更复杂测试场景的概率预言机（probabilistic oracles）。