量子计算机正在进入高性能计算中心，目前的主要挑战已从单纯的硬件访问转变为集成问题。当前许多软件路径仍然依赖于用户SDK、调度器和后端API之间特定于供应商的适配器链。这种模式使操作变得不必要的复杂，并拖慢了从试点项目向生产工作流过渡的进程。

我们提出了一种以量子设备管理接口为核心的实用集成路径。以IQM Quantum的超导系统作为硬件案例研究，我们实现了一个基于IQM Quantum的QDMI层，并将其连接到高性能计算中心在处理量子计算机时已经关注的两个软件层：基于Slurm的作业执行和面向Qiskit的用户工作流。该实现已公开提供。

核心信息很简单：将量子硬件集成到高性能计算中，不必为每个后端都进行定制化的工程工作。一旦软硬件边界标准化，软件栈的大部分内容就可以在不同供应商和部署风格之间复用。我们的结果并不声称标准化能消除所有高性能计算与量子计算集成中的挑战，而是表明这一特定边界如今已经可以以对用户、运维人员和供应商都实用的方式进行标准化。

一、引言

高性能计算中心习惯于集成新的加速器，而无需每隔几年就重写其整个软件栈。这能行之有效，是因为接口是稳定的：用户保留熟悉的工具，运维人员维持可管理的工作流，而硬件多样性则通过清晰的系统边界来处理。

量子计算如今正在进入同样的环境，但许多集成路径仍然脆弱，因为量子软件生态系统的相当一部分并非为满足高性能计算需求而设计。团队通常需要构建从前端SDK到供应商API的、针对特定后端的定制连接，然后在此基础上添加自定义的调度器粘合层。这对于短期概念验证尚可应对，但当中心希望支持多个供应商后端、长期维护工作流或跨站点共享工具时，这种做法成本就会变得很高。

对于高性能计算运维人员来说，问题很快就会出现。每个特定于后端的路径都带有其自身的认证行为、状态模型和错误语义。这些差异中的每一项都必须反映在脚本、监控和用户支持中。对用户而言，这通常意味着更换后端就需要更改整个代码和作业设置，即使实际的科学工作流并未改变。

在实践中，这正是许多高性能计算与量子计算集成工作进展缓慢的地方。挑战不仅在于量子比特质量或算法成熟度，还在于软件栈中间不断积累的大量定制集成代码。近期的部署和架构工作明确表明了这一点：围绕校准更新、维护和调度语义的操作现在已成为需要优先关注的问题。与此同时，关于资源管理的研究正趋于一致，认为量子资源应通过熟悉的HPC机制来管理，而非通过临时的侧信道。

本文聚焦于该宏大图景中的一个具体边界：HPC软件层与量子后端之间的设备管理接口。我们以QDMI作为该边界的标准化目标，并通过与IQM Quantum硬件的实际集成工作对其进行评估。目标出于务实的考虑。我们并非要从头提出一个完整的HPCQC架构或中间件，而是表明这个核心边界已经可以标准化，从而立即减少集成工作量，并可直接惠及其他希望将量子硬件集成到HPC环境中的团队。

核心贡献是一个完整的实现和集成路径，公开提供。首先，我们构建并分析了一个基于IQM Quantum的QDMI实现，该实现将真实后端行为映射到QDMI的会话、查询和作业语义中。其次，我们将该层连接到常见的HPC软件路径：基于Slurm的执行和一个面向Qiskit的前端适配器，该适配器以QDMI而非单一供应商API为目标。第三，我们通过一个端到端的QSCI工作流验证了该路径，该工作流通过用户和运维人员在实际中会使用的相同组件运行。

我们的核心主张有意保持适度且可操作：将量子硬件集成到HPC中不必令人却步或被供应商锁定。设备管理边界之上的软件层，一旦该边界得到充分标准化，即可共享。IQM Quantum是具体的案例研究平台，但该集成模式不局限于单一供应商。

这一主张并不意味着所有集成工作都会消失。物理设备仍然具有特定于供应商的载荷格式、校准行为和操作约束。关键在于，这些差异可以被隔离在设备插件内部，而不会渗透到HPCQC软件栈的每一层。

本文其余部分结构如下。第二节介绍所需的背景和操作上下文。第三节详细解释基于IQM Quantum的QDMI实现。第四节描述标准化的设备层如何连接到HPCQC工作流。第六节通过所提出的基础设施，逐步展示QSCI算法的端到端执行。第五节阐述三种潜在的部署场景。最后，第七节总结了对中心和供应商具有实用价值的要点。

