موارد الحوسبة وإدارتها

نموذج الموارد والموارد الكلاسيكية

في هذا القسم، سنقدم إطاراً للتفكير في بيئات الحوسبة يمكن تطبيقه على الحاسب المحمول وتوسيعه ليشمل الحواسيب العملاقة. بنهاية هذا القسم، ستفهم المكوّنات الأساسية لبيئة الحوسبة وكيف ترتبط ببعضها. وقد شرح Iskandar Sitdikov كل هذا في الفيديو التالي.

نموذج الموارد

أي بيئة حوسبة كلاسيكية تتكوّن من عدة موارد مترابطة تعمل معاً لتشغيل التطبيقات بكفاءة. وتشمل الموارد الرئيسية عادةً:

• وحدة المعالجة المركزية (CPU): هي وحدة المعالجة الأساسية التي تفسّر تعليمات البرنامج وتنفّذها. وهي تتعامل مع عمليات المنطق والحساب والتحكم، وتعمل بشكل أساسي بوصفها "دماغ" النظام.

• ذاكرة تخزين مؤقت للمعالج (L1, L2, L3): هي الأسرع في النظام، مدمجة مباشرةً في قلب المعالج أو بالقرب منه جداً. وتخزّن أجزاءً صغيرة من البيانات والتعليمات التي يحتاجها المعالج على الفور. المستويات المختلفة (L1, L2, L3) تمثّل مقايضةً: L1 هي الأصغر والأسرع، بينما L3 هي الأكبر والأبطأ، لكنها لا تزال أسرع بمراحل من ذاكرة الوصول العشوائي RAM.

• ذاكرة الوصول العشوائي (RAM): ذاكرة مؤقتة توفر تخزيناً كبيراً لتعليمات البرنامج والبيانات المستخدمة بنشاط. وهي تضمن أن يتمكن المعالج من الوصول السريع إلى المعلومات التي يحتاجها أثناء التنفيذ دون الاعتماد المستمر على أجهزة التخزين الأبطأ.

• التخزين (المحلي والمستند إلى الشبكة): يحتفظ التخزين بالبيانات والبرامج حتى عند إيقاف تشغيل النظام، مما يوفر استمراريةً طويلة الأمد للبيانات الضخمة والتطبيقات. في الحوسبة عالية الأداء، يجب أن تتعامل حلول التخزين مع كميات هائلة من البيانات العلمية أو التحليلية بسرعة وموثوقية. يشمل التخزين المحلي محركات الأقراص الصلبة (SSD وHDD)، وتُفضَّل أقراص SSD لانخفاض زمن الاستجابة وارتفاع معدل النقل. أما للتعامل مع البيانات الضخمة، فتتيح أنظمة الملفات المتوازية وتخزين الشبكة المشترك والأنظمة القائمة على الكائنات وصولاً سريعاً عبر عقد الحوسبة المتعددة، فيما تدعم طبقات التخزين السحابي والأرشيفي الاحتفاظ بالبيانات لفترات طويلة وقابلية التوسع.

• وحدة معالجة الرسومات (GPU): رغم أنها صُمِّمت في البداية لعرض الرسوم، إلا أن وحدات GPU الحديثة هي معالجات متوازية قوية. وتُستخدم على نطاق واسع للمهام التي تتطلب حسابات متزامنة كثيرة مثل التعلم العميق ومحاكاة الفيزياء وتحليلات البيانات الضخمة. ومن المهم ملاحظة أن GPU لا تحل محل CPU؛ فالـCPU تتولى المنطق البرمجي الرفيع المستوى بينما تسرّع GPU الخطوات المتوازية عالياً.

• الاتصالات/الحافلات (Connections/Busses): هي مسارات الاتصال التي تربط المعالج والذاكرة والتخزين والأجهزة الطرفية. تتيح هذه الحافلات نقل البيانات والتنسيق بين أجزاء النظام، مما يضمن تواصلاً سلساً عبر بيئة الحوسبة. في أنظمة HPC، ترتبط مكوّنات مثل وحدات CPU وGPU وأجهزة التخزين بوصلات عالية السرعة تتيح تبادل البيانات بسرعة. تتصل وحدات GPU بالنظام عادةً عبر PCIe، وهي واجهة قياسية بمسارات بيانات متعددة لتواصل فعّال. لتحقيق أداء أعلى، يوفر NVLink رابطاً مباشراً وعالي النطاق الترددي بين وحدات GPU أو بينها وبين CPU، مما يقلل زمن الاستجابة ويسرّع أعباء العمل المتوازية.

• نظام الملفات (Filesystem): ينظّم نظام الملفات البيانات على أجهزة التخزين. ويوفر بنيةً لتخزين الملفات واسترجاعها وإدارتها، مما يتيح للبرامج والمستخدمين الوصول إلى المعلومات بطريقة منسقة ومنطقية.

