量子云服务：IBM Quantum、AWS Braket、Azure Quantum 与作业调度

- 超导量子计算机：需 mK 级低温（稀释制冷机），体积/功耗巨大
- 捕获离子：激光系统复杂，也要真空与稳定环境
- 运维：专业团队、校准周期、故障恢复
→ 只有极少数机构自建，绝大多数「按需租用」

- 按需访问：不用买，用多少付多少
- 远程迭代：开发在本地模拟，提交到云端真机
- 共享校准：硬件商负责校准/维护，用户只关心结果
- 生态集成：与经典云服务（存储/计算/AI）无缝衔接

经典侧（本地/云 VM）：
  组装电路 → 转译 → 提交 → 收集结果 → 优化
量子侧（云端 QPU）：
  排队 → 执行 → 返回测量统计
→ 与「云函数」模式类比：你的代码 → 远程执行 → 拿结果

1. 硬件即服务（HaaS）：直接访问物理 QPU
2. 平台即服务（PaaS）：模拟器/编译器/调度/误差缓解全套
→ 现代平台都做「PaaS 优先」，HaaS 是底层

产品形态：
  - IBM Quantum Platform（web 控制台 + API）
  - IBM Quantum Composer（可视化搭电路）
  - IBM Quantum Lab（Jupyter 云端）
  - IBM Quantum Runtime（执行服务，含误差缓解）
  - Qiskit SDK（本地开发 → 云端提交）

- 硬件优先：自家超导 QPU 最多（公开/预留/私有）
- Runtime 执行：电路 + 经典循环在「会话（Session）」内连续运行
  → 变分算法不需要「来回传电路」（延迟优化）
- 误差缓解内置：分级缓解（ZNE/态校准）在服务侧
- 生态锁定：Qiskit 是主要接口（其他 SDK 也可用）

- 公开队列：免费 token 可访问（限额）
- 付费计划：预留容量、优先排队、私有集群
- 企业/研究：按需开通更高配额
→ 免费层适合学习/验证，生产需付费

- Qiskit 用户、想跑真实超导 QPU
- 需要「执行服务」（Runtime/Session）做变分算法
- 在 IBM 生态内做端到端量子开发

产品形态：
  - Braket SDK（Python）
  - 统一接口访问多家 QPU（IonQ/Quantinuum/Rigetti/Amazon IQ...）
  - 与 AWS 生态集成（S3/SageMaker/EC2）
  - 云端模拟器（SV1 等）
  - Hybrid Jobs（托管作业：经典+量子混合跑在 AWS 上）

- 统一接口：同一套 API 接多家硬件（可移植性）
- 云原生：提交/存储/计费全走 AWS（IAM/S3/CloudWatch）
- Hybrid Jobs：把经典循环也托管（代码 + 电路一起提交）
- 弹性：模拟器无限扩容（按用量），真机按需
- 无硬件绑定：选 IonQ/Quantinuum 由你定

- AWS 账户即可用（按用量计费，无独立订阅）
- QPU 有各自的排队与价格（Braket 统一界面）
- 预留容量：对热门的 QPU 可预订
→ 标准 AWS 计费模式（pay-as-you-go）

- 已在 AWS 生态、想统一管理量子与经典资源
- 想「一个接口试多家硬件」做对比
- 需要托管混合作业（变分/误差缓解的经典循环）

产品形态：
  - Azure Quantum 门户（网页 + API）
  - Q#（语言）+ QDK（开发套件）
  - 多家 QPU：Quantinuum/IonQ/Rigetti/（Azure 自家拓扑在研）
  - 云端模拟器 + 资源估算器（Resource Estimator）
  - 集成 Azure（身份/存储/日志）

- Q# 生态：类型安全语言 + Python 互操作
- 资源估算器：提交算法（不需要真跑）→ 估算物理资源
  → 帮「还没硬件」时就规划算法成本
- 多供应商：同一服务接多家硬件
- 微软路线：赌拓扑量子比特（长期，与码层不同）

- Azure 订阅 + 量子工作区（Quantum Workspace）
- 按用量计费（每家硬件各自定价）
- 资源估算器相对便宜（不跑真机）
→ Azure 标准计费 + 量子工作区管理

