FAQ sur les modes d'exécution de Qiskit Runtime

Le mode de test local de Qiskit Runtime prend-il en charge les différents modes d'exécution ?

Le mode de test local prend en charge la syntaxe des différents modes d'exécution, mais comme aucune planification n'est impliquée lors des tests en local, les modes sont ignorés.

Combien de jobs peuvent s'exécuter en parallèle pour un backend spécifique ?

Le nombre de jobs s'exécutant en parallèle est basé sur le degré de parallélisme configuré pour le backend, qui est de cinq pour la plupart des backends aujourd'hui.

Comment l'utilisation est-elle rapportée pour les jobs échoués ou annulés ?

Consulte la section Jobs échoués et annulés sur la page des modes d'exécution.

Sessions

Que se passe-t-il avec mes jobs si une session est fermée ?

Si tu utilises la classe Session dans qiskit-ibm-runtime :

• Session.close() signifie que la session n'accepte plus de nouveaux jobs, mais les jobs existants s'exécutent jusqu'à leur terme.
• Session.cancel() annule tous les jobs de session en attente.

Si tu utilises directement l'API REST :

• PATCH /sessions/{id} avec accepting_jobs=False signifie que la session n'accepte plus de nouveaux jobs, mais les jobs existants s'exécutent jusqu'à leur terme.
• DELETE /sessions/{id}/close annule tous les jobs de session en attente.

Si j'utilise le mode session et que mon expérience est censée durer plusieurs heures, est-il possible de demander des calibrations ?

Non. La calibration à la demande n'est pas disponible.

Y a-t-il un délai d'inactivité interactif (TTL interactif) avec le mode session ?

Oui. Cela permet de réduire les coûts non souhaités si un utilisateur oublie de fermer sa session.

Puis-je modifier le TTL interactif ou le TTL maximum d'une session ?

Tu ne peux pas modifier la valeur du TTL interactif. Tu peux modifier la valeur du TTL maximum d'une session (voir Spécifier la durée de la session), mais elle doit être inférieure au maximum défini par le système. Contacte ton administrateur pour qu'il contacte le support IBM si tu as besoin d'un TTL interactif ou d'un TTL système maximum différent.

Comment l'utilisation des sessions affecte-t-elle les membres du réseau IBM Quantum qui ne sont pas facturés à l'usage ?

Les membres du réseau IBM Quantum bénéficient d'une capacité réservée sur les QPU IBM Quantum®. L'utilisation est déduite de cette capacité et les instances avec une capacité plus faible ont des temps d'attente plus longs.

Est-ce que j'obtiens le même parallélisme en mode session qu'en mode batch ?

Oui. Si tu soumets plusieurs jobs simultanément dans une session, ces jobs s'exécuteront en parallèle.

Les sessions peuvent-elles être interrompues par des mises à jour ou des calibrations du QPU ?

Non. Les sessions s'exécutent en mode dédié, ce qui signifie que l'utilisateur a un accès total au backend. Les sessions ne sont jamais interrompues par des calibrations ou des mises à jour logicielles.

Le temps de compilation est-il comptabilisé comme usage en mode session ?

Oui. En mode session, l'utilisation correspond au temps horloge pendant lequel le QPU est engagé dans la session. Elle commence lorsque le premier job de session démarre et se termine lorsque la session devient inactive, est fermée, ou lorsque le dernier job se termine, selon ce qui se produit en dernier. Ainsi, l'utilisation continue à s'accumuler après la fin d'une session si le QPU est encore en train d'exécuter un job. De plus, le temps après la fin d'un job pendant lequel le QPU attend un autre job de session (le TTL interactif) est comptabilisé comme usage. C'est pourquoi tu dois t'assurer que la session est fermée dès que tu as terminé de lui soumettre des jobs.

Batch

Combien de jobs s'exécutent en parallèle en mode batch ?

Le nombre de jobs s'exécutant en parallèle est basé sur le degré de parallélisme configuré pour le backend, qui est de cinq pour la plupart des backends. Cependant, le nombre de jobs simultanés dans un batch actif peut être inférieur car d'autres jobs pourraient déjà être en cours d'exécution lorsque le batch devient actif.

En quoi l'exécution de N PUBs en mode job diffère-t-elle de l'exécution de N jobs à PUB unique en mode batch ?

