WO2020072819A1 - Parcelled quantum resources - Google Patents

Abstract

In a general aspect, methods and systems are described for dynamically partitioning and virtualizing a monolithic quantum-classical hybrid computing resource into multiple different and independently-saleable, as a resource to a user, parcels. These parcels may comprise configurations of qubits and qubit-qubit links on one or more quantum processor units for use by users for running computer programs.

Description

Parcelled Quantum Resources

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U.S. Provisional Application No. 62/740,808 filed October 3, 2018 and entitled“Parcelled Quantum Resources,” and to U.S. Provisional Application No. 62/746,970 filed October 17, 2018 and entitled“Parcelled Quantum Resources.” The entire contents of the above-referenced priority applications are hereby incorporated by reference.

BACKGROUND

[0002] The following description relates to methods and systems generally related to dynamically partitioning and virtualizing a monolithic quantum-classical hybrid computing resource into multiple different and independently-saleable (as a resource to a user) parcels.

[0003] Quantum computers can perform computational tasks by storing and processing information within quantum states of quantum systems. For example, qubits (i.e., quantum bits) can be stored in and represented by an effective two-level sub-manifold of a quantum coherent physical system. A variety of physical systems have been proposed for quantum computing applications. Examples include superconducting circuits, trapped ions, spin systems and others.

BR1EF DESCRIPTION OF THE DRAW1NGS

[0004] F1G. 1 is a block diagram of an example computing system.

[0005] F1G. 2 is a block diagram of a first example of a computing system including a

QPU resource monitoring, auctioning and scheduling subsystem.

[0006] F1G. 3 is a high level block diagram of a second example computing system including a QPU resource monitoring, auctioning and scheduling subsystem.

[0007] F1G. 4 is a detailed block diagram of the second example computing system of F1G. 3. [0008] F1G. 5 is a flow chart showing example operation of the second example computing system of F1G. 4.

[0009] F1G. 6 is a representation of an example control system architecture for virtualized hybrid quantum classical computing.

[0010] F1G. 7 is a representation of an example virtualizable hybrid quantum-classical processor unit.

[0011] F1G. 8 is a representation of an example of two coherent virtualizable hybrid quantum-classical processor units.

[0012] F1G. 9 is the hybrid quantum-classical processor unit of F1G. 6 showing the Quantum Memory Management Unit in more detail.

[0013] F1G. 10 is a representation of an example 4-processor coherent virtualizable hybrid quantum-classical processor system.

[0014] F1G. 11 is a representation of an example 8-processor coherent virtualizable hybrid quantum-classical processor system with a fully connected topology.

[0015] F1G. 12 is a representation of an example 8-processor coherent virtualizable hybrid quantum-classical processor system with a hypercube connected topology.

[0016] F1G. 13 is an illustration of an example of a multi-tenancy enabled 4 qubit processor.

[0017] F1G. 14 is a representation of a method for enforcing execution ordering between sequencers controlling different qubits.

[0018] F1G. 15 is a flow chart showing an example quantum resource order matching and filling process.

[0019] F1G. 16 is a flow chart showing an example process for matching of quantum computing programs to particular subsets of qubits on one or more quantum computation devices.

[0020] F1G. 17 is a ball and stick representation of an example partitioned quantum processor unit. [0021] F1G. 18 is a ball and stick illustration of a hierarchical plaquette fusion heuristic.

[0022] F1G. 19 is a flow chart showing an example plaquette fusion process.

[0023] F1G. 20 is a flow chart showing an example greedy plaquette request allocation process.

DETA1LED DESCRIPTION

[0024] ln some aspects of what is described here, monolithic quantum-classical hybrid computing resources may be dynamically partitioned and virtualized into multiple different and independently-saleable (as a resource to a user) parcels. These parcels may comprise configurations of qubits and qubit-qubit links on one or more quantum processor units for use by users for running computer programs. This virtualization may extend from the qubit level up through the control system, and including auxiliary classical infra / compute resources for demanding hybrid workloads and jobs. An order matching system can match a demand queue to a set of available dynamically provisioned quantum-classical resources, as part of a front-end system for a user to reserve, provision, and purchase credits for, or time on, hybrid quantum-classical resources of a certain desired

performance level, and for systems for monitoring and metering the use of these resources to provide an account bill or usage statement. Furthermore, in some instances, each qubit control signal may be independently controlled by a thread of computation, implemented by a CPU scheduling operations on the spooler. These threads are synchronized, either with explicit signals, or through deterministic timing. This makes it very natural to allocate a collection of control threads (i.e. those associated with a specific subset of qubits) to each user to natively support multi-tenancy of the hybrid quantum-classical computing resources.

[0025] A connected set of qubits, for example on a quantum integrated circuit, is referred to herein as a plaquette. A plaquette may also be described as a configuration of qubits and qubit-qubit links on one or more quantum computation devices. An epoch is the period of time during which a physical quantum-classical hybrid computing system is provisioned in a particular fixed configuration. The epoch time may be on the order of hours, or minutes, or in embodiments seconds or fractions of seconds. [0026] ln some instances, method for calculating a price for use of a configuration of qubits and qubit-qubit links on one or more quantum processor units by a user for running a computer program, may comprise: accessing a first database by a computer processor unit to collect design characteristics of the one or more quantum processor units, including inferred characteristics pertaining to the expressiveness of the one or more quantum processor units, wherein the inferred characteristics include instruction availability;

accessing a second database by the computer processor unit to collect measurements of physical characteristics of the one or more quantum processor units; accessing a third database by the computer processor unit to collect characteristics of a specific user’s request; and determining the price using data collected from the first, second and third databases.

[0027] ln some instances, a computer system for calculating a price for use of a configuration of qubits and qubit-qubit links on one or more quantum processor units by a user for running a program, may comprise: a first database for storing design

characteristics of the one or more quantum processor units, including inferred

characteristics pertaining to the expressiveness of the device, wherein the inferred characteristics include instruction availability; a second database for storing

measurements of physical characteristics of the one or more quantum processor units; a third database for storing characteristics of a specific user’s request; and a computer processor unit for determining the price, wherein the computer processor unit is linked to the first, second and third databases for accessing input data for the determining.

[0028] ln some instances, a method of auctioning quantum computing resources, may comprise: opening an auction and receiving price bids electronically submitted by users, each price bid having an order with a user desired qubit configuration, each order including a number of qubits, a configuration of qubit connectivities, a lower bound on qubit quality and one or more of a duration, a particular segment of time and a minimum duration; rejecting a specific price bid of the price bids unless the specific price bid satisfies a criteria, the criteria including one or more of: a minimum number of qubits and qubit- qubit links on one or more quantum processor units, a start time of at least a fixed time in the future, and a maximum duration; on satisfaction of one or more specific criteria, closing the auction to any new price bids; activating an order filling process, the order filling process including calculating a plurality of solutions for filling non-conflicting orders, and selecting one of the plurality of solutions according to a metric; and informing users of a status of their price bids. Furthermore, computer systems may be configured to auction quantum computing resources as described above.

[0029] ln some instances, a method of matching quantum computing programs to particular subsets of qubits on one or more quantum processor units, may comprise:

receiving a quantum computing program by an anonymizer unit, the anonymizer unit processing the quantum computing program to remove distinguishing characteristics to provide an anonymized quantum computing program; extracting by an adviser unit of a basic structure of the anonymized quantum computing program, the basic structure including qubit count, qubit connectivity and minimum relaxation or coherence times for qubits; comparing by the adviser unit the basic structure of the anonymized quantum computing program with structures of a plurality of quantum execution targets on the one or more quantum processor units, wherein the plurality of quantum execution targets are subsets of qubits and qubit-qubit links on one or more quantum processor units, and determining appropriate quantum execution targets using a heuristic, the heuristic including one or more of: matching native gate sets, matching plaquette and desired topologies, meeting gate activation fidelity requirements, meeting read-out fidelity requirements, and meeting coherence time or relaxation time requirements; and

generating by the adviser unit of output identifying recommended quantum execution targets for the quantum computing program.

[0030] ln some instances, a computer system for matching quantum computing programs to particular subsets of qubits on one or more quantum processor units, may comprise: (1) an anonymizer unit for: receiving a quantum computing program by the anonymizer unit, the anonymizer unit processing the quantum computing program to remove distinguishing characteristics of a quantum computing program for anonymizing the quantum computing program; and (2) an adviser for: extracting a basic structure of the anonymized quantum computing program, the basic structure including one or more of qubit count, qubit connectivity, native gate sets, fidelity-type measurements of native gates, readout fidelity, execution fidelity, relaxation or coherence time measurements, randomized benchmarking results, run quality of certain standard programs, historical quantum processor unit performance drifts, and coherent and incoherent noise channel measurements; comparing the basic structure of the anonymized quantum computing program with structures of a plurality of quantum execution targets, wherein the quantum execution targets are subsets of qubits and qubit-qubit links on one or more quantum computational devices, and determining appropriate quantum execution targets using a heuristic, the heuristic including one or more of: matching native gate sets, matching plaquette and desired topologies, meeting fidelity requirements, and meeting coherence time or relaxation time requirements; and generating output identifying recommended quantum execution targets for the quantum computing program.

[0031] ln some instances, a method of plaquette fusion, wherein a plaquette is a configuration of qubits and qubit-qubit links on one or more quantum processor units, may comprise: receiving by a computer processor unit a plurality of plaquette requests; sorting by the computer processor unit the plaquette requests by plaquette qubit count; fusing by the computer processor unit the plaquette requests with plaquette qubit count below a predetermined integer value, X, into one or more fused plaquette requests; and submitting a request list to an allocation process, wherein the request list includes the one or more fused plaquette requests and unfused plaquette requests. Furthermore, computer systems may be configured to fuse plaquettes as described above.

[0032] ln some instances, a method of plaquette allocation, wherein a plaquette is a configuration of qubits and qubit-qubit links on one or more quantum processor units, may comprise: receiving by a computer processor unit a plurality of plaquette requests; sorting by the computer processor unit requests by one or more of highest priority, highest revenue per qubit, and highest number of qubits; initializing by the computer processor unit an empty quantum processor unit (QPU) allocation; adding by the computer processor unit the highest priority plaquette request to the allocation; and determining by the computer processor unit if there are any unassigned qubits in the allocation and (a) if there are no unassigned qubits then submit the QPU allocation for the next available epoch, (b) if there are unassigned qubits then further determine if there are any unassigned requests that fit onto the unassigned qubits and (i) if no unassigned requests fit then submit the QPU allocation for the next available epoch, (ii) if unassigned requests fit then add highest priority remaining request to the allocation and repeat the determining. Furthermore, computer systems may be configured to allocate plaquettes as described above.

[0033] F1G. 1 is a block diagram of an example computing environment 100. The example computing environment 100 shown in F1G. 1 includes a computing system 101 and user devices 110A, HOB, HOC. A computing environment may include additional or different features, and the components of a computing environment may operate as described with respect to F1G. 1 or in another manner.

[0034] The example computing system 101 includes classical and quantum computing resources and exposes their functionality to the user devices 110A, 110B, 110C (referred to collectively as“user devices 110”). The computing system 101 shown in F1G. 1 includes one or more servers 108, quantum computing systems 103A, 103B, a local network 109 and other resources 107. The computing system 101 may also include one or more user devices (e.g., the user device H0A) as well as other features and components. A computing system may include additional or different features, and the components of a computing system may operate as described with respect to F1G. 1 or in another manner.

[0035] The example computing system 101 can provide services to the user devices 110, for example, as a cloud-based or remote-accessed computer system, as a distributed computing resource, as a supercomputer or another type of high-performance computing resource, or in another manner. The computing system 101 or the user devices 110 may also have access to one or more other quantum computing systems (e.g., quantum computing resources that are accessible through the wide area network 115, the local network 109 or otherwise).

[0036] The user devices 110 shown in F1G. 1 may include one or more classical processor, memory, user interfaces, communication interfaces, and other components. For instance, the user devices 110 may be implemented as laptop computers, desktop computers, smartphones, tablets or other types of computer devices ln the example shown in F1G. 1, to access computing resources of the computing system 101, the user devices 110 send information (e.g., programs, instructions, commands, requests, input data, etc.) to the servers 108; and in response, the user devices 110 receive information (e.g., application data, output data, prompts, alerts, notifications, results, etc.) from the servers 108. The user devices 110 may access services of the computing system 101 in another manner, and the computing system 101 may expose computing resources in another manner.

[0037] ln the example shown in F1G. 1, the local user device 110A operates in a local environment with the servers 108 and other elements of the computing system 101. For instance, the user device 110A may be co-located with (e.g., located within 0.5 to 1 km of) the servers 108 and possibly other elements of the computing system 101. As shown in F1G. 1, the user device 110A communicates with the servers 108 through a local data

connection.

[0038] The local data connection in F1G. 1 is provided by the local network 109. For example, some or all of the servers 108, the user device 110A, the quantum computing systems 103A, 103B and the other resources 107 may communicate with each other through the local network 109. ln some implementations, the local network 109 operates as a communication channel that provides one or more low-latency communication pathways from the server 108 to the quantum computer systems 103A, 103B (or to one or more of the elements of the quantum computer systems 103A, 103B). The local network 109 can be implemented, for instance, as a wired or wireless Local Area Network, an Ethernet connection, or another type of wired or wireless connection. The local network 109 may include one or more wired or wireless routers, wireless access points (WAPs), wireless mesh nodes, switches, high-speed cables, or a combination of these and other types of local network hardware elements ln some cases, the local network 109 includes a software-defined network that provides communication among virtual resources, for example, among an array of virtual machines operating on the server 108 and possibly elsewhere.