二、预备知识

为使本文自成一体，本节重点回顾两个核心组成部分：QDMI作为拟标准化的接口，以及IQM Quantum系统作为本案例研究的目标硬件平台。

01.QDMI作为面向HPC的边界

QDMI旨在标准化量子设备的软硬件边界，为后端集成提供稳定、供应商无关的API。这种设备级抽象是对中间件解决方案的补充，中间件在QDMI之上运行，用于实现资源调度、作业编排以及HPC环境中量子与经典资源的统一管理。通过聚焦于设备接口，QDMI使研究人员能够为混合量子-经典工作流构建可移植、可扩展的解决方案。

适配器、编译器、资源管理器、认证器、调度器等各类软件组件，以及不同类型的硬件平台，均通过QDMI作为标准化的软硬件边界进行交互。

QDMI使用C语言编写，这使得它可以很方便地用多种语言（C++、Fortran、Rust或Python）进行封装和实现，对于长期运行的集成代码足够稳定，并且在资源所有权和错误处理方面非常明确。

从概念上讲，QDMI提供三个函数组。会话函数为选定的后端创建并初始化一个经过认证的执行上下文。查询函数暴露设备属性，范围从静态架构数据到与校准相关的动态数值。作业函数管理程序提交、作业状态跟踪、取消和结果检索。

示例1展示了一个涉及上述函数组的典型QDMI交互模式。请注意，除了开头的IQM Quantum标识符外，完全相同的模式适用于任何QDMI设备，无论具体的后端细节如何。首先，初始化一个设备。接下来，可以配置并与该设备建立一个经过认证的会话。然后，该会话可用于创建一个作业。配置完成后，可以提交作业执行并检索其结果。最后，当不再需要时，显式释放作业和会话，并终结设备。

沙漏视图说明了本文的核心论点：HPCQC软件栈的上层，如前端的适配器、编译器或资源管理器，只要它们以QDMI为目标，就可以独立于供应商API进行演进。下层则可以自由地在接口背后暴露硬件特定的功能。

明确范围也很重要。QDMI标准化的是控制边界，而非完整的科学工作流。它不决定使用哪种转换器、选择哪种算法框架，或者中心如何全局调度混合的经典和量子资源。这些问题仍属于更高层级的关注点，但当硬件边界稳定时，这些层面的构建和维护无疑会变得更加容易。

02.IQM Quantum系统与服务器API背景

我们的案例研究使用超导量子计算机，因为它们代表了现实的HPC集成目标：可操作的量子硬件、周期性的校准更新，以及远程和本地两种部署模式。这使我们能够评估QDMI是否具有足够的表达能力来涵盖不同的部署风格，以及相同的软件路径是否能在这些部署中通用。作为HPCQC领域内成熟的供应商，IQM Quantum系统拥有现有的软件栈，QDMI必须被嵌入其中。本节概述了相应的软件栈，其中QDMI被定位为中间件组件和后端IQM Quantum服务器API之间的共享接口。

在最底层是IQM Quantum服务器API，它暴露了QDMI设备实现所需的后端原语。它允许发现可通过QDMI暴露的可用后端列表。在查询方面，它暴露静态架构信息（例如，设备拓扑、站点标识符和运行可用性）和动态质量指标（例如，量子比特相干时间和门保真度）。在执行方面，它提供作业提交、状态检查、工件访问以及（如果适用）取消行为。

在下一节中，我们将描述这些概念如何映射到QDMI的概念，以及如何成功地将它们抽象在这个通用接口之后。

三、实现基于IQM Quantum的QDMI设备

在阐述了高层背景之后，本节描述基于IQM Quantum后端的QDMI设备的具体实现，并解释特定工程选择的理由。目标是使集成路径可复现，而非仅提供一个概念性草图。该实现以开源形式提供，使其他中心能够检查并调整该模式，而无需从头重建。本节总结了所介绍的功能性实现。

01.实现架构

基于IQM Quantum的QDMI设备被构建为一个共享库，暴露所有用于会话管理、属性查询和作业处理的QDMI函数。在实现中，大部分设备逻辑集中在一个核心实现文件中，而认证、端点构建和HTTP传输则被分解到一个小的支撑层中。本节总结了此结构。