- Q# 用户、微软云生态
- 想做「算法资源预估算」的规划
- 需要「多供应商 + 云服务」组合

产品形态：
  - 自有超导硬件（Sycamore 系列）
  - Cirq 生态（SDK）+ qsim 模拟器
  - 通过云平台提供（与 AWS/GCP 合作）
  - 更多是「研究访问」而非大众商业服务

- 领先实验：纠错里程碑（distance 扩展）、随机电路采样（2023+）
- 硬件 + 研究深度耦合：优先内部算法/物理验证
- Cirq/qsim：研究者友好（精细电路控制）
- 开放模式：部分成果开源/与学术合作
- 访问门槛：多面向研究合作，非「自助开通」

- IBM：产品化最强（免费层 + 付费计划）
- AWS：云原生最中立（聚合多家）
- Azure：服务层最完整（资源估算 + Q#）
- Google：研究最前沿（但商业服务最薄）
→ 选 Google 的场景：前沿研究、需要 Google 硬件/算法合作

- 优先「量子优势」证明（纠错 + 实用问题）
- 硬件推进：大码距表面码 + 拓扑整合
- 生态：开源 Cirq/qsim/OpenFermion（贡献研究社区）
- 商业服务：通过合作渠道，非独立 PaaS 主打

- QPU 是「串行执行器」：一次只跑一个作业（大多数）
- 硬件维护/校准/冷却时间 → 可用窗口有限
- 多人共享同一台 QPU（公开队列）
→ 提交 ≠ 立即执行，先排队

- 提交（API）→ 校验/转译 → 排队（per-QPU）→ 执行 → 返回
- 优先级：付费计划 > 免费；预留 > 公开
- 队列可见：可查询当前队列位置/预计等待
- 超时：作业超时自动取消（配额保护）

- 选「冷门」时段/硬件（队列短）
- 用预留容量（提前订时段）
- 合并电路（批处理：一个作业跑多个电路）
- Session：保持「连续队列位置」避免多次排队
→ 调度策略直接影响「实验吞吐」

- 变分算法需要多轮迭代 → 每轮都排队会爆炸
- 解决方案：Session/Runtime（保持连接连续执行）
- 或：本地模拟多轮 → 只最后真机验证
→ 作业调度设计 = 与「量子预算」的博弈

公开队列（Open/Public）：
  - 任何人按配额访问
  - 排队时间长、无优先权
  - 适合学习/验证/低吞吐
  - 通常免费或低价

预留容量（Reserved/Dedicated）：
  - 提前预订一段时间（小时/天）
  - 期间独占或高优先访问
  - 适合生产实验/时间敏感作业
  - 付费（按时段计费）

私有集群（Private cluster）：
  - 独占一台 QPU（长期）
  - 完全可控（调度/校准/集成）
  - 适合企业核心业务/大规模研发
  - 最贵，需商务谈判

阶段 1（学习）：公开队列，免费 token
阶段 2（验证）：预留时段，有限预算
阶段 3（生产）：私有集群/长期预留
→ 随吞吐与可靠性需求升级访问层级

- 公开：随时可试，但结果不稳定（排队/校准波动）
- 预留：可规划，但需提前预订（灵活性低）
- 私有：最稳，但成本与运维负担最高
→ 把「核心实验」放预留/私有，「探索实验」放公开

- 电路：要执行的量子电路（列表）
- shots：每个电路采样多少次（统计精度）
- 后端：目标 QPU/模拟器
- 优化等级：转译优化强度
- 测量缓解：是否开启误差缓解

- 期望值精度 ∝ 1/√shots（统计噪声）
- shots 越多越贵/越慢 → 平衡「精度 vs 预算」
- 常见策略：先低 shots 快速探索，后高 shots 确认
- 自适应 shots：根据方差动态调
→ shots 预算 = 量子实验的「采样成本」

- 一次作业提交多个电路 → 在队列中「连续执行」
- 比多次单独提交快（只排一次队）
- 变分算法的多参数评估 → 打包成批
- 注意：批内电路共享同一校准状态（一致性更好）

