ข้ามไปยังเนื้อหาหลัก

การใช้งาน Workload

Usage คือการวัดปริมาณเวลาที่ QPU ถูกล็อกสำหรับ workload ของคุณ และคำนวณแตกต่างกันขึ้นอยู่กับ execution mode ที่คุณใช้

  • Session usage คือเวลาตาม wall-clock ที่ session ทำงาน ดู ความยาวของ Session สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการเปลี่ยนสถานะของ session
  • Batch usage คือผลรวมของ quantum time (เวลาที่ QPU complex ใช้ในการประมวลผล job ของคุณ) ของ job ทั้งหมดใน batch
  • Single job usage คือ quantum time ที่ job ใช้ในการประมวลผล

โปรดทราบว่า job ที่ล้มเหลวหรือถูกยกเลิกนับรวมใน usage ของคุณในบางกรณี ดูส่วน Job ที่ล้มเหลวและถูกยกเลิก สำหรับรายละเอียด

สำหรับผู้ใช้แผนแบบเสียเงิน usage กำหนดต้นทุนของ workload ดู จัดการค่าใช้จ่าย สำหรับรายละเอียด

Usage สำหรับ job ที่ล้มเหลวและถูกยกเลิก​

เมื่อ job ล้มเหลวหรือถูกยกเลิก usage ที่รายงานเป็นดังนี้:

  • โหมด Job หรือ Batch: usage ที่รายงานคือเวลาที่ QPU ถูกล็อกสำหรับการรัน workload ของคุณจนถึงเวลาที่ล้มเหลวหรือถูกยกเลิก ดังนั้น หากการล้มเหลวหรือการยกเลิกเกิดขึ้นก่อนการล็อก usage ที่รายงานจะเป็นศูนย์ มิฉะนั้น usage ที่รายงานของ workload คือปริมาณ usage ก่อนที่ workload จะล้มเหลวหรือถูกยกเลิก ดังนั้น job ที่ล้มเหลวบางส่วนจะไม่ปรากฏใน usage ที่รายงาน และบางส่วนก็ปรากฏ

  • โหมด Session: usage ที่รายงานคือเวลาตาม wall-clock ที่ session ทำงาน โดยไม่คำนึงถึงจำนวน job ที่ล้มเหลวหรือถูกยกเลิก

ดู usage จริงของ workload​

หลังจาก workload เสร็จสมบูรณ์ มีหลายวิธีในการดู usage จริง:

  • รัน batch.usage() หรือ session.usage() ใน qiskit-ibm-runtime 0.30 หรือใหม่กว่า หากใช้เวอร์ชันเก่ากว่าของ qiskit-ibm-runtime (>= 0.23 และ < 0.30) ยังสามารถพบ usage ได้ใน session.details()["usage_time"] และ batch.details()["usage_time"]
  • ใช้ GET /sessions/{id} เพื่อดู usage สำหรับ batch หรือ session เฉพาะ
  • ใช้ GET /jobs/{id} เพื่อดู usage สำหรับ job เดียว

ดู usage ของ instance​

สามารถดู usage ของ instance ได้ที่หน้า Instances หรือสำหรับผู้ที่มีสิทธิ์ที่เหมาะสม ที่หน้า Analytics โปรดทราบว่าหน้าต่างๆ อาจแสดงตัวเลข usage ที่แตกต่างกันเพราะคำนวณ usage ต่างกัน

หน้า Instances แสดง usage แบบ real-time สำหรับ 28 วันที่ผ่านมา (แบบ rolling) จนถึงเวลาปัจจุบันของวันนี้ Usage ในหน้า Analytics จะถูกคำนวณใหม่ทุกชั่วโมงและรวม 28 วันเต็มที่ผ่านมา นั่นคือ แสดง usage ตั้งแต่ 00:00 เมื่อ 28 วันก่อนจนถึงวันนี้ ณ ต้นชั่วโมง