该实现围绕两个内部数据结构展开：会话对象和作业对象。会话存储连接相关信息，包括认证参数、HTTP客户端、令牌管理器和API配置。它还保存选定的量子计算机标识符、活动校准集标识符以及在会话初始化期间缓存的元数据。作业对象存储对其所属会话的引用，以及提交的程序信息、特定于后端的执行选项、当前作业状态和缓存的结果数据。大多数QDMI调用在内部操作这两个对象。

支撑层被刻意保持小巧。令牌管理器解析凭证并提供用于向IQM Quantum服务器API发起所有请求的令牌。API配置模块将符号化的后端操作（例如静态架构查询、针对运行时可能变化的校准敏感值的动态架构查询、作业提交和结果检索）映射到具体的IQM Quantum服务器API路由。最后，HTTP传输在libcurl之上实现了一个简单的GET/POST接口，执行请求，并将HTTP响应转换为QDMI状态码。

整个架构的一个关键要求是，标准化绝不能以牺牲性能为代价。特别是，与直接调用供应商特定的IQM Quantum服务器API相比，它绝不能增加不必要的延迟。正如将在以下各节中清晰呈现的，QDMI API和IQM Quantum服务器API在功能上存在非常大的重叠。这使得QDMI实现能够成为围绕专有调用的薄封装，中间无需繁重处理，从而满足开销可忽略不计的要求。

02.会话引导与认证

QDMI的第一个基石和入口点是QDMI会话函数的实现。在此上下文中，会话代表与IQM Quantum服务器的认证连接加上一个已解析的目标后端。一个典型的会话设置工作流使用了所列的配置参数。会话配置接受一个基础端点、一个凭证源和一个可选的备份选择器。随后，初始化会话会触发API配置、HTTP客户端设置和令牌管理器的实例化。

首先，令牌管理器验证认证配置，并为后续所有对IQM Quantum服务器的API调用提供有效的令牌。其次，已认证的会话使用显式选择器（通过自定义QDMI参数）向IQM Quantum服务器查询目标后端，或者在未提供选择器时使用默认设备。第三，它检索初始的架构和质量元数据，并将标准化表示存储在会话状态中。

由于HPC系统严重依赖通过环境变量注入凭证，认证信息既可以显式地通过QDMI会话参数传递，也可以通过环境变量传递。因此，相同的代码可以在不同场景下无需更改地运行，例如在交互式终端中或作为Slurm批处理作业运行。

03.能力与校准查询

实现的第二个基石，也是调用方收集设备、站点和操作属性的主要机制，是查询函数。查询遵循严格的划分，将基本静态的架构数据与动态质量数据分开。静态属性包括设备拓扑、站点标识符和操作可用性。动态属性包括与校准相关的指标，如量子比特相干时间和门保真度指标。

这两类数据都被归一化为QDMI属性，因此上层永远不会直接解析供应商的载荷。归一化包括必要的单位和类型转换，以便QDMI调用方接收稳定且可比较的值。这是实践中最重要的可移植性优势之一：编译器、转换传递和调度器侧的检查可以在不同后端之间共享单一的查询格式。

示例2展示的过程说明了使用同一接口函数的两种查询模式。第一种模式用于大小预先未知的属性：调用方传递空指针和零大小以获取所需的缓冲区大小。然后第二次调用使用返回的大小来分配缓冲区并检索实际数据，在本例中，是一个站点（即量子比特）标识符的向量。最后的查询演示了通过单次调用获取特定站点的T1值来直接检索固定大小的属性。

对于静态元数据和运行时可能动态变化的校准信息，数据新鲜度的处理方式不同。静态数据在初始化期间加载一次，并且仅在会话重新初始化或切换到不同后端时重新加载。动态数据在会话初始化期间也会缓存，但可以通过启动校准作业来刷新。这避免了数据陈旧的问题，同时无需每次查询都产生昂贵的网络往返开销。

这种划分在面向批处理的HPC设置中可能很有用，例如，当通过调度器连续启动作业时。在多次作业运行期间不太可能更改的元数据可以缓存一次，而可能随时间漂移的值可以在每次执行后刷新。例如，如果更新的错误率表明某些量子比特的质量已经下降，后续作业可能需要绕过设备的这些部分进行重新路由，这反过来可能增加交换开销，从而影响运行时间。因此，动态查询使运行时成本更加可预测，并允许后续作业对相关的设备更新做出反应。

