Utilisation des workloads

L'utilisation représente la consommation du service Qiskit Runtime et est déterminée par le temps pendant lequel un QPU est verrouillé pour exécuter des workloads.

• L'utilisation d'une session est mesurée comme le temps écoulé pendant que la session reste active, car la capacité du QPU est réservée pour toute la durée de la session, que des workloads soient en cours d'exécution ou non. Voir Durée de session pour plus d'informations sur les transitions d'état de session.
• L'utilisation d'un batch est mesurée comme le temps cumulé pendant lequel le QPU est verrouillé pour exécuter tous les jobs du batch.
• L'utilisation d'un job individuel est mesurée comme le temps pendant lequel le QPU est verrouillé pour exécuter le job.

Note que les jobs échoués ou annulés sont comptabilisés dans ton utilisation dans certaines circonstances — consulte la section Jobs échoués et annulés pour plus de détails.

Pour les utilisateurs du plan Pay-As-You-Go, voir Gérer les coûts pour plus de détails sur la définition d'une limite de coût.

Utilisation pour les jobs échoués et annulés

Quand un job échoue ou est annulé, l'utilisation rapportée est la suivante :

• Mode job ou batch : Si l'échec ou l'annulation est dû à une erreur système, l'utilisation rapportée est nulle. Pour les jobs qui ont échoué en raison d'une erreur utilisateur ou lorsqu'un utilisateur a annulé un job, l'utilisation rapportée correspond à toute consommation survenue jusqu'à ce moment.

• Mode session : L'utilisation rapportée correspond au temps réel (wall-clock) pendant lequel la session est active, indépendamment du nombre de jobs qui échouent ou sont annulés.

Consulter l'utilisation réelle d'un workload

Une fois un workload terminé, plusieurs façons permettent de consulter son utilisation réelle :

• Lance batch.usage() ou session.usage() dans qiskit-ibm-runtime version 0.30 ou ultérieure. Si tu utilises une version plus ancienne de qiskit-ibm-runtime (>= 0.23 et < 0.30), l'utilisation peut quand même être trouvée dans session.details()["usage_time"] et batch.details()["usage_time"].
• Utilise GET /sessions/{id} pour voir l'utilisation d'un batch ou d'une session spécifique.
• Utilise GET /jobs/{id} pour voir l'utilisation d'un job individuel.

Voir l'utilisation d'une instance

Tu peux consulter l'utilisation d'une instance sur la page Instances ou, pour ceux disposant des autorisations appropriées, sur la page Analytics. Note que ces pages peuvent afficher des chiffres d'utilisation différents car elles calculent l'utilisation de manière distincte.

La page Instances affiche l'utilisation en temps réel pour les 28 derniers jours (glissants), jusqu'à l'heure actuelle du jour en cours. L'utilisation affichée sur la page Analytics est recalculée toutes les heures et inclut les 28 derniers jours complets ; autrement dit, elle affiche l'utilisation depuis 00:00 il y a 28 jours jusqu'à aujourd'hui, à l'heure ronde précédente.

Estimer l'utilisation avant de soumettre un job

Bien qu'obtenir une estimation locale précise soit compliqué par les opérations supplémentaires effectuées pour la suppression et l'atténuation des erreurs, tu peux utiliser cette formule de base pour obtenir une approximation de l'utilisation estimée :

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

• <per sub-job overhead> est une surcharge d'environ 2s par sous-job. Cela inclut des opérations telles que le chargement du payload dans l'électronique de contrôle. Ton job de primitive peut être divisé en plusieurs sous-jobs s'il est trop volumineux pour que le moteur d'exécution le traite en une seule fois.
• rep_delay est une option personnalisable par l'utilisateur, et sa valeur par défaut est donnée par backend.default_rep_delay, qui est de 250 microsecondes sur la plupart des backends IBM Quantum. Note que réduire rep_delay diminue le temps total d'exécution sur le QPU, mais au détriment d'un taux d'erreur de préparation d'état plus élevé ; consulte le guide Exécution à taux de répétition dynamique pour plus d'informations.
• <circuit length> est la longueur totale des instructions. Chaque instruction prend un temps différent sur le QPU, donc la longueur totale varie d'un circuit à l'autre. Une mesure, par exemple, peut prendre 56 fois plus de temps qu'une porte x. backend.target[<instruction>][<qubit>].duration peut être utilisé pour trouver la durée exacte de chaque instruction. Une longueur de circuit typique se situe généralement entre 50 et 100 microsecondes. Si tu utilises des techniques de suppression ou d'atténuation des erreurs avec les primitives, des instructions supplémentaires pourraient être insérées dans ton circuit, ce qui augmenterait la longueur totale du circuit.
  remarque

  L'option expérimentale scheduler_timing retourne le temps total du circuit, mais ce n'est PAS le temps utilisé pour la facturation.

• <num executions> est le nombre total de circuits multiplié par le nombre de shots, où les circuits sont ceux générés après la diffusion des éléments PUB.
  • Si tu utilises des techniques d'atténuation des erreurs avec les primitives, des circuits supplémentaires pourraient être exécutés dans le cadre du processus d'atténuation, ce qui augmenterait le nombre total d'exécutions. De plus, les techniques d'atténuation des erreurs avancées telles que PEA et PEC entraînent une surcharge bien plus importante car elles nécessitent l'exécution de circuits pour l'apprentissage du bruit.
  • L'Estimator regroupe les observables commutant qubit par qubit, ce qui réduit le nombre d'exécutions.

Si tu n'utilises pas de techniques d'atténuation des erreurs avancées ni de rep_delay personnalisé, tu peux utiliser 2+0.00035*<num executions> comme formule rapide.

Estimer l'utilisation localement avec Qiskit

Cet exemple de code montre comment utiliser Qiskit pour calculer la durée d'un circuit :

# 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")

Étapes suivantes

Recommandations

• Consulte ces conseils : Minimiser le temps d'exécution des jobs.
• Définis le Temps d'exécution maximum.
• Apprends à transpiler localement dans la section Transpiler.
• Essaie le guide Comparer les paramètres du transpileur.