ClustersVLQ
Estimating Your Consumption on VLQ
How Time Is Accounted
The accounting runs in qpu seconds. Two components per shot, are accounted.
| Component | Cost per Shot |
|---|---|
| Circuit execution overhead | up to 50 µs (variable) |
| Circuit postprocessing overhead | approximately 350 µs (fixed) |
| Billed per shot | approximately 400 µs |
Key point: Only these two components count toward your consumption. Latency incurred while waiting for the job to start and return results is not billed.
What Is Not Accounted
Every job submission carries an overhead of 3 to 15 seconds of latency — overing queuing, job scheduling, and result retrieval. This is wall-clock time you will observe, but it does not appear in your consumption bill. Do not factor it into your usage estimate.
Estimating Your Consumption
Per-Shot Cost
Use 400 µs (0.4 ms) as your worst-case per-shot figure. For typical circuits that are shorter or simpler, your circuit component will be less than 50 µs, bringing the per-shot cost closer to 350 µs.
Formula
Total billed time = Total Number of shots × Cost per shot
Worst case: Total billed time (µs) = shots × 400
Typical case: Total billed time (µs) = shots × (350 + actual circuit time)Examples
| Shots | Circuit time | Billed time |
|---|---|---|
| 1,000 | 50 µs (max) | 400,000 µs = 0.4 s |
| 10,000 | 50 µs (max) | 4,000,000 µs = 4 s |
| 10,000 | 20 µs | 3,700,000 µs = 3.7 s |
Practical Tips
- Use worst-case (400 µs/shot) when budgeting — it gives you a safe upper bound.
- Expect 3–15 s of extra wall time per job submission regardless of shot count. Plan your experiment timing accordingly, but do not count this toward usage.
- Asynchroneous execution To minimize wall-clock time, submit multiple jobs asynchronously and let them queue in parallel. Once submitted, use
.wait_for_final_state()method to wait for completion, then retrieve all results together. This way the latency overhead of each job overlaps rather than stacking sequentially.