[0039] ln the example shown in F1G. 1, the remote user devices HOB, HOC operate remote from the servers 108 and other elements of the computing system 101. For instance, the user devices 110B, 110C may be located at a remote distance (e.g., more than 1 km, 10 km, 100 km, 1,000 km, 10,000 km, or farther) from the servers 108 and possibly other elements of the computing system 101. As shown in F1G. 1, each of the user devices HOB, HOC communicates with the servers 108 through a remote data connection.

[0040] The remote data connection in F1G. 1 is provided by a wide area network 115, which may include, for example, the lnternet or another type of wide area communication network ln some cases, remote user devices use another type of remote data connection (e.g., satellite-based connections, a cellular network, a virtual private network, etc.) to access the servers 108. The wide area network 115 may include one or more internet servers, firewalls, service hubs, base stations, or a combination of these and other types of remote networking elements. Generally, the computing environment 100 can be accessible to any number of remote user devices.

[0041] The example servers 108 shown in F1G. 1 can manage interaction with the user devices 110 and utilization of the quantum and classical computing resources in the computing system 101. For example, based on information from the user devices 110, the servers 108 may delegate computational tasks to the quantum computing systems 103A, 103B and the other resources 107; the servers 108 can then send information to the user devices 110 based on output data from the computational tasks performed by the quantum computing systems 103A, 103B and the other resources 107.

[0042] As shown in F1G. 1, the servers 108 are classical computing resources that include classical processors 111 and memory 112. The servers 108 may also include one or more communication interfaces that allow the servers to communicate via the local network 109, the wide area network 115 and possibly other channels ln some

implementations, the servers 108 may include a host server, an application server, a virtual server or a combination of these and other types of servers. The servers 108 may include additional or different features, and may operate as described with respect to F1G. 1 or in another manner.

[0043] The classical processors 111 can include various kinds of apparatus, devices, and machines for processing data, including, by way of example, a microprocessor, a central processing unit (CPU), a graphics processing unit (GPU), an FPGA (field programmable gate array), an AS1C (application specific integrated circuit), or combinations of these. The memory 112 can include, for example, a random access memory (RAM), a storage device (e.g., a writable read-only memory (ROM) or others), a hard disk, or another type of storage medium. The memory 112 can include various forms of volatile or non-volatile memory, media and memory devices, etc.

[0044] Each of the example quantum computing systems 103A, 103B operates as a quantum computing resource in the computing system 101. The other resources 107 may include additional quantum computing resources (e.g., quantum computing systems, quantum virtual machines (QVMs) or quantum simulators) as well as classical (non quantum) computing resources such as, for example, digital microprocessors, specialized co-processor units (e.g., graphics processing units (GPUs), cryptographic co-processors, etc.), special purpose logic circuitry (e.g., field programmable gate arrays (FPGAs), application-specific integrated circuits (ASlCs), etc.), systems-on-chips (SoCs), etc., or combinations of these and other types of computing modules.

[0045] ln some implementations, the servers 108 generate programs, identify appropriate computing resources (e.g., a QPU or QVM) in the computing system 101 to execute the programs, and send the programs to the identified resources for execution. For example, the servers 108 may send programs to the quantum computing system 103A, the quantum computing system 103B or any of the other resources 107. The programs may include classical programs, quantum programs, hybrid classical/quantum programs, and may include any type of function, code, data, instruction set, etc.

[0046] ln some instances, programs can be formatted as source code that can be rendered in human-readable form (e.g., as text) and can be compiled, for example, by a compiler running on the servers 108, on the quantum computing systems 103, or elsewhere ln some instances, programs can be formatted as compiled code, such as, for example, binary code (e.g., machine-level instructions) that can be executed directly by a computing resource. Each program may include instructions corresponding to

computational tasks that, when performed by an appropriate computing resource, generate output data based on input data. For example, a program can include instructions formatted for a quantum computer system, a quantum virtual machine, a digital microprocessor, co-processor or other classical data processing apparatus, or another type of computing resource.

[0047] ln some cases, a program may be expressed in a hardware-independent format. For example, quantum machine instructions may be provided in a quantum instruction language such as Quil, described in the publication“A Practical Quantum lnstruction Set Architecture,” arXiv:1608.03355v2, dated Feb. 17, 2017, or another quantum instruction language. For instance, the quantum machine instructions may be written in a format that can be executed by a broad range of quantum processing units or quantum virtual machines ln some cases, a program may be expressed in high-level terms of quantum logic gates or quantum algorithms, in lower-level terms of fundamental qubit rotations and controlled rotations, or in another form ln some cases, a program may be expressed in terms of control signals (e.g., pulse sequences, delays, etc.) and parameters for the control signals (e.g., frequencies, phases, durations, channels, etc.) ln some cases, a program may be expressed in another form or format.

[0048] ln some implementations, the servers 108 include one or more compilers that convert programs between formats. For example, the servers 108 may include a compiler that converts hardware-independent instructions to binary programs for execution by the quantum computing systems 103A, 103B. ln some cases, a compiler can compile a program to a format that targets a specific quantum resource in the computer system 101. For example, a compiler may generate a different binary program (e.g., from the same source code) depending on whether the program is to be executed by the quantum computing system 103A or the quantum computing system 103B.

[0049] ln some cases, a compiler generates a partial binary program that can be updated, for example, based on specific parameters. For instance, if a quantum program is to be executed iteratively on a quantum computing system with varying parameters on each iteration, the compiler may generate the binary program in a format that can be updated with specific parameter values at runtime (e.g., based on feedback from a prior iteration, or otherwise) ln some cases, a compiler generates a full binary program that does not need to be updated or otherwise modified for execution. [0050] ln some implementations, the servers 108 generate a schedule for executing programs, allocate computing resources in the computing system 101 according to the schedule, and delegate the programs to the allocated computing resources. The servers 108 can receive, from each computing resource, output data from the execution of each program. Based on the output data, the servers 108 may generate additional programs that are then added to the schedule, output data that is provided back to a user device 110, or perform another type of action.

[0051] ln some implementations, all or part of the computing environment operates as a cloud-based quantum computing (QC) environment, and the servers 108 operate as a host system for the cloud-based QC environment. The cloud-based QC environment may include software elements that operate on both the user devices 110 and the computer system 101 and interact with each other over the wide area network 115. For example, the cloud-based QC environment may provide a remote user interface, for example, through a browser or another type of application on the user devices 110. The remote user interface may include, for example, a graphical user interface or another type of user interface that obtains input provided by a user of the cloud-based QC environment ln some cases the remote user interface includes, or has access to, one or more application programming interfaces (APIs), command line interfaces, graphical user interfaces, or other elements that expose the services of the computer system 101 to the user devices 110.

[0052] ln some cases, the cloud-based QC environment may be deployed in a

“serverless” computing architecture. For instance, the cloud-based QC environment may provide on-demand access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, services, quantum computing resources, classical computing resources, etc.) that can be provisioned for requests from user devices 110. Moreover, the cloud-based computing systems 104 may include or utilize other types of computing resources, such as, for example, edge computing, fog computing, etc.

[0053] ln an example implementation of a cloud-based QC environment, the servers 108 may operate as a cloud provider that dynamically manages the allocation and provisioning of physical computing resources (e.g., GPUs, CPUs, QPUs, etc.). Accordingly, the servers 108 may provide services by defining virtualized resources for each user account. For instance, the virtualized resources may be formatted as virtual machine images, virtual machines, containers, or virtualized resources that can be provisioned for a user account and configured by a user ln some cases, the cloud-based QC environment is implemented using a resource such as, for example, OPENSTACK ®. OPENSTACK ® is an example of a software platform for cloud-based computing, which can be used to provide virtual servers and other virtual computing resources for users.

[0054] ln some cases, the server 108 stores quantum machine images (QMI) for each user account. A quantum machine image may operate as a virtual computing resource for users of the cloud-based QC environment. For example, a QM1 can provide a virtualized development and execution environment to develop and run programs (e.g., quantum programs or hybrid classical/quantum programs). When a QM1 operates on the server 108, the QM1 may engage either of the quantum processor units 102A, 102B, and interact with a remote user device (HOB or HOC) to provide a user programming environment. The QM1 may operate in close physical proximity to and have a low-latency communication link with the quantum computing systems 103A, 103B. ln some implementations, remote user devices connect with QMls operating on the servers 108 through secure shell (SSH) or other protocols over the wide area network 115.

[0055] ln some implementations, all or part of the computing system 101 operates as a hybrid computing environment. For example, quantum programs can be formatted as hybrid classical/quantum programs that include instructions for execution by one or more quantum computing resources and instructions for execution by one or more classical resources. The servers 108 can allocate quantum and classical computing resources in the hybrid computing environment, and delegate programs to the allocated computing resources for execution. The quantum computing resources in the hybrid environment may include, for example, one or more quantum processing units (QPUs), one or more quantum virtual machines (QVMs), one or more quantum simulators, or possibly other types of quantum resources. The classical computing resources in the hybrid environment may include, for example, one or more digital microprocessors, one or more specialized co processor units (e.g., graphics processing units (GPUs), cryptographic co-processors, etc.), special purpose logic circuitry (e.g., field programmable gate arrays (FPGAs), application- specific integrated circuits (ASICs), etc.), systems-on-chips (SoCs), or other types of computing modules.

[0056] ln some examples, hybrid classical/quantum algorithms may employ a variational execution model in order to accomplish tasks such as, for example, solving combinatorial optimization problems or simulating quantum chemistry. To execute hybrid classical/quantum algorithms according to this model, the server 108 can generate an initial quantum program (e.g., based on a proposed solution to a problem, starting with an initial guess, etc.), and send the initial quantum program to quantum computer resource (e.g., the quantum computer system 103A, the quantum computer system 103B, a QVM, or a combination of them) for execution. Then, from the output of executing the initial quantum program, a classical optimizer running on the server 108 (or another classical computer resource) may update the quantum program for the next round of iteration on the quantum computer resource. Depending on the difficulty of the problem, the quality of the quantum computer resource, and other factors, the iteration loop may be repeated many times before completing the computational task ln some implementations, low- latency hybrid classical/quantum computing can be achieved, for example, when a QM1 operates on a classical machine that is physically located close to a QPU.

[0057] ln some cases, the servers 108 can select the type of computing resource (e.g., quantum or classical) to execute an individual program, or part of a program, in the computing system 101. For example, the servers 108 may select a particular quantum processing unit (QPU) or other computing resource based on availability of the resource, speed of the resource, information or state capacity of the resource, a performance metric (e.g., process fidelity) of the resource, or based on a combination of these and other factors ln some cases, the servers 108 can perform load balancing, resource testing and calibration, and other types of operations to improve or optimize computing performance.

[0058] Each of the example quantum computing systems 103A, 103B shown in F1G. 1 can perform quantum computational tasks by executing quantum machine instructions (e.g., a binary program compiled for the quantum computing system) ln some

implementations, a quantum computing system can perform quantum computation by storing and manipulating information within quantum states of a composite quantum system. For example, qubits (i.e., quantum bits) can be stored in and represented by an effective two-level sub-manifold of a quantum coherent physical system ln some instances, quantum logic can be executed in a manner that allows large-scale entanglement within the quantum system. Control signals can manipulate the quantum states of individual qubits and the joint states of multiple qubits ln some instances, information can be read out from the composite quantum system by measuring the quantum states of the qubits ln some implementations, the quantum states of the qubits are read out by measuring the transmitted or reflected signal from auxiliary quantum devices that are coupled to individual qubits.

[0059] ln some implementations, a quantum computing system can operate using gate- based models for quantum computing. For example, the qubits can be initialized in an initial state, and a quantum logic circuit comprised of a series of quantum logic gates can be applied to transform the qubits and extract measurements representing the output of the quantum computation lndividual qubits may be controlled by single-qubit quantum logic gates, and pairs of qubits may be controlled by two-qubit quantum logic gates (e.g., entangling gates that are capable of generating entanglement between the pair of qubits) ln some implementations, a quantum computing system can operate using adiabatic or annealing models for quantum computing. For instance, the qubits can be initialized in an initial state, and the controlling Hamiltonian can be transformed adiabatically by adjusting control parameters to another state that can be measured to obtain an output of the quantum computation.

[0060] ln some models, fault-tolerance can be achieved by applying a set of high-fidelity control and measurement operations to the qubits. For example, quantum error correcting schemes can be deployed to achieve fault-tolerant quantum computation. Other

computational regimes may be used; for example, quantum computing systems may operate in non-fault-tolerant regimes ln some implementations, a quantum computing system is constructed and operated according to a scalable quantum computing

architecture. For example, in some cases, the architecture can be scaled to a large number of qubits to achieve large-scale general purpose coherent quantum computing. Other architectures may be used; for example, quantum computing systems may operate in small- scale or non-scalable architectures.

[0061] The example quantum computing system 103A shown in F1G. 1 includes a quantum processing unit 102A and a control system 105A, which controls the operation of the quantum processing unit 102A. Similarly, the example quantum computing system 103B includes a quantum processing unit 102B and a control system 105B, which controls the operation of a quantum processing unit 102B. A quantum computing system may include additional or different features, and the components of a quantum computing system may operate as described with respect to F1G. 1 or in another manner.

[0062] ln some instances, all or part of the quantum processing unit 102A functions as a quantum processor, a quantum memory, or another type of subsystem ln some examples, the quantum processing unit 102A includes a quantum circuit system. The quantum circuit system may include qubit devices, readout devices and possibly other devices that are used to store and process quantum information ln some cases, the quantum processing unit 102A includes a superconducting circuit, and the qubit devices are implemented as circuit devices that include Josephson junctions, for example, in superconducting quantum interference device (SQUID) loops or other arrangements, and are controlled by radio frequency signals, microwave signals, and bias signals delivered to the quantum processing unit 102A. ln some cases, the quantum processing unit 102A includes an ion trap system, and the qubit devices are implemented as trapped ions controlled by optical signals delivered to the quantum processing unit 102A. ln some cases, the quantum processing unit 102A includes a spin system, and the qubit devices are implemented as nuclear or electron spins controlled by microwave or radio-frequency signals delivered to the quantum processing unit 102A. The quantum processing unit 102A may be implemented based on another physical modality of quantum computing.

