Google, TorchTPU'yu açık kaynak yaptı; PyTorch/XLA arşivi 15 Kasım için hazırlandı

Google, TPU'lara yerel bir PyTorch yolu sunuyor

Google, 20 Ekim 2026'da TorchTPU'yu GitHub'da yayınladı; bu backend, TPU'ları PyTorch'un GPU ve CPU'larda olduğu gibi yerel olarak hedefleyebildiği bir cihaza dönüştürüyor. Gabriel Anhaia'nın bir dev.to yazısına göre bu sürüm, önceki yolu da sonlandırıyor: PyTorch/XLA artık kullanımdan kaldırıldı ve deposunun 15 Kasım 2026'da arşivlenmesi planlanıyor. Bu, torch_xla çalıştıran ekiplere proje salt okunur hale gelmeden önce dört haftadan kısa bir süre bırakıyor.

dev.to yazısı, Google'ın TorchTPU'yu PyTorch Conference 2026'da tanıttığını ve atıf yaptığı Google Cloud bloguna göre Meta'nın PyTorch ekibiyle birlikte geliştirdiğini söylüyor. Backend, hata ayıklama için eager execution ve üretim performansı için torch.compile sunuyor.

Sürüm 0.2.0 neler içeriyor

Depo Apache 2.0 lisanslı ve PyPI'daki güncel sürüm 0.2.0; Python 3.11 veya daha yeni bir sürüm gerektiriyor. Google'ın özellik sayfaları TPU v5e, v5p, v6e ve v7'yi doğrulanmış donanım olarak listeliyor; v8i ve v8t yakın vadeli yol haritasında yer alıyor ancak henüz desteklenmiyor.

Eğitimin yanında serving desteği de geliyor. Google, Inferact ile geliştirilmiş bir vLLM backend'ine ve RadixArk ile geliştirilmiş bir SGLang backend'ine bağlantı veriyor; Hugging Face Transformers v5'ın device_map="tpu" kullanarak TPU'lara dağıtılabildiğini söylüyor. Eğitim tarafında Google, TorchTitan ile Qwen 3 8B eğitirken yüzde 52'ye varan tepe model-FLOPs kullanımı bildiriyor ve 8.192 Ironwood TPU'ya kadar neredeyse doğrusal ölçekleme olduğunu belirtiyor. Bunlar bağımsız bir kıyas değil, Google'ın kendi rakamları.

Taşınma tek bir dizgeyle başlıyor

SSS, mevcut bir iş yükünün taşınmasını .to("cuda") ifadesini .to("tpu") olarak değiştirmek olarak tanımlıyor. Kurulumla ilgili bir ayrıntı önemli: README, varsayılan torch kurulumunun CUDA sürümünü çektiği uyarısını yapıyor; bu yüzden Google, torch_tpu 0.2.0'ı download.pytorch.org'daki CPU wheel'iyle birlikte kurmayı öneriyor.

Yürütme modeli belgeleri varsayılan katı eager modunu anlatıyor: her işlem -O1'de derlenen tek işlemlilik bir grafa dönüşüyor ve önbelleğe alınıyor; böylece önbellek hızla ısınıyor. torch.compile ise TorchTPU'ya tam FX grafiğini veriyor ve onu -O2'de derliyor. İkisinin arasında iki ortam değişkeni var: TORCH_TPU_LAUNCH_BLOCKING hataların onlara neden olan işlemde ortaya çıkmasını sağlıyor, TORCH_TPU_DEFER_AND_FUSE ise ertelenmiş işlemleri daha büyük graflarda birleştiriyor; Google'a göre bu, modelde hiçbir değişiklik yapmadan varsayılan eager'a kıyasla yüzde 50'ye varan hızlanma sağlayabiliyor.

Önce kontrol edilmesi gereken bilinen sınırlar

