Penggunaan beban kerja

Penggunaan adalah ukuran jumlah masa QPU dikunci untuk beban kerja anda, dan ia dikira secara berbeza, bergantung pada mod pelaksanaan yang anda gunakan.

• Penggunaan Session adalah masa jam dinding semasa sesi aktif. Lihat Tempoh sesi untuk maklumat lanjut tentang peralihan status sesi.
• Penggunaan Batch adalah jumlah masa kuantum (masa yang diambil oleh kompleks QPU untuk memproses kerja anda) bagi semua kerja dalam batch.
• Penggunaan kerja tunggal adalah masa kuantum yang digunakan kerja dalam pemprosesan.

Perlu diingat bahawa kerja yang gagal atau dibatalkan dikira dalam penggunaan anda dalam keadaan tertentu - lihat bahagian Kerja yang gagal dan dibatalkan untuk butiran.

Bagi pengguna pelan berbayar, penggunaan menentukan berapa banyak kos beban kerja. Lihat Urus kos untuk butiran.

Penggunaan untuk kerja yang gagal dan dibatalkan

Apabila kerja gagal atau dibatalkan, penggunaan yang dilaporkan adalah seperti berikut:

• Mod kerja atau batch: Penggunaan yang dilaporkan adalah masa QPU dikunci untuk melaksanakan beban kerja anda sehingga masa ia gagal atau dibatalkan. Oleh itu, jika kegagalan atau pembatalan berlaku sebelum penguncian, penggunaan yang dilaporkan adalah sifar. Jika tidak, penggunaan yang dilaporkan bagi beban kerja adalah jumlah penggunaan sebelum beban kerja gagal atau dibatalkan. Oleh itu, sesetengah kerja yang gagal tidak muncul dalam penggunaan yang dilaporkan anda dan sesetengahnya muncul.

• Mod sesi: Penggunaan yang dilaporkan adalah masa jam dinding semasa sesi aktif, tanpa mengira bilangan kerja yang gagal atau dibatalkan.

Tanya penggunaan sebenar beban kerja

Selepas beban kerja selesai, terdapat beberapa cara untuk melihat penggunaan sebenarnya:

• Jalankan batch.usage() atau session.usage() dalam qiskit-ibm-runtime 0.30 atau lebih baharu. Jika menggunakan versi lama qiskit-ibm-runtime (>= 0.23 dan < 0.30), penggunaan masih boleh didapati dalam session.details()["usage_time"] dan batch.details()["usage_time"].
• Gunakan GET /sessions/{id} untuk melihat penggunaan bagi batch atau sesi tertentu.
• Gunakan GET /jobs/{id} untuk melihat penggunaan bagi kerja tunggal.

Lihat penggunaan instans

Anda boleh melihat penggunaan instans pada halaman Instans, atau, bagi mereka yang mempunyai autoriti yang sesuai, halaman Analitik. Perlu diingat bahawa halaman tersebut mungkin menunjukkan nombor penggunaan yang berbeza kerana ia mengira penggunaan secara berbeza.

Halaman Instans menunjukkan penggunaan masa nyata untuk 28 hari lepas (bergulir), sehingga masa semasa pada hari semasa. Penggunaan halaman Analitik dikira semula setiap jam dan merangkumi 28 hari penuh terakhir; iaitu, ia menunjukkan penggunaan dari 00:00 28 hari lalu hingga hari ini, pada jam teratas.

Anggarkan penggunaan sebelum menghantar kerja

Walaupun mendapatkan anggaran setempat yang tepat adalah rumit kerana operasi tambahan yang dilakukan untuk penindasan dan mitigasi ralat, anda boleh menggunakan formula asas ini untuk mendapatkan anggaran penggunaan yang dianggarkan:

<overhead sestiap sub-kerja> + (rep_delay + <panjang litar>) * <bilangan pelaksanaan>

• <overhead sestiap sub-kerja> adalah overhead kira-kira 2 saat sestiap sub-kerja. Ini termasuk operasi seperti memuatkan muatan ke dalam elektronik kawalan. Kerja primitif anda mungkin dibahagikan kepada berbilang sub-kerja jika terlalu besar untuk diproses oleh enjin pelaksanaan sekaligus.
• rep_delay adalah pilihan yang boleh disesuaikan pengguna, dan lalainya diberikan oleh backend.default_rep_delay, iaitu 250 mikrosaat pada kebanyakan backend IBM Quantum. Perlu diingat bahawa mengurangkan rep_delay mengurangkan jumlah masa pelaksanaan QPU, tetapi dengan kos kadar ralat penyediaan keadaan yang meningkat; lihat panduan Pelaksanaan kadar pengulangan dinamik untuk maklumat lanjut.
• <panjang litar> adalah jumlah panjang arahan. Setiap arahan mengambil masa yang berbeza pada QPU, jadi jumlah panjang berbeza-beza dari litar ke litar. Pengukuran, contohnya, boleh mengambil masa 56 kali lebih lama daripada gate x. backend.target[<instruction>][<qubit>].duration boleh digunakan untuk mencari tempoh tepat bagi setiap arahan. Panjang litar biasa mungkin antara 50-100 mikrosaat. Jika anda menggunakan teknik penindasan atau mitigasi ralat dengan primitif, arahan tambahan mungkin dimasukkan ke dalam litar anda, yang akan meningkatkan jumlah panjang litar.
  nota

  Pilihan scheduler_timing eksperimen mengembalikan jumlah masa litar, tetapi ini BUKAN masa yang digunakan untuk pengebilan.

• <bilangan pelaksanaan> adalah jumlah bilangan litar darab bilangan shot, di mana litar adalah yang dijana selepas elemen PUB disiarkan.
  • Jika anda menggunakan teknik mitigasi ralat dengan primitif, litar tambahan mungkin dijalankan sebagai sebahagian daripada proses mitigasi, yang akan meningkatkan jumlah bilangan pelaksanaan. Selain itu, teknik mitigasi ralat lanjutan seperti PEA dan PEC datang dengan overhead yang jauh lebih tinggi kerana ia memerlukan menjalankan litar untuk pembelajaran hingar.
  • Estimator mengumpulkan boleh cerap yang berkomutat secara qubit-bijak, yang mengurangkan bilangan pelaksanaan.

Jika anda tidak menggunakan sebarang teknik mitigasi ralat lanjutan atau rep_delay tersuai, anda boleh menggunakan 2+0.00035*<bilangan pelaksanaan> sebagai formula pantas.

Langkah seterusnya

Cadangan

• Semak petua ini: Minimumkan masa jalankan kerja.
• Tetapkan Masa pelaksanaan maksimum.
• Pelajari cara mentranspil secara setempat dalam bahagian Transpil.
• Cuba panduan Bandingkan tetapan transpiler.