Job-uri dry-run

Un job dry-run rulează sarcina ta prin IBM Quantum® Compute Service fără a folosi timp QPU. Folosește un job dry-run pentru a face următoarele înainte de a te angaja într-o rulare reală:

• **Obține consumul pe care l-ar genera jobul pe QPU-ul real.

• Validează jobul. Quantum Compute verifică parametrii jobului, la fel ca pentru un job real.

• Obține programul de temporizare a circuitului, dacă îl soliciți, pentru a depana jobul înainte de a-l rula pe bune.

Spre deosebire de job-urile dry-run, testarea locală (backend-uri fake și Qiskit Aer) rulează pe propriul tău calculator și de aceea nu poate furniza valori de consum, validare pe partea serviciului sau informații de temporizare ale serviciului. Pentru a compara cele două abordări, vezi Dispozitive mock comparate cu backend-urile fake.

notă

• Pentru job-urile dry-run este necesar qiskit-ibm-runtime v0.51.0 sau o versiune ulterioară.
• Job-urile dry-run sunt disponibile în toate regiunile și doar în planurile Flex, Premium și On-Prem. Nu sunt disponibile în planurile Open sau Pay-As-You-Go.

Cum funcționează

Pentru a rula un job dry-run, transmite dry_run=True metodei run() a primitivei:

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 este un argument al metodei run() (valoarea implicită este False), nu o opțiune de runtime. Este disponibil pentru toate primitivele.

Un job dry-run are următoarele caracteristici:

• Rulează în IBM Quantum Compute Service în cloud, nu pe calculatorul tău.

• Folosește datele de calibrare ale QPU-ului real, nu doar un instantaneu.

• Rezultatele sale păstrează schema așteptată și urmează forma așteptată a rezultatelor de la QPU-ul real, dar conțin date mock randomizate. Nu sunt rezultate de măsurare reale sau simulate, așa că nu le folosi pentru a verifica corectitudinea fizică.

• Procesarea are loc pe server, deci este posibil ca jobul să nu se termine imediat.

Dimensiunea circuitului, numărul de shot-uri și alte limite sunt aceleași ca pentru orice job al acelui program.

dry_run=True funcționează și atunci când backend-ul este deja un dispozitiv mock.

Citește consumul

Consumul unui job dry-run finalizat este consumul pe care l-ar genera același job pe QPU-ul real, cu excepția situațiilor rare în care datele de calibrare se modifică semnificativ după jobul dry-run și înainte de jobul pe un QPU real.

• job.usage() returnează consumul în secunde.

• job.metrics()["usage"] returnează aceleași date împreună cu starea consumului.

Consumul dry-run nu este taxat, nu consumă alocarea planului tău și nu se numără pentru nicio limită.

Nu folosi job.usage_estimation cu job-uri dry-run

Nu folosi job.usage_estimation pentru un job dry-run. Folosește job.usage().

job.usage() returnează 0 până când calculul consumului este final, așa că așteaptă ca jobul să se termine înainte de a-l citi.

Programul de temporizare a circuitului

Pentru a solicita programul de temporizare a circuitului, folosește aceeași opțiune ca pentru un job real. Pentru detalii complete, vezi Vizualizează temporizarea circuitului.

Limitări

• Doar modurile job și batch. Job-urile dry-run pot rula doar în job mode și batch mode.

• Doar planurile Flex, Premium și On-Prem. Job-urile dry-run nu sunt disponibile în planurile Open sau Pay-As-You-Go.

Dispozitive mock

Dispozitivele mock sunt implementarea din spatele job-urilor dry-run. Job-urile dry-run ascund implicit dispozitivele mock, dar le întâlnești în aceste cazuri:

• Instanțe configurate să acceseze doar dispozitive mock. Exemplu: dacă folosești service.backend("ibm_phoenix") pentru a trimite un job dry-run pe ibm_phoenix, dar instanța ta nu are acces la ibm_phoenix, vei primi un QiskitBackendNotFoundError. În schimb, selectează direct dispozitivul mock cu service.backend("mock_phoenix").

• Resurse de calcul. Dispozitivele mock sunt ascunse implicit pe pagina Resurse de calcul. Tabelul din pagină are o opțiune de filtrare pentru a le include, dar doar planurile Flex, Premium și On-Prem au acces la dispozitive mock.

• Tabelul de sarcini. Job-urile de pe dispozitive mock sunt ascunse implicit pe pagina Sarcini. Tabelul are o opțiune de filtrare (pictograma de pâlnie) pentru a le afișa.

• API Python. service.backends() și service.jobs() exclud dispozitivele mock, cu excepția cazului în care le apelezi cu include_mocks=True. IBMBackend.is_mock indică dacă un backend este un dispozitiv mock. service.least_busy() nu returnează niciodată un dispozitiv mock.

