3. Benchmark需求分析与指标设计

量子软件与硬件Benchmark工程的第一道分水岭，不是“跑什么测试”，而是“为谁、为什么场景、用什么指标判定合格”。同一个量子处理器，在化学模拟用户眼里可能因保真度不足而不可用，在组合优化用户眼里却可能因吞吐和成本合适而完全够用。因此，需求分析必须从用户场景出发，把模糊的“性能好”翻译成可测量、可验收、可复现的指标集合，最终形成需求规格说明书。

一、从用户场景到质量属性

需求分析的第一步是识别场景中的角色与任务。典型角色包括算法研究员、应用开发者、云平台运维者和采购决策者。算法研究员关心的是在给定量子体积下能否稳定跑通深层线路；应用开发者关心的是提交任务到拿到结果的端到端延迟；运维者关心的是多租户并发下的吞吐与能耗；采购者则关心单位量子体积的成本。把这些诉求抽象为质量属性，就得到吞吐、延迟、保真度、量子体积、能耗、成本六类核心指标。

需要强调的是，这些指标并非彼此独立。提高保真度往往需要更多校准与纠错资源，可能拉低吞吐、抬高能耗；追求低延迟可能牺牲批处理带来的吞吐收益。因此需求规格说明书必须记录指标之间的权衡关系，而不是简单罗列目标值。

二、六类指标的工程定义

吞吐（Throughput）：单位时间内成功完成的量子任务数或量子门操作数，常用单位是 tasks/s 或 CZ gates/s。定义时必须明确“成功”的判据，例如任务返回且结果通过后处理校验。示例：某云平台在 8 并发下测得 120 tasks/min，则吞吐为 2 tasks/s。

延迟（Latency）：从任务提交到结果可用的时间，可细分为排队延迟、编译延迟、执行延迟和读出延迟。对交互式用户，端到端 P95 延迟比平均值更有意义。

保真度（Fidelity）：实际量子操作与理想操作的接近程度，包括单比特门保真度、双比特门保真度、读出保真度和态制备保真度。常用随机基准测试（RB）或交叉熵基准测试（XEB）测量。示例：某设备单比特 RB 保真度 99.9%，双比特 CZ 保真度 99.2%。

量子体积（Quantum Volume, QV）：综合衡量量子处理器在宽度与深度上可执行的最大方形随机线路规模，QV = 2^n，n 为通过测试的最大量子比特数。它比单一保真度更能反映整机能力。

能耗（Energy）：完成一次基准任务所消耗的电能，单位可为 J/task 或 J/门操作。对稀释制冷机，应区分稳态功耗与任务增量功耗。

成本（Cost）：单位有效量子计算量的费用，例如 元/QV 或 元/千次双比特门。成本需与保真度、吞吐联合定义，否则低价低质没有意义。

三、指标设计中的关键约定

指标要可验收，必须约定测量条件。例如保真度是在 10 mK 温度、特定脉冲校准后、单次运行还是多次平均下测得；吞吐是在多少并发、多长任务队列下统计；能耗是否包含制冷机稳态功耗。缺少这些约定，不同团队测出的数字无法比较。

另一个约定是参照系。延迟从“任务提交”还是“编译开始”计时，结果差异很大。本文统一采用端到端口径：从用户调用 API 提交任务，到结果写入用户可读存储为止。若需切换为编译后口径，必须在文档中显式说明。

四、需求规格说明书示例

下面给出一份可直接参考填写的需求规格说明书片段，场景为“中等规模量子化学模拟云服务”。表中数值为教学示例假设，不是实测结果。

五、从需求到测试用例的衔接

需求规格说明书完成后，应能直接导出测试用例。例如“吞吐 ≥ 100 tasks/min”对应一条并发压测用例：固定 8 并发、提交 200 个标准任务、记录成功数与耗时；“双比特保真度 ≥ 99.0%”对应 RB 测试用例，指定量子比特对、脉冲参数和统计次数。这样，后续章节的基准测试脚本才有明确的输入与判定依据。

总结来看，本节的核心动作是：先锁定用户场景，再抽象质量属性，然后为每个属性定义可测量指标，记录指标间的权衡，最后落成带目标值、验收方法和复现条件的规格说明书。这份文档是后续所有基准测试、数据采集和结果判读的基准线。