3. 基准测试的指标体系设计

要比较两个量子纠错译码器,仅凭“哪个更快”或“哪个更准”是不够的。译码器在真实系统中的价值,取决于它在逻辑错误率、延迟、吞吐量和内存之间取得的平衡。本节将逐项定义这些指标的计算方法,并讨论它们之间无法回避的权衡关系。需要说明的是,本节出现的所有数值均为教学示例或合理假设,用于说明计算过程,并非实测结果。

逻辑错误率:以“每轮逻辑操作”为归一化基准

逻辑错误率(Logical Error Rate, LER)衡量译码后逻辑信息出错的概率。最直接的定义是:在固定码距 d、固定物理错误率 p 下,运行 N 次独立的记忆实验,每次实验包含 R 个纠错轮次,统计逻辑观测值发生翻转的次数 k,则单轮逻辑错误率为

p_L = 1 - (1 - k / N)^(1 / R)  ≈  k / (N · R)   (当 k/N 远小于 1 时)

这里必须强调归一化基准。若只报告“每次实验的错误率”而不说明轮数,不同实验之间无法比较。工程上更常用的是“每轮逻辑错误率”与“每逻辑量子比特每轮错误率”两种口径,前者用于评估单个逻辑比特的记忆质量,后者在多个逻辑比特并行时更公平。此外,统计置信区间不可省略:当 k 很小(例如 0 或个位数)时,点估计不可靠,应使用 Wilson 区间或 Clopper-Pearson 区间给出 95% 置信范围。示例:若 N = 10000、R = 20、k = 8,则 p_L ≈ 8 / 200000 = 4×10⁻⁵,但置信区间上界可能接近 8×10⁻⁵,报告时必须一并给出。

解码时间分布:均值之外必须看尾部

解码时间不能只报平均值。量子纠错要求译码在实时窗口内完成,而窗口由 syndrome 提取周期决定。若平均延迟为 1 μs 但 99.9 分位延迟达到 50 μs,系统仍会因超时产生“译码滞后”错误。因此应采集完整延迟分布,至少报告均值、中位数、P95、P99 与 P99.9。计算方法为:对每次译码调用记录起止时间戳,得到样本集合 {t_i},按升序排列后取对应分位点;均值用于评估稳态负载,尾部用于评估最坏情况风险。

尾部延迟的来源值得单独分析:它可能来自 syndrome 图中出现大分量(译码复杂度随分量规模增长)、匹配算法在稠密图上的回溯、或内存分配抖动。基准测试应设计“压力场景”,例如人为注入高密度错误事件,专门测量尾部行为,而不是只跑平均错误率下的随机样本。

吞吐量与内存占用

吞吐量定义为单位时间内完成的译码次数,常用“每秒译码次数”或“每微秒处理的 syndrome 比特数”表示。它与延迟不是倒数关系:流水线并行、批处理和多核调度可以让吞吐量远高于 1/均值延迟。测量时应明确并发度与批大小,否则数字不可复现。内存占用则需区分峰值与稳态:峰值决定硬件资源下限,稳态决定长期运行的占用。对基于匹配的译码器,内存通常与 syndrome 图规模、匹配表大小相关;对基于神经网络的译码器,则主要是模型权重与中间激活。建议用固定输入规模下的峰值 RSS 或显存占用作为报告口径。

译码器基准指标体系与权衡关系 逻辑错误率 LER 每轮归一化 + 置信区间 p_L ≈ k /(N·R) 越小越好 解码延迟分布 均值 / P95 / P99 / P99.9 尾部决定实时可行性 受 syndrome 规模影响 吞吐量 每秒译码次数 依赖并发度与批大小 ≠ 1 / 均值延迟 内存占用 峰值 / 稳态 匹配表、模型权重 决定硬件下限 核心权衡关系 精度 ↔ 延迟:更精确的译码(如更大匹配搜索范围、更复杂模型)通常增加单次译码时间,抬高尾部延迟。 延迟 ↔ 吞吐:批处理与流水线可提升吞吐,但会引入排队延迟,使 P99 变差;实时系统需限制批大小。 吞吐 ↔ 内存:更高并发与更大缓存提升吞吐,但峰值内存随之上升,可能超出硬件预算。 精度 ↔ 内存:查表式或大模型译码器精度高,但内存占用大;轻量译码器省内存,却可能牺牲 LER。 结论:基准报告应同时给出四项指标及其测试条件(码距、物理错误率、并发度、输入规模),单一数字不具可比性。

指标间的权衡:没有免费的午餐

上述四项指标并非彼此独立。最典型的权衡出现在精度与延迟之间:基于最小权匹配的译码器通过扩大搜索范围或引入更精细的边权来提高纠错能力,但匹配复杂度随 syndrome 图规模上升,尾部延迟随之恶化。反过来,为压低延迟而采用贪心近似,会在高错误率区域明显抬高逻辑错误率。

延迟与吞吐之间也存在结构性矛盾。批处理能把多次译码合并调度,提高单位时间处理量,但每个请求都要等待批次凑齐,排队延迟直接反映在 P99 上。对实时纠错而言,通常应限制批大小甚至禁用批处理,用吞吐换确定性。吞吐与内存同样耦合:更大的并发缓冲和缓存能提升吞吐,却抬高峰值内存,可能使译码器无法部署到靠近量子芯片的低温或边缘硬件上。

因此,基准测试的结论不应是“某译码器全面更优”,而应给出“在给定码距、物理错误率、延迟预算和内存预算下,哪一项指标成为瓶颈”。一个实用的做法是绘制帕累托前沿:以延迟预算为横轴、逻辑错误率为纵轴,把每个译码器配置画成一个点,落在前沿上的配置才是该预算下的合理选择。下表给出一个示例性的报告字段设计,便于复现与横向比较。

指标计算口径示例值(假设)必须附带的测试条件
逻辑错误率每轮归一化,含 95% 置信区间4.0×10⁻⁵ [2.1, 7.9]×10⁻⁵码距 d=5,物理错误率 p=0.1%,R=20 轮
解码延迟均值 / P95 / P99 / P99.91.2 / 3.5 / 9.8 / 42 μssyndrome 规模、压力场景注入方式
吞吐量每秒译码次数6.5×10⁵ 次/秒并发度 8,批大小 16
内存占用峰值 RSS / 显存峰值 380 MB,稳态 210 MB输入规模、是否含模型加载
报告逻辑错误率时,若 k 小于约 20,点估计的统计噪声很大,建议增加实验次数或直接报告置信区间上界,避免用“零错误”得出过于乐观的结论。
不要用平均延迟代替尾部延迟做实时性判断。译码超时错误往往由 P99.9 决定,而非均值;压力场景下的尾部测量应作为基准测试的固定环节。