AWS Quantum Technologies Blog
Managing the cost of your experiments in Amazon Braket
Estimating the usage and cost of experiments is a key requirement for customers interacting with Amazon Braket. Customers want to have a way to track cost and usage as their algorithms run, especially for complex problems that require multiple cycles to yield a satisfactory result. Furthermore, given the wide variety of on-demand simulators and quantum hardware available on Amazon Braket, it is even more important that customers are able to track, predict and compare costs across devices. With that goal in mind, we aim to give customers every option to do these calculations with minimum effort, make it easy to choose the most cost-effective platform, and assist them to better manage their budget.
In this blog post, we introduce the new Braket Cost Tracker to help manage your Amazon Braket costs in near-real time, and cover other cost management tools that are available from AWS. Starting with a pricing overview, we provide examples and different options to help control your spend before, during, and after running your quantum workloads. After reading this post, you will be able to predict, monitor, limit, and report the spend associated with your Amazon Braket usage. For readers that are already familiar with Braket pricing, you can jump to the overview of cost tracking tools here.
Amazon Braket pricing structure
Amazon Braket provides access to quantum computers, quantum circuit simulators, fully managed execution of hybrid quantum-classical algorithms, and a Jupyter notebook development environment. We cover the first three here; for pricing of Jupyter notebooks refer to the Amazon SageMaker pricing page.
First, let’s review the costs associated with accessing quantum computers via Braket. When using a quantum processing unit (QPU), there are two main pricing components to consider: a per-task fee and a per-shot fee.
A shot is a single execution of a quantum circuit on a QPU. On a gate-based QPU from IonQ, Oxford Quantum Circuits (OQC), or Rigetti, a shot is a single circuit execution and measurement. When you use a D-Wave quantum annealer, a shot is the gathering of one result sample of a quantum annealing problem. Lastly, for the Xanadu Gaussian boson sampling device, a shot is the individual execution of a time-domain circuit. Note that the per-shot pricing depends on the type of QPU used; this is not affected by the number or type of gates used, or the number of variables used. The pricing documentation page shows up-to-date information of the per-shot price for each QPU.
A task is a logical grouping of shots. It is the sequence of repeated shots based on the same circuit design or annealing problem. You define how many shots you want included in a task when you submit the task to Amazon Braket. Currently, per-task pricing is the same across all QPUs and regions.
Let’s illustrate these concepts with an example: A researcher runs a quantum annealing problem on the D-Wave Advantage quantum computer in the AWS US West (Oregon) Region. This task includes 10,000 result samples of the same annealing problem. In order to compare results, the researcher runs this experiment four times with different parameters each time. The cost to run each of the four tasks includes a per-task charge, plus 10,000 shots at a per-shot fee. As such, the total charges for this experiment will be:
In contrast to this model, the pricing of on-demand quantum circuit simulators only depends on the task execution duration. Amazon Braket offers three different on-demand simulators: the state vector simulator (SV1), the tensor network simulator (TN1), and the density matrix simulator (DM1). The number of gates, qubits, and operations, as well as the graph structure and concurrency, have different impact on the task runtime, but are not used directly to determine the task cost, which is solely measured based on its duration. The pricing documentation page shows up-to-date information for each simulator.
Let’s consider another example: A developer uses the Amazon Braket SDK to design a quantum circuit with 30 qubits, and then runs a simulation of that circuit using the Amazon Braket on-demand simulator SV1 in the AWS US East (N. Virginia) region. The simulation task takes 15 minutes, and is repeated four times with a different number of shots each time. The total cost of this workload is calculated per-minute, with a minimum billing duration of three seconds, at the on-demand price:
Note that the same workload would be covered at no cost by the AWS Free Tier, which provides one hour of simulation time per month for the first 12 months of your Braket usage.
A third way of running experiments is via a hybrid job: Amazon Braket Hybrid Jobs provides fully managed execution of hybrid quantum-classical algorithms, combining AWS classical compute resources based on Amazon Elastic Compute Cloud (the ‘job instance’) with Amazon Braket QPUs or quantum circuit simulators. This feature can speed up the execution of hybrid algorithms by supporting on-demand, priority access to QPUs on Braket.
There are two components that determine the cost of using the Hybrid Jobs feature: use of classical resources and use of quantum computers or quantum circuit simulators.
With Hybrid Jobs, you are charged for the job instance based on instance type, and the execution of the quantum task on the hardware or simulator you chose. By default, the Hybrid Jobs feature uses the ml.m5.large instance, but you can choose a different instance type during job creation. You also have the option to add extra data storage within the job instance at an additional cost. For pricing of different instance types and supplementary instance storage, please refer to the “Job Instances” pricing table on the Hybrid Jobs tab in the Amazon Braket pricing page. Your use of QPUs and simulators during a hybrid job is priced in the same way as standalone tasks.
To see how this works, consider this example: A scientist runs a variational algorithm that uses parameterized quantum circuits to minimize a loss function, using gradient descent to iteratively adjust the circuit parameters. She runs this algorithm on the Rigetti Aspen-M QPU using Amazon Braket Hybrid Jobs in the AWS US West (N. California) Region. This hybrid job needs two tasks running for each of 50 iterations to converge, with 100 shots each. The scientist also uses an ml.p3.8xlarge job instance to orchestrate the classic portion of the workload and adjust parameters on each iteration for the entire duration of the experiment, which takes 26 minutes to complete. The charges for this workload are as follows:
An overview of AWS and Amazon Braket cost tracking and budgeting tools
Near real-time cost tracking: Amazon Braket Cost Tracker
Certain quantum algorithms can be complex, and predicting their cost in advance is sometimes not straightforward. For example, the number of tasks that an annealing problem needs depends on the size of the embedded graph, and the running time of a QML hybrid algorithm depends on the number of iterations required to converge. Recently, we launched the Amazon Braket Cost Tracker, a utility that is now part of the Braket SDK and allows customers to estimate in near real-time the maximum cost for their quantum workloads.
The new Braket Cost Tracker focuses on your use of quantum resources by giving you the option to add a single line of code that tracks resources associated to your algorithm, returning the estimated cost for QPU tasks and shots, as well as the cost of simulator tasks based on their duration.
To use this feature, you first initialize the Tracker()
object and then define and run your algorithm as usual. This object tracks resources inside an execution context: this can span an entire notebook, or be scoped to a specific iteration within a variational algorithm. The Cost Tracker provides several methods that can be used to track usage and simplify cost-control logic. You can find them in the Braket SDK documentation.
Let’s see the Cost Tracker in action. The following example builds a Bell state circuit and runs it on the SV1 simulator. We begin by importing the Braket SDK libraries, defining a Bell state, and instantiating the Tracker()
object to track the quantum tasks created. When calling the statistics and cost methods, they return the number of shots sent, tasks completed with their status, the execution duration, the billed execution duration, and the maximum cost in US dollars. The execution duration may vary on each simulation.
# Import any required modules
from braket.aws import AwsDevice
from braket.circuits import Circuit
from braket.tracking import Tracker
from braket.annealing import Problem,ProblemType
# Create Bell state and initialize tracking
circ = Circuit().h(0).cnot(0,1)
device = AwsDevice("arn:aws:braket:::device/quantum-simulator/amazon/sv1")
with Tracker() as tracker:
task = device.run(circ, shots=100).result()
# Your results
print(task.measurement_counts)
# Print tracker results
print(f"Task statistics: {tracker.quantum_tasks_statistics()}")
print(f"Estimated cost to run this example: {tracker.simulator_tasks_cost():.5f} USD")
Output:
Counter({'11': 51, '00': 49})
Task statistics: {
'arn:aws:braket:::device/quantum-simulator/amazon/sv1': {
'shots': 100,
'tasks': {'COMPLETED': 1},
'execution_duration': datetime.timedelta(microseconds = 64000),
'billed_execution_duration': datetime.timedelta(seconds = 3)}}
Estimated cost to run this example: 0.00375 USD
As seen here, the execution duration is 0.064 seconds, but the billed execution duration is three seconds: this is the minimum charge for a simulator task. Let’s now run the same circuit, but changing the device variable to point to a QPU instead: Rigetti Aspen-11 QPU. When calling the tracker statistics, there is no mention of running times, as only tasks and shots are considered when calculating the cost.
# Import any required modules
from braket.aws import AwsDevice
from braket.circuits import Circuit
from braket.tracking import Tracker
from braket.annealing import Problem,ProblemType
#create our bell circuit
circ = Circuit().h(0).cnot(0,1)
device = AwsDevice("arn:aws:braket:::device/qpu/rigetti/Aspen-11")
with Tracker() as tracker:
task = device.run(circ, shots=100).result()
#Your results
print(task.measurement_counts)
# Print tracker results
print(f"Task statistics: {tracker.quantum_tasks_statistics()}")
print(f"Estimated cost to run this example: {tracker.qpu_tasks_cost():.3f} USD")
Output:
Counter({'00': 42, '11': 33, '10': 14, '01': 11})
Task statistics: {
'arn:aws:braket:::device/qpu/rigetti/Aspen-11': {
'shots': 100,
'tasks': {'COMPLETED': 1}}}
Estimated cost to run this example: 0.335 USD
Using the Cost Tracker to add cost control logic
You can use the tracker for adding cost control logic for your experiments. For instance, you can set a maximum spend threshold for an experiment, determining how much you are willing to spend on a given workload. The following example maps a QUBO problem on the D-Wave Advantage System 6.1 and limits spending by stopping the execution of new tasks after the total cost exceeds the defined limit of $2.00. The tracker shows that the cost of one task and 1000 shots is $0.49, and we set the logic to iterate and print the cost until we breach the $2 threshold, which in this case is five runs. This gives you the flexibility to produce several results to compare against while keeping the cost close to the limit you specify.
# Import any required modules
from braket.aws import AwsDevice
from braket.annealing import Problem,ProblemType
from braket.tracking import Tracker
# Create your annealing problem
problem = Problem(ProblemType("QUBO"), {35: 1}, {(35, 36): -1})
device = AwsDevice("arn:aws:braket:us-west-2::device/qpu/d-wave/Advantage_system6")
with Tracker() as tracker:
while tracker.qpu_tasks_cost() <= 2:
result = device.run(problem, shots=1000).result()
# Print the cost of each iteration
print(f"Estimated cost: {tracker.qpu_tasks_cost():.2f} USD")
# Print final results
print(f"Task statistics: {tracker.quantum_tasks_statistics()}")
Output:
Estimated cost: 0.49 USD
Estimated cost: 0.98 USD
Estimated cost: 1.47 USD
Estimated cost: 1.96 USD
Estimated cost: 2.45 USD
Task statistics: {
'arn:aws:braket:us-west-2::device/qpu/d-wave/Advantage_system6': {
'shots': 5000,
'tasks': {'COMPLETED': 5}}}
In all the examples described so far, the tracker starts and stops within a circuit or annealing problem, but remember that you can choose to have the tracker function span an entire notebook, or be scoped to a specific iteration within a hybrid job: you define the execution context by calling the start
and stop
methods as you wish.
Programmatic access to pricing information: AWS Price List service API
While the Braket Cost Tracker is attached to an execution context and it updates itself with the task(s) state —keeping count of resources usage until stopped— sometimes it is also useful to make a discrete query to the current price of Braket components, programmatically. The AWS Price List service API is a convenient way to query up-to-date pricing information. It uses standardized product attributes that can be used to do budget calculations, estimate future workload costs, or reconcile billing data.
When used within Jupyter notebooks (or your own custom development environment), the API can provide guidance on the QPU tasks and shots price at any time within your code; or, if you know simulation execution time in advance, it can return the total cost estimation based on the per-minute price. The main difference with the Cost Tracker in the previous section is that the Price List Service API is not embedded in your workload logic unless you code it: this means that it does not update its value if a task is interrupted, added, changes its parameters, or runs for a different time than you anticipated (in the case of simulators).
To use the Price List Service API, you can call the GetServices
method with a service code to retrieve the attribute names for that service. After you set the service code to 'AmazonBraket,'
you can use GetAttributeValues
to see what values are available for an attribute; usagetype
is the attribute name that contains all the service information. With service code, attribute name, and its value, you can use GetProducts
to retrieve information about tasks, shots, and duration-based pricing per device and region, as well as job instance pricing.
To complete the review of programmatic access to pricing, it is worth mentioning that the Braket SDK comes with per-shot pricing information, embedded as a method in the device properties. You can find an example of a call to device.properties.service.deviceCost.price
at the bottom of this notebook.
A browser-based tool to run estimate costs: AWS Pricing Calculator
An alternative method for estimating costs is to use the AWS Pricing Calculator. It is a web-based planning tool that you can use to create estimates for your Amazon Braket experiments. You can use it to model your quantum workloads before building them, explore Braket price points, and review the calculations behind your estimates. You can use it to help you plan how you spend, find cost saving opportunities, and make informed decisions when using Amazon Braket. This is a useful tool if you are not familiar with AWS, since you don’t need any experience with the cloud or having an AWS account to use it.
In the screenshot example that follows, a principal investigator is planning the monthly budget that will be allocated to the quantum projects under her responsibility. After filtering by Amazon Braket and selecting a region, the investigator starts adding values in the relevant categories. As seen below, she estimates an average of 185 simulations running daily, distributed across local, state vector (SV1), tensor network (TN1) and noise simulators (DM1). Since simulator time is charged by the minute, she inputs the estimated average time that each simulation will take. Similarly, in the QPU section, the usage input is the estimated number of tasks and shots that are planned to run throughout the month. In this case, she provides a weekly input of 100 tasks with an average of 1000 shots per task. As displayed, the total monthly cost updates dynamically at the bottom of the screen, which allows the investigator to change values to fit a budget, or weight one type of workload over another.
After all of the inputs are entered, the investigator has access to an annual forecast overview based on inputs, ability to share the estimation with colleagues through a link, and export the report to CSV and PDF formats.
Visualize your workload cost over time: AWS Cost Explorer
Another graphical tool is the AWS Cost Explorer, that you can use to run reports, visualize costs, and export data related to your Amazon Braket usage for any given period, up to one year in the past. AWS Cost Explorer is included within the Cost Management section of the Management Console, and you can control who can access it by setting the right permissions.
As shown in the screenshot, you can filter by Service in the right-hand panel and select Braket. In the top panel you can select the timeframe for your report, and the granularity (monthly, daily, hourly). Finally, by choosing the Usage Type category in the Group by menu, you can visualize charges for QPU tasks and shots, and duration of simulations in a single report. As with AWS Pricing Calculator, reports produced can also be saved, shared, and exported to CSV format.
Receive alerts on your workload cost over time: AWS Budgets
To complete the list of pricing tools available, you can use AWS Budgets to set custom budgets that alert you when your costs or usage exceed your budgeted amount. This tool is also included within the Cost Management section of the Management Console. AWS Budgets is a great tool for administrators or financial controllers who just want to build custom budgets for Braket expenditure, compare them against actual spend, or gain more granular control over the usage of specific components.
In the example that follows, the account administrator for the Advanced Computing Department of a research institution wants to control the recurring spend on trapped-ion technology, for which the department sets a dedicated budget of $500 monthly. Firstly, the administrator sets up a new budget report that reports monthly against the planned cost:
Then, the budget is scoped by specific cost dimensions, in this case IonQ tasks and shots, which can be easily defined as filters. As seen in the screenshot, the tool allows for granular dimensionality, or a broader scope like the entire AWS usage if desired.
After this initial configuration, the monthly reports are automatically produced and available in the Management Console. If working in a monthly timeframe, AWS Budgets also allows customers to setup alerts that notify the administrator if the actual spend exceeded the monthly forecast.
Next Steps
In this blog, we provided an overview of the Amazon Braket pricing structure and reviewed key terminology: shots, tasks, simulation duration, duration for jobs instances, and optionally, managed notebook instance duration. We looked at various ways to track your costs in near-real time via the Braket Cost Tracker available with the Braket SDK, run estimations in advance using graphical and programmatic pricing tools, and produce summaries and reports with AWS Calculator, AWS Cost Explorer, and AWS Budgets. Each tool gives you a different perspective on the costs associated with your quantum computing workloads on AWS.
If you are an existing customer, you can launch a new notebook instance, or update your existing ones from the Github repository. The new Cost Tracker has been embedded throughout all sample Braket notebooks to add transparency and help you incorporate it in your existing workloads. Start using it today and let us know how it goes!