משאבי מחשוב וניהול משאבים

מודל משאבים ומשאבים קלאסיים

בחלק זה נציג מסגרת לחשיבה על סביבות מחשוב שניתן ליישם הן על מחשב נייד והן על מחשבי-על. בסוף החלק תבינו את המרכיבים הבסיסיים של סביבת מחשוב וכיצד הם קשורים זה לזה. כל זאת מוסבר על ידי איסקנדר סיטדיקוב בסרטון הבא.

מודל המשאבים

כל סביבת מחשוב קלאסית בנויה ממספר משאבים משולבים הפועלים יחד להפעלת יישומים בצורה יעילה. המשאבים המרכזיים כוללים בדרך כלל:

• CPU (יחידת עיבוד מרכזית): ה-CPU הוא יחידת העיבוד המרכזית המפרשת ומבצעת הוראות תוכנית. הוא מטפל בפעולות לוגיות, אריתמטיות ובקרה, ומשמש למעשה כ"מוח" של המערכת.

• מטמון CPU‏ (L1,‏ L2,‏ L3): זוהי הזיכרון המהיר ביותר במערכת, הבנוי ישירות בתוך ליבת ה-CPU או קרוב מאוד אליה. הוא מאחסן כמויות קטנות של נתונים והוראות שה-CPU זקוק להן באופן מיידי. הרמות השונות (L1,‏ L2,‏ L3) מייצגות פשרה: L1 הוא הקטן והמהיר ביותר, בעוד L3 הוא הגדול והאיטי ביותר, אך עדיין מהיר בסדרי גודל מ-RAM.

• RAM (זיכרון גישה אקראית): זיכרון נדיף המספק אחסון זמני גדול להוראות תוכנית ולנתונים בשימוש פעיל. הוא מבטיח שה-CPU יוכל לגשת במהירות למידע הדרוש לו במהלך הביצוע, ללא תלות מתמדת בהתקני אחסון איטיים יותר.

• אחסון (מקומי ומבוסס-רשת): האחסון שומר נתונים ותוכנות גם כשהמערכת מכובה, ומספק שמירה לטווח ארוך של מאגרי נתונים גדולים ויישומים. במחשוב ביצועים גבוהים, פתרונות האחסון חייבים לטפל בכמויות עצומות של נתונים מדעיים או אנליטיים במהירות ובאמינות. אחסון מקומי כולל כוננים מוצקים (SSD) וכוננים קשיחים (HDD), כאשר SSD מועדף בזכות השהייה נמוכה ותפוקה גבוהה. לטיפול בנתונים בקנה מידה גדול, מערכות קבצים מקביליות, אחסון רשת משותף ומערכות מבוססות-אובייקטים מאפשרות גישה מהירה על פני צמתי מחשוב רבים, בעוד ענן ואחסון ארכיוני תומכים בשמירה לטווח ארוך ובסקלאביליות.

• GPU (יחידת עיבוד גרפי): אף שבתחילה תוכנן לעיבוד גרפיקה, ה-GPU המודרני הוא מעבד מקביל רב-עוצמה. הוא נמצא בשימוש נרחב לביצוע משימות הדורשות חישובים מקביליים רבים כמו למידה עמוקה, סימולציות פיזיקליות וניתוח ביג דטה. חשוב לציין שה-GPU אינו מחליף את ה-CPU; ה-CPU מנהל לוגיקת תוכנית ברמה גבוהה וה-GPU מאיץ שלבים מקביליים מאוד.

• חיבורים/אפיקים: אלה הם נתיבי תקשורת המחברים את ה-CPU, הזיכרון, האחסון וציוד ההיקפי. האפיקים מאפשרים העברת נתונים ותיאום בין חלקי המערכת, ומבטיחים תקשורת חלקה בסביבת המחשוב. במערכות HPC, רכיבים כמו CPUs,‏ GPUs והתקני אחסון מחוברים על ידי חיבורים במהירות גבוהה המאפשרים החלפת נתונים מהירה. GPUs מתחברים בדרך כלל למערכת דרך PCIe, ממשק סטנדרטי עם מסלולי נתונים מרובים לתקשורת יעילה. לביצועים גבוהים יותר, NVLink מספק חיבור ישיר ורוחב פס גבוה בין GPUs או בין GPUs ל-CPUs, מה שמפחית השהייה ומאיץ עומסי עבודה מקביליים.

• מערכת קבצים: מערכת הקבצים מארגנת נתונים על התקני אחסון. היא מספקת מבנה לאחסון, אחזור וניהול קבצים, ומאפשרת לתוכניות ולמשתמשים לגשת למידע בצורה עקבית והגיונית.

לכל סוג משאב יש יחידות מדידה משלו הקשורות לביצועים. לדוגמה, מעבדים נמדדים בדרך כלל ב"ליבות" ו"מהירות שעון". בעת רכישת מחשב נייד, המפרטים שלו כוללים בדרך כלל את מספר הליבות. מושג דומה חל על צמתי מחשוב במרכז נתונים, שם כל צומת משויך למספר מסוים של ליבות. סביבות מחשוב הכוללות סוגי משאבים מרובים (CPUs,‏ GPUs, אפילו QPUs) מכונות סביבות מחשוב הטרוגניות. תצורות אלה מטפלות ביעילות בעומסי עבודה מגוונים על ידי מינוף החוזקות של כל סוג מעבד. לדוגמה, CPUs ישמשו למשימות כלליות ו-GPUs לעיבוד מקביל. בהקשר של ניהול משאבים ותזמון — במיוחד בסביבות מחשוב הטרוגניות — ייתכן שיהיה צורך ביחידות מדידה נוספות מעבר לאלו שתוארו כאן.

לגבי זיכרון, יחידת המדידה תהיה מגה/גיגה/טרה-בייט.

