Örnek sorular
Ti Checkpointing Fault ToleranceZorluk 2
Bir ekip checkpoint'leri yalnızca torch.save(model.state_dict(), path) ile kaydediyor, sonra eğitimi bu dosyayı taze kurulmuş bir modele ve taze kurulmuş bir SGD(momentum=0.9) optimizer'a yükleyerek devam ettiriyor. Resume sonrası önce ne bozulur?
- aModel'in forward pass'i resume edilen ilk batch'te hemen NaN çıktı üretir.
- bOptimizer'ın henüz momentum tampon değeri yok; resume'un ilk adımları momentum'u sıfırdan yeniden kurar.✓
- cHiçbir şey bozulmaz; SGD momentum'u optimizer'da değil model parametrelerinin içinde saklanır.
- dLoss fonksiyonu resume sonrası sessizce farklı bir reduction moduna geçer.
Açıklama:Taze bir SGD optimizer'ın state_dict()['state'] alanı en az bir .step() çağrılana kadar boştur; bu yüzden momentum sıfırdan yeniden birikmek zorundadır — çökme öncesi momentum tampon değerleri hiç kaydedilmemiştir çünkü yalnız model.state_dict() diske yazılmıştı.
Ti Checkpointing Fault ToleranceZorluk 2
Bir iş, öğrenme oranını 12.000. adıma kadar 0.1'den 0.025'e düşüren bir StepLR scheduler ile eğitiliyor. Yalnızca model ve optimizer durumu kaydedilmişti. Çökme sonrası tamamen yeni bir StepLR örneğiyle resume edildiğinde eğitim hangi öğrenme oranından devam eder?
- a0.025, çünkü optimizer'ın
param_groups'u — scheduler'dan bağımsız olarak — son uygulanan öğrenme oranını hatırlar. - b0.0125, çünkü scheduler resume edilen ilk adımda oranı bir kez daha yarıya indirir.
- c0.1, scheduler'ın taban öğrenme oranı — çünkü yeni bir
StepLR last_epoch=0 ile başlar.✓ - d0.0, çünkü kaydedilmemiş bir scheduler yeniden ısıtılana kadar varsayılan olarak sıfır öğrenme oranı verir.
Açıklama:Yeni kurulan bir StepLR her zaman last_epoch=0 ile başlar; bu yüzden optimizer'ın kurucusuna verilen taban öğrenme oranını uygular. Scheduler'ın kendi durumu (adım sayacı) checkpoint'lenmediği için, iş taban orandan itibaren decay takvimini sessizce baştan başlatır.
Ti Checkpointing Fault ToleranceZorluk 1
opt = torch.optim.SGD(model.parameters(), lr=0.1, momentum=0.9)
print(len(opt.state_dict()['state']))
Bu satır
opt kurulduktan hemen sonra, hiç
.step() çağrılmadan çalışıyor. Ne yazdırır?
- a0✓
- bModeldeki parametre tensörlerinin sayısı.
- c1, çünkü
state kurulumdan hemen sonra tek bir toplu girdi tutar. - dBir hata, çünkü
state_dict() ilk optimizasyon adımından önce çağrılamaz.
Açıklama:Bir optimizer'ın state sözlüğü tembel doldurulur — momentum tampon değerleri gibi girdiler yalnızca bir parametre ilk kez .step() ile güncellendiğinde oluşturulur. Kuruluşun hemen ardından bu sözlük boştur, dolayısıyla len(...) 0 verir.
Ti Checkpointing Fault ToleranceZorluk 1
Aşağıdakilerden hangisi gerçekten torch.amp.GradScaler'ın state_dict()'i içinde saklanır?
- aEğitim başladığından beri gözlenen tüm loss değerlerinin tam listesi.
- bEn son backward pass'te hesaplanan her gradyan tensörünün bir kopyası.
- cOptimizer'ın her parametre grubu için öğrenme oranı.
- dŞu anki loss-scale faktörü, artı büyüme/geri çekilme faktörleri ve bir büyüme-aralığı adım sayacı.✓
Açıklama:GradScaler.state_dict(), {'scale', 'growth_factor', 'backoff_factor', 'growth_interval', '_growth_tracker'} gibi küçük bir sözlük döndürür — mevcut ölçekleme faktörünü ve bir sonraki ölçek büyütmesine ne kadar yakın olunduğunu izler; gradyanları ya da loss geçmişini değil.
Ti Checkpointing Fault ToleranceZorluk 2
Bir model checkpoint'i yalnızca ağırlıkları ve optimizer durumunu kaydediyor, RNG durumunu değil. Çökme sonrası eğitim aynı adımdan, başlangıçta taze bir torch.manual_seed(123) çağrısıyla devam ettiriliyor; amaç çökme öncesiyle aynı dropout maskelerini ve artırmaları yeniden üretmek. Gerçekte ne olur?
- aRNG dizisi tam olarak yeniden üretilir, çünkü başlangıçta tohumlamak bir koşunun herhangi bir sonraki noktasındaki diziyi yeniden üretir.
- bRNG dizisi hemen sapar, çünkü yeniden tohumlamak üreteci sıfırdan yeniden başlatır.✓
- cPyTorch, RNG durumunu otomatik olarak
model.state_dict() içinde saklar ve geri yükler; bu yüzden bu bir sorun değildir. - dModel
.train() modundayken dropout maskeleri RNG durumundan bağımsız olarak belirlenmiştir.
Açıklama:Aynı taban tohumla yeniden tohumlamak, diziyi sıfır konumundan tekrar oynatır — çökme öncesi üretecin binlerce önceki çekimden sonra ulaştığı noktadan değil. Bu yüzden resume edilen koşunun dropout maskeleri ve artırmaları, çökme öncesinde gelecek olanlarla artık örtüşmez.
Ti Checkpointing Fault ToleranceZorluk 2
Bir checkpoint yazma rutini önce torch.save(state, path + ".tmp") çağırıyor, ancak bu hatasız tamamlandıktan SONRA os.replace(path + ".tmp", path) çağırıyor. Neden doğrudan torch.save(state, path) çağırmak yerine geçici bir yola yazıp yeniden adlandırılıyor?
- aSüreç yazma sırasında ölürse, geçici dosya yarım kalır —
path'teki dosya dokunulmamış kalır.✓ - bBu gereklidir çünkü
torch.save aynı yoldaki mevcut bir dosyanın üzerine yazamaz. - cYazımı hızlandırır, çünkü bir dosyayı yeniden adlandırmak — tam bir yeniden yazımın aksine — aynı bayt sayısını iki kez yazmaktan daha hızlıdır.
- dYalnızca GPU tensörlerini kaydederken gereklidir; CPU tensörleri bu riski taşımadan her zaman doğrudan nihai yola kaydedilebilir.
Açıklama:Aynı dosya sisteminde bir yeniden adlandırma (os.replace) neredeyse anlıktır ve ya tamamen başarır ya da hiç gerçekleşmez — bu yüzden path her zaman ya eski, tam checkpoint'e ya da yeni, tam checkpoint'e işaret eder, asla yarım yazılmış bir dosyaya değil. Doğrudan path'e yazmak, süreç kayıt sırasında ölürse orada yarım kalmış, okunamaz bir dosya bırakma riski taşır.