Job Costing

Note

Quantinuum Helios job submissions require a max cost specification. This specification is a hard quantitative limit on how much a user is willing to spend, and it is not necessarily a measure of the cost required to complete a job. The Helios syntax checkers can provide an estimate for the max cost of user program, but this is not an absolute upper bound. It is impossible to predict a max cost for arbitrary Guppy programs due to the halting problem.

Quantinuum Helios allows execution of programs with arbitrary control flow. This means each Hardware Quantum Credits (HQC) consumption per shot is non-uniform and dynamic to the circuit generated by the user program. As a consequence, the total HQC consumption is also dynamic and determined during runtime. Users are required to specify a maximum cost with each job submission. For a job submission with multiple programs, the maximum cost specification is per program. The maximum cost limits HQC consumption by terminating a job if the HQC consumed exceed this threshold.

The Nexus python client, qnexus, introduces a max_cost kwarg to enable user input of the maximum cost. The Helios syntax checkers return a prediction for the maximum cost of a supplied Helios program, and this prediction should guide the user’s choice of max_cost. The max cost of a Guppy program is estimated via the python call, nexus:qnx.hugr.cost().

HQC Cost Estimation

Note

HQC max cost estimation using the syntax checker is unreliable for non-deterministic programs. Any program that utilizes complex control flow and conditionality will require significant analysis to estimate a max cost.

The max cost estimate of a Guppy program can be estimated using the Helios syntax checker. This estimate becomes increasingly unreliable for non-deterministic programs utilizing complex control-flow and conditionality. The syntax checker performs a Selene simulation with the simple runtime and the coinflip simulator. The simulation accumulates metrics over 10-shots to estimate a “worst-case” cost and extrapolates to a user-specified number of shots via the HQC formula. The HQC formula consists of two components, a fixed cost and a variable cost,

(1)\[\textrm{HQC} = 5 + \frac{C}{5000} \left( \textrm{Max}( N_{1q}) + \textrm{Max}(N_{2q}) + \textrm{Max}(N_{M}) ) \right),\]

where the variable component consists of the following variables,

  • \(C\): Number of shots required to run the program on hardware;

  • \(\textrm{Max}( N_{1q})\): The maximum number of physical 1-qubit gates from a specific shot instance over the 10 shot simulation (\(R_z\) operations excluded), hence the number of \(R_{xy}\) (phased_x) gates;

  • \(\textrm{Max}(N_{2q})\) The maximum number of physical 2-qubit gates from a specific shot instance over the 10 shot simulation, hence the number of \(R_{zz}\) (zz_phase) gates;

  • \(\textrm{Max}(N_{M})\) The maximum number of measure (measure), leakage measurement (leaked_measure), resets (measure_and_reset) or initializations (maximum ion allocations) from a specific shot instance over the 10 shot simulation.

Confidence Interval

Note

Forthcoming via the syntax checker is a confidence on the cost estimation (float).

The confidence on the cost estimation is calculated using the Coefficient of Variation method and is normalized to 95%. Cost distribution from the 10 shot simulation is used to estimate the confidence interval (CI) using,

(2)\[\textrm{CI} = 95 \times \left( 1 - \frac{\sigma}{\mu} \right),\]

where \(\sigma\) and \(\mu\) correspond to the sample standard deviation and mean, respectively. The CI becomes increasingly unstable for non-deterministic programs. It is important to note that completely static programs have a CI of 95%. This an artifact of normalization. Static programs have a fixed HQC cost with zero variation.

Additional Details

Note

Each Nexus job can have many child programs. Each child program is an independent hardware job with a hardware job ID, in addition to the Nexus job ID.

Users can specify number of shots per child program. However the max cost specification is across all child programs. This is currently an issue for scenarios where 1 Nexus job consists of many child programs.

  1. Each Nexus job should consist of 1 program. There is a mismatch in the definition for max cost as specified by the user in Nexus and the internal Helios system. Nexus assumes the max cost is across all the child programs in a Nexus job. The Helios system assumes the max cost is per child program.

  2. The max cost specified by the user is subtracted from the user’s HQC allocations. If the max cost specification exceeds the user’s HQC allocations, the Nexus job will subsequently enter a FAILED state.

  3. Due to the misalignment between max cost behaviour between Nexus and the Helios system, the max cost specified by the user is subtracted from the user’s HQC allocations on a per program basis. This means the Nexus job can enter a FAILED state if any of the child programs also enters a FAILED state.

  4. After the child program in a Nexus job starts running on the machine, if the HQC cost accrued by the program exceeds the max cost specification then the child program will enter a DEPLETED state.

