Toplu yürütüm — Birden çok PUB veya işin birlikte planlanması

Toplu yürütüm (batch), uzak ilkel çağrılarını tek bir planlama çerçevesinde bir araya getirme kararıdır: aynı gönderimde birden çok PUB, aynı toplu bağlamda arka arkaya planlanan çağrılar veya ürünün sunduğu “batch” soyutlamasıyla paketlenmiş işler. Amaç, kuyruk başına düşen klasik ön işleme ve bağlantı maliyetini amorti etmek ve deney hattını öngörülebilir kılmaktır; ⟨O⟩ veya bit dizesi matematiği yine Estimator ve Sampler sayfalarında kalır.

Bu sayfa toplu neden ve nasıl paketlenir sorularını işler; tek işin kimlik ve durum yüzeyi Runtime işleri, ardışık çağrıların bağlamda gruplanması oturum sistemi dosyalarında ayrıntılandırılır. Belirli bir REST uç noktası, kota tablosu veya SDK sınıf adı burada sabitlenmez; üretimde güncel IBM Quantum belgeleri ve kilitlenmiş sürüm aralığı esas alınmalıdır.

Orkestrasyon desenleri ilkel iş akışları ve klasik–kuantum döngü hibrit kuantum iş akışı başlıklarında kalır; burada yalnızca “hangi PUB’lar aynı pakette, hangi metriklerle izlenir?” sorusu ele alınır.

Ne vaat edilmez

Ücret, kota veya SLA taahhüdü verilmez; bunlar platforma ve hesap türüne göre değişir.

Toplunun “her zaman daha ucuz veya daha hızlı” olduğu varsayımı doğru değildir: paket boyutu, zaman aşımı ve hata oranı birlikte değerlendirilmelidir.

Tek iş, tek bir gönderimin kuyruk ve kimlik üzerinden izlenen örneğidir ( Runtime işleri). Oturum, aynı uzak bağlamda çağrıları gruplayarak klasik–kuantum etkileşimini sadeleştirir ( oturum sistemi). Toplu yürütüm ise “aynı anda veya aynı planlama penceresinde birden çok birimi birlikte düşünme” yaklaşımıdır: ya tek çağrıda çoklu PUB listesi ya da toplu kapsayıcı altında sıralanan çağrılar. Üç mod birbirini dışlamaz; ürün yüzeyine göre iç içe geçebilir.

Oturum “aynı bağlamda devam et” derken, toplu genelde “aynı gönderim maliyet eğrisinde grupla” der. Karışıklık, her ikisinin de wall-clock’u iyileştirebilmesinden kaynaklanır; fakat oturumun odak noktası durum taşıyan bağlam, toplunun odak noktası iş birimi sayısı ve paket sınırıdır.

IBM belgelerinde yürütme modları karşılaştırmalı anlatılır; bu sayfa o tabloyu kopyalamaz, yalnızca Qubyt içi sınır çizer: mod seçimi için platform belgelerine, iş yaşam döngüsü için Runtime işleri sayfasına yönlendirir.

İzlenebilirlik

Toplu paket adı, deney etiketi, kod sürümü ve veri kümesi parmak izi birlikte loglanmalıdır; aksi halde kısmi başarıda hangi alt kümenin geçerli olduğu bulunamaz.

Aynı PUB listesi bile farklı paketlerde yeniden gönderilebilir; idempotent anahtar ( parçalama ve zaman aşımı bölümü) olmadan “tekrar mı, yeni deneme mi?” ayrımı kaybolur.

Primitive V2 düşüncesinde PUB (primitive unified bloc), devre + gözlemlenebilir + parametre + seçeneklerin tek satırlık birimidir. Birden çok PUB’u aynı run(...) çağrısına vermek, istemci tarafında tek bir “toplu matematik paketi” oluşturur; sunucu bunu nasıl kuyruğa koyarsa koysun, sizin tasarım sorunuz “hangi PUB’lar atomik olarak birlikte başarısız olsun?” sorusuna indirgenir.

PUB içi shot ve gözlemlenebilir tasarımı shot mantığı ve gözlemlenebilir değerlendirme ile ilişkilidir; burada yalnızca listeleme ve sıra disiplinine odaklanılır: sonuç dizisi ile girdi dizisinin bire bir eşlenmesi, istemci kodunda test edilmelidir.

