An Adaptive Scheduling Method for Computing Resources in a Quantum Computing Cloud Platform

Abstract

This invention relates to the field of quantum computing technology and discloses an adaptive scheduling method for computing resources in a quantum computing cloud platform. The method first parses the quantum script to construct a logical topology, then combines the real-time physical characteristics of heterogeneous resources to perform topology depth matching through basic constraint screening and the VF2 subgraph isomorphism algorithm. Subsequently, weighted scoring and ranking are performed based on normalized multidimensional performance indicators to generate a recommended list. Finally, the task is translated and submitted, and the execution process data is fed back to update resource indicators in a closed loop. This invention uses the VF2 algorithm to perform subgraph isomorphism matching between the logical bit coupling relationship and the physical bit coupling topology information of the computing resources. This automatically verifies whether the physical connection structure of the computing resources meets the logical connection requirements of the quantum program. During the task scheduling phase, resources that cannot be executed or have excessive mapping costs due to physical topology mismatch are excluded, ensuring the physical executability of the selected resources.

Description

Technical Field

[0001] This invention relates to the field of quantum computing technology, specifically to an adaptive scheduling method for computing resources in a quantum computing cloud platform. Background Technology

[0002] With the rapid development of quantum computing technology, quantum computing is gradually moving from laboratory environments to cloud service models. Quantum Computing as a Service (QCaaS) based on cloud platforms has become the main way for researchers and developers to access quantum computing power. Currently, quantum computers with various physical realization routes, including superconducting, ion trap, and optical quantum computing, are made available to the public through the cloud, forming a multi-source heterogeneous computing resource environment.

[0003] However, in the current process of resource scheduling and adaptation in quantum cloud platforms, there is a common gap between the logic program and the physical hardware. Due to the era of Noisy Medium-Scale Quantum (NISQ), real quantum processors are limited by physical manufacturing processes, and their qubits are not fully connected, but rather exhibit a specific coupled topology. Existing scheduling techniques often lack in-depth pre-verification of this physical topology constraint. As a result, when user-written general quantum programs are deployed to specific hardware, they often cannot be executed because the connection requirements of the logic bits exceed the actual coupling capacity of the physical bits, or they are forced to insert a large number of SWAP gate operations to satisfy connectivity, resulting in a sharp increase in circuit depth, which in turn severely reduces the fidelity of the computation results due to noise accumulation.

[0004] Furthermore, quantum computing resources exhibit extremely high environmental sensitivity and performance drift characteristics, with key parameters such as coherence time and gate fidelity fluctuating significantly over time. Existing resource evaluation systems largely rely on periodic calibration data or nominal static parameters provided by hardware manufacturers. This data is often outdated and fails to reflect the current instantaneous health status of the equipment. This scheduling mode, lacking a real-time feedback mechanism, easily leads to the system assigning tasks to computing nodes with excellent nominal parameters but actually experiencing performance dips or malfunctions, resulting in high and difficult-to-reproduce task failure rates.

[0005] Meanwhile, faced with vastly different heterogeneous computing resources, existing scheduling strategies typically employ single-dimensional evaluation criteria, such as considering only queue length or bit count. They lack a quantitative evaluation model that comprehensively considers multi-dimensional indicators such as computational cost, execution accuracy, and response speed. This makes it difficult for users to make optimal decisions based on their business needs (such as scientific research verification or teaching demonstrations) when faced with resources with different characteristics, such as high-cost, high-precision and low-cost, low-precision resources. This results in expensive high-fidelity computing power being occupied by low-value tasks, or high-precision tasks being forced to run on low-performance machines, leading to a need to improve both resource utilization efficiency and user experience. Summary of the Invention

[0006] To address the shortcomings of existing technologies, this invention provides an adaptive scheduling method for computing resources in quantum computing cloud platforms. This method solves the problems of difficulty in mapping user programs due to the diverse physical hardware topologies in quantum cloud platforms, as well as the low task execution fidelity and insufficient resource utilization caused by the lack of a unified multi-dimensional performance evaluation mechanism.

[0007] To achieve the above objectives, the present invention provides the following technical solution:

[0008] The first aspect of this invention provides an adaptive scheduling method for computing resources in a quantum computing cloud platform, the method comprising the following steps: A quantum computing resource pool is constructed and maintained. Each computing resource in the quantum computing resource pool includes basic characteristics, dynamic characteristics, and index characteristics. Among them, the dynamic characteristics include at least physical bit coupling topology information, which is used to characterize the connection structure between physical qubits in the quantum processor.

[0009] The system receives user-submitted general quantum assembly language program scripts. It parses these scripts, extracting the logical parameters required for the execution of the quantum task. These logical parameters include a list of quantum gates, the index of the largest qubit, and the logical qubit coupling relationships.

[0010] The computing resources are adapted and screened based on the aforementioned basic and dynamic characteristics. Specifically, this screening process involves: first, filtering out initial resources that meet preset conditions based on the basic characteristics (such as online status, maximum number of bits, and supported quantum gate types); then, for these initial resources, performing graph isomorphism matching between the logical bit coupling relationships extracted from the script and the physical bit coupling topology information of the computing resources. Through this matching process, a list of candidate resources whose physical topology can support the task's logical connection requirements is selected.

[0011] Obtain the user-specified or system-preset ranking weight strategy, combine the indicator features to perform weighted scoring on the resources in the candidate resource list, and generate a recommended resource list based on the scoring results.

[0012] Preferably, the following specific method is used when parsing the general quantum assembly language program script: The code iterates through each line of the general quantum assembly language program script, using regular expressions to match and extract quantum gate operators. After deduplication, a list of quantum gates is generated. All operation instructions involving qubits in the general quantum assembly language program script are scanned, and the qubit number values ​​are extracted. The largest extracted value is determined as the maximum qubit index, and the number of different qubits actually used is counted. Gate operation instructions involving multiple qubits (e.g., controlled NOT gate CNOT, swap gate SWAP, etc.) in the general quantum assembly language program script are scanned, and the two qubit numbers involved in each instruction are extracted. These two qubit numbers are established as a node pair with a connection relationship, thereby generating the logical bit coupling relationship.

[0013] In one specific embodiment, the process of performing graph isomorphic matching between the logical bit coupling relationships and the physical bit coupling topology information of the computing resources is implemented using the VF2 algorithm. Specific steps include: constructing a screening mesh graph, defining the qubits actually used in the general quantum assembly language program script as nodes and the logical bit coupling relationships as edges; constructing an initial mesh graph, defining the currently available bits of the computing resources as nodes and the bit couplings in the physical structure of the computing resources as edges; and calling the VF2 algorithm to detect whether the screening mesh graph is isomorphic to any subgraph of the initial mesh graph. If the detection result is yes, the computing resource is determined to meet the topology connectivity requirements, and the computing resource is added to the candidate resource list.

[0014] Preferably, the method for maintaining the dynamic characteristics in the quantum computing resource pool includes: the system receiving topology data pushed periodically by the quantum computer manufacturer, the topology data including a list of available bits and a list of bit couplings; the system parsing the topology data and updating the list of available single bits and the physical bit coupling topology of the corresponding computing resources in real time; and simultaneously, the system monitoring and updating the online status of the computing resources in real time.

[0015] Preferably, the method for maintaining the indicator characteristics in the quantum computing resource pool includes: the system receiving callback data after a quantum task has been executed on the computing resources, the callback data including the task execution status and runtime; and periodically recalculating and refreshing the statistical indicators of the computing resources based on the callback data and historical stored data. The statistical indicators include at least the average task execution time, task success rate, single-qubit fidelity, and average cost.

