Amazon Braket supported devices

In Amazon Braket, a device represents a QPU or simulator that you can call to run quantum tasks. Amazon Braket provides access to five QPU devices — from IonQ, Oxford Quantum Circuits, QuEra, Rigetti, and Xanadu, three on-demand simulators, three local simulators, and one embedded simulator. For all devices, you can find further device properties, such as device topology, calibration data, and native gate sets, on the Devices tab of the Amazon Braket console or by means of the GetDevice API. When constructing a circuit with the simulators, Amazon Braket currently requires that you use contiguous qubits or indices. If you are working with the Amazon Braket SDK, you have access to device properties as shown in the following code example.

from braket.aws import AwsDevice
from braket.devices import LocalSimulator

device = AwsDevice('arn:aws:braket:::device/quantum-simulator/amazon/sv1')              #SV1
# device = LocalSimulator()                                                             #Local State Vector Simulator
# device = LocalSimulator("default")                                                    #Local State Vector Simulator
# device = LocalSimulator(backend="default")                                            #Local State Vector Simulator
# device = LocalSimulator(backend="braket_sv")                                          #Local State Vector Simulator
# device = LocalSimulator(backend="braket_dm")                                          #Local Density Matrix Simulator
# device = LocalSimulator(backend="braket_ahs")                                         #Local Analog Hamiltonian Simulation
# device = AwsDevice('arn:aws:braket:::device/quantum-simulator/amazon/tn1')            #TN1
# device = AwsDevice('arn:aws:braket:::device/quantum-simulator/amazon/dm1')            #DM1
# device = AwsDevice('arn:aws:braket:::device/qpu/ionq/ionQdevice')                     #IonQ
# device = AwsDevice('arn:aws:braket:us-west-1::device/qpu/rigetti/Aspen-M-2')          #Rigetti Aspen-M-2
# device = AwsDevice('arn:aws:braket:us-west-1::device/qpu/rigetti/Aspen-M-3')          #Rigetti Aspen-M-3
# device = AwsDevice('arn:aws:braket:eu-west-2::device/qpu/oqc/Lucy')                   #OQC Lucy
# device = AwsDevice('arn:aws:braket:us-east-1::device/qpu/xanadu/Borealis')            #Xanadu Borealis
# device = AwsDevice('arn:aws:braket:us-east-1::device/qpu/quera/Aquila')               #QuEra Aquila

# get device properties
device.properties

Supported QPUs

• IonQ

• OQC Lucy

• QuEra Aquila

• Rigetti Aspen-M-2

• Rigetti Aspen-M-3

• Xanadu Borealis

Supported simulators

• Local state vector simulator (braket_sv) ('Default Simulator')

• Local density matrix simulator (braket_dm)

• Local AHS simulator

• State vector simulator (SV1)

• Density matrix simulator (DM1)

• Tensor network simulator (TN1)

• PennyLane’s Lightning Simulators

Choose the best simulator for your task

• Compare simulators

Note

To view the available AWS Regions for each device, scroll right across the following table.

Amazon Braket devices
Provider	Device Name	Paradigm	Type	Device ARN	Region
IonQ	ionQdevice	gate-based	QPU	arn:aws:braket:::device/qpu/ionq/ionQdevice	us-east-1
Oxford Quantum Circuits	Lucy	gate-based	QPU	arn:aws:braket:eu-west-2::device/qpu/oqc/Lucy	eu-west-2
QuEra	Aquila	Analog Hamiltonian Simulation	QPU	arn:aws:braket:us-east-1::device/qpu/quera/Aquila	us-east-1
Rigetti	Aspen M-2	gate-based	QPU	arn:aws:braket:us-west-1::device/qpu/rigetti/Aspen-M-2	us-west-1
Rigetti	Aspen M-3	gate-based	QPU	arn:aws:braket:us-west-1::device/qpu/rigetti/Aspen-M-3	us-west-1
Xanadu	Borealis	continuous-variable	QPU	arn:aws:braket:us-east-1::device/qpu/xanadu/Borealis	us-east-1
AWS	braket_sv	gate-based	Local simulator	N/A (local simulator in Braket SDK)	N/A
AWS	braket_dm	gate-based	Local simulator	N/A (local simulator in Braket SDK)	N/A
AWS	SV1	gate-based	On-demand simulator	arn:aws:braket:::device/quantum-simulator/amazon/sv1	All Regions where Amazon Braket is available.
AWS	DM1	gate-based	On-demand simulator	arn:aws:braket:::device/quantum-simulator/amazon/dm1	All Regions where Amazon Braket is available.
AWS	TN1	gate-based	On-demand simulator	arn:aws:braket:::device/quantum-simulator/amazon/tn1	us-west-2, us-east-1, and eu-west-2