Dispozitive mock comparate cu backend-urile fake

Numele sunt similare, dar un dispozitiv mock și un backend fake sunt lucruri diferite. Un backend fake este un obiect local în mediul tău Python. Un dispozitiv mock este o resursă cloud în IBM Quantum Compute Service.

	Dispozitiv mock (de exemplu mock_phoenix)	Backend fake (de exemplu FakeManilaV2)
Ce este	Un dispozitiv în IBM Quantum Compute Service	O clasă Python în qiskit_ibm_runtime.fake_provider
Unde rulează	În cloud, în serviciu	Local, pe calculatorul tău
Cum îl obții	service.backend("mock_phoenix"), sau automat cu run(..., dry_run=True)	from qiskit_ibm_runtime.fake_provider import ...
Cont și instanță	Doar anumite planuri (Flex, Premium sau On-Prem)	Toate instanțele și planurile
Calibrare	Live, corespunde dispozitivului real în orice moment	Instantaneu fix livrat cu pachetul instalat
Rezultate	Date randomizate cu schema așteptată. Nu este o simulare	Simulare zgomotoasă care folosește modelul de zgomot al instantaneului
Rezultate cu semnificație fizică	Nu. Nu le folosi niciodată pentru a verifica corectitudinea	Aproximativ, în limitele modelului de zgomot
Consum raportat	Da	Niciunul
Taxat sau numărat în alocarea planului sau în limite	Nu	Nu
Validarea jobului	Făcută de serviciu, la fel ca pentru un job real	Limitată la ceea ce verifică clientul
Programul de temporizare	Disponibil la cerere	Indisponibil
Moduri de execuție	Doar job mode și batch mode. Sesiunile sunt blocate	Sintaxa de sesiune este acceptată, dar ignorată (modul local nu are sesiuni sau batch-uri reale)
Finalizare	Asincronă, pe server	Rulează local și returnează la terminare
Afișat în interfața platformei și în listele API	Ascuns implicit (Resurse de calcul, tabelul de sarcini, backends(), jobs()). Activează opțiunea pentru a-l afișa	Niciodată, deoarece nu se trimite nimic către serviciu

Cum alegi

• Pentru a afla cât consum va avea jobul sau dacă serviciul îl va accepta, folosește un job dry-run.

• Pentru a afla cum ar putea arăta rezultatul sau pentru a lucra offline, folosește un backend fake sau Aer.

• Pentru a face ambele, iterează pe circuite și rezultate cu un backend fake, apoi rulează dry-run ca ultimă verificare înainte de QPU-ul real.

Puncte frecvente de confuzie

• Un dispozitiv mock nu este un simulator. Rezultatul său este aleatoriu, deci eșantionarea unui circuit Bell pe mock_phoenix nu returnează o distribuție Bell. Dacă vrei un rezultat zgomotos realist, folosește un backend fake.

• Un backend fake nu este dispozitivul live. Calibrarea sa este un instantaneu și poate fi depășită. Un dispozitiv mock urmărește calibrarea reală, deci circuitele transpilate și temporizarea corespund cu ceea ce vede QPU-ul astăzi.

• Niciunul nu rulează pe hardware real. Niciunul nu consumă timp QPU, dar doar un job dry-run trece prin serviciu.

• usage_estimation nu este estimarea dry-run. Pentru un job dry-run, job.usage() returnează secundele de consum care ți-ar fi taxate pe un QPU real.

Cazuri de utilizare

Studenți și cursuri

Un administrator restricționează o instanță doar la dispozitive mock, folosind comutatorul de personalizare a QPU-ului la crearea sau editarea instanței. Studenții își validează apoi sarcinile de la un capăt la altul, fără a consuma timp QPU real sau RU. Deoarece instanța are acces doar la dispozitive mock, studenții selectează backend-ul după numele său mock:

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

Planificarea proiectului

O echipă care urmează să înceapă un proiect rulează dry-run pe job-uri reprezentative pentru a vedea RU de care are nevoie proiectul, înainte de a alege un plan sau o alocare:

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

Verificarea finală înainte de rularea pe un QPU real

Validează parametrii și inspectează programul de temporizare cu dry_run=True, apoi elimină argumentul și rulează pe QPU-ul real. Nimic altceva din codul tău nu se schimbă:

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])

Pașii următori

Recomandări

• Testează programele pe propriul calculator cu Local testing mode.
• Află cum este măsurat consumul sarcinii.
• Vizualizează programul de temporizare a circuitului.
• Înțelege unitățile de resurse și planurile disponibile.