量子计算资源是扩展高性能计算（HPC）系统计算能力的最有前途的候选资源之一。因此，HPC量子集成已成为一个日益活跃的研究领域。虽然现有文献大多集中在软件堆栈集成和量子电路编译上，但混合资源分配和作业调度等关键挑战却受到较少的关注。

4月17日，意大利linkS基金会、E4 Computer Engineering、3CINECA、4Politecnico di Torino组成的科研团队在arXiv平台上发布题为“Assessing the Elephant in the Room in Scheduling for Current Hybrid HPC-QC Clusters”（评估当前混合HPC-QC集群的调度中的“房间里的大象”）的研究论文。

在这项工作中，科研团队强调了在将量子计算机与作HPC环境集成的背景下，需要同时考虑量子技术的当前成熟度和异构性。然后，为了应对这些挑战，科研团队提出了一套概念策略，这为在不久的将来实际的HPC-QC集成铺平了道路。

注：房间里的大象（elephant in the room）是一个英语习语，用来隐喻某件虽然明显却被集体视而不见、不做讨论的事情或者风险，抑或是一种不敢反抗争辩某些明显的问题的集体迷思。其源于一则寓言故事：有个人参观博物馆，他在那里仔仔细细观察了很多小昆虫，但是却没有注意到屋子里的大象。一般来说，大象这么大只，如果房间里有头大象，肯定看得见，除非是故意视而不见。

一、导引

如今，量子计算机（QC）被认为是加速化学和材料研究中计算成本高昂的任务的绝佳候选者。这些研究领域正是高性能计算（HPC）研究中的典型代表。因此，混合经典-量子方法因其独特优势而备受关注，并已成为当前研究的热点。随着不断推进量子计算（QC）与高性能计算（HPC）系统的集成，这一领域逐渐显现出一种显著趋势：混合计算模式正在成为未来发展的关键方向，并且随着技术的成熟，编程模型可能会转向成熟的卸载方法，类似于目前用于图形处理单元（GPU）加速器的方法。但是，当前具有不同特征的不同技术共存的方案需要一组特定的工具和技术，这些工具和技术必须解决一个关键问题——量子处理单元（QPU）是一种极其稀缺的资源。

科研团队声称，要想实现HPC工作负载（即大规模MPI作业）与量子的集成，战胜与编译器、软件堆栈、编程语言等相关的挑战，解决量子和经典资源的公平和有效分配是关键的一步。以前的文献强调了专用计划策略的重要性，尤其是在多个用户或作业共享对单个QPU的访问权限的情况下。如果没有这样的策略，量子资源和经典资源都有可能得到充分利用或浪费。通过这篇论文，科研团队旨在进一步强调这些关键性，并提出一些解决这些问题的想法。

在这篇论文中，科研团队

本文的结构如下：第2节回顾了HPC-QC集成的最新工作，重点介绍了量子资源分配的关键概念。第3节概述了具体的集成挑战，而第4节提出了在作HPC约束下解决这些挑战的方法。第5节总结了这篇论文。

二、HPC-QC集成概述

HPC-QC集成在研究层面受到积极研究，由量子计算供应商推广，并得到EuroHPC和Quantum Flagship等知名倡议的支持。这些努力对量子应用的分类做出了重大贡献、HPC-QC架构的定义、共享软件堆栈的开发和编程模型的初始轮廓。

然而，目前，量子机器通常安装在远离运营数据中心的实验室环境中，并通过高级语言和专用库（例如Qiskit、Pulser）经由公共网络进行访问。通过这些工具，用户可以定义内核（即电路），通过具象状态传输（REST）应用程序编程接口（API）将它们发送到机器，并以顺序（主要是单线程）方式执行它们。

虽然云访问模型可以有效地利用当前的量子机器，但它无法实现真正的HPC集成，这需要直接、高带宽的连接和对量子硬件（HW）的闭环控制。包括HPC设施在内的研究社区已开始探索朝着这个方向迈进的步骤，但由于该技术仍处于早期阶段，因此对于如何实现HPC-QC集成尚无明确的共识。尽管如此，科研团队可以根据文献中提出的解决方案将HPC-QC集成方法分为三种类型：

第一种模式仍然需要硬件成熟度的显著进步，因此这篇论文没有讨论，而是重点介绍第二种和第三种集成模式的用例。

三、当前的HPC-QC集成挑战 

