DevQ：开源量子运行时，让量子计算执行层透明可复现

量子计算的"黑箱"困境

量子计算正被寄予颠覆性期望，但一个鲜少被公开讨论的问题是：主流商业量子运行时（quantum runtime）本质上是一个不透明的黑箱。所谓量子运行时，是指从用户提交量子电路到最终返回测量结果之间的整个软件执行层——它涵盖了量子电路的编译优化（将抽象门操作转化为硬件支持的原生门集）、量子比特映射（将逻辑量子比特分配到物理量子比特上）、电路调度（决定任务执行的优先级和时序）、以及错误缓解策略的应用等关键环节。在IBM的Qiskit Runtime或Google的Cirq执行环境中，这些步骤通常作为云端服务的一部分自动完成，用户仅能通过有限的参数接口进行配置。

你提交一个量子电路，拿到结果，而中间发生的一切——哪些物理量子比特被选中执行、为什么是这些比特、做了怎样的错误权衡、任务如何被调度——全部发生在一个无法窥探、也无法修改的封闭系统内部。

近日，一位开发者在 Reddit 上分享了他的开源项目 DevQ，正是针对这一痛点而生。用他的话说："对于一个本应践行科学精神的领域来说，这种不透明性一直让我觉得是本末倒置。"科学的核心在于可复现、可验证，而当关键决策被隐藏在 API 边界之后时，一次实验结果究竟是可靠的结论，还是仅仅是一则无法复现的"轶事"？

DevQ 核心理念：运行时决策完全对开发者开放

DevQ 是一个采用 Apache-2.0 许可证的开源量子执行层，其设计目标就是彻底的"开放"。作者特别强调，这里的"开放"不是那种"客户端 SDK 放在 GitHub 上，但真正的核心逻辑跑在服务器端"的伪开源，而是彻底的透明：你可以阅读到底是哪段源代码替你选择了量子比特，可以用自己的策略替换它，还可以通过一个随机种子（seed）完整复现一次运行。

项目建立在一条简单而有力的原则之上：运行时所做的任何决策，都不应该对你隐藏。这句话被落实到了架构设计的每一个层面。

可检视性（Inspectability）：实时暴露运行时内部状态

DevQ 提供了一个交互式 shell，可以实时暴露运行时的内部状态——包括当前使用了哪些量子比特、错误映射（error maps）情况、以及进程状态。

这里的错误映射是量子处理器中各量子比特和量子门当前错误率的拓扑图。由于量子比特的性能会随时间漂移——受温度波动、宇宙射线、串扰等因素影响——错误映射需要通过定期校准来更新。这些数据包括单比特门错误率、双比特门错误率、读出错误率以及量子比特连接拓扑。在商业平台中，虽然部分校准数据会通过API提供给用户，但运行时如何利用这些数据做出路由和分配决策的具体逻辑仍然是封闭的。DevQ将这一层完全打开，没有任何信息被隐藏在一道无法跨越的 API 边界之后。

对于量子计算研究人员而言，这种透明度意味着他们终于能够理解并信任每一步的执行逻辑。

可扩展的插件化架构设计

DevQ 将路由器（routers）、分配器（allocators）、调度器（schedulers）、提供者（providers）和前端（frontends）全部设计为可插拔组件。

这里值得深入理解的是量子比特分配问题的技术本质：在真实量子硬件中，并非所有物理量子比特的质量都相同。每个量子比特都有不同的T1（能量弛豫时间）和T2（退相干时间），不同量子比特对之间的双比特门（如CNOT门）的错误率也存在显著差异。因此，"选择哪些物理量子比特来执行你的电路"这一决策对最终结果的质量有着决定性影响。商业平台通常会根据实时校准数据自动进行这种分配，但用户无法得知分配的具体依据，也无法验证是否选择了最优方案。DevQ的插件化分配器正是要让研究者能够完全掌控这一环节。

用户可以自带实现，且这些自定义组件被视为"一等公民"，与内置组件享有同等待遇。这种插件化设计让研究者能够针对特定实验需求，替换掉任意一个量子执行环节的策略。

可复现性（Reproducibility）：种子化运行确保结果可验证

