Zadania dry-run

Zadanie dry-run uruchamia Twoje obciążenie w IBM Quantum® Compute Service bez zużywania czasu QPU. Użyj zadania dry-run, aby przed prawdziwym uruchomieniem zrobić następujące rzeczy:

• **Sprawdź zużycie, jakie zadanie wygenerowałoby na prawdziwym QPU.

• Zwaliduj zadanie. Quantum Compute sprawdza parametry zadania tak samo jak w przypadku prawdziwego zadania.

• Pobierz harmonogram czasowy obwodu, jeśli o niego poprosisz, aby zdebugować zadanie przed prawdziwym uruchomieniem.

W przeciwieństwie do zadań dry-run, lokalne testowanie (fake backendy i Qiskit Aer) działa na Twoim własnym komputerze, więc nie może dostarczyć danych o zużyciu, walidacji po stronie usługi ani informacji o czasie po stronie usługi. Aby porównać oba podejścia, zobacz Urządzenia mock a fake backendy.

uwaga

• Zadania dry-run wymagają qiskit-ibm-runtime w wersji v0.51.0 lub nowszej.
• Zadania dry-run są dostępne we wszystkich regionach i tylko w planach Flex, Premium i On-Prem. Nie są dostępne w planach Open ani Pay-As-You-Go.

Jak to działa

Aby uruchomić zadanie dry-run, przekaż dry_run=True do metody run() prymitywu:

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 jest argumentem metody run() (domyślnie False), a nie opcją środowiska uruchomieniowego. Jest dostępny dla wszystkich prymitywów.

Zadanie dry-run ma następujące cechy:

• Działa w IBM Quantum Compute Service w chmurze, a nie na Twoim komputerze.

• Używa danych kalibracyjnych z prawdziwego QPU, a nie tylko migawki.

• Jego wyniki zachowują oczekiwany schemat i kształt wyników z prawdziwego QPU, ale zawierają losowe dane mock. Nie są to rzeczywiste ani symulowane wyniki pomiarów, więc nie używaj ich do sprawdzania poprawności fizycznej.

• Przetwarzanie odbywa się na serwerze, więc zadanie może nie zakończyć się natychmiast.

Rozmiar obwodu, liczba shotów i inne limity są takie same jak dla każdego zadania danego programu.

dry_run=True działa również wtedy, gdy backend jest już urządzeniem mock.

Odczyt zużycia

Zużycie ukończonego zadania dry-run jest takie samo, jakie to samo zadanie wygenerowałoby na prawdziwym QPU, z wyjątkiem rzadkich sytuacji, gdy dane kalibracyjne znacząco się zmienią po zadaniu dry-run i przed zadaniem na prawdziwym QPU.

• job.usage() zwraca zużycie w sekundach.

• job.metrics()["usage"] zwraca te same dane wraz ze statusem zużycia.

Zużycie z zadania dry-run nie jest naliczane, nie pomniejsza alokacji w Twoim planie i nie wlicza się do żadnych limitów.

Nie używaj job.usage_estimation z zadaniami dry-run

Nie używaj job.usage_estimation w zadaniu dry-run. Użyj job.usage().

job.usage() zwraca 0, dopóki obliczenie zużycia nie zostanie sfinalizowane, więc przed odczytem poczekaj na zakończenie zadania.

Harmonogram czasowy obwodu

Aby zażądać harmonogramu czasowego obwodu, użyj tej samej opcji co w przypadku prawdziwego zadania. Szczegóły znajdziesz w Wizualizacja czasów obwodu.

Ograniczenia

• Tylko tryby job i batch. Zadania dry-run można uruchamiać tylko w job mode i batch mode.

• Tylko plany Flex, Premium i On-Prem. Zadania dry-run nie są dostępne w planach Open ani Pay-As-You-Go.

Urządzenia mock

Urządzenia mock są implementacją stojącą za zadaniami dry-run. Zadania dry-run domyślnie ukrywają urządzenia mock, ale spotkasz je w następujących przypadkach:

• Instancje skonfigurowane tak, by miały dostęp tylko do urządzeń mock. Przykład: jeśli używasz service.backend("ibm_phoenix"), aby wysłać zadanie dry-run na ibm_phoenix, ale Twoja instancja nie ma dostępu do ibm_phoenix, otrzymasz QiskitBackendNotFoundError. Zamiast tego wybierz urządzenie mock bezpośrednio za pomocą service.backend("mock_phoenix").

• Zasoby obliczeniowe. Urządzenia mock są domyślnie ukryte na stronie Compute resources. Tabela na stronie ma opcję filtra, by je uwzględnić, ale dostęp do urządzeń mock mają tylko plany Flex, Premium i On-Prem.

• Tabela obciążeń. Zadania z urządzeń mock są domyślnie ukryte na stronie Workloads. Tabela ma opcję filtra (ikona lejka), by je wyświetlić.

• Python API. service.backends() i service.jobs() pomijają urządzenia mock, chyba że wywołasz je z include_mocks=True. IBMBackend.is_mock wskazuje, czy backend jest urządzeniem mock. service.least_busy() nigdy nie zwraca urządzenia mock.

