CN115983393B - 量子电路任务超时原因确定方法、装置、设备及存储介质 - Google Patents

Abstract

本公开提供了一种量子电路任务超时原因确定方法、装置、电子设备及存储介质，涉及量子计算机、量子电路任务、故障诊断技术领域。该方法包括：响应于外部传入的量子电路任务处理超时，查询内部实验队列确定是否存在处于运行状态的内部实验；响应于确定存在处于运行状态的内部实验，返回因内部实验占用的第一超时原因；响应于无法确定存在处于运行状态的内部实验，返回疑似量子设备出现硬件异常的第二超时原因。通过应用该方案提供的超时原因排查方式，得以确认具体是因为哪种原因导致外部传入的量子电路任务处理超时，得以使任务发起者在明确具体超时原因的情况下不再重复发起任务，避免因任务队列包含重复任务而浪费有限且宝贵的量子运算资源。

Description

量子电路任务超时原因确定方法、装置、设备及存储介质

技术领域

本公开涉及数据处理技术领域，具体涉及量子计算机、量子电路任务、故障诊断技术领域，尤其涉及一种量子电路任务超时原因确定方法、装置、电子设备、计算机可读存储介质及计算机程序产品。

背景技术

眼下量子设备依然是极度稀缺的资源。量子设备通常需要兼顾对外开放和对内实验，甚至被多方接入。如何平衡对外和对内服务，让来自多方的任务不发生冲突，是急需关注的问题。

为了控制量子设备在云平台上的对外服务状态，现有技术增加了对量子设备是否可被外部用户使用的上下线状态反馈，但在实际应用中发现，仅仅有上下线状态管理不足以应对底层由于硬件不稳定而出现的异常错误和内部频繁的实验需求。

发明内容

本公开实施例提出了一种量子电路任务超时原因确定方法、装置、电子设备、计算机可读存储介质及计算机程序产品。

第一方面，本公开实施例提出了一种量子电路任务超时原因确定方法，包括：响应于外部传入的量子电路任务处理超时，查询内部实验队列确定是否存在处于运行状态的内部实验；响应于确定存在处于运行状态的内部实验，返回因内部实验占用的第一超时原因；响应于无法确定存在处于运行状态的内部实验，返回疑似量子设备出现硬件异常的第二超时原因。

第二方面，本公开实施例提出了一种量子电路任务超时原因确定装置，包括：内部实验运行查询单元，被配置成响应于外部传入的量子电路任务处理超时，查询内部实验队列确定是否存在处于运行状态的内部实验；第一超时原因返回单元，被配置成响应于确定存在处于运行状态的内部实验，返回因内部实验占用的第一超时原因；第二超时原因返回单元，被配置成响应于无法确定存在处于运行状态的内部实验，返回疑似量子设备出现硬件异常的第二超时原因。

第三方面，本公开实施例提供了一种电子设备，该电子设备包括：至少一个处理器；以及与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的指令，该指令被至少一个处理器执行，以使至少一个处理器执行时能够实现如第一方面描述的量子电路任务超时原因确定方法。

第四方面，本公开实施例提供了一种存储有计算机指令的非瞬时计算机可读存储介质，该计算机指令用于使计算机执行时能够实现如第一方面中任一实现方式描述的量子电路任务超时原因确定方法。

第五方面，本公开实施例提供了一种包括计算机程序的计算机程序产品，该计算机程序在被处理器执行时能够实现如第一方面描述的量子电路任务超时原因确定方法的步骤。

本公开实施例提供的量子电路任务超时原因确定方案，在确认有外部传入的量子电路任务出现处理超时的情况下，首先排查是否有内部实验处于运行状态，若有内部实验处于运行状态，则确定因内部实验运行占用导致的超时，反之则确定为疑似硬件异常导致的超时。通过此种排查方式得以确认具体是因为哪种原因导致外部传入的量子电路任务处理超时，得以使任务发起者在明确具体超时原因的情况下不再重复发起任务，避免因任务队列包含重复任务而浪费有限且宝贵的量子运算资源。

应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本公开的其它特征、目的和优点将会变得更明显：

图1是本公开可以应用于其中的示例性系统架构；

图2为本公开实施例提供的一种量子电路任务超时原因确定方法的流程图；

图3为本公开实施例提供的一种外部任务队列和内部实验队列提交至量子计算单元的结构流程示意图；

图4为本公开实施例提供的另一种量子电路任务超时原因确定方法的流程图；

图5为本公开实施例提供的一种根据第一超时原因进行后续处理的方法的流程图；

图6为本公开实施例提供的一种根据第二超时原因进行后续处理的方法的流程图；

图7为本公开实施例提供的另一种根据第二超时原因进行后续处理的方法的流程图；

