State-of-the-Art Hardware

Quantum hardware is not one technology. It is a family of competing physical approaches, each with different control methods, scaling constraints, error mechanisms, and operational tradeoffs.

This chapter gives the systems-level view. The goal is not to crown a winner. The goal is to understand how hardware choices shape the rest of the stack.

2.1 Hardware changes the software problem

In classical cloud computing, a developer can usually ignore whether a CPU package was manufactured on one process node or another. In quantum computing, the physical substrate changes the programming and operating model.

flowchart TD
    Hardware[Hardware architecture] --> Topology[Connectivity topology]
    Hardware --> Gates[Native gate set]
    Hardware --> Noise[Noise processes]
    Hardware --> Timing[Gate and measurement timing]
    Hardware --> Control[Control stack]

    Topology --> Compiler[Compiler strategy]
    Gates --> Compiler
    Noise --> ErrorBudget[Error budget]
    Timing --> Scheduler[Scheduler]
    Control --> Calibration[Calibration system]

    Compiler --> Workload[Workload feasibility]
    ErrorBudget --> Workload
    Scheduler --> Workload
    Calibration --> Workload

A hardware-neutral algorithm still becomes hardware-specific when it is compiled and executed.

2.2 Main architecture families

The field includes superconducting qubits, trapped ions, neutral atoms, photonics, spin qubits, and topological approaches at different stages of development. This chapter uses superconducting and trapped-ion systems as concrete examples; chapter 19 covers other modalities.

Superconducting systems

Superconducting quantum computers use circuits cooled to extremely low temperatures. They often offer fast gate operations and lithographic manufacturing compatibility, but they face challenges in cryogenic wiring, crosstalk, calibration complexity, and maintaining high fidelity as systems scale.

IBM’s public roadmap sets quantum-advantage goals around 2026 and targets a fault-tolerant system in 2029. These are vendor planning targets, not demonstrated capabilities or guaranteed delivery dates. See R1, R2, and R3.

Google reported Willow as a 105-qubit chip. The associated Nature paper demonstrates below-threshold surface-code memories on Willow processors: increasing code distance reduced logical memory errors under the tested conditions. This is a memory demonstration, not a demonstration of a complete fault-tolerant general-purpose computation. See R4 and R5.

Trapped-ion systems

Trapped-ion systems use individual ions as qubits, manipulated by electromagnetic fields and lasers. They are often discussed for high-fidelity operations and flexible connectivity. The operational tradeoffs include laser control complexity, motional modes, timing, and scaling the ion-control architecture.

IonQ describes Forte as a trapped-ion system with software-configurable characteristics. See R6. Quantinuum’s H2 documentation describes a trapped-ion architecture with 56 physical qubits in its product data sheet. See R7 and R8.

2.3 Architecture comparison

The details change quickly, but the axes are stable.

Do not over-read this table. The important point is not that one column is “better.” The point is that each architecture produces a different operating system problem.

2.4 The QPU is a managed resource

A quantum processing unit should be treated like a scarce, time-varying resource. Its quality is not static. A good scheduler does not only ask “is the machine free?” It asks whether the machine is suitable for the workload now.

flowchart LR
    Job[Incoming quantum job] --> Requirements[Requirements: qubits, topology, depth, precision]
    Requirements --> BackendPool[Available backends]
    BackendPool --> CalData[Calibration snapshots]
    CalData --> Score[Backend scoring]
    Score --> Decision{Suitable backend?}
    Decision -- yes --> Queue[Queue and execute]
    Decision -- no --> Rewrite[Rewrite circuit or wait]
    Queue --> Results[Results + metadata]

A backend score may include number of usable qubits, two-qubit gate fidelity, readout fidelity, queue time, calibration age, topology fit, and historical performance for similar circuits.

2.5 Error correction changes the hardware target

Near-term machines are noisy. They run physical qubits directly with mitigation and careful circuit design. Fault-tolerant machines aim to encode logical qubits across many physical qubits, using error correction to suppress logical error rates.

This transition changes the meaning of scale. In a noisy machine, more physical qubits can help only if they are good enough and connected well enough. In a fault-tolerant machine, the key metrics shift toward logical qubits, logical error rates, decoder performance, syndrome extraction, and the overhead required for a useful algorithm.

flowchart TD
    Physical[Physical qubits] --> Code[Error-correcting code]
    Code --> Syndrome[Syndrome measurements]
    Syndrome --> Decoder[Classical decoder]
    Decoder --> Correction[Correction / frame update]
    Correction --> Logical[Logical qubit]
    Logical --> Algorithm[Fault-tolerant algorithm]

    Noise[Physical noise] --> Syndrome
    Latency[Decoder latency] --> Correction
    Overhead[Physical-to-logical overhead] --> Logical

The systems challenge is that error correction adds classical real-time work to a quantum control problem that was already difficult.

2.6 Hardware telemetry that matters

A serious operating platform should collect more than raw job results. Hardware telemetry should include:

2.7 Operational rule: compile against the machine you actually have

Hardware-aware compilation is not an optimization flourish. It is mandatory. The same abstract circuit may be practical on one device and useless on another because of topology, native gates, or calibration state.

In a mature platform, compilation should be parameterized by current backend data, not hardcoded assumptions. A compiler that ignores calibration is like a network router that ignores link health.

2.8 Chapter summary

Quantum hardware architecture determines topology, control, noise, timing, calibration, and feasible workloads. Current state-of-the-art systems are progressing quickly, but the operator’s job remains the same: match workloads to hardware under current constraints, preserve telemetry, and avoid abstracting away the physical facts that dominate result quality.

Additional technical sources: [R252].