图1：相关量子作业/镜头的时间尺度。中性原子机器上的作业包括任意寄存器几何结构的校准时间。

在探索HPC和量子计算的集成时，必须弥合成熟、标准化的HPC技术与量子硬件仍然主要是实验性质之间的根本差距。在本节中，科研团队将重点介绍必须解决的两个关键差异，以实现HPC和量子资源的有效集成。然后，科研团队将讨论管理对可用性高度不平衡的资源的访问的挑战。

软件异构性：QC和HPC的软件生态系统差异很大，首先是它们选择的编程语言。QC应用程序通常依赖于Python和Julia等解释型语言，而HPC传统上使用C、C++和Fortran等编译的、面向性能的语言，以及MPI、OpenMP和CUDA等编程模型。这种差异反映了这两个领域之间的成熟度差距：QC仍处于早期阶段，侧重于展示可用性而不是最大限度地提高性能，而HPC则围绕着针对效率优化的成熟架构构建。尽管对齐和标准化QC和HPC的软件堆栈对于未来的集成至关重要，但它超出了这项工作的范围。

访问和分配模型：当前的量子计算机通常通过专用库和REST API进行访问，由支持异步作业提交和多用户使用的内部排队系统提供支持。对这些API的访问通常通过专有的会计机制进行管理。但是，此模型与运营HPC环境不一致，在运营HPC环境中，资源访问由作业计划程序和策略驱动的分配控制。此外，每个量子硬件供应商都提供自己的API，需要自定义集成工作，以实现与现有HPC系统的互作性。鉴于此背景，第一个关键挑战是将QPU供应商机制集成到由批处理计划程序和完善的策略和会计系统管理的环境中。具体来说，科研团队需要一种方法将QPU（通常作为Web服务公开）整合到HPC系统的运营模型中，确保与SLURM等作业调度程序兼容以及遵守机构资源管理政策。

工作负载不平衡：除了访问模型之外，还需要了解量子作业的特征时间尺度会严重影响作业调度。与随算法复杂性和输入大小扩展的经典计算不同，量子内核持续时间在很大程度上由特定的QPU技术决定。如图1所示，执行时间可能会因量子硬件的不同而有很大差异，这可能会导致工作负载不平衡。这种可变性可能会挑战传统HPC批处理计划程序的有效性，传统HPC批处理计划程序可能难以在此类异构环境中保持高效的资源利用率。

清单1：运行潜在HPC-QC混合作业的SLURM作业脚本示例。

为了阐明这一点，科研团队可以以清单1中的作业为例，它描述了一个作业，该作业在经典分区中共同调度10个节点，在量子分区中协同调度1个QPU（定义为SLURM gres，详见第4节），这两个任务都持续1小时。科研团队考虑了超导QPU的情形，假设每个量子任务都将持续约10秒（见图1）：即使在作业中启动了许多任务，这也可能导致专门分配给此作业的QPU严重利用不足一小时。相反，如果QPU基于中性原子，则量子任务很容易持续超过30分钟，导致经典节点未充分利用，这些节点将处于空闲状态，等待量子作业完成。在将量子硬件集成到HPC设施中以确保有效资源分配时，必须考虑这些问题：具有独占QPU访问权限的简单协同调度不足以在异构HPC-QC环境中实现最佳资源利用率。

四、建议的集成思路

鉴于当前QC和混合算法的异质性，一刀切的解决方案不太可能。相反，科研团队设想了一组对HPC友好的互补方法，以根据工作负载不平衡的方向量身定制，以应对集成挑战。虽然这些策略在传统HPC中广为人知，但它们在HPC-QC集成中的应用也才刚刚开始探索，又或者据科研团队所知，在文献中被忽视了。科研团队相信，即使在NISQ时代，单独或组合使用它们也将实现有效的HPC-QC集成。

工作流：基于松散耦合的工作流方法，并利用工作流管理器（如Nextflow、StreamFlow、PyCOMPS，甚至直接shell脚本），令用户能够独立调度经典作业和量子作业，但将它们视为单个执行，如图2所示。与上一节中讨论的纯共同调度不同，资源分配最初不会同时针对量子资源和经典资源进行；当执行需要资源时，会发生这种情况。此行为可确保执行仅保留它在计算期间使用的资源。另一方面，当每个步骤的持续时间超过计算长度时，每个步骤必须经历的排队时间可能会带来很大的开销。

图2：作为松散耦合、独立计划的工作流执行的量子-HPC工作负载。