图8为本公开实施例提供的在一具体应用场景下的量子电路任务超时原因确定方法的流程示意图；

图9为本公开实施例提供的一种量子电路任务超时原因确定装置的结构框图；

图10为本公开实施例提供的一种适用于执行量子电路任务超时原因确定方法的电子设备的结构示意图。

具体实施方式

以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。需要说明的是，在不冲突的情况下，本公开中的实施例及实施例中的特征可以相互组合。

本公开的技术方案中，所涉及的用户个人信息的收集、存储、使用、加工、传输、提供和公开等处理，均符合相关法律法规的规定，且不违背公序良俗。

图1示出了可以应用本公开的量子电路任务超时原因确定方法、装置、电子设备及计算机可读存储介质的实施例的示例性系统架构100。

如图1所示，系统架构100可以包括终端设备101、102、103，网络104和量子服务端105。网络104用以在终端设备101、102、103和量子服务端105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备101、102、103通过网络104与量子服务端105交互，以下发待处理的量子电路任务或接收返回的电路运行结果、处理超时反馈等。终端设备101、102、103和量子服务端105上可以安装有各种用于实现两者之间进行信息通讯的应用，例如任务下发类应用、任务处理类应用、超时原因诊断类应用等。

终端设备101、102、103和量子服务端105可以是硬件，也可以是软件。当终端设备101、102、103为硬件时，可以是具有显示屏的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等；当终端设备101、102、103为软件时，可以安装在上述所列举的电子设备中，其可以实现成多个软件或软件模块，也可以实现成单个软件或软件模块，在此不做具体限定。当量子服务端105为硬件时，可以实现成多个量子设备和多个前置服务器组成的分布式服务器集群，也可以实现成单个量子设备与前置服务器组成的硬件组合；当量子服务端105为软件时，可以实现成多个仿真软件或仿真软件模块，也可以实现成单个仿真软件或单个仿真软件模块，在此不做具体限定。

量子服务端105通过内置的各种应用可以提供各种服务，以可以提供超时原因诊断服务的超时原因诊断类应用为例，量子服务端105在运行该超时原因诊断类应用时可实现如下效果：首先，通过网络104接收终端设备101从外部传入的量子电路任务；然后，在确认从外部传入的该量子电路任务处理超时时，查询内部实验队列确定是否存在处于运行状态的内部实验；接着，在确定存在处于所述运行状态的内部实验的情况下，将通过网络104向终端设备101返回因内部实验占用的第一超时原因，而在无法确定存在处于运行状态的内部实验的情况下，将通过网络104向终端设备101返回疑似量子设备出现硬件异常的第二超时原因。

本公开后续各实施例所提供的量子电路任务超时原因确定方法由对接有量子设备的量子服务端105来执行，相应地，量子电路任务超时原因确定装置一般也设置于量子服务端105中。

应该理解，图1中的终端设备、网络和量子服务端的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和量子服务端。

请参考图2，图2为本公开实施例提供的一种量子电路任务超时原因确定方法的流程图，其中流程200包括以下步骤：

步骤201：响应于外部传入的量子电路任务处理超时，查询内部实验队列确定是否存在处于运行状态的内部实验；

本步骤旨在由量子电路任务超时原因确定方法的执行主体(例如图1所示的量子服务端105)在确认外部传入的量子电路任务出现处理超时问题时，对内部实验队列进行查询，即查询内部实验队列中确定是否存在处于运行状态的内部实验，即内部实验队列是否记录了正在占用量子设备的某个内部实验。

具体的，对是否存在处于运行状态的内部实验的查询或确认，可通过多种方式实现，例如比对一段时间前后内部实验队列中队首的内部实验编号是否发生变化，若发生变化说明在这一段时间内必然出现了内部实验的流转(即排在队列前面的某个内部实验因运行完成后被移出队列，导致队首变更)，也就能够证明存在处于运行状态的内部实验；还可以在能够读取内部实验队列中各内部实验的运行状态参数的情况下，直接明确是否有某个内部实验处于运行中状态；也可以在能够读取到内部实验队列的队列日志的情况下，通过查询队列日志看内部实验队列的运行状态，若在不久前还对某个内部实验的运行结果进行了反馈或更新了状态，那么也必然能够确定存在处于运行状态的内部实验，反之则可以无法确定存在处于运行状态的内部实验。

步骤202：响应于确定存在处于运行状态的内部实验，返回因内部实验占用的第一超时原因；

在步骤201的基础上，本步骤旨在由上述执行主体在确定存在处于运行状态的内部实验的情况下，返回因内部实验占用导致的第一超时原因，通常情况下，返回对象应为从外部传入出现处理超时的量子电路任务的账户、用户或终端设备。即第一超时原因代表着因量子设备正在处理内部实验而导致无法对外部传入的量子电路任务进行响应，即量子设备处于被其他任务占用的状态。

