Transformers Model Entegrasyon Sözleşmeleri (MIC)

30 Temmuz 2026'da Transformers kütüphanesi, T5 modeli için PyTorch'un ölçeklendirilmiş nokta çarpım dikkatini (SDPA) etkinleştirdi. Ancak bunun beklenmedik bir yan etkisi olarak, UMT5'in kod çözücüsü (decoder) gelecekteki token'lara dikkat edebilmeye başladı. Eğitim sırasında model, tahmin etmesi gereken cevaba gizlice bakabiliyordu. Hiçbir sistem çökmediği için bu sessiz hata yaklaşık iki ay boyunca ana dalda (main) kaldı. Daha sonra bu commit'ler geriye dönük oynatıldığında, CPU üzerinde çalışan küçük bir UMT5 modeli her seferinde hatayı yakaladı. Bu yazı, söz konusu küçültülmüş modeli ve etrafında inşa edilen test mimarisini ele almaktadır.

Hatalar Ana Dala (Main) Neden Ulaşır?#

Transformers 750'den fazla model tipini destekler ve devasa bir test paketine sahiptir: ana dalda 88.000'den fazla CPU testi ve günlük çalışmalarda 200.000'den fazla GPU testi bulunur. Üstelik model testleri bunun yalnızca bir parçasıdır; boru hatları (pipelines), eğitim, dağıtık yürütme, nicemleme (quantization) ve dikkat çekirdekleri de test edilir. Entegrasyon testleri gerçek ağırlık noktalarını (checkpoints) yükler ve model API'sini gerçek donanımda sınar. Tüm bunları her Pull Request (PR) aşamasında çalıştırmak, gün boyu çok sayıda GPU'yu meşgul etmek anlamına gelir ki bu pratik değildir. Zamanlanmış bir test çalışması gerilemeyi (regression) bulduğunda ise hata çoktan ana dala karışmış olabilir.

Buradaki mühendislik yaklaşımı modeli küçültmektir. Gerçek kontrol noktasının yapılandırmasından üretilen, daha az ve daha dar katmanlara sahip ancak içerdiği her katman türünü barındıran, tokenizer ve işlemci dosyaları değiştirilmemiş küçük bir model yani bir fixture oluşturulur. Bir kez yayınlanır ve tekrar tekrar kullanılır. Böylece ucuz bir CPU çalıştırıcısında "hızlı entegrasyon testleri" koşulabilir. Yapılan CPU çalışmasında, deneysel UMT5 fixture modeli 1.227 MB olan kaynak modele kıyasla yalnızca 66 MB ağırlık kullanmıştır. Bu yöntem, standart GPU'lara sığmayan devasa modelleri bile CPU üzerinde test etmeyi mümkün kılar.

Model entegratörleri halihazırda küçük test modelleri (tiny-random-*) oluşturmaktadır. Ancak yazılım geliştirme açısından sadece modeli yükleyip ileri besleme (forward pass) çalıştırmanın ötesine geçen ortak bir reçeteye ihtiyaç vardır; çünkü UMT5 hatası basit bir ileri besleme testinden sorunsuz geçebilirdi. Fixture yapıları tam entegrasyon testlerinin yerini almasa da, PR aşamasında hataları ana dala ulaşmadan yakalama şansı verir.

Model Entegrasyon Sözleşmelerini (MIC) Tanıyalım#

transformers-mic, bu testleri paketlemek için önerilen yeni bir standarttır. Bir Model Entegrasyon Sözleşmesi (MIC) üç temel parçadan oluşur:

• Bir fixture (sabit model): Yukarıda açıklanan, bir kez yayınlanan ve sabitlenen küçültülmüş model.
• Bir kullanım yolu (usage path): Metin üretmek veya bir eğitim adımı çalıştırmak gibi, insanların modelle yaptığı işlemleri içeren çalıştırılabilir bir Markdown örneği.
• Referans değerler (baselines): Bu örneği çalıştırırken kaydedilen ve bir insan tarafından incelenip onaylanan çıktılar.

Kullanım yolunu fixture üzerinde çalıştırmak hala aynı referans çıktıları üretiyorsa sözleşme geçerliliğini korur. Bir sözleşme tek bir kontrol noktasını değil, bir mimariyi ve kullanım yolunu kapsar; uyumlu modeller kendi beklenen sonuçlarını korurken aynı fixture'ı paylaşabilir ve bunlar huggingface-mic altında yayınlanır.

Örneğin SmolLM sözleşmesi, "The capital of France is" gibi istemlerden metin üretir ve üretilen token kimliklerini kaydedilmiş yanıtla karşılaştırır:

inputs = tokenizer("The capital of France is", return_tensors="pt")
outputs = model.generate(**inputs, max_new_tokens=4, do_sample=False)
new_tokens = outputs[:, inputs["input_ids"].shape[1]:]
print(tokenizer.batch_decode(new_tokens, skip_special_tokens=True))

Ayrıca bu yapı eğitim kaybını (training loss) karşılaştırır, gradyanların sonlu (finite) olduğunu kontrol eder ve bir optimizasyon adımını doğrular.

Pratik Çıkarım: Yapay zeka sistemlerinde sessiz mantık hatalarını erken yakalamak için yalnızca sistemin çökmemesini (forward pass) test etmek yetmez; CI/CD süreçlerinde CPU'da hızlıca koşabilen küçültülmüş mimari kopyalar (fixture) ve deterministik çıktı sözleşmeleri kullanmak maliyet ve güvenilirlik açısından kritik bir mühendislik pratiğidir.

Bu konuyu derinlemesine öğrenmek isterseniz: AI Test Stratejileri modülüne göz atın.