To view additional details about the QPUs you can use with Amazon Braket, see Amazon Braket Hardware Providers.

IonQ

IonQ offers a gate-based QPU based on ion trap technology. IonQ’s trapped ion QPUs are built on a chain of trapped 171Yb+ ions that are spatially confined by means of a microfabricated surface electrode trap within a vacuum chamber.

The IonQ device supports the following quantum gates.

'x', 'y', 'z', 'rx', 'ry', 'rz', 'h', 'cnot', 's', 'si', 't', 'ti', 'v', 'vi', 'xx', 'yy', 'zz', 'swap'

With verbatim compilation, the IonQ device supports the following native gates.

'gpi', 'gpi2', 'ms'

These native gates can only be used with verbatim compilation. To learn more about verbatim compilation, see Verbatim Compilation.

Rigetti

Rigetti quantum processors are universal, gate-model machines based on all-tunable superconducting qubits. The 79-qubit Aspen-M-3 device leverages their proprietary multi-chip technology and is assembled from 2 40-qubit processors. The same applies for the 80-qubit Aspen-M-2 device.

The Rigetti devices support the following quantum gates.

'cz', 'xy', 'ccnot', 'cnot', 'cphaseshift', 'cphaseshift00', 'cphaseshift01', 'cphaseshift10', 'cswap', 'h', 'i', 'iswap', 'phaseshift', 'pswap', 'rx', 'ry', 'rz', 's', 'si', 'swap', 't', 'ti', 'x', 'y', 'z'

With verbatim compilation, the Rigetti devices support the following native gates.

'rx', 'rz', 'cz', 'cphaseshift', 'xy'

Rigetti superconducting quantum processors can run the 'rx' gate with only the angles of ±π/2 or ±π.

Pulse-level control is available on the Rigetti devices, which support a set of predefined frames of the following types:

'rf', 'rf_f12', 'ro_rx', 'ro_rx', 'cz', 'cphase', 'xy'

For more information about these frames, see Roles of frames and ports.

Oxford Quantum Circuits (OQC)

OQC quantum processors are universal, gate-model machines, built using scalable Coaxmon technology. The OQC Lucy system is an 8-qubit device with the topology of a ring in which each qubit is connected to its two nearest neighbors.

The Lucy device supports the following quantum gates.

'ccnot', 'cnot', 'cphaseshift', 'cswap', 'cy', 'cz', 'h', 'i', 'phaseshift', 'rx', 'ry', 'rz', 's', 'si', 'swap', 't', 'ti', 'v', 'vi', 'x', 'y', 'z', 'ecr'

With verbatim compilation, the OQC device supports the following native gates.

'i', 'rz', 'v', 'x', 'ecr'

Pulse-level control is available on the OQC devices. The OQC devices support a set of predefined frames of the following types:

'drive', 'second_state', 'measure', 'acquire', 'cross_resonance', 'cross_resonance_cancellation'

OQC devices support dynamic declaration of frames provided that you supply a valid port identifier. For more information about these frames and ports, see Roles of frames and ports.

Note

When using pulse control with OQC, the length of your programs cannot exceed a maximum of 90 microseconds. The maximum duration is approximately 50 nanoseconds for single-qubit gates and 1 microsecond for two-qubit gates. These numbers may vary depending on the qubits used, the device’s current calibration, and the circuit compilation.

