From QPU to Results: A Practical Guide to Superconducting Quantum Processor Calibration  

How do you calibrate a superconducting quantum processor? 

At last month’s workshop at the Winter School in Academia Sinica in Taiwan, we shared a hands-on look at exactly this workflow – going from initial signals to gate-level performance, reducing iteration time while increasing experimental reliability. 

The calibration of a single- or few-qubit device is very different from calibrating a large-scale device, as there are many more sources of error and crosstalk and more interdependent control parameters.  

One challenge is that quantum hardware drifts in time, so calibration is never a one-time effort. You can hardly expect the same pulse sequence to yield equally high fidelity a few hours after your calibration. You need to iterate – characterize, adjust, validate, and repeat. The faster and more robust this loop is, the more time the QPU can run experiments.  

Here are some key points and logical steps to keep in mind. 

Start with signal integrity 

Before considering any operation, calibration starts with basic questions: Can you generate the signals you think you’re generating?  Can you rely on the measurement results you’re getting?  

Addressing these questions requires the validation of the output chain behavior (amplitude scaling linearity, phase stability, spurious tones and so on) and input chain behavior (meaning gain and noise floor). When signal integrity is off, it can masquerade as ‘bad qubits,’ ‘bad gates,’ or ‘mysterious decoherence,’ while the real issue may not have anything to do with the quantum system.  

It’s critical to remove the unknowns early. You want the control stack to behave deterministically, to focus on the device’s physics and not instrumentation. 

Plan your way to success 

Once basic signal sanity is established, calibration starts with strategic decisions. Think of it as a checklist: 

• Find the frequency 
• Tune the amplitude 
• Fix the readout 
• Optimize the two-qubit gate 

The problem is, in practice, the parameters we want to calibrate are rarely independent. Pulse amplitudes depend on frequency estimates. Crosstalk compensation depends on pulse shapes. Two‑qubit gates depend on the quality of everything underneath them. 

Calibration is not a straight path, but rather a web of dependencies. When these dependencies are not made explicit, progress becomes reactive: 

Something drifts → experiments are rerun → performance improves → something else drifts → repeat. 

To move forward intentionally, this dependency structure must be made visible. A useful way to formalize this is to think in terms of a calibration graph, which describes how calibration parameters depend on one another. Such a graph organizes experiments, revealing which assumptions depend on others, and which parts of the system must be revisited when something changes. It allows you to re-run only the parts of the workflow affected by drift, localize failures when performance degrades, and adapt the workflow as experimental goals change. The goal is not to eliminate complexity, but to make it visible and controllable.  

Define nodes and edges on the calibration graph 

A calibration graph is like a map, breaking down the big strategic goal into specific tactical ones, defined by nodes and edges. Nodes are calibration steps that update specific parameters, and edges represent dependencies between parameters.  

A calibration node is one experiment along with all the decision-making derived from the experiment outcomes: what parameter to change, whether to validate (pass/fail), and what to do next – how to branch out. It is impossible to compensate for all effects in a single experiment. For example, if the Stark shift induced by the drive amplitude is handled in a separate node, it does not belong here. Interdependence may require revisiting a node later, but that does not change its local objective during a given execution. The node does not need to know the global graph. Each node should have ONE unambiguous goal and be optimized for doing it correctly and efficiently.  

While nodes define action, edges define impact. If Node A has an edge to Node B, it means that a change in the parameter updated by Node A may invalidate the parameter updated by Node B. Edges encode the dependency structure of the system and determine how recalibration propagates. If we look at the calibration graph as the map, nodes are where decisions are made and edges determine where impact propagates next. 

Use suitable metrics 

Measurements in different calibration nodes serve very different purposes. Some measurements act as checkpoints, aiming to comprehensively assess the system-level performance of the QPU that has been brought up so far. Randomized benchmarking (RB) is a canonical metric. It reports average Clifford gate fidelity and serves as a widely accepted reference point for gate performance. Checkpoint measurements like RB should be treated as validation milestones. They tell you where you are but do not guide any action towards improvement.

The measurements that drive the calibration are diagnostic. Instead of an overall assessment, such measurements are supposed to expose the imperfection of a specific operation. A good metric for such a measurement should be selective, reflecting only the parameter of interest. It should also be interpretable, meaning it should lead to some direct corrective action. And it should be efficient – providing enough information with a minimal number of measurement shots. 

The technique commonly used for the above involves error amplification. By repeating certain operations, stretching a sequence, or constructing interference conditions, a small deviation in a parameter can result in large contrast in the measurement outcome. A suitable metric makes the best use of a measurement it is designed for, speeding up the calibration process.  

Manage the state machine smartly 

Calibration parameters form a ‘state machine’ – every new update transitions the system into a new state, with a specific validity window and dependency context. This brings up two concerns. One, the parameter structure should be device‑aware – meaning that the structural relationship between qubits and their operations should be reflected in the data structure. For example, the properties associated with the data qubits, ancilla qubits, and couplers, as well as operations that could affect parameters of a specific element, or operations that could be performed simultaneously and those that couldn’t. 

And two, the management system should be device‑agnostic. Ideally, the calibration software framework should apply to state machines for any QPU architecture. It’s important to find a common logical flow that would support specific parameter updates and their dependencies. A smart parameter management system turns calibration history into usable data, enabling comparison, regression testing, and controlled iteration—especially when automation enters the iteration loop.  

Speed of calibration matters 

Calibration is not a one-time milestone. Being able to complete a calibration workflow doesn’t mean achieving success. The bottleneck is often not whether certain calibration measurements can be done, but whether they can be done fast enough to be useful. 

A practical QPU calibration loop has to cope with the drift in the physical system, at timescales ranging from milliseconds to hours, the qubit-to-qubit variation on a large-scale device, and any change to the experimental conditions. This means that the calibrated parameters are constantly aging. In practice, the question is not how well the system is performing during calibration, but how long that performance would remain good for. 

Fast calibration leads to an important capability: tracking physical drifts in real time. For example, qubit frequencies can drift over time. While a rapid calibration loop can continuously update the control parameters, it’s critical to maintain gate performance despite the ongoing drifts. In this regime, calibration acts as an active stabilizer for the processor. 

On the other hand, drifts that occur on timescales shorter than the calibration operation cannot be compensated – meaning that drifts that outrun calibration speed set a hard ceiling on achievable performance. That’s why the speed of the calibration matters – not just for productivity, but also for the performance a system can sustain. 

The time spent on calibration includes the duration of the execution of the experiment, the data analysis, and the feedforward parameter updates.  Workflows that rely on manual intervention or slow offline analysis face a bottleneck in terms of the total speed. So automation is not an optional feature for convenience but a must, especially for scaling. Fast, automated calibration is what matters for the quantum hardware to behave as a usable processor and, more importantly, to stay this way as we scale.  

Bringing up, or calibrating, a superconducting quantum processor is an intriguing engineering endeavor at the intersection of hardware and software. The ideas shared in this blog are not meant as a recipe, but as reflections drawn from the authors’ experience – hoping to help fellow quantum engineers, including our future selves, with finding less friction and more satisfaction in QPU calibration. As tools, software infrastructure, and calibration workflows continue to mature, we are confident that calibration will become faster and more reliable, providing a robust foundation for running quantum experiments at scale.