可参见图3所示的结构流程示意图，可见用于外部量子电路任务和内部实验被分别通过两个任务队列传入至QPU(Quantum Processing Unit，量子处理单元)，分别为那个接收外部量子电路任务的QPU Agent(代理)和用于接收内部实验的Quanlse，相应的两个队列中的任务编号命名方式也不完全相同。

步骤203：响应于无法确定存在处于运行状态的内部实验，返回疑似量子设备出现硬件异常的第二超时原因。

在步骤201的基础上，本步骤旨在由上述执行主体在无法确定存在处于运行状态的内部实验的情况下，返回疑似量子设备出现硬件异常的第二超时原因。

通常情况下，返回对象应为从外部传入出现处理超时的量子电路任务的账户、用户或终端设备。即第二超时原因代表着构成量子设备的硬件可能存在异常，导致量子设备无法正常运行，也就无法处理任何来自外部或内部的电路任务，通俗的说，就是量子设备发生了物理性损坏，即硬件参数偏离了能使量子设备正常运行的参数范围(例如某硬件温度过高、某硬件的曲率过大或过小等)。

本公开实施例提供的量子电路任务超时原因确定方法，在确认有外部传入的量子电路任务出现处理超时的情况下，首先排查是否有内部实验处于运行状态，若有内部实验处于运行状态，则确定因内部实验运行占用导致的超时，反之则确定为疑似硬件异常导致的超时。通过此种排查方式得以确认具体是因为哪种原因导致外部传入的量子电路任务处理超时，得以使任务发起者在明确具体超时原因的情况下不再重复发起任务，避免因任务队列包含重复任务而浪费有限且宝贵的量子运算资源。

为了加深对如何通过查询内部实验队列确认是否存在处于运行状态的内部实验的理解，本实施例还通过图4示出了另一种量子电路任务超时原因确定方法的流程图，其中流程400包括以下步骤：

步骤401：在间隔第一预设时长的前后，分别查询内部实验队列中处于队首的实验任务编号，得到第一编号和第二编号；

本步骤旨在由上述执行主体在时间t和t+第一预设时长的两个时刻，均查询内部实验队列中处于队首的实验任务编号，即在t时刻查询得到第一编号和在t+第一预设时长的时刻查询得到第二编号。

步骤402：判断第一编号是否与第二编号相同，若是，执行步骤405，否则执行步骤403；

在步骤401的基础上，本步骤旨在由上述执行主体判断第一编号是否与第二编号相同，并根据判断结果执行不同的处理分支。

步骤403：确定存在处于运行状态的内部实验；

本步骤建立在步骤402的判断结果为第一编号不同于第二编号的基础上，也就说明内部实验队列在第一预设时长的间隔过程中，位于队首的内部实验发生了变更，即说明在这一过程中原先位于队首的内部实验因运行完毕被移出了内部实验队列，并使得新位于队首的内部实验处于正在运行状态(即内部实验队列在本实施中的队列运行方式为：总是将处于运行状态的内部实验处于队首位置)，因此将由上述执行主体确定存在处于运行状态的内部实验。

步骤404：返回因内部实验占用的第一超时原因；

在步骤403的基础上，本步骤旨在由上述执行主体返回因内部实验占用的第一超时原因。

步骤405：无法确定存在处于运行状态的内部实验；

本步骤建立在步骤402的判断结果为第一编号与第二编号相同的基础上，也就说明内部实验队列在第一预设时长的间隔过程中，位于队首的内部实验未发生变更，而该第一预设时长通常是大于一个内部实验的运行耗时的，此时存在以下几种情况：1)该内部实验极其复杂导致其耗时远超第一预设时长；2)该内部实验在运行过程中出现硬件异常导致卡在某个执行环节无法继续下去；3)无内部实验在运行但该量子设备出现硬件异常。

因上述几种可能情况，本步骤旨在由上述执行主体确定当前无法准确的确定存在处于运行状态的内部实验。

步骤406：返回疑似量子设备出现硬件异常的第二超时原因。

在步骤405的基础上，本步骤旨在由上述执行主体返回疑似量子设备出现硬件异常的第二超时原因。这是因为上述3种情况下，因通常第一预设时长设置的合理性和内部实验的规模特性，将导致情况1发生的概率极小，因此剩余的两种情况均为发生硬件异常所导致，因此将返回疑似量子设备出现硬件异常的第二超时原因，疑似也是因为无法排除情况1的非硬件异常的超时原因。

区别于上一实施例，本实施例通过步骤401-步骤407，提供了一种基于间隔第一预设时长两次查询内部实验编号，并基于内部实验编号的一致性比对结果来确认是否存在处于运行状态的内部实验，更加准确、更具有可行性。