Çok büyük PUB listeleri bellek, serileştirme ve doğrulama süresini artırır; “hepsini tek seferde” yerine üst boyut ve alt paketlere bölmek ( parçalama ve zaman aşımı bölümü) operasyonel olarak daha güvenlidir.

Sıra ve deterministik okuma

Sonuç koleksiyonunda indeks, deney meta verisiyle birlikte saklanmalıdır; yalnızca sıraya güvenmek, ara sürümlerde ek alanlar eklendiğinde kırılganlık yaratır.

Parametre sweepleri gibi tekrarlı yapılar için, PUB üretimini saf fonksiyon halinde tutmak regresyonu kolaylaştırır.

Üretimde toplu paket üç sınırla kesilir: maksimum PUB sayısı, tek paket wall-clock üst sınırı ve yeniden deneme politikası. İlk ikisi platformdan gelir; üçüncüsü tamamen sizin kontrolünüzdedir. Paket boyutu büyüdükçe tek hatada “büyük kayıp” riski artar; küçük paketlerde ise kuyruk başına overhead baskın olabilir.

Zaman aşımı hem istemci hem sunucu tarafında tanımlı olabilir; hangi tarafın önce kestiği hata iletisi farklıdır. Toplu senaryoda tek bir yavaş PUB, tüm paketin algılanan süresini şişirebilir — bu yüzden “uzun kuyruk” ve “ağır PUB” ayrı kuyruklara veya farklı paketlere ayrılmalıdır.

Yeniden deneme (retry) için istemci tarafında deterministik bir idempotency anahtarı (örneğin deney kimliği + PUB karması + kod sürümü) tutulmalıdır; aksi halde ağ kesintisinde mükerrer yürütme üretilir. Runtime işleri sayfasındaki iş yaşam döngüsü ile birlikte okunmalıdır.

Eşzamanlılık ve geri basınç

Paralel paket gönderimi, kuyruk derinliği ve hız sınırıyla etkileşir; istemci tarafında sınırlayıcı (semaphore) olmadan patlama yapılmamalıdır.

Yerel prototipte kuyruk yoktur; bulutta ise aynı kod yolunun davranışı farklılaşır. Bu yüzden entegrasyon testleri küçük paketlerle başlamalıdır.

Toplu yürütümün ekonomik argümanı çoğu zaman sabit maliyetlerin paylaşılmasıdır: kimlik doğrulama, devre doğrulama, serileştirme ve ilk kuyruk yerleşimi. Bu kazanım, PUB başına shot sayısı düşükken görece daha belirgin olabilir; tersine, çok yüksek shot’lı az sayıda PUB’da baskın terim yürütme süresi olabilir.

Aynı toplu pencerede yürütülen PUB’lar, donanım kalibrasyonu ve sıcaklık açısından birbirine yakın koşullarda çalışabilir; bu, karşılaştırmalı deneylerde istenir veya istenmez. İstenmeyen durumda, paketleri zamana yaymak veya referans PUB eklemek gerekir; aksi halde “gürültü korelasyonu” yorum hatasına yol açar.

Kullanım ölçümü ve süre tahmini IBM belgelerinde anlatılır; bu sayfa yalnızca metrik toplama disiplinini hatırlatır: paket kimliği, gönderim zamanı, kuyruk bekleme süresi, yürütme süresi ve başarı oranı ayrı alanlarda tutulmalıdır.

Hata azaltma etkileşimi

Hata azaltma seçenekleri yürütme yolunu uzatabilir; toplu planlarken bu ek süreyi paket bütçesine dahil etmek gerekir. Hata azaltma ile birlikte okunmalıdır.

Ağ ve uç nokta seçimi Runtime yürütme sayfasında özetlenir.

Toplu paketlerde hata üç düzeyde okunur: tüm paket reddi (doğrulama veya kota), yürütme sırasında kesinti, sonuç ayrıştırma hatası. Ürün, PUB bazlı kısmi sonuç döndürebilir veya tüm paketi “başarısız” işaretleyebilir; bu ayrım entegrasyon testlerinde açıkça doğrulanmalıdır.

İptal çağrısı her zaman anında durdurma anlamına gelmez; kuyrukta bekleyen veya yarım kalan PUB’lar için gecikmeli durum gözlenebilir. Operasyon ekibi için “hangi alt küme tamamlandı?” sorusu, iş kimliğinden bağımsız olarak paket düzeyinde cevaplanabilmelidir.

Log şemasında batch_id (veya eşdeğeri), alt iş kimlikleri ve PUB indeksi birlikte bulunmalıdır; yalnızca iş kimliği ile arama yapmak, toplu iç içe yapılarda yetersiz kalır.

