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

เลือก execution mode ที่เหมาะสม

workload ระดับ utility-scale อาจใช้เวลาหลายชั่วโมงในการทำให้สำเร็จ ดังนั้นจึงเป็นสิ่งสำคัญที่ทั้ง classical และ quantum resources จะได้รับการจัดตารางอย่างมีประสิทธิภาพเพื่อทำให้การ execution ราบรื่น Execution modes ให้ความยืดหยุ่นในการสร้างสมดุลระหว่างต้นทุนและเวลาเพื่อใช้ทรัพยากรอย่างเหมาะสมที่สุดสำหรับ workload ของคุณ มีหลายด้านที่ต้องพิจารณาเมื่อเลือก execution mode ที่จะใช้ เช่น เวลา execution โดยรวม (maximum time to live หรือ TTL) และเวลาระหว่าง jobs (interactive TTL)

ข้อดีของแต่ละแบบสรุปไว้ด้านล่าง:

  • Batch
    • jobs ทั้ง batch จะถูกจัดตารางร่วมกันและไม่มีเวลา queuing เพิ่มเติมสำหรับแต่ละ job
    • การคำนวณ classical ของ jobs เช่น compilation จะรันแบบขนานกัน ดังนั้นการรัน jobs หลาย jobs ใน batch จึงเร็วกว่าการรันแบบ serial อย่างมาก
    • โดยปกติจะมีความล่าช้าน้อยมากระหว่าง jobs ซึ่งช่วยหลีกเลี่ยง drift ได้
    • ถ้าคุณแบ่ง workload เป็นหลาย jobs และรันในโหมด batch คุณสามารถรับผลลัพธ์จาก jobs แต่ละตัวได้ ทำให้ยืดหยุ่นในการทำงานมากขึ้น ตัวอย่างเช่น ถ้าผลลัพธ์ของ job ไม่ตรงกับความคาดหวัง คุณสามารถยกเลิก jobs ที่เหลือได้ และถ้า job หนึ่ง fail คุณสามารถ submit ใหม่แทนที่จะรัน workload ทั้งหมดอีกครั้ง
    • โดยทั่วไปราคาถูกกว่า sessions
  • Session
    • ฟังก์ชันทั้งหมดจาก batch mode (แต่ต้องการการใช้งานที่มากขึ้น ดู Workload usage สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับวิธีคำนวณการใช้งาน)
    • สิทธิ์การเข้าถึง QPU แบบ dedicated และ exclusive ในช่วงเวลา active window ของ session
    • มีประโยชน์สำหรับ workload ที่ไม่มี input ทั้งหมดพร้อมตั้งแต่ต้น สำหรับ iterative workload ที่ต้องการ classical post-processing ก่อนที่จะรัน iteration ถัดไป และสำหรับการทดลองที่ต้องรันชิดกันให้มากที่สุด
  • Job
    • ใช้งานง่ายที่สุดเมื่อรันการทดลองขนาดเล็ก
    • อาจรันได้เร็วกว่า batch mode

คำแนะนำและ best practices​

โดยทั่วไป ใช้ batch mode เว้นแต่คุณมี workload ที่ไม่มี input ทั้งหมดพร้อมตั้งแต่ต้น

  • ใช้โหมด batch เพื่อ submit primitive jobs หลาย jobs พร้อมกันเพื่อลดเวลาในการประมวลผล

  • ใช้โหมด session สำหรับ iterative workloads หรือถ้าคุณต้องการสิทธิ์การเข้าถึง QPU แบบ dedicated

  • ใช้โหมด job เสมอเมื่อ submit primitive request เพียงอันเดียว

  • เนื่องจาก sessions มักมีค่าใช้จ่ายสูงกว่า จึงแนะนำให้ใช้ batch เมื่อคุณไม่ต้องการข้อดีเพิ่มเติมจากการใช้ sessions

  • ผู้ใช้ Open Plan ไม่สามารถ submit session jobs ได้

