Hybrid quantum-classical scheduler

Abstract

This disclosure relates to a method for providing access to a shared quantum resource. The method comprises receiving quantum job information from a classical scheduler. The quantum job information relates to a quantum job to be performed on the shared quantum resource. Allocation data is determined indicative of an allocation of the quantum job to the shared quantum resource. The allocation data is sent to the shared quantum resource to reserve the quantum resource for the quantum job. An access token is obtained, verifiable by the shared quantum resource, that represents a privilege to perform the quantum job on the shared quantum resource according to the allocation. The access token is sent to a classical computation node to confer, to the classical computation node, the privilege to perform the quantum job on the shared quantum resource according to the allocation.

Description

"Hybrid quantum-classical scheduler"Cross-Reference to Related Applications

[0001] The present application claims priority from Australian Provisional Patent Application No 2024903561 filed on 1 November 2024, the contents of which are incorporated herein by reference in their entirety.Technical Field

[0002] This disclosure relates to methods and systems for providing access to a shared quantum resource, such as, but not limited to, scheduling access to a quantum processor.Background

[0003] Quantum computers have reached a technological maturity such that they can be integrated into high performance computing (HPC) centres as additional resources to classical computing devices, such as central processing units (CPUs) and graphical processing units (GPUs). Such quantum resources may also be referred to as quantum processing units (QPUs) realised by a number of qubits that can be used to implement quantum gates to perform quantum operations. The quantum state of the qubits can be measured and the measurements used in the calculation or other operations by the classical CPUs or GPUs. The quantum measurements may be performed repeatedly to obtain a statistical measurement of the resulting quantum states.

[0004] Since multiple users want to access resources of an HPC, HPCs employ job scheduling systems to distribute jobs across a large number of processing resources. One example is the SLURM workload manager accessible at https: / / slurm.schedmd.com / . With a workload manager, a user can submit a job request and a controller daemon on the HPC schedules the requested job amongst other jobs and allocates each job to one of multiple nodes (hosting the requested resources). Each job request may contain job information, such as requested wall time, number of processors and amount of memory per processor. The controller daemon then schedules the job amongst the other jobs so that the resources are used optimally given the job information of each job.

[0005] A user can also request additional generic resources, such as GPUs for particular jobs. The controller daemon then allocates a node with that generic resource to the job. For example, different nodes may have different GPUs and a user may request a specific GPU so that the job runs on a node that has that specific GPU. The common theme here is that the generic resources are directly connected to the nodes, in the sense that one node cannot access generic resources of another node. As a result, the job request specifies for each job a generic resource that is required for that particular job on an allocated node. This generic resource is then allocated together with the node and is therefore not available to any other jobs during the duration of the allocation, that is, during the wall time provided by the user. For example, if a job is suspended, the resources do not become available although they are not currently used.

[0006] It is difficult to use existing job scheduling systems for QPUs, which is why there is a need for an improved quantum job allocation system.

[0007] Any discussion of documents, acts, materials, devices, articles or the like which has been included in the present specification is not to be taken as an admission that any or all of these matters form part of the prior art base or were common general knowledge in the field relevant to the present disclosure as it existed before the priority date of each of the appended claims.

[0008] Throughout this specification the word "comprise", or variations such as "comprises" or "comprising", will be understood to imply the inclusion of a stated element, integer or step, or group of elements, integers or steps, but not the exclusion of any other element, integer or step, or group of elements, integers or steps.Summary

[0009] A method for providing access to a shared quantum resource comprises: receiving quantum job information from a classical scheduler, the quantum job information relating to a quantum job to be performed on the shared quantum resource; determining allocation data indicative of an allocation of the quantum job to the shared quantum resource;sending the allocation data to the shared quantum resource to reserve the quantum resource for the quantum job; obtaining an access token, verifiable by the shared quantum resource, that represents a privilege to perform the quantum job on the shared quantum resource according to the allocation; and sending the access token to a classical computation node to confer, to the classical computation node, the privilege to perform the quantum job on the shared quantum resource according to the allocation.

[0010] It is an advantage that the method reserves the quantum resource and obtains an access token to confer the privilege to perform the quantum job to the classical computation node. This way, the quantum resource can be integrated into an architecture with many classical computation nodes where the quantum resource can be shared while maintaining the ability to allocate the quantum resource to be used together with classical jobs effectively.

[0011] In some embodiments, obtaining the access token comprises generating the access token or receiving the access token from the shared quantum resource.

[0012] In some embodiments, generating the access token is based on a cryptographic method to secure the access token.

[0013] In some embodiments, the access token comprises a hash value of the quantum job information and only quantum jobs that have the same hash value are accepted by the shared quantum resource.

[0014] In some embodiments, the shared quantum resource is a quantum computing unit comprising a classical controller and multiple qubits and the quantum job comprises executing a quantum circuit on the qubits and measuring states of the multiple qubits after executing the quantum circuit.

[0015] In some embodiments, determining the allocation data comprises determining an allocation of time to use the shared quantum resource.

[0016] In some embodiments, determining the allocation of time comprises determining an amount of time for which the shared quantum resource is allocated exclusively to the quantum job.

[0017] In some embodiments, determining the allocation of time comprises a validity time window within which the amount of time can be used.