[0016] In one specific embodiment, the single-bit fidelity is calculated as follows: the first relaxation time fidelity and the second decoherence time fidelity are obtained from the computing resource calibration data; the arithmetic mean of the first relaxation time fidelity and the second decoherence time fidelity is calculated, and the arithmetic mean is used as the single-bit fidelity.

[0017] In one specific embodiment, the average cost is calculated as follows: obtain the single task cost, task operation rate, and average task time of the computing resource; calculate the product of the task operation rate and the average task time, and add the product to the single task cost to obtain the average cost.

[0018] Preferably, the specific process of weighted scoring of resources in the candidate resource list includes: determining the weight values ​​of four dimensions: average cost, single-bit fidelity, average task execution time, and task success rate, with the sum of the weight values ​​of the four dimensions being one; for each candidate resource, calculating the product of average cost and average cost weight, the product of single-bit fidelity and single-bit fidelity weight, the product of average task execution time and average task execution time weight, and the product of task success rate and task success rate weight; and adding the above four products to obtain the comprehensive score of the candidate resource.

[0019] Preferably, after generating the recommended resource list, the method further includes: receiving an instruction from a user to select a target computing resource from the recommended resource list; associating the general quantum assembly language program script with the target computing resource and constructing a task for submission; and after the task is executed, feeding back the execution result to the computing power adaptation service to trigger the update of the indicator features, thereby achieving closed-loop maintenance of the indicator features.

[0020] A second aspect of the present invention provides a computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the method described in the first aspect.

[0021] The technical solution provided by this invention directly extracts the logical topology requirements of quantum tasks by automatically parsing general-purpose quantum assembly language program scripts, and uses a graph isomorphism matching algorithm to accurately compare the logical topology with the physical topology of computing resources, thus achieving automated screening of computing resources. This solution avoids the tedious process of users manually comparing the connectivity of quantum circuits with the physical structure of chips, ensuring that the screened computing resources can directly support or support the execution of quantum programs through mapping in terms of physical connectivity. Simultaneously, by combining multi-dimensional indicator features (cost, fidelity, time consumption, success rate) based on real-time callback data updates for weighted ranking, resources can be recommended according to the actual execution performance of the task, adapting to the characteristics of large fluctuations and strong heterogeneity of quantum computing resources.

[0022] This invention provides an adaptive scheduling method for computing resources in a quantum computing cloud platform. It offers the following advantages: 1. This invention extracts logical bit coupling relationships by parsing general quantum assembly language program scripts, and uses the VF2 algorithm to perform subgraph isomorphic matching of the logical relationships with the physical bit coupling topology information of the computing resources. This technique can automatically verify whether the physical connection structure of the computing resources meets the logical connection requirements of the quantum program. During the task scheduling stage, resources that cannot be executed or have excessive mapping costs due to physical topology mismatch are excluded, ensuring the physical executability of the selected resources.

[0023] 2. This invention utilizes callback data after task execution to establish a closed-loop maintenance mechanism for indicator characteristics. By collecting task execution status and runtime in real time, it dynamically refreshes statistical indicators such as task success rate and average time consumption. This update method based on historical measured data can objectively reflect the current real-time operational stability and health status of computing resources, correcting the deviations that may exist if only relying on the manufacturer's nominal static parameters, thereby reducing the risk of scheduling tasks to resources with nominal parameters that are normal but are actually in a faulty or high-noise state.

[0024] 3. This invention implements a multi-dimensional weighted ranking strategy based on average cost, single-bit fidelity, average task execution time, and task success rate. By combining performance indicators of different dimensions with user-defined weight strategies for comprehensive scoring, this method can quantitatively evaluate the applicability of heterogeneous quantum computing resources in different demand scenarios. Under the premise of satisfying physical topological constraints, it can output an optimal resource recommendation list based on the user's preference for cost, accuracy, or speed. Attached Figure Description

[0025] Figure 1 This is a system architecture diagram of an embodiment of the present invention; Figure 2 This is a schematic diagram of the overall adaptive scheduling scheme for computing resources according to an embodiment of the present invention; Figure 3 This is a flowchart of the quantum program script parsing and logic topology construction according to an embodiment of the present invention; Figure 4 This is a schematic diagram illustrating a bit coupling filtering example according to an embodiment of the present invention; Figure 5 This is a flowchart illustrating the multi-dimensional weighted scoring and resource recommendation list generation process according to an embodiment of the present invention. Figure 6 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of the present invention.

[0026] Among them, 101 is the script parsing module; 102 is the feature summarization module; 103 is the feature adaptation module; 104 is the result sorting module; and 105 is the computing power adaptation service module. Detailed Implementation

[0027] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0028] See attached document Figure 1 Appendix Figure 2 and attached Figure 6 This invention provides an adaptive scheduling method for computing resources in a quantum computing cloud platform. This method operates on a system architecture comprising multiple functional modules. The system mainly includes a script parsing module 101, a feature aggregation module 102, a feature adaptation module 103, a result sorting module 104, and a computing power adaptation service module 105. The modules are connected and interact with each other via a data bus or API interface, jointly achieving closed-loop control from user task input to precise matching of computing resources and execution feedback.

[0029] The script parsing module 101 is configured to receive user-submitted general quantum assembly language program scripts. This module uses a built-in text analysis engine to scan and parse the input script line by line. The goal of the parsing is to extract key parameters characterizing the computational logic of the quantum task. These parameters include, but are not limited to, the list of quantum gate operations, the maximum bit index, and logical bit coupling relationships. Logical bit coupling relationships reflect the connection requirements between qubits in multi-qubit gate operations within the program and are a core basis for subsequent resource selection.

[0030] The feature aggregation module 102 is configured to build and dynamically maintain a quantum computing resource feature library. This module communicates with the underlying physical quantum computer or simulator cluster, collecting and storing multi-dimensional attributes of the computing resources in real time. Each computing resource in the feature library is defined as a data structure containing three types of features: basic features, dynamic features, and index features. Basic features include the resource type, technical approach, maximum number of qubits, and supported quantum gate set; dynamic features include the resource's online status and physical qubit coupling topology information; index features include average task execution time, task success rate, single-qubit fidelity, and average cost, statistically derived from historical running data.

[0031] The feature adaptation module 103 is connected to the script parsing module 101 and the feature aggregation module 102, receiving task logic parameters from the script parsing module 101 and resource feature data from the feature aggregation module 102. The feature adaptation module 103 performs a two-level filtering logic: the first level is hard filtering based on basic features, eliminating resources that are offline in online status, have a maximum number of bits less than the task requirements, or do not support specific quantum gates; the second level is deep matching based on topology, using the VF2 subgraph isomorphism algorithm to map the logical bit coupling relationship of the task to the physical bit coupling topology information of the computing resources. Only when the physical topology of a computing resource contains a subgraph isomorphic to the logical topology of the task is the resource determined to meet the topology connection requirements and enters the candidate resource list.

[0032] The result ranking module 104 is configured to perform multi-dimensional weighted scoring on the resources in the candidate resource list. This module receives a user-specified or system-preset ranking weight strategy and, combined with the indicator features provided by the feature aggregation module 102, calculates a comprehensive score for each candidate resource. The system generates a final recommended resource list based on the comprehensive scores, for user selection or automatic system scheduling.

