Jobs dry-run

Un job dry-run exécute ta charge de travail via IBM Quantum® Compute Service sans utiliser de temps QPU. Utilise un job dry-run pour faire ce qui suit avant de t'engager dans une vraie exécution :

• **Obtenir la consommation que le job entraînerait sur le vrai QPU.

• Valider le job. Quantum Compute vérifie les paramètres du job, de la même manière que pour un vrai job.

• Obtenir le planning temporel du circuit, si tu le demandes, pour déboguer le job avant de l'exécuter pour de bon.

Contrairement aux jobs dry-run, les tests locaux (backends fictifs et Qiskit Aer) s'exécutent sur ta propre machine et ne peuvent donc pas fournir de chiffres de consommation, de validation côté service ni d'informations de timing du service. Pour comparer les deux approches, consulte Appareils mock comparés aux backends fictifs.

remarque

• qiskit-ibm-runtime v0.51.0 ou ultérieure est requis pour les jobs dry-run.
• Les jobs dry-run sont disponibles dans toutes les régions et uniquement avec les plans Flex, Premium et On-Prem. Ils ne sont pas disponibles avec les plans Open ou Pay-As-You-Go.

Comment ça marche

Pour exécuter un job dry-run, passe dry_run=True à la méthode run() de la primitive :

backend = service.backend("ibm_phoenix")
isa_circuit = pm.run(circuit)  # transpiled for ibm_phoenix
sampler = Sampler(mode=backend)
job = sampler.run([isa_circuit], dry_run=True)
job.result()  # wait for completion
print(job.usage())

dry_run est un argument de la méthode run() (la valeur par défaut est False), et non une option d'exécution. Il est disponible pour toutes les primitives.

Un job dry-run présente les caractéristiques suivantes :

• Il s'exécute dans IBM Quantum Compute Service, dans le cloud, et non sur ta machine.

• Il utilise les données de calibration du vrai QPU, et pas seulement un instantané.

• Ses résultats conservent le schéma attendu et suivent la forme attendue des résultats du vrai QPU, mais contiennent des données fictives aléatoires. Ce ne sont pas de vrais résultats de mesure ni des résultats simulés ; ne les utilise donc pas pour vérifier l'exactitude physique.

• Le traitement a lieu sur le serveur, donc le job peut ne pas se terminer immédiatement.

La taille du circuit, les shots et les autres limites sont les mêmes que pour n'importe quel job de ce programme.

dry_run=True fonctionne aussi lorsque le backend est déjà un appareil mock.

Lire la consommation

La consommation d'un job dry-run terminé est celle que le même job entraînerait sur le vrai QPU, sauf dans de rares situations où les données de calibration changent de manière significative après le job dry-run et avant le job sur un vrai QPU.

• job.usage() renvoie la consommation en secondes.

• job.metrics()["usage"] renvoie les mêmes données avec l'état de la consommation.

La consommation dry-run n'est pas facturée, ne consomme pas l'allocation de ton plan et ne compte dans aucune limite.

N'utilise pas job.usage_estimation avec les jobs dry-run

N'utilise pas job.usage_estimation sur un job dry-run. Utilise job.usage().

job.usage() renvoie 0 tant que le calcul de la consommation n'est pas final ; attends donc la fin du job avant de la lire.

Planning temporel du circuit

Pour demander le planning temporel du circuit, utilise la même option que pour un vrai job. Pour tous les détails, consulte Visualiser le timing du circuit.

Limitations

• Modes job et batch uniquement. Les jobs dry-run ne peuvent s'exécuter qu'en job mode et en batch mode.

• Plans Flex, Premium et On-Prem uniquement. Les jobs dry-run ne sont pas disponibles avec les plans Open ou Pay-As-You-Go.

Appareils mock

Les appareils mock sont l'implémentation sous-jacente des jobs dry-run. Les jobs dry-run masquent les appareils mock par défaut, mais tu les rencontres dans les cas suivants :

• Instances configurées pour n'accéder qu'à des appareils mock. Exemple : si tu utilises service.backend("ibm_phoenix") pour soumettre un job dry-run sur ibm_phoenix, mais que ton instance n'a pas accès à ibm_phoenix, tu obtiendras une QiskitBackendNotFoundError. Sélectionne plutôt directement l'appareil mock avec service.backend("mock_phoenix").

• Compute resources. Les appareils mock sont masqués par défaut sur la page Compute resources. Le tableau de la page dispose d'une option de filtre pour les inclure, mais seuls les plans Flex, Premium et On-Prem ont accès aux appareils mock.

• Tableau Workloads. Les jobs provenant d'appareils mock sont masqués par défaut sur la page Workloads. Le tableau dispose d'une option de filtre (l'icône en forme d'entonnoir) pour les afficher.

• API Python. service.backends() et service.jobs() excluent les appareils mock, sauf si tu les appelles avec include_mocks=True. IBMBackend.is_mock indique si un backend est un appareil mock. service.least_busy() ne renvoie jamais d'appareil mock.

