量子模拟器困在HPC机房，HPC-vQPU把它放了出来

arXiv: 2605.28845 | 29页，5图 | Pawsey超算中心，Setonix，AMD MI250X，IBM Fez校准数据

一句话：HPC-vQPU把量子模拟器从批处理作业的牢笼里放了出来，让它像一个真正的QPU那样对外服务。

问题：连接性反转

HPC超算中心有GPU。量子模拟器需要GPU。但把两者拼在一起，卡住了。

HPC的接口是调度器导向的。用户提交作业脚本，排队等待，拿到节点，运行，退出。这套流程运行了半个世纪，成熟、安全、高效。问题是：量子软件想要的不是作业脚本。它想要一个QPU。一个可以submit、可以observe、可以query状态的设备。一个像IBM Quantum或AWS Braket那样，对开发者友好的API。

现有方案各自有缺口。云量子平台提供交互接口，但规模受限、成本高昂。通用科学网关只是把作业提交包装了一下，不处理设备校准、拓扑语义、门集合约束。而直接把量子软件塞进HPC批处理系统，意味着用户要手动处理队列、模块加载、环境隔离——每一次交互都变成一次作业提交。

更深层的障碍是安全。HPC计算节点是内部寻址的、调度分配的、短暂存在的。它们不能开入站端口。一个虚拟QPU服务如果要跨出HPC边界，必须面对一个残酷事实：没有外部连接可以连进来。所有协调只能是出站、由代理发起。

这就是论文定义的"连接性反转问题"（connectivity inversion）。不是把量子作业送进HPC，而是把HPC内部的量子模拟器，导出来。

双平面架构：控制平面与执行平面

HPC-vQPU的解法是一个刻意的不对称设计。两个平面，一条边界，全部出站。

外部客户端  ←→  控制平面（vqpu_server）
                      ↓  CLAIM/HEARTBEAT/REPORT（全部出站）
               HPC安全边界（禁止入站）
                      ↑
                执行平面（vqpu_agent）
                      ↓  调度器（Slurm/Dask）
                      ↓  计算节点（GPU模拟）

控制平面是云可见的。它说话的单位是设备、任务、生命周期状态、结果。它不认识分区、模块栈、批处理脚本。它用REST API接收任务，用SSE事件流推送状态。它是权威的真相来源：任务状态、设备快照、事件日志，都在这里。

执行平面在HPC登录节点上跑。一个非特权进程，vqpu_agent。它通过协议参与，不通过入站连接。它轮询控制平面，CLAIM任务，拿到所有权，然后把任务变成调度器作业。作业完成后，它解析结果工件，回报告终状态。

两个平面之间只有三个动词：CLAIM、HEARTBEAT、REPORT。没有回调。没有RPC。服务器不会调用代理。代理死了？心跳过期。服务器不会问"你怎么了"，它只会在心跳停掉之后，把任务标记为需要恢复。

核心抽象：设备快照作为不可变契约

HPC-vQPU中间最关键的东西，不是API，不是调度器适配器，而是一个数据结构：设备快照。

一个快照 Δ(𝒟, t) 包含：

• 耦合图 G = (Q, E)，有向，拓扑约束
• 原生门集合 G_native，可接受性验证
• 每个量子比特的 T1/T2 相干时间、单比特门误差 ε_1q、读出误差 r
• 每条边的双比特门误差 ε_ij 和门类型 g_ij
• 方向性：ε_ij ≠ ε_ji 允许非对称耦合

这不是元数据。这是执行契约。论文从IBM Fez的真实校准数据构建了一个156量子比特的虚拟设备 ibm-fez-0309，对照设备 ibm-fez-ideal（零误差）。两个设备拓扑相同、门集合相同、API路径相同。只有校准内容不同。跑出来的电路分布不同。总变差距离 TV = 0.03537。

快照绑定的时机是CLAIM时刻。提交时绑定太早，队列延迟期间设备可能变了。计算节点运行时绑定太晚，需要网络连接，违反密封性。代理CLAIM任务、获得所有权的那一瞬间，快照从控制平面冻结，随任务一起进入执行。