לגבי כרטיסי גרפיקה ומאיצים אחרים, יחידת המדידה תלויה בהקשר. בעוד שיכולת המחשוב האמיתית שלהם נמדדת על ידי מדדים מדויקים — מספר ליבות עיבוד, גודל זיכרון ורוחב פס זיכרון — בדיונים ברמה גבוהה על משאבי אשכול או תזמון עבודות, GPUs ומאיצים דומים ניתנים לכימות ברמת התקן לפי מספר ההתקנים השלמים המוקצים (לדוגמה, שלושה GPUs).

רשת/קישוריות/אפיקים הם היבט קריטי בכל תשתית מחשוב, שכן הם קובעים את מהירות העברת הנתונים בין רכיבי המחשוב. מה-LPU למטמון ה-CPU, ל-RAM, לכרטיסי PCI, להתקנים המחוברים ברשת — הכל הוא תקשורת, וחיוני שתהיה לנו מודל מנטלי מדויק של זה כדי לתכנן אלגוריתמים מותאמים מאוד ל-HPC.

התרחבות משאבים קלאסיים

מחשוב ביצועים גבוהים (HPC) כולל התרחבות משאבים קלאסיים אלה להשגת זמני עיבוד מהירים יותר או הגדלת הנתונים שניתן לטפל בהם בו-זמנית (לדוגמה, להגדיל את גודל מרחבי הפתרונות שניתן לחפש בהם). ניתן להשיג זאת באמצעות:

• התרחבות אנכית: הגדלת עוצמת משאבים בודדים, כגון שימוש במעבד חזק יותר או הוספת זיכרון בתוך צומת פיזי אחד, כאשר צומת הוא יחידה של אשכול מחשוב המכילה מספר משאבי מחשוב.

• התרחבות אופקית: הוספת משאבים נוספים, כגון מספר CPUs או GPUs, לעבוד יחד על צומת אחד, או — נפוץ יותר — על מספר צמתים, מה שמאפשר מחשוב מבוזר.

חלק ממושגי ההתרחבות מחלק זה יהיו רלוונטיים לחלק הבא על משאבי מחשוב קוונטיים. היבטים אחרים של משאבים קוונטיים יכומתו בדרכים חדשות.

בדוק את הבנתך

השתמש בתיאורים לעיל כדי להסיק כמה יתרונות וחסרונות של גישות ההתרחבות השונות: אנכית ואופקית?

תשובה

ייתכנו תשובות נכונות רבות. התרחבות אנכית לרוב פשוטה יותר, במיוחד אם יש לך עומסי עבודה צפויים שידרשו כמות קבועה של משאבים. אך התרחבות אנכית עשויה להיות יקרה יותר לשדרוג, שכן יחידת המחשוב הבסיסית אינה ניתנת לפירוק בקלות כמו בהתרחבות אופקית. התרחבות אופקית מורכבת יותר לניהול ולעיתים יש קשיים או השהיות הקשורות לחיבורים בין צמתים. אך היא הרבה יותר מסתגלת לדרישות משאבים משתנות ומודולרית כאשר נדרשים שדרוגים.

סוג משאב חדש: QPU (יחידת עיבוד קוונטית)

בחלק זה נציג סוג משאב חדש — משאב קוונטי — ונחקור את הגדרתו, יחידות המדידה שלו וקישוריותו לתשתית קלאסית.

הגדרת QPU

• יחידת עיבוד קוונטית (QPU): QPU כוללת את כל החומרה האחראית לקבלת ערכת הוראות קוונטיות ניתנות לביצוע, או Circuit קוונטי, ולהחזרת תשובה מדויקת.

כלומר, ה-QPU כוללת שבב קוונטי אחד או יותר (למשל Heron), רכיבים נוספים רבים במקרר הדילול כמו מגברים קוונטיים, אלקטרוניקת בקרה, ומחשוב קלאסי הנדרש למשימות כמו אחסון הוראות וצורות גל בזיכרון, צבירת תוצאות, ופענוח תיקון שגיאות עתידי. בעוד מקרר דילול נדרש לביצוע משימות אלה, אנחנו מוציאים את מקרר הדילול מהגדרה זו כדי לאפשר את המקרה של מספר QPUs באותו מקרר.

• מחשב קוונטי: מחשב קוונטי מורכב מה-QPU בתוספת המחשוב הקלאסי המארח את סביבת הריצה.

• סביבת ריצה: השילוב של חומרה ותוכנה המאפשר הרצת תוכנית.

שכבות ב-Circuit קוונטי

הן במחשוב קלאסי והן בקוונטי, תהליכים עשויים להתבצע באופן רציף או מקביל. מכיוון של-Qubit יש מרחב מצב עשיר בהשוואה לביטים קלאסיים, לעיתים הגיוני לבצע מספר Gates חד-Qubit על qubit אחד ברצף (כמו Gate מסוג R_x אחריו Gate מסוג R_z). מכיוון שהסתבכות בין qubits חיונית למחשוב קוונטי, נפוץ גם שבמעגל קוונטי יהיה סט של Gates מסתבכים הפועלים על qubits רבים. אלה וגורמים אחרים הופכים לנפוץ לזהות תהליכים שניתן לבצע במקביל בקנה מידה של פעולות Gate בודדות במעגל קוונטי. במחשוב קלאסי, מקביליות ברמת הביט אפשרית גם כן אך נחשבת פחות ברמת ה-Gate; נפוץ יותר להתייחס לתהליכים מקביליים ורציפים בקנה מידה גדול יותר.

במחשוב קוונטי, מתייחסים ל"שכבה" של Gates שכולן יכולות להתבצע בו-זמנית. ביישומים רבים שימושי לבצע סט סיבובים על כל ה-Qubits ואז Gates מסתבכים בין זוגות של qubits. בהקשרים אלה מתייחסים ל"שכבת סיבוב" (שכבה של Gates כמו R_x, R_y, ו/או R_z) ו"שכבה מסתבכת" (כמו זו עם Gates מסוג CNOT). מספר השכבות ב-Circuit הוא "עומק ה-Circuit", מדד חשוב שכן עומק גדול יותר פירושו שכבות נוספות של רעש ושגיאות מצטברות.

