Cihaz sistemi — yürütüm bağlamı, örneklem ve türev uyumu

dev = qml.device("default.qubit", wires=n) satırı, sonraki tüm QNode çağrılarının paylaştığı yürütüm sözleşmesini kurar: kaç kablo var, hangi yürütücü ailesi kullanılacak, varsayılan örnekleme davranışı ne. QNode dekoratörü bu nesneyi kapanışa alır; kuantum fonksiyonu gövdesi aynı kalsa bile farklı bir dev ile sarıldığında farklı bir fiziksel veya sayısal model çalıştırılmış olur. Hibrit ML’de cihaz seçimi, model mimarisinin bir parçasıdır — “sonradan deploy” ayrıntısı değil.

QNode mimarisi ile ayrım

QNode’un çağrılabilir sınırı ve dönüş sözleşmesi QNode mimarisi sayfasında anlatılır; kablo envanteri ve indeks disiplini kablo yönetimi başlığındadır. Burada odak, cihaz nesnesinin eğitim döngüsüne hangi varsayımları taşıdığıdır.

Hibrit modellerde cihaz seçimi, “hangi fizik gerçeğinde eğitiyorum?” sorusunun cevabıdır. Prototipte çoğu ekip default.qubit benzeri tam vektör simülatörlerle başlar: beklenen değerler analitik veya çok yüksek doğrulukla hesaplanır, maliyet yüzeyi gürültüsüz okunur ve diff_method="backprop" Torch/JAX grafiklerine doğal oturur. Bu aşamada amaç donanımı taklit etmek değil; ansatz derinliği, maliyet tanımı ve optimizasyonun yönünü görmektir.

Analitik sim ve örneklemeli sim: iki rejim

Aynı simülatör ailesinde bile iki farklı “eğitim havası” vardır. Analitik (shots yok) rejimde her QNode çağrısı deterministik bir skalar döndürür; öğrenme eğrisi pürüzsüzdür. Örneklemeli sim (shots=N) ise donanımı henüz kullanmadan örnek gürültüsünü prova etmenizi sağlar — özellikle ölçüm tabanlı maliyetlerde faydalıdır. İkisini karıştırmak yaygın bir kaynaktır: analitik simde mükemmel görünen mimari, shots açıldığında dağılabilir. Bu yüzden mimari aramayı analitikte, “gerçekçi ölçüm” testini ise kontrollü shot sayılarıyla yapmak dengeli bir yoldur.

İki aşamalı çalışma alışkanlığı

Tipik boru hattı iki kapıdır: (1) simülatörde hızlı epoch ve hiperparametre taraması; (2) aynı QNode gövdesiyle shots veya gürültü açık cihazda ince ayar veya doğrulama. Klasik ML’deki “eğitim GPU’da, doğrulama ayrı veride” ritmine benzer; fark, kuantum maliyetinin her adımda bir fiziksel veya istatistiksel okuma üretmesidir. İkinci aşamada öğrenme oranını düşürmek, shot artırmak veya ansatz’ı sığlaştırmak genelde gerekir — aksi halde birinci aşamadaki agresif adımlar gürültüye çarpar.

“İdeal kuantum katman” varsayımı, varyasyonel devrenin yapısal olarak işe yarayıp yaramadığını ayıklar; robustluk testi ise bu yapının ölçüm ve gürültü altında ayakta kalıp kalmadığını sorar. İkinci soruyu atlamak, sim’de iyi eğitilmiş bir modelin donanımda çökmesine yol açar — bu, simden donanıma geçişte beklenen sürprizlerden biridir (ayrıntı §7’de özetlenir).

shots, cihaz düzeyinde “bu maliyeti kaç ölçümle tahmin ediyorum?” sorusunun cevabıdır. Analitik rejimde maliyet yüzeyi düzgündür; sonlu shots ile her epoch’ta farklı bir tahmin görürsünüz — gradyan da buna göre titreşir. Varyasyonel eğitimde risk şudur: optimizasyon, gerçek eğimi değil örnek gürültüsünü takip ediyor gibi görünür. Ölçümün matematik modeli ve expval / probs ayrımı ölçüm süreci sayfasında; burada yalnızca shots’un eğitim dinamiğine etkisi ele alınır.

Varyans, öğrenme oranı ve “sahte iyileşme”

