Aller au contenu principal

Introduction aux modes d'exécution de Qiskit Runtime

Quand Qiskit Runtime a été introduit, les utilisateurs ne pouvaient exécuter des circuits que sous forme de jobs individuels. Au fur et à mesure que différents types de charges de travail quantiques ont émergé, le besoin de différentes stratégies de planification est devenu évident. Les modes d'exécution déterminent comment tes jobs sont planifiés, et choisir le bon mode d'exécution permet à ta charge de travail de s'exécuter efficacement dans les limites de ton budget. Il existe trois modes d'exécution : job, session et batch.

Mode job​

Une requête primitive unique de l'estimateur ou du sampler effectuée sans gestionnaire de contexte. Les circuits et les entrées sont regroupés en blocs unifiés primitifs (PUBs) et soumis comme une tâche d'exécution sur l'ordinateur quantique. Pour exécuter en mode job, spécifie mode=backend lors de l'instanciation d'une primitive. Voir Exemples de primitives pour l'utilisation.

Mode batch​

Un gestionnaire multi-jobs permettant d'exécuter efficacement des expériences composées de charges de travail multi-jobs. Ces charges de travail sont constituées de jobs exécutables de manière indépendante, sans relation conditionnelle entre eux. Avec le mode batch, les utilisateurs soumettent tous leurs jobs en une seule fois.

Le système parallélise ou divise en fils d'exécution l'étape de pré-traitement (calcul classique) de chaque job primitif afin de regrouper plus étroitement l'exécution quantique entre les jobs, puis exécute la partie quantique de chaque job en succession rapide pour obtenir les résultats les plus efficaces. Pour plus de détails sur les fils d'exécution, consulte la page FAQ sur les modes d'exécution.

Un ensemble de jobs exécutés en mode batch. La partie calcul classique de chaque job se déroule simultanément, puis tous les jobs sont envoyés au QPU. Le QPU est verrouillé pour ton usage depuis le moment où le premier job atteint le QPU jusqu'à ce que le dernier job ait fini d'être traité. Il n'y a aucune interruption entre les jobs où le QPU est inactif.

Remarques
  • Lors de l'utilisation du mode batch, l'ordre d'exécution des jobs n'est pas garanti. De plus, bien que tes jobs batch s'exécutent aussi proches que possible les uns des autres, ils n'ont pas d'accès exclusif au backend. Ainsi, tes jobs batch peuvent s'exécuter en parallèle avec les jobs d'autres utilisateurs s'il y a suffisamment de capacité de traitement sur le QPU. De plus, des jobs de calibration du QPU pourraient s'intercaler entre les jobs batch.
  • Le temps d'attente en file ne diminue pas pour le premier job soumis dans un batch. Par conséquent, les batchs n'apportent aucun avantage lors de l'exécution d'un seul job.

Pour exécuter en mode batch, spécifie mode=batch lors de l'instanciation d'une primitive ou exécute le job dans un gestionnaire de contexte batch. Voir Exécuter des jobs en batch pour des exemples.

Mode session​

Une fenêtre dédiée pour exécuter une charge de travail multi-jobs. Durant cette fenêtre, l'utilisateur a un accès exclusif au système et aucun autre job ne peut s'exécuter — y compris les jobs de calibration. Cela permet aux utilisateurs d'expérimenter des algorithmes variationnels de manière plus prévisible et même d'exécuter plusieurs expériences simultanément, en tirant parti du parallélisme dans la pile. L'utilisation des sessions aide à éviter les délais causés par la mise en file de chaque job séparément, ce qui peut être particulièrement utile pour les tâches itératives nécessitant des communications fréquentes entre les ressources classiques et quantiques.

Un ensemble de jobs exécutés en mode session et un autre exécuté en mode batch. Entre chaque job se trouve le TTL interactif (durée de vie interactive). La fenêtre active commence quand le premier job démarre et se termine après la fin du dernier job. Après la fin du dernier job du premier ensemble, la fenêtre active se ferme et la session est mise en pause (mais pas fermée). Un autre ensemble de jobs démarre ensuite et les jobs se poursuivent de manière similaire. Le QPU est réservé à ton usage pendant toute la durée de la session.

Pour exécuter en mode session, spécifie mode=session lors de l'instanciation d'une primitive, ou exécute le job dans un gestionnaire de contexte session. Voir Exécuter des jobs en session pour des exemples.

Remarques
  • Le temps d'attente en file ne diminue pas pour le premier job soumis dans une session. Par conséquent, les sessions n'apportent aucun avantage lors de l'exécution d'un seul job.
  • Les utilisateurs du plan Open ne peuvent pas soumettre de jobs en session.

Flux de travail de base​

Le flux de travail de base pour les batchs et les sessions est similaire :

  1. Le premier job d'un batch ou d'une session entre dans la file normale. Pour les batchs, l'ensemble du batch de jobs est planifié ensemble.
  2. Quand le premier job commence à s'exécuter, le minuteur de durée de vie maximale (TTL) démarre et ne s'arrête ni ne se met en pause jusqu'à ce que la fin soit atteinte.
  3. Le minuteur TTL interactif démarre après la fin de chaque job. S'il n'y a aucun job prêt dans la fenêtre TTL interactive, la charge de travail est temporairement désactivée et la sélection normale des jobs reprend. Un job peut réactiver la charge de travail désactivée si le batch ou la session n'a pas atteint sa valeur TTL maximale.
    remarque

    Le job doit passer par la file normale pour réactiver la charge de travail.

  4. Si la valeur TTL maximale est atteinte, la charge de travail se termine et tous les jobs restants en file échouent. Tout job en cours d'exécution ne sera pas mené à terme si cela dépasse la limite de coût de l'instance.

La vidéo suivante illustre le flux de travail de base, en utilisant les sessions comme exemple :

Pour tous les détails sur les minuteurs TTL, consulte le guide Durée d'exécution maximale.

Étapes suivantes​

Recommandations