งานแบบ Dry-run

Dry-run job จะรัน workload ของคุณผ่าน IBM Quantum® Compute Service โดยไม่ใช้เวลา QPU เลย ใช้ dry-run job เพื่อทำสิ่งต่อไปนี้ก่อนที่จะรันจริง:

• **ดูการใช้งานที่ job จะเกิดขึ้นบน QPU จริง

• ตรวจสอบ job Quantum Compute จะตรวจสอบพารามิเตอร์ของ job แบบเดียวกับที่ทำกับ job จริง

• ดู circuit timing schedule หากคุณร้องขอ เพื่อดีบัก job ก่อนรันจริง

ต่างจาก dry-run job ตรงที่ local testing (fake backend และ Qiskit Aer) รันบนเครื่องของคุณเอง จึงไม่สามารถให้ตัวเลขการใช้งาน การตรวจสอบฝั่งบริการ หรือข้อมูล timing ของบริการได้ หากต้องการเปรียบเทียบสองแนวทางนี้ ดู Mock devices เทียบกับ fake backend

หมายเหตุ

• ต้องใช้ qiskit-ibm-runtime v0.51.0 ขึ้นไปสำหรับ dry-run job
• Dry-run job ใช้ได้ในทุกภูมิภาค และใช้ได้เฉพาะแผน Flex, Premium และ On-Prem เท่านั้น ไม่รองรับแผน Open หรือ Pay-As-You-Go

วิธีการทำงาน

หากต้องการรัน dry-run job ให้ส่ง dry_run=True ไปยังเมธอด run() ของ primitive:

backend = service.backend("ibm_phoenix")
isa_circuit = pm.run(circuit)  # transpiled for ibm_phoenix
sampler = Sampler(mode=backend)
job = sampler.run([isa_circuit], dry_run=True)
job.result()  # wait for completion
print(job.usage())

dry_run เป็นอาร์กิวเมนต์ของเมธอด run() (ค่าเริ่มต้นคือ False) ไม่ใช่ runtime option และใช้ได้กับทุก primitive

Dry-run job มีลักษณะดังนี้:

• รันใน IBM Quantum Compute Service บนคลาวด์ ไม่ใช่บนเครื่องของคุณ

• ใช้ข้อมูล calibration จาก QPU จริง ไม่ใช่แค่ snapshot

• ผลลัพธ์ยังคงมี schema ตามที่คาดไว้และมีรูปร่างตามผลลัพธ์จาก QPU จริง แต่เป็นข้อมูล mock ที่สุ่มขึ้นมา ไม่ใช่ผลการวัดจริงหรือผลจำลอง จึงอย่านำไปใช้ตรวจสอบความถูกต้องทางกายภาพ

• การประมวลผลเกิดขึ้นบนเซิร์ฟเวอร์ ดังนั้น job อาจไม่เสร็จทันที

ขนาด Circuit, shots และขีดจำกัดอื่น ๆ เหมือนกับ job ใด ๆ ของโปรแกรมนั้น

dry_run=True ใช้ได้เช่นกันเมื่อ Backend เป็น mock device อยู่แล้ว

อ่านค่าการใช้งาน

การใช้งานของ dry-run job ที่เสร็จสมบูรณ์คือการใช้งานที่ job เดียวกันจะเกิดขึ้นบน QPU จริง ยกเว้นในบางกรณีที่หายากซึ่งข้อมูล calibration เปลี่ยนไปมากหลังจาก dry-run job และก่อน job บน QPU จริง

• job.usage() คืนค่าการใช้งานเป็นวินาที

• job.metrics()["usage"] คืนข้อมูลเดียวกันพร้อมสถานะการใช้งาน

การใช้งานของ dry-run ไม่ถูกเรียกเก็บเงิน ไม่ใช้โควตาตามแผนของคุณ และไม่นับรวมกับขีดจำกัดใด ๆ

อย่าใช้ job.usage_estimation กับ dry-run job

อย่าใช้ job.usage_estimation กับ dry-run job ให้ใช้ job.usage() แทน

job.usage() คืนค่า 0 จนกว่าการคำนวณการใช้งานจะเสร็จสิ้น ดังนั้นให้รอให้ job เสร็จก่อนจึงอ่านค่า

ตารางเวลาของ Circuit

หากต้องการร้องขอ circuit timing schedule ให้ใช้ option เดียวกับ job จริง ดูรายละเอียดทั้งหมดที่ Visualize circuit timing