لكل نوع من الموارد وحداته الخاصة في قياس الأداء. فمثلاً، يُقاس المعالج عادةً بـ"النوى" و"سرعة الساعة". عند شراء حاسب محمول، تتضمن مواصفاته عادةً عدد النوى. وتنطبق فكرة مماثلة على عقد الحوسبة في مراكز البيانات، حيث تُرتبط كل عقدة بعدد محدد من النوى. تُعرف بيئات الحوسبة التي تشمل أنواعاً متعددة من الموارد (CPU وGPU وحتى QPU) باسم بيئات الحوسبة غير المتجانسة. تتعامل هذه البيئات مع أعباء العمل المتنوعة بكفاءة أكبر من خلال الاستفادة من نقاط قوة كل نوع من المعالجات. فمثلاً، تُستخدم وحدات CPU للمهام العامة ووحدات GPU للمعالجة المتوازية. وفي سياق إدارة الموارد والجدولة — خاصةً لبيئات الحوسبة غير المتجانسة — قد تكون هناك حاجة إلى وحدات قياس إضافية جانباً للوحدات الموضحة هنا.

بالنسبة للذاكرة، وحدة القياس هي ميغابايت/جيجابايت/تيرابايت.

بالنسبة لبطاقات الرسومات والمعجّلات الأخرى، تعتمد وحدة القياس على السياق. في حين تُقاس قدرتها الحقيقية بمقاييس دقيقة — عدد نوى المعالجة وحجم الذاكرة وعرض النطاق الترددي للذاكرة — إلا أنه في المناقشات الرفيعة المستوى حول موارد الكتلة أو جدولة المهام، يمكن قياس وحدات GPU والمعجّلات المماثلة على مستوى الجهاز من خلال عدد الأجهزة الكاملة المخصصة (على سبيل المثال، ثلاث وحدات GPU).

تُعدّ الشبكة/الاتصالات/الحافلات جانباً أساسياً في أي بنية تحتية للحوسبة، إذ تحدد سرعة نقل البيانات بين مكوّنات الحوسبة. من المعالج إلى ذاكرته التخزينية المؤقتة، مروراً بالـRAM وبطاقات PCI وصولاً إلى الأجهزة المتصلة بالشبكة؛ كل شيء هو تواصل، ومن الضروري أن يكون لديك نموذج ذهني دقيق عنه لتصميم خوارزميات محسّنة للغاية في HPC.

توسيع نطاق الموارد الكلاسيكية

تتضمن الحوسبة عالية الأداء (HPC) توسيع نطاق هذه الموارد الكلاسيكية لتحقيق أوقات معالجة أسرع أو زيادة البيانات التي يمكن التعامل معها في آنٍ واحد (مثلاً، لزيادة حجم فضاءات الحلول التي يمكن البحث فيها). ويمكن تحقيق ذلك من خلال:

• التوسع الرأسي: زيادة قوة الموارد الفردية، مثل استخدام معالج أكثر قوةً أو إضافة مزيد من الذاكرة داخل عقدة فيزيائية واحدة، حيث العقدة هي وحدة في كتلة الحوسبة تجمع موارد حوسبة متعددة.

• التوسع الأفقي: إضافة المزيد من الموارد، مثل وحدات CPU أو GPU متعددة، للعمل معاً على عقدة واحدة أو — بشكل أكثر شيوعاً — على عقد متعددة، مما يتيح الحوسبة الموزّعة.

بعض مفاهيم التوسع من هذا القسم ستنطبق على القسم التالي حول موارد الحوسبة الكمية. وستُقاس بعض الجوانب الأخرى للموارد الكمية بطرق جديدة.

تحقّق من فهمك

استخدم الأوصاف أعلاه لاستنتاج بعض مزايا وعيوب مناهج التوسع المختلفة: الرأسي والأفقي؟

الإجابة

قد تكون هناك إجابات صحيحة كثيرة. التوسع الرأسي غالباً أبسط، خاصةً إذا كانت أعباء عملك متوقعة وتحتاج إلى كمية موارد ثابتة. لكنه قد يكون أغلى ثمناً للترقية، إذ لا يمكن تقسيم الوحدة الأساسية للحوسبة بسهولة كما في التوسع الأفقي. أما التوسع الأفقي فأكثر تعقيداً في الإدارة وقد تواجه أحياناً صعوبات أو تأخيرات تتعلق بالاتصالات بين العقد. لكنه أكثر مرونةً لمتطلبات الموارد المتغيرة وهو معياري عند الحاجة إلى الترقيات.

نوع جديد من الموارد: وحدة المعالجة الكمية (QPU)

في هذا القسم، سنتعرف على نوع جديد من الموارد — المورد الكمي — ونستكشف تعريفه ووحدات قياسه واتصاله بالبنية التحتية الكلاسيكية.

تعريف وحدة المعالجة الكمية (QPU)

• وحدة المعالجة الكمية (QPU): تشمل QPU جميع الأجهزة المسؤولة عن قبول مجموعة تعليمات كمية قابلة للتنفيذ، أو دائرة كمية، وإعادة إجابة دقيقة.

وهذا يعني أن QPU تشمل شريحة كمية واحدة أو أكثر (مثل Heron)، والمكوّنات الإضافية المتعددة في مبرد التخفيف كالمضخّمات الكمية وإلكترونيات التحكم والحوسبة الكلاسيكية اللازمة لمهام مثل الاحتفاظ بالتعليمات والموجات في الذاكرة وتجميع النتائج وفك ترميز تصحيح الأخطاء مستقبلاً. وبينما يُعدّ مبرد التخفيف ضرورياً لأداء هذه المهام، نستبعده من هذا التعريف لإتاحة إمكانية وجود عدة وحدات QPU في نفس المبرد.