QuEra

QuEra offers neutral-atom based devices that can run Analog Hamiltonian Simulation (AHS) tasks. These special-purpose devices faithfully reproduce the time-dependent quantum dynamics of hundreds of simultaneously interacting qubits.

One can program these devices in the paradigm of Analog Hamiltonian Simulation by prescribing the layout of the qubit register and the temporal and spatial dependence of the manipulating fields. Amazon Braket provides utilities to construct such programs via the AHS module of the python SDK, braket.ahs.

For more information, see the Analog Hamiltonian Simulation example notebooks or the Submit an analog program using QuEra’s Aquila page.

Xanadu

Xanadu builds photonic quantum computers that use continuous variables for quantum computing known as qumodes instead of traditional two-level systems or qubits. In the case of the Borealis QPU, each qumode represents the quantized electromagnetic field of a laser pulse traveling through the device. Gates between two qumodes are implemented by interfering two temporally separated qumodes via programmable beam splitters and delay lines. Instead of the usual one- and two-qubit gates, such as Hadamard or CNOT, continuous variable quantum computing uses gates such as rotation, displacement, beam-splitting, and squeezing.

Xanadu’s photonic quantum computer Borealis is not a universal machine, capable of arbitrary quantum computation, but instead implements a specific protocol known as Gaussian boson sampling (GBS). GBS is a model of photonic quantum computation first introduced by Hamilton et al. that consists of multi-mode linear optical operations followed by photon-counting measurements. The Borealis device implements GBS with 216 temporally-spaced qumodes. Amazon Braket offers access to Borealis via the open-source Strawberry Fields library for photonic quantum computation.

For more information, see the Borealis example notebook

Local state vector simulator (braket_sv)

The local state vector simulator (braket_sv) is part of the Amazon Braket SDK that runs locally in your environment. It is well-suited for rapid prototyping on small circuits (up to 25 qubits) depending on the hardware specifications of your Braket notebook instance or your local environment.

The local simulator supports all gates in the Amazon Braket SDK, but QPU devices support a smaller subset. You can find the supported gates of a device in the device properties.

Note

The local simulator supports advanced OpenQASM features which may not be supported on QPU devices or other simulators. For more information on supported features, see the examples provided in the OpenQASM Local Simulator notebook.

For more information about how to work with simulators, see the Amazon Braket examples.

Local density matrix simulator (braket_dm)

The local density matrix simulator (braket_dm) is part of the Amazon Braket SDK that runs locally in your environment. It is well-suited for rapid prototyping on small circuits with noise (up to 12 qubits) depending on the hardware specifications of your Braket notebook instance or your local environment.

You can build common noisy circuits from the ground up using gate noise operations such as bit-flip and depolarizing error. You can also apply noise operations to specific qubits and gates of existing circuits that are intended to run both with and without noise.

The braket_dm local simulator can provide the following results, given the specified number of shots:

• Reduced density matrix: Shots = 0

Note

The local simulator supports advanced OpenQASM features, which may not be supported on QPU devices or other simulators. For more information about supported features, see the examples provided in the OpenQASM Local Simulator notebook.

To learn more about the local density matrix simulator, see the Braket introductory noise simulator example.

Local AHS simulator (braket_ahs)

The local AHS (Analog Hamiltonian Simulation) simulator (braket_ahs) is part of the Amazon Braket SDK that runs locally in your environment. It can be used to simulate results from an AHS program. It is well-suited for prototyping on small registers (up to 10-12 atoms) depending on the hardware specifications of your Braket notebook instance or your local environment.

The local simulator supports AHS programs with one uniform driving field, one (non-uniform) shifting field, and arbitrary atom arrangements. For details, please refer to the Braket AHS class and the Braket AHS program schema.

To learn more about the local AHS simulator, see the Hello AHS: Run your first Analog Hamiltonian Simulation page and the Analog Hamiltonian Simulation example notebooks.

State vector simulator (SV1)