在上述任意实施例的基础上，图5还示出了一种根据第一超时原因进行后续处理的方法的流程图，其流程500包括如下步骤：

步骤501：根据返回的第一超时原因，将量子设备的使用状态调整为不接受外部任务传入的忙碌状态；

本步骤旨在由上述执行主体在确认当前处理超时的原因为第一超时原因时，将量子设备的使用状态调整为不接受外部任务传入的忙碌状态，以通过调整为忙碌状态提醒其它的外部用户，不要再传入新的量子电路任务，因此处于忙碌状态的量子设备是无法响应传入的量子电路任务的。

步骤502：在量子设备处于忙碌状态的过程中，每隔第二预设时长查询内部实验队列中是否均为处于运行完成状态的内部实验；

步骤503：响应于查询到内存实验队列中均为处于运行完成状态的内部实验，将量子设备的使用状态调整为接受外部任务传入的空闲状态。

步骤502-步骤503，则是在步骤501的基础上，在量子设备处于忙碌状态的过程中，每隔第二预设时长查询内部实验队列中是否均为处于运行完成状态的内部实验，并在查询到内存实验队列中均为处于运行完成状态的内部实验时，确认后续将不会继续执行新的内部实验，即内部实验将不再占用量子设备，因此上述执行主体可将量子设备的使用状态调整为接受外部任务传入的空闲状态，以提醒外部用户此时可以传入量子电路任务，处于空闲状态的量子设备是可以正常响应传入的量子电路任务的。

具体的，第二预设时长可以与第一预设时长的时长相同，也可以不同，具体可根据实际情况灵活确定，此处不做具体限定。

需要说明的是，本实施例的步骤501可以在上述任意实施例的基础上形成独立的新实施例。

在上述任意实施例的基础上，图6还示出了一种根据第二超时原因进行后续处理的方法的流程图，其流程600包括如下步骤：

步骤601：根据返回的第二超时原因，通过预设路径向量子设备的管理对象发送硬件异常警告；

本步骤旨在由上述执行主体在确认当前处理超时的原因为第二超时原因时，通过预设路径向量子设备的管理对象发送硬件异常警告，以通过发送该硬件异常警告来使该管理对象对该量子设备的硬件状态进行查看、确认，以尽可能的明确是否确实存在硬件异常。

具体的，该预设路径可以表现为多种方式，例如通过短信、邮件、系统或界面弹窗、声光报警器等。

步骤602：根据返回的第二超时原因，将量子设备的使用状态调整为不接受所有任务传入的疑似故障状态。

本步骤旨在由上述执行主体在确认当前处理超时的原因为第二超时原因时，将量子设备的使用状态调整为不接受所有任务传入的疑似故障状态，即通过调整为疑似故障状态，以提醒所有量子设备的用户不要再传入新的量子电路任务或内部实验，因此此时的量子设备可能因硬件异常无法处理任何任务。

需要说明的是，本实施例的步骤601和602均可以在上述任意实施例的基础上形成独立的新实施例，本实施例仅作为同时包含两个方案的优选实施例存在。

在上述任意实施例的基础上，图7还示出了另一种根据第二超时原因进行后续处理的方法的流程图，其流程700包括如下步骤：

步骤701：根据返回的第二超时原因，暂停所有已下发任务，并向量子设备连续下发多项测试任务；

本步骤旨在由上述执行主体在确认当前处理超时的原因为第二超时原因时，通过暂停所有已下发任务并向量子设备连续下发多项测试任务的方式，来通过看量子设备是否对测试任务有响应来进一步确认量子设备是否确实存在硬件异常。

步骤702：响应于多项测试任务均处理超时，返回确认硬件异常的第三超时原因；

本步骤旨在由上述执行主体在确认依次下发的多项测试任务均处理超时的情况下，返回确认硬件异常的第三超时原因。

另外，若依次下发的多项测试任务有部分处理完成，则可以确定存在硬件异常，但该硬件异常是波动性出现的、是不稳定的，此处还可以返回硬件不稳定的第四超时原因。

步骤703：根据返回的第三超时原因，将量子设备的使用状态调整为不可使用的故障状态。

在步骤702的基础上，本步骤旨在由上述执行主体根据返回的第三超时原因，将量子设备的使用状态调整为不可使用的故障状态。即通过故障状态确实表征了量子设备存在硬件异常，此状态下量子设备相当于已经“下线”，将无法继续使用。

需要说明的是，本实施例的步骤701-步骤702可以在上述任意实施例的基础上形成独立的新实施例。

为加深理解，本公开还结合一个具体应用场景，给出了一种具体的实现方案：

