Penggunaan workload
Usage merepresentasikan konsumsi layanan Qiskit Runtime dan ditentukan oleh jumlah waktu QPU dikunci untuk mengeksekusi workload.
- Usage session diukur sebagai waktu yang berlalu selama session tetap aktif, karena kapasitas QPU dicadangkan selama durasi session, terlepas dari apakah workload sedang berjalan secara aktif atau tidak. Lihat Panjang session untuk informasi lebih lanjut tentang transisi status session.
- Usage batch diukur sebagai akumulasi waktu QPU dikunci untuk mengeksekusi semua job dalam batch.
- Usage single job diukur sebagai waktu QPU dikunci untuk mengeksekusi job.
Perlu dicatat bahwa job yang gagal atau dibatalkan tetap dihitung dalam usage kamu dalam kondisi tertentu — lihat bagian Job yang gagal dan dibatalkan untuk detailnya.
Untuk pengguna Pay-As-You-Go Plan, lihat Kelola biaya untuk detail tentang pengaturan batas biaya.
Usage untuk job yang gagal dan dibatalkan
Ketika sebuah job gagal atau dibatalkan, usage yang dilaporkan adalah sebagai berikut:
-
Mode job atau batch: Jika kegagalan atau pembatalan terjadi karena kesalahan sistem, usage yang dilaporkan adalah nol. Untuk job yang gagal karena kesalahan pengguna atau ketika pengguna membatalkan job, usage yang dilaporkan adalah konsumsi apa pun yang telah terjadi hingga titik tersebut, termasuk overhead yang terjadi untuk mempersiapkan QPU dalam menjalankan job.
-
Mode session: Usage yang dilaporkan adalah wall-clock time selama session aktif, terlepas dari berapa banyak job yang gagal atau dibatalkan.
Melihat usage aktual sebuah workload
Setelah workload selesai, ada beberapa cara untuk melihat usage aktualnya:
- Jalankan
batch.usage()atausession.usage()diqiskit-ibm-runtimeversi 0.30 atau lebih baru. Jika menggunakan versiqiskit-ibm-runtimeyang lebih lama (>= 0.23 dan < 0.30), usage masih bisa ditemukan disession.details()["usage_time"]danbatch.details()["usage_time"]. - Gunakan
GET /sessions/{id}untuk melihat usage untuk batch atau session tertentu. - Gunakan
GET /jobs/{id}untuk melihat usage untuk satu job.
Lihat usage instance
Kamu bisa melihat usage sebuah instance di halaman Instances, atau, bagi yang memiliki wewenang yang sesuai, halaman Analytics. Perlu diperhatikan bahwa kedua halaman mungkin menampilkan angka usage yang berbeda karena cara penghitungannya berbeda.
Halaman Instances menampilkan usage real-time untuk 28 hari terakhir (bergulir), hingga waktu saat ini pada hari ini. Usage halaman Analytics dihitung ulang setiap jam dan mencakup 28 hari penuh terakhir; yaitu, menampilkan usage dari 00:00 28 hari lalu hingga hari ini, pada awal jam.
Perkirakan usage sebelum mengirimkan job
Meskipun mendapatkan estimasi lokal yang akurat dipersulit oleh operasi tambahan yang dilakukan untuk error suppression dan mitigation, kamu bisa menggunakan rumus dasar ini untuk mendapatkan perkiraan estimasi usage:
<per sub-job overhead> + (rep_delay + <circuit length>) * <num executions>
<per sub-job overhead>adalah overhead sekitar 2 detik per sub-job. Ini mencakup operasi seperti memuat payload ke dalam elektronik kontrol. Job primitive kamu mungkin dibagi menjadi beberapa sub-job jika terlalu besar untuk diproses sekaligus oleh execution engine.rep_delayadalah opsi yang bisa dikustomisasi oleh pengguna, dan defaultnya diberikan olehbackend.default_rep_delay, yaitu 250 mikrodetik pada sebagian besar Backend IBM Quantum. Perlu diperhatikan bahwa menurunkanrep_delaymengurangi total waktu eksekusi QPU, tetapi dengan risiko meningkatnya error rate persiapan state; lihat panduan Dynamic repetition rate execution untuk informasi lebih lanjut.<circuit length>adalah total panjang instruksi. Setiap instruksi membutuhkan waktu yang berbeda di QPU, sehingga total panjangnya bervariasi dari Circuit ke Circuit. Pengukuran, misalnya, bisa memakan waktu 56 kali lebih lama daripada Gatex.backend.target[<instruction>][<qubit>].durationbisa digunakan untuk menemukan durasi tepat setiap instruksi. Panjang Circuit yang umum kemungkinan antara 50-100 mikrodetik. Jika kamu menggunakan teknik error suppression atau mitigation dengan primitive, instruksi tambahan mungkin disisipkan ke dalam Circuit kamu, yang akan meningkatkan total panjang Circuit.catatanOpsi eksperimental
scheduler_timingmengembalikan total waktu Circuit, tetapi ini BUKAN waktu yang digunakan untuk penagihan.<num executions>adalah total jumlah Circuit dikalikan jumlah shot, di mana Circuit adalah yang dihasilkan setelah elemen PUB disiarkan.- Jika kamu menggunakan teknik error mitigation dengan primitive, Circuit tambahan mungkin dijalankan sebagai bagian dari proses mitigation, yang akan meningkatkan total jumlah eksekusi. Selain itu, teknik error mitigation lanjutan seperti PEA dan PEC memiliki overhead yang jauh lebih tinggi karena memerlukan menjalankan Circuit untuk noise learning.
- Estimator mengelompokkan observable yang commuting secara qubit-wise, yang mengurangi jumlah eksekusi.
Jika kamu tidak menggunakan teknik error mitigation lanjutan atau rep_delay kustom, kamu bisa menggunakan 2+0.00035*<num executions> sebagai rumus cepat.
Perkirakan usage secara lokal dengan Qiskit
Contoh kode ini mendemonstrasikan cara menggunakan Qiskit untuk menghitung waktu circuit:
# Schedule the circuit to get more accurate timing
pm = generate_preset_pass_manager(
target=backend.target,
optimization_level=0,
scheduling_method="alap"
)
scheduled_circuits = pm.run(isa_circuits)
init_duration = backend.target["reset"][(0,)].duration
rep_delay = sampler.options.execution.rep_delay or backend.default_rep_delay
circuit_duration = 0
for circuit in scheduled_circuits:
# Estimate circuit length
circuit_duration += circuit.estimate_duration(backend.target)
# Add INIT time
if sampler.options.execution.init_qubits:
circuit_duration += init_duration
# Add rep_delay
circuit_duration += rep_delay
total_time = 2 + (circuit_duration*shots)
print(f"Total estimated usage is {math.ceil(total_time)} seconds")
Langkah selanjutnya
- Tinjau tips berikut: Minimalkan waktu berjalan job.
- Atur Waktu eksekusi maksimum.
- Pelajari cara transpile secara lokal di bagian Transpile.
- Coba panduan Bandingkan pengaturan Transpiler.