Provider sistemi — hesap, katalog ve erişim sınırı

Soyut düzeyde bir provider, kullanıcı kodu ile yürütülebilir hedefler (backend'ler) arasındaki fabrikadır. Siz bir devre yazarsınız; provider size "hangi makineleri görebildiğinizi" listeler, seçtiğiniz hedefe bağlanmanız için gerekli oturum bilgisini taşır ve çoğu zaman run veya Runtime primitives çağrılarının arkasındaki HTTP/WebSocket trafiğini sizden gizler. Provider devre inşa etmez, transpile etmez ve algoritmanızın doğruluğunu garanti etmez; o işler sırasıyla devre modeli, optimizasyon ve sizin deney tasarımınızdadır.

Backend ile ayrım

Backend mimarisi sayfasında vurgulandığı gibi, BackendV2 bir sözleşmedir: qubit sayısı, native kapılar, coupling, kalibrasyon özeti. Provider ise o sözleşmelerin kaynağını yönetir: hangi backend adları mevcut, hangi planla görünür, hangi Runtime kanalından çağrılır. Aynı backend adı, farklı hesaplarda farklı kuyruk derinliği veya hiç listelenmeme hâlinde olabilir; bu yüzden "kodum çalışıyordu, arkadaşımda çalışmıyor" sorularının ilk cevabı çoğu zaman provider kapsamıdır, Qiskit sürümü değil.

Bu sayfanın sınırı

Kurumsal SSO, faturalandırma, organizasyon politikaları veya IBM Cloud IAM detayları burada işlenmez; bunlar ürün belgelerinin alanıdır. Burada amaç, Qiskit kullanıcısının zihninde sağlayıcı katmanını netleştirmek ve güvenli yerel örneklerle aynı desenleri öğretmektir.

IBM Quantum ekosisteminde modern yol, qiskit-ibm-runtime paketindeki QiskitRuntimeService üzerinden yürür. Bu sınıf, eski IBMQ / load_account akışlarının yerini almış veya onlarla bir süre bir arada yaşamış olabilir; sürüm notları her yükseltmede okunmalıdır. RuntimeService'in görevi kabaca üçlüdür: (1) kimlik doğrulamasını ve oturumu yönetmek, (2) erişilebilir backend listesini sunmak, (3) Sampler/Estimator gibi primitives ve oturum API'lerine giriş noktası sağlamak. Bu üç görevin hepsi "provider" başlığı altında toplanır çünkü kullanıcı açısından tek kapıdan geçilir.

Primitives ve provider ilişkisi

Runtime yürütmesi sayfasında primitives derinleştirilecek; burada yalnızca şu bağ kurulur: primitives çağrısı yapıldığında bile alt tarafta yine bir hedef backend ve bir oturum seçilir; bu seçim RuntimeService üzerinden akar. Dolayısıyla "Sampler'ı doğrudan backend'e bağladım" (Sampler(mode=backend)) ile "Session içinde buluttaki gerçek cihaza bağladım" aynı arayüz ailesidir fakat provider katmanı ikinci yolda zorunludur.

Sürüm ve paket ayrımı

qiskit çekirdeği, qiskit-aer ve qiskit-ibm-runtime farklı sürüm takvimlerine sahiptir. Provider hatalarını ayırt ederken önce hangi paketin stack trace'de göründüğüne bakın: Aer hatası ile RuntimeService hatası farklı kök nedenlere işaret eder.

IBM Quantum'a bağlanırken tipik yol, IBM hesabından üretilen bir API token'ının yerel diske (çoğu zaman qiskit-ibm.json veya ortam değişkeni) kaydedilmesidir. Güvenlik kuralı: token'ı asla kaynak koduna, Jupyter hücresine kalıcı olarak veya bu statik siteye yapıştırmayın. Eğitim materyallerinde token göstermek, hem hesabınızı riske atar hem de öğrenciye yanlış alışkanlık kazandırır. Doğru desen: bir kerelik save_account veya resmi CLI ile yapılandırma, ardından kodda yalnızca QiskitRuntimeService() gibi parametresiz fabrika çağrıları. Bu sayfadaki kodlar bilinçli olarak token içermez ve ağa çıkmaz.

Ortam değişkenleri ve CI

Sürekli entegrasyon ortamlarında token'ı gizli değişken olarak enjekte etmek yaygındır; fakat pipeline loglarına düşmemesi için dikkatli olun. Yerel makinede ise dosya izinlerini kısıtlamak (örneğin yalnızca kullanıcı okuyabilsin) iyi bir alışkanlıktır. Bu sayfa CI reçetesi vermez; yalnızca "provider güvenliği = kimlik bilgisini kod dışında tutma" ilkesini pekiştirir.

Bulut iskeleti (yorum)

# from qiskit_ibm_runtime import QiskitRuntimeService
# service = QiskitRuntimeService()  # ~/.qiskit/qiskit-ibm.json veya ortam değişkeni
# print([b.name for b in service.backends()])

Provider, size bir katalog sunar: her girdi bir backend adı, durum bayrakları (operational, pending maintenance), simülatör mü gerçek mi, qubit sayısı gibi özet alanlarla birlikte listelenebilir. Katalog API'sinin tam imzası sürüme göre değişir; kavramsal olarak aradığınız şey şudur: "hesabımın görebildiği tüm hedefler" ve bunların üzerinde filtre uygulama. Filtre, yalnızca isim eşleştirmesi değildir; çoğu zaman min_num_qubits, simulator, operational gibi anahtarlarla ifade edilir.

Meta veri ile backend nesnesi

Katalog satırı, tam bir BackendV2 örneği değil de özet olabilir; gerçek yürütme için genelde isimden backend çözülür veya doğrudan nesne alınır. Özet ile tam nesne arasındaki fark, performans ve UI tasarımında önemlidir: binlerce kullanıcıya katalog sayfası çizerken her satır için ağır bir backend örneği oluşturmak verimsizdir.

Katalogdan seçime köprü

"Hangi backend?" sorusunun algoritmik cevabı backend seçimi sayfasında genişletilir; provider sayfasında odak, kataloğun nereden geldiği ve kimin görebildiğidir.

Üretim kodunda "ilk sıradaki backend" veya "alfabetik en küçük ad" gibi sezgisel seçimler tehlikelidir: bakım penceresine denk gelebilir, kuyruk süresi uzayabilir veya simülatör yerine yanlışlıkla ücretli bir cihaz seçilebilir. Sağlıklı strateji: (1) açık filtreler (en az qubit, simülatör/gerçek ayrımı, operational), (2) kuyruk ve kalite metrikleri için ayrı bir gözlem katmanı, (3) seçilen backend adının loglanması. Provider bu stratejinin ilk adımına veri sağlar; gözlem ve maliyet kontrolü sizin operasyon katmanınızdadır.

least_busy ve alternatifleri

least_busy yardımcıları pratik görünür; fakat "düşük kuyruk" her zaman "en iyi bilimsel sonuç" anlamına gelmez. Ayrıca bulut çağrısı gerektirdiği için bu sayfanın kod laboratuvarında yer almaz — yalnızca kuyruk mantığı ve seçim sayfalarında birlikte düşünülmelidir.

IBM Quantum'da bir hesap bazen birden fazla instance (hub / group / project hiyerarşisi) ile ilişkilendirilir. Aynı token ile bile, hangi instance'ın aktif olduğu kataloğu değiştirir: bir projede gördüğünüz cihaz diğerinde listelenmeyebilir. Provider tarafında bu, "hangi kök düğümde geziyorum?" sorusuna denk gelir. Öğretim açısından kritik nokta: erişim reddi bazen kod hatası değil, yanlış instance veya süresi dolmuş plandır.

Organizasyon ve paylaşılan hesaplar

Laboratuvar veya ekip ortamında paylaşılan servis hesapları kullanılıyorsa, kimin hangi kota altında koştuğu belirsizleşebilir. Operasyonel disiplin: kişisel token ile dene, pipeline'da ayrı kimlik kullan, paylaşılan hesapta etiketleme ve loglama zorunlu kıl.

Yetkisiz erişim, süresi dolmuş token, yanlış instance, bakımdaki cihaz veya kota aşımı — hepsi üstte benzer bir istisna ile bitebilir. Ayırt etmek için: (1) stack trace'de qiskit_ibm_runtime mi qiskit çekirdeği mi görünüyor, (2) hata mesajında "unauthorized" / "forbidden" / "not found" geçiyor mu, (3) aynı kod Aer ile çalışıyor mu. Üçüncü soru evet ise, sorun büyük olasılıkla provider veya ağ katmanındadır, devre cebri doğrudur.

Yerel doğrulama önceliği

Bulutta teşhis yapmadan önce Aer ve fake backend ile aynı transpile + run hattını koşmak, zaman kazandırır.

Öğrenme ve birim test için IBM provider'ına ihtiyaç yoktur. İki güçlü yerel desen vardır: (1) AerSimulator ile doğrudan yürütme — katalog tek öğedir; (2) FakeManilaV2 gibi sahte donanımlar — gerçek bir cihazın target ve gürültü modelini taklit eder, böylece "provider bana şu backend'i verdi" akışını taklit eden ince bir sarmalayıcı yazılabilir. Bu sayfanın laboratuvarı ikinci deseni kullanır: küçük bir FakeCatalog sınıfı, gerçek QiskitRuntimeService.backends() API'sini taklit etmez ama aynı programlama düşüncesini öğretir.

Test çifteği: aynı devre, iki sahte hedef

İki farklı fake backend aynı transpile politikasını farklı kapı sayılarına iter; böylece "provider farklı hedef döndürdü" senaryusu yerelde yeniden üretilir. Detay backend mimarisi ve fake kullanımı ile birleşik okunmalıdır.

Üç blok da tamamen yereldir: ağ çağrısı yok, token yok, IBM hesabı yok. Birinci blok, sahte backend'leri bir sözlükte toplayan minimal bir "katalog" desenini gösterir. İkinci blok, aynı Bell devresini Aer ve fake üzerinde koşturarak provider hatasından ayırt etmeyi destekler. Üçüncü blok, küçük bir sarmalayıcı ile "isimden backend al" fabrikasını gösterir — gerçek RuntimeService çağrısının yerel karşılığıdır.

from qiskit_ibm_runtime.fake_provider import FakeManilaV2

class FakeCatalog:
    """Yerel öğretim: IBM kataloğunu taklit etmez, 'isim → fabrika' düşüncesini gösterir."""

    def __init__(self):
        self._registry = {
            "fake_manila": FakeManilaV2,
        }

    def list_names(self):
        return sorted(self._registry)

    def resolve(self, name: str):
        factory = self._registry.get(name)
        if factory is None:
            raise KeyError(f"Bilinmeyen backend: {name}")
        return factory()

cat = FakeCatalog()
for n in cat.list_names():
    b = cat.resolve(n)
    print(n, "→", b.name, "qubits=", b.num_qubits)

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 smoke(backend, label, shots=512):
    tqc = transpile(qc, backend=backend, optimization_level=2)
    counts = backend.run(tqc, shots=shots).result().get_counts()
    print(f"{label:>10} → {counts}")

smoke(AerSimulator(), "aer")
smoke(FakeManilaV2(), "fake")

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

def make_backend(name: str):
    if name == "fake_manila":
        return FakeManilaV2()
    raise ValueError(f"Bilinmeyen backend: {name} — kataloğu genişletin.")

backend = make_backend("fake_manila")

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

tqc = transpile(qc, backend=backend, optimization_level=2)
counts = backend.run(tqc, shots=1024).result().get_counts()
print(backend.name, "→", counts)

Provider sistemi, Qiskit'in bulut tarafındaki kapısıdır: kimlik, katalog, Runtime köprüsü. Yerelde Aer ve fake backend'lerle aynı programlama düşüncesini kurarak öğrenmek, bulut hatalarını hızlı ayırt etmenizi sağlar. Token'ı koda gömmeyin; seçilen backend adını ve instance'ı loglayın; filtreleri açık yazın.

• Backend mimarisi — sözleşme ve katmanlar.
• Backend seçimi — filtre ve strateji.
• Job sistemi — asenkron tutamak.
• Kuyruk mantığı — bekleme ve öncelik.
• Runtime yürütmesi ve oturum mantığı — primitives.
• Fake backend kullanımı — donanım taklidi.
• Aer simülatörü — yerel yürütme.