Urządzenia mock a fake backendy

Nazwy są podobne, ale urządzenie mock i fake backend to różne rzeczy. Fake backend to lokalny obiekt w Twoim środowisku Pythona. Urządzenie mock to zasób chmurowy w IBM Quantum Compute Service.

	Urządzenie mock (na przykład mock_phoenix)	Fake backend (na przykład FakeManilaV2)
Czym jest	Urządzenie w IBM Quantum Compute Service	Klasa Pythona w qiskit_ibm_runtime.fake_provider
Gdzie działa	W chmurze, w usłudze	Lokalnie, na Twoim komputerze
Jak go uzyskać	service.backend("mock_phoenix") lub automatycznie przez run(..., dry_run=True)	from qiskit_ibm_runtime.fake_provider import ...
Konto i instancja	Tylko określone plany (Flex, Premium lub On-Prem)	Wszystkie instancje i plany
Kalibracja	Na żywo, w każdej chwili zgodna z prawdziwym urządzeniem	Stała migawka dostarczana z zainstalowanym pakietem
Wyniki	Losowe dane o oczekiwanym schemacie. To nie jest symulacja	Zaszumiona symulacja używająca modelu szumu z migawki
Wyniki mające sens fizyczny	Nie. Nigdy nie używaj ich do sprawdzania poprawności	W przybliżeniu, w granicach modelu szumu
Raportowane zużycie	Tak	Brak
Naliczane lub wliczane do alokacji planu albo limitów	Nie	Nie
Walidacja zadania	Wykonuje ją usługa, tak samo jak dla prawdziwego zadania	Ogranicza się do tego, co sprawdza klient
Harmonogram czasowy	Dostępny na żądanie	Niedostępny
Tryby wykonania	Tylko job i batch mode. Sesje są zablokowane	Składnia sesji jest akceptowana, ale ignorowana (tryb lokalny nie ma prawdziwych sesji ani batchy)
Zakończenie	Asynchronicznie, na serwerze	Działa lokalnie i zwraca wynik po zakończeniu
Widoczność w interfejsie platformy i listach API	Domyślnie ukryte (Compute resources, tabela Workloads, backends(), jobs()). Włącz, aby pokazać	Nigdy, ponieważ nic nie jest wysyłane do usługi

Jak wybrać

• Aby dowiedzieć się, ile zużycia zadanie pochłonie i czy usługa je zaakceptuje, użyj zadania dry-run.

• Aby dowiedzieć się, jak może wyglądać wynik, lub pracować offline, użyj fake backendu albo Aera.

• Aby zrobić jedno i drugie, iteruj nad obwodami i wynikami z fake backendem, a potem użyj dry-run jako ostatniego sprawdzenia przed prawdziwym QPU.

Częste źródła nieporozumień

• Urządzenie mock nie jest symulatorem. Jego wynik jest losowy, więc próbkowanie obwodu Bella na mock_phoenix nie zwraca rozkładu Bella. Jeśli chcesz realistycznego zaszumionego wyniku, użyj fake backendu.

• Fake backend nie jest urządzeniem na żywo. Jego kalibracja to migawka i może być nieaktualna. Urządzenie mock śledzi prawdziwą kalibrację, więc transpilowane obwody i czasy odpowiadają temu, co QPU widzi dzisiaj.

• Żadne z nich nie działa na prawdziwym sprzęcie. Żadne nie zużywa czasu QPU, ale tylko zadanie dry-run przechodzi przez usługę.

• usage_estimation nie jest szacunkiem z dry-run. Dla zadania dry-run job.usage() zwraca liczbę sekund zużycia, którą naliczono by Ci za zadanie na prawdziwym QPU.

Przypadki użycia

Studenci i kursy

Administrator ogranicza instancję wyłącznie do urządzeń mock, używając przełącznika dostosowania QPU podczas tworzenia lub edycji instancji. Studenci mogą wtedy walidować swoje ładunki od początku do końca bez zużywania prawdziwego czasu QPU ani RU. Ponieważ instancja ma dostęp tylko do urządzeń mock, studenci wybierają backend po jego nazwie mock:

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

Planowanie projektu

Zespół, który zaraz zacznie projekt, uruchamia reprezentatywne zadania w trybie dry-run, aby zobaczyć, ile RU potrzebuje projekt, zanim wybierze plan lub alokację:

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

Ostatnie sprawdzenie przed uruchomieniem na prawdziwym QPU

Zwaliduj parametry i sprawdź harmonogram czasowy za pomocą dry_run=True, a następnie usuń ten argument i uruchom na prawdziwym QPU. Nic więcej w Twoim kodzie się nie zmienia:

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

Następne kroki

Zalecenia

• Testuj programy na własnym komputerze za pomocą trybu testowania lokalnego.
• Dowiedz się, jak mierzone jest zużycie obciążenia.
• Zwizualizuj harmonogram czasowy obwodu.
• Poznaj jednostki zasobów i dostępne plany.