04.作业生命周期、状态映射与结果

最后，作业处理是实现的第三个基石。我们将专有的IQM Quantum服务器端点映射到标准化的QDMI作业函数。一个典型的作业生命周期包括：客户端创建作业句柄，指定程序和执行参数，并通过QDMI函数请求提交作业。在内部，这会触发设备状态更新和通过令牌管理器的认证，随后是对IQM Quantum服务器API的提交调用。后续的QDMI调用促进进度监控，并在达到终止状态后检索结果。

该实现将后端特定的状态值映射到QDMI作业状态。尽管由于IQM Quantum服务器API具有比QDMI更细粒度的状态值，一对一的映射并不总是可行，但可以实现语义一致的映射，这包括正常完成、取消和失败路径。

程序数据和执行选项通过类型化的QDMI作业参数传递。当需要后端特定选项时，它们通过扩展字段传递，而不是将专有结构泄露到上层。这保持了公共路径的整洁，同时仍然允许使用高级后端特性。

示例3展示了量子程序本身、其格式和测量次数通过标准化的QDMI参数传递。此外，QDMI设备实现支持IQM Quantum特定的执行选项，这些选项可以通过扩展字段附加。例如，客户端可以通过自定义参数请求预示模式，或者通过自定义参数指定逻辑到物理量子比特的映射。在提交期间，这些值随后被转换为IQM Quantum服务器API的相应字段。

此外，该实现同时支持阻塞式和轮询式两种使用方式。通过QDMI_device_job_wait()进行的阻塞调用在简单脚本中很方便，此时执行应暂停直至作业完成。相比之下，通过QDMI_device_job_check()进行的轮询在编排场景中更为有用，因为此类场景可能需要同时跟踪许多任务。在内部，两种操作遵循相同的状态检查路径：wait会重复调用check()，后者执行后端状态查询并将原生的IQM Quantum状态值映射到QDMI作业状态。

图1. 最小QDMI交互模式：设备、会话和作业生命周期。

值得注意的是，作业函数既支持电路执行作业，也支持校准作业（取决于指定的QDMI_PROGRAM_FORMAT），这些在后台被映射到不同的后端端点。

深圳市富临神通科技有限公司是IQM Quantum中国代理商，我们在量子技术领域拥有丰富经验。我们为客户提供：量子计算机。

结果检索既支持聚合的测量计数，也支持（如果可用）单次测量的数据。如果某个作业的测量数据已被获取，直方图计数将在本地生成，而无需发起额外的后端请求。对于校准作业，首次访问未缓存的结果时，会重新读取校准作业的状态，提取新的校准集标识符，将会话的动态架构和校准指标刷新至该校准集，或者如果首次尝试失败，则在120秒后重试一次刷新。

四、基于QDMI的HPC集成

有了可工作的设备实现后，问题转向：现有的HPC和量子软件层如何连接到QDMI？如图2所示，QDMI边界之上的一切，原则上都可以跨后端共享。边界之下的则保持供应商特定性。本节描述三个最具体现这种复用性的层面：语言绑定、面向Qiskit的前端适配器以及基于Slurm的调度器集成。

图2. QDMI作为标准化的软硬件边界，促进各类软件组件与不同硬件平台之间的交互。

01.语言互操作性

QDMI被定义为C接口，这使得从C和C++代码中调用它非常直接。然而，对于更高级的语言，直接的C互操作较为繁琐。因此，我们提供了地道的C++和Python绑定，这些绑定封装了C入口点，管理对象生命周期，并通过原生语言结构暴露QDMI会话、查询和作业。

C++层将QDMI句柄映射到RAII管理的对象，并在适当的地方将错误码转换为异常。Python层通过nanobind基于C++绑定构建。这些绑定并非IQM Quantum所独有。任何QDMI设备插件，无论供应商是谁，都可以通过相同的C++或Python API被加载和使用。在实践中，这意味着基于Python绑定编写的工作流代码，即使底层设备从IQM Quantum更换为不同的后端，也能正常工作。

图3. 显示IQM Quantum软件栈三个抽象层的高层架构图。量子电路从第1层以Qiskit代码形式提交至MQT Core，后者将电路转换为IQM JSON格式，并发送至基于IQM Quantum的QDMI实现。该实现与IQM Quantum服务器进行交互。

图4. IQM Quantum QDMI设备的实现架构。

