บทนำสู่ managed workflows

ความพร้อมใช้งานของแผน

Qiskit Functions และ managed workflows เป็นฟีเจอร์ beta ที่ใช้ได้เฉพาะผู้ใช้แผน Premium, Flex และ On-Prem (ผ่าน IBM Quantum® Platform API) เท่านั้น

Managed workflows รันโค้ด Python แบบกำหนดเองของคุณบน classical compute ที่ IBM Quantum Platform จัดการให้คุณ ใช้ managed workflows เพื่อรัน hybrid quantum-classical workflow, large-scale diagonalization และงานแบบขนานที่ใช้เวลานาน โดยไม่ต้องจัดการโครงสร้างพื้นฐานด้าน compute หรือ storage

เมื่อใดควรใช้ managed workflow

ใช้ managed workflow เมื่อไม่มี pre-built Catalog Function ที่ตอบโจทย์งานของคุณ หรือเมื่อคุณต้องการแพ็กเกจวิธีการของคุณเองเป็นฟังก์ชันที่นำกลับมาใช้ซ้ำได้ Managed workflows เหมาะเมื่อคุณต้องการทำสิ่งต่อไปนี้:

• รัน job ที่ใช้เวลานานบน cloud Managed workflow ยังคงรันต่อแม้คุณปิดแล็ปท็อป และคุณเชื่อมต่อกลับมาที่ job ได้ภายหลัง

• ใช้ node ที่มีหน่วยความจำมากและ GPU เลือกทรัพยากรหน่วยความจำ CPU และ GPU ที่ workload ต้องการ

• รันงานแบบขนาน เริ่ม job แบบ single-node จำนวนมากพร้อมกัน

คุณระบุโค้ด workflow, dependency และขนาด compute ที่ workflow รองรับ Managed workflows จะรัน workflow บน compute ที่ IBM® จัดการใน environment สำเร็จรูปที่ติดตั้งแพ็กเกจของคุณไว้ และมี cloud storage สำหรับไฟล์ที่ workflow อ่านและเขียน

Managed workflows ทำงานอย่างไร

คุณอัปโหลด workflow เพียงครั้งเดียวและรัน job ได้มากเท่าที่ต้องการ ทุก job ทำงานในลักษณะต่อไปนี้:

• job เริ่มใน environment ใหม่ที่มี local disk ว่างเปล่า Managed workflows จะปิด environment หลังจาก job จบ

• job รันบนขนาด compute ขนาดใดขนาดหนึ่งที่คุณกำหนดตอนอัปโหลด workflow คุณเลือกขนาดที่ต่างกันสำหรับแต่ละการรันได้

• job อ่านและเขียน file storage ของ workflow ได้ ไฟล์ใน file storage จะยังอยู่หลังจาก job จบ

เนื่องจากแต่ละ job เริ่มด้วย local disk ว่างเปล่า job ที่รันภายหลังจึงพบได้เฉพาะไฟล์ที่ job ก่อนหน้าบันทึกไว้ใน file storage

วงจรชีวิตของการรัน

แต่ละ job รันแบบ asynchronous นานสูงสุด 24 ชั่วโมง คุณมี active jobs ได้สูงสุด 50 รายการพร้อมกัน หาก instance ของคุณมี allocation เพียงพอ

ตารางต่อไปนี้อธิบายแต่ละขั้นตอนในแผนภาพและสถานะ job ที่คุณเห็นในขั้นตอนนั้น:

ขั้นตอน	สิ่งที่เกิดขึ้น	สถานะ job
Upload	คุณอัปโหลดโค้ด dependency และขนาดของ workflow Workflow จะปฏิเสธการอัปโหลดที่ไม่ถูกต้องก่อนที่ job ใดจะรัน	None (ยังไม่มี job)
Queue	คุณเรียก run() Workflow ตรวจสอบว่า instance ของคุณมี allocation เพียงพอหรือไม่ และจัดตารางเวลา job เมื่อมี compute ว่าง	QUEUED
Start	Workflow สร้าง environment ด้วย compute profile ที่คุณเลือก	INITIALIZING
Run	entrypoint ของ workflow ของคุณรัน entrypoint รายงานความคืบหน้าด้วย update_status() ได้ และคุณอ่าน logs ด้วย logs() ขณะที่มันรันอยู่ได้	RUNNING หรือขั้นตอนที่คุณตั้งค่า เช่น RUNNING: WAITING_FOR_QPU
Result	job จบ และ workflow ปิด environment โดยเก็บผลลัพธ์และ logs ไว้	DONE, ERROR หรือ CANCELED

สิ่งที่ job ที่กำลังรันเข้าถึงได้

แต่ละ job รันใน environment ที่แยกอิสระ แผนภาพและตารางต่อไปนี้แสดงทรัพยากรที่ job ที่กำลังรันใช้ได้

