6.5.7 · D2 · HinglishAdvanced & Emerging Architectures

Visual walkthroughGoogle TPU architecture and systolic arrays

2,313 words11 min read↑ Read in English

6.5.7 · D2 · Hardware › Advanced & Emerging Architectures › Google TPU architecture and systolic arrays

Hume sirf ek running example chahiye, toh aao ise ab fix kar lete hain aur kabhi nahin badlenge:

aur sirf numbers ki grids hain. mein 2 rows aur 2 columns hain; mein bhi utne hi hain. Hum unka product chahte hain, jo bhi ek grid hai. Hamara poora mission: cells ki ek choti machine banao jo nikale bina kisi bhi number ko memory se dobara padhe.


Step 1 — "Do matrices multiply karna" asal mein maangta kya hai

KYA. Matrix multiplication ka rule kehta hai: ke row , column mein jo number hai — use likhte hain (padho "C-eye-jay", row aur column par entry) — yeh ki row ke saath chalte aur ke column se neeche jaate hue banta hai, jo pairs milte hain unhe multiply karo, aur add kar do.

Yahan ka matlab hai " ki row , column mein entry." Chote numbers sirf grid par addresses hain.

KYUN. Hardware banane se pehle, hume exactly pata hona chahiye ki har output kaunsa sum hai. Machine jo kuch bhi karti hai woh is ek formula ki physical realisation hai. Agar hum target galat le lein, toh koi bhi clever wiring hume nahi bachayegi.

PICTURE. Figure dikhata hai bante hue: ki upar wali row (orange) ke left column (teal) ke across slide karti hai; crossings woh products hain jo hum add karte hain.

Figure — Google TPU architecture and systolic arrays

Concretely, . Yeh number yaad rakho; machine ko ise reproduce karna hai.


Step 2 — Woh ek cell jo ek "multiply-and-pile-up" karta hai

KYA. Hum poora array ek repeated part se banate hain: ek processing element (PE) — ek chota box jo exactly ek multiply aur ek add clock ke har tick par kar sakta hai. "Clock ka ek tick" (ek cycle) heartbeat hai: har cell ek saath ek baar karta hai, phir dobara. Cell ke andar ek stored weight rehta hai aur ek running total jise accumulator kehte hain, likha jaata hai .

Har cycle mein cell karta hai:

  • = woh number jo abhi left se andar aaya hai ( ki ek entry).
  • = woh number jo is cell ke andar parked hai ( ki ek entry).
  • = growing sum jo ki ek entry banega.

KYUN. Step 1 par wapas dekho: ek output products ka sum hai. Ek "multiply-then-add-to-a-total" box sabse choti machine hai jo aisa sum grow karti hai. Hum in-place pile up karte hain taaki partial answer ko cell se bahar jaana na pade — isi tarah hum memory wall se bachte hain.

PICTURE. Ek cell, labelled: weight andar frozen, left se enter karta hua, aur accumulator tick up karta hua.

Figure — Google TPU architecture and systolic arrays

Step 3 — Activation ko aage paas karna (ek baar padho, kai baar use karo)

KYA. Ek cell sirf consume nahin karta; woh use apne right wale neighbour ko bhi deta hai, unchanged:

Yeh equation trivial lagti hai, lekin yahi magic hai. Yeh kehti hai: wahi activation, yahan use hone ke baad, travel karta rehta hai aur agla cell ek cycle baad use karta hai.

KYUN. Matmul rule mein, number ki row ki har entry mein aata hai (). Toh ko memory se ek baar padha jaana chahiye aur phir physically un sab cells mein chalna chahiye jise iska zaroorat hai. wahi walk hai. Ek baar padhna aur baar reuse karna exactly wahi hai jo arithmetic intensity badhata hai.

PICTURE. Ek akela activation (orange dot) cells ki ek row mein left→right march karta hua, har ek mein ek alag parked weight se multiply hota hua, jabki partial sums neeche girte hain.

Figure — Google TPU architecture and systolic arrays

Step 4 — Weights park karo: ko grid mein rakhna

KYA. cells ka grid banao. Koi bhi activation flow hone se pehle, hum ko cells mein load karte hain, ek weight per cell, position ke hisaab se matched: row , column wala cell store karta hai.

Layout dhyan se padho: array ka column , ka column hold karta hai. Yeh deliberate hai — array ka column , ka column produce karega.

KYUN. Har output ko pair chahiye. Array-column mein ka column vertically stack karke, us column mein stream karta hua activation exactly woh weights milta hai jine use multiply karna hai. Geometry hamare liye bookkeeping kar deti hai.

PICTURE. grid mein charon cells mein frozen, colour-coded by ki woh ke kis column ki serve karte hain.

Figure — Google TPU architecture and systolic arrays

Step 5 — Activations stream karo aur dekho kaise grow karta hai

KYA. Ab grid mein ki ek row push karo. ki row 1 lo, jo hai , aur ise array-column 1 ke cells mein feed karo (jo aur hold karte hain). Us column ka accumulator collect karta hai:

Wahi row 1 ko array-column 2 mein feed karo (jo aur hold karta hai):

Har partial sum () ek cell mein upar se enter karta hai, ek product add hota hai, aur neeche ke roop mein nikalta hai:

KYUN. Step 1 ke target se compare karo. Array ne ise bina ek bhi instruction fetch ke reproduce kiya — wiring hi program hai. Woh sum jo pehle time mein unfold hota tha (CPU par loop iterations) ab space mein unfold hota hai (cells ke column mein neeche).