• الحاسوب الكمي: الحاسوب الكمي يتألف من QPU بالإضافة إلى الحوسبة الكلاسيكية التي تستضيف بيئة التشغيل.

• بيئة التشغيل: مزيج من الأجهزة والبرامج الذي يجعل تشغيل البرنامج ممكناً.

الطبقات في الدوائر الكمية

في كل من الحوسبة الكلاسيكية والكمية، يمكن تنفيذ العمليات بشكل متسلسل أو متوازٍ. نظراً لأن الكيوبتات تمتلك فضاء حالة أغنى مقارنةً بالبتات الكلاسيكية، فمن المنطقي أحياناً تنفيذ بوابات أحادية الكيوبت متعددة على كيوبت بشكل متسلسل (مثل بوابة R_x متبوعةً ببوابة R_z). بما أن التشابك بين الكيوبتات أمر محوري في الحوسبة الكمية، فمن الشائع أيضاً أن تحتوي الدائرة الكمية على مجموعة بوابات تشابك تعمل عبر كيوبتات كثيرة. تجعل هذه العوامل وغيرها من الشائع تحديد العمليات التي يمكن تنفيذها بالتوازي على مستوى عمليات البوابات المفردة في الدائرة الكمية. في الحوسبة الكلاسيكية، التوازي على مستوى البت ممكن أيضاً لكنه أقل شيوعاً في الاعتبار على مستوى البوابة؛ الأكثر شيوعاً هو الإشارة إلى العمليات المتوازية والمتسلسلة على نطاق أوسع.

في الحوسبة الكمومية، يُشار إلى "طبقة" من البوابات يمكن تنفيذها جميعًا في آن واحد. في العديد من التطبيقات يكون من المفيد إجراء مجموعة من الدورانات على جميع الكيوبتات ثم بوابات تشابك بين أزواج من الكيوبتات. في هذه السياقات، يُشار إلى "طبقة دوران" (طبقة من بوابات مثل R_x، وR_y، و/أو R_z) و"طبقة تشابك" (مثل واحدة تحتوي على بوابات CNOT). عدد الطبقات في دائرة ما هو "عمق الدائرة"، وهو مقياس مهم لأن العمق الأكبر يعني المزيد من طبقات الضوضاء والأخطاء المتراكمة.

قد يكون تحديد طبقات البوابات بصرياً أمراً صعباً حين لا تكون الطبقات محاذاةً باستخدام الحواجز. في Qiskit، يعمل الحاجز كتعليمة في الدوائر الكمية تعمل كفاصل بصري وقيد أثناء الترجمة. سواء في رسم الدائرة أو تنفيذها، لن تنتقل أي بوابات عبر الحاجز. وهذا مهم في سياقات مثل فك الاقتران الديناميكي، حيث يُنفَّذ عمداً بوابات تبسّط إلى هوية لقمع أنواع معينة من الأخطاء. لمزيد من المعلومات حول فك الاقتران الديناميكي راجع هذا الدليل. للاطلاع على التأثير البصري للحواجز، قارن هاتين الصورتين لنفس الدائرة، الأولى بدون حواجز والثانية مع حواجز لإجبار محاذاة الطبقات.

هذه هي نفس الدائرة ولها نفس عدد الطبقات. لكن في الثانية، تجعل المحاذاة من السهل رؤية أن الدائرة تحتوي على:

• طبقتان للدوران: إحداهما حول محور Y بمقدار $\pi/5$، والأخرى حول محور Z بمقدار $\pi/4$.
• ثلاث طبقات تشابك. لاحظ أنه يمكن اعتبار كل CNOT "طبقة" قائمة بذاتها، إذ لا يمكن إعادة ترتيب وحدات CNOT لتكون متوازيةً دون تغيير العملية المنطقية.
• طبقتان إضافيتان للدوران: إحداهما حول محور Y بمقدار $\pi/3$، والأخرى حول محور Z بمقدار $\pi/2$.
• طبقتان إضافيتان للتشابك. لاحظ أن الطبقة الأولى هذه المرة لُوازيت بشكل أكثر قليلاً مقارنةً بالمجموعة الأولى من طبقات التشابك.

عمق كل دائرة هو 9.

وحدات القياس

في الحوسبة الكمومية، غالبًا ما تُوصف قدرات نظام كمومي باستخدام ثلاثة أبعاد أساسية: المقياس، والجودة، والسرعة. يميّز IBM Quantum هذه الأبعاد باستخدام ثلاثة مقاييس للأجهزة يمكن تطبيقها عبر أنماط الحوسبة الكمومية: الكيوبتات القابلة للبرمجة (المقياس)، وعمليات الكيوبت (الجودة)، والحد الأقصى للدوائر في الثانية (السرعة). توفر هذه المقاييس نظرة عامة على القدرة الحاسوبية للنظام وكفاءته عبر تطبيقات الأجهزة المختلفة.

• يُقاس المقياس بعدد الكيوبتات القابلة للبرمجة. الكيوبتات القابلة للبرمجة هي الكيوبتات التي يمكن للمستخدمين التحكم بها ومعالجتها وقياسها ودمجها مباشرة في الخوارزميات الكمومية.