SV1 is an on-demand, high-performance, universal state vector simulator. It can simulate circuits of up to 34 qubits. You can expect a 34-qubit, dense, and square circuit (circuit depth = 34) to take approximately 1–2 hours to complete, depending on the type of gates used and other factors. Circuits with all-to-all gates are well suited for SV1. It returns results in forms such as a full state vector or an array of amplitudes.

SV1 has a maximum runtime of 6 hours. It has a default of 35 concurrent tasks, and a maximum of 100 (50 in us-west-1 and eu-west-2) concurrent tasks.

SV1 results

SV1 can provide the following results, given the specified number of shots:

• Sample: Shots > 0

• Expectation: Shots >= 0

• Variance: Shots >= 0

• Probability: Shots > 0

• Amplitude: Shots = 0

• Adjoint Gradient: Shots = 0

For more about results, see Result types.

SV1 is always available, it runs your circuits on demand, and it can run multiple circuits in parallel. The runtime scales linearly with the number of operations and exponentially with the number of qubits. The number of shots has a small impact on the runtime. To learn more, visit Compare simulators.

Simulators support all gates in the Braket SDK, but QPU devices support a smaller subset. You can find the supported gates of a device in the device properties.

Density matrix simulator (DM1)

DM1 is an on-demand, high-performance, density matrix simulator. It can simulate circuits of up to 17 qubits.

DM1 has a maximum runtime of 6 hours, a default of 35 concurrent tasks, and a maximum of 50 concurrent tasks.

DM1 results

DM1 can provide the following results, given the specified number of shots:

• Sample: Shots > 0

• Expectation: Shots >= 0

• Variance: Shots >= 0

• Probability: Shots > 0

• Reduced density matrix: Shots = 0, up to max 8 qubits

For more information about results, see Result types.

DM1 is always available, it runs your circuits on demand, and it can run multiple circuits in parallel. The runtime scales linearly with the number of operations and exponentially with the number of qubits. The number of shots has a small impact on the runtime. To learn more, see Compare simulators.

Noise gates and limitations

AmplitudeDamping
    Probability has to be within [0,1]
BitFlip
    Probability has to be within [0,0.5]
Depolarizing
    Probability has to be within [0,0.75]
GeneralizedAmplitudeDamping
    Probability has to be within [0,1]
PauliChannel
    The sum of the probabilities has to be within [0,1]
Kraus
    At most 2 qubits
    At most 4 (16) Kraus matrices for 1 (2) qubit
PhaseDamping
    Probability has to be within [0,1]
PhaseFlip
    Probability has to be within [0,0.5]
TwoQubitDephasing
    Probability has to be within [0,0.75]
TwoQubitDepolarizing
    Probability has to be within [0,0.9375]

Tensor network simulator (TN1)

TN1 is an on-demand, high-performance, tensor network simulator. TN1 can simulate certain circuit types with up to 50 qubits and a circuit depth of 1,000 or smaller. TN1 is particularly powerful for sparse circuits, circuits with local gates, and other circuits with special structure, such as quantum Fourier transform (QFT) circuits. TN1 operates in two phases. First, the rehearsal phase attempts to identify an efficient computational path for your circuit, so TN1 can estimate the runtime of the next stage, which is called the contraction phase. If the estimated contraction time exceeds the TN1 simulation runtime limit, TN1 does not attempt contraction.

TN1 has a runtime limit of 6 hours. It is limited to a maximum of 10 (5 in eu-west-2) concurrent tasks.

TN1 results

The contraction phase consists of a series of matrix multiplications. The series of multiplications continues until a result is reached or until it is determined that a result cannot be reached.

Note: Shots must be > 0.

Result types include:

• Sample

• Expectation

• Variance

For more about results, see Result types.

TN1 is always available, it runs your circuits on demand, and it can run multiple circuits in parallel. To learn more, see Compare simulators.

Simulators support all gates in the Braket SDK, but QPU devices support a smaller subset. You can find the supported gates of a device in the device properties.

Visit the Amazon Braket GitHub repository for a TN1 example notebook to help you get started with TN1.

