📚 课程目录第2章量子云平台资源模型与抽象

2. 量子云平台资源模型与抽象

量子云平台要同时调度量子处理器、模拟器、经典计算资源、存储与网络资源，前提是先把这些异构资源统一建模。所谓资源模型，就是为每一类资源定义一组可描述、可查询、可比较、可调度的属性集合；而资源抽象，则是在模型之上屏蔽底层硬件差异，向上层任务编排暴露一致的接口。没有统一模型，调度器就无法判断“一个 27 比特超导处理器”和“一个 32 比特模拟器”谁更适合当前任务；没有统一抽象，用户提交的量子线路就无法在不同后端之间迁移。

四类资源的统一建模

量子云平台的资源可以划分为四类：量子处理器（QPU）、模拟器、经典计算资源、存储与网络资源。它们虽然物理形态不同，但都可以用“标识—能力—状态—约束”四个维度来描述。

量子处理器：核心属性包括量子比特数、拓扑连接图、原生门集合、单/双比特门保真度、读出保真度、相干时间（T1/T2）、最大线路深度、是否支持中电路测量与动态电路。
模拟器：核心属性包括可模拟的最大比特数、模拟方法（状态向量、张量网络、密度矩阵）、是否支持噪声模型、内存上限、并行加速方式（CPU/GPU）。
经典计算资源：核心属性包括 CPU 核数、GPU 型号与显存、可用内存、任务队列长度、单任务最大运行时长。
存储与网络资源：核心属性包括可用存储容量、读写带宽、量子任务结果回传延迟、与 QPU 控制系统的网络跳数。

以一台假想的超导量子处理器为例，其资源描述可以写成如下 JSON 片段。注意这里的数值是教学示例，用于说明字段结构，并非实测数据：

{
  "resource_id": "qpu_sc_27a",
  "type": "quantum_processor",
  "qubits": 27,
  "topology": "heavy_hex",
  "native_gates": ["rz", "sx", "x", "cx"],
  "fidelity": {
    "single_qubit": 0.9992,
    "two_qubit": 0.9871,
    "readout": 0.9760
  },
  "coherence": {"T1_us": 180, "T2_us": 120},
  "max_shots": 100000,
  "queue_depth": 12,
  "status": "online"
}

模拟器则可以用同一套字段框架描述，只是能力维度不同：

{
  "resource_id": "sim_sv_32g",
  "type": "simulator",
  "method": "state_vector",
  "max_qubits": 32,
  "memory_gb": 64,
  "noise_model": true,
  "gpu_accelerated": true,
  "queue_depth": 3,
  "status": "online"
}

统一建模的关键在于：调度器不需要知道底层是超导、离子阱还是光子，只需要读取 type、qubits、fidelity、queue_depth 等标准字段，就能完成资源筛选与排序。

资源描述标准与元数据管理

资源描述标准解决的是“字段怎么定义、单位怎么统一、版本怎么管理”的问题。实践中通常采用分层元数据：

标识元数据：资源 ID、类型、所属区域、供应商、版本号。
能力元数据：比特数、门集合、保真度、模拟方法、内存、GPU 型号。
状态元数据：在线/离线/维护、队列深度、当前负载、最近校准时间。
约束元数据：最大 shots、最大线路深度、单任务时长上限、访问权限。

元数据管理需要解决三个实际问题。第一是一致性：同一资源在不同服务中的描述必须一致，通常由中心化资源注册表维护，任何状态变更都通过注册表更新。第二是时效性：QPU 的保真度和队列深度会随时间变化，元数据必须带时间戳，调度器应优先使用最近校准的数据。第三是可扩展性：新类型资源（如量子退火器、量子网络节点）加入时，不应破坏已有字段结构，通常采用“核心字段 + 扩展字段”的方式，扩展字段放在 extra 对象中。

资源注册表是平台的事实来源。调度器、计费系统、监控面板都应从注册表读取资源描述，而不是各自维护一份副本，否则会出现“调度器认为 QPU 空闲、监控面板显示忙碌”的不一致。

从资源模型到任务编排

统一资源模型最终要服务于任务编排。一个量子任务提交后，编排器通常按以下逻辑选择资源：先按 type 过滤（需要真实量子效应则选 QPU，需要大量 shots 且线路较浅可考虑模拟器）；再按能力过滤（比特数是否足够、原生门是否覆盖线路中的门、拓扑是否匹配）；最后按状态排序（队列深度小、保真度高、最近校准时间新的资源优先）。

下面这张图展示了四类资源如何通过统一元数据模型汇聚到资源注册表，并由编排器统一消费。图中同时标出了每类资源的关键描述字段，便于对照理解。

从图中可以看到，四类资源虽然能力字段不同，但都收敛到同一套“标识—能力—状态—约束”模型，再统一注册到资源注册表。编排器只面向注册表编程，不直接接触任何硬件接口。这种分层带来的直接好处是：新增一类资源时，只需实现注册接口并填写标准字段，编排逻辑无需改动；替换某个 QPU 时，只需更新注册表中的描述，任务迁移和重调度自动生效。

实践中的关键检查点

在真实平台中落地资源模型时，有几个容易出问题的环节值得特别关注。第一，单位统一：相干时间用微秒还是纳秒、内存用 GB 还是 GiB、延迟用毫秒还是秒，必须在元数据规范中写死，否则调度器比较时会出错。第二，状态同步延迟：QPU 从 online 变为 maintenance 时，注册表更新与调度器读取之间可能存在窗口期，建议调度器在最终下发前做一次二次校验。第三，扩展字段的兼容性：extra 中的字段不应被核心调度逻辑依赖，否则新资源加入时会破坏旧调度器。第四，校准时间戳：保真度数据必须带 calibrated_at，调度器应设置一个新鲜度阈值（例如 24 小时），超过阈值的资源降权或排除。

不要把资源模型设计成“只描述当前硬件”的静态表。量子硬件迭代快，今天 27 比特、明天 127 比特，字段结构必须能容纳新能力而不破坏旧逻辑。核心字段保持稳定，新能力放入扩展字段，是更稳妥的做法。

总结来说，量子云平台的资源模型与抽象，本质上是把“量子处理器、模拟器、经典计算、存储网络”这四类异构资源，用统一的元数据语言描述出来，并通过资源注册表集中管理。资源描述标准保证字段一致、单位统一、版本可控；元数据管理保证状态新鲜、扩展安全、查询高效。只有做到这一点，上层的任务编排才能在不感知硬件细节的前提下，做出正确的资源选择与调度决策。