qalgora-Q Docs Hub量子文档 ✦ Ask AI✦ 问问文档

Quantum Hardware (QPUs)

◐ Design-level API
This page documents qalgora-Q API design, architecture, or adaptation workflows. Code examples illustrate intended usage and are not guaranteed to run in the current reference implementation.

qalgora-Q documents the major hardware modalities and their intended target interfaces. The open reference build runs locally and does not natively connect to or submit to physical QPUs; real execution requires the corresponding vendor SDK, a cloud platform, or an adaptation plugin.

Modalities

ModalityStrengthsProviders
Ion trapAll-to-all connectivity, high fidelityIonQ, Quantinuum
SuperconductingFast gates, fixed coupling mapIBM, Google, Rigetti, IQM, Origin, Tianyan
Neutral atomLarge atom arrays, analog modeQuEra, Pasqal
PhotonicSampling / photonic tasksJiuzhang, TuringQ, ORCA

Neutral-atom (analog mode) and photonic (sampling) devices are not equivalent to the ordinary gate model — they run a different computational model and are not drop-in gate-circuit targets.

What differs between devices

PropertyWhy it matters
Native gate setYour gates are transpiled into the device's basis (e.g. ion traps favor MS/Rz, superconducting CZ/√X)
ConnectivityAll-to-all (ion trap) needs no routing; a fixed coupling map (superconducting) inserts SWAPs
Coherence & fidelitySets how deep a circuit stays meaningful before noise dominates
Mid-circuit measurementRequired for error correction and adaptive circuits — strong on ion traps

Targeting a device

Pick the target by name; the device-specific machine id selects the exact processor. Credentials come from environment variables, and jobs queue remotely — use the async API.

import qalgora
# Planned remote submission — not runnable in the CPU-only reference build:
# export the provider token first, e.g. QALGORA_QUANTINUUM_TOKEN
# qalgora.set_target("quantinuum", machine="H2-1")
# job = qalgora.sample_async(bell, shots_count=2000)   # queued remotely
# print(job.status())
# counts = job.get()
Reference build runs locally — not real hardware
This example targets a remote cloud/QPU, but the open reference build does not submit to a real machine — it warns and falls back to the local CPU statevector simulator, returning simulated results. Submitting to an actual device (e.g. 天衍/TianYan, IBM, IonQ, Origin) requires the vendor’s own SDK and credentials.

Provider targets

ModalityProvider · example targetNotes
Ion trapIonQ "ionq", Quantinuum "quantinuum"All-to-all, high 2-qubit fidelity
SuperconductingIQM "iqm", OQC, QCI, Anyon, Rigetti (via broker)Fast gates, fixed coupling map
Neutral atomPasqal "pasqal", QuEra "quera", InfleqtionHundreds of atoms, analog modes
PhotonicORCA "orca"Room-temperature, GBS workloads

Beyond QPUs, quantum control systems such as Quantum Machines (OPX) are addressed through the real-time stack rather than as a sampling target — qalgora-Q dispatches pulses and reads measurements inside the coherence window for feedback and error-correction loops.

Checking what a target supports

target = qalgora.get_target()
print(target.num_qubits, target.native_gates, target.connectivity)
Specification API — not in the open reference build yet
This example shows a qalgora-Q specification API (or a third-party library) that the open reference build does not bundle today. It documents the intended interface; to run code now, use the reference build’s supported core API.
Portability
The same kernel source can be reused across simulators and device targets — you change the target name rather than rewriting the kernel — but moving to a real device still goes through hardware-specific compilation, not a zero-change port. Transpilation maps your circuit to each device's native gate set and connectivity, and compile-time checks flag gates a given device cannot run natively. Note that direct native submission to physical QPUs is not built in. See Transpilation and the backend selector.
In the current reference build, hardware target names do not imply native submission. Use vendor SDKs or cloud workflows for actual QPU execution.

量子硬件(QPU)

◐ 设计接口
本页描述的是 qalgora-Q 的接口设计、架构设计或适配工作流。相关代码用于说明预期用法,当前参考实现不保证可以直接运行。

qalgora-Q 记录的是各主流技术路线及其预期的目标后端接口;开放参考实现在本地运行,不会原生连接或提交物理 QPU,真机执行需相应厂商 SDK 云平台或适配插件。

技术路线

技术路线优势服务商
离子阱全连接,高保真度IonQ, Quantinuum
超导门速快,固定耦合图IBM, Google, Rigetti, IQM, 本源(Origin), 天衍(Tianyan)
中性原子大规模原子阵列,模拟(analog)模式QuEra, Pasqal
光子采样 / 光子任务九章(Jiuzhang), 图灵量子(TuringQ), ORCA

中性原子(模拟模式)与光子(采样)设备并不等同于常规门模型——它们运行的是另一种计算模型,并非可直接替换的门线路目标。

设备间的差异

属性重要性说明
原生门集合你的门操作会被转译为设备的基门(例如离子阱偏好 MS/Rz,超导偏好 CZ/√X)
连通性全连接(离子阱)无需布线;固定耦合图(超导)则需插入 SWAP
相干性与保真度决定线路在噪声主导前能保持有效的深度上限
线路中测量纠错与自适应线路的必备能力——离子阱在此方面表现突出

指定目标设备

通过名称选择目标后端,机器标识用于指定具体处理器。凭据从环境变量中读取,任务远程排队执行——请使用异步 API。

import qalgora
# 规划中的远程提交 当前 CPU-only 参考实现不可运行:
# export the provider token first, e.g. QALGORA_QUANTINUUM_TOKEN
# qalgora.set_target("quantinuum", machine="H2-1")
# job = qalgora.sample_async(bell, shots_count=2000)   # queued remotely
# print(job.status())
# counts = job.get()
参考实现仅本地运行 · 非真机
此示例虽指向远程云端/QPU,但开放参考实现不会真正提交到真机 —— 它会给出告警并回退到本地 CPU 态矢量模拟器,返回模拟结果,不会真正提交到天衍等真机。真正提交真机需使用对应厂商的 SDK 与凭证。

服务商目标后端

技术路线服务商 · 示例目标后端备注
离子阱IonQ "ionq", Quantinuum "quantinuum"全连接,双比特保真度高
超导IQM "iqm", OQC, QCI, Anyon, Rigetti(经由 broker)门速快,固定耦合图
中性原子Pasqal "pasqal", QuEra "quera", Infleqtion支持数百原子,具备模拟模式
光子ORCA "orca"室温运行,适合 GBS 负载

除 QPU 之外,量子控制系统(如 Quantum Machines OPX)是通过实时栈来对接的,而非作为采样目标后端——qalgora-Q 在相干窗口内下发脉冲并读取测量结果,用于反馈控制与纠错回路。

查询目标后端能力

target = qalgora.get_target()
print(target.num_qubits, target.native_gates, target.connectivity)
规范接口 · 参考实现暂未包含
此示例展示的是 qalgora-Q 规范中的接口(或第三方库),开放参考实现目前尚未内置,仅用于说明预期用法;如需立即运行,请使用参考实现已支持的核心 API。
可移植性
同一份内核源码可在模拟器与不同设备目标之间复用——你改的是目标后端名称,而不必重写内核;但要落到真实设备上,仍需经过针对硬件的编译,并非零改动直接迁移。转译会将线路映射到各设备的原生门集合与连通性,编译期检查会标记指定设备无法原生执行的门操作。需注意,平台不内置直连真实 QPU 的原生提交能力。详见 转译后端选择器
在当前参考实现中,硬件 target 名称不代表已支持原生真机提交;实际 QPU 执行需通过厂商 SDK 或云平台流程完成。