Session mantığı — iteratif iş akışları için bağlı yürütme

Session kelimesinin Qiskit Runtime'daki anlamı; bir web oturumundan ya da işletim sistemi oturumundan farklıdır. Burada session bir iş paketleme bağlamıdır: "şu backend üzerinde, art arda göndereceğim primitives çağrılarını aynı pencerede tut" sözleşmesi. Bu söz; ağ tarafında bağlantı yeniden açma maliyetini, kuyruk tarafında her işin baştan sıraya girmesini, ölçüm tarafında kalibrasyon penceresinin değişmesini birlikte hafifletir. Tek bir iş için faydası genellikle yoktur; ardışık onlarca veya yüzlerce iş söz konusu olduğunda ise verimi belirgin biçimde artırır.

Hangi sorunlar bir session'ı çağırır?

Tipik tetikleyiciler: (1) varyasyonel algoritmalar — VQE/QAOA — her yeni parametre vektörü için yeni bir Estimator/Sampler çağrısı; (2) hata azaltma akışları — kalibrasyon devreleriyle aynı pencerede kalmak gerekir; (3) çok-devreli karşılaştırmalar — A ve B'yi aynı kalibrasyona göre okumak; (4) interaktif Jupyter kullanımı — kullanıcı 30 saniye düşünür, sonra bir hücre daha gönderir, ama aynı bağlamı kaybetmek istemez.

Bu sayfanın sınırı

Burada IBM Runtime CLI ayarları, faturalandırma veya enterprise plan kuralları işlenmez. Amaç, Qiskit kullanıcısının kafasında session'ın yerini ve mantığını kurmak, sonra yerelde aynı düşünceyi (token gerektirmeden) yeniden üretmektir.

Varyasyonel algoritmalarda akış genellikle şu hâldedir: parametre vektörü ile devre kur, backend'e gönder, beklenen değer veya örnek dağılımı al, klasik bir optimizatör ile parametreyi güncelle, baştan başla. Her iterasyon bağımsız bir iş gibi gönderilirse, her seferinde ağ gecikmesi + kuyruk bekleme süresi yenilenir; bu maliyet iterasyon sayısıyla ölçeklenir. Session ile bu maliyetin büyük kısmı yalnız bir kez ödenir: kanal açılır, iterasyonlar aynı pencerede iletilir, son iterasyondan sonra kanal kapanır.

VQE/QAOA için işaretler

QAOA ve VQE örneklerinde "optimizer kaç kez beklenen değer ister?" sorusu doğrudan session'ın faydasını tahmin eder. Optimizer ne kadar arama yaparsa, oturum tarafından yaratılan tasarruf o kadar büyür. Sıfır gradyanlı iterasyon (ör. plateau) durumunda bile, ağ ve kuyruk maliyeti her tekrarda kalktığı için akış pürüzsüz hisseder.

Veri toplama disipliniyle ilişki

Hata azaltma akışları (ör. zero-noise extrapolation, dynamical decoupling) çoğunlukla kalibrasyon devreleri ile birlikte koşar; bu eşli koşumların aynı kalibrasyon penceresinde kalması, raporlanan oranların kıyaslanabilir olmasını sağlar. Session, bu pencereyi açık tutar.

Pratikte Qiskit Runtime session'ı bir context manager olarak kullanılır: with Session(backend=...) as session: bloğu açılır, içinde primitives örneği oluşturulur ve çağrılır, blok sonunda kanal kapanır. Bu disiplin iki faydası vardır: (1) hata atılsa bile finally mantığı session'ı temizler; (2) session yaşam süresi açıkça koddaki bir kapsam ile sınırlanır. Açık bir session.close() çağrısı da mümkündür, fakat kapsam yöntemi daha güvenlidir.

İlk iş ve "ısıtma"

Session, açıldığı anda donanım tarafında bir yer ayırma tetiklemez; ilk iş gönderildiğinde kuyrukla buluşur. İlk iş işletim için seçildiğinde, kalan iterasyonlar aynı pencere içinde daha düşük gecikmeyle yürütülür. Bu yüzden, ısıtma maliyetini ölçerken "session açıkken ilk iş ne kadar bekledi?" sorusu, "iterasyon başına ortalama" sorusundan ayrı tutulmalıdır.

Açık ve kapalı kullanım

Üretim kodunda session'ı uzun süre açık tutmak hem maliyet hem politika açısından doğru değildir; oturum yalnızca aktif kullanıldığı sürece açık olmalıdır. Bağlam yöneticisi bu disiplini hemen hemen otomatik dayatır.

Modern Qiskit Runtime primitives (SamplerV2, EstimatorV2) "mode" parametresi alır. Mode'a doğrudan bir backend nesnesi verilirse, primitives çağrısı session açmaksızın çalışır (ad-hoc); mode'a bir Session verilirse, çağrılar o oturum içinde paketlenir; mode'a bir Batch nesnesi verilirse, art arda gönderilen işler bir batch olarak gruplanır. Tek arayüz üç davranışı kapsar; programcı tarafında "aynı kod, farklı bağlam" disiplini kurulabilir.