Best practices for working with TN1

• Avoid all-to-all circuits.

• Test a new circuit or class of circuits with a small number of shots, to learn the circuit’s "hardness" for TN1.

• Split large shot simulations over multiple tasks.

Embedded simulators

Embedded simulators work by having the simulation embedded with the algorithm code in the same container and executing the simulation on the job instance directly. This can be useful for removing bottlenecks associated with having the simulation communicate with a remote device. This can result in significantly lower memory usage, reduced number of circuit executions to achieve a desired result, and an improved performance of ten times or more. For more information about embedded simulators, see the Run a job with Amazon Braket Hybrid Jobs page.

PennyLane’s lightning simulators

You can use PennyLane’s lightning simulators as embedded simulators on Braket. With PennyLane’s lightning simulators, you can leverage advanced gradient computation methods, such as adjoint differentiation, to evaluate gradients faster. The lightning.qubit simulator is available as a device via Braket NBIs and as an embedded simulator, whereas the lightning.gpu simulator needs to be run as an embedded simulator with a GPU instance. See the Embedded simulators in Braket Jobs notebook for an example of using lightning.gpu.

Compare simulators

This section helps you select the Amazon Braket simulator that’s best suited for your task, by describing some concepts, limitations, and use cases.

Choosing between local simulators and on-demand simulators (SV1, TN1, DM1)

The performance of local simulators depends on the hardware that hosts the local environment, such as a Braket notebook instance, used to run your simulator. On-demand simulators run in the AWS cloud and are designed to scale beyond typical local environments. On-demand simulators are optimized for larger circuits, but add some latency overhead per task or batch of tasks. This can imply a trade-off if many tasks are involved. Given these general performance characteristics, the following guidance can help you choose how to run simulations, including ones with noise.

For simulations:

• When employing fewer than 18 qubits, use a local simulator.

• When employing 18–24 qubits, choose a simulator based on the workload.

• When employing more than 24 qubits, use an on-demand simulator.

For noise simulations:

• When employing fewer than 9 qubits, use a local simulator.

• When employing 9–12 qubits, choose a simulator based on the workload.

• When employing more than 12 qubits, use DM1.

What is a state vector simulator?

SV1 is a universal state vector simulator. It stores the full wave function of the quantum state and sequentially applies gate operations to the state. It stores all possibilities, even the extremely unlikely ones. The SV1 simulator’s run time for a task increases linearly with the number of gates in the circuit.

What is a density matrix simulator?

DM1 simulates quantum circuits with noise. It stores the full density matrix of the system and sequentially applies the gates and noise operations of the circuit. The final density matrix contains complete information about the quantum state after the circuit runs. The runtime generally scales linearly with the number of operations and exponentially with the number of qubits.

What is a tensor network simulator?

TN1 encodes quantum circuits into a structured graph.

• The nodes of the graph consist of quantum gates, or qubits.

• The edges of the graph represent connections between gates.

As a result of this structure, TN1 can find simulated solutions for relatively large and complex quantum circuits.

TN1 requires two phases

Typically, TN1 operates in a two-phase approach to simulating quantum computation.

• The rehearsal phase: In this phase, TN1 comes up with a way to traverse the graph in an efficient manner, which involves visiting every node so that you can obtain the measurement you desire. As a customer, you do not see this phase because TN1 performs both phases together for you. It completes the first phase and determines whether to perform the second phase on its own based on practical constraints. You have no input into that decision after the simulation has begun.

• The contraction phase: This phase is analogous to the execution phase of a computation in a classical computer. The phase consists of a series of matrix multiplications. The order of these multiplications has a great effect on the difficulty of the computation. Therefore, the rehearsal phase is accomplished first in order to find the most effective computation paths across the graph. After it finds the contraction path during the rehearsal phase, TN1 contracts together the gates of your circuit to produce the results of the simulation.

TN1 graphs are analogous to a map

