Backend mimarisi — soyut çekirdek, sürücüler ve hizmet katmanı

Qiskit'te bir devrenin "çalıştırılması" tek bir adım gibi görünür, oysa arka planda dört katmanlı bir akış işler: kullanıcı kodu bir QuantumCircuit üretir, transpiler bu devreyi hedefin native kapı seti ve coupling map'ine uydurur, backend donanımı (veya simülatörü) temsil eden sözleşmedir ve devreyi kabul edip job nesnesi döndürür, job sonunda result taşır. Mimari açısından kritik nokta, bu katmanların birbirini ne biliyor olduğudur: transpile için backend'in özelliklerine ihtiyaç vardır; job ise sonuç için backend'in asenkron arayüzüne. İki bilginin ayrı uçlarda durması Qiskit'in donanım-bağımsız kalmasını mümkün kılar.

Bu sayfanın sınırı

Burada aday seçimi, kalibrasyon parsing'i veya kuyruk politikaları kod düzeyinde derinleştirilmez; o detaylar kardeş sayfalara bırakılır. Amaç, "bir backend nedir, ne söz verir, ne söz vermez?" sorusuna mimari bir cevap vermektir. Sayfayı okurken aklınızda şu eksen bulunsun: Provider bir fabrikadır, Backend bir sözleşmedir, Job bir tutamaktır, Result ise okumadır.

Devre tarafının kendisi devre yapısı ve devre optimizasyonu sayfalarında işlendi; backend katmanı, oradaki optimizasyon kararlarının hangi hedefe göre alınacağını belirleyen taraftır.

Modern Qiskit'te tüm yürütme hedefleri ortak bir soyut sınıfı, BackendV2, miras alır. Bu sınıf "hangi sorulara cevap vermek zorunda olduğunu" belirler: kaç qubit'im var, hangi kapıları doğal olarak yapabilirim, hangi qubit çiftleri etkileşebilir, kapı süreleri ve hata oranları ne, hangi ölçüm tiplerini destekliyorum, devreyi nasıl koşacağım? Eski BackendV1 arayüzü farklı bir nesne ailesi (configuration/properties/defaults) üzerinden aynı bilgiyi sağlardı; V2, bunları tek bir Target nesnesinde topladığı için transpiler kuralları çok daha doğrudan yazılabilir hâle geldi.

Target nesnesi

Target bir backend'in "kapı sözlüğü"dür: hangi kapı, hangi qubit(ler) üzerinde, ne kadar sürede, ne kadar hata payıyla çalışır? Bu sözlük, transpiler'ın seçim ve yerleştirme kararlarının arka planıdır. Aynı devre, hedef backend'in target'ı değiştiğinde farklı bir kapı dizisine düşer; bu nedenle "devreyi optimize ettim" cümlesi, "hangi target için?" sorusuyla anlam kazanır.

Sürüm farklarına karşı disiplin

V1'den V2'ye geçişte bazı niteliklerin yeri ve adı değişti. Üretimde her sürüm yükseltmesi sonrası bu sayfalardaki örnek imzaları resmi belgeyle doğrulamak gerekir; amaç soyut sözleşmeyi anlamak, imzayı ezberlemek değildir.

Bir backend'i nasıl elde edersiniz? Doğrudan elle inşa etmek yerine, bir Provider (veya Service) nesnesi sorgulanır; bu nesne erişim yetkileri, organizasyon/proje ayrımı ve cihaz kataloğunu sarmalar. IBM Quantum tarafında bu rol QiskitRuntimeService üzerinden yürür; yerel Aer için ise basit fabrikalar yeterlidir. Provider örüntüsü, "backend nereden geliyor?" sorusunun cevabını tek bir yere taşır — kimlik doğrulama, URL ve hesap bilgileri gibi çevresel parametreler bu katmanda toplanır.

Filtreleme ve katalog

Provider, kullanıcıya bir katalog API'si sunar: belirli özelliklere (qubit sayısı, simülatör/gerçek ayrımı, anlık erişilebilirlik) göre filtreleme yapılabilir. Bu filtrelerin uygulanması ve "doğru cihazı seçme" akıl yürütmesi backend seçimi sayfasında derinleştirilir; provider'ın nasıl kurulduğu ve oturum açma akışı ise provider sistemi başlığına aittir.

Hesap ve yetki sınırı

Provider'ın eriştiği cihazlar, hesabın planı ve organizasyonun yetkileri ile çerçevelidir. Bu sayfada gizli anahtar yapılandırması veya CLI/kayıt akışları işlenmez; o adımlar resmi belgenin sorumluluğundadır.

