An algorithm scheduling method and system for input data

Abstract

This application provides an algorithm scheduling method and system for input data. The method includes: receiving input data and parsing the data parameters and computation tasks of the input data; determining candidate computing devices from a list of computing devices supported by each computing device based on the data parameters and computation tasks, and determining at least one final computing device from the candidate computing devices; and scheduling the final computing device to perform data processing on the input data. This method rapidly filters candidate computing devices, requiring only quantitative calculations on a small number of candidate computing devices for the dynamic cost model. It retains the low latency characteristics of rule-based scheduling while achieving the decision accuracy of the dynamic cost model.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to an algorithm scheduling method and system for input data. Background Technology

[0002] In systems that use multiple processors to process input data, such as computing systems composed of central processing units (CPUs), graphics processing units (GPUs), and quantum processors, different types of processors have different strengths: CPUs are good at low-latency logic control and serial tasks, GPUs are good at large-scale parallel tasks such as matrix operations, and quantum processors have the potential to accelerate certain specific problems. In order to achieve collaborative processing of processors, it is usually necessary to introduce a scheduling mechanism for multiple processors.

[0003] However, existing scheduling mechanisms often employ only coarse-grained processor idle scheduling, allocating tasks solely based on whether a processor is currently idle; or they perform static matching based on the size of the input data, selecting one or more corresponding processors. Therefore, how to efficiently coordinate these heterogeneous processors and improve the efficiency of multiprocessor processing of input data has become a pressing problem for the industry. Summary of the Invention

[0004] This application provides an algorithm scheduling method and system for input data to solve the technical problem of inefficient collaborative scheduling control.

[0005] The first aspect of this application provides an algorithm scheduling method for input data, comprising: receiving input data and parsing the data parameters and computation tasks of the input data; determining candidate computing devices from a list of computing devices supported by each computing device based on the data parameters and computation tasks, and determining at least one final computing device from the candidate computing devices; and scheduling the final computing device to perform data processing on the input data.

[0006] In one embodiment of this application, determining candidate computing devices from a list of computing devices based on data parameters and computing tasks, using a list of computing tasks supported by each computing device, includes: matching computing devices that support computing tasks from the list of computing devices based on the list of computing tasks; determining candidate computing devices from the computing devices based on data parameters, wherein the computing parameters corresponding to the computing tasks supported by the candidate computing devices satisfy the data parameters; and obtaining the operating status and priority of the candidate computing devices.

[0007] In one embodiment of this application, determining at least one final computing power device from candidate computing power devices includes: selecting the candidate computing power device with the highest priority that is in an available operating state as the final computing power device.

[0008] In one embodiment of this application, determining at least one final computing power device from candidate computing power devices includes: when it is determined that there are multiple candidate computing power devices and the highest priority candidate computing power device is in a busy state, obtaining the waiting time cost of the candidate computing power device in the busy state; if the waiting time cost is higher than the execution time difference of falling back to the second-highest priority candidate computing power device, selecting the second-highest priority candidate computing power device as the final computing power device.

[0009] In one embodiment of this application, determining at least one final computing power device from candidate computing power devices includes: when it is determined that there are multiple candidate computing power devices and the multiple candidate computing power devices are in an available operating state, calculating the predicted execution time of each candidate computing power device, and selecting the candidate computing power device whose predicted execution time meets a preset execution rule as the final computing power device, wherein the preset execution rule is determined based on the device startup overhead of the candidate computing power device, the computation time overhead of the candidate computing power device executing the processing algorithm, and the data transfer time overhead of the input data.

[0010] In one embodiment of this application, determining at least one final computing power device from candidate computing power devices includes: dividing the processing of input data into multiple sub-tasks according to the computing task; determining a directed acyclic graph of the input data according to the data dependencies between the multiple sub-tasks; and determining the final computing power device from the directed acyclic graph, wherein the directed acyclic graph includes at least two final computing power devices.

[0011] In one embodiment of this application, scheduling the final computing power device to perform data processing on the input data includes: generating initialization parameters for the input data; substituting the initialization parameters into a parameterized template, sampling the initialization parameters distributed in the parameterized template to obtain an energy expectation value; and performing gradient calculation on the energy expectation value to obtain an update parameter for the input data, wherein the update parameter and the initialization parameter satisfy a preset convergence threshold.

[0012] In one embodiment of this application, scheduling the final computing power device to perform data processing on the input data includes: implementing data transmission between the final computing power devices using asynchronous direct memory access through a pre-allocated paged memory buffer.

[0013] A second aspect of this application provides an algorithm scheduling system for input data. The system includes: a data parsing module for receiving input data and parsing out the data parameters and computation tasks of the input data; a device selection module for determining candidate computing devices from a list of computing devices supported by each computing device based on the data parameters and computation tasks, and determining at least one final computing device from the candidate computing devices; and a task scheduling module for scheduling the final computing device to perform data processing on the input data.

[0014] A third aspect of this application provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the algorithm scheduling method of the first aspect of this application when executing the computer program.

[0015] The beneficial effects of this invention are as follows: By using a unified matching mechanism between the computing power task list and the device list, the differences between heterogeneous computing power devices are encapsulated within the system's scheduling and adaptation layer. Only the data parameters and computation tasks of the input data need to be received; there is no need to learn the interface specifications of each computing power device. This lowers the technical threshold for multi-computing power development, significantly improves development efficiency, and greatly shortens the development cycle. A two-stage scheduling mechanism combining static rules and dynamic costs is adopted, balancing scheduling response speed and decision accuracy. The computing power task list quickly matches candidate computing power devices that support the computation task, and then filters them based on operating status, priority, and waiting cost assessment. For multiple candidate computing power devices, a dynamic cost model is further invoked to calculate and predict the execution time based on device startup overhead, computation time overhead, and data transfer time overhead, selecting the optimal computing power device for execution. This avoids performance degradation caused by small-scale tasks being mistakenly assigned to devices with high startup overhead, and also avoids large tasks missing high-throughput devices due to misjudgment by static rules. Overall task execution performance is significantly improved, and computational output per unit power consumption (energy efficiency ratio) is also significantly optimized. By describing computational tasks across computing devices using a directed acyclic graph (DAG) mechanism, complex hybrid algorithms are decomposed into multiple subtasks, each bound to a final computing device, enabling the automatic generation of multi-device collaborative execution plans. Only the computational task needs to be submitted to obtain the final result; there is no need to manually orchestrate the call sequence and data transfer between devices. Complex workflows are simplified to unified interface calls, and runtime cross-device data transfer and synchronization waiting are automatically optimized by the system, significantly reducing the development difficulty and execution overhead of hybrid algorithms. Asynchronous data transfer and direct memory access (DMA) mechanisms are employed between the final computing devices, along with a unified data view and temporary memory management, eliminating the need for developers to manually write data transfer logic when data flows between heterogeneous devices. Asynchronous transfer allows computation and communication to overlap, and direct memory access eliminates the data transfer overhead of the central processing unit, reducing unnecessary round-trip data copies between devices. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0017] In the attached diagram: Figure 1This is a diagram illustrating an application scenario for scheduling algorithms on input data, provided in an embodiment of this application. Figure 2 This is a block diagram of the heterogeneous computing power scheduling system for the algorithm scheduling method for executing input data provided in the embodiments of this application; Figure 3 This is a flowchart illustrating the algorithm scheduling method for input data provided in the embodiments of this application; Figure 4 This is a structural diagram of an electronic device using an algorithm scheduling method for running input data provided in the embodiments of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application are described in detail below with reference to the accompanying drawings. Obviously, the embodiments described herein are only a part of the embodiments of this application, and not all of them. Other embodiments obtained by those skilled in the art based on the embodiments described in this application without creative effort are all within the scope of protection of this application.

[0019] In the following description, unless otherwise stated, "multiple" is understood as two or more, and "above" and "below" are understood to include the stated number; the following embodiments and the technical features in each embodiment can be combined with each other without contradiction. To facilitate understanding of the technical solutions of this application, several technical terms involved in this application are first explained in detail.