虚拟QPU：由于QPU稀缺，因此引入某种机制以允许多个应用程序共享它似乎是合乎逻辑的。虽然隔离问题令在应用程序之间划分可用量子比特变得不可行，但让它们通过时间交错共享资源仍是合理的。当应用程序花费大量时间执行长时间运行的经典计算与非常短的量子作业交错执行时，此声明尤其适用。在这种情况下，纯协同计划解决方案将保留量子资源而不会使用太长时间，而与量子快照的短时间相比，工作流方案将遭受大量的排队时间。

量子执行的时间交错可以通过虚拟化来实现：通过配置为单个真实QPU分配的QPU类型的gre数量（--gres=qpu）来定义（固定或动态）数量的虚拟QPU（VQPU）。通过虚拟化，应用程序可以请求虚拟QPU，而实际上，它们为在同一物理QPU上执行预留分时。图3显示了这种行为的实际应用：两个应用程序同时向量子资源发出请求，但由于这些请求的速率是有限的，科研团队可以以最小的延迟在资源上共同调度它们，这受VQPU数量的限制。使用VQPU有几个好处，因为这些更改根本不影响应用程序代码，同时扩大了量子资源的可用性。另一方面，如果量子分区所需的时间与准备快照数据所需的时间相当或更大，则执行时间交错应该会导致边际收益，并且不可行。

图3：表示异步作业提交到真实QPU，利用虚拟QPU实现多租户。

延展性：为混合HPC-QC工作负载分配资源的挑战源于资源需求的动态性质与传统资源分配的静态性质之间的不匹配。基于延展性的方法通过允许应用程序在执行期间请求或释放资源来解决这个问题，从而提高经典和量子资源的利用率。延展性已在HPC文献中得到广泛探讨由于其显着的潜在好处。但是，它也带来了额外的复杂性：应用程序必须能够适应可用进程数量的运行时变化。这一要求限制了它的采用，因为大多数HPC库（如MPI）以及基于这些库构建的应用程序本身并不支持延展性。尽管如此，在新兴的HPC-QC领域，混合应用才刚刚开始形成，因此有机会从一开始就考虑到延展性来设计它们。

图4：表示具有延展性属性的使用案例，用于在从经典工作负载切换到面向量子的工作负载时处理资源的释放和检索。

通过可延展执行，应用程序根据需要动态请求资源。与工作流不同，资源分配在运行时可以根据系统可用性而变化：应用程序可以使用更少的资源继续运行，接受较慢的性能以换取减少的队列时间。重要的是，执行被视为单个作业而不是一系列任务，从而避免了重复排队。例如，在量子阶段，该作业可以保留最少的经典资源，从而可以在之后更快地恢复经典计算（参见图4）。当经典阶段和量子阶段都很短时，这种方法特别有利，因为工作流可能会产生过多的排队开销。在虚拟化产生有限好处的情况下，它也可能很有效，因为延展性与量子阶段持续时间无关。但是，与其他策略不同的是，实现延展性需要对应用程序代码进行大量修改，因为它必须支持在运行时动态适应资源变化。

五、总结和未来工作

使用QC作为HPC集群的加速器的趋势日益显著，而这源于两者具有重叠的应用领域以及两种技术具备互补优势。量子硬件供应商和超算中心都在努力实现实用的近期HPC-QC集成。然而，当前以QPU稀缺、异构技术和客户端-服务器访问模型为标志的格局需要量身定制的解决方案来实现高效的资源分配和调度。简单地将QPU附加到HPC计划程序可能会未充分利用量子资源或经典资源。根据工作负载不平衡（通常受特定量子技术的影响），需要专门的策略来最大限度地提高系统效率。

在这项工作中，科研团队研究了这一挑战并提出了三个互补的想法：松散耦合的工作流、虚拟QPU和工作延展性。每个版本都针对不同的场景和硬件架构。未来的工作将扩展这些概念，为集成量子和HPC系统制定开放、实用的蓝图。

此外，从量子计算的角度出发，由于目前量子计算机性能有限、实用量子算法稀缺等原因，量子-经典混合算力平台正在成为各大机构发展量子计算云平台的主要方向。通过在云平台上集成量子计算资源，混合算力平台能够以相对较低的价格，随时向用户提供量子计算服务，不仅有助于推动量子计算技术的普及，还为量子计算在科研、金融、医疗等领域的应用提供了更多可能。

参考链接