זיהוי שכבות של שערים חזותית עשוי להיות קשה כאשר השכבות אינן מיושרות באמצעות מחסומים. ב-Qiskit, מחסום משמש כהוראה במעגלים קוונטיים הפועלת כמפריד חזותי ואילוץ במהלך קומפילציה. הן בציור המעגל והן בביצועו, לא יועברו שערים מעבר למחסום. זה יכול להיות חשוב בהקשרים כמו ניתוק דינמי, שבו מיישמים במכוון שערים שמצטמצמים יחד לפעולת הזהות כדי לדכא סוגי שגיאות מסוימים. לפרטים נוספים על ניתוק דינמי ראה מדריך זה. להשפעה החזותית של מחסומים, השווה בין שתי התמונות הבאות של אותו מעגל, הראשונה ללא מחסומים והשנייה עם מחסומים לכפיית יישור שכבות.

אלה אותו Circuit ויש להם אותו מספר שכבות. אך בשנייה, היישור מקל לראות שיש ל-Circuit:

• שתי שכבות סיבוב: אחת סביב ציר Y ב-$\pi/5$, אחת סביב ציר Z ב-$\pi/4$.
• שלוש שכבות מסתבכות. שים לב שניתן לקרוא לכל CNOT "שכבה" בפני עצמו, מכיוון שלא ניתן לסדר מחדש את ה-CNOTs להיות מקביליים מבלי לשנות את הפעולה הלוגית.
• שתי שכבות סיבוב נוספות: אחת סביב ציר Y ב-$\pi/3$, אחת סביב ציר Z ב-$\pi/2$.
• שתי שכבות מסתבכות נוספות. שים לב שהפעם השכבה הראשונה הייתה מקובצת מעט יותר מאשר בסט הראשון של שכבות מסתבכות.

עומק כל Circuit הוא 9.

יחידות מדידה

במחשוב קוונטי, היכולות של מערכת קוונטית מתוארות לרוב באמצעות שלושה ממדים בסיסיים: היקף (scale), איכות (quality), ומהירות (speed). IBM Quantum מאפיינת ממדים אלה באמצעות שלושה מדדי חומרה שניתן להחיל על פני שיטות מחשוב קוונטי שונות: qubits הניתנים לתכנות (היקף), פעולות qubit (איכות), ומספר מקסימלי של מעגלים לשנייה (מהירות). מדדים אלה מספקים מבט ברמה גבוהה על היכולת החישובית והיעילות של מערכת על פני יישומי חומרה שונים.

• היקף (Scale) נמדד על ידי מספר ה-qubits הניתנים לתכנות. qubits הניתנים לתכנות הם ה-qubits שמשתמשים יכולים לשלוט בהם ישירות, לתפעל, למדוד ולשלב באלגוריתמים קוונטיים.

• איכות (Quality) נמדדת על ידי פעולות qubit (QuOps), מדד המתאר כמה מהפעולות התובעניות ביותר מבחינה חישובית מערכת יכולה לבצע באופן אמין לפני שהשגיאות המצטברות משתלטות על החישוב. יכולת QuOps גבוהה יותר מאפשרת בדרך כלל מעגלים עמוקים יותר ואלגוריתמים קוונטיים מתוחכמים יותר.

• מהירות (Speed) נמדדת על ידי מספר מקסימלי של מעגלים לשנייה, הידוע גם כ-throughput של מעגלים. מדד זה משקף כמה מעגלים קוונטיים שימושיים מערכת יכולה להריץ לאורך זמן, ומספק אינדיקציה ליעילות החישובית הכוללת.

מדדי חומרה נוספים משמשים לעיתים קרובות לאפיין היבטים ספציפיים של התנהגות המעבד. לדוגמה, EPLG (שגיאות לכל Gate בשכבה) ומדידות layer-fidelity מספקות תובנה לגבי איכות ה-Gates והצטברות שגיאות, בעוד ש-CLOPS (‏Circuit Layer Operations Per Second) מודד את מהירות הביצוע של עומס עבודה סטנדרטי לבנצ'מרק קוונטי. מדדים אלה נותרים שימושיים להערכת עומסי עבודה מסוימים ופרטי יישום, אך qubits הניתנים לתכנות, פעולות qubit, ומספר מקסימלי של מעגלים לשנייה מספקים מסגרת רחבה יותר להשוואת מערכות קוונטיות.

הבדלים בין מדדים קוונטיים לקלאסיים

מערכות מחשוב קלאסיות מאופיינות לעיתים קרובות באמצעות מדדים כגון FLOPS (פעולות נקודה צפה לשנייה), קיבולת זיכרון, רוחב פס זיכרון, וקצבי שעון של המעבד. ניתן לעשות כמה אנלוגיות רופפות בין אלה לבין המדדים למחשבים קוונטיים שהוצגו לעיל, אך ההבדלים בין המדדים חשובים.

מספר מקסימלי של מעגלים לשנייה יכול להיחשב כאנלוגיה רופפת למדדי ביצועים מוכווני-throughput במחשוב קלאסי, מכיוון שהוא מודד כמה עבודה שימושית מערכת קוונטית יכולה לבצע לאורך זמן. עם זאת, בניגוד ל-FLOPS, הוא מודד ביצוע של מעגלים קוונטיים ולא פעולות אריתמטיות.