ข้อจำกัด

• เฉพาะ job mode และ batch mode Dry-run job รันได้เฉพาะใน job mode และ batch mode เท่านั้น

• เฉพาะแผน Flex, Premium และ On-Prem Dry-run job ไม่รองรับแผน Open หรือ Pay-As-You-Go

อุปกรณ์จำลอง

Mock device คือการทำงานเบื้องหลังของ dry-run job โดยค่าเริ่มต้น dry-run job จะซ่อน mock device แต่คุณจะพบมันในกรณีเหล่านี้:

• Instance ที่ตั้งค่าให้เข้าถึงได้เฉพาะ mock device ตัวอย่าง: หากคุณใช้ service.backend("ibm_phoenix") เพื่อส่ง dry-run job บน ibm_phoenix แต่ instance ของคุณไม่มีสิทธิ์เข้าถึง ibm_phoenix คุณจะได้รับ QiskitBackendNotFoundError ให้เลือก mock device โดยตรงด้วย service.backend("mock_phoenix") แทน

• Compute resources โดยค่าเริ่มต้น mock device จะถูกซ่อนในหน้า Compute resources ตารางในหน้านั้นมีตัวเลือกตัวกรองเพื่อแสดง mock device แต่มีเพียงแผน Flex, Premium และ On-Prem เท่านั้นที่เข้าถึง mock device ได้

• ตาราง Workloads โดยค่าเริ่มต้น job จาก mock device จะถูกซ่อนในหน้า Workloads ตารางมีตัวเลือกตัวกรอง (ไอคอนรูปกรวย) เพื่อแสดง job เหล่านั้น

• Python API service.backends() และ service.jobs() ไม่รวม mock device เว้นแต่คุณจะเรียกด้วย include_mocks=True ส่วน IBMBackend.is_mock บอกว่า Backend เป็น mock device หรือไม่ และ service.least_busy() จะไม่คืน mock device เลย

Mock devices เทียบกับ fake backend

ชื่อคล้ายกัน แต่ mock device กับ fake backend เป็นคนละอย่างกัน Fake backend เป็นออบเจ็กต์ภายในเครื่องในสภาพแวดล้อม Python ของคุณ ส่วน mock device เป็นทรัพยากรบนคลาวด์ใน IBM Quantum Compute Service

	Mock device (เช่น mock_phoenix)	Fake backend (เช่น FakeManilaV2)
คืออะไร	อุปกรณ์ใน IBM Quantum Compute Service	คลาส Python ใน qiskit_ibm_runtime.fake_provider
รันที่ไหน	คลาวด์ ในบริการ	ภายในเครื่อง บนเครื่องของคุณ
วิธีรับมา	service.backend("mock_phoenix") หรืออัตโนมัติด้วย run(..., dry_run=True)	from qiskit_ibm_runtime.fake_provider import ...
บัญชีและ instance	เฉพาะบางแผน (Flex, Premium หรือ On-Prem)	ทุก instance และทุกแผน
Calibration	สด ตรงกับอุปกรณ์จริงตลอดเวลา	Snapshot คงที่ที่มาพร้อมแพ็กเกจที่ติดตั้ง
ผลลัพธ์	ข้อมูลสุ่มที่มี schema ตามที่คาดไว้ ไม่ใช่การจำลอง	การจำลองแบบมี noise ที่ใช้ noise model ของ snapshot
ผลลัพธ์มีความหมายทางกายภาพ	ไม่ อย่าใช้ตรวจสอบความถูกต้อง	โดยประมาณ ภายในขีดจำกัดของ noise model
รายงานการใช้งาน	ใช่	ไม่มี
ถูกเรียกเก็บเงินหรือนับรวมกับโควตาหรือขีดจำกัดของแผน	ไม่	ไม่
การตรวจสอบ job	ทำโดยบริการ เหมือน job จริง	จำกัดเฉพาะสิ่งที่ไคลเอนต์ตรวจ
Timing schedule	มีให้เมื่อร้องขอ	ไม่มี
Execution modes	เฉพาะ job และ batch mode เท่านั้น Session ถูกบล็อก	รับไวยากรณ์ Session แต่ไม่สนใจ (โหมดภายในเครื่องไม่มี session หรือ batch จริง)
การเสร็จสิ้น	แบบอะซิงโครนัส บนเซิร์ฟเวอร์	รันภายในเครื่องและคืนค่าเมื่อเสร็จ
แสดงในอินเทอร์เฟซแพลตฟอร์มและรายการ API	ซ่อนโดยค่าเริ่มต้น (Compute resources, ตาราง Workloads, backends(), jobs()) เลือกเปิดเพื่อแสดง	ไม่เคย เพราะไม่มีอะไรถูกส่งไปยังบริการ