[0063] The quantum processing unit 102A may include, or may be deployed within, a controlled environment. The controlled environment can be provided, for example, by shielding equipment, cryogenic equipment, and other types of environmental control systems ln some examples, the components in the quantum processing unit 102A operate in a cryogenic temperature regime and are subject to very low electromagnetic and thermal noise. For example, magnetic shielding can be used to shield the system components from stray magnetic fields, optical shielding can be used to shield the system components from optical noise, thermal shielding and cryogenic equipment can be used to maintain the system components at controlled temperature, etc.

[0064] ln some implementations, the example quantum processing unit 102A can process quantum information by applying control signals to the qubits in the quantum processing unit 102A. The control signals can be configured to encode information in the qubits, to process the information by performing quantum logic gates or other types of operations, or to extract information from the qubits ln some examples, the operations can be expressed as single-qubit quantum logic gates, two-qubit quantum logic gates, or other types of quantum logic gates that operate on one or more qubits. A quantum logic circuit, which includes a sequence of quantum logic operations, can be applied to the qubits to perform a quantum algorithm. The quantum algorithm may correspond to a computational task, a hardware test, a quantum error correction procedure, a quantum state distillation procedure, or a combination of these and other types of operations.

[0065] The example control system 105A includes controllers 106A and signal hardware 104A. Similarly, control system 105B includes controllers 106B and signal hardware 104B. All or part of the control systems 105A, 105B can operate in a room- temperature environment or another type of environment, which may be located near the respective quantum processing units 102A, 102B. ln some cases, the control systems 105A, 105B include classical computers, signaling equipment (microwave, radio, optical, bias, etc.), electronic systems, vacuum control systems, refrigerant control systems or other types of control systems that support operation of the quantum processing units 102A, 102B.

[0066] The control systems 105A, 105B may be implemented as distinct systems that operate independent of each other ln some cases, the control systems 105A, 105B may include one or more shared elements; for example, the control systems 105A, 105B may operate as a single control system that operates both quantum processing units 102A, 102B. Moreover, a single quantum computer system may include multiple quantum processing units, which may operate in the same controlled (e.g., cryogenic) environment or in separate environments.

[0067] The example signal hardware 104A includes components that communicate with the quantum processing unit 102A. The signal hardware 104A may include, for example, waveform generators, amplifiers, digitizers, high-frequency sources, DC sources, AC sources, etc. The signal hardware may include additional or different features and components ln the example shown, components of the signal hardware 104A are adapted to interact with the quantum processing unit 102A. For example, the signal hardware 104A can be configured to operate in a particular frequency range, configured to generate and process signals in a particular format, or the hardware may be adapted in another manner.

[0068] ln some instances, one or more components of the signal hardware 104A generate control signals, for example, based on control information from the controllers 106A. The control signals can be delivered to the quantum processing unit 102A during operation of the quantum computing system 103A. For instance, the signal hardware 104A may generate signals to implement quantum logic operations, readout operations or other types of operations. As an example, the signal hardware 104A may include arbitrary waveform generators (AWGs) that generate electromagnetic waveforms (e.g., microwave or radio-frequency) or laser systems that generate optical waveforms. The waveforms or other types of signals generated by the signal hardware 104A can be delivered to devices in the quantum processing unit 102A to operate qubit devices, readout devices, bias devices, coupler devices or other types of components in the quantum processing unit 102A.

[0069] ln some instances, the signal hardware 104A receives and processes signals from the quantum processing unit 102A. The received signals can be generated by the execution of a quantum program on the quantum computing system 103 A. For instance, the signal hardware 104A may receive signals from the devices in the quantum processing unit 102A in response to readout or other operations performed by the quantum

processing unit 102A. Signals received from the quantum processing unit 102A can be mixed, digitized, filtered, or otherwise processed by the signal hardware 104A to extract information, and the information extracted can be provided to the controllers 106A or handled in another manner ln some examples, the signal hardware 104A may include a digitizer that digitizes electromagnetic waveforms (e.g., microwave or radio-frequency) or optical signals, and a digitized waveform can be delivered to the controllers 106A or to other signal hardware components ln some instances, the controllers 106A process the information from the signal hardware 104A and provide feedback to the signal hardware 104A; based on the feedback, the signal hardware 104A can in turn generate new control signals that are delivered to the quantum processing unit 102A.

[0070] ln some implementations, the signal hardware 104A includes signal delivery hardware that interfaces with the quantum processing unit 102A. For example, the signal hardware 104A may include filters, attenuators, directional couplers, multiplexers, diplexers, bias components, signal channels, isolators, amplifiers, power dividers and other types of components ln some instances, the signal delivery hardware performs

preprocessing, signal conditioning, or other operations to the control signals to be delivered to the quantum processing unit 102A. ln some instances, signal delivery hardware performs preprocessing, signal conditioning or other operations on readout signals received from the quantum processing unit 102A.

[0071] The example controllers 106A communicate with the signal hardware 104A to control operation of the quantum computing system 103A. The controllers 106A may include classical computing hardware that directly interface with components of the signal hardware 104A. The example controllers 106A may include classical processors, memory, clocks, digital circuitry, analog circuitry, and other types of systems or subsystems. The classical processors may include one or more single- or multi-core microprocessors, digital electronic controllers, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an AS1C (application specific integrated circuit), or other types of data processing apparatus. The memory may include any type of volatile or non-volatile memory or another type of computer storage medium. The controllers 106A may also include one or more communication interfaces that allow the controllers 106A to communicate via the local network 109 and possibly other channels. The controllers 106A may include additional or different features and components.

[0072] ln some implementations, the controllers 106A include memory or other components that store quantum state information, for example, based on qubit readout operations performed by the quantum computing system 103A. For instance, the states of one or more qubits in the quantum processing unit 102A can be measured by qubit readout operations, and the measured state information can be stored in a cache or other type of memory system in or more of the controllers 106A. ln some cases, the measured state information is subsequently used in the execution of a quantum program, a quantum error correction procedure, a quantum processing unit (QPU) calibration or testing procedure, or another type of quantum process.

[0073] ln some implementations, the controllers 106A include memory or other components that store a quantum program containing quantum machine instructions for execution by the quantum computing system 103A. ln some instances, the controllers 106A can interpret the quantum machine instructions and perform hardware-specific control operations according to the quantum machine instructions. For example, the controllers 106A may cause the signal hardware 104A to generate control signals that are delivered to the quantum processing unit 102A to execute the quantum machine instructions.

[0074] ln some instances, the controllers 106A extract qubit state information from qubit readout signals, for example, to identify the quantum states of qubits in the quantum processing unit 102A or for other purposes. For example, the controllers may receive the qubit readout signals (e.g., in the form of analog waveforms) from the signal hardware 104A, digitize the qubit readout signals, and extract qubit state information from the digitized signals ln some cases, the controllers 106A compute measurement statistics based on qubit state information from multiple shots of a quantum program. For example, each shot may produce a bit-string representing qubit state measurements for a single execution of the quantum program, and a collection of bit-strings from multiple shots may be analyzed to compute quantum state probabilities.

[0075] ln some implementations, the controllers 106A include one or more clocks that control the timing of operations. For example, operations performed by the controllers 106A may be scheduled for execution over a series of clock cycles, and clock signals from one or more clocks can be used to control the relative timing of each operation or groups of operations ln some implementations, the controllers 106A may include classical computer resources that perform some or all of the operations of the servers 108 described above. For example, the controllers 106A may operate a compiler to generate binary programs (e.g., full or partial binary programs) from source code; the controllers 106A may include an optimizer that performs classical computational tasks of a hybrid classical/quantum program; the controllers 106A may update binary programs (e.g., at runtime) to include new parameters based on an output of the optimizer, etc.

[0076] The other quantum computer system 103B and its components (e.g., the quantum processing unit 102B, the signal hardware 104B and controllers 106B) can be implemented as described above with respect to the quantum computer system 103A; in some cases, the quantum computer system 103B and its components may be implemented or may operate in another manner.

[0077] ln some implementations, the quantum computer systems 103A, 103B are disparate systems that provide distinct modalities of quantum computation. For example, the computer system 101 may include both an adiabatic quantum computer system and a gate-based quantum computer system. As another example, the computer system 101 may include a superconducting circuit-based quantum computer system and an ion trap-based quantum computer system ln such cases, the computer system 101 may utilize each quantum computing system according to the type of quantum program that is being executed, according to availability or capacity, or based on other considerations.

[0078] F1GS. 2 & 3 are schematic representations of high level block diagrams 200, 300 of example computing systems including QPU resource monitoring, auctioning and scheduling subsystems ln some implementations, elements of the example computing environment 100 shown in F1G. 1 can be cast with an architecture illustrated by the example systems 200, 300 & 400 shown in F1GS. 2, 3 & 4, respectively. The example system 200 shown in F1G. 2 provides users 201 access to the QPU control system 212 via the cloud, the internet, or some other communication link, which is comparable to user device 110 access to quantum computing systems 103 in F1G. 1. F1G. 2 also includes plaquette analysis module 205 and resource auctioning and scheduling system 206, which may be provided on servers 108 in F1G. 1. [0079] Hardware and software systems for virtualized quantum-classical computing are described as follows with reference to the figures. The system capabilities and core concepts that underpin the virtualization of quantum-classical compute systems and their provisioning to multiple simultaneous users are covered starting from the qubit level (for example, the quantum integrated circuit) and including: the dynamical creation and definition of qubit plaquettes with specific performance attributes and characteristics; the hosting on a single QPU multiple user instances connected to those plaquettes and the provisioning of classical resources to support each such instance in a quantum classical architecture, as demanded by the specific job or user.

[0080] ln some embodiments a quantum computing system may be configured such that one or more of the following apply: the number of concurrent computations can be larger than one; concurrent computations are logically independent instances of hybrid quantum-classical algorithms; the number of concurrent computations is larger than the number of aggregated quantum computation resources; one aggregated quantum resource is an entire processor of superconducting qubits (likewise for pother qubit types including ions, spins, nitrogen vacancies (NVs), etc.); the time ordering of concurrent execution of computations is managed by a resource manager; the apportionment of multiple partial resources (plaquettes) from a single aggregate quantum system for computation is managed by a resource manager; the constitution and/or properties of multiple partial resources (plaquettes) apportioned from a single aggregate quantum system for

computation may be modified by a resource manager.

[0081] Users want to run programs on a quantum processor unit (QPU), but often their programs far underutilize the total collection of quantum resources available.

Understanding the resource utilization of individual programs, together with the resource subset availability on the QPU, user’s jobs can be matched with subsets of the available resources to most effectively utilize the QPU. A representation of an example hybrid quantum-classical computing system 200 with subsystems for parceling quantum resources to multiple users 201 is provided in F1G. 2. Users 201 are the external customers for resources. Through the offer interface 202 users can view the available QPU resources including information about embeddable plaquettes and qubit qualities; historic price information may also be provided. On the order interface 203 users can submit an order, or bid, for a certain number of epochs running on a plaquette of a certain size, connectivity and quality of qubits ln the case of an auction-based process, the order interface allows the user to see the success of previously submitted bids and to re-submit a new bid for the next round.

[0082] The resource, auctioning and scheduling subsystem 206 provides the following functions: matches orders to available resources and their usage /access schedule (order book job schedule 207); determines the pricing of plaquettes; accepts or rejects orders submitted by users; manages temporal access control to QPU resources (access control 209); and handles the bookkeeping of consumed epochs on resources (update bookkeeping 208). A usage database 204 stores the record of consumed epochs on plaquettes for each user along with the corresponding price. A plaquette analysis module 205 tracks the properties of available QPU plaquettes over time (across recalibrations of the QPU). A QPU characteristics database 210 stores the quality metrics of each qubit and gate on each QPU. Calibration agents 211 periodically execute recalibration jobs on each qubit of each QPU 212, measure the current performance, and provide the data to the QPU characteristics database 210. The control systems and their connected QPUs 212 include both the classical and quantum compute resources as well as everything required for the interaction of the hybrid resources.

[0083] F1G. 3 is a high-level block diagram of a second example computing system 300 including a QPU resource monitoring, auctioning and scheduling subsystem. System 300 comprises a user interface 301, an engine 302 and QPU plaquettes 303. The user interface 301 comprises a classic computer resource configured to enable: a multitude of users to compose a multitude of algorithms, compile and/or submit the multitude of algorithms for a multitude of executions, receive and/or interact with a plurality of results from the multitude of algorithm executions, and receive and/or interact with information about the system. Some or all of these user interactions may be simultaneous.

[0084] The engine 302 comprises a classic computer resource configured to enable: scheduling a multitude of algorithm requests; composing a multitude of plaquette resources from an aggregate system; monitoring and/or managing the availability of plaquettes for computation; instructing a multitude of QPU plaquettes on a plurality of computation steps; and returning a multitude of execution results. The engine 302 may include a database for storing information.

[0085] The QPU plaquettes 303 comprise multiple quantum-classical hybrid systems operated as independent computational elements, which may be parts of an aggregate system. The QPU plaquettes are configured to allow a multitude of computation

instructions to be concurrently executed across a plurality of QPU plaquettes. The QPU plaquettes may have features at physical or logical boundaries between resources which reduce coupling between plaquettes, as described in more detail below.

