บทนำสู่ Qiskit Runtime execution modes
เมื่อ Qiskit Runtime เปิดตัวครั้งแรก ผู้ใช้สามารถรัน Circuit เป็น job แต่ละตัวเท่านั้น เมื่อ quantum workloads ประเภทต่างๆ เกิดขึ้น ความต้องการสำหรับกลยุทธ์การจัดตารางเวลาที่แตกต่างกันก็ชัดเจนขึ้น execution modes กำหนดวิธีจัดตารางเวลา job ของคุณ และการเลือก execution mode ที่เห มาะสมช่วยให้ workload ของคุณรันได้อย่างมีประสิทธิภาพภายในงบประมาณของคุณ มี execution modes สามแบบ: job, session และ batch
Job mode
การร้องขอ primitive เดียวของ estimator หรือ sampler ที่ทำโดยไม่มี context manager Circuit และ inputs ถูกบรรจุเป็น primitive unified blocs (PUBs) และส่งเป็น execution task บน quantum computer หากต้องการรันใน job mode ระบุ mode=backend เมื่อสร้าง primitive ดูตัวอย่าง Primitives สำหรับการใช้งาน
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 คล้ายกัน:
- job แรกใน batch หรือ session เข้าคิวปกติ สำหรับ batches ชุด job ทั้งหมดถูกจัดตารางเวลาร่วมกัน
- เมื่อ job แรกเริ่มรัน maximum time to live (TTL) timer จะเริ่มและไม่หยุดหรือ pause จนกว่าจะถึงจุดสิ้นสุด
- interactive TTL timer เริ่มหลังจาก job แต่ละตัวเสร็จสมบูรณ์ หากไม่มี workload jobs พร้อมภายใน interactive TTL window workload จะถูก deactivate ชั่วคราวและการเลือก job ปกติจะดำเนินต่อ job สามารถ reactivate workload ที่ถูก deactivate ได้หาก batch หรือ session ยังไม่ถึงค่า maximum TTL
หมายเหตุ
job ต้องผ่านคิวปกติเพื่อ reactivate workload
- หากถึงค่า maximum TTL workload จะสิ้นสุดและ job ที่รออยู่ที่เหลือจะล้มเหลว job ที่กำลังรันอยู่จะไม่รันจนเสร็จหากการทำเช่นนั้นจะเกินขีดจำกัดค่าใช้จ่ายของ instance
วิดีโอต่อไปนี้แสดงเวิร์กโฟลว์พื้นฐาน โดยใช้ sessions เป็นตัวอย่าง:
สำหรับรายละเอียดทั้งหมดเกี่ยวกับ TTL timers ดูคู่มือเวลารันสูงสุด