CLOPS מושווה לעיתים לבנצ'מרקים של throughput קלאסי כגון FLOPS, אך עדיף להבין אותו כבנצ'מרק ספציפי לעומס עבודה ולא כמדד אוניברסלי לביצועי מחשוב קוונטי. EPLG ומדידות נאמנות קשורות מספקות תובנה לגבי מידת הדיוק שבה מעבד מבצע שכבות של Gates קוונטיים. מדדים אלה שימושיים להבנת מאפייני חומרה ספציפיים, בעוד שהמסגרת העיקרית של היקף-איכות-מהירות מספקת בסיס כללי יותר להשוואת מערכות קוונטיות. ניתן למצוא תיאורים רבים של ביצועי מחשב קוונטי בדף משאבי המחשוב ב-IBM Quantum Platform. שימו לב שבעוד שמספר ה-qubits הניתנים לתכנות הוא מספר קבוע עבור QPU נתון, מדדי המהירות והאיכות יכולים להשתנות מעט לאורך זמן עקב עדכוני כיול, תחזוקה, תנאי תפעול, ושיפורים בתשתית החומרה והתוכנה הסובבת.

יחד, מדדים משלימים אלה מסייעים בהכוונת הקצאת משאבים, תזמון, ועיצוב יישומים במערכות מחשוב קוונטי.

במקרים רבים, מערכת הקוונטום כולה מטופלת כיחידה אחת. עם זאת, כאשר משימה חורגת מקיבולת יחידה אחת — בין אם מבחינת ספירת qubits הניתנה לתכנות, עומק ה-Circuit, או throughput של Circuit — ניתן להשתמש בטכניקות כמו חיתוך/קשירה של Circuits. חיתוך Circuit הוא התהליך של פירוק משימות קוונטיות גדולות למשימות-משנה קטנות וניתנות לניהול שניתן לפזר על פני שבבים קוונטיים מרובים, המאפשר מחשוב קוונטי סקלאבילי למרות מגבלות חומרה. קשירת Circuit מתייחסת לתהליך שבא לאחר חיתוך ה-Circuit — שלב העיבוד הקלאסי שלאחר מכן ש"קושר" או משלב את התוצאות מה-Circuits המשוניים הקטנים יחדיו.

למחשבים קוונטיים אין זיכרון מסורתי, במובן של אחסון מתמיד וניתן לכתובת כמו RAM או זיכרון GPU. למשאבי מחשוב קלאסיים יש ביטים בדידים המאוחסנים בזיכרון, המאפשר שמירה, אחזור ושימוש חוזר בנתונים במהלך חישוב. משאבים קוונטיים משתמשים ב-Qubits שאינם מאחסנים זיכרון במובן הקלאסי. במקום זאת, qubits קיימים במצבים קוונטיים המייצגים סופרפוזיציות של 0 ו-1 בו-זמנית, המאפשרים מקביליות אקספוננציאלית במרחב המצבים. עם זאת, מצבי qubit הם שבירים ולא ניתן לשכפל אותם או לקרוא אותם בדרך דטרמיניסטית בשלבי ביניים מבלי לקרוס את המצב הקוונטי, לכן אין התנהגות דמויה-זיכרון מתמיד במהלך החישוב. Qubits חייבים להישאר במצב קוהרנטי לאורך כל הביצוע, ו"הזיכרון" הוא למעשה המצב הקוונטי עצמו. ניתן להשתמש בזיכרון קלאסי לצד מעבד קוונטי בלבד, לא כזיכרון קוונטי פנימי. לכך יש השלכות משמעותיות: משאבי מחשוב קלאסיים יכולים לעשות שימוש חוזר ולאחסן תוצאות ביניים בחופשיות; משאבים קוונטיים אינם יכולים לעשות זאת מבלי למדוד, דבר המשבש את החישוב.

קישוריות לתשתית קלאסית

ניתן לחבר QPUs לתשתית קלאסית דרך רשתות וממשקי תכנות יישומים שונים (APIs) המאפשרים למפתחי תוכנה לתקשר עם QPUs באופן תכנותי. APIs אלה מוסתרים בדרך כלל מאחורי ערכות פיתוח תוכנה (SDKs) וספריות (כמו Qiskit) וחשופים למדעני מחשוב בצורת הפשטות תכנות (כמו primitives, עליהן נדבר בפרק 3: מודלי תכנות).

כדאי להבחין בין שילוב הדוק ורופף של משאבים קוונטיים וקלאסיים. כיום QPUs אינם על אותו צומת כמו משאבי מחשוב קלאסיים. למעשה, QPUs אינם מחוברים כיום דרך PCIe, אלא דרך הרשת. זה עשוי להשתנות בעתיד, אך קיימים אתגרי הנדסה הקשורים לתנאי סביבה אופטימליים עבור QPUs ומשאבי מחשוב קלאסיים.

התרחבות משאבים קוונטיים

גם התרחבות משאבים קוונטיים ניתנת לסיווג כאנכית ואופקית.

• התרחבות אנכית תהיה הגדלת מספר ה-Qubits לשבב או שיפור נאמנות ההתקנים.

• התרחבות אופקית תהיה חיבור שבבים עם מצמדים או עם חיבור קלאסי.

בדוק את הבנתך

מהם האנלוגים הקוונטיים של (א) ביטים קלאסיים של מידע, ו-(ב) מהירות מעבד?

תשובה

(א) ביטים קוונטיים או qubits — יחידות מידע שבניגוד למקביליהם הקלאסיים (שיכולים לקבל רק את המצב 0 או 1), יכולים להיות בסופרפוזיציה של 0 ו-1 בו-זמנית. (ב) פעולות שכבת Circuit לשנייה או CLOPS — מספר הפעולות הרציפות שה-QPU יכול לבצע בכל שנייה, כולל ממשק מסוים עם משאבי מחשוב קלאסיים, כמו טעינת פרמטרים מה-Circuit.

ניהול משאבים

הן משאבי HPC והן משאבים קוונטיים הם יקרי ערך ומורכבים; יש לנהל אותם בזהירות. בחלק זה נסביר כיצד לנהל משאבים עבור תוכניות משתמש. ניהול משאבים בתשתית מחשוב מתייחס לתהליך של (1) תכנון, (2) הקצאה, ו-(3) שליטה/ניהול בשימוש במשאבי מחשוב כמו CPUs, זיכרון, אחסון ורוחב פס רשת להבטחת ניצול יעיל ואפקטיבי של משאבים.

