Facilities, Cryogenics, and Physical Infrastructure

A cloud user can pretend the QPU is an endpoint. A builder cannot. A state-of-the-art quantum computer is a physical installation with power, cooling, vibration, electromagnetic compatibility, gas handling, safety interlocks, maintenance windows, clean workflows, spares, and service contracts.

Facilities work is not secondary. It defines what the platform can become.

20.1 The machine room is part of the computer

flowchart TB
    Building[Building infrastructure] --> Power[Power quality and backup]
    Building --> HVAC[HVAC and heat rejection]
    Building --> Floor[Vibration and floor loading]
    Building --> Safety[Safety and access controls]
    Power --> Controls[Control electronics]
    HVAC --> Cryo[Cryogenic platform]
    Floor --> Cryo
    Safety --> Ops[Operations process]
    Cryo --> QPU[QPU package]
    Controls --> QPU
    QPU --> Data[Experiment data]

A quantum facility has two simultaneous jobs:

1. keep the physical environment inside the device envelope,
2. keep the human and operational environment inside the safety envelope.

Ignoring either one produces outages.

20.2 Cryogenic systems for superconducting hardware

Superconducting processors require ultra-low-temperature environments. Bluefors describes cryogen-free dilution refrigerators as closed-loop cooling systems that cool samples and devices to millikelvin temperatures and are used in quantum computing and related research [R44]. IBM’s System Two materials similarly frame future systems as an integration of cryogenic infrastructure, runtime servers, and modular control electronics [R39].

flowchart LR
    RoomTemp[Room temperature electronics] --> Feedthrough[Feedthroughs]
    Feedthrough --> Stages[Cryogenic stages]
    Stages --> Attenuators[Attenuators / filters]
    Attenuators --> Package[QPU package]
    Package --> Amp[Cryogenic amplification]
    Amp --> Acquisition[Acquisition electronics]
    Acquisition --> Runtime[Runtime]

The cryogenic stack constrains:

20.3 Facility telemetry

Every facility variable should be treated as possible experiment context. That does not mean every result depends on every sensor. It means unexplained regressions are impossible to debug if the facility state was not recorded.

flowchart TB
    Sensors[Facility sensors] --> Stream[Telemetry stream]
    Stream --> TSDB[Time-series store]
    Stream --> Alerts[Alert rules]
    TSDB --> Correlate[Correlation with experiments]
    Experiments[Experiment metadata] --> Correlate
    Correlate --> RootCause[Root-cause analysis]

Minimum facility telemetry:

The platform should attach relevant facility-state summaries to experiment bundles when a job overlaps an anomaly window.

20.4 Maintenance windows and cooldown economics

A classical server can often be rebooted in minutes. A cryogenic quantum system may require long thermal cycles and careful recommissioning after hardware changes.

gantt
    title Example physical maintenance timeline
    dateFormat  YYYY-MM-DD
    section Preparation
    Freeze job intake              :a1, 2026-04-20, 1d
    Export last calibration state  :a2, after a1, 1d
    section Intervention
    Warm-up / safe access          :b1, 2026-04-22, 2d
    Physical service               :b2, after b1, 2d
    Cooldown                       :b3, after b2, 3d
    section Recovery
    Bring-up checks                :c1, after b3, 1d
    Calibration campaign           :c2, after c1, 2d
    Benchmark release gate         :c3, after c2, 1d

The cost of a physical intervention is not the technician time. It is the lost experiment window, the reset calibration state, and the opportunity cost of deferred jobs.

20.5 Facilities SLOs

flowchart LR
    FacilitySLO[Facility SLOs] --> Uptime[Uptime]
    FacilitySLO --> Stability[Environmental stability]
    FacilitySLO --> Recovery[Recovery time]
    FacilitySLO --> Observability[Telemetry completeness]
    FacilitySLO --> Safety[Safety compliance]

Example SLOs:

These are not vanity metrics. They prevent users from interpreting facility failures as algorithmic failures.

20.6 Spares, vendors, and service contracts

The supply chain is part of uptime. A failed controller card, compressor component, laser subsystem, amplifier, or custom cable can become the critical path for platform recovery.

flowchart TB
    Failure[Component failure] --> Spare{Local spare?}
    Spare -- yes --> Replace[Replace under procedure]
    Spare -- no --> Vendor[Vendor lead time]
    Vendor --> Downtime[Extended downtime]
    Replace --> Requalify[Requalify subsystem]
    Requalify --> Release[Release QPU]

Inventory policy should be based on:

• component failure rate,
• vendor lead time,
• substitution risk,
• calibration impact,
• safety implications,
• whether replacement requires warm-up or user downtime.

For critical physical infrastructure, “we can order one” is not a recovery strategy.

20.7 On-premises versus cloud access

Most organizations should start with cloud access. On-premises systems are justified when the organization needs physical control, dedicated capacity, data locality, custom integration, or strategic hardware development.

quadrantChart
    title Access model decision
    x-axis Low need for physical control --> High need for physical control
    y-axis Low dedicated capacity need --> High dedicated capacity need
    quadrant-1 On-premises candidate
    quadrant-2 Reserved cloud capacity
    quadrant-3 Shared cloud access
    quadrant-4 Shared lab or hardware partnership
    Exploratory research: [0.2, 0.2]
    Regulated data pilot: [0.65, 0.35]
    High-volume algorithm lab: [0.4, 0.8]
    Hardware co-design program: [0.9, 0.85]

On-premises operation requires at least four mature functions:

1. physical operations,
2. quantum control engineering,
3. platform software,
4. research-user enablement.

Without all four, ownership becomes liability.

20.8 Safety and change control

Facilities changes must be treated like production changes. A small cabling, rack, cooling, vibration, or power modification can become a device-quality event.

flowchart TB
    Change[Facilities change request] --> Risk[Risk assessment]
    Risk --> Window[Maintenance window]
    Window --> Execute[Execute change]
    Execute --> Verify[Physical verification]
    Verify --> Calibrate[Calibration campaign]
    Calibrate --> Bench[Benchmark gate]
    Bench --> Release{Release?}
    Release -- yes --> Users[Resume user jobs]
    Release -- no --> Rollback[Rollback or continue repair]

Change-control record:

facility_change:
  id: FC-YYYY-NNN
  owner: string
  affected_systems:
    - cryostat
    - control_rack
    - network
    - power
  user_impact: none|degraded|downtime
  rollback_plan: string
  safety_review: required|not_required
  calibration_required: true
  release_gate:
    - facility_telemetry_normal
    - calibration_complete
    - benchmark_suite_passed

20.9 Chapter rule

A quantum computer is not installed when the vendor leaves. It is installed when the facility, telemetry, maintenance, release gates, and recovery process can preserve trust in user results.

References used in this chapter: [R39], [R44].

Additional technical sources: [R273].