استخدام حمل العمل

يمثّل الاستخدام استهلاك خدمة Qiskit Runtime ويُحدَّد بمقدار الوقت الذي يكون فيه QPU مقفلًا لتنفيذ أحمال العمل.

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

لاحظ أن المهام الفاشلة أو الملغاة تُحسب ضمن استخدامك في ظروف معينة — راجع قسم المهام الفاشلة والملغاة للتفاصيل.

بالنسبة لمستخدمي خطة الدفع حسب الاستخدام (Pay-As-You-Go Plan)، راجع إدارة التكلفة للتفاصيل حول ضبط حد التكلفة.

الاستخدام للمهام الفاشلة والملغاة

عند فشل مهمة أو إلغائها، يكون الاستخدام المُبلَّغ عنه كالتالي:

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

• وضع الجلسة: الاستخدام المُبلَّغ عنه هو وقت الساعة الفعلي الذي تكون فيه الجلسة نشطة، بغض النظر عن عدد المهام الفاشلة أو الملغاة.

الاستعلام عن الاستخدام الفعلي لحمل العمل

بعد اكتمال حمل العمل، هناك عدة طرق لعرض استخدامه الفعلي:

• شغّل batch.usage() أو session.usage() في qiskit-ibm-runtime الإصدار 0.30 أو أحدث. إذا كنت تستخدم إصدارًا أقدم من qiskit-ibm-runtime (>= 0.23 و< 0.30)، لا يزال بإمكانك العثور على الاستخدام في session.details()["usage_time"] وbatch.details()["usage_time"].
• استخدم GET /sessions/{id} لعرض الاستخدام لدُفعة أو جلسة معينة.
• استخدم GET /jobs/{id} لعرض الاستخدام لمهمة واحدة.

عرض استخدام المثيل

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

تعرض صفحة المثيلات الاستخدام في الوقت الفعلي للـ 28 يومًا الأخيرة (متحركة)، حتى الوقت الحالي من اليوم الحالي. أما استخدام صفحة التحليلات فيُعاد حسابه كل ساعة ويشمل آخر 28 يومًا كاملة؛ أي أنه يعرض الاستخدام من الساعة 00:00 قبل 28 يومًا حتى اليوم، عند بداية الساعة.

تقدير الاستخدام قبل إرسال مهمة

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

<per sub-job overhead> + (rep_delay + <circuit length>) * <num executions>

• <per sub-job overhead> هو عبء يبلغ تقريبًا 2 ثانية لكل مهمة فرعية. يشمل ذلك عمليات مثل تحميل الحمولة في الإلكترونيات الضابطة. قد تُقسَّم مهمة primitive الخاصة بك إلى عدة مهام فرعية إذا كانت كبيرة جدًا بحيث لا يستطيع محرك التنفيذ معالجتها دفعة واحدة.
• rep_delay هو خيار قابل للتخصيص من قِبَل المستخدم، والقيمة الافتراضية يحددها backend.default_rep_delay، وهي 250 ميكروثانية على معظم backends الكم من IBM. لاحظ أن تقليل rep_delay يُقلل من إجمالي وقت تنفيذ QPU، لكن على حساب زيادة معدل خطأ تحضير الحالة؛ راجع دليل تنفيذ معدل التكرار الديناميكي للمزيد من المعلومات.
• <circuit length> هو إجمالي طول التعليمات. تستغرق كل تعليمة وقتًا مختلفًا على QPU، لذا يتفاوت الطول الإجمالي من Circuit إلى أخرى. على سبيل المثال، يمكن أن تستغرق عملية القياس (measurement) 56 ضعف الوقت الذي يستغرقه بوابة x. يمكن استخدام backend.target[<instruction>][<qubit>].duration لمعرفة المدة الدقيقة لكل تعليمة. الطول النموذجي للـ Circuit يتراوح على الأرجح بين 50-100 ميكروثانية. إذا كنت تستخدم تقنيات قمع الأخطاء أو تخفيفها مع الـ primitives، فقد تُدرج تعليمات إضافية في Circuit الخاصة بك، مما يزيد من إجمالي طول الـ Circuit.
  ملاحظة

  يُرجع خيار scheduler_timing التجريبي إجمالي وقت الـ Circuit، لكن هذا ليس الوقت المستخدم للفوترة.

• <num executions> هو إجمالي عدد الـ Circuits مضروبًا في عدد اللقطات (shots)، حيث الـ Circuits هي تلك التي تُولَّد بعد بث عناصر PUB.
  • إذا كنت تستخدم تقنيات تخفيف الأخطاء مع الـ primitives، فقد تُشغَّل Circuits إضافية كجزء من عملية التخفيف، مما يزيد من إجمالي عدد عمليات التنفيذ. بالإضافة إلى ذلك، تقنيات تخفيف الأخطاء المتقدمة مثل PEA وPEC تأتي بعبء أعلى بكثير لأنها تتطلب تشغيل Circuits لتعلُّم الضوضاء.
  • يُجمِّع Estimator المراقبات المتبادلة بحسب الكيوبت (Qubit-wise commuting)، مما يُقلل من عدد عمليات التنفيذ.

إذا لم تكن تستخدم أي تقنيات متقدمة لتخفيف الأخطاء أو rep_delay مخصصًا، يمكنك استخدام 2+0.00035*<num executions> كصيغة سريعة.

تقدير الاستخدام محليًا باستخدام Qiskit

يوضح مثال الكود هذا كيفية استخدام Qiskit لحساب وقت الدائرة:

# Schedule the circuit to get more accurate timing
pm = generate_preset_pass_manager(
    target=backend.target,
    optimization_level=0,
    scheduling_method="alap"
)

scheduled_circuits = pm.run(isa_circuits)

init_duration = backend.target["reset"][(0,)].duration
rep_delay = sampler.options.execution.rep_delay or backend.default_rep_delay

circuit_duration = 0

for circuit in scheduled_circuits:
    # Estimate circuit length
    circuit_duration += circuit.estimate_duration(backend.target)

    # Add INIT time
    if sampler.options.execution.init_qubits:
        circuit_duration += init_duration

    # Add rep_delay
    circuit_duration += rep_delay

total_time = 2 + (circuit_duration*shots)
print(f"Total estimated usage is {math.ceil(total_time)} seconds")

الخطوات التالية

Recommendations

• راجع هذه النصائح: تقليل وقت تشغيل المهمة.
• اضبط الحد الأقصى لوقت التنفيذ.
• تعلّم كيفية التحويل (Transpile) محليًا في قسم Transpile.
• جرّب دليل مقارنة إعدادات Transpiler.