- 保持「优先队列位置」的连续执行窗口
- 变分循环：每轮迭代不用重新排队
- 适合：需要多轮「电路→结果→优化」的算法
- Runtime/Hybrid Jobs 都基于 Session 模型

- 查询作业状态（queued/running/done/failed）
- 结果统计：counts / 期望值 / 退位
- 失败排查：转译错误、配额超限、超时
- 日志与追踪：云端作业的完整链路

- 按用量（按秒/按时段）：QPU 执行时间
- 按 shots：部分平台按采样次数计价
- 按时段：预留容量的时间费
- 模拟器：按 CPU/内存/时间（AWS 计费）
- 附加服务：误差缓解/资源估算的用量

- IBM：免费 token（限额 shots/时长）
- AWS：免费额度（新账户模拟器 + 少量 QPU）
- Azure：有免费额度的试用
- Google：研究合作模式（非自助免费层）
→ 学习期「零成本」可行，生产全成本

- 并发作业数：同时排队的作业上限
- 每月 shots/时长：免费层硬限制
- 单作业大小：电路宽度/深度上限
- 超时限制：作业最长执行时间
→ 配额决定「一次能跑多少」，预算决定「总成本」

- 本地模拟先行（免费迭代），真机只做关键验证
- 低 shots 探索 → 高 shots 确认（避免浪费）
- 批处理合并（减少排队空闲计费）
- 监控用量：平台 dashboard 追踪消费
- 预留 vs 公开：按「等待容忍度」选
→ 量子云成本 = 「真机时间」× 单价 + 「模拟」× 单价

云端模拟器：
  - 大规模状态向量模拟（超出本机内存）
  - 噪声模拟（模拟真机错误行为）
  - 弹性扩容：按需租用（AWS/IBM 都提供）
  → 用途：验证电路、调试、误差缓解基准

误差缓解服务：
  - ZNE/态校准/测量校准（服务侧内置）
  - 与执行服务耦合（Runtime）
  → 用户「一键开缓解」，不用自己实现

混合执行服务：
  - Session/Runtime/Hybrid Jobs：经典+量子统一执行
  - 变分算法/ML 训练的全托管
  → 从「提交电路」进化到「提交算法」

- 本地：免费、快（小规模）、私有
- 云端：大规模（数百比特）、噪声模拟、弹性
- 策略：本地小验证 → 云端大验证 → 真机采样
→ 模拟器是「量子开发的 CI 环境」

- 云侧缓解：硬件校准数据 + 服务算法
- 用户侧缓解：结果后处理（PEC/ZNE 实现）
- 混合：云提供「缓解后的结果」
→ 现代平台把缓解「产品化」，用户侧工作减少

- 从「电路提交」到「算法提交」（Hybrid Jobs）
- 从「原始结果」到「缓解后结果」
- 从「单机」到「经典-量子资源编排」
→ 云量子正在变成「量子计算即服务（QCaaS）」

1. 本地开发（免费）：
   Qiskit/Cirq/PennyLane + 本地模拟器
   → 快速迭代、验证逻辑
2. 云端验证（小成本）：
   提交到云端模拟器（噪声/大比特）
   → 确认电路在「现实模型」下行为
3. 真机采样（关键验证）：
   提交到 QPU（预留时段优先）
   → 得到真实硬件结果
4. 结果后处理：
   误差缓解 + 经典优化
→ 每层都「最省钱地」验证后再升级

- 排队时间比执行时间长（规划「并行提交」）
- 校准漂移：不同时段的 QPU 错误率不同（记录元数据）
- 配额/费用意外：先设预算上限/监控
- 结果非确定：同电路多跑取统计（噪声）
→ 工程纪律 = 元数据 + 预算 + 统计分析

- 团队先统一 SDK 与作业模板（可移植性）
- 建立「量子资源预算」流程（配额/成本审批）
- 结果可复现：记录电路/后端/校准/时间戳
- 与云供应商保持技术对接（新硬件/新服务）
→ 云量子开发 = 经典工程方法 + 量子特殊性