Backend özellikleri — cihazın kendisini tarif eden canlı sözlüğü

Bir backend özelliği; cihazın topolojisi ile davranış kalitesi'ni birlikte tarif eden ölçülebilir alanlar kümesidir. Topoloji tarafında "kaç qubit'im var, hangileri komşu, hangi kapıları doğrudan yapabilirim?" sorularına yanıt veririz; davranış kalitesi tarafında ise "her kapı ne kadar sürer, ne kadar hata yapar, ölçüm ne kadar güvenilir, qubit'in coherence'i ne durumda?" sorularına. Bu iki katmanın birleşimi, transpiler için bir "yön levhası", algoritma yazarı için "beklenti çerçevesi" oluşturur.

Neden tek bir nesnede?

Geleneksel kütüphanelerde bu alanlar farklı sınıflara dağılmıştı; Qiskit'in V2 mimarisinde tek bir Target nesnesi etrafında toplanır. Bu birleşim, transpiler kararları için "hepsi aynı kaynaktan akar" disiplinini sağlar. Backend mimarisi sayfasında çizdiğimiz "sözleşme = Target" cümlesinin somut yüzü budur.

Bu sayfanın sınırı

Qubyt Core bir backend operasyon ya da cihaz kıyaslama sitesi değildir. Bu sayfa, "özelliklerin alanları ve okuma mantığı" üzerine kuruludur; herhangi bir cihaza özel "şu cihaz şu kadar iyi" tablosu üretmeyiz. Bu, hem güncel kalmak hem okuyucuyu doğru kaynağa (resmi belge) yönlendirmek için bilinçli bir tercihtir.

Tarihsel olarak Qiskit, cihaz bilgisini üç ayrı nesnede tutardı: configuration (donanım yapısı), properties (gün içi ölçülen hata ve süre değerleri) ve defaults (puls/komut varsayılanları). V1 backend arayüzü bu üçünü ayrı yöntemlerle açıyordu. Modern BackendV2 ise tüm bu bilgiyi Target adlı bir nesnede topladı; "hangi kapı, hangi qubit'lerde, ne kadar sürede, ne kadar hatayla çalışır?" sorularının cevabı tek bir kaynak hâline geldi. Bu birleşim, transpiler kuralının yazımını kısalttığı gibi okuyucunun zihnindeki haritayı da netleştirir.

Sürüm dikkati

Bazı eski kod örneklerinde backend.properties().gate_error("cx", [0, 1]) gibi V1 çağrılarını görürsünüz; bunlar hâlâ çalışabilir ama V2 hattı yerine kullanmak kodun gelecek sürümlerle hizalanmasını zorlaştırır. Yeni yazılan içerikte target üzerinden okuma — target["cx"][(0, 1)].error — tercih edilir.

Aynı bilgi, farklı arayüz

Hangi sürümü kullanıyor olursanız olun, anlatılan kavram aynıdır: cihazın bir haritası ve bu harita üzerine her kapı için "süre + hata" etiketi iliştirildiği bir tablodur.

Topoloji üç sayfadan oluşur: (a) qubit sayısı ve hangi indekslerin kullanılabilir olduğu; (b) native kapı seti — donanımın doğrudan uygulayabildiği temel kapılar (örneğin süperiletken cihazlarda sx, x, rz ve iki-qubit için cx ya da ecr); (c) coupling map — iki-qubit etkileşiminin hangi yönlü kenarlar üzerinde mümkün olduğu. Transpiler, devreyi bu üç sayfaya uydurmak için yer değiştirme (SWAP) ve ayrıştırma adımlarını birlikte planlar.

Yön ve simetri

Bazı kapılar yönlüdür: (0, 1) ile (1, 0) aynı qubit çifti olsa da farklı kalibrasyon taşıyabilir, hatta yalnızca tek yön desteklenebilir. Bu nedenle "qubit 0 ve 1 yan yana" ile "cx(0, 1) ucuz" cümleleri her zaman birbirinin yerini tutmaz.

Topoloji ve coupling ile birleşik okuma

Native set + coupling, devre tasarımı sırasında "kaç SWAP ekleneceğini" şekillendirir. Konunun fiziksel arka planı bağlanırlık ve topoloji sayfasında, transpile tarafındaki etkileri ise coupling map sayfasında işlenir.

Her native kapı, donanım üzerinde belirli bir süre alır. Tek-qubit kapıları tipik olarak onlarca nanosaniye, iki-qubit kapıları yüzlerce nanosaniye düzeyindedir ama bu değerler donanıma, mimariye ve gün içindeki kalibrasyona göre değişir. Süre bilgisi "kaç qubit operasyonu yaparım?" sorusunu "bu operasyon coherence penceremde sığar mı?" sorusuna çevirir.