PICTURE. Row column 1 mein enter karti hui; partial sum accumulate karta hua, phir hota hua jaise woh do cells se neeche girta hai.

Figure — Google TPU architecture and systolic arrays

Step 6 — Skew: kyun inputs diagonally enter karte hain (timing edge case)

KYA. Ek subtlety hai jo hum gloss over kar gaye: cells ek saath har cycle mein kaam karte hain, lekin data ko travel karne mein time lagta hai. Agar hum har activation ko ek hi cycle mein push kar dein, toh upar se aate partial sums galat activation se milenge. Fix yeh hai ki inputs ko stagger (skew) karo: data ki row 2, row 1 se ek cycle baad enter karti hai, row 3 ek aur baad, ek slanted diagonal wavefront banate hue.

KYUN. Kisi product ke correct hone ke liye, activation aur partial sum ko same cell mein same cycle par rendezvous karna chahiye. Kyunki partial sum ko neeche jaane mein har cycle ek hop lagta hai, aur ek activation ko cross karne mein har cycle ek hop, hume unke launch times offset karne chahiye taaki unke paths sahi instant par cross karein. Har row ke liye ek cycle skewing se poora grid synchronise ho jaata hai.

PICTURE. Inputs ka ek slanted "wavefront": data ki top row already array ke andar deep jabki agla row abhi sirf enter ho raha hai — woh tell-tale diagonal staircase.

Figure — Google TPU architecture and systolic arrays

Step 7 — Cost count karo: fill, drain, aur kyun arrays bade batches chahte hain

KYA. Ek array ke liye (yahan ; TPUv1 mein ), pehla result tab tak nahin aa sakta jab tak data poore grid mein diagonally propagate na ho jaaye. Woh warm-up fill hai; pipeline afterward khaali karna drain hai. Saath mein unka cost lagbhag cycles hai. Pipeline full hone ke baad, results ki ek nayi row har cycle mein nikalt hai. Toh rows input push karne mein lagta hai:

Efficiency — useful streaming karne wale cycles ka fraction — hai:

KYUN. Us fraction ki shape dekho. Agar tiny hai, toh fixed dominate karta hai aur zyaadatar cycles warm up mein waste hote hain. Agar bahut bada hai, toh fixed cost average mein vanish ho jaata hai. Yahi precisely reason hai ki TPU bade batches ke liye throughput machine hai, low-latency machine nahin — ek idea jise Roofline model aur arithmetic-intensity view quantitative banata hai.

Numbers. ke liye: fill/drain . efficiency achieve karne ke liye:

toh lagbhag 4600 rows (parent ka "" rounder use karte hue).

PICTURE. Efficiency curve near-zero se ki taraf badhti hui jaise batch size grow karta hai, line marked ke saath.

Figure — Google TPU architecture and systolic arrays

Ek-picture summary

Upar ki sab cheez ek single frame mein collapse ho jaati hai: grid mein parked weights, left se flow karte activations ka skewed diagonal, neeche cascade karte partial sums, aur ki finished entries bottom se drop karti hain.

Figure — Google TPU architecture and systolic arrays
Recall Feynman retelling — plain words mein wapas bolo

Hum do grids of numbers multiply karna chahte the. Har answer-box sirf ek row-times-column "dot product" hai — matching pairs multiply karo aur pile up karo. Toh humne ek chota box banaya jo ek multiply-and-add har heartbeat par karta hai, aur humne unka poora grid glue kiya. Humne doosri matrix ke numbers boxes ke andar park kiye (har ek apni jagah rehta hai — weight-stationary). Phir humne pehli matrix ko left se feed kiya, aur yahan trick hai: har box, ek incoming number use karne ke baad, use apne neighbour ko unchanged deta hai — toh har number memory se ek baar padha jaata hai lekin ek row mein sab jagah reuse hota hai. Partial sums har column mein neeche slide karte hain, badhte hue jab tak woh ek answer-box ke barabar na ho jaayein, phir bottom se gir jaate hain. Incoming number aur girte sum ko sahi box mein sahi beat par milane ke liye, hum input rows ko ek slanted staircase mein release karte hain (har row ke liye ek beat baad). Pipeline warm up karna aur drain karna ek fixed number of beats cost karta hai, toh chote jobs warm up mein time waste karte hain — isliye TPU bade batches pyaar karta hai, jahan har ek beat par ek answer-row niklti hai.

Recall Quick self-test

Activation ko right neighbour ko unchanged kyun pass kiya jaata hai? ::: Taaki ise memory se ek baar padha jaaye lekin row mein har cell reuse kare — woh reuse trick jo memory wall ko beat karti hai (). Inputs diagonally staggered kyun enter karne chahiye? ::: Taaki har activation aur uska descending partial sum same cycle mein same cell mein pahunche; har row ke liye ek cycle skewing se rendezvous synchronise hota hai. Ek array ke liye, roughly kitna batch efficiency deta hai? ::: Lagbhag rows (fill/drain , solve ). Throughput ki jagah kyun scale karta hai? ::: cells hain, har ek har cycle mein ek MAC karta hai — parallelism spatial hai, toh peak FLOP/s.


Related: ASIC vs FPGA vs general-purpose processors · Quantization and 8-bit inference · GPU architecture and SIMT execution