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

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


背景技术：

2.眼下量子设备依然是极度稀缺的资源。量子设备通常需要兼顾对外开放和对内实验，甚至被多方接入。如何平衡对外和对内服务，让来自多方的任务不发生冲突，是急需关注的问题。
3.为了控制量子设备在云平台上的对外服务状态，现有技术增加了对量子设备是否可被外部用户使用的上下线状态反馈，但在实际应用中发现，仅仅有上下线状态管理不足以应对底层由于硬件不稳定而出现的异常错误和内部频繁的实验需求。


技术实现要素：

4.本公开实施例提出了一种量子电路任务超时原因确定方法、装置、电子设备、计算机可读存储介质及计算机程序产品。
5.第一方面，本公开实施例提出了一种量子电路任务超时原因确定方法，包括：响应于外部传入的量子电路任务处理超时，在预设的初始时间间隔的前后，分别查询内部实验队列中队首位置的处于运行状态的内部实验编号；其中，所述初始时间间隔的时长大于一个内部实验的平均运行耗时；响应于两次查询得到的内部实验编号不同，返回因内部实验占用的第一超时原因；响应于两次查询得到的内部实验编号相同，返回疑似量子设备出现硬件异常的第二超时原因。
6.第二方面，本公开实施例提出了一种量子电路任务超时原因确定装置，包括：内部实验运行查询单元，被配置成响应于外部传入的量子电路任务处理超时，在预设的初始时间间隔的前后，分别查询内部实验队列中队首位置的处于运行状态的内部实验编号；其中，所述初始时间间隔的时长大于一个内部实验的平均运行耗时；第一超时原因返回单元，被配置成响应于两次查询得到的内部实验编号不同，返回因内部实验占用的第一超时原因；第二超时原因返回单元，被配置成响应于两次查询得到的内部实验编号相同，返回疑似量子设备出现硬件异常的第二超时原因。
7.第三方面，本公开实施例提供了一种电子设备，该电子设备包括：至少一个处理器；以及与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的指令，该指令被至少一个处理器执行，以使至少一个处理器执行时能够实现如第一方面描述的量子电路任务超时原因确定方法。
8.第四方面，本公开实施例提供了一种存储有计算机指令的非瞬时计算机可读存储介质，该计算机指令用于使计算机执行时能够实现如第一方面中任一实现方式描述的量子电路任务超时原因确定方法。
9.第五方面，本公开实施例提供了一种包括计算机程序的计算机程序产品，该计算机程序在被处理器执行时能够实现如第一方面描述的量子电路任务超时原因确定方法的步骤。
10.本公开实施例提供的量子电路任务超时原因确定方案，在确认有外部传入的量子电路任务出现处理超时的情况下，通过在预设的初始时间间隔的前后分两次查询内部实验队列中处于队首位置的处于运行状态的内部实验编号，并在经对比后确认两次查询得到的内部实验编号不同时，可确定超时原因为内部实验运行占用，反之则将超时原因确定为疑似硬件异常，由于该初始时间间隔的时长大于一个内部实验的平均运行耗时，因此能够确认具体是因为哪种原因导致外部传入的量子电路任务处理超时，得以使任务发起者在明确具体超时原因的情况下不再重复发起任务，避免因任务队列包含重复任务而浪费有限且宝贵的量子运算资源。
11.应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。
附图说明
12.通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本公开的其它特征、目的和优点将会变得更明显：
13.图1是本公开可以应用于其中的示例性系统架构；
14.图2为本公开实施例提供的一种量子电路任务超时原因确定方法的流程图；
15.图3为本公开实施例提供的一种外部任务队列和内部实验队列提交至量子计算单元的结构流程示意图；
16.图4为本公开实施例提供的一种对于不同超时原因提供不同的后续处理方式的方法的流程图；
17.图5为本公开实施例提供的一种根据第二超时原因上调后续查询间隔时长的方法的流程图；
18.图6为本公开实施例提供的一种根据第二超时原因进行后续处理的方法的流程图；
19.图7为本公开实施例提供的一种在两次查询的内部实验编号不相同时下调后续查询时长的方法的流程图；
20.图8为本公开实施例提供的在一具体应用场景下的量子电路任务超时原因确定方法的流程示意图；
21.图9为本公开实施例提供的一种量子电路任务超时原因确定装置的结构框图；
22.图10为本公开实施例提供的一种适用于执行量子电路任务超时原因确定方法的电子设备的结构示意图。
具体实施方式
23.以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同
样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。需要说明的是，在不冲突的情况下，本公开中的实施例及实施例中的特征可以相互组合。
24.本公开的技术方案中，所涉及的用户个人信息的收集、存储、使用、加工、传输、提供和公开等处理，均符合相关法律法规的规定，且不违背公序良俗。
25.图1示出了可以应用本公开的量子电路任务超时原因确定方法、装置、电子设备及计算机可读存储介质的实施例的示例性系统架构100。
26.如图1所示，系统架构100可以包括终端设备101、102、103，网络104和量子服务端105。网络104用以在终端设备101、102、103和量子服务端105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。
27.用户可以使用终端设备101、102、103通过网络104与量子服务端105交互，以下发待处理的量子电路任务或接收返回的电路运行结果、处理超时反馈等。终端设备101、102、103和量子服务端105上可以安装有各种用于实现两者之间进行信息通讯的应用，例如任务下发类应用、任务处理类应用、超时原因诊断类应用等。
28.终端设备101、102、103和量子服务端105可以是硬件，也可以是软件。当终端设备101、102、103为硬件时，可以是具有显示屏的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等；当终端设备101、102、103为软件时，可以安装在上述所列举的电子设备中，其可以实现成多个软件或软件模块，也可以实现成单个软件或软件模块，在此不做具体限定。当量子服务端105为硬件时，可以实现成多个量子设备和多个前置服务器组成的分布式服务器集群，也可以实现成单个量子设备与前置服务器组成的硬件组合；当量子服务端105为软件时，可以实现成多个仿真软件或仿真软件模块，也可以实现成单个仿真软件或单个仿真软件模块，在此不做具体限定。
29.量子服务端105通过内置的各种应用可以提供各种服务，以可以提供超时原因诊断服务的超时原因诊断类应用为例，量子服务端105在运行该超时原因诊断类应用时可实现如下效果：首先，通过网络104接收终端设备101从外部传入的量子电路任务；然后，在确认从外部传入的该量子电路任务处理超时时，在预设的初始时间间隔的前后，分别查询内部实验队列中队首位置的处于运行状态的内部实验编号，该初始时间间隔的时长大于一个内部实验的平均运行耗时；接着，在确定两次查询得到的内部实验编号不同的情况下，将通过网络104向终端设备101返回因内部实验占用的第一超时原因，而在确定两次查询得到的内部实验编号相同的情况下，将通过网络104向终端设备101返回疑似量子设备出现硬件异常的第二超时原因。
30.本公开后续各实施例所提供的量子电路任务超时原因确定方法由对接有量子设备的量子服务端105来执行，相应地，量子电路任务超时原因确定装置一般也设置于量子服务端105中。
31.应该理解，图1中的终端设备、网络和量子服务端的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和量子服务端。
32.请参考图2，图2为本公开实施例提供的一种量子电路任务超时原因确定方法的流程图，其中流程200包括以下步骤：
33.步骤201：响应于外部传入的量子电路任务处理超时，在预设的初始时间间隔的前后，分别查询内部实验队列中队首位置的处于运行状态的内部实验编号；
34.本步骤旨在由量子电路任务超时原因确定方法的执行主体(例如图1所示的量子服务端105)在确认外部传入的量子电路任务出现处理超时问题时，通过间隔预设的初始时间间隔分两次查询内部实验队列中队首位置的处于运行状态的内部实验编号的方式，来确认内部实验队列中是否存在处于运行状态的内部实验，即内部实验队列是否记录了正在占用量子设备的某个内部实验。
35.具体的，上述执行主体可分别在时间t和t+初始时间间隔的时长的分别对应的时刻，查询内部实验队列中处于队首的实验任务编号，即在t时刻查询得到第一编号和在t+初始时间间隔的时长的时刻查询得到第二编号。
36.步骤202：响应于两次查询得到的内部实验编号不同，返回因内部实验占用的第一超时原因；
37.本步骤建立在步骤201的判断结果为两次查询得到的内部实验编号不同的基础上(即第一编号不同于第二编号)，也就说明内部实验队列在初始时间间隔的时长过程中，位于队首的内部实验发生了变更，即说明在这一过程中原先位于队首的内部实验因运行完毕被移出了内部实验队列，并使得新位于队首的内部实验处于正在运行状态(即内部实验队列在本实施中的队列运行方式为：总是将处于运行状态的内部实验处于队首位置)，因此将由上述执行主体确定存在处于运行状态的内部实验，由此将返回因内部实验占用的第一超时原因。
38.通常情况下，返回对象应为从外部传入出现处理超时的量子电路任务的账户、用户或终端设备。即第一超时原因代表着因量子设备正在处理内部实验而导致无法对外部传入的量子电路任务进行响应，即量子设备处于被其他任务占用的状态。
39.可参见图3所示的结构流程示意图，可见用于外部量子电路任务和内部实验被分别通过两个任务队列传入至qpu(quantum processing unit，量子处理单元)，分别为那个接收外部量子电路任务的qpu agent(代理)和用于接收内部实验的quanlse，相应的两个队列中的任务编号命名方式也不完全相同。
40.步骤203：响应于两次查询得到的内部实验编号相同，返回疑似量子设备出现硬件异常的第二超时原因。
41.本步骤建立在步骤201的判断结果为两次查询得到的内部实验编号相同(即第一编号与第二编号相同)的基础上，也就说明内部实验队列在初始时间间隔的时长过程中，位于队首的内部实验未发生变更，而由于该初始时间间隔的时长通常是大于一个内部实验的运行耗时的，那么此时将存在以下几种情况：1)该内部实验极其复杂导致其耗时远超第一预设时长；2)该内部实验在运行过程中出现硬件异常导致卡在某个执行环节无法继续下去；3)无内部实验在运行但该量子设备出现硬件异常。
42.因上述几种可能情况，上述执行主体实际上在当前无法准确的确定存在处于运行状态的内部实验。考虑到因为上述3种情况下，因通常第一预设时长设置的合理性和内部实验的规模特性，将导致情况1发生的概率极小，因此剩余的两种情况均为发生硬件异常所导致，因此本步骤将返回疑似量子设备出现硬件异常的第二超时原因，疑似也是因为无法排除情况1的非硬件异常的超时原因。
43.通常情况下，返回对象应为从外部传入出现处理超时的量子电路任务的账户、用户或终端设备。即第二超时原因代表着构成量子设备的硬件可能存在异常，导致量子设备
无法正常运行，也就无法处理任何来自外部或内部的电路任务，通俗的说，就是量子设备发生了物理性损坏，即硬件参数偏离了能使量子设备正常运行的参数范围(例如某硬件温度过高、某硬件的曲率过大或过小等)。
44.本公开实施例提供的量子电路任务超时原因确定方法，在确认有外部传入的量子电路任务出现处理超时的情况下，通过在预设的初始时间间隔的前后分两次查询内部实验队列中处于队首位置的处于运行状态的内部实验编号，并在经对比后确认两次查询得到的内部实验编号不同时，可确定超时原因为内部实验运行占用，反之则将超时原因确定为疑似硬件异常，由于该初始时间间隔的时长大于一个内部实验的平均运行耗时，因此能够确认具体是因为哪种原因导致外部传入的量子电路任务处理超时，得以使任务发起者在明确具体超时原因的情况下不再重复发起任务，避免因任务队列包含重复任务而浪费有限且宝贵的量子运算资源。
45.另外，除通过比对一段时间前后内部实验队列中队首的内部实验编号是否发生变化来确认处于运行状态的内部实验的方式外，还可以在能够读取内部实验队列中各内部实验的运行状态参数的情况下，直接明确是否有某个内部实验处于运行中状态；也可以在能够读取到内部实验队列的队列日志的情况下，通过查询队列日志看内部实验队列的运行状态，若在不久前还对某个内部实验的运行结果进行了反馈或更新了状态，那么也必然能够确定存在处于运行状态的内部实验，反之则可以无法确定存在处于运行状态的内部实验。
46.在上述任意实施例的基础上，图4还示出了对不同的超时原因提供相应的后续处理方案的流程图，其包括如下方案：
47.1)根据返回的第一超时原因，将量子设备的使用状态调整为不接受外部任务传入的忙碌状态；
48.本步骤旨在由上述执行主体在确认当前处理超时的原因为第一超时原因时，将量子设备的使用状态调整为不接受外部任务传入的忙碌状态，以通过调整为忙碌状态提醒其它的外部用户，不要再传入新的量子电路任务，因此处于忙碌状态的量子设备是无法响应传入的量子电路任务的。
49.2)根据返回的第二超时原因，通过预设路径向量子设备的管理对象发送硬件异常警告；
50.本步骤旨在由上述执行主体在确认当前处理超时的原因为第二超时原因时，通过预设路径向量子设备的管理对象发送硬件异常警告，以通过发送该硬件异常警告来使该管理对象对该量子设备的硬件状态进行查看、确认，以尽可能的明确是否确实存在硬件异常。
51.具体的，该预设路径可以表现为多种方式，例如通过短信、邮件、系统或界面弹窗、声光报警器等。
52.3)根据返回的第二超时原因，将量子设备的使用状态调整为不接受所有任务传入的疑似故障状态。
53.本步骤旨在由上述执行主体在确认当前处理超时的原因为第二超时原因时，将量子设备的使用状态调整为不接受所有任务传入的疑似故障状态，即通过调整为疑似故障状态，以提醒所有量子设备的用户不要再传入新的量子电路任务或内部实验，因此此时的量子设备可能因硬件异常无法处理任何任务。
54.需要说明的是，本实施例的均可以在上述任意实施例的基础上形成独立的新实施
例，本实施例仅是对不同方案的汇总呈现。
55.在上述任意实施例的基础上，图5为本公开实施例提供的一种根据第二超时原因上调后续查询间隔时长的方法的流程图，其流程500包括如下步骤：
56.步骤501：根据返回的第二超时原因，对初始时间间隔的时长进行上调；
57.即在初步判定存在疑似硬件异常问题的情况下，将对该初始时间间隔的时长进行上调，其上调幅度或上调比例可根据实际需求自行确定和选取，此处不做具体限定。
58.步骤502：将经时长上调后的时间间隔作为下一次比对内部实验编号的实际时间间隔，直至下一次比对内部实验编号时确认两次查询得到的内部实验编号不同时不再继续上调。
59.在步骤501的基础上，本步骤旨在由上述执行主体将经时长上调后的时间间隔作为下一次比对内部实验编号的实际时间间隔，即下一次进行查询比对操作将间隔更长的时长，且时长上调操作将在后续每次查询比对操作均得到编号相同的情况下持续进行，也就意味着时间间隔将随着查询比对次数的不断增加而不断上调，也就导致后续将间隔更长的时长才进行下一次查询比对操作，从而避免按照固定时间间隔造成的频繁且无效的查询比对操作。
60.时长的上调操作将直至下一次比对内部实验编号时确认两次查询得到的内部实验编号不同时不再继续。
61.进一步的，若发现连续多次比对内部实验编号的结果均为相同，甚至还可以根据比对结果连续相同次数，增大对下一次比对内部实验编号的实际时间间隔的上调幅度，即比对结果连续相同次数的大小与上调幅度成正比关系，例如原先按照固定的上调幅度(例如固定增加20分钟的时长)，此吃将随着比对结果连续相同次数的增加，将从原先固定的增加20分钟时长的方式，逐步调整为增加30分钟、40分钟、50分钟的上调幅度，以进一步减少无效的查询比对操作次数。
62.在上述任意实施例的基础上，图6还示出了另一种根据第二超时原因进行后续处理的方法的流程图，其流程600包括如下步骤：
63.步骤601：根据返回的第二超时原因，暂停所有已下发任务，并向量子设备连续下发多项测试任务；
64.本步骤旨在由上述执行主体在确认当前处理超时的原因为第二超时原因时，通过暂停所有已下发任务并向量子设备连续下发多项测试任务的方式，来通过看量子设备是否对测试任务有响应来进一步确认量子设备是否确实存在硬件异常。
65.步骤602：响应于多项测试任务均处理超时，返回确认硬件异常的第三超时原因；
66.本步骤旨在由上述执行主体在确认依次下发的多项测试任务均处理超时的情况下，返回确认硬件异常的第三超时原因。
67.另外，若依次下发的多项测试任务有部分处理完成，则可以确定存在硬件异常，但该硬件异常是波动性出现的、是不稳定的，此处还可以返回硬件不稳定的第四超时原因。
68.步骤603：根据返回的第三超时原因，将量子设备的使用状态调整为不可使用的故障状态。
69.在步骤602的基础上，本步骤旨在由上述执行主体根据返回的第三超时原因，将量子设备的使用状态调整为不可使用的故障状态。即通过故障状态确实表征了量子设备存在
硬件异常，此状态下量子设备相当于已经“下线”，将无法继续使用。
70.需要说明的是，本实施例的步骤601-步骤602可以在上述任意实施例的基础上形成独立的新实施例。
71.进一步的，之前在根据第二超时原因对下次查询时间间隔进行的上调幅度，还可以在进一步确认处于第三超时原因的情况下，增大该上调幅度，以对应明确确认处于的硬件异常的故障状态。
72.在上述任意实施例的基础上，图7为本公开实施例提供的一种在两次查询的内部实验编号不相同时下调后续查询时长的方法的流程图，其流程700包括如下步骤：
73.步骤701：响应于在当前的时间间隔的前后分别查询得到的内部实验编号不同，对当前的时间间隔的时长进行下调；
74.本步骤旨在由上述执行主体在根据当前的时间间隔(即可能是基于图5所示实施例进行过多次上调的时间间隔)的前后分别查询得到的内部实验编号不同，对当前的时间间隔的时长进行下调。
75.即在某次进行的内部实验编号查询比对操作时发现两编号不同，也就意味着可确认此时存在处于运行状态的内部实验，也就意味着量子设备已经处于可正常运行任务的状态，即意味着量子设备可能从之前的硬件异常状态恢复至硬件正常状态，因此不必要继续上调时间间隔的时长，而是对当前的时间间隔的时长进行下调。
76.需要说明的是，对时间间隔的时长所进行的下调操作，其下调结果的下限为初始时间间隔。
77.步骤702：将经时长下调后的时间间隔作为下一次对比内部实验编号的实际时间间隔；
78.在步骤701的基础上，本步骤旨在由上述执行主体将经时长下调后的时间间隔作为下一次对比内部实验编号的实际时间间隔。即下一次进行查询比对操作将间隔更短的时长，且时长下调操作将在后续每次查询比对操作均得到编号不相同的情况下持续进行，也就意味着时间间隔将随着查询比对次数的不断增加而不断下调，也就导致后续将间隔越来越短的时长就进行下一次查询比对操作，从而通过多次查询来确认量子设备是否处于一个比较稳定的正常运行状态。
79.步骤703：响应于当前的时间间隔与初始时间间隔相同，将量子设备的使用状态调整为接受任务传入的空闲状态。
80.在步骤702的基础上，本步骤旨在由上述执行主体在当前的时间间隔与初始时间间隔相同时，将量子设备的使用状态调整为接受任务传入的空闲状态。即通过多次查询确认量子设备处于一个比较稳定的正常运行状态的情况下，才将量子设备的使用状态调整为接受任务传入的空闲状态。
81.进一步的，若连续多次比对内部实验编号的结果均为不相同，还可以根据比对结果连续不相同次数，增大对下一次比对内部实验编号的实际时间间隔的下调幅度，该比对结果连续不相同次数的大小与该下调幅度成正比关系。
82.例如原先按照固定的下调幅度(例如固定减少20分钟的时长)，此吃将随着比对结果连续不相同次数的增加，将从原先固定的减少20分钟时长的方式，逐步调整为减少30分钟、40分钟、50分钟的下调幅度。
83.为加深理解，本公开还结合一个具体应用场景，给出了一种具体的实现方案：
84.为了使当前稀有的量子资源可以供尽可能多的用户使用到，因此在该场景下将本地化的量子设备资源封装上云，使其不仅可满足本地用户传入的使用需求，也可以接收远端访问用户基于对云服务的使用传入其使用需求，为更好的满足对使用需求的处理，本场景下还创建有用于管理外部用户使用需求的代理，即qpu agent。
85.首先，在本实例中qpu agent状态管理的设计架构包括三种状态：
86.1)idle(空闲)指真机设备对外可用，该状态属于在线状态，agent服务开启；
87.2)maintenance(维护中)指设备停机，并且在短时间内无法恢复，例如对量子比特重新校准、设备断电、调试等情况都属于维护中，该状态属于下线状态，agent会将负责提供对外服务的核心进程挂起；
88.3)busy(忙碌)指设备机时被占用，短期内可以恢复，该状态应用于内部专享实验的情况，属于下线状态，agent行为和维护中一致。agent的状态由服务端管理，而不是agent自身来维护。agent通过定期请求服务端，将自身状态和服务端的状态同步。且同步过程是从服务端到agent单向进行的，agent无法在本地独自切换状态，每次切换都需要去修改服务端所管理的agent状态，再通过向服务端同步状态的方法达到切换自身状态的目的。
89.在上述状态管理架构的基础上，本实施例由qpu agent监控组件提供了一种支持自动化状态流转的解决方案。该方案在现有状态管理基础上，结合agent部署使用的kubernetes集群系统与docker容器技术，设计出全新组件agent-monitor。
90.下述将分别从整体架构设计和agent-monitor内部功能逻辑两方面展开说明监控组件是怎样实现的：
91.底层队列架构
92.agent与底层量子硬件的操控系统对接时需要将处理过的任务转发到底层的任务队列中。该任务队列为agent专用，用于接收云平台用户提交的电路任务。当研究员在发起内部实验时，通常会在量子硬件操控系统上直接发起脉冲层面任务。实验任务也会发送到底层任务队列中排队执行，但这里使用的队列和agent所用的不是同一个队列。不同的labspaceid用于指定往底层不同的队列中发送任务。即agent与底层系统使用两个不同的labspaceid(可参见图3所示的示意图)。
93.底层队列的设计架构十分便于判断某一时刻是否有内部实验正在进行。使用实验队列的labspaceid去请求即可获取队列中的实验信息。接着通过检索状态为received或running的下的实验便可判断是否由于占用机时而将agent切换到busy状态。
94.监控组件架构
95.基于当前agent状态管理的实现，agent本身和修改agent状态没有紧密耦合在一起，切换状态只需要请求服务端和agent无关。再考虑到agent目前容器化部署在kubernetes集群中的实现方法。结合以上两点可以将复杂的监控功能作为独立服务的可能。假如将监控组件直接集成到agent中作为单体应用的一部分，会大幅增加agent系统复杂度和系统负荷，而且需要对代码架构做大规模修改。
96.因此本实施例在架构上选择将监控组件作为单独容器部署独立的微服务，让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隔离，避免作为辅助功能的监控组件异常时导致主业务受影响。
97.监控组件功能
98.监控组件监听内部实验占用和硬件错误两类超时原因，并且对这两类异常的处理是不同的。下述会分别介绍当这两类异常发生时监控组件内部的功能逻辑。
99.监控组件收到来自agent的超时预警后，需要判断造成超时的原因是否由内部实验占用机时导致。这里的判断方法参考底层队列架构，通过请求内部实验队列(需要预先将内部任务队列的labspaceid和token配置给agent-monitor容器对象)查看是否有正在进行中的实验，此时使用被动模式查询平均两次内部实验汇报之间的时间差tgap。预设时间t(预设时间通常与底层系统实验方法有关，例如每个内部实验的平均处理耗时作为超时时间)，tgap首次设置为tgap＝t。此时发生了第一次超时事件。
100.发现超时后，首先agent-monitor会改为主动模式，使用token去labspaceid_quantum_lab_dev取当前实验号num1以及当前系统时间t1，在预设时间t后，发起再次请求取当前实验号num2以及当前系统时间t2(需要注意的是考虑底层处理能力情况下，大多情况下t2》t1+t)，此时比较任务号num1和num2之间的差异。
101.如果num1≠num2，则认为造成超时的原因是内部实验占用导致，此时监控组件请求服务端将agent状态切换到busy。修改后agent将自己挂起不再接收任务(任务在服务端队列中不会超时，挂起agent避免将任务送到底层队列导致超时)，前端则会同步服务端agent状态并将内部实验中的信息反馈给用户。
102.如果num1＝num2，则认为底层出错(硬件错误或者超大电路，或者底层编译出错)。除了做超时动作，这时监控组件请求服务端先将agent状态切换到busy，修改后agent将自己挂起不再接收任务(任务在服务端队列中不会超时，挂起agent避免将任务送到底层队列导致超时)，前端则会同步服务端agent状态并将内部实验中的信息反馈给用户。同时，还需要做如后额外的警告步骤:，对于来自底层硬件的报错，不依靠人工排查，完全自动化处理其实是十分困难的。这类错误中有部分源自于当前量子设备的不稳定性。设备可能受环境温度、元器件震动等因素影响，错误可能是临时的，下一次运行时假如系统恢复稳定便可正常运行。
103.因此，考虑到以上情况，监控组件收到这类预警不会立即将agent修改为下线状态，而是第一时间发出携带任务号和错误信息的报警邮件到预留的管理员邮箱。之后监控组件在本地另外发起两到三次电路任务用于检查，如果都捕获到异常则认为该错误不能短时间内恢复，自动将agent切换到下线状态。如果用于检查的电路任务正常运行，则继续监
听端口。假如将agent下线，状态恢复则需要人为操作，没有其它判断机制。
104.监控组件完成将agent下线后，对实验队列开启折半轮询。因为需要同时考虑排队原因和底层原因两种不同情况，仅仅判断任务号处理并不足够可以将agent系统重新上线，采用策略折半-维持方式，确保量子qpu执行能力恢复，在超时预警步骤处理完后，如果是底层出错原因更新tgap＝2
×
t，此时是在预设情况下因为底层出错发生了问题，我们延长探测时间，并且进入被动模式，等待下一次判断。在下一次发生时更新为tgap＝4
×
t以此类推tgap＝2n
×
t，其中n为探测的次数，直到tgap》＝tmax，tmax是预设最大值，此时表示系统逐渐进入严重拥塞；如果是因内部实验占用导致超时，则会折半探测时间等待下一次判断，更新tgap＝1/2
×
t进行折半缩减直到tgap＝t，认为目前队列已经恢复正常，则会重置agent状态。
105.上述判别流程具体可参见图8所示的流程示意图。
106.本实施例所提供的上述方案为qpu agent提供了自动化状态流转的实现途径，也为qpu agent首次提供了对上游硬件设备的校验机制，携带监控组件的agent更加关注底层设备可用性，配合邮件预警系统，提升agent对上游错误的发现和反馈能力。从内部使用角度看，监控组件替研发人员在实验时及时反馈外部用户，帮助研发人员用最快速度对硬件报错做初步检查和应急处理；从用户使用角度看，该技术方案支持及时向用户同步平台接入量子设备的对外服务状态，有效避免将硬件错误持续暴露给用户，更避免了内部占用而给用户造成服务不可用的错误印象。起到辅助研发人员处理异常和提升用户使用体验的作用，帮助平台更具竞争力。
107.进一步参考图9，作为对上述各图所示方法的实现，本公开提供了一种量子电路任务超时原因确定装置的一个实施例，该装置实施例与图2所示的方法实施例相对应，该装置具体可以应用于各种电子设备中。
108.如图9所示，本实施例的量子电路任务超时原因确定装置900可以包括：内部实验运行查询单元901、第一超时原因返回单元902、第二超时原因返回单元903。其中，内部实验运行查询单元901，被配置成响应于外部传入的量子电路任务处理超时，查询内部实验队列确定是否存在处于运行状态的内部实验；第一超时原因返回单元902，被配置成响应于确定存在处于运行状态的内部实验，返回因内部实验占用的第一超时原因；第二超时原因返回单元903，被配置成响应于无法确定存在处于运行状态的内部实验，返回疑似量子设备出现硬件异常的第二超时原因。
109.在本实施例中，量子电路任务超时原因确定装置900中：内部实验运行查询单元901、第一超时原因返回单元902、第二超时原因返回单元903的具体处理及其所带来的技术效果可分别参考图2对应实施例中的步骤201-203的相关说明，在此不再赘述。
110.在本实施例的一些可选的实现方式中，内部实验运行查询单元901可以被进一步配置成：
111.在间隔第一预设时长的前后，分别查询内部实验队列中处于队首的实验任务编号，得到第一编号和第二编号；
112.响应于第一编号不同于第二编号，确定存在处于运行状态的内部实验；
113.响应于第一编号与第二编号相同，无法确定存在处于运行状态的内部实验。
114.在本实施例的一些可选的实现方式中，量子电路任务超时原因确定装置900还可
以包括：
115.忙碌状态调整单元，被配置成根据返回的第一超时原因，将量子设备的使用状态调整为不接受外部任务传入的忙碌状态。
116.在本实施例的一些可选的实现方式中，量子电路任务超时原因确定装置900还可以包括：
117.内部实验运行完成查询单元，被配置成在量子设备处于忙碌状态的过程中，每隔第二预设时长查询内部实验队列中是否均为处于运行完成状态的内部实验；
118.空闲状态调整单元，被配置成响应于查询到内存实验队列中均为处于运行完成状态的内部实验，将量子设备的使用状态调整为接受外部任务传入的空闲状态。
119.在本实施例的一些可选的实现方式中，量子电路任务超时原因确定装置900还可以包括：
120.硬件异常警告发送单元，被配置成根据返回的第二超时原因，通过预设路径向量子设备的管理对象发送硬件异常警告。
121.在本实施例的一些可选的实现方式中，量子电路任务超时原因确定装置900还可以包括：
122.疑似故障状态调整单元，被配置成根据返回的第二超时原因，将量子设备的使用状态调整为不接受所有任务传入的疑似故障状态。
123.在本实施例的一些可选的实现方式中，量子电路任务超时原因确定装置900还可以包括：
124.测试任务下发单元，被配置成根据返回的第二超时原因，暂停所有已下发任务，并向量子设备连续下发多项测试任务；
125.第三超时原因返回单元，被配置成响应于多项测试任务均处理超时，返回确认硬件异常的第三超时原因。
126.在本实施例的一些可选的实现方式中，量子电路任务超时原因确定装置900还可以包括：
127.故障状态调整单元，被配置成根据返回的第三超时原因，将量子设备的使用状态调整为不可使用的故障状态。
128.本实施例作为对应于上述方法实施例的装置实施例存在，在确认有外部传入的量子电路任务出现处理超时的情况下，通过在预设的初始时间间隔的前后分两次查询内部实验队列中处于队首位置的处于运行状态的内部实验编号，并在经对比后确认两次查询得到的内部实验编号不同时，可确定超时原因为内部实验运行占用，反之则将超时原因确定为疑似硬件异常，由于该初始时间间隔的时长大于一个内部实验的平均运行耗时，因此能够确认具体是因为哪种原因导致外部传入的量子电路任务处理超时，得以使任务发起者在明确具体超时原因的情况下不再重复发起任务，避免因任务队列包含重复任务而浪费有限且宝贵的量子运算资源。
129.根据本公开的实施例，本公开还提供了一种电子设备，该电子设备包括：至少一个处理器；以及与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的指令，该指令被至少一个处理器执行，以使至少一个处理器执行时能够实现上述任意实施例所描述的量子电路任务超时原因确定方法。
130.根据本公开的实施例，本公开还提供了一种可读存储介质，该可读存储介质存储有计算机指令，该计算机指令用于使计算机执行时能够实现上述任意实施例所描述的量子电路任务超时原因确定方法。
131.根据本公开的实施例，本公开还提供了一种计算机程序产品，该计算机程序在被处理器执行时能够实现上述任意实施例所描述的量子电路任务超时原因确定方法。
132.图10示出了可以用来实施本公开的实施例的示例电子设备1000的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。
133.如图10所示，设备1000包括计算单元1001，其可以根据存储在只读存储器(rom)1002中的计算机程序或者从存储单元1008加载到随机访问存储器(ram)1003中的计算机程序，来执行各种适当的动作和处理。在ram 1003中，还可存储设备1000操作所需的各种程序和数据。计算单元1001、rom 1002以及ram 1003通过总线1004彼此相连。输入/输出(i/o)接口1005也连接至总线1004。
134.设备1000中的多个部件连接至i/o接口1005，包括：输入单元1006，例如键盘、鼠标等；输出单元1007，例如各种类型的显示器、扬声器等；存储单元1008，例如磁盘、光盘等；以及通信单元1009，例如网卡、调制解调器、无线通信收发机等。通信单元1009允许设备1000通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。
135.计算单元1001可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元1001的一些示例包括但不限于中央处理单元(cpu)、图形处理单元(gpu)、各种专用的人工智能(ai)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(dsp)、以及任何适当的处理器、控制器、微控制器等。计算单元1001执行上文所描述的各个方法和处理，例如量子电路任务超时原因确定方法。例如，在一些实施例中，量子电路任务超时原因确定方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元1008。在一些实施例中，计算机程序的部分或者全部可以经由rom 1002和/或通信单元1009而被载入和/或安装到设备1000上。当计算机程序加载到ram 1003并由计算单元1001执行时，可以执行上文描述的量子电路任务超时原因确定方法的一个或多个步骤。备选地，在其他实施例中，计算单元1001可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行量子电路任务超时原因确定方法。
136.本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(fpga)、专用集成电路(asic)、专用标准产品(assp)、芯片上系统的系统(soc)、负载可编程逻辑设备(cpld)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。
137.用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。
138.在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦除可编程只读存储器(eprom或快闪存储器)、光纤、便捷式紧凑盘只读存储器(cd-rom)、光学储存设备、磁储存设备、或上述内容的任何合适组合。
139.为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，crt(阴极射线管)或者lcd(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。
140.可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(lan)、广域网(wan)和互联网。
141.计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，又称为云计算服务器或云主机，是云计算服务体系中的一项主机产品，以解决传统物理主机与虚拟专用服务器(vps，virtual private server)服务中存在的管理难度大，业务扩展性弱的缺陷。
142.根据本公开实施例的技术方案，在确认有外部传入的量子电路任务出现处理超时的情况下，通过在预设的初始时间间隔的前后分两次查询内部实验队列中处于队首位置的处于运行状态的内部实验编号，并在经对比后确认两次查询得到的内部实验编号不同时，可确定超时原因为内部实验运行占用，反之则将超时原因确定为疑似硬件异常，由于该初始时间间隔的时长大于一个内部实验的平均运行耗时，因此能够确认具体是因为哪种原因导致外部传入的量子电路任务处理超时，得以使任务发起者在明确具体超时原因的情况下不再重复发起任务，避免因任务队列包含重复任务而浪费有限且宝贵的量子运算资源。
143.应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例
如，本发公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。
144.上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。