[0086] F1G. 4 is a detailed block diagram of the example computing system of F1G. 3; hybrid quantum-classical computing system 400 comprises the following elements. A User interface 401 comprises: a web interface; a command line (e.g. SSH) interface; a GU1 interface and/or a multitude of visualizations; and provides access a system information interface 402 and programming system interface 403. The system information interface 402 provides: visualizations of available resources, including information about potential plaquettes, benchmark information on the plaquettes and component qubits, system availability and scheduling. The system information interface may be periodically updated, for instance by queries to the device database 411.

[0087] The system programming interface provides access to features such as software packages, quantum computing simulation capabilities, compilation capabilities, error checking and/or debugging capabilities, and resource estimators, such as a plaquette generator 406 and/or schedule estimates, for example by providing access to a request database 404. The request database is configured to store requests from a multitude of users, and organize the requests by one or more of the required resources, requested time for use of QPU and/or duration, etc. The scheduler 405 is configured to optimize: parcel resource allocation of requests, time ordering of requests including concurrent execution of requests, and timing of recalibration, all given some objective function(s). For example, the timing of recalibration may be optimized to maximize available run time for jobs, optimized to provide anticipated performance at or above a fixed criteria based on historical performance (which may be recalibration at fixed time intervals), optimized to make system available for highest priority jobs, etc. lnformation about the system may be used for these optimizations, for example system benchmarks (available from device database 411 and/or current (or future) availability (available from resource manager 407).

[0088] Plaquette generator 406 is configured to: encode the properties of an aggregate quantum resource, such as its connectivity and/or benchmarks, as a graph network to represent potential plaquettes; solve for suitable graph configurations for a multitude of concurrent algorithm requests; consider a weighted graph distance metric that includes benchmarks in the weights; and compute properties of plaquettes such as route problems, like minimum spanning tree and/or shortest path and/or longest path and/or statistical properties of graphs. The generator 406 may be employed by users through user interface 401 or programming interface 403.

[0089] Resource manager 407 is configured to: features: monitor the QPU for available resources; assign QPU resources to“unavailable” based on specified criteria, such as poor fidelity, recalibration, etc.; assign QPU resources to“available”; and instruct the formation of plaquettes from a pool of QPU resources. Note that parcels are re-constituted if necessary for a given execution. Plaquette formation may include hardware

reconfiguration, such as: bias adjusted for tunable couplers to cause more/less coupling between qubits; room temperature switch activated to change signal paths; adjustments to control parameters (e.g. modular control 1P). Furthermore, plaquette formation may include software reconfiguration, such as: memory register addresses may be set; CPU threads may be created or deleted; virtual machine instances may be created or deleted. Furthermore, memory addresses that translate virtual resources to physical resources may be set. Furthermore, the resource manager may be embedded in the control system of the aggregate quantum computer, for instance in a host computer or on an FPGA.

[0090] Execution job database 408 may comprise a time-ordered set of executions for the QPU and may be implemented as a stack (queue). Furthermore, the database may be embedded in the control system of the aggregate quantum computer, for instance in a host computer or an FPGA. Furthermore, the database may be re-ordered by the scheduler 405. [0091] Execution engine 409 is configured to send instructions to a multitude of QPU parcels and receive results from a multitude of QPU parcels.

[0092] The QPU plaquettes/parcels 410 may comprise: conventional information processing capabilities; conventional, heterogeneous processing capabilities (e.g. GPUs); sufficient control system to operate a parcel of quantum resources. The QPU parcels may be characterized by: a static relationship between control system and quantum resource (i.e. fixed signal paths); or a dynamic relationship between control system and quantum resource (i.e. switches). The QPU parcels may be configured to enable adjusting control parameters when re-allocation of parcelling is indicated by the resource manager 407.

Note that a pool of QPU parcels may be considered aggregated if run-time execution information and/or quantum information could be exchanged between them.

[0093] Device database 411 may be configured to: store results from benchmarking tests on a multitude of parcels; store results from selected executions on a multitude of parcels; include meta-information about devices in the system, for instance device connectivity and/or status. Results database 412 may be configured to: store the results of executions from a multitude of QPU parcels; organize results according to information pertaining to the job request.

[0094] F1G. 5 is a flow chart showing an example operation of the computing system of F1G. 4. lnformation may be provided to the user (501) through a user interface (401) where the data may include: information about potential plaquettes; information about benchmarks; information about system availability; and information about scheduling. Relevant data may be stored in a database (411). Historical data and/or trends may be stored and/or accessed. Data may be stored in a relational database. Data may be average and/or expected values. Data may include statistical confidence intervals lnformation may be provided to the user through a system information interface (402) and may include: visualizations, for instance of benchmark results; representations of quantum device connectivity, e.g. graphical; and information about the results or expected results of algorithms run on the system and/or on plaquettes. The user may interact with this interface through a web browser and/or GU1 and/or AP1. [0095] A user may compose an algorithm (502) through a user interface (401) and/or through a system programming interface (403): The user may utilize pre-developed software packages to compose an algorithm, for example: Rigetti’s open source Grove package contains a multitude of known quantum algorithms implemented in Quil. These may be made available to users, through a gamming interface. The users may incorporate these as subroutines and/or modify them as they determine. Furthermore, third parties may develop software that is made available to users through the system programming interface (403). The user may utilize simulation capabilities to compose an algorithm. For example, Rigetti’s simulator, the Quantum Virtual Machine (QVM) may be accessible through the system programming interface (403). Users may simulate all or parts of their algorithm with the QVM to test for errors and/or expected behavior. The user may utilize checking and/or debugging capabilities. For example: the interface may allow for checking for compile time errors such as undefined variables and/or operations; the interface may allow for checking of gate depth constraints; the interface may allow for checking of conventional hardware constraints such as recursion limits and/or potential run-time errors; the interface may allow for debugger modes, which may include for instance inspection of breakpoints and thread execution state.

[0096] The algorithm may be compiled (503) through a system programming interface (403). The compilation may include: a translation of an algorithm to a set of machine executable instructions, for instance a set of executable gates and readout operations; translation of an algorithm and/or instructions to another algorithm and/or instructions, for instance reducing the number of gate operations required to approximately implement a unitary to optimize the algorithms efficiency; providing information about potential plaquettes available to perform the algorithm, for instance their connectivity, and/or available gate-set, and/or benchmarks; and providing information about other

compilations, for instance if a requested subroutine has been compiled for use with a previous algorithm.

[0097] The plaquette resources required for an algorithm may be determined (504) by the user and/or compiler at a system programming interface (403), and/or by a scheduler (405). The information used to determine resources may include information stored, for instance in databases, as a few examples: information about the properties of plaquettes may be stored in a device database (411), and/or information about other execution requests may be stored in a request database (404), and/or information about resource availability may be stored in an execution job database (408). A user may submit information that affects the requirements for resources, for instance number of qubits and/or lattice type and/or performance and/or specific plauqette configurations. A multitude of constraints and objective functions may be provided to a plaquette generator (406) that may determine optimized mappings between resource/algorithm request and potential resources.

[0098] The execution of a specific computation may be requested (505) on the system by the user through a system programming interface (403). A requested execution job may be stored (506) by the system, for instance by a database such as request DB (404).

[0099] A requested execution job may be scheduled (507) by a scheduler (405). The scheduler may make use of a plaquette generator (406) to map multiple requests for resources into a multitude of epochs. For example, it may be determined that two jobs can be placed on the system concurrently (as one epoch) if they are determined to be compatible with non-overlapping plaquette resources. The Scheduler may access information about a multitude of requests in the request database (404) and/or in the execution job database (408) to determine schedules of epochs. The Scheduler may access information about the availability of computational resources, for instance by

communication with a resource manager (407). The Scheduler may update users, for instance through the device database (411) and/or the request database (404) with information regarding availability of resources and/or information about the expected timing of a multitude of executions.

[00100] An execution job and/or an epoch of jobs may be stored in a memory (508) such as job execution database (408), that may include scheduling information. The execution job and/or epochs may be stored in a queue or stack data type. The execution job and/or epochs may be stored in a low latency memory cache, for instance local to the control system. [00101] A multitude of plaquettes of hybrid quantum-classical resources may be prepared (509) for the execution of one or more epochs of jobs, by, for instance, a resource manager (407) or an execution engine (409). lnformation about the desired configuration may be taken from the execution job database (408), for instance by querying for the next epoch in a sorted queue or stack. The resource manager (407) may indicate the availability of system resources with respect to the current job and future schedules.

[00102] An epoch may be executed (510) on the system, for instance using a multitude of QPU plaquettes (410). Results of a multitude of executions and associated information may be returned (511), for instance to a database such as a results database (412). Meta information about an execution job within an epoch, such as user information, may determine how the results are stored by the system, for instance memory location. Results may be post-processed or otherwise analyzed by the system, for instance by a multitude of QPU plaquettes (410) or the execution engine (409). Results may be stored in the device database (411), for instance, if the results are pertinent to benchmarks or otherwise understanding aspects about the system and/or specific QPU plaquettes (410). A user may be able to access results from executions, for instance the execution they requested, through a system programming interface (403).

[00103] A multitude of epochs may be executed to evaluate benchmarks (512) or otherwise provide information about the system and/or specific QPU plaquettes (410) intermittently. The execution information about these epochs may include instructions and/or analysis and/or information about recalibration. The execution information about these epochs may be stored in a database such as the execution job database (408) and/or they may be stored and/or managed by a resource manager (407).

[00104] System information may be updated (513) as the result of new information about the system, for instance in response to a change of contents in the device database (411). Such updates may result in changes to the system information interface (402).

[00105] An example control rack architecture 600 for full virtualized hybrid classical quantum computing is shown in F1G. 6. The control rack architecture 600 comprises user specification 601, control lines 602 (which may be multiplexed), readout lines 603 (which may be multiplexed), a hybrid control rack 610 and quantum hardware 620. The hybrid control rack comprises classical control hardware 611 (such as CPUs, GPUs, etc.), XY control spoolers 612, Z control spooler 613, coupling control spooler 614, readout spoolers 615, (612-615 being for waveform operations), DAC/Upconverter 616, and DACs 617. The quantum hardware 620 comprises: qubits 621 and controllable coupler 622.

[00106] The control system may include one or more of the following. Hierarchical architecture within the control system, with abstraction / virtualization within respective layers. Constrain high-RAM allocations to larger qubit plaquettes. For each qubit, one or more control signals is provided to realize IQ, 2Q, or nQ gates, as well as a signal path to read the state of the qubit. The control and readout signals for multiple qubits may be multiplexed, such as RF multiplexing on a transmission line, or optical multiplexing on a fiber. Each control signal is driven by a waveform engine; the waveform engine takes parameters for a gate signal (shape, amplitude, frequency, phase offset, start time) and produces the commanded signals. Readout is accomplished by readout engines consisting of a waveform engine for generating the interrogation signal and an analysis engine for determining the result of the qubit measurement.

[00107] Commands for the waveform and readout engines are provided by the classical compute functionality of the hybrid classical/quantum processor (the“sequencers”). Soft processor(s) may be on the same FPGA as the waveform engine logic and hard processor(s) may be integrated on the same die as the FPGA/AS1C as the waveform engine. Processors are connected to the waveform engine via a high-bandwidth, low-latency (« than the coherence time) communications link/bus. Results from readout engines are distributed to all sequencers that are associated with a plaquette to enable hybrid computing. A mechanism to determine the allocation of physical classical resources shared between sequencers (i.e. RAM physically connected to a group of sequencers) lf a program requires more RAM, it may prevent other programs to run on sequencers that share the same RAM resource, so the user could be charged more to run that program ln some embodiments there is a one-to-one mapping between sequencers and gate signals, so these can be readily partitioned into plaquettes. [00108] Readout signals may be multiplexed, for example 8:1. Each qubit readout is controlled by a single readout transmit sequencer and a readout receive sequencer. The signals for eight transmit sequencers can be added to be combined onto a single readout line. The resulting received waveform is distributed to each of the receive sequencers, each of which uses a matched filter to separate out the readout result from the associated qubit, while rejecting interference from any other readout operations which might be being performed simultaneously. The size of a plaquette could be set to be a multiple of the largest number of multiplexed signals controlled by a single sequencer (in this case 8Q, hence plaquettes would be up to n*8Q). ln this case, the plaquettes would also be physically constrained to include qubits in the corresponding 8Q chunks. For example, a plaquette of 15 qubits might span 3 octagons and hence require an allocation of 3 multiplexed readout lines in this simple solution. Multiplexed readout or signal lines could be serviced by multiple sequencers running separate programs. Readout requests for (two) independent plaquettes that share a multiplexed readout or gate signal can be staggered by the compiler to avoid interference between programs running on the (two) plaquettes. Readout by multiple sequencers would still need to be coordinated by the compiler, or the compiler can allow simultaneous multiplexed access if the specific readout/gate signals are known (from characterization measurements) to not interfere with each other significantly. A method can be provided to guarantee that simultaneous multiplexed access does not occur. This might incur a higher price for the user.

[00109] The hybrid classical quantum system can include a low-latency means of communicating between sequencers, particularly readout results. At compile time, the amount of low-latency traffic generated by a program can be calculated and provides another billable metric ln some implementations, if program A and program B are running simultaneously, and program A requires a lot of iSWAPs, program B may suffer increased latency waiting for the bus to be available to transfer qubit measurement results.

Guaranteed latency metrics could be another billable item ln the preceding example, if the user running program B is willing to pay for the absolute lowest latency, the low-latency messages from program B could be prioritized over the onslaught of messages from program A. [00110] A description of an example embodiment of a multiprocessor for hybrid quantum-classical computing with virtualization support in hardware is provided. The following describes how the task of mapping hybrid quantum-classical programs (jobs) to available hardware can be performed by the hardware itself using concepts from classical computer virtualization.

[00111] As an example, if a user submits a program to be run on four interconnected qubits, that program could start on four specific qubits (call them q0-q3). During the course of execution, there will be periods of time when the qubit states are not classical (i.e in a superposition of states, or entangled), and periods after the qubits states have been measured, and the states are all classical. When the states are all classical, the virtualization manager (“hypervisor”) could decide to migrate the program to a set of four other qubits (call them ql0-ql3), provided the connectivity between the qubits is sufficient for the desired program. This would allow programs to make efficient use of the classical and quantum resources, by letting the hardware reallocate resources as jobs are submitted.

[00112] There are two aspects of this approach which are carefully considered. The first is that the state of each qubit (“clean”: classical 0, classical 1; or quantum indeterminant, “dirty” in the language use below) is propagated throughout the system with low latency. This allows the hypervisor to know which qubits are not immediately in use and thus could potentially be reallocated lt also allows any running program which might have control flow operations that depend on the readout result of a qubit to have the information necessary to execute that control flow. A simple, specific, example of this would be using the readout result to decide if a gate should be played to reset the state of a qubit. This aspect is represented by the Qi state and hygiene mask in the figures below.

[00113] The second aspect is that the quantum gate instructions need to be available with extremely low latency to all the individual control processors for each qubit.

Continuing with the example above, if the users program performs a gate on a qubit, and that gets allocated to qO for one iteration, but then is reallocated to qlO for another iteration, the control system for qlO needs to have that instruction. This aspect is represented by the Qi unitary command in the figures below. The translation table discussed below is what holds the current mapping of programs to qubit resources. The programs are written to use“virtual” qubit addresses, which this table then translates to physical qubits.

[00114] The description below encompasses a range of system scales, from the case where all qubits could be controlled by a single classical compute chip, so that the low- latency shared memory could be implemented as a multi-port memory register, to cases where communication between chips, boards, and chassis are needed ln these later cases, tradeoffs between interconnect density and latency are discussed.

[00115] The hybrid-quantum supercomputer described below is an example of a system of the present invention according to some embodiments.

[00116] F1G. 7 is a representation of an example virtualizable hybrid quantum-classical processor unit, and F1G. 8 is a representation of an example of two coherent virtualizable hybrid quantum-classical processor units. The processor units 700, 800 comprise:

independent QPU cores 701, 801 where each box in the figure corresponds to a thread of execution for an array of N qubit(s); independent CPU cores 702, 802 where each box corresponds to a classical thread of execution (which may be processing an instance, doing minimum weight perfect matching, etc.); local Qache bus 703, 803 which is tightly coupled memory shared between all the QPU and CPU cores on the hybrid processing unit (HPU); processor-to-processor (system) Qache bus 804, 904 which enables coherency of the hybrid shared cache across multiple hybrid processing units; local Qache copy 705, 805, 905, which is cache copy local to a given hybrid processing unit that is managed by that hybrid processor’s Quantum Memory Management Unit (QMMU) and holds coherent copies of all hybrid classical variables and state readout for the entire system; hybrid virtualization manager (hypervisor) 706, 806, 906 loads and manages jobs for execution, and part of managing these jobs includes configuring and maintaining the QMMU; Qache Virtualization Module 707, 807, 907 where the QMMU maintains cache coherence between the local qache copy and the local qache copies of other hybrid processors on the system qache bus. As such the hybrid processor 708, 808, 908 is a collection of concurrent quantum and classical cores that can share memory, and form a standalone-capable unit for hybrid quantum computation. [00117] The neighbor hybrid processor 809 is a second hybrid processor that sits on a cache coherent bus with another hybrid processor. Examples of arbitrary parceling 810 of hybrid resources, which are arbitrary subsets of the available quantum and classical cores from the hybrid multi-processor that form the work units for execution of customer hybrid computation, are indicated in F1G. 8 for customers 1, 2 and 3 as 811, 812 and 813. All arbitrary subsets maintain tight coupling through the shared memory interface (system Qache bus).

[00118] The QMMU and the Qache are shown in detail in F1G. 9. The QMMU and Qache operate with the following: Ci Classical Shared Variable 921, which is a classical bit-string for communicating state/sharing data between QPU and CPU cores; Qi Gate Command 922, which are gate commands for triggering specified state manipulation of qubits Qi from i=0 to i=N, where N is the number of qubits allocated to that QPU core; Qi State 923, which is the last measured state of Qi (if gate has been applied, this Qache entry is marked dirty in the hygiene mask., if measured state is still valid, hygiene mask holds clean for this Qache entry); Qi State Hygiene Mask 924 indicates if quantum information exists in the system for Qi or if Qi contains a bit of classical information. A Coherency Agent 925 uses a cache coherence scheme (snooping, directory based, etc.) to maintain Qache coherency across the multiprocessor system.

[00119] A QMMU Bypass Bus 926 enables a calibration agent by providing direct access to underlying physical qubit resources, and also enables virtual migration within or between systems. The hypervisor 906 has knowledge of qubit topology to process quantum state swap (within the system) when the cache for a qubit state is dirty and re-parcelling is requested lf the qache for the qubit state is clean, the classical information itself can be shuffled (within or outside system) and the freed qubit re-initialized.

[00120] Configurable Translation Table 927 enables virtual“migration” within a system. Qubits can be retargeted system wide by code in situ using this table, alleviating the need to physically move the code around the system in order to reparcel.

[00121] At compile time, user code can be targeted to specific plaquettes, by querying the calibration database for the details of each gate for a corresponding qubit in the plaquette and then synthesizing binary programs consisting of schedules of primitives such as waveforms, delays, phase changes, as well as explicit waits for an operation to complete on another sequencer (communicated via the“spoolnet” described below) ln this case, deterministic programs can be completely specified as a set of scheduled operations with known durations. Alternatively, the user code can be compiled to“relocatable” code that consists of gate operation templates on virtual qubit targets. When the program is scheduled to run on an allocated set of physical qubits, a lookup table is generated mapping the low-level operations that make up the gate operation template on virtual qubits to calibrated operations on the corresponding physical qubits. As an example, a CZ gate on virtual qubits 0 and 1 could result in the following gate operation templates.

[00122] For the Z (flux) control on qubit 0

1. WA1T for“done” message from any XY operations on qubit 0 and qubit 1 to complete. The origin and encoding of the“done” message to wait on is obtained from the lookup table populated by the hypervisor.

2. PLAY waveform at location 0. This location is reserved for the calibrated CZ waveform for this gate

3. SEND message“done” to all controls in this plaquette. The destination and encoding of this“done” message is obtained from the lookup table populated by the hypervisor.

For the XY (gate) control on qubit 0

1. WA1T for“done” message from Z controller

2. DELAY for calibrated time stored in spooler reserved memory location“A” to effect any RZ correction gate needed

3. Send“done” message to all controls in this plaquette. The destination and encoding of this“done” message is obtained from the lookup table populated by the hypervisor.

For the XY (gate) control on qubit 1

1. WA1T for“done” message from Z controller 2. DELAY for calibrated time stored in spooler reserved memory location“A” to effect any RZ correction gate needed

3. Send“done” message to all controls in this plaquette. The destination and encoding of this“done” message is obtained from the lookup table populated by the hypervisor.

[00123] At run time, the lookup tables would be initialized by the hypervisor with the specific details required to target the allocated physical qubits. These instructions then directly populate the scheduling queues of the spooler associated with each controller. See figure“details of a spooler.” Each entry in the scheduling queue has a timestamp or condition indicating when the operation should be executed. The entries can include operations to control oscillators, which could be implemented as numerically controlled oscillators (NCOs) which track the frequency of the qubit operation (i.e. the frequency of the fOl transition or of the CZ02 flux pulse). The entries can also indicate which waveform envelope should be played, as well as which oscillator should be used to modulate the waveform to perform the desired gate operation. The lookup tables could also be implemented by dynamic signal routing between sequencers co-located on the same silicon chip, physical board, or potentially between boards. This would dramatically reduce the latency compared to sending messages over an encoded or multiplexed bus.

[00124] Lower level physical instructions can also be provided as part of the instruction set which bypass the QMMU lookup table functionality to allow direct physical access to the qubit control sequencers. This would provide a natural way to perform calibration operations and system diagnostics. These lower level instructions could be implemented by providing a single“mode” bit in the op-code to distinguish user-level virtual instructions requiring retargeting from lower level system instructions. These lower level system instructions could also be restricted so that only certain memory locations could execute them, as a means of improving system security.

[00125] Arbitrary Qache bus topologies are supported and are limited only by balancing 10 constraints with latency overhead considerations. Here follows a variety of possible Qache Bus topologies as the system scales to many hybrid processing units (arbitrary resource parcelling not shown). A 4-processor coherent system 1000 is shown in F1G. 10; the system comprises four HPUs 1001-1004. F1GS. 11 & 12 show an 8-processor system (HPUs 1101-1108, and HPUs 1201-1208, respectively) with two different coherency topologies - fully connected and hypercube (1209), respectively. The hypercube case could be generalized as connecting the HPU via a network switch which could implement a number of topologies internally - fully connected crossbar, hypercube, hypertorus, etc.. As the system scales past a fully connected graph, the application model, 10 constraints, latency overhead, and bandwidth limitations need to be traded off in the coherency mechanism and topology employed (e.g., the speed of snoop based protocols will be overcome by its bandwidth inefficiency, the 10 scalability of the hypercube will win out over the speed of the fully connected graph, etc.).

[00126] A single user can be allocated resources across multiple HPU units, and the resources within each HPU can be allocated among many simultaneous user programs. At a finer level, multiple users can run on subsets of qubits within each QPU unit, and the classical portion of the program control can run on subsets of the CPU cores available in each HPU.

[00127] The QMMU can parcel up, virtualize, and pool quantum lC’s (even across different fridges). This allows us to offer arbitrary plaquette bundling w/ classical resources - cores can remote write qubits through the Qache bus at a small and bounded latency cost (one hop). This would allow any core to control not only any physical qubit anywhere on the Quantum 1C but even physical qubits on remote lC’s (provided the physical qubit has been mapped by the hypervisor to the program’s virtual address space and the respective daughter cards are accessible over the same Qache Bus). Therefore, there is the flexibility of putting a“foreign system” on the“ring” as in F1GS. 10-12 (where one of the HPUs may be the foreign system).

[00128] Customers may want a mix of dedicated but interconnected resources, as well as multi-tenant resources. For example, a customer may prefer dedicated access to a physical system for reasons including increased performance or more security. The customer can generate a deployment policy that governs how the user applications are deployed to the hardware. This deployment policy would imply requirements on the underlying hardware, and thus could be billed at different rates depending on the demand for the hardware resources. Using the HPU memory-coherency schemes (i.e. Qache) shown above, there are at least three inter-thread latency classes:

Level 1: Local Qache latency (~10’s ns)

Level 11: System Qache Bus latency (~ 100’s ns)

Level 111: Networked latency (~< 1 ms)

[00129] lntra-HPU thread latencies are always Level 1 by definition because they share a local Qache. HPU’s on the same System Qache Bus are“Qache Connected” and have level 11 capable inter-thread latency relationships between them. A level 111 inter-thread relationship can be formed between any HPU’s across the datacenter since it is built from a conventional network connection.

[00130] When deploying an application on the HPU based services, the following decisions need to be made, either automatically by the compiler or other application, or by the user explicitly. First, should the application be constrained to a dedicated set of resources (to the exclusion of other users or applications) or can it target virtualized hardware, and then be mapped to physical hardware dynamically by the hypervisor? Second, various metrics need to be specified: how many QPUs to use (perhaps to parallelize the algorithm); how many interconnected qubits are needed in the lattice for the algorithm to run on; and what classical compute resources are needed (CPU cores, GPU cores, memory space, etc.).

[00131] Second, given the results of the above decisions, what latency class (described above) is needed? For programs that use little to no control flow during the coherence time of the qubits, the latency between qubit controls (spoolers) is of little concern, whereas programs that rely on performing gates conditionally based on the measurements of other qubits will have stringent latency requirements. This will constrain the hypervisor when it allocates the physical resources to run the program.

[00132] Third, the qubit lattices need to be decided. This includes both the topology needed (what degree of interconnection is available and what is most efficient for the algorithm), as well as the qubit technology itself. The HPUs could support QPUs based on a number of qubit technologies (i.e. superconducting qubits, spin qubits, ion traps, etc), some of which may be more suited to a particular algorithm than others.

[00133] Finally, the user can then run their application on a quantum virtual machine, quantum simulator, (using classical compute resources in the HPUs or in dedicated classical compute hardware), and when desired, seamlessly migrate the application to real qubits.

[00134] F1G. 13 shows an example of the hybrid classical computer-quantum control system connected to a four qubit quantum 1C. ln this example two of the qubits, Q0 and Q2 have a fixed frequency, while Q1 and Q2 are tunable via a magnetic flux provided by an additional digital to analog converter channel. The system is scalable to a much larger number of qubits and with many more qubits controlled per control node. All of the soft digital links in this diagram belong to one bus (the system Qache Bus). The Qache bus could be implemented between chips with deterministic low latency using communication protocols such as the GBT/Versatile Link developed at CERN. (See

https://wiki.to. infn.it/lib/exe/fetch.php?media=elettronica:projects:cms_dt:gbtsystem:bar on-gbtfpgaug.pdf ) There is a sideband bus that is not shown here for the sake of simplicity (spoolnet), that is used for timing synchronization and concurrency control.

[00135] ln F1G. 13, the classical CPUs have the same industry-standard architecture as is used in general purpose data centers. This would allow a user’s program to run against a quantum virtual machine (QVM) and then immediately target the real QPU, without needing to recompile the software. This could happen after a user is done prototyping hybrid algorithms on a QVM in the traditional cloud infrastructure and needs to run code on a real Quantum 1C.

[00136] ln F1G. 13, the logic 1306 can be implemented as a standard processor chip connected to a custom logic chip, which in turn could be implemented as an FPGA or an AS1C. This connection could be done inside a standard BGA package, or could be implemented as a stacked multi-chip module. Alternatively, a single custom logic chip could be used, either an FPGA with integrated hard-lP CPUs (e.g. lntel Stratix with ARM CPUs) or as an FPGA with soft-lP CPUs. The custom logic chip could also be an AS1C, with or without a portion of reconfigurable logic for efficient implementation of dynamic re-routing of the internal, on-chip communication busses (Qache and spoolnet) described above. As an example, lntel produces FPGAs with integrated cache coherent high bandwidth

interconnects (QP1 and UPI) designed to interface with high performance Xeon CPUs.

[00137] Each of the physical controls for the qubits can be implemented as a "spooler" which is responsible for tracking the phase of the associated control signals (using, for example, a numerically controlled oscillator), and which produces modulated waveform data for the digital to analog converters (DACs) which produce the analog signals to control the qubit. The spooler may have a pre-loaded waveform library such that specific gate signals can be generated by requesting a given waveform modulated by a specified oscillator frequency and phase. All of these events can be scheduled to occur at a specific time, or on reception of a signal from another spooler or other part of the system. For qubit state readout, the spooler works similarly, but performs a matched filtering operation to determine the qubit state, instead of modulating a gate control waveform.

[00138] During the migration, the hypervisor must configure the QMMU to map the virtual resources specified in the program to physical qubit resources. The Quantum Memory Management Unit (Q-MMU) is a HW accelerated virtualization module in the fabric of the on-die integrated FPGA that is cache coherent with the many hybrid programs running on that chip. The QMMU holds a global view of the Physical Memory of the full hybrid system lt is able to achieve this using an architecture similar to what can be found in cache systems with many cores. Every QMMU in the hybrid system sits on a very low and bounded latency ring (the System Qache Bus) and broadcasts (i.e., for Qache Bus snooping) the following: bit-strings of state resulting from measurement, dirty cache notifications when the host box commands a quantum gate, and updates to shared classical variables. A completely clean quantum state cache implies all qubit states are known and no quantum information exists on the system. At this time, the program state could be frozen and safely swapped around the system. However, because the QMMU can be dynamically

reconfigured by the hypervisor, the virtual to physical mappings of the qubit resources can be modified in situ, and the users virtual resource allocation instance only need be frozen and swapped if it is being completely removed from the system. [00139] Benefits of this architecture include: transparent user virtual resource migration from QVM-capable to QPU-capable; leverage state of the art compute tools by using industry-standard CPU architectures (e.g. x86_64 or ARM); memory used by the quantum program (e.g. a program written in QU1L) is natively available to the CPUs on the system; QMMU virtualization supports arbitrary plaquette bundling with classical resources;

hypervisor and QMMU enables a mixed-tenant model with rapid reallocation of resources; architecture scales to many qubit control cards per chassis, and many chassis per coherent system; latency of a single link is almost same order of magnitude as signal propagation delay, (of order 10's of nanoseconds); there is hardware support for multi-threaded quantum programs; and Global Hybrid Memory aggregated (broadcasts on Qache Bus are bus snooped) & virtualized by QMMU

[00140] A method for Quil Concurrency Control is described with reference to F1G. 14 for enforcing execution ordering between the sequencers controlling different qubits ln the figure, an H gate is being applied to qubit 0, after which the“ml” message is broadcast. The sequencer for qubit 1 is instructed to wait for the“ml” message before executing the commanded CNOT gate. By sending these messages on a different (“out of band”) connection 1405 (referred to here as Spoolnet) than the Qache bus 1404, the latency of these concurrency messages can be guaranteed without impacting the performance of the Qache bus.

[00141] Spoolnet 1405 distributes sub-nanosecond resolution timing and allows quil thread synchronization to be implemented downstream from the QU1L machine 1401, thereby allowing higher level synchronization objects (i.e., no explicit notion of time, only synch primitives) to be used at the Quil Machine level. These primitives are embedded in the Quil instruction as a tag and require no Quil Machine clock cycle overhead, yet provide maximum latency performance in enforcing inter-qubit gate dependencies between threads.

[00142] This scheme for concurrency control has many benefits including: guarantees satisfaction of gate dependencies; no need for dedicated clock trees; abstracts timing from QU1L machine by implementing QU1L synch primitives; deterministic, sub-nanosecond timing can be accomplished over standard computer data connections like Ethernet by using techniques similar to those developed as part of the White Rabbit protocol ( see https://white-rabbit.web.cern.ch/ ); Out of Band traffic preserves tight/predictable latencies on Qache Bus and Spoolnet

[00143] ln summary, for some embodiments of the coherent virtualizable hybrid quantum-classical processor system described above with reference to F1GS. 7-14 the following advantages can be achieved. First, each qubit control signal is independently controlled by a thread of computation (implemented by a CPU scheduling operations on the spooler). These threads are synchronized, either with explicit signals, or through deterministic timing. This makes it very natural to allocate a collection of control threads (i.e. those associated with a specific subset of qubits) to each user to natively support multi-tenancy. Second, by implementing these independent control threads with an industry standard CPU architecture, the same computer hardware is used for both the classical computations of the hybrid program, as well as for executing the quantum gates. Thus, there is less of a boundary between the classical part of the program and the quantum part. As an example, instead of having a QU1L program running on specialized arbitrary waveform generator hardware, waiting for gate parameters from a standard computer which is running a classical optimizer, we have the optimizer running on a CPU and when a quantum result is needed, the same code on the same CPU executes the necessary quantum instructions, and the qubit results appear directly in the memory space of the same CPU so that the optimizer can continue operation immediately.

[00144] Systems and methods for matching orders within a demand queue to a set of dynamically provisioned quantum-classical instances, and allocating such instances to particular jobs/users are described as follows. A system is described that, each epoch, takes as input both the order book (demand queue) and the physical system capabilities (the available quantum-classical instances / plaquettes) and provides a partitioned and provisioned system for the duration of that epoch. This system may also receive as input the performance and quality metrics of the qubits and other system characteristics. A connected set of qubits on a quantum 1C is referred to herein as a“plaquette”, which may also be described as a configuration of qubits and qubit-qubit links on one or more quantum computation devices. An“epoch” is defined herein as the period of time during which a physical quantum-classical hybrid computing system is provisioned in a particular fixed configuration; the epoch time may be on the order of hours, or minutes, or in embodiments seconds or fractions of a second.

[00145] Methods of determining the price of plaquettes sold on a hybrid quantum- classical computer system are varied and different approaches may be suitable for different circumstances. The minimum unit of time for utilizing a plaquette on a QPU that may be purchased is most conveniently a single epoch, or in some embodiments, multiple epochs. Furthermore, a user will often want to start use at a specified time or at least within a specified time window. Prices for specific qubits or groups of qubits from amongst a QPU chip full of qubits may be varied depending on factors such as fidelity of qubits and groups of qubits ln some embodiments a hybrid quantum-classical computer system may autonomously sample and measure its own fidelity and use those fidelities as an input to a) order matching; b) plaquette decomposition of the full chip; c) pricing of plaquettes.

Furthermore, plaquettes that remove the possibility for large adjacent plaquettes on a chip may be priced at a premium.

[00146] When one doesn’t know a priori what QPU time is worth, a customer’s application/request is going to inform this, and auction type of pricing models may be effective. For example, a second price auction may be used where the winner of the auction is the second highest price offered. An auction system can comprise multiple rounds of bidding, although multiple bidding rounds might not always be directly compatible with a real-time bidding/scheduling process. The auction process can sell specific future epochs on the qubits of a QPU. One round of the concrete auction system could look as follows: users submit collection of bids for epochs on plaquettes; auction backend greedily produces several alternative plaquette schedules potentially combining several bids that can run concurrently to maximize the revenue of such a bid combination and usage of the QPU; the second most valuable bid combination wins the round; in addition to selling fixed future scheduled qubits one can also always keep part of the QPU free to accept high priority jobs in real time based on a single round bidding process.

[00147] An example computing system that assigns prices to different qubit regions on a quantum processor may take input from several sources: a long-term database of design characteristics of the device (e.g., qubit count, qubit connectivity); a short-term database of measurements pertaining to the physical characteristics of the device (e.g., one-qubit, qubit-qubit interaction, and readout fidelities, gate fidelity, native gate availability, qubit count, link count, link topology, coherence time, relaxation time, etc.); inferred

characteristics pertaining to the expressiveness of the device (e.g., instruction availability); a database of user requests (e.g., system-wide strain, historical usage patterns); and the particular characteristics of a given user’s request (e.g., urgency or expected duration).

This information can be retrieved from remote stores via network communication, from remote agents via network communication, from local caches. The system may be configured to assign prices to plaquettes based on: their physical characteristics; response to user demand; on historical popularity; and immediacy.

[00148] The system may be configured to automatically assess the physical

characteristics of a quantum device for input to a pricing model. The system may assign prices to plaquettes through a (multiple-round) pricing auction. Furthermore, a process may be implemented that validates plaquette fidelity immediately before user residence begins.

[00149] ln some instances, method for calculating a price for use of a configuration of qubits and qubit-qubit links on one or more quantum processor units by a user for running a computer program, may comprise: accessing a first database by a computer processor unit to collect design characteristics of the one or more quantum processor units, including inferred characteristics pertaining to the expressiveness of the one or more quantum processor units, wherein the inferred characteristics include instruction availability;

accessing a second database by the computer processor unit to collect measurements of physical characteristics of the one or more quantum processor units; accessing a third database by the computer processor unit to collect characteristics of a specific user’s request; and determining the price using data collected from the first, second and third databases.

[00150] ln some instances, a computer system for calculating a price for use of a configuration of qubits and qubit-qubit links on one or more quantum processor units by a user for running a program, may comprise: a first database for storing design characteristics of the one or more quantum processor units, including inferred characteristics pertaining to the expressiveness of the device, wherein the inferred characteristics include instruction availability; a second database for storing

measurements of physical characteristics of the one or more quantum processor units; a third database for storing characteristics of a specific user’s request; and a computer processor unit for determining the price, wherein the computer processor unit is linked to the first, second and third databases for accessing input data for the determining.

[00151] An embodiment of a long-term ordering matching system is shown in F1G. 15. Users submit bids (via a web interface, via a web AP1, ...) on desired order configurations, which may include: a particular segment of time (e.g., 9am-5pm on 7/2/2018), a particular duration (e.g., one hour), or a minimum duration (e.g., at least one hour); a particular subset of qubits (e.g., qubits 0-5), a particular configuration of qubit connectivities (e.g., a T-shaped configuration of four qubits), or a particular quantity of qubits (e.g., any four qubits); a lower bound on qubit quality (e.g., minimum readout fidelity of at least 95%); as well as other qualities.

[00152] The orders are rejected unless they satisfy certain criteria, so as to constrain the auction. Such criteria may include: a minimum plaquette size (e.g., at least 8 qubits requested), sufficiently distant start time (e.g., no sooner than three days after the end of the auction), a maximum duration (e.g., no longer than one day), as well as other qualities. These criteria are chosen so as to simplify the packing process: larger orders admit fewer possible configurations; separating the start times for the orders of large and small qubit counts ensure that only large qubit count orders initially need to be packed; a limited duration makes resource exclusion less likely; and so on. Different order filling processes may generate different constraint sets.

[00153] Bids (both the offered value and the configuration data as specified in item 1 above) are captured in an order database, where they collect. After some interval of time passes (e.g., the duration of time available to bidders in the auction divided by the number of rounds in the auction, so as not to keep the auction horizon a fixed distance away), a background process locks the order database, disallowing any more orders to be placed. [00154] An order filling process then activates, calculating several possible ways that non-conflicting orders could be filled. One such filling is then selected according to some metric (e.g., the nth most revenue-maximizing possibility). A bidding round counter is decremented lf the counter is zero, the order filling selection from the previous step is sent to the scheduler database as the plan of record, and the counter is reset to the number of rounds in the next auction ln both cases, the users participating in the bidding process are informed of the results. The order database is cleared and unlocked.

[00155] ln some instances, a method of auctioning quantum computing resources, may comprise: opening an auction and receiving price bids electronically submitted by users, each price bid having an order with a user desired qubit configuration, each order including a number of qubits, a configuration of qubit connectivities, a lower bound on qubit quality and one or more of a duration, a particular segment of time and a minimum duration; rejecting a specific price bid of the price bids unless the specific price bid satisfies a criteria, the criteria including one or more of: a minimum number of qubits and qubit- qubit links on one or more quantum processor units, a start time of at least a fixed time in the future, and a maximum duration; on satisfaction of one or more specific criteria, closing the auction to any new price bids; activating an order filling process, the order filling process including calculating a plurality of solutions for filling non-conflicting orders, and selecting one of the plurality of solutions according to a metric; and informing users of a status of their price bids. Furthermore, computer systems may be configured to auction quantum computing resources as described above.

[00156] Determining plaquette resources needed for a program, with quality estimate of the resources, can be done while preserving customer security and an agreement that the service provider won’t inspect the semantics of their programs or how they’re using their data by anonymizing a program. For example, stripping the gate descriptions, except for some basic properties, in some embodiments including one or more of: what resources an instruction acts on; whether an instruction performs a measurement; an estimate of the number of times a given instruction might be executed; and a desired list of native instructions. [00157] Comparing a program against a list of available plaquettes, may include in some embodiments measuring against one or more of: matching high-activity program links with high-fidelity QPU links; matching program topology (after restricting to high-activity links, for cases where the problem is made easier) with native QPU topology; matching program qubit count with QPU qubit count.

[00158] See the flow chart in F1G. 16 for an example of some embodiments. A user sends one or more quantum programs to a locally-running anonymizer. The anonymizer removes distinguishing characteristics of the quantum program, then returns the anonymized quantum program(s) to the user. Examples of anonymization techniques include: removing gate parameters, removing gate names, permuting gates, removing control structures (perhaps retaining expected execution count for each instruction), removing all instructions and retaining only the expected gate set, as well as others. The user then submits the anonymized program(s) to an adviser, which may reside on a remote server (e.g., one owned and operated by the service provider) or which may also reside on the user’s machine. The adviser retrieves a list of available plaquettes, together with their operating characteristics. (The precise transmission mechanism here depends on the residence of the adviser.) Operating characteristics may include: qubit counts, qubit connectivities, native gate sets, fidelity-type measurements of native gates, readout fidelity, relaxation or coherence time (T1 or T2) measurements, randomized benchmarking results, run quality of certain standard programs, historical drifts, coherent and incoherent noise channel measurements, as well as others. This retrieved data may contain information about all quantum devices or about just some; and it may contain information about all sub -plaquettes that could be leased on this device or about just those plaquettes which are available to be leased within some time window. The adviser then applies a combination of heuristics to judge the appropriateness of each plaquette for program execution. The set of heuristics might include matching native gate sets, matching plaquette and desired topologies, meeting fidelity requirements, meeting coherence time or relaxation time requirements, as well as others. Finally, the adviser returns these scores to the user.

[00159] ln some embodiments, the adviser, which may be a computationally expensive service, can run on a remote server or on the user’s local machine lf the adviser service runs on a remote machine, the user might first anonymize their program contents while preserving the salient operating characteristics ln both cases, the adviser service retrieves a list of available plaquettes and their operating characteristics from the service providers data servers. This data may contain information about all of the service provider’s quantum devices or about just some; and it may contain information about all sub- plaquettes that could be leased on this device or about just those plaquettes which are available to be leased within some time window.

[00160] An example system according to some embodiments may be a system that marries quantum programs to potential plaquette venues.

[00161] An example process according to some embodiments may be a process that: anonymizes quantum programs by erasing identifying characteristics; anonymizes quantum programs for structural analysis by third parties; combines the structural analyses of several quantum programs into a single collection of desiderata; compares the structure of one or more quantum programs with the structure of a quantum execution target and execution fidelity; compares the structure of a quantum program with the structure of a quantum execution target and estimates transfer faithfulness; compares the structure of a quantum program with the fidelity properties of a quantum execution target and estimates overall decrease in quality.

[00162] Herein an identifying characteristic of a quantum program may include the names of gates, the parameters of gates, the ordering of gates, etc.

[00163] ln some instances, a method of matching quantum computing programs to particular subsets of qubits on one or more quantum processor units, may comprise:

receiving a quantum computing program by an anonymizer unit, the anonymizer unit processing the quantum computing program to remove distinguishing characteristics to provide an anonymized quantum computing program; extracting by an adviser unit of a basic structure of the anonymized quantum computing program, the basic structure including qubit count, qubit connectivity and minimum relaxation or coherence times for qubits; comparing by the adviser unit the basic structure of the anonymized quantum computing program with structures of a plurality of quantum execution targets on the one or more quantum processor units, wherein the plurality of quantum execution targets are subsets of qubits and qubit-qubit links on one or more quantum processor units, and determining appropriate quantum execution targets using a heuristic, the heuristic including one or more of: matching native gate sets, matching plaquette and desired topologies, meeting gate activation fidelity requirements, meeting read-out fidelity requirements, and meeting coherence time or relaxation time requirements; and

generating by the adviser unit of output identifying recommended quantum execution targets for the quantum computing program.

[00164] ln some instances, a computer system for matching quantum computing programs to particular subsets of qubits on one or more quantum processor units, may comprise: (1) an anonymizer unit for: receiving a quantum computing program by the anonymizer unit, the anonymizer unit processing the quantum computing program to remove distinguishing characteristics of a quantum computing program for anonymizing the quantum computing program; and (2) an adviser for: extracting a basic structure of the anonymized quantum computing program, the basic structure including one or more of qubit count, qubit connectivity, native gate sets, fidelity-type measurements of native gates, readout fidelity, execution fidelity, relaxation or coherence time measurements,

randomized benchmarking results, run quality of certain standard programs, historical quantum processor unit performance drifts, and coherent and incoherent noise channel measurements; comparing the basic structure of the anonymized quantum computing program with structures of a plurality of quantum execution targets, wherein the quantum execution targets are subsets of qubits and qubit-qubit links on one or more quantum computational devices, and determining appropriate quantum execution targets using a heuristic, the heuristic including one or more of: matching native gate sets, matching plaquette and desired topologies, meeting fidelity requirements, and meeting coherence time or relaxation time requirements; and generating output identifying recommended quantum execution targets for the quantum computing program.

[00165] ln some embodiments there is some kind of matching between an order book (whose rows consist of a user, a program, a qubit configuration (which consists of both a topology and fidelity requirements), and in some embodiments a time limit) and the available sub-plaquettes of a partially-utilized QPU. There are many variables here, including: some users pay more and get priority in the matching process; the process is optimized for revenue, and accordingly schedules more resource-intensive jobs (which can be priced more highly) more aggressively ln some embodiments particular plaquette configurations (in some embodiments based on previous experience that a particular configuration is useful) rather than allowing them to be split up into less useful

configurations.

[00166] F1G. 17 shows a small 16Q QPU over 4 epochs (t=0, 1, 2, 3) where individual qubits are grouped into a plaquette for each epoch (filled circles). Plaquettes can generally persist for several epochs (vertical dashed lines) and may be separated by unused and inactive qubits (open circles) to prevent or reduce cross-talk or entanglement between plaquettes.

[00167] As represented in F1G. 18, in some embodiments individually requested plaquettes are combined to larger and more regularly shaped (e.g., convex with near minimal circumference) subgraphs, with reserved unused and inactive qubits for crosstalk reduction, etc. as discussed above. The graph of 2-qubit gates naturally provides a criterion for how such a boundary should be defined. For example, one could require that when removing the boundary unused qubits from the 2-qubit graph, the graph components corresponding to different plaquettes must be disconnected, i.e., no path exists that originates in one plaquette and ends in another. A different way of defining which qubits must be unused and inactive could be by using an empirically calibrated matrix of qubit- qubit cross-talk, i.e., a matrix (SJk) where j and k are labels for qubits on the device which specifies the strength (e.g., in decibels or some other relevant unit) of cross-talk between qubits j and k. ln this case the requirement could be to disallow any qubits labeled j, k from different plaquettes to have Sjk larger than some threshold. Combined plaquette blocks can be merged to form ever larger tiles.

[00168] F1G. 19 shows a method, according to some embodiments, to preprocess a list of plaquette requests by combining requests for plaquettes below a certain size (number of qubit) threshold. For example, there may be a very large number of requests for single and two qubit plaquettes. These should generally be easy to allocate, but any part of the allocation procedure that scales strongly with the total number of requests may be slowed down by the need to handle all these simple requests. By fusing several small requests into a larger request may make the process more efficient. This may reduce the complexity of the subsequent allocation/scheduling step. Specifically, a list of incoming plaquette requests may be sorted by their priority, the effective revenue per qubit and their necessary number of qubits ln a subsequent loop, all requests with number of qubits below some minimal number X, e.g., X = 2 or X = 10, are successively fused with other requests into a single effective request which now contains more qubits than X. Finally, the list which now only contains requests above a certain size is submitted for further processing.

[00169] ln some instances, a method of plaquette fusion, wherein a plaquette is a configuration of qubits and qubit-qubit links on one or more quantum processor units, may comprise: receiving by a computer processor unit a plurality of plaquette requests; sorting by the computer processor unit the plaquette requests by plaquette qubit count; fusing by the computer processor unit the plaquette requests with plaquette qubit count below a predetermined integer value, X, into one or more fused plaquette requests; and submitting a request list to an allocation process, wherein the request list includes the one or more fused plaquette requests and unfused plaquette requests. Furthermore, computer systems may be configured to fuse plaquettes as described above.

[00170] According to some embodiments, and as shown in F1G. 20, plaquette requests from the order book can be sorted by one or more of: priority, cost per qubit and/or number of qubits. An empty allocation is created which is subsequently filled in a loop: starting from the highest priority, highest revenue requests, the QPU is greedily allocated until no more requests exist that can be allocated. Finally, the complete allocation for one epoch is submitted.

[00171] ln some instances, a method of plaquette allocation, wherein a plaquette is a configuration of qubits and qubit-qubit links on one or more quantum processor units, may comprise: receiving by a computer processor unit a plurality of plaquette requests; sorting by the computer processor unit requests by one or more of highest priority, highest revenue per qubit, and highest number of qubits; initializing by the computer processor unit an empty quantum processor unit (QPU) allocation; adding by the computer processor unit the highest priority plaquette request to the allocation; and determining by the computer processor unit if there are any unassigned qubits in the allocation and (a) if there are no unassigned qubits then submit the QPU allocation for the next available epoch, (b) if there are unassigned qubits then further determine if there are any unassigned requests that fit onto the unassigned qubits and (i) if no unassigned requests fit then submit the QPU allocation for the next available epoch, (ii) if unassigned requests fit then add highest priority remaining request to the allocation and repeat the determining. Furthermore, computer systems may be configured to allocate plaquettes as described above.

[00172] ln further embodiments:

[00173] A computing process for allocating quantum computing resources to specific resource requests as described herein, may further include one or more of: wherein each resource request and allocation may be for a specific period of time as measured in epochs; wherein an allocation may be specified by providing the epoch, by listing the exact qubit addresses on the QPU for each plaquette and assigning each plaquette to a specific resource request; wherein a resource request may specify a user id that is granted exclusive access to the quantum computing resources during the scheduled epoch; wherein the plaquette allocation for a single epoch may be stored in a computer memory and/or on a hard disk, e.g., within a database; and wherein resource requests can originate from different users, where they can have been submitted at different times and they are self-contained.

[00174] A computing process for allocating quantum computing resources to specific resource requests as described herein, may further include one or more of: selecting a simultaneously allocatable request subset in such a way that it exactly or approximately maximizes revenue; ensuring that request priorities are respected; allocating resources in a round robin fashion across some category of users that submit requests, where the category is defined by a user priority, and/or where the category is defined by a pricing tier; allocating resources based on an auction process with multiple rounds of bidding; applying a heuristic to allocate and schedule user access to qubits on a quantum processor; scheduling a heuristic that operates by hierarchically combining requests for qubit plaquettes of comparable size in order to make the scheduling problem tractable by allocating larger segments of the quantum processor at once, where requested plaquettes can be grouped by their size and connectivity (very small plaquettes are then combined into larger super-plaquettes with ideally very simple shapes - e.g. rectangular - that are subsequently easier to tile the full QPU with; scheduling and partitioning qubits on a quantum processor such that cross-talk from simultaneously executed programs on nearby plaquettes is minimized; scheduling and partitioning that minimizes cross-talk by separating allocated plaquettes by non-allocated qubits (when embedding/allocating requested plaquettes into the QPU connectivity graph one can mark a layer of immediately surrounding“buffer” qubits from being allocated in subsequent embeddings), where the control system for“buffer” qubits may in instances just be idle for the duration of the scheduled epoch.

[00175] A computing process for allocating quantum computing resources to specific resource requests as described herein, may further include one or more of: combining individually requested plaquettes into larger and more regularly shaped (e.g., convex with near minimal circumference) subgraphs, with reserved“dead” qubits for cross-talk reduction. The graph of 2-qubit gates naturally provides a criterion for how such a boundary should be defined. E.g., one could require that when removing the boundary “dead” qubits from the 2-qubit graph, the graph components corresponding to different plaquettes MUST be disconnected, i.e., no path exists that originates in one plaquette and ends in another. A different way of defining which qubits must be dead could be by using an empirically calibrated matrix of qubit-qubit cross-talk, i.e, a matrix (SJk) where j and k are labels for qubits on the device which specifies the strength (e.g., in decibels or some other relevant unit) of cross-talk between qubit j and k. ln this case the requirement could be to disallow any qubits labeled j, k from different plaquettes to have Sjk larger than some threshold.

[00176] A computing system for allocating quantum computing resources to specific resource requests as described herein, may further include one or more of: a scheduling system that schedules repartionable connected resources over several time epochs; a scheduling system that minimizes repartitioning overhead associated with scheduling connected resources over several time epochs by stacking requests for similarly sized plaquettes along the time (epoch) axis (i.e., it allocates the same plaquettes to these requests but at different times), wherein the qubit connectivity graph is a graph with all qubits of a QPU as nodes and an edge for every available 2-qubit gate.

[00177] lt is noted that: a single epoch QPU allocation is given by a specification of non intersecting plaquettes where each plaquette is assigned to a particular user; and a resource request specifies a minimum number of qubits, a minimum degree of connectivity (or alternatively a specific required connectivity graph), a required level of average quality (gate fidelity, coherence time), a required number of epochs and the price or a range of prices that the user has agreed to pay.

[00178] ln some embodiments there may be different types of prepaid credits ln some embodiments, a“bin filling” mechanism is used where the available plaquettes are“bronze” plaquettes, a few“silver” plaquettes, and a couple of“gold” ones, which are statically determined blocks,“gold” being the highest value blocks.

[00179] Some of the subject matter and operations described in this specification can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Some of the subject matter described in this specification can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions, encoded on a computer storage medium for execution by, or to control the operation of, data-processing apparatus. A computer storage medium can be, or can be included in, a computer-readable storage device, a computer-readable storage substrate, a random or serial access memory array or device, or a combination of one or more of them. Moreover, while a computer storage medium is not a propagated signal, a computer storage medium can be a source or destination of computer program instructions encoded in an artificially generated propagated signal. The computer storage medium can also be, or be included in, one or more separate physical components or media (e.g., multiple CDs, disks, or other storage devices). [00180] Some of the operations described in this specification can be implemented as operations performed by a data processing apparatus on data stored on one or more computer-readable storage devices or received from other sources.

[00181] Data-processing apparatus encompass all kinds of apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, a system on a chip, or multiple ones, or combinations, of the foregoing. The apparatus can include special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an AS1C (application specific integrated circuit). The apparatus can also include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, a cross -platform runtime environment, a virtual machine, or a combination of one or more of them.

[00182] A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, object, or other unit suitable for use in a computing environment. A computer program may, but need not, correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.

[00183] Some of the processes and logic flows described in this specification can be performed by one or more programmable processors executing one or more computer programs to perform actions by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatus can also be

implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an AS1C (application specific integrated circuit). [00184] While this specification contains many details, these should not be understood as limitations on the scope of what may be claimed, but rather as descriptions of features specific to particular examples. Certain features that are described in this specification or shown in the drawings in the context of separate implementations can also be combined. Conversely, various features that are described or shown in the context of a single implementation can also be implemented in multiple implementations separately or in any suitable sub-combination.

[00185] Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results ln certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the implementations described above should not be understood as requiring such separation in all implementations, and it should be understood that the described program components and systems can generally be integrated together in a single product or packaged into multiple products.

[00186] A number of embodiments have been described. Nevertheless, it will be understood that various modifications can be made. Accordingly, other embodiments are within the scope of the following claims.

Claims

CLA1MS What is claimed is:

1. A method for calculating a price for use of a configuration of qubits and qubit-qubit links on one or more quantum processor units by a user for running a computer program, comprising: accessing a first database by a computer processor unit to collect design

characteristics of the one or more quantum processor units, including inferred

characteristics pertaining to the expressiveness of the one or more quantum processor units, wherein the inferred characteristics include instruction availability; accessing a second database by the computer processor unit to collect

measurements of physical characteristics of the one or more quantum processor units; accessing a third database by the computer processor unit to collect characteristics of a specific user’s request; and determining the price using data collected from the first, second and third databases.

2. The method of claim 1, further comprising accessing a fourth database by the computer processor unit to collect data characterizing a multiplicity of user requests, including user requests by different users, and wherein the determining the price uses data collected from the first, second, third and fourth databases.

3. The method of claim 1, wherein the computer processor unit is configured to calculate a price based at least in part on the physical characteristics of the one or more quantum processor units.

4. The method of claim 1, wherein the computer processor unit is configured to determine a price based at least in part on user demand for use of the one or more quantum processor units.

5. The method of claim 4, wherein the price is determined through a pricing auction comprising one or more rounds.

6. The method of claim 4, wherein the computer processor unit is configured to determine a price based at least in part on a popularity of the specific configuration of qubits and qubit-qubit links being requested by the user.

7. The method of claim 4, wherein a user requests to run the program within a specified time frame, and wherein the computer processor unit is configured to determine a price based at least in part on the specified time frame.

8. The method of claim 1, wherein the first database includes information on qubit count and qubit connectivity.

9. The method of claim 1, wherein the second database includes one or more physical measurements of: gate fidelity, native gate availability, qubit count, link count, link topology, readout fidelity, qubit coherence time and qubit relaxation time.

10. The method of claim 2, wherein the fourth database includes one or more of data characterizing system-wide strain and historical usage patterns.

11. The method of claim 1, wherein the third database includes one or more of an expected duration of use of one of the connected sets of qubits and a requested calendar time for running the program.

12. The method of claims 1 or 2, wherein one or more of the first, second, third and fourth databases are remote databases accessible via network communication.

13. The method of claim 1 or 2, wherein one or more of the first, second, third and fourth databases are accessible from remote agents via network communication.

14. The method of claim 1 or 2, wherein one or more of the first, second, third and fourth databases are local caches.

15. The method of claim 1 or 2, wherein two or more of the first, second, third and fourth databases are combined.

16. A computer system for calculating a price for use of a configuration of qubits and qubit-qubit links on one or more quantum processor units by a user for running a program, comprising: a first database for storing design characteristics of the one or more quantum processor units, including inferred characteristics pertaining to the expressiveness of the device, wherein the inferred characteristics include instruction availability;

a second database for storing measurements of physical characteristics of the one or more quantum processor units;

a third database for storing characteristics of a specific user’s request; and a computer processor unit for determining the price, wherein the computer processor unit is linked to the first, second and third databases for accessing input data for the determining.

17. The computer system of claim 16, further comprising a fourth database for storing data characterizing a multiplicity of user requests, including user requests by different users, and wherein the computer processor unit is linked to the first, second, third and fourth databases for accessing input data for the determining.

18. The computer system of claim 16, wherein the computer processor unit is configured to calculate a price based at least in part on the physical characteristics of the one or more quantum processor units.

19. The computer system of claim 16, wherein the computer processor unit is configured to determine a price based at least in part on user demand for use of the one or more quantum processor units.

20. The computer system of claim 16, wherein the price is determined through a pricing auction comprising one or more rounds.

21. The computer system of claim 16, wherein the computer processor unit is configured to determine a price based at least in part on the popularity of the specific configuration of qubits and qubit-qubit links being requested by the user.

22. The computer system of claim 16, wherein a user requests to run the program within a specified time frame, and wherein the computer processor unit is configured to determine a price based at least in part on the specified time frame.

23. The computer system of claim 16, wherein the first database includes information on qubit count and qubit connectivity.

24. The computer system of claim 16, wherein the second database includes one or more physical measurements of: gate fidelity, native gate availability, qubit count, link count, link topology, readout fidelity, qubit coherence time and qubit relaxation time.

25. The computer system of claim 17, wherein the fourth database includes one or more of data characterizing system-wide strain and historical usage patterns.

26. The computer system of claim 16, wherein the third database includes one or more of an expected duration of use of one of the connected sets of qubits and a requested calendar time for running the program.

27. The computer system of claims 16 or 17, wherein one or more of the first, second, third and fourth databases are remote databases accessible via network communication.

28. The computer system of claim 16 or 17, wherein one or more of the first, second, third and fourth databases are accessible from remote agents via network communication.

29. The computer system of claim 16 or 17, wherein one or more of the first, second, third and fourth databases are local caches.

30. The computer system of claim 16 or 17, wherein two or more of the first, second, third and fourth databases are combined.

31. A method of auctioning quantum computing resources, comprising: opening an auction and receiving price bids electronically submitted by users, each price bid having an order with a user desired qubit configuration, each order including a number of qubits, a configuration of qubit connectivities, a lower bound on qubit quality and one or more of a duration, a particular segment of time and a minimum duration; rejecting a specific price bid of the price bids unless the specific price bid satisfies a criteria, the criteria including one or more of: a minimum number of qubits and qubit-qubit links on one or more quantum processor units, a start time of at least a fixed time in the future, and a maximum duration; on satisfaction of one or more specific criteria, closing the auction to any new price bids; activating an order filling process, the order filling process including calculating a plurality of solutions for filling non-conflicting orders, and selecting one of the plurality of solutions according to a metric; and informing users of a status of their price bids.

32. The method of claim 31, further comprising running the selected one of the plurality of solutions on the quantum computing resources.

33. The method of claim 31, wherein each order may further include at least one of a particular subset of qubits and a particular spatial arrangement of the qubits.

34. The method of claim 31, further comprising repeating the receiving, rejecting, closing, activating and informing.

35. The method of claim 31, wherein the metric is the nth most revenue-maximizing possibility, where n is greater than 1.

36. The method of claim 31, wherein the lower bound on qubit quality is a minimum qubit readout fidelity.

37. The method of claim 31, wherein the price bids are stored in an order database.

38. The method of claim 37, further comprising, after the informing users, clearing the order database.

39. A method of matching quantum computing programs to particular subsets of qubits on one or more quantum processor units, comprising: receiving a quantum computing program by an anonymizer unit, the anonymizer unit processing the quantum computing program to remove distinguishing characteristics to provide an anonymized quantum computing program; extracting by an adviser unit of a basic structure of the anonymized quantum computing program, the basic structure including qubit count, qubit connectivity and minimum relaxation or coherence times for qubits; comparing by the adviser unit the basic structure of the anonymized quantum computing program with structures of a plurality of quantum execution targets on the one or more quantum processor units, wherein the plurality of quantum execution targets are subsets of qubits and qubit-qubit links on one or more quantum processor units, and determining appropriate quantum execution targets using a heuristic, the heuristic including one or more of: matching native gate sets, matching plaquette and desired topologies, meeting gate activation fidelity requirements, meeting read-out fidelity requirements, and meeting coherence time or relaxation time requirements; and

generating by the adviser unit of output identifying recommended quantum execution targets for the quantum computing program.

40. The method of claim 39, wherein the distinguishing characteristics include one or more of: gate parameters, gate names, ordering of gates, control structures, and

instructions.

41. The method of claim 39, wherein the removing includes permuting gates.

42. The method of claim 39, wherein the removing includes removing control structures while retaining expected execution count for each instruction.

43. The method of claim 39, wherein the removing includes removing all instructions and retaining only an expected gate set.

44. The method of claim 39, wherein the comparing includes utilizing details of quantum execution targets available on the one or more quantum processor units.

45. The method of claim 44, further comprising filtering quantum execution targets before the importing, the filtering being by exact qubit count, qubit connectivity and minimum T1 and T2 values for qubits.

46. The method of claim 44, wherein the details of quantum execution targets are imported from a remote server.

47. The method of claim 39, wherein the quantum computing program includes several quantum computing programs.

48. The method of claim 39, wherein the basic structure further includes qubit use statistics during running of the quantum computing program, and wherein the comparing includes identification of quantum execution targets for which qubits with highest fidelity coincide with most frequently used qubits in the quantum computing program.

49. The method of claim 44, wherein an adviser service retrieves a list of available plaquettes and their operating characteristics from one or more data server.

50. A computer system for matching quantum computing programs to particular subsets of qubits on one or more quantum processor units, comprising: an anonymizer unit for: receiving a quantum computing program by the anonymizer unit, the anonymizer unit processing the quantum computing program to remove distinguishing characteristics of a quantum computing program for anonymizing the quantum computing program; and an adviser for: extracting a basic structure of the anonymized quantum computing program, the basic structure including one or more of qubit count, qubit connectivity, native gate sets, fidelity-type measurements of native gates, readout fidelity, execution fidelity, relaxation or coherence time measurements, randomized benchmarking results, run quality of certain standard programs, historical quantum processor unit performance drifts, and coherent and incoherent noise channel measurements; comparing the basic structure of the anonymized quantum computing program with structures of a plurality of quantum execution targets, wherein the quantum execution targets are subsets of qubits and qubit-qubit links on one or more quantum computational devices, and determining appropriate quantum execution targets using a heuristic, the heuristic including one or more of: matching native gate sets, matching plaquette and desired topologies, meeting fidelity requirements, and meeting coherence time or relaxation time requirements; and generating output identifying recommended quantum execution targets for the quantum computing program.

51. The computer system of claim 50, wherein the anonymizer is installed on a user’s computer.

52. The computer system of claim 50, wherein the adviser is installed on a user’s computer.

53. A method of plaquette fusion, wherein a plaquette is a configuration of qubits and qubit-qubit links on one or more quantum processor units, comprising: receiving by a computer processor unit a plurality of plaquette requests; sorting by the computer processor unit the plaquette requests by plaquette qubit count; fusing by the computer processor unit the plaquette requests with plaquette qubit count below a predetermined integer value, X, into one or more fused plaquette requests; and submitting a request list to an allocation process, wherein the request list includes the one or more fused plaquette requests and unfused plaquette requests.

54. The method of claim 53, wherein the sorting is by plaquette qubit count in combination with one or more of a priority of the plaquette request and a cost of the plaquette request, wherein the priority of the plaquette request includes an assessment of the relative proximity in time to the time of sorting of requested running of a program by a customer relative to all sorted requests.

55. The method of claim 53, wherein the fusing includes fusing the smallest plaquette requests until all unfused plaquette requests and fused plaquette requests have a qubit count of X or more.

56. The method of claim 53, wherein X is determined from a statistical analysis of a distribution of qubit count values for the plurality of plaquette requests.

57. The method of claim 53, wherein X is a predefined number.

58. The method of claim 53, wherein X is calculated using the qubit count of a quantum processor on which the requests are under consideration to be run.

59. A method of plaquette allocation, wherein a plaquette is a configuration of qubits and qubit-qubit links on one or more quantum processor units, comprising:

receiving by a computer processor unit a plurality of plaquette requests; sorting by the computer processor unit requests by one or more of highest priority, highest revenue per qubit, and highest number of qubits; initializing by the computer processor unit an empty quantum processor unit (QPU) allocation; adding by the computer processor unit the highest priority plaquette request to the allocation; and determining by the computer processor unit if there are any unassigned qubits in the allocation and (a) if there are no unassigned qubits then submit the QPU allocation for the next available epoch, (b) if there are unassigned qubits then further determine if there are any unassigned requests that fit onto the unassigned qubits and (i) if no unassigned requests fit then submit the QPU allocation for the next available epoch, (ii) if unassigned requests fit then add highest priority remaining request to the allocation and repeat the determining.

60. The method of claim 61, further comprising: initializing by the computer processor unit a new empty QPU allocation; adding by the computer processor unit the highest priority unassigned plaquette request to the new allocation; and determining by the computer processor unit if there are any unassigned qubits in the new allocation and (a) if there are no unassigned qubits then submit the new QPU allocation for the next available epoch, (b) if there are unassigned qubits then further determine if there are any unassigned requests that fit onto the unassigned qubits and (i) if no unassigned requests fit then submit the new QPU allocation for the next available epoch, (ii) if unassigned requests fit then add highest priority remaining request to the new allocation and repeat the determining.

61. The method of claim 60, further comprising repeating initializing, adding and determining until all of the plaquette requests of the plurality of plaquette requests are assigned.