วิธีเลือก

• หากต้องการทราบว่า job จะใช้การใช้งานเท่าไร หรือบริการจะรับ job หรือไม่ ให้ใช้ dry-run job

• หากต้องการทราบว่าผลลัพธ์อาจมีหน้าตาอย่างไร หรือต้องการทำงานออฟไลน์ ให้ใช้ fake backend หรือ Aer

• หากต้องการทั้งสองอย่าง ให้ปรับปรุง Circuit และผลลัพธ์ซ้ำ ๆ ด้วย fake backend แล้วทำ dry-run เป็นการตรวจสอบครั้งสุดท้ายก่อนใช้ QPU จริง

จุดที่มักสับสน

• Mock device ไม่ใช่ simulator ผลลัพธ์เป็นแบบสุ่ม ดังนั้นการ sampling Circuit แบบ Bell บน mock_phoenix จะไม่คืนการแจกแจงแบบ Bell หากต้องการผลลัพธ์ที่มี noise สมจริง ให้ใช้ fake backend

• Fake backend ไม่ใช่อุปกรณ์จริงแบบสด calibration ของมันเป็น snapshot และอาจล้าสมัย ส่วน mock device ติดตาม calibration จริง ดังนั้น Circuit ที่ transpile แล้วและ timing จึงตรงกับที่ QPU เห็นในวันนี้

• ทั้งสองอย่างไม่ได้รันบนฮาร์ดแวร์จริง ทั้งคู่ไม่ใช้เวลา QPU แต่มีเพียง dry-run job เท่านั้นที่ผ่านบริการ

• usage_estimation ไม่ใช่ค่าประมาณของ dry-run สำหรับ dry-run job job.usage() จะคืนจำนวนวินาทีของการใช้งานที่ job ของคุณจะถูกเรียกเก็บบน QPU จริง

กรณีการใช้งาน

นักเรียนและหลักสูตร

ผู้ดูแลระบบจำกัด instance ให้ใช้ได้เฉพาะ mock device โดยใช้สวิตช์การปรับแต่ง QPU เมื่อสร้างหรือแก้ไข instance จากนั้นนักเรียนสามารถตรวจสอบ payload ของตนแบบ end-to-end ได้โดยไม่ใช้เวลา QPU จริงหรือ RU เนื่องจาก instance เข้าถึงได้เฉพาะ mock device นักเรียนจึงเลือก Backend ด้วยชื่อ mock:

backend = service.backend("mock_phoenix")
sampler = Sampler(mode=backend)
job = sampler.run([isa_circuit], dry_run=True)

การวางแผนโปรเจกต์

ทีมที่กำลังจะเริ่มโปรเจกต์ทำ dry-run กับ job ตัวอย่างเพื่อดู RU ที่โปรเจกต์ต้องใช้ ก่อนเลือกแผนหรือโควตา:

backend = service.backend("ibm_phoenix")
sampler = Sampler(mode=backend)
job = sampler.run([isa_circuit], dry_run=True)
job.result()
print(job.usage()) 

การตรวจสอบครั้งสุดท้ายก่อนรันบน QPU จริง

ตรวจสอบพารามิเตอร์และดู timing schedule ด้วย dry_run=True จากนั้นเอาอาร์กิวเมนต์ออกแล้วรันบน QPU จริง โค้ดส่วนอื่นไม่ต้องเปลี่ยน:

sampler = Sampler(mode=backend)

# Pre-flight check
job = sampler.run([isa_circuit], dry_run=True)
job.result()

# Real run - same code, without dry_run
job = sampler.run([isa_circuit])

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

คำแนะนำ

• ทดสอบโปรแกรมบนเครื่องของคุณเองด้วย Local testing mode
• เรียนรู้ว่าการใช้งาน workload วัดอย่างไร
• ดูcircuit timing schedule แบบภาพ
• ทำความเข้าใจหน่วยทรัพยากรและแผนที่มีให้เลือก