Wprowadzenie do trybów wykonania Qiskit Runtime
Gdy Qiskit Runtime zostało wprowadzone, użytkownicy mogli wykonywać Circuit tylko jako pojedyncze zadania. Wraz z pojawieniem się różnych typów obciążeń kwantowych stała się oczywista potrzeba stosowania różnych strategii harmonogramowania. Tryby wykonania określają, w jaki sposób twoje zadania są planowane, a wybór odpowiedniego trybu wykonania pozwala efektywnie uruchomić obciążenie w ramach budżetu. Dostępne są trzy tryby wykonania: job, session i batch.
Tryb job
Pojedyncze żądanie prymitywne do Estimator lub Sampler, złożone bez menedżera kontekstu. Circuit i dane wejściowe są pakowane jako primitive unified blocs (PUBs) i przesyłane jako zadanie wykonania na komputerze kwantowym. Aby uruchomić w trybie job, podaj mode=backend podczas tworzenia instancji prymitywu. Zajrzyj do Przykładów użycia prymitywów.
Tryb batch
Menedżer wielu zadań umożliwiający efektywne przeprowadzanie eksperymentów składających się z obciążeń wielozadaniowych. Obciążenia te składają się z niezależnie wykonywalnych zadań, które nie mają wzajemnych zależności warunkowych. W trybie batch użytkownicy przesyłają wszystkie swoje zadania jednocześnie.
System zrównoleglenia lub wątkowania kroków wstępnego przetwarzania (obliczenia klasyczne) każdego zadania prymitywnego pozwala na ściślejsze pakowanie wykonania kwantowego między zadaniami, a następnie uruchamia wykonanie kwantowe każdego zadania w szybkiej kolejności, dostarczając jak najwydajniejsze wyniki. Szczegółowe informacje na temat wątkowania znajdziesz na stronie FAQ dotyczącej trybu wykonania.
- W trybie batch nie ma gwarancji, że zadania będą uruchamiane w kolejności ich przesyłania. Ponadto, choć zadania w batchu będą uruchamiane możliwie jak najbliżej siebie, nie uzyskujesz wyłącznego dostępu do Backend. Dlatego twoje zadania w batchu mogą być uruchamiane równolegle z zadaniami innych użytkowników, jeśli QPU dysponuje wystarczającą wydajnością przetwarzania. Między zadaniami w batchu mogą również uruchamiać się zadania kalibracyjne QPU.
- Czas oczekiwania w kolejce nie skraca się dla pierwszego zadania przesłanego w ramach batchu. Dlatego batche nie przynoszą żadnych korzyści przy uruchamianiu pojedynczego zadania.
Aby uruchomić w trybie batch, podaj mode=batch podczas tworzenia instancji prymitywu lub uruchom zadanie w menedżerze kontekstu batch. Przykłady znajdziesz w artykule Uruchamianie zadań w trybie batch.
Tryb session
Dedykowane okno do uruchamiania obciążeń wielozadaniowych. W tym oknie użytkownik ma wyłączny dostęp do systemu i żadne inne zadania nie mogą być uruchamiane — w tym zadania kalibracyjne. Pozwala to użytkownikom eksperymentować z algorytmami wariacyjnymi w bardziej przewidywalny sposób, a nawet uruchamiać jednocześnie wiele eksperymentów, korzystając z równoległości w stosie. Korzystanie z sesji pomaga uniknąć opóźnień spowodowanych osobnym kolejkowaniem każdego zadania, co może być szczególnie przydatne w przypadku zadań iteracyjnych wymagających częstej komunikacji między zasobami klasycznymi i kwantowymi.
Aby uruchomić w trybie session, podaj mode=session podczas tworzenia instancji prymitywu lub uruchom zadanie w menedżerze kontekstu session. Przykłady znajdziesz w artykule Uruchamianie zadań w sesji.
- Czas oczekiwania w kolejce nie skraca się dla pierwszego zadania przesłanego w ramach sesji. Dlatego sesje nie przynoszą żadnych korzyści przy uruchamianiu pojedynczego zadania.
- Użytkownicy planu Open Plan nie mogą przesyłać zadań w trybie session.
Podstawowy przepływ pracy
Podstawowy przepływ pracy dla trybów batch i session jest podobny:
- Pierwsze zadanie w batchu lub sesji trafia do normalnej kolejki. W przypadku batchu całe zbiór zadań jest planowany razem.
- Gdy pierwsze zadanie zaczyna działać, uruchamia się timer maksymalnego czasu życia (TTL) — nie zatrzymuje się ani nie jest wstrzymywany aż do osiągnięcia końca.
- Interaktywny timer TTL uruchamia się po zakończeniu każdego zadania. Jeśli w oknie interaktywnego TTL nie ma gotowych zadań, obciążenie jest tymczasowo dezaktywowane i wznawiany jest normalny wybór zadań. Zadanie może reaktywować dezaktywowane obciążenie, jeśli batch lub session nie osiągnęły maksymalnej wartości TTL.
uwaga
Zadanie musi przejść przez normalną kolejkę, aby reaktywować obciążenie.
- Jeśli zostanie osiągnięta maksymalna wartość TTL, obciążenie kończy się, a wszystkie pozostałe zadania w kolejce kończą się niepowodzeniem. Żadne aktualnie uruchomione zadanie nie zostanie dokończone, jeśli jego ukończenie przekroczyłoby limit kosztów instancji.
Poniższy film ilustruje podstawowy przepływ pracy na przykładzie sesji:
Szczegółowe informacje na temat timerów TTL znajdziesz w przewodniku Maksymalny czas wykonania.