Her donanımın doğrudan uygulayabildiği kapılar sınırlıdır; süperiletken cihazlarda tipik olarak tek-qubit için sx, x, rz ve iki-qubit için cx ya da ecr görülür. Aynı şekilde, hangi qubit çiftlerinin iki-qubit kapısı yapabileceği coupling map ile sabitlenir; eksik kenarlar için SWAP zinciri gerekir. Transpiler bu iki bilgiyi target üzerinden alır; "neden devre büyüdü?" sorusunun çoğu zaman ilk cevabı buradadır.

Topoloji düşüncesi

Birbirine yakın olmayan iki qubit arasında iki-qubit kapısı isteniyorsa, transpiler SWAP'larla "qubit'leri yan yana getirir". Bu hareket hem kapı sayısını hem hata bütçesini artırır; dolayısıyla algoritma tasarlanırken donanım topolojisi göz ardı edilemeyecek bir bağlamdır. Topoloji ve coupling tartışması coupling map sayfasında, donanım tarafındaki fiziksel arka plan ise bağlanırlık ve topoloji sayfasında genişletilir.

Hedef tabanlı transpile

Target nesnesi, native set ile coupling map'i tek bir yerde tutar; bu sayede devre ayrıştırma ve devre optimizasyonu aşamaları aynı kaynağa danışarak tutarlı çalışır. Aynı devreyi farklı target'larda transpile etmek, doğal olarak farklı kapı dizileri üretir; karşılaştırma yaparken bu nokta açıkça yazılmalıdır.

Backend yalnızca topolojiyi taşımaz; aynı zamanda canlı kalibrasyon verisini de raporlar: kapı süreleri, kapı hata oranları, qubit T1/T2 değerleri, okuma hatası tahminleri. Bu sayılar gün içinde değişebilir — donanım yeniden ayarlanır, sıcaklık kayar, kalibrasyon turu işler. Bu nedenle "dün koştuğum aynı transpile çıktısı, bugün de optimal mi?" sorusunun cevabı çoğu zaman hayır'dır: target değişmiştir.

Properties ve Defaults

V1 mimarisinde bu bilgiler ayrı nesneler (properties, defaults) olarak durur; V2'de target'a yerleşir. İçerik aynı sınıftan: hangi kapının hangi qubit'te ne kadar güvenilir? Bu bilginin pratik kullanımı —en az hatalı yolu seçme, transpile seed'i ile karşılaştırma— ayrı sayfalarda işlenir: backend özellikleri ve kalibrasyon verisi.

Gürültü modeli ile köprü

Kalibrasyon raporu, simülasyon tarafında bir gürültü modeli kurmak için de kullanılabilir; aynı backend'in FakeBackend sürümleri tam olarak bunu yapar. Bu köprü gürültü simülasyonu ve fake backend kullanımı sayfalarında derinleştirilir.

backend.run(...) çağrısı yapıldığında, devre hedefe gönderilir ve geriye senkron bir sonuç yerine bir job tutamağı döner. Job; "henüz beklemede", "kuyrukta", "çalışıyor", "tamamlandı", "iptal", "hata" gibi durumlar arasında geçer. Sonunda job.result() çağrısı bir Result nesnesi üretir; örneğin shot sayımları, durum vektörü snapshot'ı veya gürültülü bir tomografi çıktısı bu nesneden okunur.

Asenkron disiplin

Gerçek donanımda iş kuyruğa girer; sonuç gelmeden önce dakikalar ya da saatler geçebilir. Bu yüzden uygulama kodu çoğu zaman polling ya da callback yapısı kurar; doğrudan .result()'a kilitlenmek, uzun süreli kullanım için sağlıklı değildir. Asenkron iş yönetimi job sistemi ve kuyruk mantığı sayfalarında işlenir.

Result kabı: ortak şekil

Result'un içeriği backend tipine göre farklılaşsa da kabuk benzerdir: birden fazla devre için liste, her birinde shot sayımları veya simülatöre özel snapshot'lar. Okuma tarafının ayrıntıları qasm simülasyonu ve save_statevector talimatı gibi sayfalarda gösterildi.

Aynı backend.run(...) arayüzü; gerçek bir IBM cihazına da, Aer simülatörüne de, gerçek cihazın topoloji ve gürültü modelini taklit eden bir FakeBackend'e de uygulanır. Bu sözleşme paylaşımı, "kodu değiştirmeden hedef değiştirebilme" disiplinini mümkün kılar — geliştirme döngüsü hızlanır, yeniden üretilebilir deneyler kurulabilir.

Aer simülatörü

Aer, devreyi yerel olarak çalıştırır ve farklı yöntem ailelerini destekler (durum vektörü, yoğunluk matrisi, stabilizer vb.). Yöntem ve sınırlar Aer simülatörü sayfasında ele alındı.

Fake backend

Fake backend'ler, gerçek bir cihazın target'ını taklit eden simülatörlerdir; gerçek donanıma erişiminiz olmasa bile transpile çıktısının nasıl davranacağını ve gürültü altında nasıl bozulacağını test edebilirsiniz. Ayrıntı fake backend kullanımı sayfasında genişletilir.

