บทนำสู่ Qiskit Runtime execution modes

เมื่อ Qiskit Runtime เปิดตัวครั้งแรก ผู้ใช้สามารถรัน Circuit เป็น job แต่ละตัวเท่านั้น เมื่อ quantum workloads ประเภทต่างๆ เกิดขึ้น ความต้องการสำหรับกลยุทธ์การจัดตารางเวลาที่แตกต่างกันก็ชัดเจนขึ้น execution modes กำหนดวิธีจัดตารางเวลา job ของคุณ และการเลือก execution mode ที่เหมาะสมช่วยให้ workload ของคุณรันได้อย่างมีประสิทธิภาพภายในงบประมาณของคุณ มี execution modes สามแบบ: job, session และ batch

Job mode

การร้องขอ primitive เดียวที่ทำโดยไม่มี context manager Circuit และ inputs ถูกบรรจุเป็น primitive unified blocs (PUBs) และส่งเป็น execution task บน quantum computer หากต้องการรันใน job mode ระบุ mode=backend เมื่อสร้าง primitive ดูตัวอย่าง Estimator และตัวอย่าง Sampler สำหรับการใช้งาน

Batch mode

ตัวจัดการ multi-job สำหรับการรันการทดลองที่ประกอบด้วย multi-job workloads อย่างมีประสิทธิภาพ workload เหล่านี้ประกอบด้วย job ที่รันได้อิสระซึ่งไม่มีความสัมพันธ์แบบมีเงื่อนไขต่อกัน ด้วย batch mode ผู้ใช้ส่ง job ทั้งหมดพร้อมกันทีเดียว

ระบบทำ parallelizes หรือ threads ขั้นตอนการประมวลผลล่วงหน้า (classical computing) ของแต่ละ primitive job เพื่อบรรจุ quantum execution ข้าม job ให้แน่นขึ้น จากนั้นรัน quantum execution ของแต่ละ job ในการสืบต่อกันอย่างรวดเร็วเพื่อให้ผลลัพธ์ที่มีประสิทธิภาพมากที่สุด สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับ threading ดูหน้า Execution mode FAQ.

หมายเหตุ

• เมื่อใช้ batching job ไม่รับประกันว่าจะรันตามลำดับที่ส่ง นอกจากนี้ แม้ batch jobs ของคุณจะรันใกล้กันมากที่สุดเท่าที่จะเป็นไปได้ แต่ไม่ได้รับสิทธิ์เข้าถึง backend แบบ exclusive ดังนั้น batch jobs ของคุณอาจรันพร้อมกับ job ของผู้ใช้รายอื่นหากมีกำลังการประมวลผลเพียงพอบน QPU นอกจากนี้ QPU calibration jobs อาจรันระหว่าง batched jobs
• เวลาในคิวไม่ลดลงสำหรับ job แรกที่ส่งใน batch ดังนั้น batches ไม่ให้ประโยชน์ใดๆ เมื่อรัน job เดียว

หากต้องการรันใน batch mode ระบุ mode=batch เมื่อสร้าง primitive หรือรัน job ใน batch context manager ดูรัน job ใน batch สำหรับตัวอย่าง

Session mode

หน้าต่างเฉพาะสำหรับการรัน multi-job workload ในช่วงนี้ผู้ใช้มีสิทธิ์เข้าถึงระบบแบบ exclusive และไม่มี job อื่นสามารถรันได้ รวมถึง calibration jobs สิ่งนี้ช่วยให้ผู้ใช้ทดลองกับ variational algorithms ในแบบที่คาดเดาได้มากขึ้น และยังรันการทดลองหลายตัวพร้อมกันได้ โดยใช้ประโยชน์จาก parallelism ใน stack การใช้ sessions ช่วยหลีกเลี่ยงความล่าช้าที่เกิดจากการจัดคิว job แต่ละตัวแยกกัน ซึ่งมีประโยชน์มากสำหรับงานแบบ iterative ที่ต้องการการสื่อสารบ่อยครั้งระหว่างทรัพยากร classical และ quantum

หากต้องการรันใน session mode ระบุ mode=session เมื่อสร้าง primitive หรือรัน job ใน session context manager ดูรัน job ใน session สำหรับตัวอย่าง

หมายเหตุ

• เวลาในคิวไม่ลดลงสำหรับ job แรกที่ส่งใน session ดังนั้น sessions ไม่ให้ประโยชน์ใดๆ เมื่อรัน job เดียว
• ผู้ใช้ Open Plan ไม่สามารถส่ง session jobs

เวิร์กโฟลว์พื้นฐาน

เวิร์กโฟลว์พื้นฐานสำหรับ batches และ sessions คล้ายกัน:

1. job แรกใน batch หรือ session เข้าคิวปกติ สำหรับ batches ชุด job ทั้งหมดถูกจัดตารางเวลาร่วมกัน
2. เมื่อ job แรกเริ่มรัน maximum time to live (TTL) timer จะเริ่มและไม่หยุดหรือ pause จนกว่าจะถึงจุดสิ้นสุด
3. interactive TTL timer เริ่มหลังจาก job แต่ละตัวเสร็จสมบูรณ์ หากไม่มี workload jobs พร้อมภายใน interactive TTL window workload จะถูก deactivate ชั่วคราวและการเลือก job ปกติจะดำเนินต่อ job สามารถ reactivate workload ที่ถูก deactivate ได้หาก batch หรือ session ยังไม่ถึงค่า maximum TTL
   หมายเหตุ

   job ต้องผ่านคิวปกติเพื่อ reactivate workload

4. หากถึงค่า maximum TTL workload จะสิ้นสุดและ job ที่รออยู่ที่เหลือจะล้มเหลว job ที่กำลังรันอยู่จะไม่รันจนเสร็จหากการทำเช่นนั้นจะเกินขีดจำกัดค่าใช้จ่ายของ instance

วิดีโอต่อไปนี้แสดงเวิร์กโฟลว์พื้นฐาน โดยใช้ sessions เป็นตัวอย่าง:

สำหรับรายละเอียดทั้งหมดเกี่ยวกับ TTL timers ดูคู่มือเวลารันสูงสุด

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

คำแนะนำ

• รัน job ใน batch mode.
• รัน job ใน session mode.
• เลือก execution mode ที่เหมาะสม.
• ดูคำถามที่พบบ่อยเกี่ยวกับ execution modes.