[0033] The computing power adaptation service module 105 is responsible for task submission, execution, and result feedback. Once a target computing resource is selected, the computing power adaptation service module 105 associates a general quantum assembly language program script with that resource and triggers its execution. After task execution is complete, the computing power adaptation service module 105 receives callback data containing execution status and runtime, and feeds this data back to the feature aggregation module 102. The feature aggregation module 102 recalculates and refreshes the corresponding resource's indicator characteristics based on the feedback data, thereby achieving adaptive closed-loop updates of the scheduling system.

[0034] In the result ranking module 104, the process of weighted scoring of candidate resources involves calculating the overall score. The system calculates the overall score for each candidate resource according to the following formula: ; in, This represents the overall score of the candidate resources; The weighting coefficient representing the average cost; This represents the normalized average cost index value. Weighting coefficients representing the fidelity of a single bit; This represents the normalized single-bit fidelity index value. Weighting coefficients representing the average execution time of tasks; This represents the normalized average task execution time. Weighting coefficients representing the success rate of a task; This represents the normalized task success rate metric. Weighting coefficients. , , , The sum of them equals 1.

[0035] The system's workflow begins with the initialization and maintenance of the resource pool by the feature aggregation module 102. This module periodically receives machine status data pushed by the quantum computer manufacturer's interface. This data includes a list of currently available physical bits and a list of coupling connections between bits. The feature aggregation module 102 parses this data and updates the physical bit coupling topology information of each resource in its local database, ensuring that scheduling decisions are based on the latest physical hardware status. Simultaneously, the feature aggregation module 102 continuously monitors the execution results fed back by the computing power adaptation service module 105 and dynamically updates the indicator features.

[0036] When a user submits a general quantum assembly language program script through the client, the script parsing module 101 immediately starts the parsing process. The script parsing module 101 uses regular expressions to match the quantum gate instructions in the script, extracts all involved qubit numbers, and calculates the maximum number of logical bits required for the task and the actual number of bits used. Simultaneously, the script parsing module 101 identifies all multi-bit gate operation instructions in the script, extracts the control bit and target bit pairs involved in each instruction, and constructs the logical bit coupling diagram of the task.

[0037] Subsequently, the feature adaptation module 103 retrieves the current resource feature library and first performs an initial screening of all online resources based on the maximum number of bits and the set of supporting gates. For resources that pass the initial screening, the feature adaptation module 103 constructs a physical topology graph and uses the logical bit coupling graph output by the script parsing module 101 as the target subgraph, calling the VF2 algorithm to perform subgraph isomorphism detection. This detection process determines whether there exists a substructure in the physical topology graph whose node connection relationship is completely consistent with the logical bit coupling graph. If the detection result is true, it means that the physical machine can directly carry the quantum program without additional gate swapping operations or with very little mapping cost, and the resource is then added to the candidate resource list.

[0038] Finally, the result ranking module 104 obtains the corresponding weight vector based on the currently activated ranking strategy (e.g., cost-first strategy or fidelity-first strategy). The result ranking module 104 reads the average cost, single-bit fidelity, average task execution time, and task success rate data for each resource in the candidate resource list, and substitutes them into the aforementioned comprehensive score formula for calculation. The resource list is sorted in descending or ascending order according to the calculated S value, generating a recommendation list presented to the user. After user confirmation, the task is submitted to a physical machine for execution. After execution, the actual time consumption and status data generated are fed back to the feature aggregation module 102, completing one full adaptive scheduling cycle.

[0039] See attached document Figure 1 and attached Figure 2 The quantum computing resource pool maintained by the feature aggregation module 102 adopts a hierarchical three-dimensional feature definition structure. This structure aims to comprehensively quantify and describe the static attributes and dynamic capabilities of heterogeneous computing resources, enabling the scheduling system to manage resources across platforms based on a unified data standard. The feature aggregation module 102 establishes a unique identity for each connected computing resource and associates it with three sets of feature data: basic features, dynamic features, and indicator features.

[0040] The fundamental characteristics describe the inherent physical properties and technical specifications of computing resources, which typically remain unchanged throughout the resource's lifecycle. These fundamental characteristics specifically include resource type, technology approach, maximum number of qubits, and supported quantum gate set. The resource type distinguishes between a physical quantum computer and quantum simulator software. The technology approach field identifies the physical implementation of the underlying hardware, including but not limited to superconducting quantum computing, ion trap quantum computing, optical quantum computing, neutral atom quantum computing, and nuclear magnetic resonance quantum computing. The maximum number of qubits defines the upper limit on the total number of qubits physically possessed by the resource. The supported quantum gate set stores, in list form, the types of native quantum gate operations that the underlying hardware of the resource can directly execute, such as a single-qubit rotation gate or a two-qubit controlled NOT gate.

[0041] Dynamic features describe the operational state of computing resources over time, and these features are updated in real-time by the feature aggregation module 102 based on external input. Dynamic features mainly include online status and physical bit coupling topology information. Online status is a Boolean value indicating whether the resource is currently active for an acceptable task. Physical bit coupling topology information is the core of the dynamic features; it is stored in the form of a graph-theoretic data structure and precisely describes the list of actually available qubits on the physical machine at the current moment and the physical coupling connections between these qubits. Since qubits in a quantum processor may be temporarily unavailable due to calibration failures or hardware malfunctions, the physical bit coupling topology information dynamically reflects an effective subset of the maximum number of qubits and their interconnection structure.

[0042] The metrics describe the statistical performance of computing resources in historical task execution, and are used to quantitatively evaluate the performance and cost of the resources. The metrics are calculated by the feature aggregation module 102 based on closed-loop feedback data, and specifically include average task time, task success rate, single-bit fidelity, and average cost.