Yerel mode

Mode'a bir FakeBackend veya yerel AerSimulator verildiğinde, primitives yerelde çalışır; ağa çıkmaz. Bu kalıbı backend mimarisi sayfasında Sampler(mode=backend) örneği ile gördük. Runtime yürütmesi sayfası primitives derinleştirir; burada yalnızca "mode = bağlam seçimi" gerçeği vurgulanır.

Aynı kod, farklı bağlam

Mantıksal sınır: primitives nesnesi nasıl oluşturulursa oluşturulsun, run([...]) çağrısının imzası aynı kalır. Mode parametresini tek bir noktada değiştirerek iteratif algoritmanızı ad-hoc / session / batch arasında taşıyabilirsiniz; algoritma mantığını yeniden yazmazsınız. Bu, kod taşınabilirliğinin doğrudan kazanımıdır.

Üç davranışın net bir kıyaslamasını tutmak, mimarinin değil kullanıcı kararının bir parçasıdır. Ad-hoc: her primitives çağrısı bağımsız bir iş gibi gönderilir; en az ön kurulum, en yüksek başına maliyet. Batch: art arda işler tek pakette gruplanır; toplam aktarımı azaltır ama art arda gelen iterasyonlar arasında "konuşma" yoktur — sonraki iterasyon, öncekinin sonucuna bağlıysa batch zorlanır. Session: art arda gelen işler aynı kanalı paylaşır ve iterasyon karar akışına izin verir; klasik optimizatör koşulu için doğal seçimdir.

Hangi durum ne ister?

Bağımsız bir Bell devresi: ad-hoc. 50 farklı sabit devrenin tek seferde koşulması: batch. Yüz iterasyonluk varyasyonel optimizasyon: session. Üretimde, bu kararı algoritma çağrısının üst katmanına ayırt etmek (örneğin bir mode parametresi) okunabilirliği artırır.

Session sonsuza kadar açık kalmaz. Üst sınırlar tipik olarak iki başlıkta tutulur: max_time — oturumun ömrü için tavan; idle — son işin bitmesinden sonra yeni iş gelmezse pasif kapanma. Hesap planına göre değerler değişir; kullanıcı kodu bu sınırlara dayanıklı yazılmalıdır: oturum kapanırsa yeniden açılır, elindeki ara sonuçlar kalıcı olarak saklanır. Bu disiplin, "tek bir uzun session" heyecanını "kısa, dayanıklı session zinciri" tasarımına çevirir.

Kuyruk ve önceliklendirmeyle ilişki

Session içinde işler arası önceliklendirme dışarıdaki ad-hoc işlere göre farklı olabilir; bu konu donanım ve plan politikasıyla yakından bağlıdır. Kuyruk mantığı sayfasında bu disiplin genişletilir.

Maliyet okunabilirliği

"Bu deney bana ne kazandırdı?" sorusunu raporlarken, session ile ad-hoc maliyetini ayrı satırlarda göstermek faydalıdır; aynı algoritmanın iki bağlamda koşulan ölçümleri, donanım vakti açısından farklı sayılar üretebilir.

Session açıkken yaşanabilecek hatalar üç ailede toplanır: kanal hataları — ağ kopması, sunucu tarafı kısa kesinti; politika hataları — plan limiti, zaman aşımı; iş hataları — devre transpile veya çalışma hatası. Üçü de session'ı tek bir genel "başarısızlığa" indirgemez; dayanıklı yazım, hangi katmanın kırıldığını ayırt etmeyi gerektirir.

Yeniden bağlanma

Kanal kopması durumunda kod, ya yeni bir session başlatmalı ya da batch / ad-hoc akışına düşmelidir. Düşmenin kararı algoritmanın doğasına bağlıdır: birbirine bağımlı iterasyonlar yapıyorsanız, kısa süreli kayıp bile uzun yeniden başlangıç anlamına gelebilir.

İş hatası ile session hatasını ayırın

Bir iş hata alırsa, session hâlâ açık ve kullanılabilir olabilir; bu durumda job sistemi içinde anlattığımız retry / log / sonraki iterasyon disiplini devreye girer. Session kapanmadıkça, programınızın bütün durumunu yeniden kurmak zorunda değilsiniz.

IBM Runtime tarafındaki Session sınıfı yerelde "gerçek" anlamıyla çalışmaz — bir hizmet ve hesap ister. Fakat session'ın düşüncesi (aynı backend nesnesini paylaşan, art arda gönderilen iş paketinde sabit bağlam) yerelde kolayca taklit edilebilir. Pratik desen: tek bir fake backend oluşturun, SamplerV2(mode=backend) veya EstimatorV2(mode=backend) nesnesini iterasyon başında bir kere kurun, tüm iterasyonlarda yeniden kullanın. Bu kalıp Runtime ile aynı kod düzenini üretir; tek fark, gerçek hizmet yerine yerel hedeftir.