Appareils mock comparés aux backends fictifs

Les noms sont proches, mais un appareil mock et un backend fictif sont deux choses différentes. Un backend fictif est un objet local dans ton environnement Python. Un appareil mock est une ressource cloud dans IBM Quantum Compute Service.

	Appareil mock (par exemple mock_phoenix)	Backend fictif (par exemple FakeManilaV2)
Ce que c'est	Un appareil dans IBM Quantum Compute Service	Une classe Python dans qiskit_ibm_runtime.fake_provider
Où il s'exécute	Dans le cloud, dans le service	En local, sur ta machine
Comment l'obtenir	service.backend("mock_phoenix"), ou automatiquement avec run(..., dry_run=True)	from qiskit_ibm_runtime.fake_provider import ...
Compte et instance	Plans spécifiques uniquement (Flex, Premium ou On-Prem)	Toutes les instances et tous les plans
Calibration	En direct, correspond à tout moment à l'appareil réel	Instantané figé fourni avec le paquet installé
Résultats	Données aléatoires avec le schéma attendu. Pas une simulation	Simulation bruitée qui utilise le modèle de bruit de l'instantané
Résultats physiquement significatifs	Non. Ne les utilise jamais pour vérifier l'exactitude	Approximativement, dans les limites du modèle de bruit
Consommation rapportée	Oui	Aucune
Facturé ou décompté de l'allocation du plan ou des limites	Non	Non
Validation du job	Effectuée par le service, comme pour un vrai job	Limitée à ce que vérifie le client
Planning temporel	Disponible sur demande	Non disponible
Modes d'exécution	Job mode et batch mode uniquement. Les Sessions sont bloquées	Syntaxe de Session acceptée mais ignorée (le mode local n'a pas de vraies sessions ni de vrais batches)
Achèvement	Asynchrone, sur le serveur	S'exécute en local et renvoie le résultat à la fin
Affiché dans l'interface de la plateforme et les listes de l'API	Masqué par défaut (Compute resources, tableau Workloads, backends(), jobs()). À activer explicitement pour l'afficher	Jamais, car rien n'est envoyé au service

Comment choisir

• Pour savoir combien de consommation le job va utiliser, ou si le service l'acceptera, utilise un job dry-run.

• Pour savoir à quoi la sortie pourrait ressembler, ou pour travailler hors ligne, utilise un backend fictif ou Aer.

• Pour faire les deux, itère sur les circuits et les résultats avec un backend fictif, puis fais un dry-run comme dernière vérification avant le vrai QPU.

Points de confusion courants

• Un appareil mock n'est pas un simulateur. Sa sortie est aléatoire ; échantillonner un circuit de Bell sur mock_phoenix ne renvoie donc pas une distribution de Bell. Si tu veux une sortie bruitée réaliste, utilise un backend fictif.

• Un backend fictif n'est pas l'appareil réel en direct. Sa calibration est un instantané et peut être obsolète. Un appareil mock suit la calibration réelle, de sorte que les circuits transpilés et le timing correspondent à ce que le QPU voit aujourd'hui.

• Aucun des deux ne s'exécute sur du vrai matériel. Ni l'un ni l'autre ne consomme de temps QPU, mais seul un job dry-run passe par le service.

• usage_estimation n'est pas l'estimation dry-run. Pour un job dry-run, job.usage() renvoie les secondes de consommation qui te seraient facturées sur un vrai QPU.

Cas d'usage

Étudiants et cours

Un administrateur restreint une instance aux seuls appareils mock, à l'aide du bouton de personnalisation des QPU lors de la création ou de la modification de l'instance. Les étudiants valident alors leurs charges de travail de bout en bout sans consommer de vrai temps QPU ni de RUs. Comme l'instance n'a accès qu'aux appareils mock, les étudiants sélectionnent le backend par son nom mock :

backend = service.backend("mock_phoenix")
sampler = Sampler(mode=backend)
job = sampler.run([isa_circuit], dry_run=True)

Planification de projet

Une équipe sur le point de démarrer un projet exécute en dry-run des jobs représentatifs pour voir les RUs dont le projet a besoin, avant de choisir un plan ou une allocation :

backend = service.backend("ibm_phoenix")
sampler = Sampler(mode=backend)
job = sampler.run([isa_circuit], dry_run=True)
job.result()
print(job.usage()) 

Dernière vérification avant l'exécution sur un vrai QPU

Valide les paramètres et inspecte le planning temporel avec dry_run=True, puis supprime l'argument et exécute sur le vrai QPU. Rien d'autre ne change dans ton code :

sampler = Sampler(mode=backend)

# Pre-flight check
job = sampler.run([isa_circuit], dry_run=True)
job.result()

# Real run - same code, without dry_run
job = sampler.run([isa_circuit])

Prochaines étapes

Recommandations

• Teste des programmes sur ta propre machine avec le mode de test local.
• Découvre comment la consommation de la charge de travail est mesurée.
• Visualise le planning temporel du circuit.
• Comprends les unités de ressources et les plans disponibles.