Dalla fisica del silicio al rack AI: come nasce (e lavora) un acceleratore moderno

L’AI “non vive nel cloud”: vive su una catena industriale complessa, fatta di fisica, strumenti di progettazione, impianti di fabbricazione, memoria avanzata, packaging sempre più sofisticato e — infine — integrazione a livello di rack e data center.

Per chi sviluppa software (frontend incluso) può sembrare lontano, ma basta guardare come cambiano latenza e costo dei servizi AI per capire che questi dettagli hardware stanno risalendo lo stack: incidono su throughput, disponibilità, prezzi e perfino sulle API che consumiamo.

Di seguito una panoramica coerente “dalla A alla Z” del percorso tipico di un acceleratore AI: dalla nascita del chip fino al modo in cui esegue un’inferenza in produzione.

---

1) Le sei fasi della filiera: la mappa mentale

Un acceleratore moderno attraversa, in grande, queste fasi:

1. Fisica dei semiconduttori: transistor, scaling, limiti energetici e di densità.
2. Design (EDA): progettazione logica/fisica con tool specializzati.
3. Fabbricazione (fab): litografia e processo su wafer.
4. Memoria: soprattutto HBM (High Bandwidth Memory) per acceleratori.
5. Packaging: integrazione logica+memoria, interposer, collegamenti die-to-die.
6. Rack-scale integration: reti ad alta banda nel rack (scale-up) e tra rack (scale-out).

La parte interessante è che oggi questi strati sono sempre più interdipendenti: non progetti un chip senza pensare a memoria, packaging e rete; e non progetti un rack senza pensare ai vincoli del chip.

---

2) Un esempio concreto: perché un “solo GPU” può essere composto da più die

Per anni era naturale pensare “un GPU = un die”. Oggi, con acceleratori top di gamma, questa equivalenza si rompe per un motivo molto semplice: il limite di reticolo (reticle limit).

Reticolo: il “campo visivo” della litografia

In fab, i pattern del circuito vengono trasferiti sul wafer tramite sistemi ottici. Il reticolo (semplificando) definisce l’area massima che puoi esporre in un singolo “campo”. Se vuoi un chip più grande di quel limite, non puoi semplicemente “allargare la foto”.

Soluzione: multi-die (chiplet) con collegamento ad altissima banda

Quando la dimensione desiderata supera il limite, una strada è realizzare più die separati e farli lavorare come un unico dispositivo logico. Per farlo serve un’interconnessione die-to-die estremamente veloce, capace di avvicinare il comportamento a quello di un singolo die monolitico.

Un ordine di grandezza tipico per questo collegamento è nell’intorno delle decine di terabyte al secondo di banda aggregata: numeri necessari per evitare che la “cucitura” tra die diventi il collo di bottiglia.

Implica una cosa importante: la performance non dipende solo dal silicio, ma anche da come i pezzi vengono connessi e impacchettati.

---

3) La “shoreline” del chip: quando memoria e interconnessioni definiscono la forma

Negli acceleratori AI moderni spesso vedi una disposizione fisica riconoscibile:

• su alcuni lati: moduli HBM (memoria ad alta banda) disposti attorno al die;
• su altri lati: link di interconnessione ad alta banda per parlare con altre GPU.

Questo perché il chip non è più “solo compute”: è un oggetto pensato per massimizzare banda di memoria e banda di comunicazione.

---

4) HBM: perché è centrale (e perché è difficile scalarla)

La HBM è diventata la memoria “naturale” per acceleratori AI perché offre:

• banda enorme (multi-terabyte/s a livello di GPU);
• efficienza energetica migliore rispetto ad alternative con banda simile;
• integrazione vicina al compute tramite packaging avanzato.

Memoria “a torre”: 12-high e oltre

HBM è tipicamente stacked, cioè impilata verticalmente in più strati (es. configurazioni “12-high”). Questo aumenta la capacità mantenendo footprint compatto e banda alta.