[0043] Among them, single-qubit fidelity is a key indicator for measuring the operational accuracy of qubits. The feature aggregation module 102 calculates the single-qubit fidelity using the following formula, based on the latest calibration data provided by the quantum computer manufacturer: ; in, A metric representing the single-bit fidelity of computing resources; Indicated based on energy relaxation time ( The fidelity component measured over time; Indicated based on decoherence time ( The fidelity component measured over time.

[0044] Average cost is a metric that measures the economic investment required by a user to use a resource to perform a task. The feature aggregation module 102 combines billing rules and historical operational data to calculate the average cost using the following formula: ; in, This represents the average cost metric for computing resources; This represents the fixed base cost required to initiate a quantum mission; This indicates the rate per unit of runtime for the computing resource; This indicates the average time taken for the computing resource to successfully execute tasks within the historical statistical period.

[0045] The feature aggregation module 102 stores the aforementioned three-dimensional feature data in a high-performance cache database and provides a query interface. After the script parsing module 101 completes task parsing, the feature adaptation module 103 calls this interface to obtain the basic and dynamic features of all online resources for filtering. After filtering is completed, the result sorting module 104 calls this interface to obtain the indicator features of the candidate resources for weighted calculation. Through this structured feature definition, the system achieves standardized measurement of quantum computing resources with different technical routes and performance levels.

[0046] See attached document Figure 1 and attached Figure 2 The feature aggregation module 102 maintains dynamic features by actively receiving and parsing real-time status push data from quantum computing hardware vendors. To achieve this mechanism, the feature aggregation module 102 is configured with a dedicated data listening interface (Webhook) or message queue consumer client to maintain communication connections with quantum computer control systems using different technological approaches. The connection supports receiving standardized data formats, such as status messages in JSON or XML format.

[0047] When the feature aggregation module 102 receives the topology data packet pushed by the vendor, it first performs data integrity verification and timestamp comparison to ensure that the processed data is up-to-date. The data packet contains a unique resource identifier, global operating status, a list of currently available physical bits, and a physical bit coupling graph. The feature aggregation module 102 first parses the global operating status field. If this field indicates that the resource is under maintenance, calibration, or offline due to a fault, it immediately updates the online status of the resource in the local database to unavailable and suspends the distribution of new computing tasks to it.

[0048] If the global operating status indicates that the resources are online, the feature aggregation module 102 further parses the topology data to construct physical bit coupling topology information. This process is not simply data overwriting, but includes dynamic graph construction logic based on the current hardware status. The feature aggregation module 102 reads the list of available physical bits, which excludes physical qubits that are currently temporarily masked due to manufacturing defects, calibration failures, or excessive thermal noise. Subsequently, the feature aggregation module 102 reads the physical bit coupling graph, which is typically provided in the form of an edge list or adjacency list, describing physically adjacent qubit pairs on the chip that are allowed to interact with two-bit gates.

[0049] When updating the physical bit coupling topology, the feature aggregation module 102 performs a validity filtering operation. For each connection edge in the coupling graph, the system checks whether both endpoint qubits of the edge exist in the aforementioned list of available physical bits. Only when both endpoints of the connection edge are available is the edge retained and constructed as a valid undirected or directed edge in the local graph database. Through this process, the physical topology graph constructed by the feature aggregation module 102 accurately reflects the actual connectivity of the quantum processor at the current moment, automatically eliminating invalid paths containing faulty bits. This dynamic topology update mechanism ensures that the graph isomorphic matching performed by the subsequent feature adaptation module 103 is based on real and available hardware links, avoiding mapping tasks to physical regions containing bad bits.

[0050] In addition, the feature aggregation module 102 will also analyze parameters such as single-bit and double-bit gate error rates, readout error rates, relaxation time, and decoherence time contained in the pushed data. Although these parameters are mainly used to calculate the aforementioned single-bit fidelity index, if certain key parameters (such as the readout error rate) exceed the preset safety threshold, the feature aggregation module 102 will also trigger a logical judgment to remove the corresponding qubit from the available list and trigger the reconstruction of the physical topology graph. In this way, even if the hardware is not completely damaged at the physical level but its performance is severely degraded, logical isolation and circuit breaker protection at the software level can be achieved.

[0051] See attached document Figure 1 and attached Figure 2 In addition to processing static and dynamic topology data pushed by vendors, the feature aggregation module 102 also achieves closed-loop updates of indicator features by receiving feedback data after task execution. This mechanism mainly relies on asynchronous communication between the computing power adaptation service module 105 and the feature aggregation module 102. When the computing power adaptation service module 105 submits the quantum assembly script to the physical machine for execution and receives a completion signal, the feature aggregation module 102 automatically generates a callback message containing task execution metadata. The data structure of the callback message includes at least the task's unique identifier, the identifier of the computing resources used, the task's final status (success, failure, or timeout), and the actual runtime of the task.

[0052] Upon receiving the callback message, the feature aggregation module 102 triggers a recalculation process for statistical indicators specific to the computing resource. The feature aggregation module 102 maintains historical data using a sliding time window or cumulative counting method to balance the real-time sensitivity and statistical stability of the indicators. For the task success rate indicator, the feature aggregation module 102 reads the total number of task submissions and successful executions for that resource within the statistical period and updates the task success rate using the following formula: ; in, This indicates the current task success rate of computing resources; This indicates the cumulative number of tasks that returned a successful status within the statistical window period for this resource; This indicates the total number of task scheduling requests received by the resource within the statistical window period. If The system assigns zero. A preset initial value. For the average task execution time metric, the feature aggregation module 102 only filters task records with a success status in the callback messages. The feature aggregation module 102 accumulates the actual runtime of these tasks and updates the average task execution time using the following formula: ; in, This indicates the average time currently spent on computing resources; This represents the total runtime of all successful tasks within the statistical window period for that resource. The definition is consistent with the above. This metric not only reflects the gate operation speed of the quantum processor, but also implies the task queuing latency and the average time overhead required for quantum compilation optimization.

[0053] After completion After the update, the feature aggregation module 102 then uses the aforementioned average cost calculation formula, with the latest... The average cost metric for the resource is recalculated. Through this cascading update mechanism, the cost score of the resource in subsequent scheduling decisions is fine-tuned based on the execution result of each task.

[0054] Furthermore, the feature aggregation module 102 also has anomaly detection logic. If the callback message shows that a certain computing resource continuously displays specific error codes (such as a surge in read error rate or control pulse calibration failure), even if the vendor has not yet pushed an offline notification, the feature aggregation module 102 will force the success rate in the indicator features of that resource to be set to zero or an extremely low value. This dynamic adjustment based on actual test feedback ensures that the result ranking module 104 can automatically reduce the weight of faulty resources or exclude them in the next round of scheduling, thereby realizing adaptive health management of the computing resource pool.

[0055] See attached document Figure 3 The script parsing module 101 begins its processing of general quantum assembly language program scripts (such as OpenQASM format) with a rigorous preprocessing stage. The main goal of this stage is to convert the raw unstructured text data into a standardized sequence of instructions containing only valid execution logic, thereby eliminating the interference of code comments, whitespace characters, and non-standard formats on the accuracy of subsequent feature extraction.

[0056] The preprocessing process is first executed by the text loading unit. The script parsing module 101 receives the script file or string stream uploaded by the user and reads it using a unified UTF-8 encoding format. The system first scans the raw text line by line, performing a comment stripping operation. For the OpenQASM language specification, the system identifies comment markers that begin with double forward slashes / / . For each line of code, the preprocessing logic locates the / / symbol and truncates the symbol and all characters following it. This step is crucial, preventing commented-out obsolete quantum gate instructions or test code from being misidentified as valid computational requirements by subsequent regular expressions, thus ensuring the accuracy of resource requirement assessment.

[0057] After comment stripping, the system performs whitespace cleaning and instruction splitting. Since general-purpose quantum assembly language typically uses semicolons (;) as instruction terminators rather than simply newline characters, the preprocessing logic replaces newline characters (\n) and carriage returns (\r) in the stripped text stream with spaces. Then, it re-segments the text stream using semicolons as delimiters, generating a preliminary instruction list. For each element in the list, the system calls a string trimming function to remove leading and trailing redundant spaces and tabs. If the processed instruction string is empty or contains only whitespace characters, it is removed from the list.

[0058] Subsequently, the script parsing module 101 performs version and environment checks on the cleaned instruction list. The system scans the preceding instructions in the list, looking for version declaration statements that begin with OPENQASM. The system extracts the version number value and compares it with the built-in compatibility list. If the version number declared by the script (such as 2.0 or 3.0) is within the system's supported range, execution continues; otherwise, a format incompatibility exception is thrown. At the same time, the system checks for the existence of standard library reference instructions (such as include "qelib1.inc";). This check confirms that the basic quantum gates used in the script (such as h, cx, t, s, etc.) conform to the gate operation semantics defined by the standard, providing a semantic consistency guarantee for subsequently mapping these gates to the set of gates supported by the physical machine.

[0059] After the aforementioned preprocessing steps, the original script is transformed into an ordered, standardized, and efficient instruction queue. Each element in this queue is a complete, parsable quantum operation statement, containing no non-functional text. This instruction queue, serving as an intermediate data structure, is passed to the subsequent feature extraction logic for quantum gate list generation and logical topology construction. This preprocessing mechanism ensures that the system can robustly handle quantum programs written in different user styles (such as different indentation and commenting habits), guaranteeing the determinism and uniqueness of subsequent parsing steps.

[0060] See attached document Figure 3 After completing preprocessing, the script parsing module 101 enters the core feature extraction stage. The first task of this stage is to generate a deduplicated list of quantum gates, which will be used for subset verification against the set of gates supported by computing resources. The script parsing module 101 is configured with predefined gate operator regular expressions. The pattern of these expressions is designed to match string sequences that begin with a letter, are followed by any letter, number, or underscore, and terminate with whitespace or parentheses.

[0061] While traversing the preprocessed instruction queue, the script parsing module 101 applies a gate operator regular expression to each instruction. The system extracts the first consecutive character sequence at the beginning of the instruction line as a candidate operator. Subsequently, the system compares this candidate operator with a built-in list of NOT gate instruction keywords, which includes OPENQASM, include, qreg, creg, barrier, measure, and reset. If a candidate operator does not belong to the keyword list, the system identifies it as a valid quantum gate operator (e.g., h, cx, rz) and stores it in a hash set data structure. Utilizing the uniqueness of the hash set's keys, the system automatically filters out duplicate gate operators, ultimately exporting all elements from the hash set to generate the quantum gate list required for the task.

[0062] The second task of this phase is to determine the scale requirements of quantum tasks for qubit resources. The script parsing module 101 employs bit index scanning logic, parsing all operand portions of the instruction queue using a specific set of regular expressions. The regular expressions are designed to capture string structures in the form of register name[digit index] (e.g., q[0] or qubit

[15] ). The system scans each instruction containing qubit operations, extracting the integer values ​​within the square brackets.

[0063] During the scanning process, the system maintains an integer variable to record the maximum bit index and a separate data set to record the identifiers of the actual qubits used. For each extracted bit index value, the system compares it with the currently recorded maximum bit index. If the extracted value is greater than the currently recorded value, the maximum bit index is updated. Simultaneously, the system stores a unique identifier composed of the register name and the index value in the separate data set. After traversing all instructions, the system outputs the final determined maximum bit index and counts the total number of elements in the separate data set as the number of different qubits actually used. These two parameters are used to assess whether the computing resources have sufficient address space and the total number of physical bits to support the task, respectively, preventing failures due to index out-of-bounds errors or insufficient resources.

[0064] See attached document Figure 3 The script parsing module 101 further executes the parsing of multi-qubit gate operation instructions to construct logical bit coupling relationships characterizing the connectivity requirements of the quantum task. This process aims to extract all interacting qubit pairs in the quantum program and transform them into a set of edges in a graph theory model.

[0065] The script parsing module 101 has a pre-built list of multi-bit gate operators. This list contains all operators involving two or more qubits defined in the general quantum assembly language standard library, mainly including controlled NOT gates (CX), controlled phase gates (CZ, CP), swap gates (Swap), and Tolliver gates (CCX). During the traversal of the instruction queue, the system first checks whether the operator of the current instruction is included in the list of multi-bit gate operators. If a match is found, the system determines that the instruction defines a logical coupling constraint.

[0066] For instructions determined to be multi-bit gate operations, the system initiates operand parsing logic. General quantum assembly languages ​​typically use comma separators to distinguish different operands (e.g., cxq[0], q[1];). The system uses a string splitting function or a specific regular expression to divide the operand into independent substrings, delimited by commas. For each substring, the system again applies the aforementioned bit index extraction logic to parse out the specific qubit number. Taking a controlled NOT gate as an example, the system extracts the control bit number and the target bit number.

[0067] The system defines two extracted qubit numbers as a node pair, indicating a direct coupling dependency between these two logical qubits. To construct a concise and accurate logical topology graph, the system introduces a deduplication mechanism. During program execution, the same two qubits may undergo multiple multi-bit gate operations, or different types of multi-bit gate operations may be performed at different times. The script parsing module 101 maintains a set of edges based on a hash algorithm. For each newly extracted node pair, the system normalizes it (e.g., always placing the smaller number first, or maintaining the order according to the definition of directed / undirected graphs) and generates a unique edge identifier. The system checks whether this edge identifier already exists in the edge set; if not, it adds it.

[0068] After a full scan, the edge set stores all the unique qubit connections required by the quantum program. The script parsing module 101 combines this edge set with the previously extracted list of actually used qubits (as a node set) and instantiates it into a logical graph data structure. In this data structure, nodes represent qubits in the program logic, and edges represent coupling paths that must exist in the physical hardware. This logical graph constitutes the source input data for the subsequent feature adaptation module 103 to perform graph isomorphism matching. For gates involving three or more bits (such as ccx), the system decomposes them into equivalent two-bit gate sequences and then extracts the two-bit connections in the decomposed instructions, or directly extracts all pairwise combinations as coupling edges to ensure that the physical topology can support the decomposition and implementation of the multi-bit gate.

[0069] See attached document Figure 4 When initiating the computing resource screening process, the feature adaptation module 103 first performs a preliminary screening step based on basic features. This step aims to quickly remove resources from the massive resource pool that obviously cannot meet the hard constraints of task execution through scalar comparison operations with low computational complexity, thereby reducing the search space of the subsequent graph isomorphic matching algorithm and reducing the overall scheduling latency.

[0070] The feature adaptation module 103 establishes an iterative loop to traverse all computing resource records stored in the feature aggregation module 102. During the traversal, the feature adaptation module 103 first checks the online status field of each computing resource. The system performs Boolean logic judgments; if the online status of a computing resource is marked as offline, under maintenance, or faulty, the system immediately marks the resource as unqualified and skips subsequent checks for that resource, directly proceeding to the evaluation of the next resource. This mechanism ensures that the system will not attempt to distribute tasks to physically inaccessible hardware endpoints.

[0071] For computing resources deemed valid in the online state, the feature matching module 103 further performs matching based on the qubit scale capability. The feature matching module 103 retrieves the task's maximum bit index output by the script parsing module 101 and obtains the physical maximum number of bits from the basic features of the current computing resource. The system constructs numerical comparison logic to determine whether the physical maximum number of bits is strictly greater than the task's maximum bit index. This determination logic considers not only the total number of qubits but also, more importantly, the address space coverage capability.

[0072] If the maximum physical number of qubits is less than or equal to the maximum bit index of the task, it means that the quantum program is attempting to address a qubit number that does not exist on the physical chip, which will lead to a low-level compilation error or runtime overflow. Therefore, any resources that do not meet this condition are filtered out.

[0073] After passing the scale capability check, the feature adaptation module 103 performs a quantum gate instruction set compatibility verification. The feature adaptation module 103 obtains the task quantum gate list extracted by the script parsing module 101 and the set of quantum gates supported by the computing resources. The system performs set inclusion relation operations to check whether each element in the task quantum gate list is included in the quantum gate set, or whether it exists in the system's pre-set general instruction decomposition table. If a specific operator (e.g., a specific type of controlled rotation gate) exists in the task quantum gate list that is neither in the quantum gate set nor can be decomposed into a basic gate combination in the quantum gate set using standard compilation rules, the system determines that the resource has an instruction set architecture incompatibility and removes it from the candidate list.

[0074] After the aforementioned multiple logical filtering processes, the feature adaptation module 103 generates a preliminary list of qualified resources. This list only includes online computing resources with sufficient qubit address space and instruction set compatibility. This list is passed as an intermediate result to the subsequent topology depth matching unit, ensuring that computationally expensive graph algorithms are only applied to resource objects with basic execution potential.

[0075] See attached document Figure 4After completing the initial screening, the feature adaptation module 103 initiates a topology depth matching process based on the VF2 algorithm for each remaining qualified computing resource. This process aims to verify from a graph theory perspective whether the physical connection structure of the computing resource can directly support the logical coupling requirements of the user program. The feature adaptation module 103 first constructs two graph models: a filter graph representing the task requirements, and a filter mesh graph (FilterGraph). ) and the initial grid graph representing resource capabilities. .

[0076] The system reads the logical bit coupling relationship output by script parsing module 101 and instantiates the filtering mesh diagram. Among them, the node set The edge set consists of all logical qubits that actually participate in the computation in the script. The system consists of logical connection edges corresponding to all multi-bit gate operations extracted from the script. Simultaneously, the system reads the physical bit coupling topology information maintained in real-time by the feature aggregation module 102 and instantiates the initial mesh diagram. Among them, the node set Only includes the physical qubits currently marked as available, and the set of edges. This includes all physical couplers connecting two available physical bits. The graph construction process here strictly eliminates physical bits in a faulty state and their associated edges, ensuring that the matching process is based on actual hardware connectivity.

[0077] After construction is complete, the feature adaptation module 103 calls the VF2 subgraph isomorphism algorithm engine to... As a query graph, As the target graph, a state-space search is performed to determine whether there exists a path from... arrive injective function The injective function must satisfy the subgraph isomorphism constraint, that is, for Any two nodes in If an edge exists Then in The corresponding mapping node There must be an edge between them. .

[0078] The VF2 algorithm engine performs a depth-first search process, starting with an empty mapping state and gradually expanding to match state pairs. At each level of the search tree, the algorithm selects... One unmatched node Try mapping it to One unmatched node In attempting to establish mapping pairs Previously, the algorithm performed a feasibility rule check. This check verified two points: First, nodes exist The number (degree) of neighboring nodes in the node must be greater than or equal to the node's degree. exist The number of neighboring nodes in the data; Second, for exist Each neighbor node that has been matched , its in Mapping nodes in Must with There is a physical connection.

[0079] If for the current node ,exist No node satisfying the above feasibility rules can be found. The algorithm performs a backtracking operation, returning to the previous state and trying other mapping paths. If the algorithm succeeds... All nodes in If a corresponding node that satisfies the connection constraints is found, the computing resource is determined to meet the topology matching requirements, the search process is terminated, and a matching success signal is returned.

[0080] The feature adaptation module 103 updates the resource list based on the return results of the VF2 algorithm. For computational resources that return a successful match signal, the system adds them to the final candidate resource list. Resources in this final candidate resource list not only meet the basic bit quantity requirements, but their physical topology contains a substructure that is completely isomorphic to the user program's logical structure. This means the program can be directly mapped to the physical chip for execution, or requires only minimal compilation overhead, thus ensuring high fidelity and low latency in task execution. For resources that cannot be matched isomorphically through the subgraph, the system removes them from the candidate pool for the current scheduling cycle to prevent the explosive growth of SWAP gates and the resulting accumulation of signal noise caused by forced mapping.

[0081] Before generating the recommendation list, the result ranking module 104 first performs quantitative calculations and standardization on the core performance indicators of each computing resource in the final candidate resource list. This process aims to eliminate differences in the dimensions, orders of magnitude, and optimization direction (positive or negative) of different evaluation indicators, and construct a dimensionless normalized indicator set, thereby providing a unified mathematical basis for multidimensional weighted scoring.

[0082] The result sorting module 104 first obtains the original indicator data of each candidate resource from the feature summarization module 102. For single-bit fidelity and average cost, the system directly uses the aforementioned calculation logic to obtain the values; for task success rate and average task time, the system uses the aforementioned closed-loop update logic to obtain the values.

[0083] To achieve comprehensive evaluation across multiple indicators, the result ranking module 104 incorporates an extreme value normalization calculation model. The system first iterates through the current candidate resource list, extracting the maximum and minimum values ​​for each indicator within the current candidate set, denoted as follows: and .

[0084] For performance-related metrics, i.e., those with higher values ​​indicating better performance, including single-bit fidelity and task success rate, the system uses a forward normalization formula for calculation: ; in, This represents the normalized value of the benefit-type indicator, and its value ranges from [0,1]. This represents the original indicator value corresponding to the resource; This indicates the maximum value of this indicator in the current set of candidate resources; This represents the minimum value of this indicator in the current set of candidate resources. If... equal Then let The value is 1.

[0085] For cost-related metrics, i.e., those where smaller values ​​indicate better performance, including average cost and average task time, the system uses an inverse normalization formula for calculation: ; in, This represents the normalized cost indicator value, with a range of [0,1]. This represents the original indicator value corresponding to the resource; This indicates the maximum value of this indicator in the current set of candidate resources; This represents the minimum value of this indicator in the current set of candidate resources. If... equal Then let The value is 1.

[0086] Using the above calculation model, the result sorting module 104 uniformly transforms the original data with different physical units (such as seconds, dollars, percentages) into dimensionless scalars within the interval [0,1]. The normalized single-bit fidelity is denoted as... The normalized task success rate is denoted as The normalized average cost is denoted as The normalized average task time is denoted as These standardized symbols directly correspond to the variable parameters in the aforementioned comprehensive score, ensuring the mathematical validity of the subsequent weighted summation operation. Furthermore, the calculation model includes default imputation logic for outliers or missing values; if the original indicator of a resource is missing, its normalized value is set to 0 by default to reduce its competitiveness in the ranking.

[0087] See attached document Figure 5 The result ranking module 104 executes a multi-dimensional weighted scoring algorithm using a linear weighted sum model, fusing normalized multi-source heterogeneous indicators into a single decision scalar. This process begins with the mapping and loading of weight strategies. The result ranking module 104 has a pre-set strategy configuration table, which establishes a mapping relationship from user strategy identifiers to weight vectors. (Weight vectors) It is a one-dimensional array containing four floating-point values, each corresponding to an average cost weighting coefficient. Single-bit fidelity weighting coefficient Weighting coefficient for average task execution time and task success rate weighting coefficient And it satisfies the normalization constraint. .

[0088] When the system receives a strategy identifier contained in a task scheduling request, the result sorting module 104 retrieves and locks the corresponding weight vector. This embodiment specifically discloses four typical preset strategy modes: The first type is the fidelity-first mode, where the weight vector configuration focuses on maximizing the accuracy of the calculation results. For example, setting... This mode is suitable for scientific research verification or high-precision algorithm testing scenarios; The second type is the cost-first model, whose weight vector configuration focuses on minimizing economic expenditure, for example, setting... This model is suitable for large-scale repetitive experiments or teaching scenarios; The third type is the speed-priority mode, whose weight vector configuration focuses on shortening the feedback delay, for example, setting... This mode is suitable for iterative scenarios of hybrid quantum-classical algorithms with high real-time requirements; The fourth type is the equilibrium mode, where the weight vector is set as follows: This is used for general scheduling when there are no specific preferences. In addition, the system supports a custom mode, allowing user-defined floating-point arrays to be directly passed as weight vectors via the API interface, provided that the array has passed normalization and non-negativity checks.

[0089] Determining the weight vector And obtain the set of normalized indices calculated in the aforementioned steps ( Then, the result sorting module 104 performs a comprehensive score calculation for each candidate computing resource. The system calls the aforementioned comprehensive score formula ( The final score for the resource is obtained through vector dot product operations. Since the aforementioned normalization process has transformed cost-type indicators into values ​​where larger is better, the calculated... The larger the value, the higher the overall matching degree of the resource under the current weighted strategy.

[0090] After calculating the scores of all candidate resources, the result sorting module 104 executes the sorting algorithm. The system uses either quicksort or mergesort algorithms, based on... The values ​​are sorted in descending order of the resource list. To process... For boundary cases where values ​​are completely equal, the system has a built-in two-level sorting logic: if the comprehensive scores of two resources are equal, then their single-bit fidelity index is compared. , Those with higher values ​​are ranked first; if If the values ​​are still equal, then compare their average cost indicators. After sorting, the system generates a recommended list containing resource IDs, comprehensive scores, and detailed indicators. The resource ranked first is marked as the default scheduling target, or the Top-N list is returned to the user interface for manual confirmation. This algorithm ensures that scheduling decisions strictly follow user performance preferences, achieving a mathematical mapping from multi-dimensional physical parameters to a single decision dimension.

[0091] See attached document Figure 5 After completing the scoring and ranking of candidate resources, the result ranking module 104 enters the generation and encapsulation stage of the recommendation list. This generation and encapsulation stage aims to convert the internal ranking data structure into a standardized output format that can be parsed and executed by external systems or user terminals, and implement the final quality control truncation logic.

[0092] The result sorting module 104 first performs a threshold filtering operation based on absolute scores. The system has a preset minimum availability threshold, which defines the lower limit of the overall score considered to have minimal execution value. The system iterates through the resource list in descending order, checking the overall score of each resource. If a certain resource If a resource's value falls below the minimum availability threshold, it will be removed from the list, even if it ranks highly in the current list (e.g., when all resources perform extremely poorly). This mechanism prevents the system from recommending inferior resources to users that, while relatively optimal, cannot meet basic research requirements in terms of absolute performance.

[0093] After threshold filtering, the result sorting module 104 performs a list truncation operation. The system reads the maximum recommended quantity value from the configuration parameters. (The default value is usually 3 or 5). The system retains the top items in the sorted list. If the length of the filtered list is less than [a certain number of] resource objects, the remaining resources will be truncated and discarded. If the resource is not selected, all remaining resources are retained. For each retained resource object, the system constructs a detailed recommendation entry data package. This recommendation entry data package not only contains the resource's unique identifier and comprehensive score, but also encapsulates the unnormalized original metric values ​​of the four dimensions on which the comprehensive score is based (i.e., single-bit fidelity, average cost, average task time, and task success rate). This full-parameter disclosure mechanism allows users to verify the rationality of the recommendation results and view the specific performance metrics.

[0094] In addition, when generating the recommendation list, the result ranking module 104 simultaneously calculates and adds estimated queuing time information. The system queries the computing power adaptation service module 105 for the current queue length of tasks pending processing for that resource and the historical average task processing rate of that resource, and estimates the waiting time required if the current task is submitted to that resource by multiplying the two. This estimated queuing time is written into the recommendation item data packet as an auxiliary reference field, allowing users to make auxiliary decisions in addition to the comprehensive score.

[0095] Finally, the result ranking module 104 serializes all recommended items into standardized JSON or XML format response messages. If the recommendation list is empty after all the above steps (i.e., no resources pass the topology filtering or all resource scores are below the threshold), the system generates an exception response message containing a status code indicating no available resources and the specific reason for failure (such as topology matching failure or low overall score). This response message is returned to the front-end interactive interface for rendering and display via the API interface, or directly passed to the automated scheduling script, which selects the first resource in the list (Rank-1) to trigger the subsequent task submission process.

[0096] Upon receiving a clear scheduling instruction, the computing power adaptation service module 105 initiates the task construction and submission process. The inputs to this process include the original quantum assembly script, the unique identifier of the target computing resource, and the logical-physical bit mapping table generated by the feature adaptation module 103. The computing power adaptation service module 105 first performs a quantum program translation operation specific to the hardware. This translation operation does not alter the logical semantics of the program but rather transforms the general description into a sequence of instructions that the target physical machine can recognize.

[0097] During the translation process, the computing power adaptation service module 105 first applies a bit mapping transformation. The computing power adaptation service module 105 reads the mapping function determined by the feature adaptation module 103 during the topology matching stage (based on the VF2 algorithm), and replaces the indices of all logical qubits in the original script with the corresponding physical qubit numbers on the target quantum processor. For example, if the mapping function specifies that logical bit q[0] corresponds to physical bit... Then all operation instructions in the script, such as hq[0], will be rewritten as hQ

[12] . This step ensures that the gate operations executed subsequently strictly fall on the qubits with real connections in the physical topology, avoiding instruction rejection due to connectivity errors during runtime.

[0098] Subsequently, the computing power adaptation service module 105 performs basic gate decomposition and replacement. Since different quantum computers using different technologies (such as superconducting and ion trap quantum computers) support different sets of native gates, the computing power adaptation service module 105 needs to access the resource-supported quantum gate set data stored in the feature aggregation module 102. The computing power adaptation service module 105 scans each instruction in the script; if it finds a non-native gate operation, it queries the built-in compiler library to expand the non-native gate into an equivalent sequence of native gates. For example, if the target machine only supports… and The door, and the script contains The door, the computing power adaptation service module 105 will automatically... Replace the door with a specific set Revolving doors and Pulse combination (depending on the specific hardware-defined base set). This process ensures that the issued instruction set fully complies with the decoding requirements of the underlying hardware control electronic system.

[0099] After code translation is complete, the computing power adaptation service module 105 encapsulates the task payload. The computing power adaptation service module 105 creates a standardized task object, which contains the translated assembly code, the user-specified number of runs (Shots, used for statistical probability distribution), task priority parameters, and user-defined tag metadata. The computing power adaptation service module 105 serializes this task object into a data packet in JSON or Protocol Buffers format according to the API specifications of the target computing resource vendor.

[0100] Before sending the data packet, the computing power adaptation service module 105 performs authentication and routing operations. The computing power adaptation service module 105 accesses the encrypted credential repository, retrieves the API key (APIKey) or access token (AccessToken) corresponding to the target computing resource vendor, and adds it to the HTTP request header or gRPC metadata. Subsequently, the computing power adaptation service module 105 initiates an asynchronous submission request to the cloud gateway provided by the vendor through a secure network channel.

[0101] Upon receiving an HTTP 200 response or a corresponding success status code from the vendor's server, the computing power adaptation service module 105 extracts the External Job ID from the response message. The module then creates a new execution record in the local task database, binds the local task ID to the External Job ID, and updates the task status to "Submitted / Queued." If the network request times out or returns a 4xx / 5xx error code, the module triggers an exponential backoff retry mechanism. If the number of retries is exhausted without success, it automatically sends a submission failure alarm to the user and suggests re-triggering the resource selection process to choose alternative resources. This series of steps achieves a seamless bridge from logic code to physical execution, shielding the heterogeneity of the underlying hardware interface.

[0102] After submitting the task, the computing power adaptation service module 105 enters the execution result monitoring and data feedback stage. Since quantum computing tasks typically involve time-consuming processes such as queuing, compilation optimization, and physical execution, the computing power adaptation service module 105 does not block the main thread. Instead, it starts an asynchronous polling or callback monitoring mechanism based on a state machine to track the task lifecycle.

[0103] The computing power adaptation service module 105 maintains a task status monitoring queue. For vendor interfaces that support active callbacks, the computing power adaptation service module 105 opens a specific HTTP listening port to wait for remote pushes; for vendor interfaces that only support passive queries, the computing power adaptation service module 105 implements an adaptive polling strategy. This adaptive polling strategy uses an exponential backoff algorithm to dynamically adjust the query interval. The query frequency is low in the initial stage, and gradually increases as the estimated queuing time ends, thereby ensuring the real-time acquisition of results while avoiding rate limiting on the vendor API gateway due to high-frequency requests.

[0104] When the task status changes to COMPLETED, the computing power adaptation service module 105 initiates a result download request. The acquired raw result data typically includes the quantum measurement statistical distribution (Counts, i.e., the number of times each ground state is measured) or a list of binary strings from a single measurement. At this point, the computing power adaptation service module 105 performs crucial data standardization processing. Due to differences in the definition of big-endian and little-endian ordering of qubits among different hardware manufacturers, the computing power adaptation service module 105 automatically performs a bit-order reversal operation based on the manufacturer metadata stored in the aforementioned feature aggregation module 102, uniformly converting all results into the standard bit-order format defined internally by the system. This processing eliminates user misinterpretation of results caused by bit-order confusion.

[0105] While processing user business data, the computing power adaptation service module 105 extracts metadata for system optimization in parallel and performs data feedback operations. The computing power adaptation service module 105 parses the actual physical execution time, queuing time, and system calibration parameters at the end of the task from the header or metadata fields returned by the vendor. The computing power adaptation service module 105 encapsulates this data into a standard execution feedback object and sends it asynchronously to the feature aggregation module 102 via the internal message bus. This action directly triggers the aforementioned closed-loop indicator update process, that is, using the actual time and success status of this task to correct the historical statistical indicators of the resource.

[0106] Furthermore, the computing power adaptation service module 105 possesses a sophisticated error classification mechanism. When a task fails, the computing power adaptation service module 105 parses the error code to distinguish between user-side errors (such as illegal code logic or missing measurement operators) and system-side errors (such as control system timeouts or cryostat malfunctions). Only when a system-side error is determined will the failure record be returned as a negative sample to the feature aggregation module 102 to lower the resource's score; if it is a user-side error, the system only reports the error to the user without penalizing the computing resource's health score. This differentiated feedback mechanism ensures the fairness and robustness of the resource evaluation system. Finally, the standardized measurement results and original metadata are persistently stored in a local database and pushed to the end user via WebSocket or email notification service, marking the end of a complete scheduling cycle.

Claims

1. An adaptive scheduling method for computing resources in a quantum computing cloud platform, characterized in that, Includes the following steps: Construct and maintain a quantum computing resource pool, wherein each computing resource in the quantum computing resource pool contains basic characteristics, dynamic characteristics, and index characteristics, and the dynamic characteristics contain at least physical bit coupling topology information; The system receives a general quantum assembly language program script submitted by a user, parses the general quantum assembly language program script, and extracts the list of quantum gates, the maximum bit index, and the logical bit coupling relationship required for the quantum task. The computing resources are adapted and screened based on the basic characteristics and the dynamic characteristics, and the adaptation and screening specifically involves: Based on the basic features, preliminary resources that meet the preset conditions are filtered out. Then, for the preliminary resources, the extracted logical bit coupling relationship is matched with the physical bit coupling topology information of the computing resources to screen out a list of candidate resources that meet the topology connection requirements. Obtain the user-specified or system-preset ranking weight strategy, combine the indicator features to perform weighted scoring on the resources in the candidate resource list, and generate a recommended resource list based on the scoring results.

2. The adaptive scheduling method for computing resources in a quantum computing cloud platform according to claim 1, characterized in that, The specific methods for parsing the general quantum assembly language program script include: Traverse each line of code in the general quantum assembly language program script, extract quantum gate operators using regular expressions, and generate the quantum gate list after deduplication; Scan all operation instructions involving qubits in the general quantum assembly language program script, extract the maximum value of the qubit number as the maximum bit index, and count the number of different qubits actually used; Scan the gate operation instructions involving multiple qubits in the general quantum assembly language program script, extract the two qubit numbers involved in each instruction, and use the two qubit numbers as a node pair with a connection relationship to generate the logical bit coupling relationship.

3. The adaptive scheduling method for computing resources in a quantum computing cloud platform according to claim 1, characterized in that, The process of performing graph isomorphic matching between the logical bit coupling relationship and the physical bit coupling topology information of the computing resources specifically includes: Construct a filtering grid diagram, defining the qubits actually used in the general quantum assembly language program script as nodes, and the logical bit coupling relationships as edges; Construct an initial mesh graph, defining the currently available bits of the computing resources as nodes and the bit couplings in the physical structure of the computing resources as edges; The VF2 algorithm is used to detect whether the filtered grid graph is isomorphic to any subgraph of the initial grid graph; If the detection result is yes, then the computing resource is determined to meet the topology connection requirements, and the computing resource is added to the candidate resource list.

4. The adaptive scheduling method for computing resources in a quantum computing cloud platform according to claim 1, characterized in that, The methods for maintaining the dynamic characteristics in the quantum computing resource pool include: Receive topology data periodically pushed by quantum computer manufacturers, the topology data including a list of available bits and a list of bit couplings; The topology data is parsed, and the list of available single bits and the physical bit coupling topology of the corresponding computing resources are updated in real time. The online status of the computing resources is monitored and updated in real time.

5. The adaptive scheduling method for computing resources in a quantum computing cloud platform according to claim 1, characterized in that, The methods for maintaining the index characteristics in the quantum computing resource pool include: Receive callback data after the quantum task has been completed on the computing resources, the callback data including the task execution status and runtime; Based on the callback data and historical data, the statistical indicators of the computing resources are periodically recalculated and refreshed. The statistical metrics include at least the average task time, task success rate, single-bit fidelity, and average cost.

6. The adaptive scheduling method for computing resources in a quantum computing cloud platform according to claim 5, characterized in that, The single-bit fidelity is calculated as follows: Obtain the first relaxation time fidelity and the second decoherence time fidelity from the computing resource calibration data; The arithmetic mean of the first relaxation time fidelity and the second decoherence time fidelity is calculated as the single-bit fidelity.

7. The adaptive scheduling method for computing resources in a quantum computing cloud platform according to claim 6, characterized in that, The average cost is calculated as follows: Obtain the single task cost, task execution rate, and average task time of the computing resources; Calculate the product of the task operation rate and the average task time, and add the product to the cost per task to obtain the average cost.

8. The adaptive scheduling method for computing resources in a quantum computing cloud platform according to claim 7, characterized in that, The weighted scoring of resources in the candidate resource list specifically includes: The weight values ​​of the four dimensions—average cost, single-bit fidelity, average task execution time, and task success rate—are determined, and the sum of the weight values ​​of the four dimensions is one. For each candidate resource, calculate the product of the average cost and the average cost weight, the product of the single-bit fidelity and the single-bit fidelity weight, the product of the average task execution time and the average task execution time weight, and the product of the task success rate and the task success rate weight. The combined score of the candidate resource is obtained by adding the four products mentioned above.

9. The adaptive scheduling method for computing resources in a quantum computing cloud platform according to claim 1, characterized in that, After generating the recommended resource list, the process also includes: Receive instructions from the user to select a target computing resource from the recommended resource list; Associate the general quantum assembly language program script with the target computing resource and construct and submit the task; After the task is completed, the execution result is fed back to the computing power adaptation service to trigger the update of the aforementioned indicator features.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 9.

Images