תכנון — אומדן משאבים

כל תוכנית צורכת משאבים, ואומדן המשאבים הנדרשים הוא קריטי לניהול משאבים יעיל. זה כולל אומדן כמות ה-CPU, הזיכרון ומשאבים אחרים הנדרשים להרצת תוכנית. אותו הדבר ניתן לומר על משאבים קוונטיים. עם זאת, משאבים קוונטיים קיימים בקנה מידה שונה לחלוטין. מעבדים קוונטיים IBM Quantum® Heron r3 מכילים 156 qubits, לעומת מיליארדי ביטים קלאסיים רבים במחשב נייד נפוץ. זמן ועלות הם גם שיקולים. כיום, ל-IBM Quantum יש תוכנית חינמית, תוכנית Open Plan, המאפשרת למשתמשים לחקור מחשוב קוונטי תוך שימוש ב-10 דקות של זמן QPU לחודש. חלק מארגוני המחקר דורשים כל כך הרבה זמן QPU שיש להם מחשב קוונטי IBM ייעודי בשטחם.

שלב אחד באומדן משאבים הייחודי למחשוב קוונטי הוא עומק ה-Circuit. כפי שהוזכר קודם, כל Gate קוונטי וכל זמן עיכוב בין פעולות מגיעים עם רעש והסתברות מסוימת לשגיאה. ככל שה-Circuit הקוונטי עמוק יותר, כך הרעש גדול יותר. יש שני ניואנסים לכך: ל-Gates דו-Qubit יש שיעורי שגיאה גבוהים הרבה יותר מאשר ל-Gates חד-Qubit, לכן לעיתים קרובות ניתן להתעלם מהעומק החד-Qubit. יתר על כן, לא כל ה-Qubits על שבב קוונטי מחוברים ישירות. לפעמים מידע צריך להיות מוחלף מ-Qubit ל-Qubit כדי לבצע את ההסתבכויות הנדרשות, ותהליך ההחלפה עצמו דורש Gates דו-Qubit. ההחלפה הזאת מטופלת בתהליך הנקרא "טרנספילציה", תהליך מורכב שמשרת מטרות נוספות גם כן; על כך מדובר בפירוט בשיעור הבא. הגודל המגביל הרלוונטי הוא לכן עומק הדו-Qubit המטרנספל. העומק המרבי הספציפי שבו ניתן להשיג תוצאות בנאמנות גבוהה תלוי ב-Circuit. אך תוך מינוף טכניקות מודרניות להפחתת שגיאות, ניתן להשיג תוצאות בנאמנות גבוהה עם עומקי דו-Qubit מטרנספלים של 80 ומעלה.

הקצאה — תזמון

תזמון הוא תהליך הקצאת משאבים לתוכניות וניהול ביצוען. זה כולל:

• הגשת עבודה: התהליך שבו משתמש שולח בקשה (עבודה) למערכת HPC, תוך ציון אילו עבודה חישובית ומשאבים נדרשים לביצוע.
• הקצאת משאבים: ההקצאה של משאבי מערכת HPC זמינים (כגון צמתים, CPUs, זיכרון) לעבודה שהוגשה בהתאם לדרישותיה.
• ביצוע עבודה: ההרצה בפועל של המשימות החישוביות שהוגדרו על ידי העבודה על משאבי ה-HPC המוקצים.

קיימים אנלוגים לכל התהליכים הללו עבור מחשבים קוונטיים.

• עבודות מוגשות על ידי המשתמש, תוך מינוף IBM Quantum Compute Service, ובדרך כלל באמצעות primitive של IBM Quantum, כמו Sampler, Estimator, או אחרים.
• המשתמש בוחר מרשימת Backends שיש לו גישה אליהם. הרשימה המלאה של Backends זמינים ניתן לראות בדף משאבי מחשוב ב-IBM Quantum Platform. נפוץ פשוט להשתמש במחשב הקוונטי הפנוי ביותר. אך ישנם מקרים שבהם יכול להיות חשוב להשתמש בספציפי בגלל שיקולי פריסת התקן, שכפול חישובים קודמים, וכן הלאה.
• ביצוע עבודות קוונטיות דומה למקרה HPC. אף שכמה הבדלים כבר הוזכרו, כמה שווה לחזור עליהם כאן. QPUs אינם ממוקמים כיום בדרך כלל על אותו צומת כמו משאבי מחשוב קלאסיים אלא מחוברים דרך רשת. לכך עשויות להיות השלכות על תזמון. יתרה מכך, למחשבים קוונטיים עשויים להיות זמני תור משמעותיים, וזמני התור הללו משתנים, מה שמקשה על שליטה מדויקת בתזמון. מצב זה עשוי להיות שונה עבור מערכות ייעודיות; זה תלוי בניהול הפנימי של המחשב הקוונטי.

שליטה/ניהול — ניהול עומסי עבודה

ניהול עומסי עבודה, המכונה גם תזמור, הוא תהליך ניהול תוכניות מרובות ודרישות המשאבים שלהן. זה כולל:

• אספקת משאבים: התהליך של הכנת משאבי HPC והפיכתם לזמינים ומוכנים לשימוש על ידי עבודות, כולל הגדרת חומרה ותוכנה. כפי שנראה בהמשך, QPUs הם משאבי מחשוב שניתן לספק אותם בדומה למשאבי HPC קלאסיים, עם הסתייגויות מהחלק הקודם.
• תזמון עבודות: פעילות תוכנת המתזמן בהחלטה אילו עבודות מורצות, מתי, ועל אילו משאבים, תוך ניהול עדיפויות ותורים לניצול יעיל של מערכת ה-HPC. אף שהצהרה רחבה זו חלה על משאבים קוונטיים, ייתכן שיהיה פחות שליטה על תזמון מאשר עם משאבים אחרים.

Example:

שקול משימה מוכרת כהקשר להבנת ניהול משאבים: מציאת הגורמים הראשוניים של מספרים גדולים. נניח עוד שהאלגוריתם בשימוש מסתמך על בדיקה כוחנית של כל מחלק פוטנציאלי. בעוד שזו לרוב אינה השיטה היעילה ביותר, קל להבין כיצד עומס העבודה עשוי להיות מנוהל.

תכנון — אומדן משאבים

• אמוד כמה זמן CPU וזיכרון פירוק הגורמים הראשוניים עשוי לדרוש.

• תכנן את המקבוליזציה של משימתך — כמה CPUs/ליבות תשתמש?

הקצאה — תזמון

• עם הגשת העבודה, המתזמן מקצה ליבות CPU וזיכרון למשימת פירוק הגורמים הראשוניים. לדוגמה, הוא עשוי להקצות את כל המחלקים הפוטנציאליים המסתיימים בספרות 1, 3, 7, 9 לאחת מארבע ליבות, בהתאמה.

• ביצוע עבודה: אלגוריתם פירוק הגורמים הראשוניים מורץ, מבצע חלוקות או שלבי פירוק אחרים על המשאבים המוקצים עד להשלמת המשימה.

שליטה/ניהול — ניהול עומסי עבודה

• המערכת מתזמרת את הסדר והתזמון של עבודות פירוק הגורמים הראשוניים לאופטימיזציה של תפוקה.

• המקרה הקל ביותר לדמיין הוא שאחת הליבות מוצאת את הגורם הראשוני המבוקש. זה צריך לעצור את החישוב על ליבות אחרות כדי שיוכלו לשמש למשימה הבאה.

סביבות מחשוב עתיר ביצועים (HPC) משתמשות בתוכנה מיוחדת לביצוע שלבים אלה וניהול משאבים. בחלק הבא נלמד על מערכת ניהול משאבים מאומצת באופן נרחב: Slurm.

דוגמה עם משאבים קוונטיים:

זרימת עבודה שתהיה נושא שיעורים אחרים בקורס זה היא קביעת מצבי יסוד ואנרגיות כימיות תוך שימוש בלכסון קוונטי מבוסס מדגם (SQD). נושא זה מכוסה ביתר פירוט בשיעור 4, וניתן גם לבקר קורס זה על SQD ושיטות קשורות ב-IBM Quantum Learning. כל מה שאנחנו צריכים לדעת לדיון זה הוא שזרימת העבודה כוללת את הדברים הבאים:

• הכנת Circuit קוונטי
• מדידת ה-Circuit הקוונטי
• שימוש בתוצאות המדידה להקרנת הבעיה לתת-מרחב שימושי
• לכסון מטריצה קטנה יותר ומוקרנת באמצעות משאבי מחשוב קלאסיים
• איטרציה, בין אם להבטחת עקביות עצמית דרך שיקולים כמו שימור מטען, ואיטרציות אפשריות של ה-Circuit הקוונטי אם יש לו פרמטרים ורייאציוניים.

תכנון — אומדן משאבים

• מפה את המסלולים האלקטרוניים ל-Qubits כדי לקבוע את מספר ה-Qubits הדרושים לך.

• שלב את ההמילטוניאן הממופה של המערכת והמצב (האפשרי ורייאציוני) ל-Circuit קוונטי ובדוק את עומק הדו-Qubit המטרנספל. ודא שהוא סביר.

• אמוד את גודל תת-המרחב שאליו תקרין; מכך, אמוד כמה זמן CPU וזיכרון הלכסון עשוי לדרוש.

• תכנן את המקבוליזציה של משימתך — כמה CPUs/ליבות תשתמש?

הקצאה — תזמון

• המשתמש בוחר את ה-QPU; תהליך הטרנספילציה ממפה אוטומטית qubits ב-Circuit הקוונטי המופשט שלך ל-Qubits פיזיים על ה-QPU. זה חשוב מכיוון שה-Circuit המופשט עשוי להניח קישוריות ישירה שאינה קיימת על השבב, בין שיקולים אחרים.

• עם הגשת העבודה דרך Quantum Compute, העבודה נכנסת לתור של ה-QPU שנבחר. למשתמש אין שליטה על זמן התור, אם כי זה עשוי להיות שונה עבור מערכות ייעודיות.

• משאבי מחשוב קלאסיים ממתינים לתוצאות הקוונטיות.

• עבודת לכסון מוגשת למשאבי HPC; עם הגשת העבודה, המתזמן מקצה ליבות CPU וזיכרון למשימת הלכסון.

• ביצוע עבודה: אלגוריתם הלכסון מורץ, מלכסן את המטריצה המוקרנת הקטנה יותר עד להשלמת המשימה.

שליטה/ניהול — ניהול עומסי עבודה

• המערכת מתזמרת את הסדר והתזמון של שלבים קוונטיים וקלאסיים לאורך כל התהליך. לדוגמה, לאחר שהמטריצה המוקרנת לוכסנה ואנרגיית מצב היסוד התקבלה, בהתאם לקריטריוני התכנסות, זרימת העבודה עשויה לחזור ל-Circuit קוונטי חדש (עם פרמטר ורייאציוני חדש).

• כאשר אנרגיית מצב היסוד עומדת בקריטריוני ההתכנסות, החישוב בכל הליבות נעצר.

סביבות מחשוב עתיר ביצועים (HPC) משתמשות בתוכנה מיוחדת לביצוע שלבים אלה וניהול משאבים. בחלק הבא נלמד על מערכת ניהול משאבים מאומצת באופן נרחב: Slurm. חשוב לציין של-Slurm אין כלים לכל השלבים שתוארו לעיל. Slurm אינו מספק תמיכה לתכנון עבודות, ולא לניהול עומסי עבודה מפורט כמו תקשורת בין רכיבי עומס עבודה. זה מתאים היטב למצב הנוכחי של מחשוב קוונטי ב-HPC, שכן QPUs נגישים בדרך כלל דרך הרשת.