02.前端集成：基于QDMI的Qiskit

Qiskit适配器基于Python绑定构建，并在QDMI之上实现Qiskit的BackendV2接口。具体来说，在转换过程中的属性查询、目标构建、电路提交和结果检索，都映射到QDMI的会话和作业调用，而非任何特定于供应商的客户端库。

图5. IQM Quantum QDMI设备会话设置序列及其与IQM Quantum服务器API的交互结果。

表I. QDMI入口点与IQM Quantum服务器API之间的功能映射

除了后端接口，适配器还提供了Qiskit基本抽象的SamplerV2和EstimatorV2实现。由于这两种基本功能都在内部委托给QDMI，它们适用于任何QDMI设备，而不仅仅是IQM Quantum硬件。从用户的角度看，Qiskit代码无需修改：电路通过常规的Qiskit工作流进行转换、执行和测量。不同之处在于，后端现在也可以是可通过QDMI连接的、HPC可访问的量子计算机，而不仅仅是供应商特定提供商包管理的云端点。

这种设计将适配器的维护集中在QDMI边界。没有它，每个硬件供应商都需要提供和维护自己的Qiskit提供器，并且每次Qiskit API变更都需要在这些提供器之间独立地传播。有了统一的面向QDMI的适配器，前端的演进和后端的演进被解耦。

图6. IQM Quantum QDMI设备的属性查询序列。

图7. IQM Quantum QDMI设备作业设置序列及其与IQM Quantum服务器API的交互结果。

03.调度器集成实践

从用户的角度来看，从交互式QDMI使用过渡到Slurm分派的执行几乎不需要修改。应用程序代码是相同的；只有启动方式不同。用户编写标准的sbatch脚本，应用程序内部的量子调用走的路径与交互式shell中相同，都经过QDMI会话和作业路径。

更有趣的设计问题在于运维侧：端点URL和凭证如何以及在哪里注入？我们考虑了两种方法。第一种是脚本级配置，即每个作业脚本显式设置所需的环境变量。这适用于探索性测试和初期接入。第二种是通过在Slurm序言中运行的SPANK插件进行集中注入。在此模式下，插件读取站点级配置文件，为分配的分区解析正确的IQM Quantum端点和令牌路径，并在用户应用程序启动前导出相应的环境变量。用户从不直接接触端点URL或凭证路径。

图8. 基于QDMI的Qiskit适配器框架。

图9. 启用QDMI执行的Slurm提交示例模式。

基于SPANK的方法有两个实际优点。首先，凭证轮换和端点变更成为运维层面的配置更新，而非面向用户的变更。其次，该插件可以强制执行站点策略，例如限制哪些分区可以访问哪些后端，或者在作业启动前验证令牌文件是否有效。这两点都减轻了为众多用户手动设置环境所带来的支持负担。同时，它的缺点在于依赖SPANK作为插件系统，这对于某些HPC中心来说可能难以采用。

图10. 基于相同QDMI集成路径所支持的部署场景。

图11. 简化的QSCI控制流，展示了执行模式的切换。offload和simulator标志是本地模拟、Slurm分派模拟、本地硬件和Slurm分派硬件执行之间唯一不同的参数。

图12. QSCI执行的端到端工作流示意图。数字表示工作流的操作顺序，在正文中已有说明。QDMI在步骤4和步骤5中促进通信。

提交脚本示例中，用户仅指定Slurm资源参数和应用程序命令；所有QDMI相关配置都自动注入。

五、部署场景与权衡

综观上一节所述的组件，无论中心如何部署其量子资源，用户代码和适配器逻辑都保持不变；只有端点和凭证配置发生变化。这种一致性是QDMI边界标准化的直接回报，也构成了我们在此评估的部署风格的动机。

01.云QPU

第一种风格是松散耦合：经典计算在标准环境中运行，而量子执行通过QDMI转发到远程（云）后端。这通常是快速入门的方式，对早期用户接入很有帮助。这种方法对于交互式开发仍然很有价值，允许终端用户设计硬件特定的算法，改进算法的编译和优化性能，并在投入生产前进行完整的流水线测试。

许多早期工作都遵循这种模式，但没有统一的资源编排。量子计算机通过云端访问，生成的数据被上传到另一个独立的HPC中心。在这种断连状态下运行迭代循环很困难，工作流通常是顺序执行的，而没有来自早期步骤的反馈。在实践中，这意味着要么在整个工作流持续时间内阻塞经典和量子资源，要么无限期地释放它们。对于量子计算机，释放资源意味着将作业返回到QPU内的通用队列中，从而增加实际耗时。