[0020] The technical solutions of this application can be applied to scenarios such as high-performance computing centers, cloud computing platforms, classical-quantum hybrid computing platforms, and edge heterogeneous computing nodes. In these scenarios, the Central Processing Unit (CPU) is used for low-latency logic control and serial tasks, and its numerical computation ecosystem is mainly based on BLAS / LAPACK standard libraries; the Graphics Processing Unit (GPU) is used for large-scale data parallel computing and supports various software development kits (such as CUDA and ROCm); the Quantum Processing Unit (QPU) has theoretical acceleration potential in problems such as unstructured search and quantum system simulation, but its software stack is centered on quantum circuits.

[0021] A context object is a software object that encapsulates the computing resources of various computing devices (processors). Internally, it manages the CPU thread pool, GPU data streams (such as CUDA streams, ROCm streams, etc.), QPU communication handles, and paged memory pools. Passing the context object during algorithm calls makes computing resources reusable, traceable, and concurrent throughout the application's lifecycle, reducing the overhead of repeatedly initializing the processor's configuration environment for each call.

[0022] A TensorView is a lightweight, multidimensional array descriptor that spans various computing devices. It does not hold memory ownership and contains a data pointer (void). Tensor views can be used to uniformly describe input data, including shape (shape array), stride (stride array), data type (dtype), device identifier (device), etc.

[0023] Pinned memory refers to a memory region in the CPU's main memory that is locked by the operating system and does not participate in page swapping. During Direct Memory Access (DMA) transfers, data in pinned memory can be transferred directly without first copying it to a temporary buffer, thereby reducing transfer latency.

[0024] The quantum register (Qureg) and the quantum oracle class (QuantumOracle) are used to encapsulate the allocation, reset, and measurement operations of qubits. The quantum oracle class is used to encapsulate unitary operator logic, define a unified interface for quantum black-box functions, and hide the low-level details of physical qubit allocation and quantum circuit compilation.

[0025] The computation-to-memory access ratio (CTR) is the ratio of the number of computations performed to the amount of data accessed from memory, used to measure whether a task is computationally intensive or memory-intensive. A device status table records the status of each computing device as available, unavailable, or busy. Waiting overhead is the estimated time consumed while waiting for busy computing devices to release resources; degradation benefit is the time saved by switching to a less efficient computing device compared to continuing to wait. A backend adapter is a Service Provider Interface (SPI) that uniformly defines the execution method (Execute) and temporary memory estimation method (GetTempSize) for each computing device implementing the core algorithm.

[0026] refer to Figure 1 , Figure 1The application scenario provided in this application uses static scheduling to perform algorithm scheduling on input data. If static scheduling is used, for example, for a sorting task with 1000 input data points, taking idle scheduling as an example, randomly routing the input data to a GPU in an available state requires approximately 10 microseconds (μs) of startup overhead, far exceeding the actual computation time of approximately 0.7 μs, resulting in a significant performance inversion. If an artificial intelligence model is used to perform global optimization on each input data point, its own computational overhead introduces unacceptable scheduling latency. How to achieve a balance between low scheduling latency and decision accuracy is a long-standing and difficult problem to solve in related technologies. Furthermore, for cross-computing power hybrid algorithms represented by Variational Quantum Eigensolvers (VQE), the general algorithm standard library of GPUs or QPUs often implicitly allocates and releases memory within the kernel, causing severe memory fragmentation and allocation latency in high-frequency iterative call scenarios; unnecessary round-trip copying can also easily occur when the same data flows between different devices.

[0027] It can be seen that if the scheduling of CPU, GPU, and QPU is independent, each computing device needs to learn / adapt its own programming interface, involving a large number of interfaces / functions, such as CUDA programming interface, quantum circuit design framework, and algorithm library interface. Simultaneously, manual management of data transfer, interface conversion, and mixed execution logic between different computing devices is required, leading to lengthy development cycles, extremely low code reusability, resulting in computing silos, a lack of unified standard interfaces, and high development barriers. Existing solutions cannot automatically allocate algorithms to the optimal computing device based on the data scale, data parameters, and operating status of the input data. For example, QPUs perform inefficient simulations on classical computers (the state vector grows exponentially with the number of qubits), and there is no awareness or avoidance mechanism when there is uneven load across multiple computing devices. Overall energy efficiency is low. The lack of unified scheduling results in low hardware resource utilization.

[0028] To address the aforementioned issues, this application proposes an algorithm scheduling method and corresponding scheduling system for input data. The overall concept is as follows: Through a top-down three-layer decoupled architecture (unified interface layer, scheduling and adaptation layer, and backend implementation layer) and a centrally coordinating registration mechanism (device registry and algorithm registry), the physical differences of heterogeneous hardware are shielded at the software stack level. In scheduling decisions, a two-stage scheduling chain is adopted, combining a three-level decision tree for coarse screening with a dynamic cost model for fine calculation, balancing low scheduling latency with optimal device selection. In data flow, a tensor view across computing power devices and a temporary memory estimation method are used to reduce memory allocation overhead and unnecessary copying. The following detailed description of each implementation method is provided in conjunction with the accompanying drawings.

[0029] See Figure 2 The algorithm scheduling method for input data in this embodiment is applied to a heterogeneous computing power scheduling system 2 (also referred to as an algorithm scheduling system) that includes CPU, GPU, and QPU. This heterogeneous computing power scheduling system may include a unified interface layer 20, a scheduling and adaptation layer 21, and a backend implementation layer 22, with each layer connected via a device registry 23 and an algorithm registry 24. The unified interface layer 20 exposes a hardware-transparent unified standard interface; the scheduling and adaptation layer 21 includes an algorithm attribution rule engine 211, a dynamic cost model 212 (preset execution rules), and a hybrid algorithm transparent orchestration engine 213 (preset orchestration rules); the backend implementation layer 22 includes a CPU execution unit 221, a GPU execution unit 222, and a QPU execution unit 223. This scheduling method (which may be referred to as a heterogeneous computing power scheduling method) is executed by the scheduling and adaptation layer 21. It can be understood that the aforementioned "layer," "registration," "engine," "model," and "unit" can all be various functional modules within the heterogeneous computing power scheduling system.

[0030] See Figure 3 , Figure 3 The algorithm scheduling method for input data provided in the embodiments of this application includes the following steps.

[0031] S301: Receives input data and parses out the data parameters and calculation tasks of the input data.

[0032] S302: Based on the data parameters and computing tasks, determine candidate computing devices from the list of computing tasks supported by each computing device, and determine at least one final computing device from the candidate computing devices.

[0033] S303: Schedule the final computing power device to perform data processing on the input data.

[0034] In response to the above Figure 2The algorithm scheduling method shown, as one implementation, includes the following steps for input data scheduling: parsing the input data, extracting the feature parameters (also called data parameters) and computation tasks of the input data, where feature parameters include data size, sparsity, and number of qubits; using the device parameters of the computing power devices maintained by the algorithm attribution rule engine (including supported classical algorithms and algorithm parameters), determining candidate computing power devices based on the computation tasks (corresponding to general tasks) and feature parameters, querying the device status table of computing power devices, obtaining the device status of each computing power device (CPU, GPU, and QPU), and evaluating the waiting overhead and degradation benefits of each computing power device to obtain candidate computing power devices; calling the dynamic cost model to calculate the predicted execution time of the computation task of the input data on the candidate computing power devices, and deciding on the final computing power device from the candidate computing power devices based on the predicted execution time to execute the computation task on the input data. It can be seen that, especially for computing tasks that are cross-computing power hybrid types, the hybrid algorithm transparent orchestration engine directly determines the final computing power device and generates the cross-computing power device directed acyclic graph (DAG) and data transfer instructions between computing power devices, and controls the final computing power devices to collaboratively execute computing tasks.

