QuBind: A Multi-Metric Approach for Optimal and Dynamic QPU Selection

MASTER’S THESIS QuBind: A Multi-Metric Approach for Optimal and Dynamic QPU Selection Conducted by Adrián Romero Flores For the attainment of the Master’s degree in Ingeniería del Software - Cloud, Datos y Gestión TI Supervised by Alfonso Eduardo Márquez Chamorro Antonio Ruiz Cortés June Call, Academic Year 2024/25 Acknowledgements To my parents, whose unwavering support, encouragement, and sacrifices have been fundamental throughout my life. To my girlfriend, Manuela, for her love, support, help, and understanding throughout this entire process. For listening to me and putting up with me, even without having the slightest idea of what I was doing, and for encouraging me every day to keep moving forward. Thanks to my supervisors, Alfonso and Antonio for their invaluable guidance, mentorship, and support in my firsts steps as a researcher. To my colleagues, specially Álvaro and Antonio, whose support, advices and presence day after day has been make this process more bearable. This work has been funded by the Consejería de Transformación Económica, Industria, Conocimiento y Universidades, de la Junta de Andalucía, within the framework of the project “Smart Computer systems Research and Engineering (SCORE)” part of the Programa de Fortalecimiento de Institutos Universitarios de Investigación de la Universidades Andaluzas, Centros e Infraestructuras aimed at obtaining the “Severo Ochoa” or “María de Maeztu” excellence accreditation. i Abstract The emergence of Quantum Software Engineering (QSE) has introduced new challenges in the development and orchestration of hybrid applications that combine classical and quantum services. These applications are typically delivered through a Hybrid Software-as-a-Service (HSaaS) model, which integrates both computing paradigms within an unified cloud-based platform. One of the core problems in this domain is the orchestration of quantum services, particularly the selection of quantum processing units (QPUs) across one or multiple providers. Existing orchestration solutions rely on simplistic decision models based on a single metric. This reductionist approach fails to accommodate trade-offs between fidelity, cost, and execution time, which are often mutually conflicting. Furthermore, these models often overlook workload-specific requirements, such as user-defined priorities. This master’s thesis addresses this problem through the development of QuBind, a novel multi-metric QPU selection framework based on a matcher and optimizer pattern. The matcher filters candidate QPUs according to declarative feasibility constraints, while the optimizer ranks the feasible options based on configurable Figures of Merit. QuBind supports dynamic optimization across several performance and operational metrics, enabling context-aware decisions. It also subsumes existing approaches in the literature by reinterpreting and generalizing their orchestration strategies within our optimization framework. Keywords: Quantum Computing, Quantum Software Engineering, Orchestration, QPU Selection ii Resumen El surgimiento de la Ingeniería de Software Cuántico (QSE, por sus siglas en inglés) ha introducido nuevos desafíos en el desarrollo y la orquestación de aplicaciones híbridas que combinan servicios clásicos y cuánticos. Estas aplicaciones suelen implementarse a través de un modelo llamado Hybrid Software-as-a-Service (HSaaS), que integra ambos paradigmas computacionales dentro de un único servicio en la nube. Uno de los principales problemas en este dominio es la orquestación de servicios cuánticos, en particular la selección de unidades de procesamiento cuántico (QPUs, por sus siglas en inglés) entre uno o múltiples proveedores. Las actuales soluciones de orquestación se basan en modelos de decisión simples, que solo tienen en cuenta una única métrica. Este enfoque reduccionista no permite gestionar adecuadamente los compromisos entre fidelidad, coste y tiempo de ejecución, los cuales suelen estar en conflicto. Además, dichos modelos ignoran requisitos específicos de ejecución, como las prioridades que pueda tener el usuario. Este trabajo de fin de master aborda dicho problema mediante el desarrollo de QuBind, un framework de selección de QPUs teniendo en cuenta múltiples métricas, usando un patrón de matcher y optimizador. QuBind permite la optimización dinámica sobre múltiples métricas de rendimiento y operación, facilitando decisiones sensibles al contexto. Asimismo, engloba y generaliza enfoques existentes en la literatura, reinterpretando sus estrategias de orquestación dentro de nuestro marco de optimización. Palabras clave: Computación Cuántica, Ingeniería del Software Cuántico, Orquestación, Selección de QPU iii Contents 1 Introduction 1 1.1 Context ................................... 1 1.2 Motivation.................................. 2 1.3 Objectives.................................. 3 1.4 Contributions................................ 3 1.5 Structure of this Document . . . . . . . . . . . . . . . . . . . . . . . . 4 2 Methodology, Planning and Budget 5 2.1 Methodology ................................ 5 2.2 Planning................................... 6 2.3 Budget.................................... 6 2.3.1 TemporaryBudget ......................... 6 2.3.2 MonetaryBudget.......................... 8 3 Background 10 3.1 QuantumComputing............................ 10 3.1.1 What is Quantum Computing? . . . . . . . . . . . . . . . . . . 10 3.1.2 Why Quantum Computing? . . . . . . . . . . . . . . . . . . . . 14 3.1.3 How Does Quantum Computing Work? . . . . . . . . . . . . . . 15 3.1.4 Current Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.2 QuantumServices ............................. 20 3.3 Summary .................................. 25 4 State of the Art 26 4.1 RelatedWork ................................ 26 4.1.1 Methodology ............................ 26 4.1.2 LiteratureReview.......................... 27 4.2 What is Quantum Orchestration? . . . . . . . . . . . . . . . . . . . . . 28 4.3 Architecture of a Quantum Orchestrator . . . . . . . . . . . . . . . . . 28 4.4 Conclusions................................. 29 5 Proposal 31 5.1 QuBind ................................... 31 5.2 Optimization Model for Quantum Device Selection . . . . . . . . . . . 32 5.2.1 FiguresofMerit........................... 32 5.2.2 Problem Definition . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.3 QuBindRAPI ................................ 33 5.3.1 APIArchitecture .......................... 34 5.3.2 MockingQPUs ........................... 35 5.3.3 Constraint Definition . . . . . . . . . . . . . . . . . . . . . . . . 35 5.3.4 Binding Endpoint Specification . . . . . . . . . . . . . . . . . . 36 6 Validation of the problem definition 38 iv 6.1 NISQAnalyzer ............................... 38 6.2 Q-Orchestrator ............................... 39 6.3 MQTPredictor ............................... 40 6.4 Current QubindR API Implementation . . . . . . . . . . . . . . . . . . 41 6.5 Conclusions................................. 43 7 Use Cases of the QuBindR API 44 7.1 NISQAnalyzer ............................... 45 7.2 Q-Orchestrator ............................... 46 7.3 MQTPredictor ............................... 48 7.4 BalancedMode............................... 49 7.5 Conclusions................................. 50 8 Conclusions 51 A Qrchestrator 52 B QPU Mocks 57 B.1 Mock QPU Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . 57 B.1.1 PremiumQuantum......................... 57 B.1.2 StandardQuantum......................... 58 B.1.3 BudgetQuantum.......................... 58 B.1.4 Capacity Quantum (IBM) . . . . . . . . . . . . . . . . . . . . . 59 B.1.5 Available Quantum (AWS) . . . . . . . . . . . . . . . . . . . . . 59 B.1.6 Inactive Quantum (AWS) . . . . . . . . . . . . . . . . . . . . . 60 C Code Availability 62 D Bibliography 63 v List of Figures 1.1 Example scenario of a HSaaS. . . . . . . . . . . . . . . . . . . . . . . . 1 2.1 Temporal distribution of the estimated effort for the Master’s thesis project across work areas. . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1 Double-slit experiment with projectiles. . . . . . . . . . . . . . . . . . . 11 3.2 Double-slit experiment with waves. . . . . . . . . . . . . . . . . . . . . 12 3.3 Double-slit experiment with electrons. . . . . . . . . . . . . . . . . . . 12 3.4 Double-slit experiment with electrons and light indicator. . . . . . . . . 13 3.5 Relationship among the complexity classes PSPACE, NP, P, and BQP. . . 15 3.6 Representation of a qubit using the Bloch sphere . . . . . . . . . . . . . 16 3.7 Truth table of the CCNOT gate and its notation. . . . . . . . . . . . . . 19 3.8 Example quantum circuit. . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.9 Overview of QPU availability and performance metrics on the IBM Quantumplatform................................. 21 3.10 IBM Quantum interface showing the status and technical details of an individual quantum device. . . . . . . . . . . . . . . . . . . . . . . . . 21 3.11 Example of rate-limiting policy in the IBM Quantum API. . . . . . . . . 22 3.12 IBM Quantum pricing model based on QPU runtime. . . . . . . . . . . 24 3.13 AWS Braket pricing model based on circuit executions and gate operations...................................... 24 3.14 Azure Quantum pricing model based on circuit characteristics and shots. 25 4.1 Process followed to identify the related work. . . . . . . . . . . . . . . 26 4.2 Architecture of a quantum orchestrator. . . . . . . . . . . . . . . . . . . 29 4.3 Quantum orchestration typical execution process. . . . . . . . . . . . . 29 5.1 High-level architecture of the QuBind framework integrated within a quantumorchestrator. ........................... 32 5.2 OpenAPI specification for the QuBindR RESTful interface, as rendered inSwaggerUI. ............................... 34 5.3 Example constraint for the depth(C, qi)≤maxDepth(qi)condition . . 36 5.4 Example binding request payload demonstrating constraints and optimizationweights .............................. 37 5.5 Example binding response with selected QPU and its figure of merit score 37 7.1 Quantum Fourier Transform for 4 qubits circuit . . . . . . . . . . . . . 44 7.2 Example JSON payload for the NISQ Analyzer use case submitted to the /bind endpoint............................. 45 7.3 JSON response from the /bind endpoint illustrating the selected QPU, including hardware specifications, gate and readout fidelities, and a ranked list of suitable QPUs for the NISQ Analyzer use case. . . . . . . 46 7.4 Example JSON payload for the Q-Orchestrator use case submitted to the /bind endpoint............................. 47 vi 7.5 JSON response from the /bind endpoint showing the selected QPU for the Q-Orchestrator use case based on minimal workload. . . . . . . . . 47 7.6 Example JSON payload for the MQT Predictor use case submitted to the /bind endpoint............................. 48 7.7 JSON response from the /bind endpoint showing the selected QPU for the MQT Predictor use case based on maximum fidelity. . . . . . . . . . 48 7.8 Example JSON payload for the balanced use case submitted to the /bind endpoint............................... 49 7.9 JSON response from the /bind endpoint showing the selected QPU for the balanced use case based on costs, fidelity and workload. . . . . . . 49 vii 1. Introduction 1.1. Context Quantum Software Engineering (QSE) is still a young discipline in which significant research efforts are needed to address the current challenges of the area [17]. Quantum applications are inherently hybrid, meaning they comprise both quantum and classical programs [28]. Instinctively, these applications are naturally suited to deployment via cloud-based platforms, typically offered through a subscription-based Software-as-a-Service (SaaS) model. This paradigm gives rise to the concept of Hybrid Software-as-a-Service (HSaaS), which refers to the integration of quantum and classical services into a unified solution that end users experience as a single, cohesive service [23]. In this context, the ATHENA is a research project proposed to the Plan Nacional de Investigación Científica, Técnica y de Innovación, funded by the Agencia Estatal de Investigación (AEI), and collaboratively developed by multiple spanish universities. It aims to address the challenges of hybrid service composition in cloud-based quantumclassical environments. This thesis is framed within the scope of ATHENA and contributes specifically to the orchestration of quantum services. Figure 1.1: Example scenario of a HSaaS. Source: [23] 1 2.3.2 Monetary Budget Building upon the temporary budget outlined in the previous section, this section presents a monetary budget estimating the financial cost of developing the project within a professional environment. Generally, three primary types of costs have been considered for this project: personnel costs, equipment depreciation, and fixed costs. Personnel costs account for the labour involved in the research, development, and documentation. Equipment depreciation reflects the wear and usage of hardware resources over the duration of the project. Fixed costs include recurring expenses such as software subscriptions and other necessary services to support the project. Personnel costs To estimate the personnel costs associated with the professional development of this project, we considered standard roles and corresponding remuneration typical in the information technology and research sectors. The base salary values are derived from the Informe Final sobre la Consulta Preliminar del Mercado: Perfiles Profesionales Ámbito Informático, published by the Junta de Andalucía [8]. In addition to the base salary, a 31.10% overhead is applied to account for employer-paid social security contributions. This percentage is based on current rates provided by the Spanish Social Security [25], broken down as follows: •Common contingencies: 23.60% •Additional rate for fixed-term contracts: 6.70% •FOGASA: 0.20% •Vocational training: 0.60% Table 2.3 presents a detailed breakdown of the estimated personnel costs, incorporating both the base hourly rate and the associated social costs. The distribution of hours is derived from the temporal effort allocation shown in Table 2.2. Role Base Salary per Hour (€) Social Costs (31.10%) (€) Hours Total per Role (€) Project Manager 50.48 15.70 20 1,323.60 Project Leader 48.75 15.16 20 1,273.20 Analyst 39.98 12.43 120 6,289.20 Programmer 27.10 8.43 20 710.60 Documental Consultant 40.28 12.53 140 7,393.40 Total 16,990.00 € Table 2.3: Breakdown of personnel costs by role, including base salary, social security contributions, and allocated hours. Following this estimation, Table 2.4 outlines the correspondence between each role and the main work areas as defined in the temporary budget. 8 Role Associated Work Areas Assigned To Project Manager Meetings Supervisors Project Leader Planning, Meetings Student Analyst Literature Review, Orchestrator Analysis & Extension, Model Development & Validation Student Programmer API Design Student Documental Consultant SISTEDES Paper, Thesis Writing, Presentation Student Table 2.4: Assignment of professional roles to project tasks. Equipment depreciation The primary equipment used for this project is a MacBook Pro M3 laptop with 18GB shared memory and a 512GB SSD, purchased at a cost of €2,371.10. Depreciation is calculated over an expected useful life of 5 years (60 months). Considering the project duration of approximately 4 months, the proportional depreciation cost allocated to this project is calculated as follows: Depreciation cost =2,371.10 60 ×4 = 158.07 €(2.1) Fixed costs These include subscriptions, utilities, and other necessary services that support the research and development environment. Specifically: Concept Monthly Cost (€) Months Total per Service (€) Overleaf Premium 12.00 4 48.00 Internet Connection 30.00 4 120.00 Electricity Bill 20.00 4 80.00 Total 248.00 € Table 2.5: Estimated fixed costs over the project’s four-month duration. Final Budget Table 2.6 summarises the total estimated cost of the project, aggregating the three main categories previously detailed: Cost Category Amount (€) Personnel Costs 16,990.00 Equipment Depreciation 158.07 Fixed Costs 248.00 Total 17,396.07 € Table 2.6: Summary of the final estimated budget for the project. 9 3. Background 3.1. Quantum Computing To explore the foundational concepts of quantum computing, we begin by addressing three fundamental questions often posed when approaching a new discipline: What is it? Why is it relevant? And how does it work? 3.1.1 What is Quantum Computing? Quantum computing is the field of study concerning information processing tasks that are carried out utilizing quantum mechanics [18]. Quantum mechanics defines the set of physical properties that nature exhibits on the atomic and subatomic scales. Quantum computing exploits fundamental aspects of quantum mechanics such as superposition, entanglement, and the phenomenon of wave function collapse during measurement 1. The Principle of Superposition The double-slit experiment stands as a canonical example in quantum mechanics, offering a clear illustration of the principle of quantum superposition. Accordingly, rather than approaching this quantum principle abstractly, we will focus on describing this experiment. The key components required for this experiment include: a source emitting particles or waves, a double-slit apparatus, and a detection screen on which interference fringes can be observed [5]. In order to understand the behavior of a subatomic particle, such as the electron, we will first examine the behavior of classical projectiles and waves [13]. Let us consider a source that emits projectile-like bullets. This source irregularly fires indestructible projectiles on a relatively wide angular spread [13]. In front of our source, we have a wall with two slits, each wide enough to allow one of these projectiles to pass through. Behind this wall, there is another wall that will absorb these masses [13]. On the back wall, we have a detector. When a projectile comes into contact with it, the projectile stops and is accumulated. This detector can be moved back and forth in the x-coordinate. This experimental setup is visually detailed in (a) of Figure 3.1. The question we are asking is: what is the probability that one of these projectiles, after passing through the slits, will collide with the back wall at a distance x from the center? [13] That is the function of the detector: to determine this probability as a function of x. 1This section is based on original elaboration inspired by the explanations of Richard Feynman, especially those presented in the Feynman Lectures on Physics and supplementary video materials available at https://www.feynmanlectures.caltech.edu/. 10 Figure 3.1: Double-slit experiment with projectiles. Source: [13] The response to this question lies within the region (c) of Figure 3.1, where the prominent maximum at x= 0 warrants our attention. Upon examination of (b) in the aforementioned Figure 3.1, one can discern the probability density functions P1and P2, representing the probabilities Pnwhen the aperture nis unobstructed only. These functions exhibit their maximums at the xcoordinate corresponding to the center of the respective aperture n. Consequently, the probability distribution when both apertures are open is given by: P12 =P1+P2(3.1) We shall refer to this result as an observation of non-interference, for reasons that will become clear shortly[13]. Now, let us now consider the fact that the source emits waves on a water surface. We continue with a setup similar to that of the previous experiment, except that the detector now measures the intensity of the wave motion [13]. Now, observing the wave intensity as a function of x, as shown in panel (c) of Figure 3.2, we no longer obtain, as before, the simple sum of the two functions In, measured when only slit nis open. Here, the effect of interference becomes evident. When a maximum peak is observed, constructive interference is occurring, as both waves are in phase. Conversely, when a minimum is observed, destructive interference occurs, since the waves are out of phase or have opposite phases. As a definition, the intensity of a wave is proportional to the square of its amplitude[13], therefore: I1=|h1|2, I2=|h2|2(3.2) If both slits are open, the intensity is proportional to the sum of the amplitudes of the two waves, leading to the following equation: I12 =|h1+h2|2(3.3) 11 Figure 3.2: Double-slit experiment with waves. Source: [13] Finally, let us consider one last experiment involving subatomic particles, specifically electrons. It utilizes a setup similar to the first one: a source emitting electrons, our slits, a wall where the electrons will collide, and a detector that registers when an electron collides, as we understand that they behave like material projectiles. Posing the same question as when using projectiles, the result obtained is the one shown in panel (c) of Figure 3.3. Figure 3.3: Double-slit experiment with electrons. Source: [13] We assume that the electrons pass through one of the two slits, just like the projectiles, and we can make them pass through a single slit. Thus, we can obtain P1 and P2, which are the results shown in panel (b) of Figure 3.3, and are similar to those observed in panel (b) of Figure 3.1. Upon allowing the electrons to pass through both slits, we conclude, based on the results shown in panel (c) of Figure 3.3, that: 12 P12 =P1+P2(3.4) Instead, P12 is similar to the curve I12 obtained in the experiment with the waves. Mathematically, it was easy to describe P1and P2as the squared absolute values of two complex numbers, functions of x, denoted ϕ1and ϕ2.[13]: P1=|ϕ1|2, P2=|ϕ2|2(3.5) The effect with both slits open was, indeed: P12 =|ϕ1+ϕ2|2(3.6) It was this experiment that truly concluded that the electron sometimes behaves as a particle and other times as a wave’[13]. Thus, it possesses the properties of two completely distinct states simultaneously. This is what is known as quantum superposition. Wave Function Collapse Let us return to the double-slit experiment and explain this phenomenon based on the experiment itself, rather than in an abstract and theoretical manner. In our final experiment, we will add a light source, which will indicate whether the electron has passed through slit number one or slit number two [13], as can be seen in the area marked with an ‘A’ in Figure 3.4. Figure 3.4: Double-slit experiment with electrons and light indicator. Source: [13] Let us repeat the experiment, this time with the detector that counts the collisions with the electrons, also detecting through which slit the electron passed. For each of the slits, we will have a probability P′n, which will tell us that the detected electron passed through the slit n. We calculate these probabilities as a function of x, as in previous experiments [13], we obtain the functions shown in panel (b) of Figure 13 3.4. If we sum both probabilities, we would obtain the probability that an electron collides after passing through either slit [13]: P′12 =P′1+P′2(3.7) Thus, we no longer obtain the previous curve P12 that the experiment presented earlier. What is happening is that we are forcing the electron to collapse into one of the possible states when measuring which slit it passes through, in this case the particle state, resulting in the pattern observed in the first experiment. This phenomenon is known as wave function collapse. Quantum Entanglement To explain this property, we will use Bell’s theorem. Originally, this theorem was proposed by Einstein as a paradox challenging the validity of quantum mechanics [11]. Bell considered a source that emits two particles travelling in opposite directions, each with opposite spin (angular momentum). Specifically, if particle number 1 has a positive spin, particle number 2 will have a negative spin, or vice versa [5]. The intriguing aspect of this scenario is that, up until the moment of measurement, the spin of the particles is indeterminate. However, once we measure one of them, we immediately know the state of the other without having to measure it directly. In quantum terms, when we collapse the state of one particle, the state of the other is also determined, without disturbing its superposition. This is possible because the particles are entangled. 3.1.2 Why Quantum Computing? Indeed, we ask ourselves: What barriers have we overcome with quantum computing? To answer this, we will analyse the computational power that these systems possess. All of this stems from the theory of computational complexity, whose basic idea is to divide computational problems into classes of complexity [18]. The two key types are P and NP problems. P or PTIME problems are those that can be solved quickly on a classical computer. On the other hand, NP or NPTIME problems are those for which solutions can be verified quickly on a classical computer [18]. It is intuitive to say that P is a subset of NP, as the ability to solve a problem implies the ability to validate its solution. What remains unresolved today is whether these two classes are different or not, that is [18]: P=NP ?or P=NP ?(3.8) We say that there are certain problems within NP but not in P, which are referred to as NP-complete problems. Currently, there are hundreds of problems in this class, which are as complex as NP problems and whose solutions (algorithms) can be adapted to any other NP problem. Furthermore, every NP-complete problem does not have an efficient solution on a classical computer [18]. 14 Considering quantum computing, it is believed that quantum computers can help solve NP problems by taking advantage of quantum parallelism [18]. If we consider PSPACE as a complexity class that includes both P and NP, we can define Bounded-error Quantum Polynomial time (BQP) as the class of problems that can be efficiently solved on a quantum computer. Moreover, for every problem in BQP, there exists a quantum solution with a certain allowed probability of error [18]. Now, where do we place BQP? Numerous researchers argue that it lies between P and PSPACE. A clearer representation of these sets can be seen in Figure 3.5. Figure 3.5: Relationship among the complexity classes PSPACE, NP, P, and BQP. Source: [18] Therefore, in response to the question posed at the beginning of this section, the only thing we truly know is that, as of today, quantum computers surpass classical ones only in certain specific problems. 3.1.3 How Does Quantum Computing Work? In this section, we will discuss the fundamental concepts of quantum computing, including the qubit, qubit registers, quantum logic gates, and quantum circuits. It is important to note that we are referring specifically to the circuit model of quantum computing. The qubit The bit is the fundamental unit of information and classical computation. In quantum computing, we have its analogue: the quantum bit, or qubit. We know that classical bits can exist in one of two states, 0 or 1. Qubits can also exist in these states, denoted |0⟩and |1⟩. The symbol |⟩ corresponds to Dirac notation, which is used to represent states in quantum mechanics. A qubit, however, can exist in a state that is a linear combination of these two basis states. This phenomenon is known as superposition [18]: 15 Figure 3.6: Representation of a qubit using the Bloch sphere Source: [18] |ψ⟩=α|0⟩+β|1⟩,where α, β ∈C(3.9) When we collapse the superposition state by measuring the qubit, we obtain the value 0 with probability |α|2, or the value 1 with probability |β|2. Consequently, the sum of these probabilities must equal 1. Alternatively, the state of the qubit can be interpreted as a vector in a two-dimensional complex vector space. This vector must be normalized to have unit length [18], so that: |α|2+|β|2= 1 (3.10) We can rewrite Equation 3.9 as: ψ⟩= cos θ 2|0⟩+eiφ sin θ 2|1⟩,where θ, φ ∈R(3.11) Using the variables θand φ, we can define a point on a three-dimensional unit sphere, as shown in Figure 3.6, called the Bloch sphere [18]. This representation is quite useful for understanding and visualizing the state of a qubit. Multiple qubits Now, let’s consider the case where we have two qubits. These can have the following possible states: |00⟩,|01⟩,|10⟩, and |11⟩. Each pair of qubits can exist in a superposition state of these basis states, and therefore, we must associate a complex coefficient to each of these states, which we refer to as amplitudes [18]. In this case, we can define the state of the two-qubit register as: |ψ⟩+α00|00⟩+α01|01⟩+α10|10⟩+α11|11⟩(3.12) 16 As in the case of a single qubit, the sum of the squares of the absolute values of these amplitudes must equal 1, mathematically: X x∈{0,1}2|αx|2= 1 (3.13) To illustrate the dimensionality of the amount of data stored in a register of multiple qubits, consider a system of 500 qubits, |x1x2...x500⟩, its state is described by 2500 amplitudes. The total number of amplitudes is overwhelmingly greater than the number of atoms in the Universe (estimated to be 1080). Quantum Gates Just like classical computers with bits and logic gates, quantum computers can manipulate the state of one or more qubits using quantum gates. These gates can be expressed as products of unitary matrices, so: |ψ′⟩ =U|ψ⟩(3.14) Let Ube a unitary matrix that describes a quantum gate operation, U†the adjoint (conjugate transpose) matrix of U, and Ithe identity matrix, which satisfy: U†U=I(3.15) Next, we will describe the most common quantum gates: •1-Qubit Gates: –Pauli-X: This gate functions similarly to the classical NOT gate. It swaps the coefficients αand βin the quantum state. Its effect is given by the following Equation 3.17. The matrix representation is as follows [18]: X= 0 1 1 0!, X†= 0 1 1 0!(3.16) α|0⟩+β|1⟩xβ|0⟩+α|1⟩(3.17) –Pauli-Z Gate: This gate acts by changing the sign of β, and its effect is described by Equation 3.19. The matrix representation is as follows [18]: Z= 1 0 0−1!, Z†= 1 0 0−1!(3.18) α|0⟩+β|1⟩zα|0⟩−β|1⟩(3.19) 17 Figure 3.12: IBM Quantum pricing model based on QPU runtime. Figure 3.13: AWS Braket pricing model based on circuit executions and gate operations. 24 Figure 3.14: Azure Quantum pricing model based on circuit characteristics and shots. 3.3. Summary This chapter provided the foundational context necessary to understand the current landscape of quantum computing in the NISQ era. It began by introducing the key principles of quantum computation. Subsequently, the chapter explored the quantum services, detailing how cloud-based platforms abstract hardware access and deliver quantum computing capabilities via GUIs, SDKs and APIs. Furthermore, we analysed the pricing models adopted by major quantum service providers. Together, these topics establish a comprehensive background for understanding quantum computing as it exists today. 25 4. State of the Art This chapter surveys the existing body of work related to quantum orchestration. We identify and critically evaluate key contributions in the literature, examining their methodologies, assumptions, and limitations. The analysis serves to contextualize our proposed approach and to highlight the research gap. 4.1. Related Work 4.1.1 Methodology This section outlines the methodology employed in conducting the literature review. Search Strategy: Due to time constraints, the literature review was limited to an automated search within indexed databases. The process consisted of three steps: (1) query-based retrieval of primary studies from selected databases, with initial filtering applied using the databases’ built-in filters; (2) manual screening of the retrieved studies based on predefined inclusion and exclusion criteria; and (3) compilation of the final set of studies that constitute the related work. This strategy is illustrated in Figure 4.1. Figure 4.1: Process followed to identify the related work. Conducting Search: To construct the search query, we aimed to capture studies related to quantum computing with a focus on orchestration and hardware selection. The final query used in Scopus 1was: AUTHKEY((quantum AND computing) AND ((orchestration) OR ((hardware OR nisq OR (quantum AND device)) AND selection))) The AUTHKEY field ensures that only studies where these terms are explicitly emphasized by the authors are included in the results. We conducted the automatic search using the specified query and obtained a total of 8 studies. Subsequently, we 1See: www.scopus.com 26 applied the database automatic filters to restrict the results to the subject area Computer Science and to publications written in English only, obtaining 7 studies. Manual Screening: In this step, we defined and applied a set of inclusion and exclusion criteria to the initial set of studies obtained from the automated search. Inclusion criteria included: (i) publications written in English and peer-reviewed in recognized journals, conferences, or workshops; and (ii) studies whose title and abstract explicitly reference quantum orchestration or load balancing in NISQ devices. Exclusion criteria included: (i) publications focusing on unrelated uses of orchestration despite superficial keyword overlap; and (ii) studies not accessible through institutional subscriptions or open-access repositories. After applying the inclusion and exclusion criteria, we obtained a related work dataset of 6 studies. 4.1.2 Literature Review Based on the inclusion and exclusion criteria established in the methodology, we have identified a set of primary studies was selected for detailed examination. The first approach to quantum service selection was proposed by Salm et al. [24] with the introduction of the NISQ Analyzer. They were the first to define the problem, proposing a solution based on logic programming that selects the most suitable QPU according to criteria such as the number of available qubits and the circuit depth. Later, Wild et al. [29] proposed two deployment modeling styles based on the Topology and Orchestration Specification for Cloud Applications (TOSCA) to automate the deployment and orchestration of quantum tasks. Then, Weder et al. [27] proposed BPMN models to automate quantum tasks, referred to as quantum workflows. Their approach integrates the previously introduced NISQ Analyzer to support the selection of quantum services. Faro et al. [12] developed Middleware for Quantum, which provides an abstraction layer to hide the complexity of quantum hardware. Their work focuses primarily on job monitoring and scheduling, rather than on quantum service selection. Alvarado-Valiente et al. [4] introduced the Quantum Load Balancer, which integrates multiple quantum service providers and incorporates availability and task queue status into the service selection process. Finally, the most recent work by Quetschlich et al. [20] introduces the MQT Predictor, which leverages a dataset comprising quantum circuits and their associated Figures of Merit, a composite metric that encapsulates circuit-specific and quantum service characteristics, such as expected execution fidelity, cost, and queue length. Using this data, the model applies supervised classification techniques to predict the most suitable QPU for a given circuit, thereby optimizing hardware selection. 27 4.2. What is Quantum Orchestration? Quantum orchestration, as defined by Alvarado-Valiente et al. [4], refers to the management and coordination of quantum resources, computational tasks, and execution workflows within a quantum computing environment. Furthermore, a quantum orchestrator should be able to predict, identify, and effectively address the execution of quantum tasks in the different available quantum resources in the runtime of hybrid applications automatically [4]. Effective quantum orchestration is essential for achieving several operational goals, including optimal resource allocation, fault tolerance, workload distribution, and scalability. Given the variability in quantum hardware characteristics, such as qubit count, connectivity, fidelity, and queue availability, an orchestrator must dynamically select and manage the most appropriate quantum backends during program execution. 4.3. Architecture of a Quantum Orchestrator An analysis of the literature reveals the presence of recurring architectural patterns among existing quantum orchestrators, as most approaches converge upon a shared set of foundational components. Figure 4.2 presents a high-level overview of a representative quantum orchestrator architecture. This architecture comprises several distinct components, each responsible for a specific function: •API Interface: Provides the entry point to the orchestrator. Through this interface, users or client applications can submit quantum tasks and retrieve results. •Binding Service: Acts as the core of the orchestrator. It is responsible for receiving the submitted job and selecting the appropriate QPU. •Transpiler Service: This service translates high-level quantum circuits into hardware-compatible representations. •SDKs / APIs Integration: This layer provides a bridge between the orchestrator and the external quantum service providers. It abstracts the idiosyncrasies of each vendor’s API and standardizes job submission, QPU monitoring, and result retrieval. The end-to-end orchestration workflow is illustrated in Figure 4.3. This sequence diagram details the dynamic interactions among components during a typical execution cycle. The process begins with the API interface forwarding a user request to the binding service, which retrieves QPU metadata from the SDK layer. The binding service iteratively queries the transpiler service to generate QPU-specific circuits, then selects the optimal QPU. The transpiled circuit is submitted for execution via the SDK layer, which interfaces with the designated quantum service provider. Finally, the results are propagated back to the user via API. 28 Figure 4.2: Architecture of a quantum orchestrator. API Binding Service Transpiler Service SDKs / APIs Quantum Services Send request Request received Fetch QPU metadata QPU list Get QPU-specific circuit Transpiled circuit looploop Select optimal QPU Submit circuit for execution Submitted Execute circuit Execution complete Return execution results Results received Send results Response delivered Figure 4.3: Quantum orchestration typical execution process. 4.4. Conclusions Answer to RQ1: How have existing quantum orchestration strategies addressed the problem of QPU selection? The analysis conducted in this chapter reveals that existing quantum orchestration strategies address QPU selection through a range of mechanisms, each exhibiting distinct structural and functional limitations. Salm et al. [24] introduced the NISQ Analyzer, a pioneering system that uses logic programming to enforce hard constraints based on static circuit and hardware 29 properties. While foundational, its selection logic is limited to constraint satisfaction. Alvarado-Valiente et al. [4] advanced this concept with their Quantum Load Balancer, which incorporates real-time queue information. This enables runtime adaptability but restricts its decision-making to single-objective optimization over workload. Consequently, it cannot balance trade-offs between multiple quality-of-service indicators. More recently, Quetschlich et al. [20] proposed the MQT Predictor, a supervised learning model that optimizes selection based on a predicted Figure of Merit (FoM). However, because its predictions rely on static data, the model is unable to react to dynamic changes in quantum service conditions. Furthermore, it lacks a mechanism for users to configure the prioritization of different FoMs for use-case-specific tuning. In contrast, our proposed solution addresses these limitations by introducing a constrained multi-metric optimization selection strategy that integrates real-time backend metadata. This approach not only enables runtime adaptability, but also supports prioritization among multiple Figures of Merit, tailored to specific execution requirements. As summarized in Table 4.1, the surveyed approaches differ significantly across the key dimensions of selection logic, configurability and runtime adaptability,. QuBind is the only strategy that provides a comprehensive solution, synthesizing the strengths of prior methods while mitigating their key shortcomings. This establishes a more robust and flexible foundation for state-of-the-art quantum resource binding. Approach Selection Logic Optimization Constraints Multi-Metric Context-Aware Real Time Data [24]Circuit & QPU Constraint Satisfaction ✗ ✓ ✗ ✗ ✓ [4]Available & Shots Constraints with Workload Optimization ✓ ✓ ✗ ✗ ✓ [20]Figure Of Merit Prediction Optimization ✓ ✗ ✗ ✗ ✗ QuBind Constrained Multi-Figure Of Merit Optimization ✓ ✓ ✓ ✓ ✓ Table 4.1: Comparison of the related work with our approach. 30 5. Proposal In this chapter, we propose a paradigm shift in the way quantum device selection is approached within orchestration systems. Traditional quantum orchestrators typically implement monolithic selection logic, where a single module is responsible for filtering, ranking, and assigning QPUs. We argue that this design limits extensibility and adaptability. To address these limitations, we introduce QuBind, a modular and extensible binding framework inspired by analogous service binding strategies in classical serviceoriented computing. We formalize the binding problem under this framework and demonstrate how it generalizes prior approaches from the literature. 5.1. QuBind To improve QPU binding within quantum orchestration, we draw upon principles from classical Service-Oriented Architectures (SOA) and prior research on QoS-Aware Service Composition (QACO). In service oriented systems, complex applications are frequently constructed by composing multiple services, resulting in what is known as a composite web service [7]. The challenge in such compositions lies not only in satisfying the functional requirements but also in ensuring compliance with non-functional constraints, typically expressed in terms of QoS metrics, such as latency, availability, or cost. This gives rise to the QACO problem, wherein the selection of concrete services must satisfy a set of hard feasibility constraints while optimizing for multiple QoS objectives [7]. Analogously, in the quantum context, we propose a modular and extensible framework for QPU selection, referred to as QuBind. This architecture decomposes the quantum device binding process into two distinct and sequential phases: 1. Matching Phase: This phase is responsible for identifying a subset of candidate QPUs that are eligible to execute a given quantum task. It operates under declarative constraints derived from the task requirements and QPU capabilities. Constraints may include qubits constraints, QPU status or noise thresholds. The goal of this phase is to reduce the search space by filtering out infeasible options. 2. Optimization Phase: Given the reduced set of candidates produced by the matcher, this phase applies a decision-making strategy to select the most appropriate QPU based on one or more metrics. The optimization accounts for runtime information such as current queue length, fidelity estimates, and execution costs. The output of this phase is a binding decision that maximizes the expected quality of service under configurable criteria. Figure 5.1 illustrates the integration of QuBind within a quantum orchestrator. The diagram also zooms into the internal logic of QuBind, clearly delineating the 31 matcher and optimizer roles along with their inputs and outputs. Figure 5.1: High-level architecture of the QuBind framework integrated within a quantum orchestrator. 5.2. Optimization Model for Quantum Device Selection To rigorously characterize the quantum device selection problem in quantum orchestration, we introduce a formal optimization model. 5.2.1 Figures of Merit In this context, a Figure of Merit (FoM) serves as a quantitative measure to evaluate the suitability of a specific quantum resource for executing a given quantum circuit [20]. The FoM allows for the comparison and ranking of available quantum resources based on desired criteria. The definition of a FoM is highly flexible and can be customized based on the specific goals of the orchestration task. It can range from simple metrics to complex functions incorporating various factors, including categories like circuit characteristics, device characteristics, operational factors or costs. 32 5.2.2 Problem Definition Let Cbe a quantum circuit intended for execution on one of a set of available quantum resources Q={q1, q2, . . . , qn}. Each resource qi∈ Q is associated with a set of properties A(qi,C), which quantify its suitability to execute the quantum circuit C. These properties can reflect physical capabilities, operational status, current load, or any other relevant metric. Resource selection is restricted to those that satisfy a feasibility condition: Qfeasible ={qi∈ Q | feasible(qi,C) = 1}(5.1) The feasibility predicate is defined as a conjunction of constraint functions: feasible(qi,C) = r ^ j=1 cj(qi,C)where cj(qi,C)∈ {0,1}(5.2) Each cj(qi,C)is boolean valued constraint representing a necessary condition that qimust satisfy in order to be eligible for the execution of C. The orchestration system must select the QPU q∗∈ Q that maximizes a Figure of Merit, FoM(qi,C), which encodes the multi-dimensional evaluation of resource suitability: q∗= arg max qi∈Qfeasible FoM(qi,C)(5.3) Here, the function FoM(qi,C)itself is defined as a weighted sum of multiple underlying metrics or simpler Figures of Merit. This allows the single objective function to encapsulate the desired trade-offs between potentially competing factors like cost, execution fidelity, and response time. The specific definition of FoM determines how these different factors are balanced according to user priorities or application requirements. 5.3. QuBindR API The QuBindR API exposes a programmatic interface that enables external components to interact with the QuBind framework and obtain optimal QPU binding decisions. This API supports the specification of quantum tasks via quantum circuits, declarative feasibility constraints, and user-defined optimization preferences expressed through Figures of Merit. In an ideal scenario, the QuBindR API would support arbitrary Figures of Merit, allowing developers to define metrics beyond a fixed set. The current implementation supports only a core subset of metrics (costs, estimated fidelity, and current workload) due to time constraints. However, the API has been architected to accommodate any number of additional FoMs as long as they are defined in the metadata registry and can be computed at runtime. 33 Thus, the optimal selection becomes: q∗= arg max qi∈Qfeasible 1−workloadnorm(qi)(6.8) 6.3. MQT Predictor The MQT Predictor adopts a supervised machine learning pipeline to identify the most suitable quantum resource for executing a given quantum circuit. The selection is driven by a customizable Figure of Merit, which encapsulates performance objectives such as fidelity, critical depth, or hardware-specific constraints, and is derived from historical execution and compilation data [20]. While the MQT Predictor formally defines a comprehensive set of composite circuit features for use in training its machine learning models, such as program communication, entanglement-ratio, parallelism, and liveness, we abstract over these composite features in this formalization. We infer that these features are primarily employed to enhance the predictive performance rather than constituting functional constraints within the orchestration model itself. Let the quantum circuit Cbe described by the following characteristics: •qubits(C): The required number of logical qubits. •gateCount(C, qi, gj): The number of occurrences of gate type gjin the circuit C after transpilation to the native gate set of quantum resource qi. •qubitsUsed(C): Is the set of qubits used in circuit C. •measurements(C, qbk): The number of measurements in the circuit Cin qubit qbk. A quantum resource qiis characterized by: •qubits(qi): The number of physical qubits. •F(gj, qi): The expected execution fidelity of native gate gjon resource qi. •FRO(qbk, qi): The expected readout fidelity of qubit qbkon resource qi. •G(qi): The set of native gates for resource qi. •available(qi)∈ {0,1}: Binary indicator of operational status. This metric is not detailed in the approach, but, we assume that the model should only select available QPUs. While the core mechanism of the MQT Predictor’s ML model focuses on predicting the best device among those it is trained on, we infer that basic hardware compatibility and availability function as implicit feasibility constraints. feasible(qi,C) = available(qi)∧(qubits(qi)≥qubits(C)) (6.9) This defines the set of feasible resources: Qfeasible =qi∈ Q | feasible(qi,C) = 1 (6.10) 40 The Figure of Merit in this orchestration tool is designed to favour resources with high expected fidelities. This fidelity is modeled as a multiplicative combination of the individual fidelities of all gates and measurements performed in the circuit. It is calculated as: F(qi,C) =   gateCount(C,qi,gj) Y gj∈G(qi)F(gj, qi)   measurements(C,qbk) Y qbk∈qubitsUsed(C)FRO(qbk, qi) (6.11) The Figure of Merit is computed as: FoM(qi,C) = F(qi,C)(6.12) Thus, the optimal selection becomes: q∗= arg max qi∈Qfeasible F(qi,C)(6.13) 6.4. Current QubindR API Implementation Let the quantum circuit Cbe described by the following characteristics: •qubits(C): The required number of logical qubits. •shots(C): The number of shots requested in execution. •depth(C, qi): The depth of the circuit after transpilation to the topology and gate set of quantum resource qi. This is a hardware-specific property and depends on the transpilation process. •gateCount(C, qi, gj): The number of occurrences of gate type gjin the circuit C after transpilation to the native gate set of quantum resource qi. •qubitsUsed(C): Is the set of qubits used in circuit C. •measurements(C, qbk): The number of measurements in the circuit Cin qubit qbk. A quantum resource qiis characterized by: •qubits(qi): The number of physical qubits. •F(gj, qi): The expected execution fidelity of native gate gjon resource qi. •FRO(qbk, qi): The expected readout fidelity of qubit qbkon resource qi. •G(qi): The set of native gates for resource qi. •workload(qi): The number of pending jobs currently in the execution queue •available(qi)∈ {0,1}: Binary indicator of operational status. •cost(qi,C): The financial cost time for executing Cin qi. 41 •maxDepth(qi): The estimated maximum allowable circuit depth on qi, typically derived as: maxDepth(qi) = $Tdecoherence(qi) Tmax gate (qi)% where: –Tdecoherence(qi)is the average decoherence time of physical qubits, –Tmax gate (qi)is the longest duration among supported gate operations. The set of feasible resources is: Qfeasible ={qi∈Q|feasible(qi,C) = 1}(6.14) The feasibility predicate is defined as a conjunction of constraint functions: feasible(qi,C) = r ^ j=1 cj(qi,C)where cj(qi,C)∈ {0,1}(6.15) Each cj(qi,C)represents a user-defined constraint that encapsulates a specific requirement to be satisfied by the resource qiin relation to the execution of C. These constraints can capture a wide range of eligibility criteria, such as QPU status, minimum number of qubits, etc. Predefined constraints are: •available(qi). •qubits(qi)≥qubits(C). We define the FoM as a weighted linear combination of three normalized core metrics: •cost(qi,C). •workload(qi). •fidelity(qi,C)(see Equation 6.11). The Figure of Merit is computed as: FoM(qi,C) = α·1−costnorm(qi,C)+β·fidelity(qi,C) + γ·1−workloadnorm(qi) (6.16) where: •α, β, γ ∈R≥0are user-defined weights that reflect the relative importance of cost, fidelity, and workload. •The weights are normalized such that α+β+γ= 1. Consequently, the optimal selection becomes: q∗= arg max qi∈Qfeasible α·1−costnorm(qi,C)+β·fidelity(qi,C)+γ·1−workloadnorm(qi) (6.17) 42 6.5. Conclusions Answer to RQ2: Can QPU selection be formulated as a general, extensible, and context-aware decision model that captures the needs of diverse orchestration scenarios? The comprehensive analysis and reinterpretation of state-of-the-art orchestration tools demonstrate that each can be effectively represented as a specific instance within the unified Qubind optimization framework. By systematically identifying and formalizing their respective feasibility predicates and Figures of Merit, this work has established a rigorous correspondence between diverse orchestration strategies and the generalized device selection model proposed. Furthermore, the instantiation of the Qubind model in the current QubindR API implementation highlights its practical applicability, supporting multi-factor optimization and constraint satisfaction. In conclusion, this validation confirms that QPU selection can be formulated as a general, extensible, and context-aware decision model, thereby addressing the requirements of a broad spectrum of orchestration scenarios in quantum computing. 43 7. Use Cases of the QuBindR API This chapter presents a series of representative use cases that demonstrate the capabilities and flexibility of the QuBindR API in orchestrating quantum execution workflows. Again, we reinterpret the methodologies of three state-of-the-art approaches previously analysed in Chapter 4,NISQ Analyzer,Q-Orchestrator, and MQT Predictor, using the QuBindR API. Moreover, we introduce a balanced use case that leverages the full potential of the QuBind framework. As an example, we use the quantum circuit shown in Figure 7.1, represented in OpenQASM format. OPENQASM 2.0; include "qelib1.inc"; qreg q[4]; creg c[4]; h q[0]; h q[1]; h q[2]; h q[3]; h q[0]; cp(pi/2) q[1],q[0]; cp(pi/4) q[2],q[0]; cp(pi/8) q[3],q[0]; h q[1]; cp(pi/2) q[2],q[1]; cp(pi/4) q[3],q[1]; h q[2]; cp(pi/2) q[3],q[2]; h q[3]; swap q[0],q[3]; swap q[1],q[2]; measure q -> c; Figure 7.1: Quantum Fourier Transform for 4 qubits circuit 44 7.1. NISQ Analyzer Building on the model previously defined in Chapter 6, we apply our API to this use case, which focuses on selecting QPUs based on structural and compatibility constraints [24]. One such constraint, expressed as sdk(C)∈sdkSupport(qi), requires that the SDK used by a given circuit Cbe supported by the candidate QPU qi. This constraint arises from specific implementation details; however, our approach is SDK-agnostic and therefore does not explicitly enforce it. For this use case, a request is made to the /bind endpoint as showed in Figure 7.2. { "qasm": "...", "shots": 1024, "constraints": [ { "name": "depth_constraint", "description": "QPU max_depth is at least the circuit depth", "target": "circuit", "property": "depth", "operator": "le", "value": "qpu.max_depth" } ], "ranked": true } Figure 7.2: Example JSON payload for the NISQ Analyzer use case submitted to the /bind endpoint The API response returns a detailed description of the selected QPU alongside a ranked list of other suitable QPUs, as defined in the model. An example response is illustrated below in Figure 7.3: 45 { "selected_qpu": { "id": "premium-01", "name": "Premium Quantum", "provider": "IBM", "qubits": 27, "native_gates": [...], "gate_fidelities": { ...}, "readout_fidelities": {...}, "max_depth": 2000, "max_shots": 20000, "workload": 15, "available": true }, "figure_of_merit": 0, "ranked_qpus": [ { "qpu_id": "premium-01", "qpu_name": "Premium Quantum", "provider": "IBM", "figure_of_merit": 0 }, { "qpu_id": "standard-01", "qpu_name": "Standard Quantum", "provider": "AZURE", "figure_of_merit": 0 }, { "qpu_id": "budget-01", "qpu_name": "Budget Quantum", "provider": "AWS", "figure_of_merit": 0 }, ... } ] } Figure 7.3: JSON response from the /bind endpoint illustrating the selected QPU, including hardware specifications, gate and readout fidelities, and a ranked list of suitable QPUs for the NISQ Analyzer use case. 7.2. Q-Orchestrator Building on the model previously defined in Chapter 6, we apply our API to this use case, which focuses on selecting QPUs based on their workload [4]. 46 For this use case, a request is made to the /bind endpoint as depicted in Figure 7.4. { "qasm": "...", "shots": 12000, "constraints": [ { "name": "shots_constraint", "description": "Ensure shots are within QPU limits", "target": "circuit", "property": "shots", "operator": "le", "value": "qpu.max_shots" } ], "figures_of_merit": { "workload_weight": 1.0, "cost_weight": 0.0, "error_weight": 0.0 } } Figure 7.4: Example JSON payload for the Q-Orchestrator use case submitted to the /bind endpoint The API response returns a detailed description of the selected QPU, including hardware specifications, gate and readout fidelities, and its figure of merit score. An example response is shown in Figure 7.5. { "selected_qpu": { "id": "available-01", "name": "Available Quantum", "provider": "AWS", "qubits": 127, "native_gates": [...], "gate_fidelities": { ... }, "readout_fidelities": { ... }, "max_depth": 600, "max_shots": 15000, "workload": 5, "available": true }, "figure_of_merit": 0.05, } Figure 7.5: JSON response from the /bind endpoint showing the selected QPU for the Q-Orchestrator use case based on minimal workload. 47 7.3. MQT Predictor Building on the model previously defined in Chapter 6, we apply our API to this use case, which focuses on selecting QPUs based on the expected fidelity of executing a circuit Cin the QPU qi[20]. For this use case, a request is made to the /bind endpoint as depicted in Figure 7.6. { "qasm": "...", "shots": 12000, "constraints": [], "figures_of_merit": { "workload_weight": 0.0, "cost_weight": 0.0, "error_weight": 1.0 } } Figure 7.6: Example JSON payload for the MQT Predictor use case submitted to the /bind endpoint The API response returns a detailed description of the selected QPU, including hardware specifications, gate and readout fidelities, and its figure of merit score. An example response is shown in Figure 7.7. { "selected_qpu": { "id": "premium-01", "name": "Premium Quantum", "provider": "IBM", "qubits": 27, "native_gates": [...], "gate_fidelities": { ... }, "readout_fidelities": { ... }, "max_depth": 2000, "max_shots": 20000, "workload": 15, "available": true }, "figure_of_merit": 0.04706191511790869, } Figure 7.7: JSON response from the /bind endpoint showing the selected QPU for the MQT Predictor use case based on maximum fidelity. 48 7.4. Balanced Mode One of the distinguishing features of QuBindR is its ability to incorporate multiple figures of merit into the decision-making process when selecting QPUs. In this case, we enable a balanced execution strategy by equally weighting all figures of merit. For this use case, a request is made to the /bind endpoint as depicted in Figure 7.8. { "qasm": "...", "shots": 1024, "constraints": [], "figures_of_merit": { "workload_weight": 0.33, "cost_weight": 0.33, "error_weight": 0.34 } } Figure 7.8: Example JSON payload for the balanced use case submitted to the /bind endpoint The API response returns a detailed description of the selected QPU, including hardware specifications, gate and readout fidelities, and its overall figure of merit score. An example response is shown in Figure 7.9. { "selected_qpu": { "id": "standard-01", "name": "Standard Quantum", "provider": "AZURE", "qubits": 20, "native_gates": [...], "gate_fidelities": {...}, "readout_fidelities": {...}, "max_depth": 1000, "max_shots": 10000, "workload": 10, "available": true }, "figure_of_merit": 0.39048596370823874, "ranked_qpus": null } Figure 7.9: JSON response from the /bind endpoint showing the selected QPU for the balanced use case based on costs, fidelity and workload. 49 This work is licensed under a Creative Commons “Attribution-NonCommercial-NoDerivatives 4.0 International” license. 4 A. Romero-Flores et al. expressed as total pending workloads. This selection is driven by a optimization function, which evaluates each candidate QPU based on a weighted combination of after-mentioned metrics. To accommodate diverse execution priorities (e.g., speed vs. fidelity), the Quantum Load Balancer supports a user-defined parametrization of metric importance, allowing dynamic tuning of selection behaviour based on the context of the execution. For instance, let Cdenote a quantum circuit and Q=q1, q2, . . . , qnbe the set of candidate QPUs available for execution. Given the weights αand βreflecting the importance of availability and error rates respectively, the optimal QPU q∗is determined by minimizing the objective function: q∗= arg min qi∈Q (α·workload(qi) + β·errorRates(qi,C)) (1) 3 Conclusions In this work, we introduced Qrchestrator, an errorand load-aware quantum orchestration framework for executing quantum circuits across multiple cloudbased quantum providers. Our approach extends previous quantum load-balancing solutions by integrating error-awareness. As quantum software engineering continues to evolve, orchestration frameworks like Qrchestrator will be essential for ensuring higher Quality of Service (QoS) in both quantum and hybrid quantumclassical systems. A key challenge moving forward is establishing a standardized definition of cloud-based QPUs to enable optimized selection across different quantum providers. Our future work will focus on implementing the Qrchestrator framework. We will also apply this approach to the domain of demand and management in hybrid quantum-classical services [3]. Acknowledgments. This work has been funded by the Consejer´ıa de Transformaci´on Econ´omica, Industria, Conocimiento y Universidades, de la Junta de Andaluc´ıa, within the framework of the project “Smart Computer systems Research and Engineering (SCORE)” part of the Programa de Fortalecimiento de Institutos Universitarios de Investigaci´on de la Universidades Andaluzas, Centros e Infraestructuras aimed at obtaining the “Severo Ochoa” or “Mar´ıa de Maeztu” excellence accreditation. References 1. J. M. Murillo, J. Garcia-Alonso, E. Moguel, J. Barzen, F. Leymann, S. Ali, T. Yue, P. Arcaini, R. P´erez-Castillo, I. Garc´ıa Rodr´ıguez de Guzm´an, M. Piattini, A. RuizCort´es, A. Brogi, J. Zhao, A. Miranskyy, M. Wimmer, Quantum Software Engineering: Roadmap and Challenges Ahead, ACM Transactions on Software Engineering and Methodology (Jan. 2025). doi:10.1145/3712002. 2. J. Alvarado-Valiente, J. Romero-´ Alvarez, E. Moguel, J. Garc´ıa-Alonso, J. M. Murillo, Orchestration for quantum services: The power of load balancing across multiple service providers, Science of Computer Programming 237 (2024) 103139. 3. A. Ruiz-Cort´es, J. A. Parejo, An Initial Exploration of Pricing-driven Governance for Hybrid Quantum-Classical SaaS, SISTEDES, JISBD, QuantumX (2025). B. QPU Mocks This appendix provides detailed specifications for the mock QPU resources used in the QuBindR implementation. These synthetic quantum processor profiles were designed to represent a diverse range of quantum computing capabilities, with distinct tradeoffs across various dimensions such as fidelity, cost, and availability. B.1. Mock QPU Specifications The QuBindR system includes six mock QPUs with different characteristics, representing a variety of quantum computing resources available from different providers. Each QPU has specific properties that make it suitable for different types of requirements. B.1.1 Premium Quantum •ID: premium-01 •Provider: IBM •Qubits: 27 •Native Gates: X, Y, Z, H, CNOT, CZ, RZ, RX, RY •Gate Fidelities: –X: 0.9995 –Y: 0.9995 –Z: 0.9997 –H: 0.9990 –CNOT: 0.995 –CZ: 0.994 –RZ: 0.9993 –RX: 0.9992 –RY: 0.9991 •Readout Fidelity: 0.99 (uniform across all qubits) •Maximum Circuit Depth: 2000 •Maximum Shots: 20,000 •Workload: 15 pending jobs •Availability: Available •Cost Model: 2.0×shots ×gate_count/100 57 •Description: High-end QPU with excellent fidelity but high cost B.1.2 Standard Quantum •ID: standard-01 •Provider: Azure •Qubits: 20 •Native Gates: X, Y, Z, H, CNOT, CZ, RZ •Gate Fidelities: –X: 0.9980 –Y: 0.9975 –Z: 0.9985 –H: 0.9970 –CNOT: 0.988 –CZ: 0.987 –RZ: 0.9975 •Readout Fidelity: 0.985 (uniform across all qubits) •Maximum Circuit Depth: 1000 •Maximum Shots: 10,000 •Workload: 10 pending jobs •Availability: Available •Cost Model: 1.0×shots ×gate_count/100 •Description: Standard QPU with good balance of cost and fidelity B.1.3 Budget Quantum •ID: budget-01 •Provider: AWS •Qubits: 12 •Native Gates: X, Z, H, CNOT, RZ •Gate Fidelities: –X: 0.985 –Z: 0.987 –H: 0.982 58 –CNOT: 0.975 –RZ: 0.984 •Readout Fidelity: 0.96 (uniform across all qubits) •Maximum Circuit Depth: 500 •Maximum Shots: 5,000 •Workload: 75 pending jobs •Availability: Available •Cost Model: 0.5×shots ×gate_count/100 •Description: Budget QPU with lower fidelity but very low cost B.1.4 Capacity Quantum (IBM) •ID: capacity-01 •Provider: IBM •Qubits: 127 •Native Gates: X, Z, H, CNOT, RZ •Gate Fidelities: –X: 0.990 –Z: 0.992 –H: 0.988 –CNOT: 0.980 –RZ: 0.989 •Readout Fidelity: 0.975 (uniform across all qubits) •Maximum Circuit Depth: 800 •Maximum Shots: 8,000 •Workload: 50 pending jobs •Availability: Available •Cost Model: 1.5×shots ×qubits_used/10 •Description: High-capacity QPU with many qubits but medium fidelity B.1.5 Available Quantum (AWS) •ID: available-01 •Provider: AWS 59 •Qubits: 127 •Native Gates: X, Z, H, CNOT, RZ •Gate Fidelities: –X: 0.990 –Z: 0.992 –H: 0.988 –CNOT: 0.980 –RZ: 0.989 •Readout Fidelity: 0.975 (uniform across all qubits) •Maximum Circuit Depth: 600 •Maximum Shots: 15,000 •Workload: 5 pending jobs •Availability: Available •Cost Model: 1.5×shots ×qubits_used/10 •Description: Low-workload QPU with many qubits and good availability B.1.6 Inactive Quantum (AWS) •ID: inactive-01 •Provider: AWS •Qubits: 20 •Native Gates: X, Y, Z, H, CNOT, RZ •Gate Fidelities: –X: 0.990 –Y: 0.989 –Z: 0.991 –H: 0.987 –CNOT: 0.981 –RZ: 0.988 •Readout Fidelity: 0.975 (uniform across all qubits) •Maximum Circuit Depth: 1200 •Maximum Shots: 10,000 •Workload: 0 pending jobs 60 •Availability: Not Available (offline) •Cost Model: 1.0×shots ×gate_count/100 •Description: Inactive QPU for testing availability constraints 61 C. Code Availability All software artifacts developed and used during this research are available for reproducibility and reuse. The codebase is hosted on a publicly accessible Git repository https://github.com/adrrf/qubindr. 62 D. Bibliography [1] AWS Braket, 2024. URL https://aws.amazon.com/en/braket/. [2] Azure Quantum, 2024. URL https://quantum.microsoft.com/en-us/ solutions/microsoft-quantum-solutions. [3] IBM Quantum, 2024. URL https://quantum.ibm.com/. [4] J. Alvarado-Valiente, J. Romero-Álvarez, E. Moguel, J. García-Alonso, and J.M. Murillo. Orchestration for quantum services: The power of load balancing across multiple service providers. Science of Computer Programming, 237, 2024. doi: 10.1016/j.scico.2024.103139. [5] Dirk Bouwmeester, Artur K. Ekert, and Anton Zeilinger. The physics of Quantum Information: Quantum cryptography, Quantum teleportation, Quantum Computation. Springer, 2011. [6] Michael Brooks. Beyond quantum supremacy: The hunt for useful quantum computers. Nature, 574(7776):19–21, Oct 2019. doi: 10.1038/d41586-019-02936-3. URL https://www.nature.com/articles/ d41586-019-02936-3. [7] Francisco Javier Cavero, José Antonio Parejo, and Antonio Ruiz-Cortés. Bridging Apples and Oranges: A Schema for Defining QoS-Aware Composition. In SISTEDES, 2025. (In press). [8] Juan Luis Ceada Ramos. Informe Final sobre la Consulta Preliminar del Mercado: “Perfiles Profesionales Ámbito Informático”. https: //www.juntadeandalucia.es/haciendayadministracionpublica/apl/pdc_ sirec/perfiles-licitaciones/consultas-preliminares/detalle.jsf? idExpediente=000000078484, 2018. [9] Qiskit Community. Qiskit: An Open-source Framework for Quantum Computing, 2024. URL https://qiskit.org/documentation/. [10] Microsoft Corporation. Azure Quantum Documentation and QDK, 2024. URL https://learn.microsoft.com/en-us/azure/quantum/. [11] A. Einstein, B. Podolsky, and N. Rosen. Can Quantum-Mechanical Description of Physical Reality Be Considered Complete? Phys. Rev., 47:777–780, May 1935. doi: 10.1103/PhysRev.47.777. URL https://link.aps.org/doi/10. 1103/PhysRev.47.777. [12] I. Faro, I. Sitdikov, D.G. Valinas, F.J.M. Fernandez, C. Codella, and J. Glick. Middleware for Quantum: An orchestration of hybrid quantum-classical systems. In Proceedings - 2023 IEEE International Conference on Quantum Software, QSW 2023, pages 1–8, 2023. ISBN 9798350304794. doi: 10.1109/QSW59989.2023. 00011. 63 [13] Richard P. Feynman, Robert B. Leighton, and Matthew Sands. The feynmann lectures on physics, volume III. Addison-Wesley, 1966. URL https://www. feynmanlectures.caltech.edu/. [14] Alejandro García-Fernández, José Antonio Parejo, and Antonio Ruiz-Cortés. Pricing4SaaS: Towards a Pricing Model to Drive the Operation of SaaS. In Intelligent Information Systems. CAiSE 2024., pages 47–54. Springer Nature Switzerland, 2024. ISBN 978-3-031-61000-4. [15] Alan Hevner, Alan R, Salvatore March, Salvatore T, Park, Jinsoo Park, Ram, and Sudha. Design Science in Information Systems Research. Management Information Systems Quarterly, 28:75–, 03 2004. [16] Enrique Moguel, Jose Garcia-Alonso, and Juan M. Murillo. Development and Deployment of Quantum Services, pages 189–222. Springer Nature Switzerland, Cham, 2024. ISBN 978-3-031-64136-7. doi: 10.1007/978-3-031-64136-7_8. URL https://doi.org/10.1007/978-3-031-64136-7_8. [17] Juan M. Murillo, Jose Garcia-Alonso, Enrique Moguel, Johanna Barzen, Frank Leymann, Shaukat Ali, Tao Yue, Paolo Arcaini, Ricardo Pérez-Castillo, Ignacio García Rodríguez de Guzmán, Mario Piattini, Antonio Ruiz-Cortés, Antonio Brogi, Jianjun Zhao, Andriy Miranskyy, and Manuel Wimmer. Quantum Software Engineering: Roadmap and Challenges Ahead. ACM Transactions on Software Engineering and Methodology, January 2025. ISSN 1557-7392. doi: 10.1145/3712002. [18] M. A. Nielsen and Isaac Chuang. Quantum Computation and Quantum Information. Cambridge University Press, 2010. [19] John Preskill. Quantum Computing in the NISQ era and beyond. Quantum, 2:79, August 2018. ISSN 2521-327X. doi: 10.22331/q-2018-08-06-79. URL http://dx.doi.org/10.22331/q-2018-08-06-79. [20] Nils Quetschlich, Lukas Burgholzer, and Robert Wille. MQT Predictor: Automatic Device Selection with Device-Specific Circuit Compilation for Quantum Computing. ACM Transactions on Quantum Computing, 6:1–26, 3 2025. ISSN 2643-6809. doi: 10.1145/3673241. [21] Mark B. Ritter. Near-term quantum algorithms for quantum many-body systems. Journal of Physics: Conference Series, 1290(1):012003, Oct 2019. doi: 10.1088/1742-6596/1290/1/012003. URL https://iopscience.iop.org/ article/10.1088/1742-6596/1290/1/012003. [22] Adrián Romero-Flores, Alfonso E. Márquez-Chamorro, and Antonio Ruiz-Cortés. Qrchestrator: An Error and Load Aware Quantum Orchestrator for Multiple NISQ Cloud Providers. In SISTEDES 2025, QuantumX Track, 2025. In press. [23] Antonio Ruiz-Cortés and José Antonio Parejo. An Initial Exploration of Pricingdriven Governance for Hybrid Quantum-Classical SaaS. In SISTEDES 2025, QuantumX Track, 2025. In press. 64 [24] M. Salm, J. Barzen, U. Breitenbücher, F. Leymann, B. Weder, and K. Wild. The NISQ Analyzer: Automating the Selection of Quantum Computers for Quantum Algorithms, volume 1310. Springer, 2020. ISBN 9783030648459. doi: 10. 1007/978-3-030-64846-6_5. [25] Seguridad Social. Cotización y Recaudación de Trabajadores - Tipos de Cotización, 2024. URL https://www.seg-social.es/wps/portal/wss/internet/ Trabajadores/CotizacionRecaudacionTrabajadores/36537#36538. [26] Amazon Web Services. Amazon Braket SDK Documentation, 2024. URL https://docs.aws.amazon.com/braket/latest/developerguide/ braket-python-sdk.html. [27] B. Weder, J. Barzen, F. Leymann, and M. Salm. Automated quantum hardware selection for quantum workflows. Electronics (Switzerland), 10, 2021. doi: 10. 3390/electronics10080984. [28] Benjamin Weder, Johanna Barzen, Martin Beisel, and Frank Leymann. Provenance-Preserving Analysis and Rewrite of Quantum Workflows for Hybrid Quantum Algorithms. SN Computer Science, 4(3), February 2023. ISSN 26618907. doi: 10.1007/s42979-022-01625-9. URL http://dx.doi.org/10.1007/ s42979-022-01625-9. [29] K. Wild, U. Breitenbucher, L. Harzenetter, F. Leymann, D. Vietz, and M. Zimmermann. TOSCA4QC: Two Modeling Styles for TOSCA to Automate the Deployment and Orchestration of Quantum Applications. In Proceedings - 2020 IEEE 24th International Enterprise Distributed Object Computing Conference, EDOC 2020, pages 125–134, 2020. ISBN 9781728164731. doi: 10.1109/EDOC49727. 2020.00024. 65