dt birimi

dt, donanımın puls düzeyindeki zaman örnekleme aralığıdır (typically ~0.22 ns). Süre raporları ya saniye/nanosaniye olarak ham gelir ya da dt birimleri üzerinden ifade edilir. Karşılaştırma yaparken birimin doğruluğunu yazılı tutmak gerekir; "120 dt" ile "27 ns" aynı bilginin farklı yüzleridir ama yan yana yazıldığında karıştırılabilir.

Zamanlama ve scheduling

Süre bilgisi, devrenin scheduling aşamasında somut bir zaman çizgisine yerleşmesini sağlar. Bu sayede "iki-qubit kapısı sırasında 1. qubit ne yapıyor?" sorusu yanıtlanabilir ve dynamical decoupling gibi adımlar planlanabilir.

Hata raporları üç ailede ayrılır. Kapı hatası — tek-qubit ve iki-qubit kapıları için ortalama hata oranları (örn. 10^-3–10^-2). Okuma hatası — bir qubit'in 0 ya da 1 olarak okunma güvenilirliği; her qubit için ayrı raporlanır. Coherence süreleri — T1 (relaksasyon) ve T2 (dephasing); kapı süreleriyle birlikte "kaç kapı sığar?" sorusunu yanıtlar. Bu üç ailenin birlikte okunması, donanımın kalitesini tek bir cümleye indirgenmeden raporlamayı mümkün kılar.

Ortalama vs en kötü

"Bu cihazın kapı hatası X" cümlesi tipik olarak ortalamayı ifade eder; en kötü qubit çiftinin değeri belirgin biçimde daha kötü olabilir. Algoritma tasarımında "ortalama" değil "kullandığım yolun" hatası önemlidir; transpiler seçimleri bunu doğrudan değiştirir.

Hatadan kalibrasyona bağ

Hata sayıları sabit değildir; gün içinde değişir, bakım sonrası iyileşir, sürüklenirken kötüleşir. Bu yüzden "geçen ay 0.005 idi" cümlesi bugünün kararı için sınırlı bir destektir; karar günüyle aynı oturumda alınmış kalibrasyon değeri tercih edilir. Detay kalibrasyon verisi sayfasındadır.

Backend özellikleri canlıdır: cihaz yeniden kalibre edildiğinde sayılar değişir. Bu yüzden, raporlamada sayının kendisi kadar okuma zamanı da önemlidir. "X cihazında cx hatası 1.2 × 10⁻²" cümlesi, "14 Mayıs 03:15 itibarıyla X cihazında qubit (0,1) için cx hatası 1.2 × 10⁻²" hâline geldiğinde bilimsel olarak okunabilir. Bu disiplin, ders ile üretim arasındaki temel farklardan biridir.

FakeBackend ile statik fotoğraf

FakeBackend nesneleri, gerçek cihazın belirli bir andaki özelliklerinin donmuş bir kopyasını taşır. Bu nedenle FakeBackend'i okumak, kavramı öğrenmek için iyidir; gerçek cihazın bugünkü durumunu yansıtmaz.

Sürüklenme ve tekrar üretilebilirlik

Aynı algoritmanın aynı backend'de iki farklı günde farklı sonuçlar üretmesi, çoğunlukla algoritma hatası değildir; "özellikler değişti" cümlesinin somut sonucudur. Bilimsel rapor, mümkünse ölçüm sonuçlarıyla beraber o günün özellik özetini taşır.

Bir deneyi makale ya da iç rapor hâline getirirken backend özellikleri başlığı altında tutulması iyi olan alanlar: cihaz adı, sürüm/firmware, qubit ataması, kullanılan kapı seti, qubit başına T1/T2 ve okuma hatası, kullanılan qubit çiftlerinin iki-qubit kapı hataları, kalibrasyonun zaman damgası, transpile için seçilen optimization_level ve seed. Bu liste ezbere değil, "üç ay sonra okuyan biri ne arar?" sorusunun cevabıdır.

Karar yardımı

Bu özellikleri okumak, "iki cihazdan hangisini seçeyim?" sorusunu bilimsel zemine taşır. Karşılaştırma yaparken yalnızca qubit sayısı değil, kullanacağınız belirli qubit yolunun hata bütçesi de incelenir. Bu disiplinin algoritmik tarafı backend seçimi sayfasında.

"En iyi" hangi anlamda?

"En iyi backend" bağlama bağlıdır: az qubit gerektiren ve yüksek doğruluk arayan bir algoritma için tek-qubit kapı hatası baskın etmen olur; çok qubit ve uzun devre için T1/T2 ve transpile sonrası SWAP sayısı öne çıkar. Tek bir metriğe sığdırmak yerine "benim algoritmamın bütçesi nedir?" sorusuyla başlamak gerekir.