Note

Quantinuum will introduce a user-specifiable mechanism to resume DEPLETED jobs.

Dynamic Programs

A dynamic program contains multiple branches leading to varying HQC consumption across shots. The table below shows the sequence length (number of gates) and HQC consumption for a Repeat Until Success protocol. Each shot runs 10 iterations. Each iteration contains nested conditional blocks. As a result, the sequence length of the circuit is dynamic to branches selected during hardware execution. The program can generate up to 3 different circuits. The cost per circuit is calculated using Quantinuum’s HQC formula.

The Guppy program is compiled to a Heirarchical Unified Graph Representation (HUGR), before upload to the Nexus database. This results in a local instance of a HUGRRef, a reference to the uploaded HUGR. This reference must be used to query for the maximum cost estimate from the syntax checker.

r"""Approximate Rz(Arctan(2)) using Repeat Until Success Protocol"""

import math

from guppylang import guppy
from guppylang.std.builtins import result, owned, comptime, panic
from guppylang.std.angles import angle
from guppylang.std.quantum import qubit, measure, t, h, z, cx, rz, discard

N = 10

@guppy
def compute_arctan() -> float:
    return comptime(math.atan(2.0)/math.pi)


@guppy
def part1(
    auxiliary: qubit @ owned,
    resource: qubit
) -> bool:
    h(auxiliary)
    t(auxiliary)
    h(resource)
    cx(resource, auxiliary)
    t(auxiliary)
    h(auxiliary)
    result1 = measure(auxiliary)
    return result1


@guppy
def part2(
    resource: qubit @ owned,
    target: qubit
) -> bool:
    h(target)
    t(target)
    z(target)
    cx(target, resource)
    t(resource)
    h(resource)
    result2 = measure(resource)
    return result2


@guppy
def part3(target: qubit @ owned) -> bool:
    arctan2 = angle(compute_arctan())
    rz(target, arctan2)
    h(target)
    result3 = measure(target)
    return result3


@guppy
def main() -> None:
    for _ in range(comptime(N)):
        auxiliary = qubit()
        resource = qubit()

        result1 = part1(auxiliary, resource)
        result("result1", result1)
        if not result1:
            target = qubit()
            result2 = part2(resource, target)
            result("result2", result2)
            if not result2:
                result3 = part3(target)
                result("result3", result3)
            else:
                discard(target)
        else:
            discard(resource)

hugr_binary = main.compile()

The HUGR binary is uploaded to the Nexus database with a name including a unique suffix.

import qnexus as qnx
import uuid

unique_suffix = uuid.uuid1()

project = qnx.projects.get_or_create("Helios-Samples")
qnx.context.set_active_project(project)

ref_hugr = qnx.hugr.upload(
    hugr_binary, 
    name=f"repeat-until-success-{unique_suffix}"
)

Maximum Cost Prediction

The Helios syntax checker provides a prediction for the max cost of a Guppy program. The qnexus function, qnexus.hugr.cost() queries the Helios-1SC syntax checker for the max cost prediction. The function requires the HUGR reference and the number of shots to be passed as keyword arguments.

cost_confidence = qnx.hugr.cost_confidence(
    programs=[ref_hugr, ref_hugr, ref_hugr], 
    n_shots=[10, 20, 30]
)

for estimate, confidence in cost_confidence:
    print(f"Max Cost Prediction: {estimate} HQC, Confidence Interval: {confidence:.2f}")

Max Cost Prediction: 6.098 HQC, Confidence Interval: 84.00
Max Cost Prediction: 7.196 HQC, Confidence Interval: 84.00
Max Cost Prediction: 8.294 HQC, Confidence Interval: 84.00

Job Submission

The job submission workflow uses the start_execute_job() which requires the max_cost kwarg. If HQC consumption across all shots exceeds specified max cost, the program is terminated.

QuantinuumConfig accepts the maximum shot prediction for the syntax checker result, and the instance is supplied to the execute job submission function.

import numpy as np

config =  qnx.models.HeliosConfig(
    device_name="Helios-1E",
)

result_ref = qnx.start_execute_job(
    programs=[ref_hugr, ref_hugr, ref_hugr],
    n_shots=[10, 20, 30],
    max_cost=[e for e, _ in cost_confidence],
    backend_config=config,
    name=f"Helios-Emulator-{unique_suffix}"
)

qnx.jobs.wait_for(result_ref)
job_result = qnx.jobs.results(result_ref)[0].download_result()

print(job_result)