[论文解读] Trials and Tribulations of Developing Hybrid Quantum-Classical Microservices Systems

Javier Rojo, David Valencia+4 more|arXiv (Cornell University)|May 10, 2021

Cloud Computing and Resource Management参考文献 29被引用 10

一句话总结

本文利用 Amazon Braket 实现了一种用于旅行商问题的量子微服务，以评估将量子算法集成到混合经典-量子微服务架构中的可行性。研究识别出关键局限性——如硬件耦合、供应商特定结果、噪声依赖性以及缺乏中间验证——这些因素破坏了组合性与可重用性等核心面向服务的原理。

ABSTRACT

Quantum computing holds great promise to solve to problems where classical computers cannot reach. To the point where it already arouses the interest of both scientific and industrial communities. Thus, it is expected that hybrid systems will start to appear where quantum software interacts with classical systems. Such coexistence can be fostered by service computing. Unfortunately, the way in which quantum code can be offered as a service still misses out on many of the potential benefits of service computing. This paper takes the traveling salesman problem, and tackles the challenge of giving it an implementation in the form of a quantum microservice. Then it is used to detect which of the benefits of service computing are lost in the process. The conclusions help to measure the distance between the current state of technology and the state that would be desirable in order to have a real quantum service engineering.

研究动机与目标

• 研究在混合经典-量子架构中将量子算法作为微服务实现所面临的挑战。
• 识别当前量子平台如何破坏面向服务计算的核心原则，如组合性、可重用性与硬件抽象。
• 通过在 Amazon Braket 上使用现实世界问题——旅行商问题——评估量子微服务的实际可行性。
• 评估硬件特定约束（例如，量子比特拓扑、噪声、结果格式）对服务互操作性与编排的影响。
• 强调迫切需要发展量子服务工程方法论，以弥合经典微服务与量子计算之间的差距。

提出的方法

• 使用 Amazon Braket 的量子 SDK 和基于 Qiskit 的电路编译，实现了一种用于旅行商问题的量子微服务。
• 通过 Amazon Braket 在三个不同的量子硬件提供商（Rigetti、IonQ、D-Wave）上部署该量子微服务，以评估可移植性与一致性。
• 评估执行流水线：量子电路生成 → 目标硬件编译 → 在基于云的量子处理器上执行 → 结果获取。
• 通过分析不同供应商在结果格式、错误率与执行时间上的差异，量化硬件耦合程度。
• 评估由于波函数坍塌导致无法访问中间量子态，从而严重限制运行时验证与编排能力。
• 评估 Azure Quantum 与 IBM Quantum 等现有工具在抽象与可移植性方面的表现，发现其在微服务开发方面相较于 Amazon Braket 并无显著优势。

实验结果

研究问题

• RQ1 在混合经典-量子架构中，量子算法在多大程度上可被有效抽象为一等微服务？
• RQ2 硬件特定特性（如量子比特拓扑、噪声、结果格式）在多大程度上影响量子微服务的可移植性与互操作性？
• RQ3 哪些关键技术障碍阻碍了量子微服务实现与经典微服务相同的质量属性（如可重用性、可维护性）？
• RQ4 测量过程中量子态的坍塌在多大程度上限制了量子微服务的编排与验证能力？
• RQ5 现有量子软件开发工具包与云平台在多大程度上可减少供应商锁定并提升量子服务工程能力？

主要发现

• 由于不同供应商在量子比特拓扑、门集与结果表示方面存在差异，量子微服务与底层硬件紧密耦合。
• 不同量子处理器之间的噪声水平与错误率存在显著差异，使得在不同平台上实现一致结果极为困难。
• 测量后量子态的坍塌阻止了对中间结果的运行时检查，严重限制了编排与调试能力。
• 当前平台不支持量子微服务的标准化接口，违反了面向服务计算中核心的硬件抽象原则。
• 尽管存在 Amazon Braket、Azure Quantum 与 IBM Quantum 等工具包，但目前尚无任何解决方案能实现真正可移植或互操作的量子微服务。
• 缺乏成熟的量子 DevOps 与信任机制，进一步阻碍了量子微服务在生产级混合系统中的实际应用。