GPU ivmelendirmesi — Aer’de cihaz seçimi ve bellek gerçekliği

GPU ivmelendirmesi, tipik olarak yoğun doğrusal cebir çekirdeklerinde kazanç arar: büyük ünite uygulamaları, genlik güncellemeleri veya yoğunluk yürütmesindeki matris işlemleri gibi. Öte yandan kısa devrelerde çekirdek başlatma, Python katmanı ve veri kopyalama baskın çıkabilir; bu durumda duvar saati süresi GPU’da bile düşmeyebilir. “GPU açık” bayrağı tek başına bilimsel doğruluk veya daha iyi algoritma sunmaz — yalnızca aynı matematiği farklı bir işlemcide koşturmanızı sağlar.

Bu sayfanın sınırı

Donanım sürücü kurulumu, CUDA sürümü eşlemesi ve dağıtım özelindeki hata ayıklama burada adım adım yürütülmez; amaç, Aer kullanırken hangi soruları sormanız gerektiğini çerçevelemektir.

method="statevector" yolu, bellek içi tam genlik temsilinde GPU’ya uygun büyük paralel iş yükü üretebilir; yoğunluk yolu ise daha ağır bir temsil taşır ve VRAM tavanına daha çabuk yaklaşır. Shot tabanlı yürütmede ise histogram üretimi öne çıkar; burada kazanç, tek bir shot’un içindeki çekirdekten çok, toplu yürütme ve arka uç tasarımına bağlıdır. Bu ayrım, Aer simülatörü sayfasındaki “hangi yöntem hangi soruya?” çizelgesini tamamlar.

Gürültü modelleri

Gürültülü yürütme ek CPTP adımları getirir; GPU kazancı varsa bile model karmaşıklığı bellek ve dal budama davranışını değiştirir. Gürültü simülasyonu ile birlikte düşünmek, beklenmedik yavaşlamaların kaynağını ayırt etmeyi kolaylaştırır.

Statevector temsilinin boyutu üstel büyür; GPU’da “daha hızlı” olmak, önce verinin cihaza sığmasını gerektirir. PCIe veya sistem belleği üzerinden kopyalanan her büyük tensör, saf matematiksel karmaşıklığın ötesinde bir maliyet ekler. Yoğunluk matrisi yolunda bellek ihtiyacı daha da agresiftir — bu yüzden aynı kübit sayısında GPU seçmek bazen sorunu çözmez, yalnızca daha erken bellek dolu hatası almanızı sağlar.

Shot ve bellek

Çok shot’lu senaryolarda ara sonuçların biçimi, ara bellek tahsislerini etkiler; shot sayısı ile VRAM kullanımının birlikte izlenmesi gerekir. Shot mantığı sayfasındaki istatistik düşüncesi burada pratik bir uyarıdır.

Mikro kıyaslama yaparken ilk koşu genelde yanıltıcıdır: JIT derleme, önbellek ısınması ve senkronizasyon maliyetleri henüz oturmamıştır. Ayrıca on kübitlik bir örnekle “GPU her zaman kazanır” sonucu çıkarmak, büyük ölçekteki bellek duvarını gizleyebilir. İyi bir protokol, hem küçük hem orta hem de bellek sınırına yakın noktalarda ölçüm yapmayı ve ortam değişkenlerini sabitlemeyi içerir.

CPU taban çizgisi

Çok küçük devrelerde ve düşük shot’ta CPU referansı almak, GPU yolunun doğruluğunu kontrol etmek için hızlı bir çifte yönlü test sağlar; iki yolun sonuçlarını eşleştirmek, sayısal sapma mı yoksa API farkı mı ayırt etmenize yardım eder.

Paralel toplamlarda kayan nokta birleşme sırası değişebilir; bu, son basamaklarda küçük farklar üretebilir. Simülatör tohumları aynı kalsa bile donanım yolunda tam bayt düzeyinde eşleşme her zaman beklenmemelidir. Regresyon testlerinde toleranslı karşılaştırma veya referans yöntem seçimi sık kullanılan bir pratik haline gelir.

