مقدمة إلى أوضاع تنفيذ Quantum Compute
عند إطلاق IBM Quantum Compute Service في البداية، كان بإمكان المستخدمين تنفيذ الدوائر على شكل وظائف فردية فقط. ومع ظهور أنواع مختلفة من أحمال العمل الكمومية، بات من الواضح أن ثمة حاجة إلى استراتيجيات جدولة متعددة. تحدد أوضاع التنفيذ كيفية جدولة وظائفك، واختيار الوضع المناسب يتيح لحمل عملك أن يعمل بكفاءة ضمن ميزانيتك. تتوفر ثلاثة أوضاع للتنفيذ: وضع الوظيفة، ووضع الجلسة، ووضع الدُفعة.
Job mode
طلب primitive مفرد يُقدَّم خارج أي مدير سياق. تُعبَّأ الدوائر والمدخلات على شكل كتل موحَّدة للـ primitive (PUBs) وتُرسَل كمهمة تنفيذ على الحاسوب الكمومي. للتشغيل في job mode، حدد mode=backend عند إنشاء primitive. راجع أمثلة Estimator وأمثلة Sampler للاطلاع على طريقة الاستخدام.
Batch mode
مدير متعدد المهام لتشغيل التجارب التي تتضمن أحمال عمل من مهام متعددة بكفاءة عالية. تتألف هذه الأحمال من مهام قابلة للتنفيذ بصورة مستقلة دون أي علاقة شرطية فيما بينها. في batch mode، يرسل المستخدمون جميع مهامهم دفعةً واحدة.
يُوازي النظام خطوة المعالجة المسبقة (الحوسبة الكلاسيكية) لكل مهمة primitive أو يوزّعها على خيوط متعددة لتجميع تنفيذ الدوائر الكمومية عبر المهام بشكل أحكم، ثم يُشغِّل الجزء الكمومي من كل مهمة تباعاً بسرعة لتحقيق أكفأ النتائج. لمزيد من التفاصيل حول المعالجة المتوازية، راجع صفحة الأسئلة الشائعة حول أوضاع التنفيذ.
- عند استخدام وضع الدُفعة، لا يُضمَن تشغيل المهام بالترتيب الذي أُرسِلت به. وبينما تعمل مهام الدُفعة بشكل متقارب قدر الإمكان، إلا أنها لا تحظى بوصول حصري إلى Backend. لذلك، قد تعمل مهام دُفعتك بالتوازي مع مهام مستخدمين آخرين إذا توفرت طاقة معالجة كافية على وحدة QPU. كذلك قد تعمل مهام المعايرة الخاصة بوحدة QPU بين مهام الدُفعة.
- لا يقل وقت الانتظار في الطابور للمهمة الأولى المرسَلة ضمن دُفعة. لذلك لا تُقدِّم الدُفعات أي فائدة عند تشغيل مهمة واحدة فقط.
لتشغيل وظيفة في batch mode، حدد mode=batch عند إنشاء primitive، أو شغِّل الوظيفة داخل مدير سياق الدُفعة. راجع تشغيل وظائف في دُفعة للاطلاع على أمثلة.
Session mode
نافذة مخصصة لتشغيل أحمال عمل تتضمن وظائف متعددة. خلال هذه النافذة، يمتلك المستخدم وصولاً حصرياً إلى النظام ولا يمكن لأي وظيفة أخرى أن تعمل — بما في ذلك وظائف المعايرة. يتيح ذلك للمستخدمين تجربة الخوارزميات التغايرية بطريقة أكثر قابلية للتنبؤ، بل وتشغيل تجارب متعددة في آنٍ واحد مستفيدين من التوازي في المنظومة. يساعد استخدام الجلسات على تجنب التأخيرات الناجمة عن إدخال كل وظيفة إلى الطابور على حدة، وهو أمر مفيد بشكل خاص للمهام التكرارية التي تستلزم تواصلاً متكرراً بين الموارد الكلاسيكية والكمومية. تمثل دالة التكلفة في الصورة دالة خاصة بخوارزمية تغايرية كمومية، تعمل على الجهاز المحلي للمستخدم.
لتشغيل وظيفة في session mode، حدد mode=session عند إنشاء primitive، أو شغِّل الوظيفة داخل مدير سياق الجلسة. راجع تشغيل وظائف في جلسة للاطلاع على أمثلة.
- لا يقل وقت الانتظار في الطابور للوظيفة الأولى المرسَلة ضمن جلسة. لذلك لا تُقدِّم الجلسات أي فائدة عند تشغيل وظيفة واحدة فقط.
- لا يمكن لمستخدمي الخطة المفتوحة (Open Plan) إرسال وظائف الجلسة.
سير العمل الأساسي
سير العمل الأساسي للدُفعات والجلسات متشابه:
-
تدخل أول مهمة في دُفعة أو جلسة الطابور العادي. أما في الدُفعات، فتُجدوَل مجموعة المهام بأكملها معاً.
-
عند بدء تشغيل أول وظيفة، يبدأ مؤقت الحد الأقصى لوقت البقاء (TTL) ولا يتوقف أو يُعلَّق حتى ينتهي.
-
يبدأ مؤقت TTL التفاعلي بعد اكتمال كل مهمة. إذا لم تكن ثمة مهام جاهزة ضمن نافذة TTL التفاعلي، يُعلَّق حمل العمل مؤقتاً وتستأنف عملية اختيار المهام العادية. يمكن لمهمة ما إعادة تفعيل حمل العمل المعلَّق إذا لم تصل الدُفعة أو الجلسة إلى الحد الأقصى لقيمة TTL.
ملاحظةيجب أن تمر المهمة عبر الطابور العادي لإعادة تفعيل حمل العمل.
-
إذا بُلغت القيمة القصوى لـ TTL، ينتهي حمل العمل وتفشل أي وظائف متبقية في الطابور. أي وظيفة قيد التشغيل حالياً لن تكتمل إذا كان ذلك سيتجاوز حد التكلفة المحدد للمثيل (instance).
يوضح الفيديو التالي سير العمل الأساسي باستخدام الجلسات مثالاً:
للاطلاع على تفاصيل كاملة حول مؤقتات TTL، راجع دليل الحد الأقصى لوقت التنفيذ.