一个精巧的实验验证了这一点。8个任务提交到 ibm-fez-0309（含噪声）。提交后1.2秒，管理API把同一设备的所有噪声参数归零。如果绑定发生在提交时，输出应该带噪声。如果绑定发生在CLAIM时，输出应该纯净。结果是：8/8个任务返回 TV = 0，p(|00⟩) = 1.0。零噪声。CLAIM时绑定生效。

九项设计不变量

论文把这整个架构的形式化约束编码为九条设计不变量（D1-D9）。

D1 出站唯一：所有连接由代理发起。没有入站路径进入HPC。

D2 终端状态吸收：COMPLETED、FAILED、CANCELLED 是吸收态。一旦进入，不可转换。防止幽灵任务在不同状态间漂移。

D3 独占CLAIM：原子CLAIM建立唯一所有权。控制平面序列化竞争。多个代理同时CLAIM同一个任务，只有一个成功。

D4 非对称协调：心跳过期驱动故障检测，不是服务器回调。代理崩溃后，服务器不自动重排队——保持模糊性，等待显式恢复决策。

D5 快照不可变：CLAIM时绑定，计算节点执行密封。快照是契约，不是查询接口。

D6 拓扑参数化：可接受性验证在快照耦合图上做图参数化检查，不是字符串匹配。

D7 TTL缓存：设备快照在控制平面缓存，设备突变时失效。防止过时的快照被CLAIM。

D8 密封执行：计算节点无网络、无控制平面访问、无实时查询。输入(c_i, δ_i)，输出ρ_i，跑完就消失。

D9 服务端可观察：SSE事件流给外部客户端。仪表板跟踪进度，无需触及HPC域。

实验：Pawsey Setonix上的生产验证

环境：Pawsey超算中心，Setonix系统，AMD Instinct MI250X GPU，Qiskit-Aer + cuQuantum，IBM Fez 2026-03-09校准数据。不是模拟。是生产环境。

实验A：服务开销有界

随机原生门电路，28-32量子比特，1024 shots。端到端延迟分解为四个阶段：T_admit + T_queue-claim + T_exec + T_poll。

32量子比特时，T_exec = 23.77秒（指数增长，模拟器成本）。服务层开销（准入、所有权、快照处理、事件投影）占比3.7%。关键发现：模拟器的指数成本没有泄漏到服务层。服务层是常数时间的。

执行阶段内部，t_sim（GPU模拟）占主导，23.77秒。t_parse、t_noise、t_xpile（解析、噪声模型推导、转译）都是常数时间，与量子比特数无关。调度器集成、环境准备、快照序列化的开销，被严格隔离在模拟成本之外。

实验B：设备感知保真度

放大的双比特恒等电路，理想输出确定性 |00⟩。ibm-fez-ideal 只观察到 |00⟩。ibm-fez-0309（真实校准）平均 TV = 0.03537 ± 0.00171。概率质量集中在 |10⟩，与读出误差和边(0,1)上的校准双比特通道一致。快照不是装饰。

实验C：CLAIM时绑定

前述的"提交后归零"实验。8个任务，全部纯净输出。绑定时机被精确锁定在CLAIM时刻。

实验D：崩溃恢复

3个任务提交，代理CLAIM，然后杀掉代理进程。控制平面保持3个任务在RUNNING。不自动失败。不自动重排队。管理员对每个任务发出一次显式重新排队。重启代理。3/3完成。

论文强调：更激进的系统可以自动重排队，但那样会制造竞争执行谱系。如果原始调度器作业后来产出了结果，系统会面对两个可能的答案。HPC-vQPU选择保守：模糊性显式化，不自动解释。

噪声模型推导：一个容易被忽略的细节

从快照到模拟器噪声模型的推导，论文花了相当篇幅。三个通道：

1. 单比特去极化：每个物理单比特门附加，排除Rz/恒等/延迟等虚拟更新。参数 ε_1q(q_i)。
2. 对称读出：矩阵 [[1-r, r], [r, 1-r]]，r ∈ [0, 0.5] 保证有效随机算子。
3. 双比特去极化：边类型 g_ij 指定的门，方向性保持，ε_ij ≠ ε_ji 允许非对称。