Düşük shot, yüksek varyans: maliyet grafiği zıplar, erken durdurma yanlış epoch’ta tetiklenebilir. Yüksek shot, düşük varyans; fakat epoch süresi uzar. Öğrenme oranını shot ile birlikte ayarlamak gerekir — düşük shot’ta büyük adımlar genelde kötü fikirdir. Pratikte bir “shot programı” kullanılabilir: mimari aramada 100–500 shot, son doğrulamada 10⁴ ve üzeri; donanımda bütçe tavanına göre sabitlenir. Aynı shot ile hem eğitim hem doğrulama yapıyorsanız, doğrulama setinde daha yüksek shot ile tekrar ölçmek yanıltıcı iyileşmeleri ayıklar.

Maliyet–örnek sayısı takası

Her ek shot, varyansı düşürür; fakat QNode başına maliyeti artırır. Uzaktan cihazlarda bu doğrudan kuyruk süresine yazılır. Simülatörde ise önce düşük shot ile “yön doğru mu?” sorusunu yanıtlayıp, mimari oturduktan sonra shot artırmak zaman kazandırır. Shot artırırken diff_method’u da gözden geçirin — örnekleme açıkken backprop her zaman geçerli değildir (§5).

Gürültü, eğitimde “yanlış gradyan yönü”nden farklı bir sorundur: maliyet yüzeyinin kendisi değişir. Gürültülü simülatörler ve donanım köprüleri, kanal modelleriyle ideal ünite evrimini bozar; aynı θ ideal simde iyi, gürültülü cihazda kötü görünebilir. PennyLane çoğu zaman gürültüyü cihaz yapılandırması veya eklenti katmanı üzerinden sunar — burada Kraus matrislerini türetmek değil, optimizasyon döngüsüne nasıl yansıtacağınız önemlidir.

İdeal → gürültülü: kontrollü köprü

Analitik simden gürültülü sim’e geçiş, donanıma geçmeden önce “yumuşak” bir robustluk testidir. Gürültü seviyesini kademeli artırarak (T1/T2 benzeri parametreler veya kanal gücü) modelin nerede kırıldığını görebilirsiniz. Eğitimi doğrudan ağır gürültüde başlatmak, hiç öğrenememe ile karışan rastgele kaybolmalara yol açabilir. Klasik tarafta weight decay veya dropout’a benzer şekilde, kuantum tarafta daha sığ ansatz veya daha fazla shot da “düzenlileştirme” işlevi görür.

Pratik müdahaleler (cihaz seçimi düzeyinde)

Gürültü altında iyileşme için tipik araçlar: (1) öğrenme oranını düşürmek; (2) shot sayısını artırmak; (3) klasik ön/son katmanlarda batch ortalaması ile maliyeti yumuşatmak; (4) parametre sayısını azaltmak. Hangi kanalın hangi kapıdan sonra uygulandığı donanım dokümantasyonunda kalır — eğitim planında yalnızca “bu cihazda maliyet daha gürültülü mü?” sorusu yeterlidir. Fiziksel CPTP temeli için Kraus ve CPTP sayfasına bakın.

diff_method, cihazın “nasıl yürütüldüğü” ile “nasıl türevlendiği” arasındaki köprüdür; otomatik türev cihazdan bağımsız değildir. Tam vektör simülatörde backprop genelde en verimli yoldur; shots açık veya donanım yürütümünde parameter-shift, Hadamard testi veya sınırlı fark devreye girer. Yanlış eşleme — shots varken backprop varsaymak — sessizce yanlış gradyan veya çalışma zamanı hatası üretebilir.

Hızlı eşleştirme tablosu (sezgisel)

Analitik sim + Torch/JAX: çoğu zaman backprop. Shots açık sim veya donanım: çoğu zaman parameter-shift veya eklenti önerisi. Bilinmeyen gözlemlenebilir / karmaşık maliyet: yöntemi dokümantasyonla doğrulayın; sessiz uyumsuzluk en sık burada görülür. QNode tanımında cihaz ve diff_method’u birlikte yazın; cihaz değişince ikisini birden gözden geçirin. Kayıt → türev → yürütme sırasının teknik akışı yürütüm akışı sayfasındadır — burada yalnızca planlama düzeyinde kalıyoruz.

Sessiz hata örnekleri

Eğitim “çalışıyor” ama loss düşmüyorsa: shots açık mı, backprop hâlâ seçili mi? Donanıma geçince diff_method güncellendi mi? Arayüz (interface="torch") ile cihaz uyumlu mu? Bu kontroller §6’da arayüz boyutuyla birleşir; önce cihaz–türev ikilisini doğrulamak yeterlidir.

