מבוא למצבי הרצה של Qiskit Runtime
כאשר Qiskit Runtime הוצג לראשונה, משתמשים יכלו להריץ circuits רק כעבודות בודדות. ככל שהתפתחו סוגים שונים של עומסי עבודה קוונטיים, התברר שנדרשות אסטרטגיות תזמון שונות. מצבי ההרצה קובעים כיצד העבודות שלך מתוזמנות, ובחירת מצב ההרצה הנכון מאפשרת לעומס העבודה שלך לפעול ביעילות בתוך התקציב שלך. ישנם שלושה מצבי הרצה: job, session ו-batch.
מצב Job
בקשת primitive בודדת של ה-estimator או ה-sampler שנשלחת ללא context manager. ה-Circuits והקלטים ארוזים כ-primitive unified blocs (PUBs) ומוגשים כמשימת הרצה על המחשב הקוונטי. להרצה במצב job, ציין mode=backend בעת יצירת primitive. ראה דוגמאות Primitives לשימוש.
מצב Batch
מנהל עבודות מרובות להרצה יעילה של ניסויים הכוללים עומסי עבודה מרובי-עבודות. עומסי עבודה אלה מורכבים מעבודות שניתן להריץ באופן עצמאי וללא תלות מותנית ביניהן. במצב batch, המשתמשים מגישים את כל העבודות שלהם בבת אחת.
המערכת מקבילה או מחוטטת את שלב העיבוד המוקדם (חישוב קלאסי) של כל עבודת primitive כדי לארוז את ההרצה הקוונטית בצפיפות רבה יותר בין עבודות, ולאחר מכן מריצה את ההרצה הקוונטית של כל עבודה ברצף מהיר כדי לספק את התוצאות היעילות ביותר. לפרטים נוספים על חיטוט, ראה את דף שאלות נפוצות על מצבי הרצה.
- בעת שימוש ב-batch, לא מובטח שהעבודות ירוצו בסדר שבו הן הוגשו. כמו כן, בעוד שעבודות ה-batch שלך ירוצו קרוב ככל האפשר זו לזו, הן אינן מקבלות גישה בלעדית ל-backend. לכן, עבודות ה-batch שלך עשויות לרוץ במקביל לעבודות של משתמשים אחרים אם יש מספיק קיבולת עיבוד ב-QPU. בנוסף, עבודות כיול QPU עשויות לרוץ בין עבודות ה-batch.
- זמן ההמתנה בתור אינו קטן עבור העבודה הראשונה שמוגשת במסגרת batch. לכן, batch אינו מספק יתרונות כלשהם בעת הרצת עבודה בודדת.
להרצה במצב batch, ציין mode=batch בעת יצירת primitive או הרץ את העבודה ב-batch context manager. ראה הרץ עבודות ב-batch לדוגמאות.
מצב Session
חלון ייעודי להרצת עומס עבודה מרובה-עבודות. במהלך חלון זה, למשתמש יש גישה בלעדית למערכת ואף עבודה אחרת אינה יכולה לרוץ - כולל עבודות כיול. זה מאפשר למשתמשים לנסות אלגוריתמים ורואציוניים בצורה צפויה יותר ואפילו להריץ מספר ניסויים בו-זמנית, תוך ניצול מקביליות ב-stack. שימוש ב-sessions עוזר להימנע מעיכובים הנגרמים מהמ תנה בתור לכל עבודה בנפרד, דבר שיכול להיות שימושי במיוחד למשימות איטרטיביות הדורשות תקשורת תכופה בין משאבים קלאסיים וקוונטיים.
להרצה במצב session, ציין mode=session בעת יצירת primitive, או הרץ את העבודה ב-session context manager. ראה הרץ עבודות ב-session לדוגמאות.
- זמן ההמתנה בתור אינו קטן עבור העבודה הראשונה שמוגשת במסגרת session. לכן, sessions אינם מספקים יתרונות כלשהם בעת הרצת עבודה בודדת.
- משתמשי Open Plan אינם יכולים להגיש עבודות session.
זרימת עבודה בסיסית
זרימת העבודה הבסיסית עבור batches ו-sessions דומה:
- העבודה הראשונה ב-batch או session נכנסת לתור הרגיל. עבור batches, כל קבוצת העבודות מתוזמנת יחד.
- כאשר העבודה הראשונה מתחילה לרוץ, טיימר זמן החיים המרבי (TTL) מתחיל ואינו נעצר או מושהה עד לסיומו.
- טיימר ה-interactive TTL מתחיל לאחר סיום כל עבודה. אם אין עבודות מוכנות במסגרת חלון ה-interactive TTL, עומס העבודה מושהה זמנית ובחירת עבודות רגילה מתחדשת. עבודה יכולה להפעיל מחדש את עומס העבודה המושהה אם ה-batch או ה-session לא הגיעו לערך ה-TTL המרבי שלהם.
הערה
העבודה חייבת לעבור את התור הרגיל כדי להפעיל מחדש את עומס העבודה.
- אם הגיעו לערך ה-TTL המרבי, עומס העבודה מסתיים וכל העבודות שנותרו בתור נכשלות. עבודה שרצה כעת לא תושלם אם עשייתה תחרוג ממגבלת העלות של המופע.
הסרטון הבא ממחיש את זרימת העבודה הבסיסית, תוך שימוש ב-sessions כדוגמה:
לפרטים מלאים על טיימרי TTL, ראה את המדריך זמן הרצה מרבי.