为了使当前稀有的量子资源可以供尽可能多的用户使用到，因此在该场景下将本地化的量子设备资源封装上云，使其不仅可满足本地用户传入的使用需求，也可以接收远端访问用户基于对云服务的使用传入其使用需求，为更好的满足对使用需求的处理，本场景下还创建有用于管理外部用户使用需求的代理，即QPU Agent。

首先，在本实例中QPU Agent状态管理的设计架构包括三种状态：

1)Idle(空闲)指真机设备对外可用，该状态属于在线状态，Agent服务开启；

2)Maintenance(维护中)指设备停机，并且在短时间内无法恢复，例如对量子比特重新校准、设备断电、调试等情况都属于维护中，该状态属于下线状态，Agent会将负责提供对外服务的核心进程挂起；

3)Busy(忙碌)指设备机时被占用，短期内可以恢复，该状态应用于内部专享实验的情况，属于下线状态，Agent行为和维护中一致。Agent的状态由服务端管理，而不是Agent自身来维护。Agent通过定期请求服务端，将自身状态和服务端的状态同步。且同步过程是从服务端到Agent单向进行的，Agent无法在本地独自切换状态，每次切换都需要去修改服务端所管理的Agent状态，再通过向服务端同步状态的方法达到切换自身状态的目的。

在上述状态管理架构的基础上，本实施例由QPU Agent监控组件提供了一种支持自动化状态流转的解决方案。该方案在现有状态管理基础上，结合Agent部署使用的Kubernetes集群系统与Docker容器技术，设计出全新组件Agent-Monitor。

下述将分别从整体架构设计和Agent-Monitor内部功能逻辑两方面展开说明监控组件是怎样实现的：

底层队列架构

Agent与底层量子硬件的操控系统对接时需要将处理过的任务转发到底层的任务队列中。该任务队列为Agent专用，用于接收云平台用户提交的电路任务。当研究员在发起内部实验时，通常会在量子硬件操控系统上直接发起脉冲层面任务。实验任务也会发送到底层任务队列中排队执行，但这里使用的队列和Agent所用的不是同一个队列。不同的LabspaceID用于指定往底层不同的队列中发送任务。即Agent与底层系统使用两个不同的LabspaceID(可参见图3所示的示意图)。

底层队列的设计架构十分便于判断某一时刻是否有内部实验正在进行。使用实验队列的LabspaceID去请求即可获取队列中的实验信息。接着通过检索状态为Received或Running的下的实验便可判断是否由于占用机时而将Agent切换到Busy状态。

监控组件架构

基于当前Agent状态管理的实现，Agent本身和修改Agent状态没有紧密耦合在一起，切换状态只需要请求服务端和Agent无关。再考虑到Agent目前容器化部署在Kubernetes集群中的实现方法。结合以上两点可以将复杂的监控功能作为独立服务的可能。假如将监控组件直接集成到Agent中作为单体应用的一部分，会大幅增加Agent系统复杂度和系统负荷，而且需要对代码架构做大规模修改。

因此本实施例在架构上选择将监控组件作为单独容器部署独立的微服务，让Agent更加轻量化的同时提高整体应用的稳定性。该架构方案避免对Agent主业务部分做修改，Agent依然负责从服务端收集任务和调度，预处理，转发到底层以及结果收集回传等功能。将Agent-Monitor作为容器和Agent容器部署在同一容器组中(考虑到Agent-Monitor作为组件实际是Agent主进程的辅助进程，生命周期应与Agent一致且和Agent一样不涉及到扩容问题)。Agent与Agent-Monitor使用容器组内网络(localhost)进行通讯。Agent-Monitor作为服务端接收来自Agent套接字传递的错误信息。这里错误信息指未知硬件错误和真机超时错误两种，要求Agent有非常细化的错误处理机制。当遇到Agent自身异常或来自底层的已知报错时走正常处理流程返回用户错误码和错误信息。当Agent遇到未知报错和真机超时报错时，需要分别向Agent-Monitor发出DeviceError和Timeout两种预警信息后再走正常处理流程将错误码以及过滤后的错误信息返回给用户。接着，在这两种情况下，具体如何将Agent切换状态的决策和实现完全交由Agent-Monitor容器处理。监控组件与Agent隔离，避免作为辅助功能的监控组件异常时导致主业务受影响。

监控组件功能

监控组件监听内部实验占用和硬件错误两类超时原因，并且对这两类异常的处理是不同的。下述会分别介绍当这两类异常发生时监控组件内部的功能逻辑。

1)内部实验占用