[0035] Specifically, during the parsing of input data, the scheduling and adaptation layer parses and extracts characteristic parameters such as data size, sparsity (i.e., the proportion of non-zero elements), and number of qubits. In some embodiments, the characteristic parameters may also include dimensions such as accuracy requirements (e.g., single-precision or double-precision) and noise tolerance thresholds to provide more complete input for subsequent rule matching and cost prediction. The extraction process of characteristic parameters is transparent to upper-layer application developers.

[0036] The scheduling and adaptation layer automatically retrieves feature parameters based on the shape, step size, and data type information carried by the tensor view, combined with the metadata fields declared by each algorithm in the algorithm registry. This eliminates the need for users to explicitly pass these parameters when calling the general algorithm standard library provided by the heterogeneous computing power scheduling system. This transparent parsing mechanism improves the cumbersome problem of developers having to manually configure running parameters for different hardware, and also provides a unified and standardized input for subsequent steps.

[0037] During the process of querying the device status table, the scheduling and adaptation layer obtains the device status of the CPU, GPU, and QPU. The CPU is typically continuously online, while the GPU and QPU can be perceived as being in one of three states: available, unavailable, or busy. If multiple candidate computing devices are identified, and the highest-priority candidate is in a busy state, the waiting time cost of the busy candidate is calculated. If the waiting time cost is higher than the execution time difference of falling back to the next-highest priority candidate, the next-highest priority candidate is selected as the final computing device. In other words, when a computing device is busy, the waiting overhead (waiting time cost) of continuing to wait for it to release resources is further calculated and compared with the degrade benefit (execution time difference, the difference between execution time and waiting time cost) of having the next-highest priority device execute the task. If the waiting overhead is greater than the degrade benefit, a degrade branch is directly triggered.

[0038] For example, a long task queue in the QPU can lead to an estimated waiting time of several seconds. However, downgrading the input data computation task to be executed by the GPU would only take a few hundred milliseconds. In this case, the benefits of downgrading significantly outweigh the benefits of waiting, and the scheduling and adaptation layer directly selects the downgraded path. This quantitative comparison-based processing mechanism reduces the probability of tasks being ineffectively blocked on high-load nodes.

[0039] During the three-level decision tree matching process, the scheduling and adaptation layer takes feature parameters as input and performs rule matching through the three-level decision tree to determine candidate computing power devices. This step, as a coarse screening link in the two-stage scheduling chain, uses pre-set attribution rules to quickly eliminate obviously mismatched computing power devices, significantly reducing scheduling costs and thus ensuring scheduling response speed.

[0040] During the secondary verification calculation of the predicted execution time in the dynamic cost model, the scheduling and adaptation layer invokes the dynamic cost model to calculate the predicted execution time for each candidate computing power device selected by the three-level decision tree, and selects the candidate computing power device with the smallest predicted execution time as the final computing power device. This effectively prevents situations where a computing power device is matched by the rules but its actual execution is not cost-effective. The calculation logic and online update strategy of the dynamic cost model will be explained in detail later.

[0041] During the generation of cross-device execution plans and cross-device data transfer instructions, for computing tasks spanning multiple computing devices, the scheduling and adaptation layer breaks them down into multiple subtasks, assigning a final computing device to each subtask. A directed acyclic graph can be generated between the final computing devices. Data transfer instructions are automatically inserted between final computing devices with data dependencies. These instructions include host-to-device (H2D) transfers, device-to-host (D2H) transfers, and QPU measurement result feedback. The scheduling and adaptation layer also checks whether the temporary memory of each final computing device meets the requirements when generating the execution plan, and then distributes the execution plan to the final computing devices for execution.

[0042] It can be seen that due to the heterogeneity of the three types of computing devices (processors) in terms of underlying instruction sets, memory space distribution, and execution models, their software ecosystems are fragmented at the levels of interface specifications, memory models, and scheduling mechanisms. Differences in any of these aspects will propagate upwards to development burdens and scheduling errors. While simple static rule scheduling is fast, it cannot perceive fine-grained characteristics such as data scale, sparsity, and number of qubits, as well as real-time hardware load. On the other hand, while purely dynamic global optimization makes accurate decisions, its computational overhead conflicts with "low-latency scheduling," presenting a contradictory relationship between the two.

[0043] The algorithmic scheduling method of this application sets up a two-stage scheduling process in a coarse-to-fine manner: a three-level decision tree quickly filters candidate computing power devices, while the dynamic cost model only needs to perform quantitative calculations on a small number of candidate computing power devices. This retains the low-latency characteristics of rule-based scheduling while achieving the decision accuracy of the dynamic cost model. Simultaneously, the metadata parsing, state awareness, and cross-computing power device instruction generation mechanisms encapsulate the differences between heterogeneous computing power devices within a unified scheduling and adaptation layer. The scheduling system only needs to deal with various input data. For example, in the embodiment where a sorting task with a data size of 1000 is statically routed to the GPU, using the method of this embodiment, after secondary verification by the scheduling and adaptation layer and the dynamic cost model, the sorting task will be routed to the CPU for execution.

[0044] The following is combined Figure 2 The various functional modules of the heterogeneous computing power scheduling system described above Figure 3 The algorithm scheduling method is described in detail.

[0045] Specifically, the unified interface layer ensures all algorithms adhere to a fixed calling paradigm, eliminating differences between computing devices. The unified interface layer includes the following: a context object encapsulates the resources of the computing devices managed by the backend implementation layer, including thread pools for CPU execution units, GPU streams (cudaStream_t) for GPU execution units, and QPU connection handles for QPU execution units. All algorithm calls must explicitly pass in the Context to ensure that computing device resources are reusable, traceable, and concurrent. Context objects can be created by users using the heterogeneous computing scheduling system and reused throughout their lifecycle, avoiding the overhead of repeated initialization with each call.

[0046] The device enumeration can take values ​​of {CPU, GPU, QPU, Auto}. Users can force the specification of a device (e.g., device enumeration::GPU, indicating that a GPU is specified), or specify Device::Auto for automatic decision-making. Forcing the specification of a device allows for a fallback strategy to be applied when the hardware is unavailable.

[0047] Tensor views are lightweight, multidimensional array descriptors that span multiple computing devices. They do not occupy memory and only contain data pointers, shapes, strides, data types, and device identifiers. Tensor views are used to uniformly represent input and output and support zero-copy inter-device view transformations.

[0048] Temporary memory is estimated using a method that measures the temporary memory consumption of each computing device, returning the number of bytes of temporary memory required. Based on this, temporary memory blocks are pre-allocated and then passed to the execution interface. This elevates the timing of memory allocation from within the algorithm to the caller, enabling the reuse, pooling, and unified lifecycle management of temporary resources, and avoiding frequent memory allocation and release within the algorithm.