Yerel doğrulama

Küçük devrelerde önce StatevectorEstimator / StatevectorSampler ile beklenen sayısal referans, sonra bulutta küçük paketle kıyaslama regresyonu erken yakalar. Sadakat ölçütleri durum tabanlı senaryolarda yardımcı olabilir; ⟨O⟩ ile doğrudan özdeş değildir.

Sonuç önbelleği ve saklama politikası mimari bir karardır; bu sayfa veri hattını tasarlamaz.

Birinci kutu, IBM Qiskit Runtime’da Batch kapsayıcısı ile aynı toplu bağlamda birden çok ilkel çağrısı için yorum satırlı iskelet (hesap, token ve güncel qiskit-ibm-runtime belgeleri gerekir). İkinci ve üçüncü kutular, hesap gerektirmeden yerelde birden çok PUB’u tek run ile işleyerek dizin–sonuç eşlemesini pratik eder.

Sınıf ve import yolları sürüme göre değişebilir; etkinleştirmeden önce IBM Quantum belgelerini doğrulayın.

Bulut: Batch bağlamında ilkel çağrıları

Aşağıdaki satırlar bilinçli olarak yorumdadır.

# Örnek iskelet — hesap, token ve güncel qiskit-ibm-runtime belgeleri gerekir.
# from qiskit_ibm_runtime import QiskitRuntimeService, Batch, EstimatorV2 as Estimator
#
# service = QiskitRuntimeService()
# backend = service.backend("...")  # veya mode ile uyumlu backend seçimi
# pubs_a = [...]
# pubs_b = [...]
#
# with Batch(backend=backend) as batch:
#     estimator = Estimator(mode=batch)
#     job_a = estimator.run(pubs_a)
#     job_b = estimator.run(pubs_b)
#     print(job_a.job_id(), job_b.job_id())
#     ra, rb = job_a.result(), job_b.result()
# print(ra, rb)

Yerel: çoklu PUB ile Estimator

Aşağıdaki örnek, tek run çağrısında iki PUB döndürür; sonuç listesi ile girdi sırasını eşleştirmeyi alıştırır.

from qiskit import QuantumCircuit
from qiskit.quantum_info import SparsePauliOp
from qiskit.primitives import StatevectorEstimator

qc0 = QuantumCircuit(1)
qc0.h(0)
qc1 = QuantumCircuit(1)
qc1.x(0)

pubs = [
    (qc0, [SparsePauliOp("Z")]),
    (qc1, [SparsePauliOp("Z")]),
]
result = StatevectorEstimator().run(pubs).result()
for i, pub_result in enumerate(result):
    print(i, pub_result.data.evs.item())

Yerel: çoklu PUB ile Sampler

Aynı desen Sampler için de geçerlidir; bit dizesi dağılımı okumasını Sampler sayfasıyla hizalayın.

from qiskit import QuantumCircuit
from qiskit.primitives import StatevectorSampler

qc0 = QuantumCircuit(2)
qc0.h([0, 1])
qc0.measure_all()
qc1 = QuantumCircuit(2)
qc1.x(0)
qc1.measure_all()

pubs = [(qc0,), (qc1,)]
result = StatevectorSampler().run(pubs).result()
for i, pub_result in enumerate(result):
    print(i, pub_result.data.meas.get_counts())

Toplu yürütüm; PUB listesi veya toplu kapsayıcı ile yürütme birimlerini planlama kararıdır. Tek iş yaşam döngüsü Runtime işleri, bağlamda ardışıklık oturum sistemi, matematiksel çıktı Estimator ve Sampler ile tamamlanır.

Bu sayfa “hangi birimler aynı pakette, hangi metriklerle izlenir?” sorusunu yanıtlar; güncel SDK imzası ve kota IBM belgelerinde tutulur. Üretimde paket boyutu, zaman aşımı ve idempotency birlikte tasarlanmalıdır.

• Runtime işleri — kimlik, durum ve sonuç bekleme.
• Oturum sistemi — bağlamda ardışık çağrılar.
• İlkel iş akışları — orkestrasyon ve veri akışı.
• Runtime yürütme — ağ ve yürütme çerçevesi.
• IBM Quantum: Yürütme modu seçimi — tek iş, toplu ve oturum.
• IBM Quantum: İş yükü kullanımı ve süre — kullanım ölçümü.