使用这种部署场景，允许用户保持对系统资源的完整内部责任归属和可追溯性。此外，利用现有的本地基础设施来对接本地或云量子资源具有成本效益，因为它避免了额外的授权软件层。在操作上，这种策略确保标准的集群工具仍然可用于故障排除，显著简化了用户支持。建立清晰的QDMI边界有助于完善互连接口。

02.本地QPU

第二种风格是在工作节点模式下与调度器管理的量子访问紧密耦合。用户保持在中心工作流内，通过与其他工作负载相同的调度和计费路径提交量子作业，并从其常规的HPC作业环境中提供所需的后端配置。这使得HPC中心可以共同调度经典和量子资源，减少稀缺QPU硬件的空闲时间。研究人员在实践中展示了这种风格：QPU在并行计算电子轨道分布的同时，经典节点计算新的变分参数，从而在不离开调度器的情况下闭环优化循环。

这种风格在运维上更繁重，需要分区配置、计费集成和凭证管理。然而，它最符合生产策略，并能支持松散耦合无法有效支持的迭代混合工作流。同时，由于系统正常运行所需的大部分组件已经是HPC中心的一部分，其结果是一个稳健的执行平台，QPU可以以最小的干扰接入。

这种模式适用于面向批处理的系统，并支持迭代混合作业，但协调多个HPC和量子资源的更复杂工作流可能需要更丰富的编排机制。

同样的调度器管理模式也是未来协调多个QPU或将多个经典和量子资源组合在一个编排层下的工作流的自然起点，尽管此类场景超出了本文的范围。

03.SPANK插件集成

第三种风格在紧密耦合的基础上，进一步扩展了调度器侧的自动化。如第四-C小节所述，SPANK插件在作业启动时注入配置并执行防护措施。通过依赖HPC中心已有的标准化自动化机制，这种方法将成熟的运维实践扩展到量子工作负载，而无需引入单独的控制路径。这消除了用户侧重复性的设置工作，使运维人员能够直接控制端点选择、凭证管理和访问策略，并使得将量子作业纳入现有的工作流管理器和站点编排工具变得更加容易。

这种调度器级别的自动化支持用户工作流扩展规模，同时保持运维人员对防护措施的控制，以确保共享系统的正确使用。因此，此能力支持无缝扩展到更多数量的本地量子计算机，支持经典节点与稀缺量子资源之间更高的并发性，并有助于实现更复杂的调度方法。

六、演示：端到端QSCI工作流

将量子与HPC资源结合的最有前景的近期待办工作流之一是量子选择配置相互作用方法。在量子化学背景下，QSCI通过使用量子样本来识别一个约化的配置子空间，然后在经典计算机上对角化相应的截断哈密顿量，从而近似多电子哈密顿量的低能谱。该工作流从分子问题定义开始，将二次量子化的哈密顿量映射到量子比特，准备一个参数化的尝试态，在模拟器或QPU上对其进行采样，选择与目标粒子数扇区一致的占优比特串配置，最后在经典资源上求解约化的本征问题。关键的要点在于，这一序列自然地分布在异构资源上：在登录节点上进行化学预处理和编排，在面向QPU的路径上进行量子执行，在经典计算节点上进行子空间构建和对角化。

因此，QSCI是展示QDMI所赋予工作流灵活性的一个自然用例，原因有二。首先，它结合了紧密耦合的经典和量子阶段，而非提交单个孤立的电路。在我们的实现中，初始态使用Hartree-Fock参考态和UCCSD拟设来制备，变分参数通过VQE进行优化，优化后的态被采样，并由此产生的计数驱动约化空间的对角化。这代表了与HPC中心相关的编排模式：量子步骤仅是更大工作流的一个组成部分，其控制逻辑、数据移动和后续处理仍然是经典的。

其次，同一工作流必须能够以多种执行环境为目标。在开发期间，用户希望在本地针对模拟器验证量子路径；在集成阶段，他们可能将相同的计算卸载到云QPU；在生产中，他们可能将其指向本地QPU端点。独立地，经典的后处理对于小分子可能保持在本地进行，对于更大的工作负载则分派到集群资源。QDMI使应用侧代码在很大程度上独立于这种部署模式。因此，算法代码和适配器连接可以在本地开发、调度执行和硬件支持运行中复用。

