- Google TPU v1, derin öğrenme servislerinin çıkarım maliyeti ve ölçeğini karşılamak için, GPU’ya kıyasla 10 kat fiyat/performans hedefiyle 2013 sonundan itibaren 15 ayda geliştirilen bir ASIC’tir
- Temel nokta, 1978’de H.T. Kung ve Charles E. Leiserson’ın systolic array kavramını 256×256 MAC yapısı olarak uygulayarak, matris çarpımı sırasında ara sonuçların belleğe gidip gelmesini azaltmasıdır
- TPU v1, ana makineyle PCIe üzerinden iletişim kurar, ağırlıkları DDR3-2133’te saklar ve çıkarım akışını
Read_Host_Memory, Read_Weights, Matrix_Multiply / Convolve, Activate, Write_Host_Memory gibi az sayıda komutla oluşturur
- 8-bit×8-bit tamsayı çarpımı ve niceleme ile kayan nokta hesaplamalarının die alanı yükünden kaçındı; TensorFlow ile entegre çalışan User Space Driver ve Kernel Driver yürütmeyi kontrol eder
- Intel Haswell CPU ve Nvidia K80 GPU o dönemin karşılaştırma hedefleriydi; TPU v1 çıkarımda yaklaşık 15~30 kat daha hızlıydı ve GPU’ya kıyasla göreli artımlı performans/Watt değeri 25~29 kat daha yüksekti, ancak eğitim için bir cihaz değildi
Çıkarım maliyetini düşürmek için TPU v1’in çıkış noktası
- TPU v1 projesinin hedefi, derin öğrenme tabanlı servislerin gerektirdiği büyük ölçekli donanım maliyetini düşürmek için hızlıca çıkarım amaçlı bir ASIC geliştirmekti
- Hedef, çıkarımda GPU’ya göre 10 kat fiyat/performans üstünlüğüydü
- Hızlı geliştirme, yüksek performans, büyük ölçekli uygulama, yeni iş yüklerini anında destekleme ve maliyet verimliliği birlikte gerekiyordu
- TPU adı, tensor işlemlerini hızlandıran bir cihaz olmasından gelir
- Gerçek TPU v1 donanımının ele aldığı temel hesaplamalar çoğunlukla vektör ve matris işlemleridir
- Bir sinir ağının gizli katmanları ve çıkış katmanları, giriş değeri vektörü ile ağırlık matrisinin çarpımına aktivasyon fonksiyonu uygulanmasının sonucu olarak ifade edilebilir
- Birden fazla giriş verisi geldiğinde, matris çarpımı sonucunun her öğesine aktivasyon fonksiyonu uygulanmış olur
Systolic array ile matris çarpımını işleme
- TPU v1, H.T. Kung ve Charles E. Leiserson’ın 1978 tarihli Systolic Arrays (for VLSI) makalesindeki systolic system kavramını kullanır
- Birden çok işlemcinin veriyi düzenli bir ritimle hesaplayıp ilettiği bir yapıdır
- Her işlemci kısa bir hesaplama yaparken veriyi sürekli içeri ve dışarı taşır
- Basit bir 2×2 matris çarpımında, giriş değerleri üstten ve soldan doğru sırayla verilirse sonuç 2×2 MAC dizisinden doğal olarak çıkar
- Her MAC çarpma ve toplama işlemini gerçekleştirir
- Kısmi toplamlar dizinin içinde saklanır ve nihai sonuç hareket eden bir köşegen biçiminde ortaya çıkar
- 2×2 örneği 4 adım gerektirir; ancak pratikte sol üstteki MAC boşalır boşalmaz bir sonraki matris çarpımı başlatılabildiği için, her 2 çevrimde bir yeni matris çarpımı mümkündür
- Temel nokta, veriler doğru sırayla systolic array’e beslendiğinde değer ve sonuç akışının gerekli hesaplama sırasını kendiliğinden oluşturmasıdır
- Ara sonuçları ana belleğe kaydedip yeniden getirmeye gerek yoktur
- Matris çarpım biriminin yapısı ve giriş sırası sayesinde ara sonuçlar ihtiyaç duyulduğu anda otomatik olarak kullanılabilir
TPU v1 sistem yapısı
- TPU v1, ana bilgisayarla PCIe yüksek hızlı seri veri yolu üzerinden iletişim kurar ve kendi DDR3 DRAM’ine doğrudan erişir
- Ana bileşenler şöyledir
- DDR3 DRAM / Weight FIFO
- Ağırlıklar, DDR3-2133 arayüzüyle bağlı DDR3 RAM yongalarında saklanır
- Ana makine belleğinden PCIe üzerinden önceden yüklenir, ardından Matrix Multiply Unit tarafından kullanılmak üzere Weight FIFO’ya taşınır
- Matrix Multiply Unit
- 256×256 MAC’ten oluşan bir systolic array’dir
- Üstten 256 ağırlık, soldan 256 veri girişi alır
- Accumulators
- Systolic matris biriminin altından çıkan sonuçları saklar
- Activation
- Sinir ağının aktivasyon fonksiyonunu uygulayan aşamadır
- Unified Buffer / Systolic Data Setup
- Aktivasyon fonksiyonu uygulanmış sonuçları saklar ve bir sonraki katmanın hesaplaması için Matrix Multiply Unit’in girişine yeniden beslenmeye hazırlar
Hesaplama biçimi ve komut kümesi
- TPU v1’in Matrix Multiply Unit’i 8-bit×8-bit tamsayı çarpımı yapar
- Niceleme kullanarak daha büyük die alanı gerektiren kayan nokta hesaplamalarından kaçınır
- Komut kümesi, yaklaşık 20 komut içeren bir CISC tasarımdır
- Komutlar bellekten getirilmez; ana bilgisayar tarafından PCIe üzerinden gönderilir
- Çıkarım akışının büyük bölümü 5 ana komuttan oluşur
Read_Host_Memory
- Giriş değerlerini ana makine belleğinden PCIe üzerinden Unified Buffer’a okur
Read_Weights
- Ağırlık belleğinden Weight FIFO’ya ağırlıkları okur
Matrix_Multiply / Convolve
- Unified Buffer’daki girişleri Accumulators’a gönderirken matris çarpımı veya konvolüsyon yapar
- B×256 giriş ile 256×256 sabit ağırlık girişini çarparak B×256 çıktı üretir ve B adet pipeline çevrimi sürer
Activate
- Accumulators’taki girdilere ReLU, Sigmoid gibi yapay nöronların doğrusal olmayan fonksiyonlarını uygular ve sonucu Unified Buffer’a çıkarır
Write_Host_Memory
- Unified Buffer’daki sonucu PCIe üzerinden ana makine belleğine yazar
- Bu akış kabaca şu biçimde görülebilir
Read_Host_Memory
Read_Weights
Loop_Start
Matrix_Multiply
Activate
Loop_End
Write_Host_Memory
- Matris birimi, Unified Buffer okuma-yazmalarını azaltıp enerji tasarrufu sağlamak için systolic yürütme kullanır
- Veri soldan girer, ağırlıklar üstten yüklenir
- 256 öğelik MAC işlemleri, köşegen bir dalga cephesi gibi matrisin içinden geçer
TensorFlow ve sürücü yığını
- TPU v1 donanımını gerçek servislerde kullanmak için onu destekleyen bir yazılım yığını gerekiyordu
- Google, TensorFlow’u geliştirip kullandığı için TensorFlow’un TPU v1 ile çalışmasını sağlayacak sürücüleri oluşturmak temel aşamaydı
- TPU yazılım yığınının CPU ve GPU yığınlarıyla uyumlu olması gerekiyordu
- Uygulamaların TPU’ya hızlıca taşınabilmesi gerekiyordu
- TPU’da çalışan uygulama bölümü genellikle TensorFlow ile yazılır ve GPU veya TPU’da çalıştırılabilir bir API’ye derlenir
- GPU’da olduğu gibi TPU yığını da User Space Driver ve Kernel Driver olarak ayrılır
- Kernel Driver hafif tutulur; yalnızca bellek yönetimi ve kesmeleri işler, uzun vadeli kararlılığı hedefler
- User Space Driver sık değişir; TPU yürütme ayarları ve kontrolünden, verinin TPU sırasına göre yeniden biçimlendirilmesinden, API çağrılarının TPU komutlarına dönüştürülmesinden ve uygulama ikililerinin oluşturulmasından sorumludur
28 nm üretim süreci ve die yerleşimi
- TPU v1, TSMC’nin nispeten olgun 28 nm üretim süreciyle üretildi
- O dönemde Google veri merkezlerinde kullanılan Intel Haswell CPU ve Nvidia K80 GPU yongaları daha gelişmiş üretim süreçleriyle üretilmişti
- Google’a göre TPU v1’in die alanı, bu yongaların die alanının yarısından küçüktür
- Basit ISA, kod çözme ve ilgili işler için gereken die ek yükünü azalttı
control alanı die alanının yalnızca %2’sini kaplar- Matrix Multiply Unit %24, Unified Buffer ise %29 yer kaplar
Performans karşılaştırması ve net sınır
- TPU v1, önceden eğitilmiş modelleri Google ölçeğindeki gerçek servislerde daha verimli kullanmak için tasarlanmış çıkarım amaçlı bir cihazdır
- Eğitim hızını veya verimliliğini artırmak için tasarlanmış bir cihaz değildir
- Çıkarım ve eğitim, özelleşmiş donanım geliştirmede birbirinden farklı sorunlar doğurur
- 2013 itibarıyla temel karşılaştırma hedefleri Intel Haswell CPU ve Nvidia K80 GPU idi
- TPU v1, K80 GPU’dan 25 kat daha fazla MAC sayısına sahiptir
- TPU v1, K80 GPU’dan 3,5 kat daha fazla on-chip belleğe sahiptir
- TPU v1, çıkarımda K80 GPU ve Haswell CPU’dan yaklaşık 15~30 kat daha hızlıdır
- GPU’ya kıyasla göreli artımlı performans/Watt değeri 25~29 kattır
- Özelleştirilmiş mimarisi sayesinde TPU v1, o dönemin CPU ve GPU’larına göre daha yüksek çıkarım performansı ve daha düşük enerji kullanımı elde etti
- Hızlı çıkarım ve güç verimliliği şeklindeki tek hedefe odaklanan birinci nesil bir tasarım olduğu için, eğitim amaçlı tasarlanmamış olması sınırlama olarak kalır
1 yorum
Hacker News yorumları
Groq CEO'su Jonathan Ross, yakın tarihli bir podcast röportajında Google’da ilk TPU’yu yapma hikâyesini anlattı; başlangıçta çıkarım hızı sorunu yaşayan bir ekibin yakınında otururken %20 zamanında yaptığı bir FPGA’ymış.
Çalışan bir şey ortaya çıkardıktan sonra Jeff Dean hesap yapmış ve ASIC’e geçmeye karar vermişler.
Bugün olsa Google’ın TPU ekibini ayrı bir şirket olarak bölüp çıkarması gerektiğini düşünüyorum. Nvidia’ya karşı koyabilecek tek güvenilir rakip ve yazılım desteği de Nvidia’dan sonraki seviyede.
https://open.spotify.com/episode/0V9kRgNS7Ds6zh3GjdXUAQ?si=q...
Ama bunların her birinin zayıf yönü var. Dökümhane kapasitesi sıkışık, fakat Nvidia daha pahalı AI çipleri satabiliyorsa tüketici GPU pazarını feda edebilir. Rakiplerden biri birkaç yıl önceden büyük bahis oynarsa ya da Intel gibi çok üretim kapasitesine sahip bir şirket önceliklerini değiştirirse bu avantaj ortadan kalkar.
Tescilli yazılımın sektör standardı olması rahatlık sağlar, ama gerçek önemi kullanım senaryosuna çok bağlı. TPU’lar için donanım tasarımı GPU’lara göre özünde çok daha basit görünüyor; ışın izleme, doku örnekleyicileri ve rasterleştirme gerekmiyor, çoğunlukla matris çarpımı ve bol bellek yeterli.
Müşteri ilişkileri, konuşmanın içinde kalmaya yarar; ama en ufak avantajı bile arayan bir pazarda dolar başına en yüksek FLOPS’u sunan donanım tedarikçisi, üretim kapasitesini dolduracak kadar müşteri bulacaktır. Bu yüzden birkaç yıl içinde rekabetin oldukça hızlı şekilde gerçeğe dönüşeceğini düşünüyorum.
Ancak TPU, Google içinde de nispeten kıt bir bilişim kaynağı ve şirket içi talebi karşılamakta bile zorlanıyor olabilir.
Bir şirkete bu kadar saygı duyduğumu pek söylemem, ama Groq’a gerçekten saygı duyuyorum.
Google TPU’yu icat etti ve Google Research LLM makalesini bile yayımladı; buna rağmen değerin neredeyse %100’ünü neden NVDA ve AI startup’larının aldığını anlamıyorum.
Google örneğinde de, ChatGPT benzeri bir şeyi yaygın sunmayı önermek, arama motorundaki ücretli gösterimleri ve insanların ziyaret etmesine gerek kalmayacak sitelerden gelen reklam gelirini baltalayabilir benzetmesi yapılabilir. Bu yüzden ancak rekabet gerektirdiğinde, daha az sarsıcı bir şekilde dikkatlice devreye alma kararı çıkmış olabilir.
Gerçekte muhtemelen bu kadar basit değildir, ama sebep buysa epey komik olurdu.
https://www.linkedin.com/posts/eolver_googles-defense-agains...
Google çalışanıyım; bir süredir TPU’ya bakmadıysanız v5’e göz atmanızı öneririm. Artık PyTorch/JAX destekliyor, bu yüzden TensorFlow’a özel olduğu döneme göre kullanması çok daha kolay.
Bu yazı, soyut biçimde dağınık duran birçok parçanın gerçekte silikonun içinde nasıl aktığını iyi şekilde birbirine bağlamış.
Basit CISC komutlarının LLM çıkarım aşamalarına neredeyse birebir karşılık geldiğini görmek özellikle hoşuma gitti.
Bilgisizliğimi ortaya koyan aptalca bir soru olabilir ama tüketici tarafında M1~M4 çiplerinin bazı AI işleri için iyi olduğunu sürekli duyuyorum.
Son dönemde benim için en önemli şey Photoshop, Resolve gibi araçlar; Apple’ın yeni özel çiplerinde eski makinemden çok daha hızlı çalıştıklarını gördüm.
Bu, bu çipin ya da H100’ün yapabildiklerine pek iyi uzanmayabilir, ama bir ölçüde uzanıp uzanmadığını merak ediyorum. Elbette Apple özel çiplerini ayrı satmıyor; bu yüzden pratikleştirmek için GPU ve AI çipleriyle dolu harici sunucu benzeri bir ürün çıkarması gerekir.
M* çipleri birleşik bellek kullanıyor ve özellikle Pro/Max/Ultra, 1080 gibi GPU’larla karşılaştırıldığında bile çok yüksek bellek bant genişliğine sahip. M1 Ultra’nın bellek bant genişliği 2080 ile 3090 arasında bir yerde.
Küçük batch boyutlarında, özellikle yerel işlerin çoğunda olduğu gibi batch 1’de, çıkarım işlem gücünden çok bellek bant genişliğine takılır. M* çiplerinin makine öğrenimi için iyi olduğu sözü buradan geliyor.
Ancak H100 esas olarak devasa batch boyutlarında eğitim için kullanılıyor ve büyük modelleri eğitmek için çok sayıda ara bağlantı gerekiyor. O ölçekte aritmetik yoğunluk çok yüksek olduğundan, M* çipleri ağ üzerinden birbirine bağlanabilse bile pek rekabetçi olmaz. H100 gibi çok güç tüketen çiplere kıyasla güç/verimlilik Pareto eğrisinde farklı bir noktayı seçmiş sayılır.
Google’ın gerçekten yapması gereken şey 2nm EUV alanına girmek ve 2nm’nin altına inmek.
Elektron litografisi olsun, ASML’in çiplere baskı yaptığı teknoloji olsun, böyle bir şeye sahip olursa gerçekten tehlikeli bir oyuncu hâline gelir. Google X tarzı sert bir moonshot projesi gerekiyor gibi.
Ya da belki tek bir ekipmanı satın alacak 500 milyon doları vardır. TPU gerçekten bu kadar iyiyse, kendi teknolojisi ve kendi fab’ına kadar dikey entegrasyon yapmak iyi bir iş olabilir.
Bugün ileri seviye fab’ların kâr etmesinin nedeni, çeşitli müşteriler ve kullanım alanları için genel amaçlı bilgi işlem cihazları üretmeleri ve onlarca yılda birikmiş yetenek ve mühendislik birikimidir. Üstelik müşteriler de Micron’un chip-on-chip HDI verim iyileştirmesi, Xilinx’in die’lar arası iletişim fabric’i ve çok çipli substrat tasarımı gibi kritik alanlarda inovasyonu bağımsız olarak ileri itiyor.
TPU, gerekli hacimleri asla yaratamaz ve kârlı ölçek ekonomisi oluşturacak müşterileri de çekemez. Google’ın rakiplerine kıyasla cazip bir fiyat da sunması gerekir.
Yeterince ikna edici bir iş gerekçesi varsa mevcut fab’lar memnuniyetle kapasite ayırır. TPU şu anda bunun için hiç de o kadar ikna edici değil.
TensTorrent’tan Jim Keller’ın yapay zeka çekirdekleri oluşturmak için farklı bir yaklaşımı anlattığı bir sunumu dinledim. 5 RISC-V çekirdeği koyup birini veri yüklemeye, birini veri upload etmeye, kalanları da matris işlemlerine ayıran bir yöntem.
Google TPU’dan da bahsetti; programlamanın VLIW ile uğraşmak gibi olduğunu ve derleyici üzerinde yaklaşık 500 kişinin çalıştığını söyledi.
Orijinal metinde “TPU v1, yaklaşık 20 komutu olan bir CISC tasarımı” deniyor; CISC/RISC’in keskin bir gözlemden araştırma programına, devrimci teknolojiye, pazarlama moda sözcüğüne ve sonunda tamamen anlamsız bir şeye dönüşmesi komik.
Buna terimlerin yaşam döngüsü demek gerek sanırım.
Bu yüzden TPU’nun komut sayısı az olsa bile her komut oldukça karmaşıksa CISC olabilir. Gerçi bilgisayar mimarisi dersini en son 15 yıl önce yüksek lisansta aldım, o yüzden hatırladıklarım bulanık. O dönemin büyük kısmını artık işe yaramaz hâle gelmiş Itanium ile ilgili işlere harcamıştık.
Foundry kapasitesi talebi çok büyük görünüyor; Microsoft veya Google kendi çiplerini yapıp üretime ihtiyaç duyduklarında sıranın en önüne nasıl geçiyorlar merak ediyorum.
Yeterince basit olup “eski ve talebi daha düşük” fab’larda da üretilebiliyorlar mı? Apple ve Nvidia’nın zaten çok fazla foundry kapasitesini tuttuğunu biliyorum.
https://en.wikipedia.org/wiki/Tensor_Processing_Unit#Product...
HBM gibi alanlarda da ciddi bir varlıkları ve harcamaları var; SemiAnalysis’te bununla ilgili iyi yazılar bulunuyor.
LLM’ler gerçekten -1, 0, 1 kuantizasyonu ile büyük ölçüde yaygınlaşırsa donanımın nasıl değişeceğini merak ediyorum.