[0018] In some embodiments, determining the allocation comprises maintaining an allocation fraction below a maximum allocation fraction threshold.

[0019] In some embodiments, the quantum job information comprises a number of shots and the method further comprises determining an amount of time that is required to perform the number of shots on the shared quantum resource and determining the allocation of the amount of time to the shared quantum resource.

[0020] In some embodiments, the allocation data is indicative of an allocation of the quantum job to one of multiple shared quantum resources.

[0021] In some embodiments, the quantum job information comprises an identification of one of the multiple shared quantum resources for the quantum job and the allocation is based on the identification.

[0022] In some embodiments, the classical computation node is one of multiple classical computation nodes that access the shared quantum resource using the access token.

[0023] In some embodiments, the multiple classical computation nodes concurrently execute respective classical jobs and access the shared quantum resource multiple times during execution of each of the classical jobs.

[0024] In some embodiments, the access token represents a privilege to terminate another quantum job that is running on the shared quantum resource when the access token is used by the classical computation node.

[0025] In some embodiments, the method further comprises, upon termination of a classical job that required the quantum job, relinquishing the allocation.

[0026] In some embodiments, the method further comprises regularly monitoring the shared quantum resource and reporting to the classical scheduler.

[0027] A system for providing access to a shared quantum resource, the system comprises a classical scheduler; a quantum scheduler; one or more classical computation nodes; a shared quantum resource; wherein the classical scheduler is configured to receive hybrid job information comprising classical job information and quantum job information; schedule one or more classical computation nodes according to the classical job information; and send the quantum job information to a quantum scheduler; wherein the quantum scheduler is configured to perform the above method. The classical computation nodes are configured to receive the access token from the quantum scheduler, and provide the access token to the shared quantum resource. The shared quantum resource is configured to receive the access token, validate the access token, upon successful validation of the access token, perform the quantum job, send a result of the quantum job to the one or more classical computational nodes.

[0028] A quantum resource is configured to be shared with multiple classical computation nodes. The quantum resource comprises one or more classical processors and quantum hardware including multiple qubits. The one or more classical processors are configured to perform the steps of receiving quantum job information relating to a quantum job to be performed on the quantum hardware and an access token from one of the multiple classical computation nodes; validating the access token; upon successful validation of the access token, controlling the quantum hardware to perform the quantum job on the qubits of the quantum processor; and sending a result of the quantum job to the one or more classical computational nodes.

[0029] Software comprises a quantum scheduler software package configured to cause a classical processor to perform the above method, a software plug-in for a classical scheduler to provide quantum job information to the quantum scheduler software package; and an interface software component for a shared quantum resource to require an access token to perform a quantum job.Brief Description of Drawings

[0030] Examples will now be described with reference to the following figures:

[0031] Figure l is a flow chart of a system for providing access to a shared quantum resource.

[0032] Figure 2 illustrates a method for providing access to a shared quantum resource.

[0033] Figure 3 illustrates a quantum scheduler.

[0034] Figure 4 illustrates a quantum resource.Description of Embodiments

[0035] As described above, existing job scheduling systems are difficult to use for scheduling QPUs. More particularly, deployment of QPUs is significantly different to deployment of CPUs and GPUs. More particularly, QPUs are not commodity resources and are typically not installed in large numbers. One reason for this is that quantum resources are complicated to operate, expensive and may use a large amount of infrastructure resources, such as cooling, power, floor space, etc. Further, they may be installed outside the classical computing nodes, i.e. on a different board or in a different rack, and may even be accessed remotely, such as through a cloud service. For these reasons, classical scheduling systems are not a good fit for scheduling quantum system.

[0036] Even further, classical jobs that request quantum resources often do not use that quantum resource for the entire duration of the job. For example, the classical node may perform some classical calculations, then run a quantum circuit for multiple times (such as 1024 shots), and then classically process the results from the quantum circuit for the rest of the allocated time. In this example, the quantum resource would be idle for a large part of the allocated time. However, it would be desirable that other jobs can use the quantum resources as soon as a previous job has finished using the quantum resource and reverts back to classical computing. This way, the quantum resource can be shared by multiple nodes and therefore be available to more jobs.

[0037] More particularly, the disclosed system comprises a classical scheduler and a quantum scheduler that schedules jobs on classical computation nodes. The classical scheduler may be using the Simple Linux Utility for Resource Management (SLURM) available at https: / / slurm.schedmd.com / . Other schedulers can equally be used with the current solution, such as Grid Engine or PBS Professional or others. The quantum scheduler is also a classical computer and schedules the use of quantum resources. The quantum resources generate access tokens for the requested reservations and the access tokens can then be used by the classical nodes to access the quantum resource when they need it.

[0038] An access token as used herein is a data structure that includes information about the access granted to the holder of the access token, such as text which may be structured, such as JSON. The access token further includes a validation code, which may be a signature or keyed hash value. This way, the key holder can re-calculate the validation code and compare the result to the validation code in the token. When they match, this indicates to the key holder that the data has not been changed and that the validation code in the token has been generated by the key holder. The access token can then be passed between entities of the network to confer the rights granted by the access token. The access token may be a JSON web token (JWT).