Modern IBM Quantum tarafında backend.run(...) yerine Runtime hizmeti üzerinden çalışan ardışık primitives (Sampler, Estimator) önerilir. Runtime; tek tek devre koşmak yerine, hedefe yakın bir ortamda paketlenmiş, yeniden kullanılabilir, hata azaltma adımlarıyla zenginleştirilebilen bir yürütme katmanıdır. Bu yaklaşım, çoklu devre senaryolarında ağ gecikmesini ve kuyruğa tekrar girme maliyetini düşürür.

Session: bağlı yürütmeler

Bir session, birbirini takip eden işleri aynı oturum içinde tutar; ağ gecikmesi ve kuyruğa tekrar girme maliyeti düşer. Varyasyonel algoritmalar (VQE/QAOA) gibi yoğun iterasyon yapan akışlarda session, "her iterasyon kuyruğa baştan girmesin" disiplinidir. Ayrıntı oturum mantığı sayfasında.

Kuyruk ve önceliklendirme

Gerçek cihazlarda iş, bir kuyrukta bekler; öncelik, plan ve cihaz politikalarına göre değişir. Geliştirici tarafından bu, "ne zaman gönderelim, ne zaman polling yapalım?" kararını şekillendirir. Genel kuyruk modeli kuyruk mantığı sayfasında işlenir; Runtime'ın kendisi runtime yürütmesi sayfasında ele alınır.

Aşağıdaki bloklar mimari sözleşmenin somut yüzüne kısa pencereler açar: bir backend nesnesinden hangi bilgileri okuyabiliriz, aynı devre farklı hedefler arasında nasıl yer değiştirir, Runtime tarafında Sampler arayüzü yerelde nasıl çağrılır ve gerçek donanıma çıkış iskeleti nasıl görünür? Üç örnek de hesap/token gerektirmeden çalışacak şekilde yerel kurulmuştur; gerçek bulut yürütmesi için yapı yorum hattında korunur. Sürümünüze göre import yolları farklılaşabilir; resmi belgeyi referans alın.

from qiskit_ibm_runtime.fake_provider import FakeManilaV2

backend = FakeManilaV2()
target = backend.target

print("Backend adı:", backend.name)
print("Qubit sayısı:", backend.num_qubits)
print("Native kapı seti:", sorted(target.operation_names))
print("Coupling map:", list(backend.coupling_map.get_edges()))
print("Örnek cx süresi (qubit 0-1):", target["cx"][(0, 1)].duration)

from qiskit import QuantumCircuit, transpile
from qiskit_aer import AerSimulator
from qiskit_ibm_runtime.fake_provider import FakeManilaV2

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

def run_on(backend, label, shots=1024):
    tqc = transpile(qc, backend=backend, optimization_level=2)
    job = backend.run(tqc, shots=shots)
    counts = job.result().get_counts()
    print(f"{label:>14} → {counts}")

run_on(AerSimulator(), "aer (ideal)")
run_on(FakeManilaV2(), "fake manila")

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

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

# Yerel ve hesap gerektirmeyen Sampler: FakeBackend'i mod olarak
# veriyoruz; aynı `Sampler` arayüzü gerçek donanım için de geçerlidir.
# Gerçek donanım iskeleti (sadece referans):
#
#   from qiskit_ibm_runtime import QiskitRuntimeService, Session
#   service = QiskitRuntimeService()                  # IBM hesabı + token gerekir
#   real    = service.least_busy(simulator=False)     # kuyruğa girer
#   with Session(backend=real) as session:
#       sampler = Sampler(session=session)
#       job = sampler.run([qc], shots=2048)
#
backend = FakeManilaV2()
sampler = Sampler(mode=backend)
job = sampler.run([qc], shots=2048)
result = job.result()
print(result[0].data.meas.get_counts())

Backend mimarisi, Qiskit'in donanım-bağımsızlığını taşıyan ana omurgadır. Aynı sözleşme sayesinde simülatör, gerçek donanım ve sahte donanım arasında kod değişmeden yer değiştirilebilir; bu disiplin geliştirme, doğrulama ve raporlama döngülerinin tamamına sirayet eder.

• Backend seçimi — provider kataloğundan aday süzme.
• Provider sistemi — hesap, yetki ve hizmet katmanı.
• Coupling map — topoloji ve native kapı seti.
• Backend özellikleri ve kalibrasyon verisi — canlı bilgi okuma.
• Job sistemi ve kuyruk mantığı — asenkron yürütme disiplini.
• Runtime yürütmesi ve oturum mantığı — primitives ve oturumlu paketleme.
• Fake backend kullanımı — topoloji + gürültü modeliyle gerçek donanım taklidi.