监控组件收到来自Agent的超时预警后，需要判断造成超时的原因是否由内部实验占用机时导致。这里的判断方法参考底层队列架构，通过请求内部实验队列(需要预先将内部任务队列的LabspaceID和Token配置给Agent-Monitor容器对象)查看是否有正在进行中的实验。如果有运行中的实验，则认为造成超时的原因是排队导致。这时监控组件请求服务端将Agent状态切换到Busy。修改后Agent将自己挂起不再接收任务(任务在服务端队列中不会超时，挂起Agent避免将任务送到底层队列导致超时)，前端则会同步服务端Agent状态并将内部实验中的信息反馈给用户。

监控组件将Agent下线后，对实验队列开启轮询。目的是为了在实验结束后可以立即将Agent从Busy切换回正确状态。由于硬件设备通常分时段提供服务，因此在实验结束后，监控组件结合当前时间判断应将Agent切换回对外状态还是维护中。实验结束的判断依据是底层实验队列中所有实验都处于执行完毕状态。修改状态后，即认为对一次真机超时处理完毕，监控组件结束轮询，恢复端口监听服务。

监控组件收到超时预警后，如果在底层实验队列中没有发现有实验在占用机时，则将此次超时归为硬件报错，走以下流程处理。

2)硬件错误

对于来自底层硬件的报错，不依靠人工排查，完全自动化处理其实是十分困难的。这类错误中有部分源自于当前量子设备的不稳定性。设备可能受环境温度、元器件震动等因素影响，错误可能是临时的，下一次运行时假如系统恢复稳定便可正常运行。因此，考虑到以上情况，监控组件收到这类预警不会立即将Agent修改为下线状态，而是第一时间发出携带任务号和错误信息的报警邮件到预留的管理员邮箱。之后监控组件在本地另外发起两到三次电路任务用于检查，如果都捕获到异常则认为该错误不能短时间内恢复，自动将Agent切换到下线状态。如果用于检查的电路任务正常运行，则继续监听端口。假如将Agent下线，状态恢复则需要人为操作，没有其它判断机制。

上述判别流程具体可参见图8所示的流程示意图。

本实施例所提供的上述方案为QPU Agent提供了自动化状态流转的实现途径，也为QPU Agent首次提供了对上游硬件设备的校验机制，携带监控组件的Agent更加关注底层设备可用性，配合邮件预警系统，提升Agent对上游错误的发现和反馈能力。从内部使用角度看，监控组件替研发人员在实验时及时反馈外部用户，帮助研发人员用最快速度对硬件报错做初步检查和应急处理；从用户使用角度看，该技术方案支持及时向用户同步平台接入量子设备的对外服务状态，有效避免将硬件错误持续暴露给用户，更避免了内部占用而给用户造成服务不可用的错误印象。起到辅助研发人员处理异常和提升用户使用体验的作用，帮助平台更具竞争力。

进一步参考图9，作为对上述各图所示方法的实现，本公开提供了一种量子电路任务超时原因确定装置的一个实施例，该装置实施例与图2所示的方法实施例相对应，该装置具体可以应用于各种电子设备中。

如图9所示，本实施例的量子电路任务超时原因确定装置900可以包括：内部实验运行查询单元901、第一超时原因返回单元902、第二超时原因返回单元903。其中，内部实验运行查询单元901，被配置成响应于外部传入的量子电路任务处理超时，查询内部实验队列确定是否存在处于运行状态的内部实验；第一超时原因返回单元902，被配置成响应于确定存在处于运行状态的内部实验，返回因内部实验占用的第一超时原因；第二超时原因返回单元903，被配置成响应于无法确定存在处于运行状态的内部实验，返回疑似量子设备出现硬件异常的第二超时原因。

在本实施例中，量子电路任务超时原因确定装置900中：内部实验运行查询单元901、第一超时原因返回单元902、第二超时原因返回单元903的具体处理及其所带来的技术效果可分别参考图2对应实施例中的步骤201-203的相关说明，在此不再赘述。

在本实施例的一些可选的实现方式中，内部实验运行查询单元901可以被进一步配置成：

在间隔第一预设时长的前后，分别查询内部实验队列中处于队首的实验任务编号，得到第一编号和第二编号；

响应于第一编号不同于第二编号，确定存在处于运行状态的内部实验；

响应于第一编号与第二编号相同，无法确定存在处于运行状态的内部实验。

在本实施例的一些可选的实现方式中，量子电路任务超时原因确定装置900还可以包括：

忙碌状态调整单元，被配置成根据返回的第一超时原因，将量子设备的使用状态调整为不接受外部任务传入的忙碌状态。

在本实施例的一些可选的实现方式中，量子电路任务超时原因确定装置900还可以包括：

内部实验运行完成查询单元，被配置成在量子设备处于忙碌状态的过程中，每隔第二预设时长查询内部实验队列中是否均为处于运行完成状态的内部实验；

空闲状态调整单元，被配置成响应于查询到内存实验队列中均为处于运行完成状态的内部实验，将量子设备的使用状态调整为接受外部任务传入的空闲状态。