ทรัพยากร	สิ่งที่ job ใช้ได้
Compute	CPU หน่วยความจำ และ GPU ของ compute profile ที่คุณเลือกสำหรับ job
โค้ดและแพ็กเกจ	ไฟล์ที่คุณอัปโหลดพร้อมกับ workflow และแพ็กเกจที่รองรับซึ่งติดตั้งใน environment
Arguments	arguments ที่คุณส่งให้ run() อ่านได้ด้วย get_arguments()
การเข้าถึง QPU	credentials และ instance ที่คุณใช้เรียก run() QPU job ที่ workflow ส่งจะรันบน instance ของคุณและนับรวมในการใช้งานของคุณ
Outputs	ผลลัพธ์ที่ job บันทึกด้วย save_result() logs ที่ job พิมพ์ และการอัปเดตสถานะที่ job ตั้งด้วย update_status()
File storage	ไฟล์ ที่ทุกการรัน workflow ของคุณใช้ร่วมกัน ไฟล์จะยังอยู่ใน storage หลังจาก job จบ
Internet	ไม่มีการเข้าถึง job สร้างการเชื่อมต่อขาออกไม่ได้ ให้ระบุแพ็กเกจตอนอัปโหลด workflow และส่งข้อมูลเป็น arguments หรือไฟล์

ความปลอดภัยและการแยกอิสระ

Managed workflows แยกแต่ละ job ออกจาก job อื่นและจำกัดสิทธิ์ของโค้ดที่รันใน job ขอบเขตการเข้าถึงในตารางก่อนหน้าเป็นส่วนหนึ่งของการแยกอิสระนี้ Managed workflows ยังใช้การป้องกันต่อไปนี้ด้วย:

• การแยก job ไม่มี job อื่นรันใน environment ของ job คุณ รวมถึง job ของผู้ใช้คนอื่นและ job ของคุณเองที่รันพร้อมกัน

• ผลลัพธ์ logs และ storage เฉพาะผู้ใช้ที่รัน job เท่านั้นที่อ่านผลลัพธ์และ logs ของ job ได้

• Credentials Managed workflows เข้ารหัส credentials ที่ job ใช้ รวมถึง API token ของคุณ เมื่อจัดเก็บ โค้ด workflow ของคุณอ่าน credentials เหล่านี้ได้ขณะที่ job รัน

• สิทธิ์ Managed workflows ถอดสิทธิ์ระดับผู้ดูแลระบบออกจาก environment ก่อนที่ entrypoint ของคุณจะเริ่ม

เปรียบเทียบกับ HPC แบบ on-premises

Managed workflows ต่างจาก HPC cluster แบบ on-premises ในเรื่องวิธีขอเวลา compute การตั้งค่าซอฟต์แวร์ และการส่ง job ตารางต่อไปนี้เปรียบเทียบงานที่พบบ่อย

งาน	HPC cluster แบบ on-premises	Managed workflows
ขอเวลา compute	ขอ allocation หรือการจองจากผู้ดูแล cluster	ใช้ allocation ของ IBM Quantum instance ของคุณ Workflow จะจัดคิวแต่ละ job เมื่อคุณเรียก run()
เข้าถึงระบบ	เชื่อมต่อกับ login node ด้วย SSH	ใช้ Python client บนคอมพิวเตอร์เครื่องของคุณ Managed workflows ไม่มี login node ให้
ติดตั้งซอฟต์แวร์	build ซอฟต์แวร์ โหลด module หรือขอให้ผู้ดูแลระบบติดตั้งแพ็กเกจ	ใช้แพ็กเกจที่รองรับซึ่งติดตั้งในทุก environment หรืออัปโหลด wheel สำหรับแพ็กเกจอื่น
ส่ง job	เขียน batch script และส่งให้ scheduler	เรียก run() พร้อม arguments ของ job
ขอทรัพยากร	ขอ node, CPU, หน่วยความจำ และ GPU	เลือกขนาด compute ขนาดใดขนาดหนึ่งที่กำหนดไว้สำหรับ workflow แต่ละ job รันบน node เดียว
รัน parameter sweep	ส่ง job array	เรียก run() หนึ่งครั้งสำหรับแต่ละชุด arguments
จัดเก็บไฟล์ที่ใช้ร่วมกัน	เขียนลงใน shared scratch file system	เขียนลงใน file storage ของ workflow
จำกัดเวลารัน	ตั้งค่าขีดจำกัด wall-time	Workflow ยกเลิก job หลังจาก 24 ชั่วโมง
Checkpoint job ที่ใช้เวลานาน	เขียน checkpoint ลงใน scratch storage	บันทึกผลลัพธ์ระหว่างทางลงใน file storage
รัน job ที่ล้มเหลวอีกครั้ง	ส่ง job ใหม่	เรียก run() อีกครั้ง Workflow ไม่ retry job ที่ล้มเหลวโดยอัตโนมัติ
ติดตาม job	ตรวจสอบคิวและไฟล์ log จาก login node	ตรวจสอบสถานะ logs และผลลัพธ์ของแต่ละ job จาก Python session บนเครื่องของคุณ

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

คำแนะนำ

• Install แพ็กเกจ client และยืนยันตัวตน
• Deploy your first managed workflow เพื่ออัปโหลด workflow รัน และรับผลลัพธ์