[0049] Quantum Abstraction Layer: This layer introduces the Qureg (quantum register) abstraction, encapsulating the allocation, reset, and measurement operations of qubits; and the QuantumOracle (quantum oracle) abstract class, defining a unified interface for unitary operators and hiding the details of physical qubit allocation and circuit compilation. Quantum algorithms (such as Grover's search) interact with the general algorithm standard library through the oracle, without directly accessing the physical qubits.

[0050] In some embodiments, the scheduling and adaptation layer uses an algorithm affiliation rule engine to match computing devices that support computing tasks from a list of computing devices based on a list of computing tasks. Based on data parameters, it determines candidate computing devices from among the computing devices. The computing parameters corresponding to the computing tasks supported by the candidate computing devices satisfy the data parameters; that is, each computing device can correspond to at least one typical algorithm (a typical algorithm can also be called a computing task, and multiple computing tasks form a list of computing tasks). Typical algorithms supported by different types of computing devices can overlap. Simultaneously, the algorithm parameters (computing parameters of the computing task) of the same typical algorithm corresponding to different computing devices are different, resulting in different feature parameters of the input data that can be supported. Taking sorting as an example, both GPUs and CPUs support sorting, but the sorting algorithm parameters of GPUs are more suitable for sorting data with a size greater than or equal to 10^5, while the sorting algorithm parameters of CPUs are more suitable for sorting data with a size less than 10^5, where ^5 represents an exponent.

[0051] Specifically, the algorithm attribution rule engine is used to determine which type of computing power device a computing task should be routed to by default. This application embodiment can classify typical algorithms into four categories and define attribution rules. Typical algorithms supported by each computing power device are as follows: For example, typical algorithms in the CPU-specific category can be low-latency, branch-intensive, and small-scale input (N<1000) algorithms, such as introsort, Dijkstra's shortest path algorithm, regular expression matching, and the L-BFGS optimizer. Judgment condition: Data size N < threshold T_cpu (default T_cpu=10000), or the algorithm contains non-parallelizable serial dependency chains (such as iterative implicit solutions). GPU-specific category: Large-scale algorithms with high data parallelism, computational intensity, and rule-based memory access, such as radix sort, GEMM matrix multiplication, large-scale FFT, convolution operations, PageRank, and Monte Carlo path simulation. Judgment condition: Data size N > threshold T_gpu (default T_gpu=100000), and computation-to-memory ratio > 10:1. QPU-specific algorithms: Algorithms that directly operate on the quantum state space and possess theoretical quantum advantage, such as Grover's search, Shor's decomposition, quantum Fourier transform (QFT), quantum phase estimation (QPE), quantum singular value transform (QSVT), amplitude amplification / estimation, etc. Judgment criteria: The problem can be encoded as a quantum unitary operator, and the quantum speedup exceeds the classical polynomial speedup. Cross-computing power hybrid algorithms: Algorithms consisting of multiple stages requiring multi-device collaborative scheduling, such as VQE (CPU optimization + QPU sampling + GPU expectation reduction), QAOA, quantum support vector machine (QSVM), tensor network contraction, etc. Judgment criteria: The algorithm's DAG contains computing nodes from two or more types of devices. Attribution determination uses a three-level decision tree rule priority mechanism: the first level determines whether it is a hybrid class based on the algorithm's DAG structure; the second level determines CPU / GPU attribution based on parallelism and data dependency; the third level determines QPU attribution based on quantum advantage. When multiple rules are met simultaneously, the priority is determined as follows: cross-computing power hybrid class > QPU-specific class > GPU-specific class > CPU-specific class. The above rules are configurable and allow the default attribution to be overridden via xcub::SetDeviceHint.

[0052] It can be seen that the underlying logic of setting the above priority determination is as follows: cross-computing power hybrid categories involve multi-device collaboration, which has the highest scheduling complexity and needs to be identified first to trigger the transparent orchestration engine of hybrid algorithms, without needing secondary verification corresponding to the scheduling and adaptation layer and dynamic cost model; QPU's acceleration advantage is the most specific, and once the problem can be mapped to a quantum algorithm, quantum resources can be allocated first; GPUs and CPUs are conventionally divided according to parallelism and data scale. When multiple rules are hit simultaneously, convergence is performed according to the above priority to avoid ownership conflicts. In terms of decision structure, the first level of the three-level decision tree involved in the above embodiment determines whether it belongs to the cross-computing power hybrid category based on the structure of the directed acyclic graph across computing power devices; the second level determines whether it belongs to the CPU-specific category or the GPU-specific category based on parallelism and data dependency type; and the third level determines whether it belongs to the QPU-specific category based on quantum acceleration advantage.

[0053] By introducing the memory access ratio as a criterion, this embodiment excludes memory-intensive tasks that have large data volumes but are memory-intensive and cannot benefit from the GPU parallel architecture from the GPU-specific class. This reduces the probability of scheduling errors caused by a single data size criterion and improves the accuracy of scheduling decisions and overall energy efficiency.

[0054] In some embodiments, the scheduling and adaptation layer can also query the device status table of the computing power devices, where the CPU is typically online continuously, and the GPU and QPU can be perceived as being in one of three states: available, unavailable, or busy. In the busy state, the waiting time cost is evaluated: if the waiting time cost (T_wait) is greater than the execution time difference of falling back to the next lower priority computing power device, then a direct fallback is performed.

[0055] In some embodiments, the scheduling and adaptation layer can also determine candidate computing devices by making decisions on the computing power devices corresponding to the computing tasks through a preset rule cost table. For example, the decision rules can refer to the following correspondence: For sorting, if the data size N>10^5 and the GPU is available, then the GPU is selected (CUBradixsort), otherwise it falls back to the CPU (introsort); for GEMMmin(M, N, K)>1024 and the GPU is available, then the GPU is selected (cuBLAS), otherwise it falls back to the CPU; for FFT, if the data size N>10^6 and the GPU is available, then the GPU is selected (cuFFT), otherwise it falls back to the CPU (FFTW / MKL); for Grover, if the QPU is available and the search space >2^20 QPU, otherwise it falls back to GPU simulation (n≤30) / or CPU tensor network (n>30); for cross-computing power hybrid classes, if the QPU is available and n_qubits≤hardware capacity, then QPU (sampling), GPU (expected value), and CPU (optimization) are used.

[0056] In this embodiment of the application, when it is determined that there are multiple candidate computing devices and the multiple candidate computing devices are in an available state, the predicted execution time of each candidate computing device can be calculated by a dynamic cost model. The candidate computing device whose predicted execution time (also known as the estimated execution time) meets the preset execution rules is selected as the final computing device. The preset execution rules are determined based on the device startup cost of the candidate computing device, the calculation time of the candidate computing device's execution processing algorithm, and the data transfer time of the input data. The candidate computing device with the smallest predicted execution time is selected as the final computing device.

[0057] Specifically, during the second-stage validation of the dynamic cost model to calculate the predicted execution time, the dynamic cost model calculates the predicted execution time according to the following prediction formula (preset execution rules): ,in, To predict execution time, The device startup cost for candidate computing power devices. To calculate time cost, For data transfer time, α, β, and γ are correction coefficients.

[0058] In a specific example, startup overhead Values ​​are assigned based on device type: approximately 1μs for CPU, approximately 10μs for GPU, and approximately 100μs for QPU (including compilation and calibration time); computational overhead. Fitting algorithm complexity, for example, general matrix multiplication on GPUs can be estimated as the ratio of the product of the three dimensions of the matrix to the device's floating-point computing power, and quantum sampling can be estimated as the product of the number of samples and the execution time of a single circuit; data transfer overhead. Estimates are based on data volume and link bandwidth; for example, PCIe link bandwidth is approximately 16GB / s, and NVLink link bandwidth is approximately 300GB / s. QPU measurement return is estimated based on bitstream length. Correction factor. , , The initial value can be obtained by fitting an offline benchmark test, and the default value can be 1.0.

[0059] After each task is completed, the system records the actual execution time. The correction factor is updated online according to the Exponential Moving Average (EMA) strategy. Taking the correction factor for startup costs as an example, it is updated as follows: ,in, The predicted value for startup costs, This is the sliding learning rate, for example, 0.05. Correction coefficient. , Online updates can be performed using a method similar to the formula for α described above. Through adaptive adjustment of the exponential moving average, the dynamic cost model can continuously correct the prediction parameters as factors such as actual hardware load and aging change.

[0060] Furthermore, this embodiment sets a sliding window threshold based on standard deviation for the actual execution time: the scheduling and adaptation layer maintains a sliding window of several recent execution samples, and determines the deviation threshold based on the standard deviation of the samples within the window; if the deviation between the actual execution time and the predicted execution time exceeds the sliding window threshold, the time consumption is determined to be abnormal jitter noise, and the sample is directly discarded without triggering the online update of the correction coefficient.

[0061] In some embodiments, during the process of querying the device state table, if the QPU is unavailable or the waiting overhead exceeds the degradation benefit, a degradation simulation is triggered, and a memory expansion compensation and secondary degradation mechanism are executed: if the number of qubits is not greater than a preset qubit threshold, it is downgraded to a GPU-based state vector simulation; if the number of qubits is greater than the preset qubit threshold, it is downgraded to a CPU-based tensor network simulation. For example, the preset qubit threshold can be 30. When the number of qubits is not greater than 30, the storage requirement of the state vector is still within the acceptable range of the mainstream GPU memory capacity, and the large-scale parallel operation characteristics of the state vector simulation match the high-concurrency memory access capability of the GPU, so it is downgraded to a GPU-based state vector simulation; when the number of qubits is greater than 30, the exponential storage requirement of the state vector exceeds the memory carrying capacity, so it is downgraded to a CPU-based tensor network simulation, using the tensor network to compress the quantum state to reduce storage pressure. When the GPU is unavailable, the large-scale parallel algorithm can also fall back to a CPU multi-threaded implementation according to similar logic to ensure functional correctness.

[0062] In some embodiments, the CPU, GPU, and QPU each have their own independent memory space and programming model (such as CUDA streams and quantum registers). If there is a lack of a unified tensor view and temporary memory management mechanism, memory allocation, data copying and other processing logic must be written separately for each computing device. This results in cross-computing tasks being filled with repetitive work and is very easy to introduce memory leaks and data consistency errors, which seriously affects the reliability and maintainability of the code and leads to a disconnect between the interface and the memory model.

[0063] therefore, Figure 2The described heterogeneous computing power scheduling system may also include a Temp ResourceManager for implementing memory fragmentation and lifecycle management in computing devices. The Temp ResourceManager implements a temporary memory estimation method, a device memory pool, a cross-device data view, and automatic lifecycle management. The temporary memory estimation method is the service provider interface described above, which returns the number of bytes of temporary memory required to execute computing tasks on the computing device. The device memory pool is configured in the context object and is used to allocate / release the content needed by the computing device. The cross-device data view manages tensor views, uniformly describing the data of each computing device, and provides cross-device copying (H2D, D2H, QPU measurement feedback), ensuring zero-copy when the same data flows within a single computing device, and performing data transfer across computing devices, eliminating unnecessary round-trip copying. Automatic lifecycle management is used to uniformly release all associated memory and sub-resources for the context object, supports reference counting, and allows multiple computing tasks to share the same temporary memory block.

[0064] Specifically, before executing the computation task on the input data, the temporary memory requirement of the computation task is obtained through a temporary memory estimation method, and temporary memory is allocated in the device memory pool on the final computing device side through a context object. The temporary memory is reused within the lifecycle of the context object. Tensor views are used to uniformly represent the input and output data of the computation task. The tensor view includes data pointers, shapes, strides, data types, device markers, memory alignment markers, and continuity markers. Data flow within the same device maintains zero-copy switching of the tensor view, and determines whether to perform memory rearrangement of the data based on the memory alignment markers and continuity markers. Data transfer across computing devices is only triggered when data transfer instructions between devices are executed.

[0065] Specifically, each computing device that consumes temporary memory can provide a temporary memory estimation result through the temporary memory estimation method (GetTempSize). First, it calls the interface to obtain the number of bytes of temporary memory required for execution on the final computing device, then pre-allocates the memory in the memory pool of the final computing device accordingly, and finally passes the pre-allocated temporary memory to the execution interface.

[0066] At the data flow level, the scheduling and adaptation layer determines the data flow based on the memory alignment and continuity flags carried by the tensor view: if the data is continuously arranged in memory and its starting address meets the alignment boundary requirements of the final computing device, the underlying data pointer is directly reused to complete a zero-copy view switch; otherwise, a memory rearrangement operation is automatically triggered to organize the data into a format that can be efficiently accessed by the final computing device before use. This criterion ensures efficient and secure flow of cross-device data views from the underlying data structure level. Furthermore, cross-computing device data transfer is only explicitly triggered when the inter-device data transfer instructions generated by the cross-device execution plan (DAG) and data transfer instructions are executed. The same data always maintains zero-copy when flowing within a single device, thereby reducing unnecessary round-trip copies of data between heterogeneous devices.

[0067] Context objects also support automatic management of the lifecycle of temporary resources: when a context object is destroyed, all its associated temporary memory and various resources are released in a unified manner; as an alternative implementation, a reference counting mechanism can also be introduced to allow multiple algorithms to share the same temporary memory, provided that these algorithms do not execute at the same time, in order to further improve memory utilization.

[0068] Based on the above-mentioned temporary resource manager operation mechanism, by managing tensor views and temporary memory, the scheduling system does not need to write memory allocation, copying and release logic separately for each computing device, thus improving the fragmentation and copying overhead problems caused by the separation of memory models between heterogeneous devices.

[0069] In some embodiments, when the computational task is a hybrid algorithm across computing power, such as the Variable Quantum Eigenvalue Solver (VQE) and the Quantum Approximation Optimization Algorithm (QAOA), the hybrid classical-quantum algorithm requires CPU to optimize parameters, GPU to accelerate the expected value matrix operation, and QPU to execute quantum circuits. These three components work closely together. If the heterogeneous computing power scheduling system only supports simple splicing of general algorithm standard library calls from various computing power devices, it cannot form a reusable and optimizable computational pipeline. This will lead to repeated serialization and deserialization operations on data between different frameworks, with the additional overhead accounting for a considerable proportion of the total time consumption. Furthermore, the lack of a unified gradient calculation, convergence judgment, and fault tolerance mechanism results in extremely low development efficiency and difficulty in ensuring the stability of hybrid algorithms.

[0070] Therefore, if the computation task is a hybrid algorithm across computing power, the hybrid algorithm transparent orchestration engine will orchestrate it in an asynchronous pipeline overlap manner, including: controlling the CPU's optimizer to iteratively update parameters and submitting the parameterized circuit to the QPU for sampling; pre-allocating a paged memory buffer in the CPU's main memory through a context object, so that the measurement bit stream output by the QPU is transferred to the GPU's video memory via asynchronous direct memory access; controlling the GPU to run a reduction kernel, weighting and summing the measurement bit stream to obtain the energy expectation value, and calculating the gradient in parallel based on the parameter offset rule; and feeding the energy expectation value and gradient back to the CPU to update the parameters until the difference between two adjacent energy expectation values ​​is less than a preset convergence threshold.

[0071] The reason for introducing this orchestration mechanism is that in variational quantum algorithms represented by VQE, the CPU, GPU, and QPU need to perform multiple iterative interactions. Taking VQE as an example, firstly, the CPU initializes the parameter vector θ and constructs the Pauli decomposition form of the Hamiltonian. ,in For coefficients, For Pauli sequences; in the parameter optimization loop, the CPU runs an optimizer that iteratively updates the parameter vector θ. The optimizer can be, for example, the L-BFGS optimizer or the Adam optimizer.

[0072] Subsequently, the CPU substitutes the current parameters θ (including the initial parameter vector θ and the iterated parameter vector θ) into the parameterization template to generate a parameterized quantum circuit (the parameter vector θ can be regarded as the parameter in each circuit node in the parameterized quantum circuit, similar to the parameter in each node of each layer in an artificial intelligence model). After completing the topology mapping and error mitigation compilation through the quantum primitive library configured by the QPU or the quantum primitive compilation subsystem (QCUB), it submits the data to the QPU for sampling. The QPU samples the quantum circuit and returns the measurement bit stream of each Pauli term.

[0073] The measurement bitstream output by the QPU is transferred to the GPU's video memory via asynchronous direct memory access. This transfer process can rely on a paged memory buffer pre-allocated in the CPU's main memory by the context object. Since the paged memory does not participate in paging, direct memory access transfers do not need to be copied to a temporary buffer first, improving the performance loss of traditional paging memory transfers. At the same time, it allows the transfer process to be mounted in an asynchronous stream and executed concurrently with the computing kernel.

[0074] After the measurement bitstream reaches the GPU, the GPU runs a reduction kernel to calculate the expected value of each Pauli term in parallel, and then sums them by coefficient weights to obtain the expected energy value: ,in, For the first The expected value of each Pauli term. If gradient calculation is enabled, the GPU calculates the gradient of each parameter component in parallel based on the parameter offset rule: ,in, For the j-th component of the parameter vector, Let be the unit vector in the j-th direction. The gradient calculation for each parameter requires two circuit evaluations, and the evaluations of all parameters can be submitted in parallel to the pipeline composed of QPU and GPU.

[0075] Finally, the GPU sends the scalar energy value and gradient vector back to the CPU, and the optimizer updates the parameters accordingly. The CPU determines whether the convergence condition is met, i.e., the difference between two consecutive expected energy values. If the value is less than the preset convergence threshold, and if convergence is not achieved, return to the optimization loop to continue iterating until the convergence condition is met or the maximum number of iterations is reached.

[0076] It can be seen that the next round of sampling transmission of the QPU and the expected value reduction calculation of the current round of the GPU can overlap on the time axis. Pauli term batch processing can also be adopted, that is, the expected values ​​of multiple Pauli terms are calculated simultaneously in a single circuit evaluation, further compressing the number of interaction rounds. The entire orchestration process is transparent to the caller; the user only needs to provide Hamiltonian coefficients and parameterized circuit templates, without needing to worry about data transfer and execution order between devices. By adopting a collaborative mechanism of a hybrid algorithm transparent orchestration engine and a paged memory buffer, the additional overhead of data serialization and deserialization, as well as runtime data transfer overhead, is overcome. At the same time, calls to complex workflows such as VQE are reduced from hundreds of lines of script to concise calls to general-purpose algorithm standard libraries, improving the development efficiency of hybrid algorithms.

[0077] In some embodiments, corresponding to the emergence of new computing power devices (FPGAs, neuromorphic chips, optical QPUs, etc.), a complete set of general algorithm standard libraries needs to be rebuilt around the computing power devices. Application layer code cannot be migrated at all, and historical algorithm assets are difficult to reuse. The lack of a hardware-independent, pluggable, and scalable standard library niche is a fundamental structural problem that restricts the diversified evolution of computing power.

[0078] The aforementioned heterogeneous computing power scheduling system also includes plug-in computing power device extensions based on service provider interfaces. For newly connected computing power devices, it implements extended device enumeration and hardware availability detection functions, and registers the extended device enumerations in the device status table. It implements the execution method of the core algorithm and the temporary memory estimation method on the newly connected computing power devices according to the backend adapter interface, and registers them in the algorithm registry. It registers the routing rules and bandwidth parameters of the newly connected computing power devices in the rule table of the three-level decision tree and the dynamic cost model. Based on the device status table, the algorithm registry, and the rule table, it completes the perception, cost assessment, and routing of the newly connected computing power devices.

[0079] Specifically, the first step involves implementing extended device enumeration and hardware availability detection functions for newly connected computing devices, and registering the extended computing devices in the device status table, enabling the system to perceive the physical existence and real-time status of the new devices. The second step, following the unified specification of the backend adapter interface, involves implementing two methods for each core algorithm: an execution method and a temporary memory estimation method on the computing device, and registering them in the algorithm registry to complete the logical mounting of computing power. The third step involves registering the routing rules and bandwidth parameters (such as startup overhead and link bandwidth) of the computing device in the rule table of the three-level decision tree and the dynamic cost model, and incorporating the device into the offline benchmark testing process of the cost model to supplement the evaluation basis required for scheduling.

[0080] After completing the aforementioned plug-in registration, the scheduling and adaptation layer can use the device status table, algorithm registry, and rule table to perceive, assess costs, and route newly connected computing devices. Newly connected computing devices can be, for example, Field Programmable Gate Arrays (FPGAs), neuromorphic chips, or optical QPUs. Because the scheduling system's architecture adheres to the design principle of being open for expansion but closed for modification, upper-layer application code can obtain the acceleration benefits of new hardware without any modification, and historical scheduling logic can be fully reused, thus mitigating the problem of excessively high costs associated with expanding computing devices.

[0081] In some embodiments, the heterogeneous computing power scheduling system further includes an error handling and rollback module, which configures a unified status code (Status) for all computing tasks, with values ​​including: Success, InvalidInput, OutOfMemory, DeviceUnavailable, NotImplemented, etc. The scheduling and adaptation layer can follow these conventions when performing error handling: When a user-specified computing device is unavailable (e.g., a QPU is specified but is unavailable), a DeviceUnavailable error code is returned, allowing the user to re-enter automatic mode (Auto) or force-specified mode; in automatic mode, no error is returned, and rollback is performed directly. The default priority in Auto mode is QPU > GPU > CPU. When the QPU is unavailable, the quantum algorithm automatically falls back to GPU vector simulation (n_qubits≤30) or CPU tensor network simulation (n_qubits>30). When the GPU is unavailable, it automatically falls back to CPU through multi-threading. During the fallback process, the temporary memory allocation strategy is automatically adjusted to ensure functional correctness. The above fallback process is observable. For example, the caller can query the actual computing device and the fallback reason through the context object (e.g., through ctx.last_device(), ctx.last_decision()) for performance analysis.

[0082] This application embodiment also provides an algorithm scheduling system for input data, the system comprising: a data parsing module, used to receive input data and parse out the data parameters and computation tasks of the input data; a device selection module, used to determine candidate computing devices from a list of computing devices supported by each computing device according to the data parameters and computation tasks, and to determine at least one final computing device from the candidate computing devices; and a task scheduling module, used to schedule the final computing device to perform data processing on the input data.

[0083] The aforementioned algorithm scheduling system can also be called a heterogeneous computing power scheduling system, comprising: a unified interface layer, also known as a data parsing module, used to publish a unified standard interface, which includes a context object, device enumeration, tensor view, temporary memory, and quantum abstraction layer; a registration center layer, including an algorithm registry and a device registry, used to register available hardware capabilities and kernel variants when the system starts, and to provide a list of computing power devices to the scheduling and adaptation layer; a scheduling and adaptation layer, also known as a device selection module, including an algorithm attribution rule engine, a dynamic cost model, and a hybrid algorithm transparent orchestration engine, used to implement automatic scheduling methods for computing power devices; and a backend implementation layer, also known as a task scheduling module, including CPU execution units, GPU execution units, and QPU execution units, used to execute computing tasks according to instructions issued by the scheduling and adaptation layer.

[0084] Specifically, in the aforementioned heterogeneous computing power scheduling system, a unified interface layer is used to publicly expose a general algorithm standard library. This general algorithm standard library provides a unified namespace (e.g., xcub::) for calling, employing a unified calling paradigm (context object, computing device, tensor view, temporary memory), decoupling it from specific computing devices. The backend implementation layer encapsulates the kernel implementations of three types of computing devices: CPU kernels (e.g., AVX-512 / multithreaded implementation, and adaptations for third-party libraries such as OpenBLAS, IntelMKL, and oneTBB); GPU kernels (e.g., CUDA / ROCm kernels, including adaptations for standard libraries such as CUB (radix sort, reduction, scan), cuBLAS (GEMM, triangulation), and cuFFT (fast Fourier transform); and a QPU execution layer, including QCUB (quantum primitive compilation subsystem) responsible for quantum circuit compilation, topology mapping, error mitigation, and sampling execution. Each algorithm has one or more computing devices at this layer. All computing devices follow the same input-output contract (same parameter signature, same return status code, same temporary memory estimation method), ensuring that the upper layer can call and replace each other without distinction. The Scheduling & Adaptation Layer includes an algorithm ownership engine and a dynamic cost model. Based on the data parameters of the input data, such as data size, sparsity, and number of qubits, combined with the availability and real-time load of the computing devices, it dynamically selects the computing devices and specific implementation variants. Through a hybrid algorithm transparent orchestration engine, it generates cross-device execution plans (DAGs) for the computational tasks corresponding to cross-computing-power hybrid algorithms and is responsible for generating and executing cross-device data transfer instructions.

[0085] The three layers mentioned above are connected via a device status table and an algorithm registry: the backend implementation layer registers the computing devices and kernel variants to be run in the device status table at startup; the unified interface layer obtains the list of computing devices by searching the algorithm registry according to the computing task; and the scheduling and adaptation layer completes the selection of computing devices through algorithm scheduling. This plug-in-like architecture means that even if a new computing device is added, no modification to the upper-layer code is required; only registration in the device status table and algorithm registry is needed.

[0086] Specifically, the unified interface layer serves as the entry point for developer interaction. It establishes a cross-hardware interface contract through a unified namespace, unified calling paradigm, and unified return status, allowing upper-layer application code to operate without being aware of the actual physical hardware type. In a specific example, the unified interface layer can include a unified interface list, supporting user input of approximately 30 computational tasks (core algorithm results), covering categories such as sorting and search (e.g., key-value sorting, selection, search, for CPU / GPU / QPU), numerical computation (e.g., matrix multiplication, fast Fourier transform, singular value decomposition, linear solving, eigenvalues, for CPU / GPU), graph and combinatorial computation (e.g., shortest path, minimum spanning tree, for CPU / GPU), quantum algorithm computation (e.g., Grover search, quantum Fourier transform, quantum phase estimation, amplitude estimation, VQE, QAOA, for QPU / GPU / CPU), and reduction and scanning computation (e.g., reduction, prefix sum, histograms, for CPU / GPU). Application code implementing computational tasks based on the unified interface layer can be compiled and run on CPU, GPU, or QPU, differing only in the computing power of the device.

[0087] As the central hub of the system, the scheduling and adaptation layer undertakes the abstract tasks issued by the unified interface layer: the algorithm affiliation rule engine realizes the rule matching of the three-level decision tree, the dynamic cost model realizes the calculation of the predicted execution time and online adaptive update, and the hybrid algorithm transparent orchestration engine realizes the cross-device orchestration of cross-computing power hybrid algorithms. Together, the three complete the entire process from parsing the input metadata to generating cross-device execution plans and cross-device data transfer instructions.

[0088] The backend implementation layer encapsulates the access, control, and data creation of various computing devices into a unified format and stores it in the device registry. Each computing device has its own execution unit. For example, the CPU execution unit includes a self-developed implementation based on the AVX-512 instruction set and multithreading, as well as adaptation and encapsulation of third-party libraries such as OpenBLAS, Intel MKL, and oneTBB; the GPU execution unit includes CUDA or ROCm kernels, as well as adaptation and encapsulation of primitive libraries such as CUB (radix sorting, reduction, scanning), cuBLAS (matrix multiplication, trigonometric solving), and cuFFT (fast Fourier transform); the QPU execution unit, as a quantum primitive compilation subsystem, is responsible for quantum circuit compilation, topology mapping, error mitigation, and sampling execution.

[0089] In some embodiments, the QPU execution unit can also be configured with reusable quantum circuit modules, such as quantum arithmetic modules (multi-controlled Toffoli gate decomposition, quantum adders, quantum comparators, modular exponentiation circuits), quantum data movement modules (Swap networks, controlled permutation networks, qubit rerouting), quantum transformation modules (quantum Fourier transform and its inverse transform, quantum phase estimation blocks), and amplitude operation modules (amplitude amplification, amplitude estimation). These modules follow the same temporary resource management principles as classical algorithms, and the use of auxiliary qubits is allocated externally through a query interface. Each module can automatically adjust the circuit depth and gate selection based on the physical qubit topology and noise parameters. For example, when the noise rate is greater than 0.1%, error mitigation strategies such as zero-noise extrapolation (ZNE) or probabilistic error cancellation (PEC) are introduced; when the topology connectivity is insufficient, a SWAP routing network is automatically inserted.

[0090] For error handling, the scheduling and adaptation layer can return a unified status code, with values ​​including successful execution, invalid input, insufficient memory, unavailable device, and unimplemented. When a user-specified device is unavailable, a device unavailable status code is returned, allowing re-calling in another mode; otherwise, no error is returned, and the process proceeds directly according to the aforementioned fallback chain. The fallback process is observable for the caller, who can query the actual execution device and the fallback reason through the context object for performance analysis.

[0091] like Figure 4 As shown, this application also provides an electronic device 40, including: a memory 401 for storing computer programs; and a processor 402 for executing the computer programs to implement the algorithm scheduling method related to computing power devices in any of the foregoing embodiments. The memory may include volatile memory (e.g., random access memory RAM), or non-volatile memory (e.g., read-only memory ROM, flash memory, hard disk, etc.), or a combination of both; the memory stores the operating system, underlying drivers, and related programs of the heterogeneous algorithm unified library architecture system required to implement the cross-computing power automatic scheduling method of this application. Here, the processor generally refers to the computing control unit configured within the electronic device. In actual deployment, the electronic device can manifest as a high-performance converged computing server, a heterogeneous accelerator card cluster, or an edge computing node, which can integrate a CPU, GPU, and QPU or quantum measurement and control board connected via a high-speed bus or dedicated line.

[0092] When the processor runs the above computer program, that is, when executing the above... Figure 2The scheduling and adaptation layer logic of the heterogeneous computing power scheduling system in the paper involves: parsing the metadata of computing tasks submitted by the application layer and sensing the load status of each heterogeneous computing power unit in real time; relying on a three-level decision tree and dynamic cost model, routing tasks to matching computing power devices within a microsecond-level time window; and coordinating direct memory access transmission between main memory and video memory for cross-computing power hybrid algorithms to ensure asynchronous overlapping execution of the pipeline. Through the hardware support of this electronic device, the technical solution of this application is implemented, improving the overall computing power utilization and task throughput of a single device and reducing the probability of hardware resource idleness.

[0093] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the algorithm scheduling method of any of the foregoing embodiments.

[0094] The computer-readable storage medium can be any tangible medium capable of containing or storing a program, such as portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the above media. When the processor of the target computing platform (e.g., the master node of a supercomputing center, a virtual machine instance of a cloud service, or a local development workstation) reads and executes the computer program on the storage medium, the system is endowed with the ability to uniformly schedule heterogeneous computing power: during program execution, a unified interface layer, a registration center, a scheduling and adaptation layer, and a backend implementation layer are instantiated in memory, thereby automatically completing task feature parsing, rule matching, cost assessment, and cross-device execution plan generation. By embedding the scheduling method of this application into a computer program in the storage medium, the distribution and deployment threshold of heterogeneous computing software stacks is lowered.

[0095] The following specific implementation example illustrates the scheduling method described above. For instance, the input data consists of 1 million key-value pairs (keys are 32-bit unsigned integers, and values ​​are 32-bit floating-point numbers), initially stored in GPU memory. The data size is parsed to N = 10^6. It is found that both CPU and GPU are available, but QPU is unavailable. The scheduling and adaptation layer determines that N is greater than the GPU size threshold (10^5) and the memory access ratio meets the GPU condition, initially routing to the GPU. The dynamic cost model further verifies this: the GPU predicts an execution time of approximately 2.01ms (including 10μs startup overhead and 2ms computation), while the CPU predicts an execution time of approximately 55ms (including 5ms data transfer). Therefore, GPU execution is ultimately chosen, calling the CUB radix sort kernel to complete the sorting, which actually takes approximately 2.3ms. If the CPU is forcibly used, the time is approximately 52ms, a performance difference of approximately 22 times. This implementation example verifies the effectiveness of the scheduling and adaptation layer combined with the dynamic cost model for collaborative decision-making, and the advantage of zero-copy data transfer when the data is already on the target device.

[0096] The scheduling and adaptation layer utilizes a hybrid algorithm transparent orchestration engine to schedule the variational quantum eigenvalue solver (VQE). The input is a 4-qubit Hamiltonian of a hydrogen molecule (H₂) (containing 5 Pauli terms), employing a hardware-efficient fitting method (8 variational parameters), with an L-BFGS optimizer and a convergence threshold of 1e-6 Hartree. The system is identified as a cross-computing power hybrid class, generating a directed acyclic graph containing CPU, QPU, and GPU nodes: the CPU handles parameter initialization and Pauli decomposition (H=Σc). i P i The QPU performs parameterized circuit sampling (8192 measurements per round), while the GPU handles expectation reduction and parameter offset gradient calculation (8 parameters × 2 evaluations). It converges after approximately 35 iterations, with a ground-state energy of -1.1373 Hartree and a total execution time of approximately 3.2 seconds. It can be seen that the hybrid algorithm transparent orchestration engine simplifies a large amount of cross-computing device interaction code into a single general algorithm standard library call, and minimizes cross-device data transfer overhead through paged memory asynchronous DMA and pipeline overlap.

[0097] For the Grover search problem with an input search space of 2^10 = 1024, QPU is available, but the search space is smaller than the quantum routing threshold (2^20), and rule matching does not meet the QPU routing conditions. Dynamic cost model verification: QPU prediction takes approximately 100ms (including compilation and calibration), while GPU state vector simulation takes only about 0.5ms. Therefore, GPU simulation is automatically selected, taking approximately 0.6ms and successfully finding the target state. If QPU is forcibly used, the time is approximately 120ms, a performance difference of 200 times.

[0098] For FPGA accelerators configured as candidate computing devices, the steps for FPGA access to the algorithm scheduling system of this application embodiment include: ① registering Device::FPGA enumeration and hardware probing functions; ② implementing the Execute and GetTempSize methods of GEMM / convolution according to the back-end adapter interface, and registering applicable conditions (data size M, N, K ∈ [512, 4096], int8 / fp16 precision); ③ registering the FPGA routing conditions (data size range hit and available), startup overhead (500μs, including bitstream loading) and bandwidth parameters in the rule table and dynamic cost model; ④ offline calibration of cost model coefficients. After access, when the upper-layer application calls GEMM with automatic scheduling, the scheduler automatically includes the FPGA in the candidate list. For a 1024×1024 fp16 matrix multiplication, the FPGA prediction time is about 1.6ms, which is better than the 2.1ms of the GPU, so it is automatically routed to the FPGA. If the FPGA firmware loading fails, it automatically falls back to the GPU / cuBLAS. This embodiment demonstrates that the plug-in extension mechanism allows new computing power to be accessed without modifying existing business logic, significantly reducing software and hardware adaptation costs.

[0099] As can be seen from the above embodiments, the heterogeneous computing power scheduling system solves the problem of computing power silos. Developers only need to master a unified general algorithm standard library to call CPU, GPU, and QPU computing power devices to form the optimal combination, without having to learn the standard libraries of each platform separately. This significantly reduces the code size of the application corresponding to the computing task, shortens the development cycle, and greatly improves development efficiency. Through the intelligent scheduling mechanism, the system can automatically avoid computing power devices with high startup overhead based on the data parameters of the computing task, so that small-scale tasks run on low-latency devices and large-scale parallel tasks run on high-throughput devices, significantly improving the overall task execution performance and optimizing the computing output per unit power consumption. The complex workflow for classical quantum hybrid algorithms is simplified to a single interface call, greatly reducing the development workload. At the same time, through pre-allocated paged memory and asynchronous pipelined transmission, the extra time spent on data transfer across computing power devices is greatly compressed, and runtime communication overhead is significantly reduced. By leveraging a unified tensor view and temporary memory, developers no longer need to write separate memory allocation, copying, and deallocation logic for each computing device, significantly reducing the amount of memory management code. Combined with memory pooling and reuse mechanisms, the number of memory allocations in high-frequency scenarios is greatly reduced, effectively mitigating the risk of memory leaks and fragmentation issues. The computing devices adopt a plug-in architecture. When adding new computing devices such as FPGAs and neuromorphic chips, only typical algorithms need to be added according to the standard interface, without modifying the upper-layer interface and business logic. The workload of integrating new computing devices is significantly reduced compared to rebuilding the system, allowing existing systems to be fully preserved and reused. In the field of classical-quantum hybrid computing, a standard library niche similar to BLAS has been established. Application software only needs to adapt the interface once to run on any platform containing CPUs, GPUs, and QPUs, eliminating the repetitive development model of each computing device requiring a separate system, significantly reducing software adaptation and maintenance costs.

[0100] Those skilled in the art will understand that the specific structures, interface forms, algorithm examples, and parameter values ​​described in the above embodiments are merely exemplary. Any equivalent method that can achieve the same function, such as replacing one optimizer with another gradient-type optimizer, or adjusting the specific values ​​of each decision threshold, falls within the scope of this application. The above are only some embodiments of this application and are not intended to limit this application. For those skilled in the art, this application can have various modifications and variations. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. An algorithmic scheduling method for input data, characterized in that, include: Receive input data and parse out the data parameters and calculation tasks from the input data; Based on the data parameters and computing tasks, candidate computing devices are determined from the list of computing devices supported by each computing device through the list of computing tasks supported by each computing device, and at least one final computing device is determined from the candidate computing devices. The final computing power device is scheduled to perform data processing on the input data.

2. The method according to claim 1, characterized in that, Based on the data parameters and computation tasks, and through the list of computational tasks supported by each computing power device, candidate computing power devices are determined from the list of computing power devices, including: Based on the computing power task list, the computing power device that supports the computing task is matched from the computing power device list; Based on the data parameters, candidate computing devices are determined from the computing devices, wherein the computing power parameters corresponding to the computing power tasks supported by the candidate computing devices satisfy the data parameters. Obtain the operating status and priority of the candidate computing power devices.

3. The method according to claim 2, characterized in that, The step of determining at least one final computing power device from the candidate computing power devices includes: The candidate computing power device with the highest priority and the operational status of "available" is selected as the final computing power device.

4. The method according to claim 2, characterized in that, The step of determining at least one final computing power device from the candidate computing power devices includes: If it is determined that there are multiple candidate computing devices, and the candidate computing device with the highest priority is in a busy state, the waiting time cost of the candidate computing device in the busy state is obtained. If the waiting time cost is higher than the execution time difference of the candidate computing power device that falls back to the next lower priority, the candidate computing power device with the next lower priority is selected as the final computing power device.

5. The method according to claim 2, characterized in that, The step of determining at least one final computing power device from the candidate computing power devices includes: If it is determined that there are multiple candidate computing devices and that the multiple candidate computing devices are in an available state, the predicted execution time of each candidate computing device is calculated, and the candidate computing device whose predicted execution time meets the preset execution rules is selected as the final computing device. The preset execution rules are determined based on the device startup overhead of the candidate computing device, the computation time overhead of the candidate computing device executing the processing algorithm, and the data transfer time overhead of the input data.

6. The method according to claim 2, characterized in that, The step of determining at least one final computing power device from the candidate computing power devices includes: The processing of the input data is divided into multiple sub-tasks according to the computation task, and the directed acyclic graph of the input data is determined according to the data dependencies between the multiple sub-tasks. The final computing devices are determined from the directed acyclic graph, wherein the directed acyclic graph includes at least two of the final computing devices.

7. The method according to claim 6, characterized in that, The process of scheduling the final computing power device to perform data processing on the input data includes: Initialization parameters for generating the input data; Substitute the initialization parameters into the parameterization template, and sample the initialization parameters distributed in the parameterization template to obtain the expected energy value; The gradient of the energy expectation value is calculated to obtain the update parameters of the input data, wherein the update parameters and the initialization parameters satisfy a preset convergence threshold.

8. The method according to claim 6, characterized in that, The process of scheduling the final computing power device to perform data processing on the input data includes: Data transmission between the final computing devices is achieved using asynchronous direct memory access via a pre-allocated paged memory buffer.

9. An algorithm scheduling system for input data, characterized in that, The system includes: The data parsing module is used to receive input data and parse out the data parameters and calculation tasks of the input data; The device selection module is used to determine candidate computing devices from the list of computing devices based on the data parameters and computing tasks, through the list of computing tasks supported by each computing device, and to determine at least one final computing device from the candidate computing devices. The task scheduling module is used to schedule the final computing power device to perform data processing on the input data.

10. An electronic device, comprising: Memory, used to store computer programs; A processor for implementing the algorithm scheduling method according to any one of claims 1 to 8 when executing a computer program.

Images