在本实施例的一些可选的实现方式中，量子电路任务超时原因确定装置900还可以包括：

硬件异常警告发送单元，被配置成根据返回的第二超时原因，通过预设路径向量子设备的管理对象发送硬件异常警告。

在本实施例的一些可选的实现方式中，量子电路任务超时原因确定装置900还可以包括：

疑似故障状态调整单元，被配置成根据返回的第二超时原因，将量子设备的使用状态调整为不接受所有任务传入的疑似故障状态。

在本实施例的一些可选的实现方式中，量子电路任务超时原因确定装置900还可以包括：

测试任务下发单元，被配置成根据返回的第二超时原因，暂停所有已下发任务，并向量子设备连续下发多项测试任务；

第三超时原因返回单元，被配置成响应于多项测试任务均处理超时，返回确认硬件异常的第三超时原因。

在本实施例的一些可选的实现方式中，量子电路任务超时原因确定装置900还可以包括：

故障状态调整单元，被配置成根据返回的第三超时原因，将量子设备的使用状态调整为不可使用的故障状态。

本实施例作为对应于上述方法实施例的装置实施例存在，本实施例提供的量子电路任务超时原因确定装置，在确认有外部传入的量子电路任务出现处理超时的情况下，首先排查是否有内部实验处于运行状态，若有内部实验处于运行状态，则确定因内部实验运行占用导致的超时，反之则确定为疑似硬件异常导致的超时。通过此种排查方式得以确认具体是因为哪种原因导致外部传入的量子电路任务处理超时，得以使任务发起者在明确具体超时原因的情况下不再重复发起任务，避免因任务队列包含重复任务而浪费有限且宝贵的量子运算资源。

根据本公开的实施例，本公开还提供了一种电子设备，该电子设备包括：至少一个处理器；以及与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的指令，该指令被至少一个处理器执行，以使至少一个处理器执行时能够实现上述任意实施例所描述的量子电路任务超时原因确定方法。

根据本公开的实施例，本公开还提供了一种可读存储介质，该可读存储介质存储有计算机指令，该计算机指令用于使计算机执行时能够实现上述任意实施例所描述的量子电路任务超时原因确定方法。

根据本公开的实施例，本公开还提供了一种计算机程序产品，该计算机程序在被处理器执行时能够实现上述任意实施例所描述的量子电路任务超时原因确定方法。

图10示出了可以用来实施本公开的实施例的示例电子设备1000的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。

如图10所示，设备1000包括计算单元1001，其可以根据存储在只读存储器(ROM)1002中的计算机程序或者从存储单元1008加载到随机访问存储器(RAM)1003中的计算机程序，来执行各种适当的动作和处理。在RAM 1003中，还可存储设备1000操作所需的各种程序和数据。计算单元1001、ROM 1002以及RAM 1003通过总线1004彼此相连。输入/输出(I/O)接口1005也连接至总线1004。

设备1000中的多个部件连接至I/O接口1005，包括：输入单元1006，例如键盘、鼠标等；输出单元1007，例如各种类型的显示器、扬声器等；存储单元1008，例如磁盘、光盘等；以及通信单元1009，例如网卡、调制解调器、无线通信收发机等。通信单元1009允许设备1000通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

计算单元1001可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元1001的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元1001执行上文所描述的各个方法和处理，例如量子电路任务超时原因确定方法。例如，在一些实施例中，量子电路任务超时原因确定方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元1008。在一些实施例中，计算机程序的部分或者全部可以经由ROM 1002和/或通信单元1009而被载入和/或安装到设备1000上。当计算机程序加载到RAM 1003并由计算单元1001执行时，可以执行上文描述的量子电路任务超时原因确定方法的一个或多个步骤。备选地，在其他实施例中，计算单元1001可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行量子电路任务超时原因确定方法。

本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、负载可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，又称为云计算服务器或云主机，是云计算服务体系中的一项主机产品，以解决传统物理主机与虚拟专用服务器(VPS，Virtual Private Server)服务中存在的管理难度大，业务扩展性弱的缺陷。

根据本公开实施例的技术方案，在确认有外部传入的量子电路任务出现处理超时的情况下，首先排查是否有内部实验处于运行状态，若有内部实验处于运行状态，则确定因内部实验运行占用导致的超时，反之则确定为疑似硬件异常导致的超时。通过此种排查方式得以确认具体是因为哪种原因导致外部传入的量子电路任务处理超时，得以使任务发起者在明确具体超时原因的情况下不再重复发起任务，避免因任务队列包含重复任务而浪费有限且宝贵的量子运算资源。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。

Claims (18)

1.一种量子电路任务超时原因确定方法，包括：