• تُقاس الجودة بعمليات الكيوبت (QuOps)، وهو مقياس يصف عدد العمليات الأكثر تطلبًا حسابيًا التي يمكن للنظام تنفيذها بشكل موثوق قبل أن تطغى الأخطاء المتراكمة على الحساب. القدرة الأعلى على QuOps تمكّن عمومًا من دوائر أعمق وخوارزميات كمومية أكثر تطورًا.

• تُقاس السرعة بالحد الأقصى للدوائر في الثانية، المعروف أيضًا باسم إنتاجية الدائرة. يعكس هذا المقياس عدد الدوائر الكمومية المفيدة التي يمكن للنظام تنفيذها عبر الزمن ويقدّم مؤشرًا على الكفاءة الحاسوبية الإجمالية.

غالبًا ما تُستخدم مقاييس أجهزة إضافية لتوصيف جوانب معينة من سلوك المعالج. على سبيل المثال، يوفر EPLG (الأخطاء لكل بوابة طبقية) وقياسات دقة الطبقة رؤية حول جودة البوابات وتراكم الأخطاء، بينما يقيس CLOPS (عمليات طبقة الدائرة في الثانية) سرعة تنفيذ حمل عمل قياسي لقياس الأداء الكمومي. تظل هذه المقاييس مفيدة لتقييم أحمال عمل وتفاصيل تنفيذ معينة، لكن الكيوبتات القابلة للبرمجة، وعمليات الكيوبت، والحد الأقصى للدوائر في الثانية توفر إطارًا أوسع لمقارنة الأنظمة الكمومية.

الفروق بين المقاييس الكمية والكلاسيكية

غالبًا ما توصف أنظمة الحوسبة الكلاسيكية باستخدام مقاييس مثل FLOPS (عمليات الفاصلة العائمة في الثانية)، وسعة الذاكرة، وعرض النطاق الترددي للذاكرة، ومعدلات ساعة المعالج. يمكن عمل بعض التشابهات التقريبية بين هذه المقاييس ومقاييس الحواسيب الكمومية التي قُدّمت أعلاه، لكن الاختلافات بين المقاييس مهمة.

يمكن اعتبار الحد الأقصى للدوائر في الثانية شبيهًا تقريبيًا بمقاييس الأداء الموجهة نحو الإنتاجية في الحوسبة الكلاسيكية لأنه يقيس مقدار العمل المفيد الذي يمكن لنظام كمومي إنجازه عبر الزمن. لكن على عكس FLOPS، فإنه يقيس تنفيذ الدوائر الكمومية بدلًا من العمليات الحسابية.

يُقارَن CLOPS أحيانًا بمعايير الإنتاجية الكلاسيكية مثل FLOPS، لكن من الأفضل فهمه كمعيار خاص بحمل عمل معين وليس كمقياس عام لأداء الحوسبة الكمومية. توفر قياسات EPLG والدقة ذات الصلة رؤية حول مدى دقة تنفيذ المعالج لطبقات البوابات الكمومية. هذه المقاييس مفيدة لفهم خصائص أجهزة معينة، بينما يوفر إطار العمل الأساسي المقياس-الجودة-السرعة أساسًا أعم لمقارنة الأنظمة الكمومية. يمكن العثور على العديد من أوصاف أداء الحاسوب الكمومي في صفحة موارد الحوسبة على IBM Quantum Platform. لاحظ أنه بينما يكون عدد الكيوبتات القابلة للبرمجة رقمًا ثابتًا لوحدة معالجة كمومية معينة، يمكن أن تتفاوت مقاييس السرعة والجودة قليلًا بمرور الوقت بسبب تحديثات المعايرة والصيانة والظروف التشغيلية والتحسينات على البنية التحتية المحيطة للأجهزة والبرمجيات.

معًا، تساعد هذه المقاييس المتكاملة على توجيه تخصيص الموارد والجدولة وتصميم التطبيقات في أنظمة الحوسبة الكمومية.

في كثير من الحالات، يُعامَل النظام الكمومي بأكمله كوحدة واحدة. غير أنه حين تتجاوز المهمة طاقة وحدة واحدة — سواء من حيث عدد الكيوبتات البرمجية أو عمق الدائرة أو معدل إنتاجية الدائرة — يمكن اللجوء إلى تقنيات مثل قطع/حياكة الدوائر. قطع الدائرة هو عملية تفكيك المهام الكمومية الكبيرة إلى مهام فرعية أصغر وأكثر قابلية للإدارة، يمكن توزيعها على عدة رقائق كمومية لتحقيق حوسبة كمومية قابلة للتوسع رغم قيود الأجهزة. أما حياكة الدائرة فتأتي بعد القطع — وهي خطوة المعالجة الكلاسيكية اللاحقة التي "تحيك" أو تجمع نتائج الدوائر الفرعية الأصغر مع بعضها.