ประมาณ usage ก่อนส่ง job​

แม้ว่าการประมาณแบบ local ที่แม่นยำจะซับซ้อนเนื่องจากการดำเนินการเพิ่มเติมสำหรับการกดและลดข้อผิดพลาด คุณสามารถใช้สูตรพื้นฐานนี้เพื่อประมาณ usage โดยประมาณ:

<per sub-job overhead> + (rep_delay + <circuit length>) * <num executions>

  • <per sub-job overhead> คือ overhead ประมาณ 2 วินาทีต่อ sub-job ซึ่งรวมถึงการดำเนินการเช่นการโหลด payload เข้าสู่ control electronics primitive job ของคุณอาจถูกแบ่งออกเป็นหลาย sub-jobs หากมันใหญ่เกินไปสำหรับ execution engine ในการประมวลผลทั้งหมดในครั้งเดียว
  • rep_delay เป็นตัวเลือกที่ผู้ใช้ปรับแต่งได้ และค่าเริ่มต้นถูกกำหนดโดย backend.default_rep_delay ซึ่งคือ 250 microseconds บน IBM Quantum backends ส่วนใหญ่ โปรดทราบว่าการลด rep_delay ลดเวลารัน QPU ทั้งหมด แต่แลกกับการเพิ่มอัตราข้อผิดพลาดในการเตรียมสถานะ ดูคู่มือ Dynamic repetition rate execution สำหรับข้อมูลเพิ่มเติม
  • <circuit length> คือความยาวของคำสั่งทั้งหมด แต่ละคำสั่งใช้เวลาต่างกันบน QPU ดังนั้นความยาวทั้งหมดจะแตกต่างกันไปตาม Circuit การวัดตัวอย่างเช่น อาจใช้เวลานานกว่า x gate ถึง 56 เท่า backend.target[<instruction>][<qubit>].duration สามารถใช้หาระยะเวลาที่แน่นอนของแต่ละคำสั่ง ความยาว Circuit ทั่วไปน่าจะอยู่ระหว่าง 50-100 microseconds หากคุณใช้เทคนิคการกดหรือลดข้อผิดพลาดกับ primitives อาจมีการแทรกคำสั่งเพิ่มเติมใน Circuit ของคุณ ซึ่งจะเพิ่มความยาว Circuit ทั้งหมด
    หมายเหตุ

    ตัวเลือก scheduler_timing แบบทดลอง ส่งคืนเวลา Circuit ทั้งหมด แต่นี่ไม่ใช่เวลาที่ใช้สำหรับการเรียกเก็บเงิน

  • <num executions> คือจำนวน Circuit ทั้งหมดคูณจำนวน shots โดยที่ Circuit คือที่สร้างหลังจาก PUB elements ถูก broadcast
    • หากคุณใช้เทคนิคการลดข้อผิดพลาดกับ primitives อาจมีการรัน Circuit เพิ่มเติมเป็นส่วนหนึ่งของกระบวนการลดข้อผิดพลาด ซึ่งจะเพิ่มจำนวนการรันทั้งหมด นอกจากนี้ เทคนิคการลดข้อผิดพลาดขั้นสูงเช่น PEA และ PEC มี overhead ที่สูงมากเพราะต้องรัน Circuit สำหรับ noise learning
    • Estimator จัดกลุ่ม observable ที่สลับกันแบบ qubit-wise ซึ่งช่วยลดจำนวนการรัน

หากคุณไม่ได้ใช้เทคนิคการลดข้อผิดพลาดขั้นสูงหรือ rep_delay แบบกำหนดเอง สามารถใช้ 2+0.00035*<num executions> เป็นสูตรเร็วได้

ขั้นตอนถัดไป​

คำแนะนำ
Source: IBM Quantum docs — updated 27 เม.ย. 2569
English version on doQumentation — updated 7 พ.ค. 2569
This translation based on the English version of 11 มี.ค. 2569