响应于外部传入的量子电路任务处理超时，查询内部实验队列确定是否存在处于运行状态的内部实验；

响应于确定存在处于所述运行状态的内部实验，返回因内部实验占用的第一超时原因；

响应于无法确定存在处于所述运行状态的内部实验，返回疑似量子设备出现硬件异常的第二超时原因。

2.根据权利要求1所述的方法，其中，所述查询内部实验队列确定是否存在处于运行状态的内部实验，包括：

在间隔第一预设时长的前后，分别查询所述内部实验队列中处于队首的实验任务编号，得到第一编号和第二编号；

响应于所述第一编号不同于所述第二编号，确定存在处于所述运行状态的内部实验；

响应于所述第一编号与所述第二编号相同，无法确定存在处于所述运行状态的内部实验。

3.根据权利要求1所述的方法，还包括：

根据返回的第一超时原因，将所述量子设备的使用状态调整为不接受外部任务传入的忙碌状态。

4.根据权利要求3所述的方法，还包括：

在所述量子设备处于所述忙碌状态的过程中，每隔第二预设时长查询所述内部实验队列中是否均为处于运行完成状态的内部实验；

响应于查询到所述内部实验队列中均为处于运行完成状态的内部实验，将所述量子设备的使用状态调整为接受外部任务传入的空闲状态。

5.根据权利要求1所述的方法，还包括：

根据返回的第二超时原因，通过预设路径向所述量子设备的管理对象发送硬件异常警告。

6.根据权利要求1所述的方法，还包括：

根据返回的第二超时原因，将所述量子设备的使用状态调整为不接受所有任务传入的疑似故障状态。

7.根据权利要求5或6所述的方法，还包括：

根据返回的第二超时原因，暂停所有已下发任务，并向所述量子设备连续下发多项测试任务；

响应于所述多项测试任务均处理超时，返回确认硬件异常的第三超时原因。

8.根据权利要求7所述的方法，还包括：

根据返回的第三超时原因，将所述量子设备的使用状态调整为不可使用的故障状态。

9.一种量子电路任务超时原因确定装置，包括：

内部实验运行查询单元，被配置成响应于外部传入的量子电路任务处理超时，查询内部实验队列确定是否存在处于运行状态的内部实验；

第一超时原因返回单元，被配置成响应于确定存在处于所述运行状态的内部实验，返回因内部实验占用的第一超时原因；

第二超时原因返回单元，被配置成响应于无法确定存在处于所述运行状态的内部实验，返回疑似量子设备出现硬件异常的第二超时原因。

10.根据权利要求9所述的装置，其中，所述内部实验运行查询单元被进一步配置成：

在间隔第一预设时长的前后，分别查询所述内部实验队列中处于队首的实验任务编号，得到第一编号和第二编号；

响应于所述第一编号不同于所述第二编号，确定存在处于所述运行状态的内部实验；

响应于所述第一编号与所述第二编号相同，无法确定存在处于所述运行状态的内部实验。

11.根据权利要求9所述的装置，还包括：

忙碌状态调整单元，被配置成根据返回的第一超时原因，将所述量子设备的使用状态调整为不接受外部任务传入的忙碌状态。

12.根据权利要求11所述的装置，还包括：

内部实验运行完成查询单元，被配置成在所述量子设备处于所述忙碌状态的过程中，每隔第二预设时长查询所述内部实验队列中是否均为处于运行完成状态的内部实验；

空闲状态调整单元，被配置成响应于查询到所述内部实验队列中均为处于运行完成状态的内部实验，将所述量子设备的使用状态调整为接受外部任务传入的空闲状态。

13.根据权利要求9所述的装置，还包括：

硬件异常警告发送单元，被配置成根据返回的第二超时原因，通过预设路径向所述量子设备的管理对象发送硬件异常警告。

14.根据权利要求9所述的装置，还包括：

疑似故障状态调整单元，被配置成根据返回的第二超时原因，将所述量子设备的使用状态调整为不接受所有任务传入的疑似故障状态。

15.根据权利要求13或14所述的装置，还包括：

测试任务下发单元，被配置成根据返回的第二超时原因，暂停所有已下发任务，并向所述量子设备连续下发多项测试任务；

第三超时原因返回单元，被配置成响应于所述多项测试任务均处理超时，返回确认硬件异常的第三超时原因。

16.根据权利要求15所述的装置，还包括：

故障状态调整单元，被配置成根据返回的第三超时原因，将所述量子设备的使用状态调整为不可使用的故障状态。

17.一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求1-8中任一项所述的量子电路任务超时原因确定方法。

18.一种存储有计算机指令的非瞬时计算机可读存储介质，所述计算机指令用于使所述计算机执行权利要求1-8中任一项所述的量子电路任务超时原因确定方法。