لا تمتلك الحواسيب الكمومية ذاكرةً تقليدية بالمعنى المتعارف عليه، أي التخزين المستمر القابل للعنونة كالذاكرة العشوائية (RAM) أو ذاكرة وحدة معالجة الرسوم (GPU). فالموارد الحسابية الكلاسيكية تعتمد على بتّات منفصلة مخزّنة في الذاكرة، مما يتيح حفظ البيانات واسترجاعها وإعادة استخدامها أثناء العملية الحسابية. أما الموارد الكمومية فتستخدم كيوبتات لا تُخزّن الذاكرة بالمفهوم الكلاسيكي. بدلاً من ذلك، توجد الكيوبتات في حالات كمومية تمثل تراكبات من 0 و1 في آنٍ واحد، مما يُتيح توازياً أسياً في فضاء الحالات. بيد أن حالات الكيوبتات هشّة، ولا يمكن نسخها أو قراءتها بشكل حتمي في خطوات وسيطة دون إحداث انهيار للحالة الكمومية، لذا فلا وجود لسلوك يشبه الذاكرة المستمرة أثناء الحساب. يجب الإبقاء على الكيوبتات في حالة تماسك (coherent) طوال التنفيذ، و"الذاكرة" في جوهرها هي الحالة الكمومية نفسها. لا يمكن استخدام الذاكرة الكلاسيكية إلا جنبًا إلى جنب مع المعالج الكمومي، لا كذاكرة كمومية داخلية. لهذا تداعيات جوهرية: يمكن لموارد الحوسبة الكلاسيكية إعادة استخدام النتائج الوسيطة وتخزينها بحرية؛ أما الموارد الكمومية فلا تستطيع ذلك دون إجراء قياسات تُربك الحساب.

الاتصال بالبنية التحتية الكلاسيكية

يمكن ربط وحدات المعالجة الكمومية (QPUs) بالبنية التحتية الكلاسيكية عبر الشبكات وواجهات برمجة التطبيقات (APIs) المتنوعة التي تتيح لمطوري البرمجيات التفاعل مع وحدات المعالجة الكمومية برمجيًا. عادةً ما تكون هذه الواجهات مخفية خلف مجموعات تطوير البرمجيات (SDKs) والمكتبات (كـ Qiskit)، ومتاحة لعلماء الحوسبة في شكل تجريدات برمجية (مثل primitives التي سنتناولها في الفصل الثالث: نماذج البرمجة).

من المفيد التمييز بين التكامل المحكم والتكامل المرن للموارد الكمومية والكلاسيكية. في الوقت الراهن، لا توجد وحدات المعالجة الكمومية على نفس العقدة التي تتواجد عليها موارد الحوسبة الكلاسيكية. في الواقع، لا ترتبط وحدات المعالجة الكمومية حاليًا عبر PCIe، بل عبر الشبكة. قد يتغير هذا مستقبلاً، لكن ثمة تحديات هندسية تتعلق بالظروف البيئية المثلى لوحدات المعالجة الكمومية ولموارد الحوسبة الكلاسيكية.

توسيع الموارد الكمومية

يمكن تصنيف توسيع الموارد الكمومية أيضًا إلى رأسي وأفقي.

• التوسيع الرأسي يعني زيادة عدد الكيوبتات على الرقاقة الواحدة أو تحسين دقة الأجهزة.

• التوسيع الأفقي يعني ربط الرقائق بعضها ببعض عبر أقطاب توصيل أو عبر وصلات كلاسيكية.

تحقق من فهمك

ما هي النظائر الكمومية لـ (أ) بتات المعلومات الكلاسيكية، و(ب) سرعة المعالج؟

الإجابة

(أ) البتات الكمومية أو الكيوبتات - وحدات من المعلومات، على عكس نظيراتها الكلاسيكية (التي يمكن أن تتخذ فقط الحالة 0 أو 1)، يمكن أن تكون في تراكب من 0 و1 في آن واحد. (ب) عمليات طبقة الدائرة في الثانية أو CLOPS - عدد العمليات المتسلسلة التي يمكن لوحدة المعالجة الكمومية تنفيذها كل ثانية، بما في ذلك بعض التواصل مع موارد الحوسبة الكلاسيكية، كما في تحميل المعاملات من الدائرة.

إدارة الموارد

كلٌّ من موارد الحوسبة عالية الأداء والموارد الكمومية ثمينة ومعقدة؛ ولا بد من إدارتها بعناية. في هذا القسم، سنشرح كيفية إدارة الموارد لبرامج المستخدمين. تشير إدارة الموارد في البنية التحتية الحسابية إلى عملية (1) التخطيط، و(2) التخصيص، و(3) التحكم/الإدارة لاستخدام الموارد الحسابية كوحدات المعالجة المركزية (CPUs)، والذاكرة، والتخزين، وعرض نطاق الشبكة، لضمان الاستخدام الكفء والفعّال للموارد.

التخطيط - تقدير الموارد

أي برنامج يستهلك موارد، وتقدير الموارد المطلوبة أمرٌ أساسي لإدارة فعّالة. يشمل ذلك تقدير كمية وحدات المعالجة المركزية والذاكرة وغيرها من الموارد اللازمة لتنفيذ البرنامج. وينطبق الأمر ذاته على الموارد الكمومية. غير أن الموارد الكمومية تعمل على مقياس مختلف تمامًا. تمتلك معالجات IBM Quantum® Heron r3 الكمومية 156 كيوبتًا، مقارنةً بمليارات البتّات الكلاسيكية الكثيرة في الحاسوب المحمول الاعتيادي. الوقت والتكلفة أيضًا من الاعتبارات. حاليًا، تتيح IBM Quantum خطة مجانية هي الخطة المفتوحة، تسمح للمستخدمين باستكشاف الحوسبة الكمومية باستخدام 10 دقائق من وقت وحدة المعالجة الكمومية شهريًا. تحتاج بعض المنظمات البحثية إلى وقت وحدة معالجة كمومية كبير لدرجة أنها تمتلك حاسوبًا كموميًا مخصصًا من IBM في مقرها.

