量子计算云平台性能测评：AWS与Azure实战对比

1. 量子计算实战：三大云平台三个月深度测评报告

作为量子计算领域的一线开发者，过去三个月我带领团队系统性地测试了AWS Braket和Azure Quantum两大云平台上的主流量子硬件。本文将分享我们在IonQ、Quantinuum等设备上运行5000+量子傅里叶变换(QFT)任务的第一手数据，揭示云量子服务的真实表现。

1.1 为什么需要这份测评？

当前量子计算生态存在严重的信息不对称：

• 厂商宣传的"理论性能"与实际使用体验差距巨大
• 不同云平台的工具链配置会显著影响算法执行效率
• 硬件保真度随时间波动的问题鲜少被公开讨论

我们采用统一测试框架(Qiskit+自建监控系统)，在完全相同的算法(QFT)和参数(500 shots)下，对比了不同硬件在8-25量子比特规模下的表现。所有测试均使用平台默认配置，模拟普通开发者的真实使用场景。

2. 测试环境与实验设计

2.1 硬件选型矩阵

我们在两大云平台上测试了四种量子处理器架构：

注：Rigetti的Ankaa-2因在测试期间退役，数据未纳入最终分析

2.2 测试算法设计

选择量子傅里叶变换(QFT)作为基准算法的三大理由：

1. 算法复杂度适中：包含单/双量子比特门操作，能全面测试硬件基础性能
2. 验证需求明确：可通过逆QFT验证结果正确性
3. 实际应用广泛：是Shor算法等量子优势算法的核心组件

测试电路的具体构建步骤：

from qiskit import QuantumCircuit from qiskit.circuit.library import QFT # 构建测试电路 def build_qft_test(n_qubits): qc = QuantumCircuit(n_qubits) # 随机数初始化 from random import randint num = randint(0, 2**n_qubits-1) for i in range(n_qubits): if (num >> i) & 1: qc.x(i) # 添加QFT和逆QFT qc.compose(QFT(n_qubits), inplace=True) qc.compose(QFT(n_qubits, inverse=True), inplace=True) return qc

2.3 数据采集系统架构

为保障测试一致性，我们开发了自动化测试平台：

[本地开发机] │ ├─ [任务调度器] → 提交作业到AWS/Azure API │ │ │ ├─ [量子硬件] → 原始结果 │ └─ [经典模拟器] → 理想结果 │ └─ [MongoDB] ←─ [结果分析器] 存储所有元数据： - 队列等待时间 - 实际执行耗时 - 门操作计数 - 保真度计算

系统每天自动：

1. 在每台可用设备上提交8-25量子比特(步长2)的QFT任务
2. 每任务执行500次测量(shots)
3. 记录完整的运行时指标

3. 平台差异导致的性能陷阱

3.1 量子门集配置的致命影响

在测试中我们发现，同样的IonQ Aria-1硬件，通过AWS和Azure访问时表现出截然不同的性能：

问题根源在于AWS Braket使用了非最优的量子门集进行电路编译(transpile)，导致：

1. 双量子比特门数量增加3倍
2. 可执行电路规模严重受限
3. 保真度波动范围增大

3.2 队列管理的透明度问题

量子硬件作为稀缺资源，任务排队是常态。但不同平台的管理策略差异显著：

Azure Quantum：

• 仅提供平均等待时间预估
• 36%的情况高估实际等待时间
• 无法查看队列位置

AWS Braket：

• 显示当前队列位置
• 区分普通/优先队列
• 但数据仅包含AWS用户提交的任务

实测队列等待时间分布：

[IonQ Aria-1] │ 50%任务: <2小时 │ 90%任务: <8小时 └─ 最长记录: 37小时 [Quantinuum H1-1] │ 固定执行时段(MT 17:00-02:00) └─ 非执行时段可提交但暂不处理

4. 硬件性能深度解析

4.1 保真度随规模衰减曲线

通过改变QFT的量子比特数，我们测量了各设备的保真度衰减情况：

关键发现：

1. Quantinuum表现最优异：

   • H2-1在25-qubit时仍保持0.5+保真度
   • 误差增长斜率最平缓

2. IonQ Forte的意外表现：

   • 虽然量子比特数更多(36 vs 25)
   • 但20-qubit时保真度已低于0.4
   • 可能因新机型校准不足

3. 模拟器与实机差距：

   • IonQ模拟器初期低估保真度达80%
   • Quantinuum模拟误差始终<5%

4.2 双量子比特门误差分析

量子计算的主要误差来源是双量子比特门。我们通过指数衰减模型拟合：

保真度 F ≈ (F_2q)^(n_2q) 其中： F_2q = 双量子比特门保真度 n_2q = 电路中的双门数量

测得各硬件的双门保真度：

注：Forte因数据不足未纳入本项分析

5. 成本模型与性价比分析

5.1 三大定价策略对比

AWS Braket（按任务+测量计费）：

cost = (n_tasks * $0.3) + (n_shots * per_shot_price) # IonQ Aria-1: $0.03/shot # Quantinuum: 不提供

Azure Quantum（按门操作计费）：

cost = (n_1q_gates * $0.00022) + (n_2q_gates * $0.000975) * shots # 有最低消费限制($12.42起)

Quantinuum订阅制：

HQC = 5 + shots * (n_gates + 5*n_qubits)/5000 # 每月$185k=17k HQC(硬件)+170k HQC(模拟器)

5.2 典型任务成本对比

执行10-qubit QFT 500 shots的成本：

成本差异主要来自：

1. AWS固定费率 vs Azure按门计费
2. Quantinuum的高精度硬件成本

6. 给量子开发者的实操建议

6.1 平台选择策略

根据我们的实测经验：

• 短期实验：用AWS Braket + IonQ组合

  • 低成本快速验证想法
  • 但注意16-qubit的限制

• 生产级应用：Azure + Quantinuum

  • 为高保真度付出合理溢价
  • 订阅制适合高频用户

• 算法开发阶段：

  # 强制使用模拟器调试 from qiskit import Aer backend = Aer.get_backend('qasm_simulator')

6.2 避坑指南

1. 门集验证：

   # 检查实际使用的门集 transpiled_circuit = transpile(qc, backend=backend) print(transpiled_circuit.count_ops())

2. 成本控制技巧：

   • 先在小规模模拟器验证
   • 设置云服务预算告警
   • 错峰提交任务(避开北美工作时间)

3. 结果可靠性检查：

   from qiskit.quantum_info import hellinger_fidelity # 对比实测与理想结果的Hellinger保真度

7. 量子计算的现实与未来

经过三个月的密集测试，我们对当前云量子计算的成熟度有了更清醒的认识：

已实现的突破：

• 通过云服务稳定访问多种量子硬件
• 25+量子比特算法已可执行
• 部分硬件的双门保真度>99%

现存挑战：

1. 工具链不成熟（如AWS的transpiler问题）
2. 硬件稳定性不足（保真度波动明显）
3. 成本模型不透明（尤其订阅制）

我们开源了测试框架的核心模块，欢迎社区共同完善：

quantum-benchmark/ ├── job_submitter.py # 多平台任务提交 ├── result_analyzer/ # 保真度计算工具 └── cost_calculator/ # 跨平台成本分析

期待未来能在误差缓解、混合量子-经典算法等方向继续探索，让量子计算真正走出实验室，解决实际问题。