Backend özelliklerini öğrenmek için canlı IBM bağlantısına ihtiyaç yoktur. FakeBackend nesneleri gerçek cihazların donmuş kopyalarını içerir; aynı API ile ad, qubit sayısı, native kapı seti, coupling map, kapı süresi ve hata oranlarını okuyabilirsiniz. Bu yöntem; öğretim, otomatik test ve sürüm uyumluluğu için son derece elverişlidir. Yerel okuma alıştırması, kavramı tek bir cümleye indirgemenin değil, alanlar arasında "hangi soruya hangi alan cevap verir?" haritasını çıkarmanın yoludur.

Karşılaştırmalı okuma

Aynı kodla iki farklı FakeBackend'i okutmak; topoloji ve hata profilinin nasıl değiştiğini somutlaştırır. "Aynı algoritma, farklı target" düşünce egzersizinin zeminidir.

Ürün değil model

Yerelde okuduğunuz değerler, sahte modelin gönderi anındaki sayılarıdır. Gerçek bir cihazın bugünkü kararı için bunlar bağlayıcı değildir; ancak kavramsal okuma için zenginleştirilmiş bir oyun alanıdır.

Üç blok da tamamen yereldir: ağ yok, IBM hesabı yok. Birinci blok BackendV2 üzerinden temel alanların okumasını gösterir; ikinci blok bir kapı için süre ve hata özetini çıkartır; üçüncü blok iki farklı FakeBackend'i yan yana okuyarak topoloji ve kalite farklarının karşılaştırmasını yapar. Bulut karşılığı yalnızca yorum hattında durur.

# from qiskit_ibm_runtime import QiskitRuntimeService
# service = QiskitRuntimeService()
# backend = service.backend("ibm_brisbane")     # canlı target çekilir
# target  = backend.target
# print(sorted(target.operation_names))
# print("cx(0,1) error :", target["cx"][(0, 1)].error)
# print("cx(0,1) duration:", target["cx"][(0, 1)].duration)

from qiskit_ibm_runtime.fake_provider import FakeManilaV2

backend = FakeManilaV2()
target  = backend.target

print("name           :", backend.name)
print("num_qubits     :", backend.num_qubits)
print("operations     :", sorted(target.operation_names))
print("coupling edges :", list(backend.coupling_map.get_edges())[:6], "...")
print("dt (sn)        :", getattr(backend, "dt", "yok"))

from qiskit_ibm_runtime.fake_provider import FakeManilaV2

backend = FakeManilaV2()
target  = backend.target

def summarize_gate(name):
    if name not in target.operation_names:
        print(f"{name:>5} : bu cihazda native değil")
        return
    rows = target[name]                    # {qargs_tuple: InstructionProperties}
    print(f"\n{name} → {len(rows)} kayıt")
    for qargs, props in list(rows.items())[:4]:
        dur = props.duration if props and props.duration is not None else None
        err = props.error    if props and props.error    is not None else None
        dur_s = f"{dur*1e9:7.1f} ns" if dur is not None else "    -   "
        err_s = f"{err:.2e}"          if err is not None else "    -   "
        print(f"  qargs={qargs}  duration={dur_s}  error={err_s}")

for g in ("sx", "rz", "x", "cx"):
    summarize_gate(g)

from qiskit_ibm_runtime.fake_provider import FakeManilaV2, FakeBelemV2

def avg_cx_error(backend):
    rows = backend.target.get("cx", {}) or {}
    errs = [p.error for p in rows.values() if p and p.error is not None]
    return sum(errs) / len(errs) if errs else float("nan")

def native_set(backend):
    return tuple(sorted(backend.target.operation_names))

for cls in (FakeManilaV2, FakeBelemV2):
    b = cls()
    print(f"{b.name:>14}  qubits={b.num_qubits}  "
          f"avg_cx_err≈{avg_cx_error(b):.3e}  "
          f"native={native_set(b)}")

Backend özellikleri, cihazın hem haritası hem termometresidir. Topoloji "ne yapabilirim?" diyor, kalibrasyon "ne kadar iyi yapıyorum?". Her sayı tek başına yargı taşımaz; yanına zaman damgası ve qubit yolu eklenince yargıya yaklaşır. Yerelde FakeBackend ile aynı arayüzü okuyarak okuma disiplini kazanmak, kavramı statik bir tablo yerine düşünce alıştırması yapar.

• Backend mimarisi — Target sözleşmesinin yeri.
• Coupling map — topoloji derinleştirmesi.
• Kalibrasyon verisi — canlı sayıların disiplini.
• Backend seçimi — özelliklerden karara.
• Fake backend kullanımı ve Aer simülatörü — yerel okuma ve test.
• Soğutma ve kalibrasyon — fiziksel arka plan.