خطوة فريدة في تقدير الموارد الكمومية هي عمق الدائرة. كما ذُكر سابقًا، كل بوابة كمومية وكل تأخير بين العمليات يصحبه ضجيج واحتمال معين لحدوث خطأ. كلما ازداد عمق الدائرة الكمومية، زاد الضجيج. ثمة دقيقتان في هذا الأمر: بوابات الكيوبتَين ذات معدلات خطأ أعلى بكثير من بوابات الكيوبت الواحد، لذا يمكن في الغالب إهمال العمق الخاص بالكيوبت الواحد. علاوة على ذلك، ليست جميع الكيوبتات على الرقاقة الكمومية متصلة مباشرةً ببعضها. أحيانًا يجب تبادل المعلومات من كيوبت إلى آخر لإجراء التشابكات المطلوبة، وهذه العملية نفسها تتطلب بوابات كيوبتَين. يُعالَج هذا التبادل في عملية تُسمى "التحويل" (transpilation)، وهي عملية معقدة تخدم أغراضًا أخرى أيضًا؛ وتناقَش بمزيد من التفصيل في الدرس التالي. الكمية المحدِّدة هي إذًا عمق الكيوبتَين بعد التحويل. يعتمد الحد الأقصى الدقيق للعمق الذي يمكن عنده الحصول على نتائج عالية الدقة على الدائرة. لكن بالاستفادة من تقنيات تخفيف الأخطاء الحديثة، يمكن الحصول على نتائج عالية الدقة بعمق كيوبتَين بعد التحويل يبلغ 80 أو أكثر.

التخصيص - الجدولة

الجدولة هي عملية تخصيص الموارد للبرامج وإدارة تنفيذها. يشمل ذلك:

• تقديم المهمة (Job submission): العملية التي يُرسل بها المستخدم طلبًا (مهمة) إلى نظام الحوسبة عالية الأداء، محددًا فيها الأعمال الحسابية والموارد اللازمة للتنفيذ.
• تخصيص الموارد (Resource allocation): تعيين موارد نظام الحوسبة المتاحة (كالعقد ووحدات المعالجة المركزية والذاكرة) للمهمة المقدَّمة بناءً على متطلباتها.
• تنفيذ المهمة (Job execution): التشغيل الفعلي للمهام الحسابية المحددة في المهمة على موارد الحوسبة المخصصة.

لجميع هذه العمليات ما يقابلها في الحواسيب الكمومية.

• تُقدَّم المهام من قِبَل المستخدم باستخدام IBM Quantum Compute Service، وعادةً باستخدام إحدى IBM Quantum primitives مثل Sampler أو Estimator أو غيرها.
• يختار المستخدم من قائمة بالخلفيات (backends) المتاحة له. يمكن الاطلاع على القائمة الكاملة للخلفيات المتاحة في صفحة موارد الحوسبة على IBM Quantum Platform. من الشائع ببساطة اختيار الحاسوب الكمومي الأقل ازدحامًا. لكن ثمة حالات قد يكون فيها من المهم استخدام حاسوب بعينه لاعتبارات تتعلق بتخطيط الجهاز، أو إعادة إنتاج حسابات سابقة، وما شابه ذلك.
• تنفيذ المهام الكمومية مماثل لحالة الحوسبة عالية الأداء. رغم أن بعض الفروق قد أُشير إليها سابقًا، يستحق بعضها التكرار هنا. لا توجد وحدات المعالجة الكمومية حاليًا على نفس العقدة التي توجد فيها موارد الحوسبة الكلاسيكية بشكل عام، بل ترتبط بها عبر الشبكة. قد يكون لهذا آثار على الجدولة. فضلاً عن ذلك، قد تتسم أوقات الانتظار في قائمة انتظار الحواسيب الكمومية بالطول والتفاوت، مما يجعل التحكم الدقيق في التوقيت أمرًا عسيرًا. قد يختلف هذا الوضع في الأنظمة المخصصة؛ ويتوقف ذلك على الإدارة الداخلية للحاسوب الكمومي.

التحكم/الإدارة - إدارة أعباء العمل

إدارة أعباء العمل، المعروفة أيضًا بالتنسيق (orchestration)، هي عملية إدارة برامج متعددة ومتطلباتها من الموارد. يشمل ذلك:

• توفير الموارد (Resource provisioning): عملية إعداد موارد الحوسبة عالية الأداء وتجهيزها لاستخدامها من قِبَل المهام، بما في ذلك إعداد الأجهزة والبرمجيات. كما سنرى لاحقًا، تُعدّ وحدات المعالجة الكمومية موارد حسابية يمكن توفيرها بطريقة مشابهة لموارد الحوسبة عالية الأداء الكلاسيكية، مع مراعاة التحفظات المذكورة في القسم السابق.
• جدولة المهام (Job scheduling): نشاط برنامج الجدولة في تحديد المهام التي ستُنفَّذ ومتى وعلى أي موارد، مع إدارة الأولويات وقوائم الانتظار لاستخدام نظام الحوسبة عالية الأداء بكفاءة. رغم أن هذا القول الشامل ينطبق على الموارد الكمومية، فقد يكون التحكم في التوقيت أقل مقارنةً بالموارد الأخرى.

Example:

لنأخذ مهمة معروفة كسياق لفهم إدارة الموارد: إيجاد العوامل الأولية للأعداد الكبيرة. لنفترض أيضًا أن الخوارزمية المستخدمة تعتمد على الفحص الاستنفادي لكل قاسم محتمل. رغم أن هذه ليست الطريقة الأكثر كفاءة في الغالب، فمن السهل فهم كيفية إدارة عبء العمل.

التخطيط - تقدير الموارد

• تقدير مقدار وقت المعالج والذاكرة الذي قد تستلزمه عملية التحليل إلى عوامل أولية.

• التخطيط لموازاة مهمتك — كم عدد وحدات المعالجة المركزية/الأنوية التي ستستخدمها؟

التخصيص - الجدولة

• عند تقديم المهمة، يُخصّص المُجدوِل أنوية المعالج والذاكرة لمهمة التحليل إلى عوامل أولية. على سبيل المثال، قد يُخصّص جميع القواسم المحتملة المنتهية بالأرقام 1, 3, 7, 9 لكل من الأنوية الأربعة على الترتيب.

• تنفيذ المهمة: تعمل خوارزمية التحليل إلى عوامل أولية، منجزةً عمليات القسمة أو خطوات التحليل الأخرى على الموارد المخصصة حتى اكتمال المهمة.

التحكم/الإدارة - إدارة أعباء العمل

• ينسّق النظام ترتيب وتوقيت مهام التحليل إلى عوامل أولية لتحسين الإنتاجية.

• أبسط حالة يمكن تخيّلها هي أن أحد الأنوية يجد العامل الأولي المستهدف. ينبغي أن يوقف هذا الحسابَ على الأنوية الأخرى حتى يمكن استخدامها للمهمة التالية.

تستخدم بيئات الحوسبة عالية الأداء برمجيات خاصة لتنفيذ هذه الخطوات وإدارة الموارد. في القسم التالي، سنتعرف على أحد أنظمة إدارة الموارد المُعتمَدة على نطاق واسع: Slurm.

مثال مع الموارد الكمومية:

تحديد الحالات الأرضية للتفاعلات الكيميائية وطاقاتها باستخدام قطرنة كمومية تستند إلى العينات (SQD) هو سير عمل سيكون موضوع دروس أخرى في هذه الدورة. يُغطَّى بمزيد من التفصيل في الدرس الرابع، ويمكنك أيضًا الاطلاع على هذه الدورة حول SQD والطرق ذات الصلة على IBM Quantum Learning. كل ما نحتاج معرفته لهذا النقاش هو أن سير العمل يتضمن:

• تجهيز دائرة كمومية
• قياس الدائرة الكمومية
• استخدام نتائج القياس لإسقاط المسألة في فضاء فرعي مفيد
• قطرنة مصفوفة أصغر مُسقَطة باستخدام موارد الحوسبة الكلاسيكية
• التكرار، سواء لضمان الاتساق الذاتي من خلال اعتبارات كحفظ الشحنة، أو التكرارات المحتملة للدائرة الكمومية إذا كانت تحتوي على معاملات متغيرة.

التخطيط - تقدير الموارد

• تعيين المدارات الإلكترونية على الكيوبتات لتحديد عدد الكيوبتات المطلوبة.

• دمج هاميلتونيان المنظومة المُعيَّن و(ربما المتغير) والحالة في دائرة كمومية، والتحقق من عمق الكيوبتَين بعد التحويل. تأكد من أنه معقول.

• تقدير حجم الفضاء الفرعي الذي ستُسقط فيه؛ ومن هذا، تقدير مقدار وقت المعالج والذاكرة التي قد تستلزمها عملية القطرنة.

• التخطيط لموازاة مهمتك — كم عدد وحدات المعالجة المركزية/الأنوية التي ستستخدمها؟

التخصيص - الجدولة

• يختار المستخدم وحدة المعالجة الكمومية؛ تُعيّن عملية التحويل تلقائيًا الكيوبتات في دائرتك الكمومية المجردة على الكيوبتات الفيزيائية في وحدة المعالجة الكمومية. هذا أمر مهم نظرًا لأن الدائرة المجردة قد تفترض اتصالاً مباشرًا غير موجود على الرقاقة، من بين أسباب أخرى.

• عند تقديم المهمة عبر Quantum Compute، تدخل المهمة في قائمة انتظار وحدة المعالجة الكمومية المختارة. لا يملك المستخدم سيطرة على وقت الانتظار في القائمة، رغم أن الأمر قد يختلف في الأنظمة المخصصة.

• تنتظر موارد الحوسبة الكلاسيكية النتائج الكمومية.