[0039] Figure 1 illustrates system 100 for providing access to a shared quantum resource comprising a user job script 101 that is provided by the user to a SLURM module 102 comprising hybrid job information including classical and quantum job information. The SLURM module 102 processes the user job script 101 and allocates classical resources accordingly. Therefore, the SLURM module 102 is also referred to as a classical scheduler. More particularly, the SLURM module 102 receives the hybrid job information comprising classical job information and quantum job information and schedules one or more classical computation nodes according to the classical job information. The classical node 104 may have a quantum software development kit (SDK), such as Qristal, Qiskit or others. Then, the SLURM module 102 sends the quantum job information to a quantum scheduler 103 (operated on a classical machine). The quantum job information relates to the quantum job that is to be performed on a shared quantum resource 105.

[0040] Quantum scheduler 103 receives the quantum job information from the SLURM module 102 (i.e. the classical scheduler) and determines allocation data indicative of an allocation of the quantum job to the shared quantum resource. More specifically, the quantum scheduler 103 performs an algorithm to allocate the quantum job to one of the quantum resources. In some examples, the quantum scheduler 103 does not allocate an absolute time slot to a quantum job, because the quantum scheduler 103 may not have the information on when the quantum job is to be performed since the quantum scheduler 103 may not have the information on how long the classical job takes on the classical computation node before the quantum job can commence. Therefore, the quantum scheduler 103 may reserve the quantum resource for a duration of time for which the classical node can use the quantum resource beginning at any time potentially during a validity time window, first-in first out, preemptive scheduling, and others.

[0041] There are a number of different scenarios. First, the user may specify a specific quantum resource that only exists once in the system. In that case, quantum scheduler 103 allocates the quantum job to that specified resource. In other cases, there may be multiple quantum resources that meet a requirement provided by the user (such as number of qubits). In that case, quantum scheduler 103 may allocate the quantum job to one of the quantum resources that matches the requirement and that has the lowest allocation fraction. The allocation fraction is the amount of computation time allocated for the length of a particular time window.

[0042] For example, if there is one quantum resource and the validity time window for all jobs is 100s, and a first quantum job reserves 10s from T=0s, then the allocation fraction is 10%. When a second quantum job of 20s is allocated to the same resource at T=10s and the first job has not been executed yet, the allocation fraction rises to 30%. When no further jobs are scheduled and the validity time window of the first job expires at T=100s, the allocation fraction drops back to 20% and to 0% at T=110s.

[0043] First-Come, First-Served (FCFS) is a scheduling algorithm where jobs are processed in the order they arrive. The Round Robin scheduling algorithm assigns a fixed time slot to each job in a cyclic order. This ensures that all jobs get a fair share of the quantum resource. Shortest Job Next (SJN), also referred to as Shortest Job First (SJF), prioritizes jobs with theshortest duration. This algorithm optimizes resource utilization by reducing the average waiting time for jobs. Priority Scheduling assigns a priority level to each job and schedules them based on their priority. Jobs with higher priority will be executed before those with lower priority. This method is useful when certain jobs are more critical than others. Backfill Scheduling aims to optimize resource utilization by allowing smaller jobs to "backfill" the gaps between larger jobs. If a smaller job can be accommodated in the idle time without delaying the start time of queued jobs, it is scheduled for execution. This algorithm significantly reduces idle time and enhances the throughput of the quantum system. Earliest Deadline First (EDF) is a dynamic scheduling algorithm that prioritizes jobs closest to their deadlines. This ensures that time-sensitive jobs are completed on schedule. EDF is particularly useful in real-time quantum computing applications where job completion within a specific time frame is critical. Preemptive Scheduling allows ongoing jobs to be interrupted and rescheduled to accommodate higher-priority jobs or efficiently manage resource utilization. This method is flexible and can adapt to changing workloads, but it requires a mechanism for saving and restoring the state of interrupted jobs, which can be complex in quantum computing.