בדוק את הבנתך

נניח שאתה מנסה לחפש במסד נתונים לא ממוין כדי למצוא אלמנט שנקרא לו 'המטרה'. עבור כל אחת מהפעולות הבאות, ציין לאיזה שלב של ניהול משאבים היא מתאימה:

(א) אמידת גודל מסד הנתונים והזמן הנדרש לבדיקת כל אלמנט

(b) הבטחה שמציאת המטרה על GPU אחד עוצרת את התהליך ב-GPUs אחרים כדי לפנות אותם לבעיה הבאה

(c) חלוקת מרחב החיפוש לאזורים עבור כל אחד מה-GPUs שלכם (נניח 10) לחיפוש

תשובה

(a) Planning

(b) שליטה/ניהול

(c) הקצאה/תזמון

תוכנה: Slurm

בחלק זה נישם את המושגים שלמדנו בפרק זה ונתרגל שימוש במערכת ניהול המשאבים הפופולרית, Slurm.

מבוא ל-Slurm

Slurm היא מערכת ניהול משאבים בקוד פתוח, בשימוש נרחב בסביבות מחשוב ביצועים גבוהים. היא מספקת סט כלים מקיף לניהול משאבים, תזמון עבודות ומעקב אחר ביצועי המערכת.

נסקור את יסודות השימוש ב-Slurm, כולל:

• הגשת עבודות
• הקצאת משאבים
• מעקב אחר עבודות

מאחר שקשה מאוד לספק משאבי HPC לכל סטודנט בקורס זה, נעשה קצת רמאות ונספק לכם מאגר עם תמונות Docker המדמות אשכול HPC אמיתי עם Slurm, אך בקנה מידה קטן. זה יעזור לנו לתרגל את המושגים הנלמדים בסביבות בטוחות וניתנות לשחזור.

שימו לב שכרגע כל המשאבים הקוונטיים והקלאסיים מוקצים לכל משך הניסוי כולו. כרגע אין הקצאה משולבת של משאבים מעורבים. הסתייגות נוספת היא שגם לאחר שהעבודה מתחילה, המערכת הקוונטית לא תישלט ישירות כפי שמשתמש HPC מנוסה עשוי לצפות. העבודה מופעלת על צומת x86 שרירותי, המריץ את IBM Quantum Compute Service, ואותו שירות runtime מתחבר למתזמן אחר שאין למשתמש שליטה ישירה עליו. תהליך עבודה זה ובעיות קשורות עשויים להיות מוכרים למשתמשי HPC שצברו ניסיון מוקדם בגישה בלעדית לצמתי GPU (השימוש המקורי ב-gres).

הוראות התקנה וסקירת ההגדרה

כדי לתרגל שילוב משאבים קוונטיים ו-HPC, תצטרכו גישה לסביבת HPC אמיתית או לדמות סביבת HPC על המחשב המקומי שלכם. מדריך התקנה להגדרה מקומית באמצעות Docker נמצא במאגר זה. המדריך מקשר לתמיכה בהגדרת חשבון IBM Cloud® והתקנת תוסף SPANK עבור QRMI. גם באותו מאגר ישנם מספר קבצי Python לבדיקת הסביבה שלכם.

לאחר שסיימתם את ההתקנה, נשתמש בפקודה למטה כדי לבדוק את משאבי החישוב של Slurm בטרמינל שלכם. אם ההתקנה הצליחה, תוכלו לאשר סך של שלושה צמתים וירטואליים.

$ sinfo

PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
normal      up 5-00:00:00     2  idle c[1-2]
quantum*    up   infinite     1  idle q1

$ scontrol show node

NodeNAME=q1 Arch=x86_64 CoresPerSocket=1
CPUAlloc=0 CPUTot=1 CPULoad=0.34
AvailableFeatures=(null)
ActiveFeatures=(null)
Gres=qpu:1
NodeAddr=q1 NodeHostName=q1 Version=21.08.6
...

יש לנו שתי מחיצות או קבוצות צמתים: normal ו-quantum. מחיצת normal מורכבת מצמתים עם גישה למשאבים קלאסיים בלבד. למחיצת quantum יש גישה למשאבים קוונטיים. תוכלו לראות את הפרטים של כל צומת על ידי הרצת scontrol show nodes.

הרצת דוגמת hello world פשוטה ב-Slurm

נתחיל עם הרצת דוגמת hello world קלאסית פשוטה עם Slurm. נשתמש ב-Python לדוגמאות. ניצור קובץ hello_world.py, שמסביר את עצמו.

$ vim hello_world.py

import time
time.sleep(10)
print("Hello, World!")
~

כעת עלינו לאמר למנהל המשאבים אילו משאבים נדרשים להרצת תוכנית זו. Slurm מספקת דרך לציין את כל המטא-נתונים של העבודה דרך סקריפט הגשה, שהוא פשוט סקריפט shell עם הערות ייחודיות ל-Slurm. הערות אלה מאפשרות לציין דרישות משאבים, פרמטרי תזמון ועוד. ניצור סקריפט shell בשם hello_world.sh לכך.

$ vim hello_world.sh

#SBATCH --job-name=hello-world
#SBATCH --output=hello-world.out
#SBATCH --nodes=1
#SBATCH --ntasks-per-node=1
#SBATCH --cpus-per-task=1
#SBATCH --partition=normal

srun hello_world.py
~

נעבור על קובץ ההגשה ונראה מה קורה שם.

הוראות #SBATCH הן הערות ייחודיות לציון הדרישות שלנו להרצת התוכנית. כאן ניתן לציין את כמות המשאבים — מספר הצמתים, מספר המשימות לכל צומת, מספר המשימות ומעבדים לכל צומת ומשימה — ואפשרויות נוספות כמו שם קובץ הפלט. רשימה מלאה של אפשרויות זמינה בתיעוד של Slurm.