Metaphorically, you can compare the underlying TN1 graph to the streets of a city. In a city with a planned grid, it is easy to find a route to your destination using a map. In a city with unplanned streets, duplicate street names, and so forth, it can be difficult to find a route to your destination by looking at a map.

If TN1 did not perform the rehearsal phase, it would be like walking around the streets of the city to find your destination, instead of looking at a map first. It can really pay off in terms of walking time to spend more time looking at the map. Similarly, the rehearsal phase provides valuable information.

You might say that the TN1 has a certain “awareness” of the structure of the underlying circuit that it traverses. It gains this awareness during the rehearsal phase.

Types of problems best suited for each of these types of simulators

SV1 is well-suited for any class of problems that rely primarily on having a certain number of qubits and gates. Generally, the time required grows linearly with the number of gates, while it does not depend on the number of shots. SV1 is generally faster than TN1 for circuits under 28 qubits.

SV1 can be slower for higher qubit numbers because it actually simulates all possibilities, even the extremely unlikely ones. It has no way to determine which outcomes are likely. Thus, for a 30-qubit evaluation, SV1 must calculate 2^30 configurations. The limit of 34 qubits for the Amazon Braket SV1 simulator is a practical constraint due to memory and storage limitations. You can think of it like this: Each time you add a qubit to SV1, the problem becomes twice as hard.

For many classes of problems, TN1 can evaluate much larger circuits in realistic time than SV1 because TN1 takes advantage of the structure of the graph. It essentially tracks the evolution of solutions from its starting place and it retains only the configurations that contribute to an efficient traversal. Put another way, it saves the configurations to create an ordering of matrix multiplication that results in a simpler evaluation process.

For TN1, the number of qubits and gates matters, but the structure of the graph matters a lot more. For example, TN1 is very good at evaluating circuits (graphs) in which the gates are short-range (that is, each qubit is connected by gates only to its nearest neighbour qubits), and circuits (graphs) in which the connections (or gates) have similar range. A typical range for TN1 is having each qubit talk only to other qubits that are 5 qubits away. If most of the structure can be decomposed into simpler relationships such as these, which can be represented in more, smaller, or more uniform matrices, TN1 performs the evaluation easily.

Limitations of TN1

TN1 can be slower than SV1 depending on the graph’s structural complexity. For certain graphs, TN1 terminates the simulation after the rehearsal stage, and shows a status of FAILED, for either of these two reasons:

• Cannot find a path — If the graph is too complex, it is too difficult to find a good traversal path and the simulator gives up on the computation. TN1 cannot perform the contraction. You may see an error message similar to this one: No viable contraction path found.

• Contraction stage is too difficult — In some graphs, TN1 can find a traversal path, but it is very long and extremely time-consuming to evaluate. In this case, the contraction is so expensive that the cost would be prohibitive and instead, TN1 exits after the rehearsal phase. You may see an error message similar to this one: Predicted runtime based on best contraction path found exceeds TN1 limit.

Note

You are billed for the rehearsal stage of TN1 even if contraction is not performed and you see a FAILED status.

The predicted runtime also depends on the shot count. In worst-case scenarios, TN1 contraction time depends linearly on the shot count. The circuit may be contractable with fewer shots. For example, you might submit a task with 100 shots, which TN1 decides is uncontractable, but if you resubmit with only 10, the contraction proceeds. In this situation, to attain 100 samples, you could submit 10 tasks of 10 shots for the same circuit and combine the results in the end.

As a best practice, we recommend that you always test your circuit or circuit class with a few shots (for example, 10) to find out how hard your circuit is for TN1, before you proceed with a higher number of shots.

Note

The series of multiplications that forms the contraction phase begins with small, NxN matrices. For example, a 2-qubit gate requires a 4x4 matrix. The intermediate matrices required during a contraction that is adjudged to be too difficult are gigantic. Such a computation would require days to complete. That’s why Amazon Braket does not attempt extremely complex contractions.

Concurrency

All Braket simulators give you the ability to run multiple circuits concurrently. Concurrency limits vary by simulator and region. For more information on concurrency limits, see the Quotas page.