In pratica, attorno al compute trovi più stack HBM; ogni stack contribuisce a capacità totale e banda aggregata. È uno dei motivi per cui i principali produttori di HBM (in genere pochi player globali) sono un punto critico della supply chain.

Implicazione pratica per chi ragiona di modelli

La HBM non è “solo RAM”: determina

• quanti parametri puoi tenere residenti;
• quanta KV cache (fondamentale per LLM in produzione) puoi mantenere senza degradare throughput;
• quanto puoi spingere su batch e parallelismo.

---

5) Cache e datapath durante l’inferenza: il modello si carica una volta, poi conta il “riuso”

Una dinamica tipica in produzione è:

1. Caricamento iniziale: i pesi del modello arrivano da storage (spesso NVMe locale nel rack), passano dalla CPU e vengono messi in HBM.
2. Forward pass ripetuti: ogni richiesta usa pesi e cache già residenti. Da qui in poi la performance dipende tantissimo da cache hit e località dei dati.

Perché i cache hit contano anche su GPU

Quando generi token in sequenza (next-token prediction), riusi continuamente:

• pesi del modello;
• attivazioni intermedie;
• soprattutto KV cache.

Più spesso ciò che ti serve resta vicino al compute (cache più vicine), meno “salti” fai nella gerarchia di memoria. In linea generale:

• hit in cache vicina → latenza più bassa, throughput più alto;
• miss fino a HBM → più passaggi, più latenza, maggiore pressione su banda.

Questa è una delle ragioni per cui l’ottimizzazione runtime (batching, scheduling, paginazione KV cache) è diventata un tema enorme: non è solo “software”, è gestione della gerarchia di memoria.

---

6) Scale-up vs scale-out: due reti, due problemi diversi

Quando un singolo modello non “sta” su una sola GPU (capienza o throughput), lo distribuisci. Qui entrano due domini distinti:

Scale-up (dentro il rack)

È il dominio ad alta banda e bassa latenza: molte GPU nello stesso rack collegate da un fabric dedicato. L’obiettivo è farle lavorare come un sistema quasi monolitico per il model parallelism (tensor/pipeline parallel, sharding, ecc.).

In alcune architetture la rete è pensata per connettività molto spinta (fino a pattern all-to-all), riducendo “hop” e colli di bottiglia.

Scale-out (tra rack / tra sistemi)

È il dominio “di data center”: collega rack o sistemi eterogenei tramite NIC/DPU, con vincoli diversi (banda più bassa rispetto allo scale-up, latenza più alta, topologie e oversubscription).

Traduzione pratica: quando un servizio AI cresce, prima cerchi di scalare “in verticale” nel rack (scale-up) per minimizzare la penalità di comunicazione; poi, quando devi distribuire davvero, passi a scale-out e accetti complessità maggiore.

---

7) Il punto chiave: i colli di bottiglia non sono più solo “compute”

Per anni la narrativa era: “più core = più performance”. Oggi è incompleta.

Le prestazioni reali in inferenza/training dipendono da un equilibrio tra:

• limiti fisici (densità, potenza, dissipazione);
• banda memoria (HBM e gerarchia cache);
• interconnessioni (die-to-die, GPU-to-GPU nel rack, network fuori dal rack);
• packaging (che abilita o limita tutto il resto);
• software di sistema (runtime, orchestrazione, gestione cache).

Se uno di questi è sotto-dimensionato, l’intero sistema “paga”.

---

Sintesi e implicazione pratica

Capire la filiera dei semiconduttori, oggi, significa capire dove si crea valore e dove si inceppa la scalabilità dei sistemi AI: nel limite di reticolo che porta al multi-die, nella disponibilità di HBM, nel packaging che rende possibile l’integrazione, e nelle reti (scale-up/scale-out) che determinano quanto un cluster si comporti come un unico computer.

Per chi costruisce prodotti software che consumano AI, la conseguenza è concreta: latenza, costo e affidabilità dipendono sempre più da questi vincoli fisici e architetturali. Ragionare “end-to-end” — dal token al transistor — è diventato un vantaggio competitivo, non una curiosità da hardware engineer.