interface="torch", "jax" veya "tf", QNode çıktısının hangi otograd evrenine bağlanacağını seçer; bu, cihaz seçiminden ayrı bir karardır. Cihaz (qml.device) kuantum yürütücüsünü ve örnekleme rejimini tanımlar; arayüz ise dönen skaların veya tensörlerin klasik grafikte nasıl türevleneceğini belirler. İkisi uyumlu olmalıdır: örneğin tam vektör simülatör + Torch + backprop tipik bir “hızlı prototip” üçlüsüdür; shots zorunlu donanım + Torch ise çoğu zaman parameter-shift veya eklenti önerilen yöntemlere iter.

Üç arayüz, üç eğitim alışkanlığı

PyTorch tarafında QNode çıktısı torch.Tensor olarak döner; loss.backward() çağrısı kuantum alt grafiğin türevini klasik optimizatöre taşır. Klasik katmanlar GPU’da, kuantum değerlendirmeleri çoğu zaman ayrı bir süreçte veya CPU’da koşar — profil çıkarırken epoch süresini yalnızca GPU kullanımına bakarak yorumlamayın; QNode çağrı sayısı genelde asıl maliyettir. JAX tarafında eğitim fonksiyonunu jax.jit ile sarmak, sabit şekilli simülatör + backprop senaryolarında belirgin hızlanma sağlayabilir; vmap ile toplu parametre veya toplu girdi denemeleri fonksiyonel bir stil sunar. TensorFlow kullanıcıları aynı deseni GradientTape ile kurar; Keras katmanı olarak sarmalama mümkün olsa da, burada odak yine “cihaz + arayüz + diff_method üçlüsünün eğitim planına nasıl yazıldığı”dır.

Kararlılık: cihazın geri yayılıma etkisi

Arayüz tensör tipini seçse de, sayısal kararlılık büyük ölçüde cihazda kalır. Analitik simülatörde beklenen değerler düzgün yüzeyler üretir; sonlu shots ile maliyet örneklemeli tahmine dönüşür ve Torch grafiği “gürültülü” gradyanlar görür. Bu, klasik derin öğrenmedeki mini-batch gürültüsüne benzer; fakat kuantum tarafta gürültü seviyesi shot sayısı ve cihaz modeliyle doğrudan ölçeklenir. Eğitim planında önce düşük gürültülü rejimde arayüz ve mimariyi doğrulayıp, sonra shots veya donanım cihazına geçmek yaygın bir stratejidir — ayrıntılı ölçüm istatistiği ölçüm süreci sayfasında kalır.

PennyLane, IBM, IonQ, Rigetti, Amazon Braket ve benzeri sağlayıcılara eklenti cihazları (qml.device("plugin.name", ...)) üzerinden bağlanır. Hibrit QML perspektifinde bu, “devreyi çizip job göndermek”ten önce şu soruları yanıtlamayı gerektirir: ansatz’ınız yerel kapı kümesine sığıyor mu? İstediğiniz Pauli / Hamiltonyen terimleri destekleniyor mu? Ölçüm zorunlu mu (shots)? Gürültü ve kalibrasyon modeli eğitim maliyetini nasıl şekillendiriyor? Kuyruk gecikmesi epoch süresini sınırlıyor mu? Bu liste, donanımı öğrenme ortamı olarak okur; transpilerin kapıları nasıl yeniden yazdığı veya coupling map ayrıntıları bu sayfada merkezde değildir — bunlar Qiskit devre çalıştırma biriminde kalır.

Sim’den donanıma: beklenen kayma

Aynı QNode gövdesi, farklı dev ile sarıldığında matematiksel olarak “aynı program” gibi görünse de maliyet eğrisi kayar. İdeal simde düzgün bir minimum, donanımda gürültü ve kısıtlar yüzünden bulanıklaşır veya yer değiştirir; bu bir hata değil, simden donanıma geçişin normal parçasıdır. Pratikte önce simülatörde mimari ve hiperparametre aralığını keşfedin; donanımda ise daha az epoch, daha yüksek shot veya daha sığ ansatz ile ince ayar yapın. Donanım sonuçlarını “sim ile birebir aynı olmalı” diye zorlamak yerine, göreli iyileşme ve tekrarlanabilir trendlere bakın.

Ön kontrol listesi (öğrenme odaklı)

Donanıma geçmeden önce: (1) gözlemlenebilir ailesi ve kablo sayısı cihazla uyumlu mu; (2) varyasyonel kapılar native set içinde mi, yoksa eklenti otomatik transpile mı ediyor (bu davranışı bilin, detayına girmeyin); (3) maliyet shots ile mi tanımlı — eğitimde diff_method buna göre seçildi mi; (4) epoch başına kabul edilebilir süre ve bütçe hesabı yapıldı mı. IBM kuyruk ve backend sözleşmesi için Qiskit backend mimarisi sayfasına bakın; PennyLane tarafında yalnızca “öğrenme kodu bu backend’e hangi cihaz adıyla bağlanıyor?” sorusu yeterlidir.