La principale différence réside dans le compromis entre temps et coût :

Mode batch :

• Le temps d'exécution total est moindre car le traitement classique peut s'exécuter en parallèle.
• Il y a un léger overhead pour l'exécution de chaque job, donc tu paies un peu plus pour les jobs en batch. Cet overhead est corrélé à la taille du job. Par exemple, l'utilisation totale de deux jobs, contenant chacun 40 circuits 100x100, est de six secondes de plus qu'un seul job contenant 80 circuits.
• Comme le mode batch ne te donne pas un accès exclusif à un backend, les jobs d'un batch peuvent s'exécuter avec les jobs d'autres utilisateurs ou des jobs de calibration.
• Si certains jobs échouent, tu obtiens quand même les résultats des jobs terminés.
• Tu peux agir au milieu d'une charge de travail en batch en te basant sur les résultats des jobs terminés. Par exemple, tu peux annuler le reste des jobs si les résultats initiaux semblent incorrects.

Mode job :

• Le temps d'exécution total sera probablement plus élevé car il n'y a pas de parallélisme.
• Tu ne paies pas l'overhead par job supplémentaire associé aux charges de travail en batch.
• Tous tes circuits s'exécuteront ensemble.
• Si ce job unique échoue, tu n'obtiens pas de résultats partiels.
• Ton job pourrait atteindre la limite s'il contient trop de circuits ou si les circuits sont trop grands.

En général, si chacun de tes jobs consomme moins d'une minute de temps QPU, envisage de les combiner en un job plus grand (cela s'applique à tous les modes d'exécution).

Combien de jobs puis-je soumettre dans un batch ?

Bien qu'il n'y ait pas de limite au nombre de jobs que tu peux soumettre dans un batch, il y a une durée maximale associée à un batch. C'est-à-dire que lorsque le temps horloge d'un batch (qui commence lorsque le premier job du batch commence à s'exécuter) dépasse la durée maximale définie par le système, le batch n'accepte plus de nouveaux jobs, et tous les jobs mis en file d'attente mais non en cours d'exécution sont annulés. De plus, il y a des limites sur la quantité d'utilisation que tes jobs peuvent consommer en fonction de ton plan. Pour déterminer la durée maximale associée à un batch, utilise la méthode batch.details() et recherche la valeur max_time.

Quand mes jobs en mode batch s'exécuteraient-ils en parallèle avec les jobs d'autres utilisateurs ?

Le degré de parallélisme configuré pour un backend est également appelé « voies d'exécution ». S'il y a une ou plusieurs voies d'exécution disponibles et que tes jobs en batch sont les suivants dans la file d'attente, le planificateur démarre suffisamment de jobs pour remplir les voies. De même, si ton batch n'a pas assez de jobs pour remplir les voies, le planificateur démarre les jobs d'autres utilisateurs.

Exemple : le backend que tu choisis dispose de cinq voies d'exécution, et deux d'entre elles sont actuellement occupées par les jobs d'autres utilisateurs. Ton batch de six jobs est le suivant dans la file d'attente.

Comme il y a trois voies disponibles, le planificateur démarre trois de tes six jobs en batch. Il continue à démarrer des jobs dans ton batch au fur et à mesure que des jobs se terminent et que des voies d'exécution se libèrent. Si une voie se libère et qu'il n'y a plus de jobs dans ton batch, le planificateur démarre le job suivant dans la file d'attente.

Tous mes jobs en batch doivent-ils attendre dans la file d'attente ?

Comme les QPU sont des ressources limitées et partagées, tous les jobs doivent attendre dans la file d'attente. Cependant, lorsque le premier job de ton batch commence à s'exécuter, tous les autres jobs de ce batch passent essentiellement en tête de la file d'attente et sont priorisés par le planificateur.

Un batch se termine-t-il automatiquement lorsque le dernier job associé se termine ?

Oui. Cependant, il y a un léger overhead associé à cette détection automatique, donc tu devrais toujours fermer ton batch et ta session.

Les batchs peuvent-ils être interrompus par des calibrations ou des mises à jour logicielles

Oui. Les charges de travail en batch peuvent être interrompues par des calibrations ou des mises à jour logicielles.

Le temps de compilation est-il comptabilisé comme usage en mode batch ?

Non. En mode batch, seul le temps passé sur le matériel quantique est comptabilisé comme usage.