通过种子化运行（seeded runs）和决策记录（recorded decisions），DevQ 确保"一个结果就是一个结果"，而不是一次无法重现的偶然现象。

量子计算的不可复现性实际上来自两个截然不同的层面：一是量子测量的固有概率性——这是物理本质，由波恩规则决定，原则上无法消除；二是运行时决策中引入的经典随机性，比如随机选择量子比特映射方案、随机化电路编译路径以实现噪声对称化等。种子化运行针对的是第二个层面——通过固定伪随机数生成器的种子，确保所有经典层面的决策在相同条件下可以精确复现。这样，当研究者观察到异常结果时，可以清晰地区分它究竟源于量子噪声的统计涨落，还是源于运行时做出了不同的经典决策。

由于量子系统固有的噪声和随机性，可复现性一直是验证量子计算结果可信度的关键门槛，DevQ 在架构层面系统性地解决了经典决策层的可复现性问题。

为什么选择 Apache-2.0 许可证

项目采用宽松的 Apache-2.0 许可证并非偶然。作者的考量是：让研究人员和企业都能够毫无摩擦地在其基础上构建自己的产品和研究。

Apache-2.0 许可证允许用户自由使用、修改和分发代码（包括用于商业用途），且不要求衍生作品开源。它还包含明确的专利授权条款，保护用户免受贡献者的专利诉讼。在量子计算领域，这一点尤为重要，因为许多量子算法和编译优化技术涉及大量专利。相比 GPL 等具有传染性的许可证，Apache-2.0 不要求衍生作品也必须开源，这大大降低了企业将其集成到商业产品中的法律顾虑。值得注意的是，IBM的Qiskit同样采用Apache-2.0许可证，这已成为量子计算开源生态的事实标准。

这一选择反映了作者对项目定位的清醒认识：他希望 DevQ 成为量子执行层的开放基础设施，而不是一个孤立的学术项目。宽松许可证是吸引生态参与者的现实路径。

项目现状：一个诚实的早期开源项目

值得肯定的是，作者对项目的现状非常坦诚。DevQ 目前是单人作者、依靠个人资源开发的项目，仍处于早期阶段。项目中存在一个标记为 WIP（Work In Progress）的命令，还有一个已知的大型设备 bug，作者选择公开追踪这些问题而非隐藏。

更难得的是，项目的完整 Git 历史从第一天起就是公开的。这种彻底的透明与项目"没有什么应该被隐藏"的核心理念一脉相承——不仅量子运行时的决策要透明，连开发过程本身也要透明。

开放量子计算生态的意义与挑战

DevQ 的出现触及了当前量子计算商业化进程中的一个深层矛盾：科学研究需要透明和可复现，而商业化往往倾向于封闭和保护。

目前主要的量子云服务商包括IBM Quantum（基于超导量子比特，拥有超过127量子比特的Eagle处理器）、Google Quantum AI（同为超导路线，以Sycamore处理器著称）、Amazon Braket（作为聚合平台接入IonQ、Rigetti等多家硬件供应商）、以及IonQ（采用离子阱路线）等。这些平台虽然提供了用户友好的SDK和云接口，但其核心运行时逻辑——特别是电路优化编译器的高级pass、动态量子比特路由算法、以及基于实时噪声数据的自适应错误缓解策略——通常是闭源的商业机密。这种封闭性在量子计算进入"实用量子优势"探索阶段时尤其成问题，因为研究者需要精确控制和理解实验的每一个变量，才能对计算结果做出可靠的科学声明。

作为一个单人维护的早期项目，DevQ 面临的挑战也很现实：能否吸引足够的贡献者形成社区、能否在真实量子硬件上验证其可靠性、能否跟上商业量子运行时快速迭代的功能。作者明确表示，正因为项目还处于早期，"深思熟虑的意见真的能够塑造它的方向"，他期待社区能贡献代码或提交 issue。

对于关注量子计算基础设施的开发者和研究者而言，DevQ 提供了一个值得关注的方向：在这个被大公司主导的领域里，是否还存在一条真正开放、可检视、可复现的量子计算技术路径。项目仓库地址为 github.com/DevUs-org/DevQ。

注：本文基于 Reddit 上项目作者的原始分享整理，为单一来源信息，项目的实际成熟度和可用性仍需读者自行评估验证。