这使得我们演示的价值显而易见。我们并非旨在展示一个基准数字；相反，我们展示了一个统一的集成路径，该路径允许本地执行、Slurm分派执行和真实硬件访问的无缝集成。执行模式在应用程序代码中切换，而端点和凭证上下文在运行时通过后端配置和认证环境注入。在我们的实现中，此上下文包括IQM Quantum端点、认证令牌或令牌文件，以及一个可选的量子计算机选择器，但QSCI算法本身保持不变。

相关的QSCI使用示例中，卸载标志在本地执行和Slurm分派执行之间选择；模拟器标志在经典模拟器和真实QPU之间选择。VQE参数估计步骤和采样步骤都使用同一组标志，因此从本地模拟运行切换到Slurm分派的硬件运行，只需更改两个布尔参数，其他一切不变。算法代码、QDMI会话路径和适配器集成路径在所有四种配置中都完全相同。

我们的QSCI工作流步骤说明如下：

(1) 分子问题的构建，通常在登录节点上进行。对于QSCI工作流，这意味着构建问题并推导相应的量子比特哈密顿量。

(2) 构建参数化的输入态。在我们的实现中，这使用Hartree-Fock初始态和UCCSD拟设，然后进行VQE优化循环以获取电路参数。

(3) 如果启用了卸载，拟设和算子在共享存储上序列化，并通过Slurm提交到量子分区；否则，相同的逻辑在本地进程中执行。

(4) 在量子路径上，面向Qiskit的适配器调用基于QDMI的IQM Quantum设备，该设备根据运行时上下文将电路提交给模拟器或目标QPU。

(5) 优化的电路被采样，得到的比特串计数通过相同的适配器和调度器路径返回。

(6) 采样的配置定义了约化的QSCI基。经典后处理在该基中构建截断的哈密顿量，并在本地或通过Slurm分派的经典执行进行对角化。

(7) 近似的本征值和本征向量返回给工作流控制器。

(8) 应用程序将QSCI结果返回给用户，同时在所有部署模式下保持相同的执行契约。

在我们的设置中，经典准备工作在登录节点上用Python运行。量子执行请求通过面向Qiskit的适配器，进入QDMI绑定，经过基于IQM Quantum的QDMI设备，最后到达IQM Quantum后端。返回的结果沿相同路径返回应用程序，用于优化和后处理。因此，本节科学主张虽然有限，但对HPC实践很重要：并非此示例设定了化学基准，而是一个执行契约贯穿本地开发、调度器介导的执行和真实硬件访问，而无需重写应用级工作流。

七、结论

本文研究了一种围绕标准化设备管理边界构建的实用HPCQC集成路径。以IQM Quantum系统为真实硬件案例研究，我们实现了一个基于IQM Quantum的QDMI设备层，并将其连接到Slurm执行和面向Qiskit的前端工作流。该实现已公开提供。

核心结果简明扼要：当设备管理边界标准化后，该边界之上的软件可以在不同部署环境中复用。在我们的实现中，这包括语言绑定、面向Qiskit的适配器、Slurm集成模式以及相关的部署路径。

端到端的QSCI研究为此提供了实践证据。相同的应用侧路径被用于本地模拟、Slurm分派模拟、本地硬件访问和Slurm分派硬件访问；只有执行模式和备份配置发生了变化。因此，贡献并非化学性能结果，而是一个集成结果：一个接口边界可以支持多个执行上下文，而无需重写工作流。

这并未消除所有HPCQC集成工作。后端特定的载荷、校准行为和操作约束仍然存在。我们的结果更具体、更实用：这些差异可以被封装在设备管理边界内，而不会渗透到用户代码、前端工具和调度器集成中。

对于HPC中心，这提供了部署灵活性，而非单一规定模式：用于早期探索的云访问、用于工作节点模式的调度器管理本地访问，以及当需要更严格运维控制时的SPANK自动化访问。应用侧软件路径在这些选项中保持不变。

总体而言，该案例研究表明，设备管理标准化在生产硬件上已经可行，并且在日常集成工作中很有用。它为中心、供应商和软件维护者提供了一个共同的集成点，而不强制采用单一部署风格。未来的工作可以在此边界基础上，研究更广泛的调度策略和多资源编排。