Belgeler, cihazı neyin yavaşlattığı konusunda açık sözlü. my_tensor.all() gibi tensor değerlerine bağlı Python dallanmaları, konağa geri kopyalama yapmaya ve yürütme kuyruğunu boşaltmaya zorluyor; ayrıca derlenmiş veya birleştirilmiş modda grafiği bozuyor. torch.masked_select gibi veriye bağlı çıktı şekillerine sahip işlemler de benzer davranıyor.

Dinamik şekiller, 128'in katlarına yuvarlanmış derlenmiş bucket'lar aracılığıyla ele alınıyor; varsayılan olarak bir, en fazla sekiz bucket kullanılabiliyor. Varsayılan dynamic=None ayarında büyüyen bir boyut sembolik olarak ele alınıyor; Google'ın genişleyen bir KV cache'li decode-döngüsü örneğinde yalnızca ilk üç adım derleme süresi ödüyor. Belirtilen kısıtlamalar şunlar: her trace için en fazla sekiz bucket, dynamic=True yok, torch.nonzero tarzı çıktı şekilleri yok ve bu yolda özel Pallas kernel'leri yok. Bu sınırlı dinamik yürütülebilir dosyalar AOTAutograd önbelleğine yazılmıyor, dolayısıyla her süreç başlangıcında yeniden derleniyorlar.

Özellik olgunluğu değişken. Karışık eager ve derlenmiş çalıştırmalar, ileri ve geri geçişler, Pallas kernel'leri ve SimpleFSDP doğrulanmış durumda; FSDPv2 ve SymInt'ler deneysel ve FSDPv2 düşük performanslı olarak işaretlenmiş.

Bugün PyTorch/XLA çalıştırıyorsanız

SSS, iki yığın arasında teknik bir çizgi çiziyor: PyTorch/XLA, JAX runtime bileşenlerine ve kendi API'lerine dayanıyordu; TorchTPU ise JAX runtime bağımlılığı olmayan yerel bir backend — ve Google, TorchTPU'nun JAX'ın yerini almak için tasarlanmadığını not ediyor. 15 Kasım'dan sonra eski depo okunabilir ve klonlanabilir kalacak ancak yeni issue veya pull request kabul etmeyecek. dev.to yazısı, bir kod tabanında git grep ile torch_xla, xla_device ve xm. referansları için arama yapmayı, sonra her eşleşmeyi TorchTPU'nun özellik matrisine göre denetlemeyi öneriyor.

Yanında bir önizleme agent paketi geliyor

Google ayrıca bir önizleme TPU agent paketi yayınladı: coding agent'lar için beceriler ve subagent'lar içeren, tek bir tpu-agent becerisiyle öne çıkan ve onboarding, profiling, donanım kontrolleri ile kernel'ler için uzmanlara yönlendiren bir paket. Claude Code ve Antigravity destekleniyor; Codex ve Cursor yakında olarak listelenmiş; şimdilik dışarıdan katkı kabul edilmiyor. Yükleyici, becerileri, agent başına prompt'ları ve yönetilen bir CLAUDE.md bloğu (Antigravity altında AGENTS.md) yazıyor; bu yüzden commit etmeden önce diff'i gözden geçirmek tavsiye ediliyor.

Neden önemli

TPU'lardaki PyTorch kullanıcıları artık katı, yakın vadeli bir son tarihle karşı karşıya: arşivlenmiş, bakımsız bir yığın karşısında belgelenmiş boşlukları olan bir 0.2.0 sürümü. Zamanlama da rekabetçi. dev.to yazısının atıf yaptığı TechCrunch, lansmanı Google'ın Nvidia'nın AI geliştiricileri üzerindeki hâkimiyetine meydan okuyan Amazon'a katılması olarak çerçeveliyor — AWS kendi Trainium PyTorch backend'ini duyurduktan bir gün sonra. TPU'lar, GPU'lar ve CPU'lar hepsi yerel PyTorch hedefleri haline gelirse, donanım seçmeye başlamak bir framework bağlılığından çok bir satır kodluk bir karar gibi görünmeye başlıyor.