[0044] Synchronisation can be achieved through the integration with the classical HPC scheduler. When the job achieves a sufficiently high priority according to the classical scheduler (reaches the 'top' of the queue, for a generalised definition of queue), and the requested classical resources are available, the classical scheduler may then periodically ask the quantum scheduler if the quantum resources are available (i.e. requests to make a reservation starting immediately, extending for the length of the job's time window). Once both sets of resources are available, both the quantum and classical resources are allocated for the pre-determined job length. As described below, the allocation of the quantum resources consists of the quantum scheduler obtaining the access token and passing it on to the classical scheduler to pass on to the actual compute job. This enables a tight integration with classical schedulers so that it can be used to co-schedule both classical and quantum resources needed for a job. This allows for the execution of parallel hybrid quantum-classical algorithms, which require synchronised use and reservation of multiple classical nodes and one or more quantum devices. For example: on a supercomputer one can use the disclosed method to schedule a single job to run across 100 classical compute nodes each with 2 GPUs, as well as 10 quantum devices. Without the ability to enforce synchronised availability of all thesecompute resources, such jobs are difficult to perform. This is an advantage over purely queuebased allocation methods.

[0045] The allocation data may be in a database format stored in a database that reserves the quantum resource for a set duration of time for a specific job identifier. In other examples, the allocation data may be simply text data or structure text, such as JavaScript Object Notation (JSON). The allocation data may also be converted from a database entry to a text / JSON format or between other formats.

[0046] Quantum scheduler 103 then sends the allocation data, such as in the form of JSON text, to the quantum resource 105 to reserve the quantum resource 105 for the quantum job. Reserving the quantum resource 105 does not necessarily mean a promise or guarantee that quantum resource 105 can be used exclusively to the exclusion of any other jobs at a specific point in time. Instead, reserving means that the job is allocated to the quantum resource 105 and that the quantum resources will perform the quantum job in the future. There may still be a queue that means that a particular quantum job will have to wait until preceding jobs are completed.

[0047] At the time of reservation, the quantum resource 105 receives the allocation data and generates an access token. To that end, the quantum resource 105 may store a private key that the quantum resource 105 uses the create a cryptographic signature added to the access token. This way, it is practically impossible for other entities to issue access tokens for the quantum resource 105. The access token may also include the allocation data or a part thereof, potentially in a hashed form, so that the access token is only valid for the request for which it has been issued. Quantum resource 105 then sends the access token back to the quantum scheduler 103, which obtains the access token.

[0048] The access token may include a variety of data fields, including job identifier, reserved duration, user identifier, classical computation node identifier, time stamp, nonce or any combination of the above.

[0049] While in some examples the quantum resource 105 generates the access token, in other examples it is the quantum scheduler 103 that obtains the access token by generating it on the quantum scheduler 103. In this way, the quantum scheduler 103 has the private key togenerate the signature in the access token and the quantum resource 105 has the public key to verify the signature. While some examples use public-private key pairs in an asymmetric encryption scheme, other examples use shared symmetric keys or other methods, including quantum cryptographic methods. Encryption methods may include the advanced encryption standard (AES), Rivest-Shamir-Adleman (RSA), elliptic curve cryptography (ECC), and others.

[0050] As a result of the cryptographic procedures applied by the quantum resource 105 in generating the access token, the access token is verifiable by the quantum resource, such as by checking the signature is correct. For the quantum resource 105, the access token represents a privilege to perform the quantum job on the shared quantum resource 105 according to the allocation. This means that the shared quantum resource 105 will check any job request on whether it contains a valid token for that request and only on successfully verifying the token, perform the requested quantum operations. For example, the access token may comprise a hash value of the quantum job information and only quantum jobs that have the same hash value are accepted by the shared quantum resource 105.

[0051] While in some examples any node can provide the access token to the quantum resource 105 to perform the quantum job, in other examples, the access token is specific to one computation node and other computation nodes cannot use the access token. In this case, the computation node may need to provide a signature to prove its identity. The latter example improves security but may reduce the efficiency of scheduling of the classical nodes.

[0052] The quantum scheduler 103 sends the access token to the classical computation node 104. This confers the privilege to the classical node 104. The classical computation node 104 receives the access token from the quantum scheduler and provides the access token to the shared quantum resource 105 when the quantum job is to be executed. As set out above, the privilege is to perform the quantum job on the shared quantum resource 105 according to the allocation. In other words, the access token provides a binding between the quantum job (such as job ID), the job allocation (such as a duration of time available for performing the quantum job), the classical computation node 104 and the quantum resource 105. This way, the classical node 104 now has the opportunity or privilege to send a quantum job to the quantum resource 105 together with the access token.

[0053] Quantum resource 105 validates the access token. For example, the validation may be based on a hash message authentication code (HMAC). In that case the quantum resource 105 creates the access token, which includes an authentication code calculated using a symmetric secret key. This may involve executing a Secure Hash Algorithm (e.g. SHA-3) cryptographic hash function. Since the key is secret, no other party can re-generate the authentication code. And since the HMAC is based on hashing, the code becomes invalid if the access token is changed. The quantum resource 105 may include the HMAC into the token, and when the quantum resource 105 receives the token, it re-calculates the HMAC and compares the result with the HMAC in the token. If both match, the toke is authenticated.

[0054] In other examples, where the quantum scheduler 103 generates the token, the quantum scheduler may share the HMAC secret key with quantum resource 105 or use a private key of a public / private key pair to generate a signature and provide the public key to the quantum resource 105. The quantum resource 105 (and any other entity with the public key) can then use the public key to verify the signature. Again, if the token is changed, the signature becomes invalid. Once the access token is validated, quantum resource 105 checks that the access token corresponds to the requested job. If successful, the quantum resource 105 performs the requested quantum job and returns the result back to the classical node 104. If another job is currently running on the quantum resource 105, there may be a queue, and the requested job is added to the queue and performed once the quantum resource 105 has finished the current job or all the earlier jobs in the queue.

[0055] It is possible that there are multiple quantum resources in the system, such as second quantum resource 106. These quantum resources 105 / 106 may be different. For example, they may differ in the number of qubits, the type of connections between the qubits, the physical platform (photons, quantum dots, nitrogen vacancies) or in other characteristics. The user may specify which specific resource is requested for a particular job in the user job script 101 and the quantum scheduler 103 allocates the quantum job to the requested resource. In other examples, the user specifies a characteristic, such as the number of qubits or the physical platform and the quantum scheduler allocates that job to one of the resources that meets these requirements. The quantum scheduler 103 may perform a scheduling algorithm to balance the queue length, utilisation, expected delay, and other metrics across the quantum resources to determine the allocation.Time duration

[0056] In some examples, the allocation of quantum jobs to quantum resources 105 / 106 is based on an expected duration for which the quantum resources 105 / 106 are required to perform the job. That is, quantum scheduler 103 determines an allocation of time to use the shared quantum resource 105 / 106. For example, the amount of time can be measured in seconds, or in the number of shots, i.e. number of qubit measurements, performed on the quantum resource. In that sense, the quantum scheduler 103 determines an amount of time (in seconds or number of shots) for which the shared quantum resource 105 is allocated exclusively to the quantum job.

[0057] This determination may also involve a validity time window within which the amount of time can be used. The advantage is that the access tokens essentially expire after a set period of time, which avoids the problem that access tokens accumulate and could be used at the same time, which would lead to an unacceptable wait time in the queue. By setting the validity time window, the overall available number of tokens and therefore allocated time can be capped to guarantee a turnaround time of the jobs in the queue.

[0058] Further, the quantum scheduler 103 may maintain an allocation fraction below a maximum allocation fraction threshold. That is, there is a maximum allocation fraction, such as 80% and when 80% of the time is allocated to that resource, no more jobs are allocated until some jobs either expire or are completed.

[0059] It is further noted that the classical computation node is one of multiple classical computation nodes that access the shared quantum resource using respective access tokens. This means that the multiple classical computation nodes concurrently execute respective classical jobs and access the shared quantum resource multiple times during execution of each of the classical jobs. For each access to the quantum resource 105, each classical node provides their access token to the quantum resource. In some examples, the classical node has received an access token that is unique for each time it accesses the quantum resource 105 while in other cases the same access token can be used multiple times for the same job identifier until the allocated time period has been exhausted.

[0060] In yet another example, there may be priority access tokens that represent a privilege to terminate another quantum job that is running on the shared quantum resource when the access token is used by the classical node 104. In that case, the job is put to the front of the queue, the current job is aborted and the priority job executed immediately. In that scenario, quantum scheduler 103 may issue only a single priority access token per quantum resource for each validity time window. The aborted job may then be re-started on completion of the priority job.

[0061] In other words, time-limited 'priority tickets' are handed out to jobs instead of exclusive reservations. These tickets are valid for a certain number of shots on the hardware and would allow the bearer to jump to the next spot in the circuit queue (or possibly even interrupt the current circuit if it is not itself a priority circuit). Shot number would be converted to effective wall time, and quantum scheduler 103 would allocate the tickets according to a scheduling algorithm based on a maximum allowed priority allocation time fraction. This would include a continuous recalculation of the fraction of coming time windows already ticketed, in order to allow for requests with overlapping priority windows. This may assume uniform probability for each ticket to be redeemed anywhere in its validity window.

[0062] For example: A user may have 4 jobs that request 10 hr walltimes, and they ask for n shots each, corresponding to 1 hr of QPU time. That means they want a Ihr priority ticket each with a lOhr validity window. If the maxPriorityAllocationFraction is set to 30%, that allows 3 / 4 jobs to start immediately. The fourth job would be allowed to start when the implied priorityAllocationFraction for the remaining part of the initial lOhr window — if the fourth job were to start immediately — dropped below 30%. This would happen as soon as 2 of the initial 3 jobs finished, so long as at least half the original lOhr window remained.

[0063] It is noted that in many applications, quantum resources are used by classical computation nodes at specific points in time when the classical computation has completed. This may occur many times in a loop, for example. With the solution presented herein, the access to the quantum resource can be scheduled so that the classical computation is synchronised with the quantum computing operation, so that the classical computation node does not have to wait for the quantum resource to become available each time the quantumcomputation is required. As a result, a significant overall delay is avoided which is specifically advantageous in cases where the quantum resource is used many times for relatively short time windows.

[0064] Other alternative implementations are possible by changing the HPC scheduler (the system does not strictly require SLURM), or simply using the scheduling agent directly without an HPC scheduler, e.g. in a cloud environment. Some examples are implemented for the hardware of Quantum Brilliance but another alternative is to use different hardware.

[0065] Another feature would be to encrypt the circuits themselves submitted to the QPUs, using the same shared secret password. This would provide security against man-in-the- middle attacks (whereas the current secure reservation system provides security against taking over QPUs or spoofing them).

[0066] While the above examples provide validity time windows the govern the validity of the access tokens, it is also possible to relinquish the allocation of the job to the quantum resource upon termination of the corresponding classical job that required the quantum job. For example, the classical job may be iterative and in each iteration the quantum resource is required. However, the break condition depends on the output of the quantum resource and is not known at allocation. Therefore, the classical node 104 may use the quantum resource for an unpredictable amount of time until the classical job terminates. At that point, the allocation is relinquished, and the access token becomes invalid.

[0067] Returning to Figure 1, there is also a status monitor 107 regularly monitors the shared quantum resources 105 / 106 and report to the classical scheduler 102 or the quantum scheduler 103. This way, the schedulers 102 / 103 can adjust the allocation of jobs to resources and in particular, not allocate any jobs to resources that are currently unavailable or reallocate jobs from unavailable resources to available resources.Commands

[0068] Quantum scheduler 103 (also referred to as “qtil”) may implement the following commands:

[0069] qti l val idate <addres s> <secret>Confirms that the connection to a quantum device works, but do not add it to the database and comprises the following steps:1. Query the device and check that it returns status normal2. Make a test reservation3. Check that the device now shows status reserved4. Cancel the reservation5. Check that device status has returned to normal

[0070] qti l regi ster <name> <addres s> <secret> [ --queue string ] Registers a new quantum device in the qtil database, i.e. Adds the specified device to the database as a member of queue (default qpus).

[0071] qti l remove <name>Removes a quantum device from the qtil database.

[0072] qti l status [ <name> | --queue string ]Displays the current status of one or more quantum devices.• Allows querying of single device, all devices, or all devices in a given queue• Queries each device and displays the returned status• Displays aggregate statistics when status of > 1 device is requested• Also displays device rego info

[0073] Concurrent

[0074] qti l reserve [ <name> ] [ --duration f loat | --end_time f loat ] [ --number int ] [ --queue string ]Attempts to reserve one or more quantum devices.• Reserves number devices from queue• Reservations timeout after duration seconds or at Unix end_t ime• Returns a JSON web token (JWT) for accessing each reserved device• Concurrent

[0075] qti l release <name> <token>Relinquishes an existing reservation on a quantum device.# Releases a single quantum device from its existing reservation# Requires the access token provided by qti l reserveSLURM plugins

[0076] In some examples, SLUM can be adapted to work with the disclosed quantum schedular by implementing the following plugins and adding them to SLURM.

[0077] j ob- submit (Lua) runs on the SLURM head node as root when the job is submitted. It parses the requests for licenses -L queue_name : num_qpus , checks that queue_name actually exists as a qtil queue and that queue_name has at least num_qpus registered. If so, the plugin exports the info about requested QPUs to the SLURM_JOB_EXTRA environment variable. If not, refuses to submit the job.

[0078] s lurmctld prolog (Python) runs on the SLURM head node as root just before the job is sent to CPU nodes for execution. It reads reservation requirements from SLURM_JOB_EXTRA, calls qti l reserve to make reservations and saves reserved QPU names, addresses + tokens back to SLURM_JOB_EXTRA using scontrol l . If the required reservations cannot be made, it requeues the job and else, sends it to the allocated CPU nodes to start executing.

[0079] task prolog (Python) runs on each of the job’s executing CPU nodes as the user (i.e. job’s owner) as the job starts. It does not have the requisite authority to execute qtil and reads reservation details from SLURM JOB EXTRA using scontrol. It also parses the contents into environment variables it makes available to the job:# QTIL QUEUES : semicolon-separated list of qtil queues used for this j ob# QTIL <queue name> NUMBER : number of reservations made from <queue name># QTIL <queue name> <n> IP : IP+port of reserved device <n> in <queue name># QTIL <queue name> <n> TOKEN : JSON web to ken for acces s to the <n>th reserved device from <queue name>

[0080] s lurmctld epilog (Python) runs on the SLURM head node as root when the job ends and runs regardless of whether the job fails or completes successfully. This plugin reads QPU reservation info from SLURM_JOB_EXTRA and releases each allocated QPU using qti l release.

[0081] cronjob (Bash) runs at regular intervals (e.g. 5 mins) as root on SLURM head node and calls qti l status to check how many registered QPUs are actually online (e.g. in case one needs to be put into maintenance mode, goes down, etc.). This plugin uses sacctmgr to update SLURM’s count of allocatable QPUs in each queue and uses s lurmdbd and dynamic licenses.Advantages

[0082] The system disclosed herein allows remote QPUs, works with job schedulers other than SLURM, operates on the cloud, and permits QPUs to be shared by multiple jobs. It does not lock all QPU activity to the scheduler and has no security gaps in device allocation and circuit submission. Furthermore, it does not require modifying SLURM every time the hardware API changes or when supporting new hardware.

[0083] The system ensures security by not requiring the exchange of keys over the air with quantum devices, and users neither need nor receive direct access to keys. Scheduling capabilities are restricted to key holders, such as SLURM, and circuits can be easily encrypted so only the user and the key holder can read them. Token-based scheduling is utilized instead of treating quantum devices as SLURM resources, making it suitable for both HPC and cloud resource scheduling. This approach allows the scheduling of both remote and local quantum resources and decouples scheduling from SLURM jobs, facilitating resource sharing, standalone operation, and the use of plugins for other schedulers. The system supports multiple queues, multi-QPU queues, and multi-QPU jobs, enabling concurrent operations that scale well to systems with thousands of devices and jobs. Additionally, it can be supported by mainline Qristal and qcstack, and interoperability with other hardware, SDKs, and schedulers can be added.Method

[0084] Figure 2 illustrates a method for providing access to a shared quantum resource. The method is performed by quantum scheduler 103 and as such, may be implemented in software, such as in C++, Python, Go or other programming languages. According to method 200, and as also explained above, quantum scheduler 103 receives 201 quantum job information from a classical scheduler where the quantum job information relates to a quantum job to be performed on the shared quantum resource 105.

[0085] Quantum scheduler 103 then determines 202 allocation data indicative of an allocation of the quantum job to the shared quantum resource and sends 203 the allocation data to the quantum resource to reserve the quantum resource for the quantum job. Further, quantum scheduler obtains 204 an access token, which is verifiable by the shared quantum resource. The access token represents a privilege to perform the quantum job on the shared quantum resource 105 according to the allocation. Finally, quantum scheduler 103 sends the access token to classical computation node 104 to confer, to the classical computation node 104, the privilege to perform the quantum job on the shared quantum resource according to the allocation.Systems

[0086] Figure 3 illustrates quantum scheduler 103 in further detail as implemented by a computer system 300 comprising a processor 301, program memory 302, data memory 303 and a communication port 304. It is noted that while only one processor 301 is shown, computer system 300 may comprise one or more processors that are configured to perform the methods disclosed herein. This may be by way of software, i.e. program code, stored on program memory 302, which is a non-transitory, computer readable medium. The program code, when executed by processor 301 causes processor 301 to perform method 200. That is, processor 301 receives quantum job information, determines allocation data, sends the allocation data to the quantum resource, obtains an access token and sends the access token to the classical computation node.

[0087] The communication of the job information, allocation data, access token and other data may be performed via communication port 304, which may be any data connection, suchas a local area network (LAN), or wide area network (WAN), such as the Internet. The communication port 304 may communicate with local resources, such as resources on the same board or in the same rack or in the same data centre or HPC or with remote resources that are accessible through cloud access. Processor 301 may be implemented in a wide range of different technologies, such as a server, personal computer, mobile device, etc.

[0088] Data memory 303 may store job information and allocation data. For example, data memory 303 may store data indicative of a current allocation of quantum resources to job numbers. For example, data memory 303 may store one record for each access token that has been issue. At a point in time when a specific access token is set to expire, this record can be deleted or marked as inactive. This way, the quantum scheduler 103 has an up-to-date repository of current access tokens which indicates the amount of time for which each of the quantum resources have been reserved. Therefore, new requests can be allocated optimally or refused if there is too much load in the system.

[0089] Figure 4 illustrates quantum resource 105 in more detail as implemented by a computer system 400, which is a hybrid system in the sense that in contains classical parts and quantum parts. That is, the shared quantum resource 105 may be a quantum computing unit comprising a classical controller and multiple qubits. The classical parts comprise processor 401, program memory 402, data memory 403 and communication port 404 which operate in a similar principle as the system components of quantum scheduler 103.

[0090] Unlike quantum scheduler 103, quantum resource 105 further comprises quantum hardware, such as quantum processor 405 including multiple qubits 406, a qubit control apparatus 407 and a readout apparatus 408. Qubits are physical systems that store quantum information in quantum states of the physical systems and quantum operations, such as quantum gates, can be performed on the quantum states taking advantage of superposition of quantum states and entanglement of different qubits.

[0091] Program code stored on program memory 402 causes processor 401 to perform the steps of receiving the access token from the classical computation node 104 and validate the access token, such as by checking the signature is valid. Upon successful validation of the access token, processor 401 controls the quantum processor 405 to perform the quantum job. This may involve that the control apparatus 407 sets each qubit into a desired qubit state andconfigures the qubits and their interaction to perform quantum gate operations. Once the operations have been performed, readout apparatus 408 measures the state of the qubits and provides the result to the processor 401, which then sends the result to the classical computation node 104. Sending the results to the classical computation node 104 may be direct via a point-to-point or network connection or may be indirectly, such as via the quantum scheduler 103 or any other intermediate software or system.

[0092] A wide range of different architectures and implementations are possible for quantum processor 405, including architectures based on photons, quantum dots, nitrogen vacancies in diamond and many others. Further, the quantum resource 105 may comprise other quantum hardware than a quantum processor, such as a quantum sensor using multiple qubits to sense a physical phenomenon or another quantum resource that is shared among multiple classical computation nodes.Implementation

[0093] The quantum scheduler 103 may be implemented as a scheduling agent which is installed by the administrator of a high-performance compute (HPC) cluster featuring one or more QPUs. When the QPUs are initially configured, they are may be given unique passwords (either by the sysadmin or by the hardware vendor). The sysadmin registers each of the QPUs into a queue in a central database of the quantum scheduler 103, along with their IPs and unique passwords.

[0094] When a user submits a user job script to the SLURM module 102 of the cluster, they may request that the job be granted access to one or more QPUs, from one or more queues - in addition to any classical resources that the job requires (CPUs, GPUs, etc). Just before the job starts, SLURM engages the quantum scheduler 103 to obtain a reservation on each of the QPUs for the allotted length of the job. It does this by sending a reservation request to the QPUs, encrypted using the secret password of each QPU. If the reservation is accepted, quantum scheduler 103 returns a unique hashed token that the user’s job can use to validate itself with the QPU for the extent of the job. Only circuits sent in combination with this hashed token will be accepted for execution by the reserved QPU during the period of the reservation.

[0095] When the job completes, SLURM requests that quantum scheduler 103 relinquish all QPU reservations associated with the job. The QPUs are then free to be reserved in the next job. SLURM keeps an internal ledger of the number of QPUs it has already allocated, and therefore how many are available for reservation at any one time. A regular job (cronjob) also runs on status monitor 107 in the background checking the status of each QPU, in order to update SLURM if any QPUs become unavailable for other reasons (maintenance, downtime, etc).

[0096] There are 3 components to this picture: the quantum scheduler 103, the additional plugins that allow it to interoperate with a particular HPC scheduler (e.g., SLURM plugin scripts), and QPU device firmware that is compatible with reservation requests and able to decrypt them using the device’s unique password.

[0097] While some examples disclosed herein relate to a shared quantum resource, it is equally possible that this shared resource is a shared classical resource, such as a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a dedicated artificial intelligence (Al) chip, a signal processor, a cryptographic device or others that do not include computing resources, such as sensors, receivers, emitters, network devices, etc.

[0098] It will be appreciated by persons skilled in the art that numerous variations and / or modifications may be made to the above-described embodiments, without departing from the broad general scope of the present disclosure. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.

Claims

CLAIMS:

1. A method for providing access to a shared quantum resource, the method comprising: receiving quantum job information from a classical scheduler, the quantum job information relating to a quantum job to be performed on the shared quantum resource; determining allocation data indicative of an allocation of the quantum job to the shared quantum resource; sending the allocation data to the shared quantum resource to reserve the quantum resource for the quantum job; obtaining an access token, verifiable by the shared quantum resource, that represents a privilege to perform the quantum job on the shared quantum resource according to the allocation; and sending the access token to a classical computation node to confer, to the classical computation node, the privilege to perform the quantum job on the shared quantum resource according to the allocation.

2. The method of claim 1, wherein obtaining the access token comprises generating the access token or receiving the access token from the shared quantum resource.

3. The method of claim 2, wherein generating the access token is based on a cryptographic method to secure the access token.

4. The method of any one of the preceding claims, wherein the access token comprises a hash value of the quantum job information and only quantum jobs that have the same hash value are accepted by the shared quantum resource.

5. The method of any one of the preceding claims, wherein the shared quantum resource is a quantum computing unit comprising a classical controller and multiple qubits and the quantum job comprises executing a quantum circuit on the qubits and measuring states of the multiple qubits after executing the quantum circuit.

6. The method of any one of the preceding claims, wherein determining the allocation data comprises determining an allocation of time to use the shared quantum resource.

7. The method of claim 6, wherein determining the allocation of time comprises determining an amount of time for which the shared quantum resource is allocated exclusively to the quantum job.

8. The method of claim 6 or 7, wherein determining the allocation of time comprises a validity time window within which the amount of time can be used.

9. The method of any one of the preceding claims, wherein determining the allocation comprises maintaining an allocation fraction below a maximum allocation fraction threshold.

10. The method of any one of the preceding claims, wherein the quantum job information comprises a number of shots and the method further comprises determining an amount of time that is required to perform the number of shots on the shared quantum resource and determining the allocation of the amount of time to the shared quantum resource.

11. The method of any one of the preceding claims, wherein the allocation data is indicative of an allocation of the quantum job to one of multiple shared quantum resources.

12. The method of claim 11, wherein the quantum job information comprises an identification of one of the multiple shared quantum resources for the quantum job and the allocation is based on the identification.

13. The method of any one of the preceding claims, wherein the classical computation node is one of multiple classical computation nodes that access the shared quantum resource using the access token.

14. The method of claim 13, wherein the multiple classical computation nodes concurrently execute respective classical jobs and access the shared quantum resource multiple times during execution of each of the classical jobs.

15. The method of any one of the preceding claims, wherein the access token represents a privilege to terminate another quantum job that is running on the shared quantum resource when the access token is used by the classical computation node.

16. The method of any one of the preceding claims, wherein the method further comprises, upon termination of a classical job that required the quantum job, relinquishing the allocation.

17. The method of any one of the preceding claims, wherein the method further comprises regularly monitoring the shared quantum resource and reporting to the classical scheduler.

18. A system for providing access to a shared quantum resource, the system comprising: a classical scheduler; a quantum scheduler; one or more classical computation nodes; a shared quantum resource; wherein the classical scheduler is configured to receive hybrid job information comprising classical job information and quantum job information; schedule one or more classical computation nodes according to the classical job information; and send the quantum job information to a quantum scheduler; wherein the quantum scheduler is configured to perform the method of claim 1; wherein the classical computation nodes are configured to : receive the access token from the quantum scheduler, and provide the access token to the shared quantum resource; and wherein the shared quantum resource is configured to: receive the access token, validate the access token, upon successful validation of the access token, perform the quantum job, send a result of the quantum job to the one or more classical computational nodes.

19. A quantum resource configured to be shared with multiple classical computation nodes, the quantum resource comprising one or more classical processors and quantum hardware including multiple qubits, wherein the one or more classical processors are configured to perform the steps of:receiving quantum job information relating to a quantum job to be performed on the quantum hardware and an access token from one of the multiple classical computation nodes; validating the access token; upon successful validation of the access token, controlling the quantum hardware to perform the quantum job on the qubits of the quantum hardware; and sending a result of the quantum job to the one or more classical computational nodes.

20. Software, comprising: a quantum scheduler software package configured to cause a classical processor to perform the method of claim 1; a software plug-in for a classical scheduler to provide quantum job information to the quantum scheduler software package; and an interface software component for a shared quantum resource to require an access token to perform a quantum job.

Images