הגיע הזמן להריץ את עבודת Slurm שלנו. sbatch היא פקודה המקבלת קובץ הגשה ומכניסה את העבודה לתור להרצה ב-Slurm.

$ sbatch hello_world.sh

Submitted batch job 63

נבדוק את מצב התוכנית שלנו באמצעות הפקודה squeue.

$ squeue

#             JOBID PARTITION     NAME         USER ST       TIME  NODES NODELIST(REASON)
#                 1 main          hello_world  root R        0:01      1 c1

לאחר שהעבודה מסתיימת, נוכל לבדוק את התוצאה על ידי עיון בקובץ הפלט.

$ cat hello_world_logs.txt
Hello, World!

בדקו את ההבנה שלכם

בהינתן סקריפט ה-shell של Slurm למטה, מה הם (א) שם העבודה, (ב) שם קובץ ה-Python, ו-(ג) שם קובץ הפלט? (ד) לבסוף, האם ניתן להשתמש כאן במשאבים קוונטיים?

vim hello_learner.sh

#SBATCH --job-name=hello-learner
#SBATCH --output=hello-learner.out
#SBATCH --nodes=1
#SBATCH --ntasks-per-node=1
#SBATCH --cpus-per-task=1
#SBATCH --partition=quantum

srun hello_learner_qm.py

תשובה

(a) hello-learner

(b) hello-learner_qm.py

(c) hello-learner.out

(d) כן, ניתן. הוא משתמש במחיצה הקוונטית (quantum partition).

הרצת דוגמת Qiskit hello world פשוטה ב-Slurm

עכשיו, בואו ננסה להשתמש גם במשאבים קוונטיים. ניצור ונריץ תוכנית "Hello, Qiskit" פשוטה המשתמשת במשאבים קוונטיים.

$ vim hello_qiskit.py

# hello_qiskit.py
from qiskit import QuantumCircuit
from qiskit.quantum_info import SparsePauliOp
from qiskit.transpiler import generate_preset_pass_manager
from qiskit_ibm_runtime import EstimatorV2 as Estimator

# Create a new circuit with two qubits
qc = QuantumCircuit(2)

# Add a Hadamard gate to qubit 0
qc.h(0)

# Perform a controlled-X gate on qubit 1, controlled by qubit 0
qc.cx(0, 1)

observables_labels = ["IZ", "IX", "ZI", "XI", "ZZ", "XX"]
observables = [SparsePauliOp(label) for label in observables_labels]

# switch to QRMI service
from qiskit_ibm_runtime import QiskitRuntimeService

service = QiskitRuntimeService()

backend = service.backend("...")

# Convert to an ISA circuit and layout-mapped observables.
pm = generate_preset_pass_manager(backend=backend, optimization_level=1)
isa_circuit = pm.run(qc)

# Construct the Estimator instance.

estimator = Estimator(mode=backend)
estimator.options.resilience_level = 1
estimator.options.default_shots = 5000

mapped_observables = [
    observable.apply_layout(isa_circuit.layout) for observable in observables
]

# One pub, with one circuit to run against five different observables.
job = estimator.run([(isa_circuit, mapped_observables)])

job_result = job.result()

pub_result = job.result()[0]

print("Result", pub_result)

כאן נשתמש בממשק ניהול המשאבים הקוונטיים (QRMI), תוסף Slurm SPANK לתמיכה במשאבים ועבודות קוונטיות שפותח במשותף על ידי IBM, Pasqal, מרכז Hartree ו-RPI. יצרנו Circuit פשוט מסוג pauli-2-design עם ערכים ראשוניים אקראיים ו-observable פשוט, ונריץ אותו באמצעות Estimator כדי לקבל את ערך התוחלת. להרצה נצטרך שוב את סקריפט ההגשה hello_qiskit.sh, שידרוש משאבים קוונטיים.

$ vim hello_qiskit.sh

#SBATCH --job-name=hello-qiskit
#SBATCH --output=hello_qiskit.out
#SBATCH --nodes=1
#SBATCH --ntasks-per-nodes=1
#SBATCH --cpus-per-task=1
#SBATCH --partition=quantum
#SBATCH --gres=qpu:1

srun python /data/ch2/hello_qiskit/hello_qiskit.py
~

נעבור על קובץ ההגשה ונראה מה קורה שם. יש לנו אפשרות חדשה אחת, והיא gres. gres היא אפשרות Slurm להגדרת משאבים חישוביים נוספים. במקרה שלנו, המשאב החדש הוא המשאב הקוונטי שלנו. מאחר שציינו את המשאבים ואת המחיצה באשכול שבה זמינים משאבים קוונטיים, ה-primitives של IBM Quantum ישתמשו במשאבים המוקצים הללו להרצת העומס הקוונטי.

הגיע הזמן להריץ את עבודת Slurm שלנו.

$ sbatch hello_qiskit.sh

לאחר מכן, נבדוק את מצב התוכנית שלנו באמצעות הפקודה squeue.

$ squeue
#             JOBID PARTITION     NAME         USER ST       TIME  NODES NODELIST(REASON)
#                 1 main          hello_qiskit  root R        0:01      1 q1

נוכל לעיין בלוגים ובתוצאות לאחר שהעבודה מסתיימת.

$ cat hello_qiskit.out | grep Exp
Expectation Value: 0.8372900070983516

סיכום

עד כה, למדנו מהם משאבי חישוב וכיצד להשתמש בהם להרצת תוכניות בסביבות הטרוגניות. יצרנו והרצנו שתי תוכניות 'Hello World' פשוטות: אחת למשאב הקלאסי ואחרת למשאב קוונטי, ולמדנו כיצד ליצור סקריפטי shell להגשת משימות וצפייה בתוצאות.

בשיעור הבא, נשתמש בידע זה על שליטה במשאבים כדי ליישם מודלי תכנות על המשאבים שרכשנו במהלך הרצת העבודה.

כל הקוד והסקריפטים המשמשים בפרק זה זמינים עבורכם במאגר GitHub שלנו.