เพื่อให้มั่นใจว่าการใช้งาน execution modes มีประสิทธิภาพสูงสุด แนะนำให้ใช้ practices ต่อไปนี้:

  • มี fixed overhead ที่เกี่ยวข้องกับการรัน job โดยทั่วไป ถ้าแต่ละ job ของคุณใช้ QPU time น้อยกว่าหนึ่งนาที ให้พิจารณารวม jobs หลาย jobs เป็น job ขนาดใหญ่ขึ้น (ใช้กับ execution mode ทุกรูปแบบ) "QPU time" หมายถึงเวลาที่ QPU complex ใช้ในการประมวลผล job ของคุณ

  • ถ้าแต่ละ job ของคุณใช้ QPU time มากกว่าหนึ่งนาที หรือถ้าการรวม jobs ไม่เหมาะสม คุณยังสามารถรัน jobs หลาย jobs แบบขนานกันได้ ทุก job ต้องผ่านทั้ง classical และ quantum processing ในขณะที่ QPU สามารถประมวลผลได้ทีละ job เท่านั้น classical jobs สูงสุดห้า jobs สามารถประมวลผลแบบขนานได้ คุณสามารถใช้ประโยชน์จากสิ่งนี้โดยการ submit jobs หลาย jobs ใน execution mode แบบ batch หรือ session

สิ่งข้างต้นเป็นแนวทางทั่วไป และคุณควรปรับ workload ของคุณเพื่อหาอัตราส่วนที่เหมาะสมที่สุด โดยเฉพาะเมื่อใช้ sessions ตัวอย่างเช่น ถ้าคุณใช้ session เพื่อสิทธิ์การเข้าถึง backend แบบ exclusive ลองพิจารณาแบ่ง jobs ขนาดใหญ่เป็น jobs ขนาดเล็กและรันแบบขนานกัน วิธีนี้อาจคุ้มค่ากว่าเนื่องจากสามารถลด wall-clock time ได้

ตัวอย่าง​

รัน quantum variational algorithm​

การรัน quantum variational algorithm มักเป็นไปตาม flow นี้:

  1. เตรียม ansatz
  2. ประเมิน cost function บน QPU
  3. นำผลลัพธ์จากขั้นตอนก่อนหน้าและรันผ่าน classical optimizer
  4. ปรับพารามิเตอร์ตามผลลัพธ์ของ (3) แล้วกลับไปที่ขั้นตอน (2)

ในกรณีนี้ ถ้าคุณใช้ job หรือ batch mode แต่ละ job ที่สร้างโดยขั้นตอน (2) ต้องกลับผ่าน queue ใหม่ สิ่งนี้ทำให้ความยาวของการทดลอง (wall-clock time) เพิ่มขึ้นอย่างมากเนื่องจากเวลา queuing นอกจากนี้ยังอาจใช้เวลานานกว่าในการ converge เนื่องจาก device drift กล่าวคือ ทุก iteration ควรให้ผลลัพธ์ที่ดีขึ้น แต่ device drift อาจทำให้ผลลัพธ์ต่อๆ มาแย่ลง

นอกจากนี้ ถ้าคุณใช้ PEA หรือ PEC คุณสามารถ เรียนรู้ noise model ครั้งเดียวและใช้กับ jobs ต่อๆ มาเมื่อรันใน dedicated session สิ่งนี้มักไม่ทำงานกับ batch หรือ job mode เนื่องจาก noise model อาจล้าสมัยเมื่อ job ถัดไปออกจาก queue

เปรียบเทียบการตั้งค่า error mitigation​

เพื่อเปรียบเทียบผลกระทบของวิธี error mitigation ที่มีอยู่ คุณอาจทำตาม flow นี้:

  1. สร้าง Circuit และ observable
  2. Submit primitive jobs ที่ใช้ combinations ต่างๆ ของการตั้งค่า error mitigation
  3. Plot ผลลัพธ์เพื่อสังเกตผลกระทบของการตั้งค่าต่างๆ

ในกรณีนี้ jobs ทั้งหมด (ที่เกี่ยวข้องกันแต่เป็นอิสระจากกัน) พร้อมใช้งานตั้งแต่ต้น ถ้าคุณใช้ batch mode jobs จะถูกจัดตารางร่วมกันเพื่อให้คุณรอ queue เพียงครั้งเดียว นอกจากนี้ เนื่องจากเป้าหมายคือการเปรียบเทียบผลกระทบของวิธี error mitigation ต่างๆ จึงเป็นประโยชน์ที่พวกมันจะรันชิดกันให้มากที่สุด ดังนั้น batch จึงเป็นตัวเลือกที่ดี คุณ อาจ รัน jobs เหล่านี้ใน session ได้ แต่เนื่องจาก sessions มักมีค่าใช้จ่ายสูงกว่า จึงแนะนำให้ใช้ batch เมื่อคุณไม่ต้องการฟังก์ชันเพิ่มเติมที่ sessions ให้

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

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