关键对称性：控制平面模拟器（用于可接受性验证）和计算节点运行器（用于实际执行）使用完全相同的推导逻辑。这防止了一个微妙但致命的bug：任务在验证路径和执行路径上语义不一致。如果一个电路在控制平面被判定为合法，在计算节点上却因为噪声模型推导不同而被拒绝，整个契约就破裂了。

和现有工作的关系

云量子平台（IBM Quantum、AWS Braket）：提供交互API，但规模受限。HPC-vQPU提供相同抽象，但底层是HPC-scale GPU模拟器。

Qiskit Runtime：在经典侧做程序优化，但假设量子后端是远程可达的。HPC-vQPU面对的是HPC安全边界，没有这个假设。

量子模拟器（Qiskit-Aer、cuQuantum）：提供高性能模拟，但不提供设备导向服务抽象。HPC-vQPU在模拟器之上加了一层服务导出。

科学网关（JupyterHub、Open OnDemand）：提供交互入口，但不把设备校准、拓扑语义、门约束作为执行契约。HPC-vQPU的"设备快照"概念填补了这一步。

vQPU时间复用（Quantum Brilliance、Lagrange）：把物理QPU虚拟化给多个作业。HPC-vQPU做的是相反方向：把模拟器虚拟化成QPU，从HPC内部导出到外部。两者互补。前者解决"QPU不够用"，后者解决"模拟器出不来"。

为什么是Pawsey

Pawsey是澳大利亚国家级超算中心。Setonix是AMD GPU系统。选择这里不是偶然。论文需要证明三件事：

1. 真实HPC环境：不是实验室原型，是生产系统。有调度器、有队列、有安全策略。
2. GPU加速模拟：cuQuantum在AMD MI250X上跑。状态向量模拟的指数成本是真实的，但服务层开销不是。
3. 真实校准数据：IBM Fez的2026-03-09校准快照。不是理想噪声，是真实设备的不完美。

作者在论文中隐含的意思是：这个架构不是为理想世界设计的。它是为一个有真实约束、真实故障、真实队列延迟的世界设计的。

局限与开放问题

论文诚实列出了局限：

• 状态向量模拟的指数成本没有被隐藏。HPC-vQPU只是防止它泄漏到服务层。32量子比特以上，模拟时间本身会压垮一切。
• 故障恢复是保守的。显式管理重排队在自动化场景下可能不够。心跳过期后的自动恢复策略是未来工作。
• 调度器集成目前只做了Dask-backed Slurm适配。其他调度器（PBS、LSF、Kubernetes）需要额外适配器。
• 目前只验证了量子模拟器。物理QPU的集成——如果有物理量子计算机接入HPC——需要额外的工作（虽然架构原则不变）。

我的判断

这篇论文的价值不在于提出了一个多么惊世骇俗的算法。它解决的是一个工程问题，但这个问题卡住了量子-HPC融合整整一个阶段。

量子计算社区一直在两个世界之间徘徊：云端的小规模交互，和HPC上的大规模批处理。前者体验好但规模受限，后者规模大但体验差。HPC-vQPU不是妥协，而是重新划界：HPC继续做它擅长的事情（调度、隔离、GPU计算），但对外暴露的接口不再是"作业脚本"，而是"设备"。

这个思路可以迁移。不只是量子模拟器。任何HPC内部需要对外提供交互服务的资源——深度学习推理、科学可视化、数据查询——都面临相同的连接性反转问题。HPC-vQPU的架构原则（双平面、出站唯一、快照契约、密封执行）是通用的。

论文的实验规模不大（28-32量子比特，3个恢复任务）。但意义在于证明了"可行"。在Pawsey的生产环境里，一个外部用户可以通过REST API提交量子电路，通过SSE观察进度，拿到一个由真实校准数据驱动的、设备感知的模拟结果。HPC的安全边界没有因此被撕开任何一个入站端口。

这扇门一旦打开，量子软件生态就可以开始认真对待HPC-scale模拟器了。不是作为一次性作业，而是作为持续服务。

参考：Shusen Liu et al., "HPC-vQPU: A Service-Export Architecture for Virtual QPUs on Batch-Scheduled HPC Systems", arXiv:2605.28845 [cs.DC], 2026.

#量子计算 #HPC #超算 #Pawsey #Qiskit #cuQuantum #虚拟QPU #服务架构