Uzun eğitim koşularında cihazı aşamalı değiştirmek — ideal sim → gürültülü sim → donanım — bilinçli bir curriculum (öğretim programı) olabilir. Her aşamada aynı kuantum fonksiyonu gövdesi korunur; değişen yürütüm bağlamıdır. Bu, klasik ML’de “önce sentetik veri, sonra gerçek dağılım” düşüncesine benzer; fark, geçişin her adımında maliyetin istatistiksel veya fiziksel anlamının da evrilmesidir. Curriculum’u plansız yapmak (ara sıra cihazı değiştirip hiperparametreleri karıştırmak) deneyleri karşılaştırmayı imkânsız kılar.

Tekrarlanabilirlik: neyi günlüklemeli?

“Aynı hiperparametre, farklı sonuç” yalnızca klasik rastgele tohumdan kaynaklanmayabilir. Kuantum tarafta shots, cihaz sürümü, kalibrasyon tarihi ve örneklem tohumları maliyeti etkiler. Deney günlüğünde en az şunları tutun: dev tanımlayıcısı ve yapılandırma sözlüğü, shot sayısı, diff_method, arayüz adı, PennyLane ve eklenti sürümleri, klasik ve kuantum tohumları. Aynı dev nesne örneğini tüm epoch boyunca paylaşın; kablo etiketleri ve kablo sayısı değişmeden kalsın — kablo sözleşmesi için kablo yönetimi sayfasına bakın.

Üç geçiş kuralı

Sim → donanım: Önce mimariyi analitik veya düşük gürültülü simülatörde doğrulayın: maliyet düşüyor mu, gradyan işaretleri tutarlı mı? Donanıma geçince epoch sayısını ve öğrenme oranını yeniden ayarlayın; çoğu zaman daha muhafazakâr adımlar gerekir. diff_method: Cihaz değişince türev yolunu yeniden seçin — simde backprop çalışan bir kurulum, donanımda parameter-shift veya eklenti önerilen yönteme dönmeyi gerektirebilir; aksi halde gradyan sessizce anlamsızlaşır veya çalışma zamanı hata verir. Yürütüm sırasının teknik ayrıntısı yürütüm akışı başlığındadır. Maliyet tanımı: Donanımda desteklenmeyen çok terimli Hamiltonyenler veya belirli Pauli kombinasyonları eğitimden çıkarılmalı ya da simülatörde öğrenilen proxy maliyetle değiştirilmelidir; aksi halde “eğitim” aslında farklı bir problemi çözer.

İlk örnek analitik simülatör ve Torch arayüzüyle hızlı gradyanlı eğitim iskeletini gösterir. İkinci örnek, sonlu shots ile örneklemeli maliyet davranışını vurgular.

import torch
import pennylane as qml

# Analitik sim: backprop ile hızlı varyasyonel döngü.
dev = qml.device("default.qubit", wires=2)

@qml.qnode(dev, interface="torch", diff_method="backprop")
def model(w):
    qml.RY(w[0], wires=0)
    qml.RY(w[1], wires=1)
    qml.CNOT(wires=[0, 1])
    return qml.expval(qml.PauliZ(0))

w = torch.tensor([0.2, 0.5], requires_grad=True)
opt = torch.optim.SGD([w], lr=0.1)
for _ in range(20):
    opt.zero_grad(set_to_none=True)
    model(w).backward()
    opt.step()

import pennylane as qml
from pennylane import numpy as np

# Sonlu shots: maliyet her çağrıda örneklemeli tahmin olur.
dev = qml.device("default.qubit", wires=1, shots=1000)

@qml.qnode(dev, diff_method="parameter-shift")
def noisy_cost(theta):
    qml.RX(theta, wires=0)
    return qml.expval(qml.PauliZ(0))

# Aynı theta ile iki çağrı genelde birebir eşleşmez.
print(noisy_cost(np.array(0.7)))
print(noisy_cost(np.array(0.7)))

Cihaz seçimi, kayıt ve yürütümle birlikte okunduğunda tamamlanır. Resmî giriş için PennyLane belgelerindeki Devices bölümüne bakın.

• QNode mimarisi — cihazın QNode kapanışındaki yeri.
• Kuantum fonksiyonları — parametrik gövde ve eğitim döngüsü.
• Kablo yönetimi — cihaz kablo envanteri ile gövde uyumu.
• Yürütüm akışı — kayıt, türev ve çalıştırma sırası.
• Ölçüm süreci — shots ve dönüş istatistiği.