Shot tekrarlanabilirliği

Örnekleme tarafında tohum davranışı shot mantığı sayfasında özetlenmişti; GPU etkinleştirildiğinde bile simülatör içi determinizm hedeflenebilir, fakat farklı cihazlarda aynı bayt düzeyinde histogram beklemek gerçekçi olmayabilir.

Aer’in GPU yolu, çoğu zaman uygun CUDA sürücüsü ve Aer’in GPU destekli derlemesiyle gelir; dağıtım paketleri platforma göre değişir. Konteyner veya uzak sunucuda çalışırken cihazın gerçekten görünür olması (nvidia-smi gibi araçlarla) ilk doğrulama adımıdır. Python sanal ortamı ile sistem kütüphanesi uyumsuzlukları, sessiz biçimde CPU’ya düşmeye yol açabilir — “GPU seçtim ama hızlanmadım” şikâyetinin sık köklerinden biridir.

Belgeyi takip

Kurulum adımlarını burada kopyalamak yerine, kullandığınız Aer sürümünün resmi notlarına bağlanmak daha doğrudur; bu sayfa karar çerçevesi sağlar, reçete deposu değildir.

2000’lerin ortasında Ian Buck ve ekibi, grafik işlemcilerini genel amaçlı hesaplama için programlanabilir bir modelle tanımlamaya yönelik çalışmalarıyla öne çıktı; bu çizgi NVIDIA’nın CUDA platformuna dönüştü ve bilimsel hesaplamada “tek bir CPU çekirdeği yeterli değil” diyen birçok uygulama için standart bir ivme yolu haline geldi. Kuantum simülasyonu da aynı geniş ailededir: büyük doğrusal cebir ve örnekleme yükünü cihaz belleğine yakın yürütmek isteği, o tarihsel yönelimin devamıdır. Bu paragraf Aer API’sinin tarihçesi değil, yalnızca GPU’nun neden bu bağlamda doğal bir seçenek olduğuna dair kültürel bir köprüdür.

Bağlamda tutmak

CUDA veya ROCm ayrıntılarına girmek gerekmez; önemli olan, ivmenin “sihirli anahtar” değil, bellek ve paralellik düzenekleriyle sınırlı bir mühendislik seçimi olduğunu hatırlamaktır.

İlk blok, statevector yolunda GPU cihazını hedefleyen iskelet bir çağrı gösterir; ikinci blok aynı devre için cihaz seçimini bilinçli biçimde CPU’da bırakır. Sürümünüze göre parametre adları veya ek seçenekler gerekebilir.

from qiskit import QuantumCircuit
from qiskit_aer import AerSimulator

qc = QuantumCircuit(18)
qc.h(range(18))
qc.measure_all()

# Aer sürümünüze göre `device` / ek seçenekler farklılık gösterebilir.
sim = AerSimulator(method="statevector", device="GPU")
job = sim.run(qc, shots=256, seed_simulator=11)
print(job.result().get_counts())

from qiskit import QuantumCircuit
from qiskit_aer import AerSimulator

qc = QuantumCircuit(18)
qc.h(range(18))
qc.measure_all()

sim = AerSimulator(method="statevector")
job = sim.run(qc, shots=256, seed_simulator=11)
print(job.result().get_counts())

GPU, Aer’de bazen belirgin hız kazancı, bazen ise yalnızca daha pahalı bir bellek hikâyesi getirir. Yöntem seçimi, shot planı ve donanım görünürlüğü birlikte ele alındığında karar netleşir; tek başına “GPU” kelimesi yeterli bir tasarım belgesi değildir.

• Aer simülatörü — yöntem ve arka uç çerçevesi.
• Statevector simülasyonu — genlik yürütmesi ve bellek ölçeği.
• Yoğunluk matrisi simülasyonu — daha ağır temsil ve GPU sınırları.