• تُقدَّم مهمة القطرنة لموارد الحوسبة عالية الأداء؛ عند تقديمها، يُخصّص المُجدوِل أنوية المعالج والذاكرة لمهمة القطرنة.

• تنفيذ المهمة: تعمل خوارزمية القطرنة، مُقطرِنةً المصفوفة المسقَطة الأصغر حتى اكتمال المهمة.

التحكم/الإدارة - إدارة أعباء العمل

• ينسّق النظام ترتيب وتوقيت الخطوات الكمومية والكلاسيكية طوال العملية. على سبيل المثال، بمجرد قطرنة المصفوفة المسقَطة والحصول على طاقة الحالة الأرضية، وبناءً على معايير التقارب، قد يعود سير العمل إلى دائرة كمومية جديدة (بمعامل متغير جديد).

• عند استيفاء معايير التقارب من قِبَل طاقة الحالة الأرضية، يتوقف الحساب على جميع الأنوية.

تستخدم بيئات الحوسبة عالية الأداء برمجيات خاصة لتنفيذ هذه الخطوات وإدارة الموارد. في القسم التالي، سنتعرف على أحد أنظمة إدارة الموارد المُعتمَدة على نطاق واسع: Slurm. من المهم الإشارة إلى أن Slurm لا يوفر أدوات لجميع الخطوات الموصوفة أعلاه. لا يقدم Slurm دعمًا لتخطيط المهام، ولا لإدارة أعباء العمل التفصيلية كالتواصل بين مكونات عبء العمل. هذا ملائم للوضع الراهن للحوسبة الكمومية في الحوسبة عالية الأداء، إذ يُتاح الوصول إلى وحدات المعالجة الكمومية عادةً عبر الشبكة.

تحقق من فهمك

افترض أنك تحاول البحث في قاعدة بيانات غير مرتبة للعثور على عنصر نسميه "الهدف". لكل من الإجراءات التالية، حدد إلى أي مرحلة من مراحل إدارة الموارد تنتمي:

(أ) تقدير حجم قاعدة البيانات والوقت اللازم للتحقق من كل عنصر

(ب) التأكد من أن إيجاد الهدف على وحدة معالجة رسومية (GPU) يوقف العملية على وحدات المعالجة الرسومية الأخرى لتحريرها للمشكلة التالية

(ج) تقسيم مساحة البحث إلى مناطق لكل من وحدات معالجتك الرسومية (لنقل 10 وحدات)

الإجابة

(a) Planning

(ب) التحكم/الإدارة

(ج) التخصيص/الجدولة

البرمجيات: Slurm

في هذا القسم، سنطبّق المفاهيم التي تعلّمناها في هذا الفصل ونتدرّب على استخدام نظام إدارة الموارد الشهير، Slurm.

مقدمة إلى Slurm

Slurm هو نظام إدارة موارد مفتوح المصدر يُستخدم على نطاق واسع في بيئات الحوسبة عالية الأداء. يوفّر مجموعة شاملة من الأدوات لإدارة الموارد وجدولة المهام ومراقبة أداء النظام.

سنغطّي أساسيات استخدام Slurm، وتشمل:

• تقديم المهام
• تخصيص الموارد
• مراقبة المهام

بما أن توفير موارد HPC لكل طالب في هذه الدورة صعب جداً، سنلجأ إلى حل بديل ونوفّر لك مستودعاً يحتوي على صور Docker تحاكي كلاستر HPC فعلي مع Slurm، لكن على نطاق صغير. سيساعدنا ذلك في التدرّب على المفاهيم التي تعلّمناها في بيئات آمنة وقابلة للتكرار.

لاحظ أن جميع الموارد الكمومية والكلاسيكية حالياً مخصّصة لمدة التجربة كلها. لا يوجد حالياً تخصيص متداخل للموارد المختلطة. تنبيه أخير: حتى بعد إطلاق المهمة، لن يتم التحكم في النظام الكمومي مباشرةً كما قد يتوقّع مستخدم HPC معتاد. يتم إطلاق المهمة على أي عقدة x86 تُنفّذ IBM Quantum Compute Service، وهذه الخدمة تتصل بجدوَل آخر لا يملك المستخدم سيطرة مباشرة عليه. هذا السير وما يرتبط به من مشاكل قد يكون مألوفاً لمستخدمي 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!

اختبر فهمك

بالنظر إلى سكريبت Slurm shell التالي، ما هو (أ) اسم المهمة، (ب) اسم ملف 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

الإجابة

(أ) hello-learner

(ب) hello-learner_qm.py

(ج) hello-learner.out

(د) نعم، يمكن ذلك. إنه يستخدم قسم الكم (quantum partition).

تشغيل مثال Qiskit بسيط في 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 بشكل مشترك. أنشأنا دائرة pauli-2-design بسيطة بقيم أولية عشوائية وقابلية رصد بسيطة، وسنشغّلها باستخدام 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 لتحديد موارد حسابية إضافية. في حالتنا، هذا المورد الجديد هو موردنا الكمي. بما أننا حددنا الموارد والقسم في الكلستر الذي تتوفر فيه الموارد الكمية، فإن IBM Quantum primitives ستستخدم هذه الموارد المخصصة لتنفيذ الحِمل الكمي.

الآن حان وقت تشغيل وظيفة 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 الخاص بنا.