Bağlam yöneticisi yazmak

Eğitim amaçlı, kısa bir LocalSession bağlam yöneticisi yazmak öğreticidir: __enter__'da backend ve primitives kurulur, __exit__'te kaynak referansları temizlenir. Bu sınıf elbette gerçek bir uzaktan kanal kurmaz, ama Runtime kullanan ekibe geçtiğinizde kalıbınız hazırdır.

İteratif örnek için disiplin

Yerel iteratif örneklerde rastgelelik tohumunu sabitlemek faydalıdır (shot mantığı sayfasındaki tartışma); böylece "iterasyon ilerledi mi?" sorusu rastgele dalgalanmadan ayrıştırılır.

Üç blok da yereldir: ağ yok, token yok, hesap yok. Birinci blok Runtime session iskeletinin yorum hattıdır (çalıştırmayın). İkinci blok yerel FakeBackend üzerinde iteratif Sampler döngüsü kurar — session düşüncesinin yerel karşılığı. Üçüncü blok küçük bir LocalSession bağlam yöneticisi gösterir; eğitim amaçlıdır.

# from qiskit_ibm_runtime import QiskitRuntimeService, Session, SamplerV2, EstimatorV2
# service  = QiskitRuntimeService()                      # ~/.qiskit/qiskit-ibm.json
# backend  = service.least_busy(simulator=False)         # canlı kuyruğa girer
# with Session(backend=backend) as session:
#     sampler   = SamplerV2(mode=session)
#     estimator = EstimatorV2(mode=session)
#     for theta in optimizer.steps():
#         expval = estimator.run([(circuit, observable, theta)]).result()
#         counts = sampler.run([(circuit_with_meas, theta)]).result()

import numpy as np
from qiskit import QuantumCircuit
from qiskit.circuit import Parameter
from qiskit_ibm_runtime import SamplerV2 as Sampler
from qiskit_ibm_runtime.fake_provider import FakeManilaV2

backend = FakeManilaV2()
sampler = Sampler(mode=backend)

theta = Parameter("theta")
qc = QuantumCircuit(2, 2)
qc.h(0)
qc.rz(theta, 0)
qc.cx(0, 1)
qc.measure([0, 1], [0, 1])

# Klasik tarafta küçük bir arama: 5 farklı parametre için P(00)'i ölçeriz.
# Gerçek bir oturumda bu döngü Runtime Session içinde paketlenirdi;
# burada yerel FakeBackend aynı backend nesnesini paylaşarak taklit eder.
for theta_val in np.linspace(0.0, np.pi, 5):
    bound = qc.assign_parameters({theta: float(theta_val)})
    result = sampler.run([bound], shots=512).result()
    counts = result[0].data.c.get_counts()
    p00 = counts.get("00", 0) / 512
    print(f"theta={theta_val:.3f}  P(00)={p00:.3f}")

from contextlib import contextmanager
from qiskit import QuantumCircuit
from qiskit_ibm_runtime import SamplerV2 as Sampler
from qiskit_ibm_runtime.fake_provider import FakeManilaV2

@contextmanager
def local_session(backend_factory):
    """Yerel öğretim: bağlam içinde aynı backend ve sampler paylaşılır.
    Gerçek Runtime Session değildir — yalnızca aynı kod düzenini taklit eder."""
    backend = backend_factory()
    sampler = Sampler(mode=backend)
    label = f"local-session({backend.name})"
    print("AÇILDI:", label)
    try:
        yield sampler
    finally:
        print("KAPANDI:", label)

qc = QuantumCircuit(2, 2)
qc.h(0)
qc.cx(0, 1)
qc.measure([0, 1], [0, 1])

with local_session(FakeManilaV2) as sampler:
    for i in range(3):
        result = sampler.run([qc], shots=256).result()
        print(f"iter {i} →", result[0].data.c.get_counts())

Session, iteratif iş yüklerinde ağ ve kuyruk maliyetini bir kez ödeten bağlı bir kanaldır; tek seferlik koşumlarda gerek yoktur. Mode parametresi ad-hoc / batch / session arasındaki geçişi tek noktada tutar. Yerelde aynı düşünceyi (FakeBackend + primitives) hesap gerektirmeden çalışabilir hâle getirebilirsiniz; üretime geçtiğinizde kalıbınız hazırdır.

• Backend mimarisi — BackendV2 sözleşmesi.
• Provider sistemi — hesap ve katalog katmanı.
• Runtime yürütmesi — primitives ailesi.
• Job sistemi ve kuyruk mantığı — asenkron yürütme.
• Fake backend kullanımı — yerel öğretim hedefi.
• QAOA · Qiskit — session'ın en yaygın kullanım örneği.